X

C++相談室 part161

■ このスレッドは過去ログ倉庫に格納されています
0483デフォルトの名無しさん
垢版 |
2022/08/16(火) 14:48:39.55ID:oZyv9MO8
>>481
C++は需要が減り衰退していく
昔はともかく現代の視点からは、設計が悪くそこへ建て増しを繰り返しているため、言語として劣っていて使いにくい
そのため次第に既存システムの保守がメインの言語となっていっているが、それさえGoogleの発表したCarbonのような言語の方がプログラマーにとってもありがたい
もちろんそのCarbonでさえそのFAQにこれはあくまでも既存の保守用の言語でと書かれている
0485デフォルトの名無しさん
垢版 |
2022/08/16(火) 15:07:03.88ID:2x3mrzZQ
>設計が悪くそこへ建て増しを繰り返している

言語仕様がそうなっていることは認めるが
設計が悪い部分は無理して使わず良い部分だけ使えば良い話でもある
0487デフォルトの名無しさん
垢版 |
2022/08/16(火) 15:24:11.24ID:n8xVLVvG
>>481
需要で言えばCOBOLでさえ無くなっていないからなぁ。

c++の完全置き替えはRustがようやっとスタート地点に立てたくらい。でもRustは初心者お断りだから無理なんじゃない？

個人的にはRustを参考にした初心者向けのサブセットC++か、Rustの複雑さをマイルドにしたスタックフレーム指向の新言語が出てくると思う。
0489デフォルトの名無しさん
垢版 |
2022/08/16(火) 15:57:43.55ID:bqAknUU+
>>487
誰が見てもC++よりRustの方が言語仕様も小さいしシンプルで洗練されていて学習しやすいよ
これは両方を使っている人なら必ず分かるから>>487は知らないものを妄想で語っている？
ちなみにRustはコンパイラによるアドバイスが非常に親切でプログラミング言語の中でもトップクラスな点でもC++との差異が大きいね
0490はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/16(火) 16:21:45.34ID:+o+ePBjP
どうだろうなぁ。
C を学んでいる人が多かったというところから実務に使いながら少しづつ C++ に習熟していくという動線があったわけで、
C という前提が崩れたら Rust のほうが合理的に設計されていて楽かもしれないとは思う。
ただ、その一方で C++ が消えてなくなるほど劣勢になる気はしないんだよな。
0491デフォルトの名無しさん
垢版 |
2022/08/16(火) 16:38:57.39ID:GaLydNkX
c++とかcやってからじゃないと到底無理
ってよく聞くんですけど
どういうことですかね？
0492デフォルトの名無しさん
垢版 |
2022/08/16(火) 16:39:15.94ID:uEezmwqj
class b:a{};
class a{};
このコードはコンパイルできませんが、aを前方宣言せずにコンパイルを通す方法ってありますかね?
0493デフォルトの名無しさん
垢版 |
2022/08/16(火) 17:52:12.39ID:2x3mrzZQ
1.
class a;
class b:a{};
class a{};

2.
class a{};
class b:a{};
0494はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/16(火) 17:53:02.94ID:+o+ePBjP
>>491
個々のルールを頭に詰め込むだけってのはしんどい。
思想に沿うように個々のルールが制定されているので思想が分かればある程度はルールの想像がつく。
低レイヤで何が起こるかある程度は認識していると思想が把握しやすい。

C++ の駄目な部分を見た後に Rust を見ると「こういうのが真っ当な仕組みだよな！」という納得もしやすいし。

ただ、 C++ の「汚くていいんだ」というのもそれはそれで優しい世界なので私は好きだよ。
0495デフォルトの名無しさん
垢版 |
2022/08/16(火) 19:22:32.37ID:wpAgGEI5
>>489
初心者からすればC++とRustの差なんて無いに等しい。コード１行書くのにいくつのルールを守る必要があるんだよ。
シンプルで洗練されている言語が初心者に良いというなら、RustよりFORTH(とその末裔)の方が初心者にふさわしいと思うわ。
0497デフォルトの名無しさん
垢版 |
2022/08/16(火) 22:17:19.28ID:bk3ffD66
>>495
FORTHはCと同等の速さを出せないし問題のすり替えはみっともない
RustはCと同等の速さを出しつつ現代的なプログラミングしやすい様々なパラダイムを洗練してシンプルにまとめている
FORTHを入れてC/C++/Rustの四者で比較してもRustがプログラミング効率も良いと同意できるだろ
0498デフォルトの名無しさん
垢版 |
2022/08/17(水) 02:44:27.88ID:C+o8slGL
夏厨って夏に湧いて出る厨房の事を指す言葉だったはずだけど
その厨房も今じゃ中年おじさんなんだよな
0500デフォルトの名無しさん
垢版 |
2022/08/17(水) 05:49:59.92ID:jVY1lffe
>>499
そうかな
C++(スマポ必須で所有権)よりはRustがシンプルではっきりと初心者向けだよ
自動解放で安全が前提でないと困るからその二つが比較対象で合っているよね
0501デフォルトの名無しさん
垢版 |
2022/08/17(水) 07:00:37.46ID:8QCiHT08
皆さんのオブジェクト指向に対する考え方
おください!
0502デフォルトの名無しさん
垢版 |
2022/08/17(水) 08:26:24.61ID:/AaT26gR
>>500
C++との比較なんてしていない。よく読め。
C++が駄目なのと同じくらいRustも初心者の学習コストはダメ。
C++はまだ部分的に汚く使う柔軟性を持つから、better c くらいのところから段階的に使う余地はある。しかしRustはいきなり複数の概念(所有権とか参照とかmoveとか)を使わないとプログラムが書けない絶壁の学習コストをしているから、「とりあえず使う」という選択肢が無い。初心者の選ぶ言語にはならんよ。
0503デフォルトの名無しさん
垢版 |
2022/08/17(水) 08:34:18.80ID:/AaT26gR
>>501
オブジェクト指向のオブジェクトは主体/客体のサブジェクト/オブジェクト。
プログラマー(主体)が操作・命令する対象(客体)をまとめて整理する考え方＆手法がオブジェクト指向。
0506デフォルトの名無しさん
垢版 |
2022/08/17(水) 08:50:31.11ID:svOZgDad
他の言語との類似や相違など色んな話題が出てもええんちゃう
特にRustはC++後継言語の一つでもあるし
0508デフォルトの名無しさん
垢版 |
2022/08/17(水) 09:18:05.65ID:3A+P/0wQ
GAFAMがRustをC++の後継言語の1つとして位置付けてRust Foundationを共同で設立したりしてますもんね
ただしGoogleは既存コードのメンテ用としてはCarbonもC++の後継言語の1つとして実験していますね
Rustはシステム更新時や分離できる新たな部分に対してC++の後継言語となるのでしょう
0509デフォルトの名無しさん
垢版 |
2022/08/17(水) 09:43:49.92ID:G5jxF3Mu
>>504
C++関連としては>>487。
あとは「Rustは初心者向けじゃないからC++後継できるところまでは行かん」という主張に対する話。C++だって学習障壁から初心者取り込みできずにユーザー規模が縮小しつつあるのに、もっと絶壁のRustが普及するとは思えん。
C++後継としてはRust以外の初心者に配慮した言語が来るんじゃない？
0510デフォルトの名無しさん
垢版 |
2022/08/17(水) 10:06:28.08ID:JpVQLN3v
スマポすなわち所有権を使ってるC++プログラマーならRustは簡単で楽勝
まともな案件ならばスマポ使っているし、急にではないけど、より安全なRustへ徐々に少しずつ移っていくんだと思うよ
0511デフォルトの名無しさん
垢版 |
2022/08/17(水) 10:18:24.59ID:T2QftTg0
>>506
それなら類似や相違など語り合うスレのほうがいいのでは？
無いなら立てれば良いし
C++の相談に来ているスレで今はRustだよなんて言われてもね
0512デフォルトの名無しさん
垢版 |
2022/08/17(水) 10:27:35.49ID:tNGd1WjN
学習障壁でユーザー規模が縮小って
なんかCOBOL臭えな

アホフィルタを外すより待遇を改善すべきだろ
マ板でやるべき内容だな
0514デフォルトの名無しさん
垢版 |
2022/08/17(水) 10:41:14.61ID:tNGd1WjN
は？ 「C++が使える」アホは俺でも知ってるが
それがこの話と何か関係あるのか？
0518デフォルトの名無しさん
垢版 |
2022/08/17(水) 12:03:04.79ID:tNGd1WjN
都合が悪くなると荒らしたいだけとか全く
C++相談室でRustを連呼するやつに言われたかねえな
0519デフォルトの名無しさん
垢版 |
2022/08/17(水) 12:06:02.53ID:tNGd1WjN
相談者はチームで突然、Rustに変えようと言い出せば
解決につながるとでも言うのか
そんな力のあるやつが相談に来るとでも？
0521デフォルトの名無しさん
垢版 |
2022/08/17(水) 12:50:49.80ID:hpgzuSC5
手動メモリ管理のZigでは無理だよ
手動メモリ管理で複雑化したときにどうしても発生している穴を防ぐことがどのIT企業でも課題となっている
0523デフォルトの名無しさん
垢版 |
2022/08/17(水) 13:46:04.27ID:0xu2lUBy
shared_ptrやunique_ptrで特に問題ないと思うが?
手動メモリ管理ってパフォーマンスでも気にしてるの?
0525デフォルトの名無しさん
垢版 |
2022/08/17(水) 15:14:20.93ID:ka8BV2dl
>>522
それはJavaがGC言語だからしょうがない
非GC言語でプログラマーによるコードに依存せず自動メモリ解放して欲しいならば現状Rustしかない
0528デフォルトの名無しさん
垢版 |
2022/08/17(水) 15:53:30.62ID:RcTU5KfW
>>523
正確にはスタックフレームに積む or スマートポインタを使ってヒープに置く、だな。

shared ptrは関数呼び出し時の値渡しのインクリメントデクリメントコストが気になるところ。
スタックフレームに存在するかどうかで参照渡しか値渡しかを自動で切り替えると便利そうだけど、最適化で上手く処理してくれたっけ？
0529デフォルトの名無しさん
垢版 |
2022/08/17(水) 15:54:04.11ID:aLEYi9j0
>>526
使い忘れと使い方ミスを常に完全にゼロにできるならばunique_ptrとshared_ptrでOK
しかし複雑化した時にミスを常にゼロにすることは不可能だと判明している

一方でC++からRustにすると以下のようなメリットが山のようにある
・Rustでは使い忘れや使い方ミスをするとコンパイラが必ず指摘してエラーとしてくれる
・Rustでは何も指定しない標準状態でC++のunique_ptrより高機能であるため記述がスッキリそして分かりやすい
・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるがRustではそのコストを必要としない
などなど
0532デフォルトの名無しさん
垢版 |
2022/08/17(水) 17:56:04.99ID:IlAVLAST
この手の議論って「全てのプログラマがポインタを直に操作する必要に迫られている」という詭弁に基いていて辟易するんだよな
0535デフォルトの名無しさん
垢版 |
2022/08/17(水) 18:40:18.95ID:JVW7ncQZ
>>532
ある程度の大きなデータは抽象的な意味でcall by reference (pointer) により受け渡しすることになり実装的にはポインタを使わざるをえない気もする
0536デフォルトの名無しさん
垢版 |
2022/08/17(水) 19:39:41.85ID:/AaT26gR
>>529
Rustの変数をunique ptrと比較している時点でRustの利点を理解出来ていない。
Rustの変数に対応するのはあくまで自動変数で、unique ptr に対応するのはBox<T>。

Rustは「高速化と自動化のためにできるだけスタックフレームを活用する」という基本的な考え方があって、そのためにあの窮屈なルールで自動変数を高機能化している。
Rustの変数がデフォルトムーブだからといって、Rustの変数はunique ptr みたいなものとするのは理解の足りない粗忽者のやることだわ。
0537デフォルトの名無しさん
垢版 |
2022/08/17(水) 19:59:51.79ID:07u67rxx
>>536
ある意味それも正しいが現実問題じゃないな
例えばi32を10個返す関数を作るとして
その型を[i32; 10]、Box<[i32; 10]>、Vec<i32>のそれぞれにした場合に生成コードはどうなりどれを選ぶべきか考えるとBoxの意義がなああ
結局Rustではもっと最適なものを選ぶからunique_ptr相当すら使うことがレアだよな
0538デフォルトの名無しさん
垢版 |
2022/08/17(水) 20:32:26.88ID:k/cupzFM
>>491
C++ちょっと分かったなーって気持ちになれるまでの遠い道のりを考えると、Cができるなんて入口にすら立ってない感じ。
だからC知ってたくらいではアドバンテージないよ。個人の感想です。
0539デフォルトの名無しさん
垢版 |
2022/08/17(水) 21:07:14.75ID:0xu2lUBy
>>529
>・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるが
>Rustではそのコストを必要としない
本当にコストは必要ないのかな?
本当に参照カウントしないのかな?
0542デフォルトの名無しさん
垢版 |
2022/08/17(水) 21:37:14.43ID:IDhwUS5q
>>539
Rustは借用(とライフタイム)があるから、
複数の参照が同時に必要となっても、
所有者は一人のまま何も変わらず、
複数の借用を普通に使うだけで済んでしまい、
付加コストの発生は無し。

一方でC++は、
複数の参照が同時に必要となる場合、
unique_ptrではもちろんダメなので、
shared_ptrを使わざるを得ず、
参照カウンタ増減という付加コストが発生。
0543デフォルトの名無しさん
垢版 |
2022/08/17(水) 21:39:05.15ID:bVkA6pax
>>540
デフォルトはヒープを想定しているだろ。
Rustの変数はデフォルトスタックを想定している。
0544デフォルトの名無しさん
垢版 |
2022/08/17(水) 21:40:11.05ID:GcPebzMx
そんなん設計でどうにでもなる
ありきたりの道具使ってばっかいるからアタマが退化してんだろ
0545デフォルトの名無しさん
垢版 |
2022/08/17(水) 21:41:54.05ID:GcPebzMx
>shared_ptrを使わざるを得ず
おまえがそう決め付けているだけで、ここら辺は設計でどうにでもなる
0547デフォルトの名無しさん
垢版 |
2022/08/17(水) 21:51:11.86ID:eXFNTowk
同じクラスが重複して定義されたとき、
そのクラスに変数が定義されていてもコンパイルエラーにならないのはなぜですか？
関数が定義されている場合、インライン展開されないとコンパイルエラーになると思います
変数にはそのような指定が無いと思いますが、なぜエラーにならないのでしょうか？
0548デフォルトの名無しさん
垢版 |
2022/08/17(水) 22:07:13.27ID:vZEBwtyc
言っている意味がちょっとわからないので最小のコードを提示してもらえるとありがたい
0549デフォルトの名無しさん
垢版 |
2022/08/17(水) 22:09:46.76ID:wEP2ktHW
単純に、同じクラスを（同じ定義で）二回定義してもエラーにならんの
便利なようで不思議だよな
0551デフォルトの名無しさん
垢版 |
2022/08/17(水) 22:12:24.01ID:vZEBwtyc
大抵インクルードガードで１回しか通らないようにしてたけど
（クラス定義だけなら）インクルードガードなしで二重に読んでも通るってことなのか…　それはしらんかった
0553デフォルトの名無しさん
垢版 |
2022/08/17(水) 22:17:02.42ID:IDhwUS5q
>>550
それはダングリングポインタになりうるからダメ
C++には借用とライフタイムの概念がないため先に解放されてしまう事態を避けられない
0554デフォルトの名無しさん
垢版 |
2022/08/17(水) 22:35:58.47ID:eXFNTowk
以下のコードをヘッダに記述して複数のソースでインクルードすると、
関数fooは重複定義でコンパイルエラーになります
inline指定にすると、コンパイルは通るようになります

class myClass {
public:
void foo();
int i;
};

void myClass::foo() {
std::cout << "OK";
}

このとき変数iは何故重複定義にならないのでしょうか？
fooと同様に複数のソースで重複定義になる気がするのですが
0555デフォルトの名無しさん
垢版 |
2022/08/17(水) 23:24:22.15ID:0xu2lUBy
>>542
コンパイル時に参照数が決まらない場合は参照カウントしてるやろ?
コンパイル時に決まるよう状況ならC++でもT&で十分
0556はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/17(水) 23:28:24.67ID:ito9w61P
>>554
int i; はメンバ宣言に該当するがそれ自体は定義ではない。
クラス定義の中にメンバ宣言があるってのがようわからん理屈だがその時点では実体が作られない、
逆に言えばその型のオブジェクトを生成するときになって初めて実体が作られるので
この段階では重複として排除する必要がない。
0557デフォルトの名無しさん
垢版 |
2022/08/17(水) 23:31:25.13ID:6ShnCCAk
>>553
参照を渡した先でどこかに参照を格納・保持して後で使う必要があるなら shared_ptr で
渡すのがいい状況になりそうだけど、その場合は Rust でも借用では済まないのでは？
0558デフォルトの名無しさん
垢版 |
2022/08/17(水) 23:51:08.75ID:eXFNTowk
>>556
ありがとうございます
グローバルスコープに定義するときは、
int i;
この記述で定義になるので、複数のソースでインクルードすると当然重複定義になります
クラス内では宣言のみになるとは思いませんでした
そういうものと覚えるしかなさそうですね
0559はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/18(木) 00:07:40.00ID:KKIhvA0h
>>553
C++ にもライフタイムの概念はあるよ。
コンパイラが検査してくれないってだけ。
ダングリング参照を作ってはいけないというルールは C++ でも Rust でも同じ。
0560デフォルトの名無しさん
垢版 |
2022/08/18(木) 02:53:41.59ID:TJJ2kcCc
>>555
スマポを使っている限りは安全だと客観的にも保証されるけど
そこでT&を使ったら自己責任の世界に戻ってしまい意味なしとなってしまう
0561デフォルトの名無しさん
垢版 |
2022/08/18(木) 04:29:06.72ID:HNqVdbFt
>>559
決定的な違い
Rustではダングリング参照するプログラムを絶対に作れない（コンパイラがエラーとする）
C++ではダングリング参照するプログラムがうっかり容易く生じてしまう（そしてコンパイラが通してしまう）
0562デフォルトの名無しさん
垢版 |
2022/08/18(木) 04:53:19.13ID:X/mZUHYK
>>561
話変わってるだろ
検査してくれるかどうかじゃなくて
> ・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるがRustではそのコストを必要としない
の話だったと思うが？
0563デフォルトの名無しさん
垢版 |
2022/08/18(木) 05:23:06.33ID:l0miaXwd
>>562
それはC++で安全を保証しようとすると
複数の参照を用いるならば常にshared_ptrの使用を必須とするしか安全を保証できないのに対して
Rustは複数の参照だけなら借用のみで安全を保証できるという話ではないか

ちなみにRustでは複数の参照ではなくもっとレアケースである複数の所有が生じた時に初めてコンパイラがRcを要求する
つまりRustでは参照と所有が明白に分離されているところが大きな違いとなる
0565デフォルトの名無しさん
垢版 |
2022/08/18(木) 07:06:14.45ID:DhI3ZTcW
C++11以降のマナーでは、ダングリングは発生しない。
設計を見直すべきでは？

旧い規格、例えばDOMを実装する場合、設計を見直すことはできない。
ところで、DOMについて、C++によるGoogle Chromeの実装は素晴らしい洞察で問題を回避している。
後学のために読んでみるとよい。
0566デフォルトの名無しさん
垢版 |
2022/08/18(木) 07:10:02.07ID:DhI3ZTcW
如何にして安全なスパゲッティ・コードを書くかというのがRustのアプローチなら。
C++の方法論は、「安全なスパゲッティなど存在しない、素麺にしましょう」ということ。
旧式のスパゲッティ・コードを書きたい人にとってC++は役に立たない。
0567デフォルトの名無しさん
垢版 |
2022/08/18(木) 08:09:28.79ID:ywzuYu7m
まぁ、c++でももっと積極的にスタックフレームに限定するアプローチは欲しいよね。

以前にインスタンスがスタックフレームに存在することを保証するスマート変数を作ろうとしたけど、インスタンス変数をどうしても制限できなくて挫折したことがある。
スマートポインタが必ずスタックにあるのなら、スマートポインタの参照渡しとかもっと活用できるのにね。
0569デフォルトの名無しさん
垢版 |
2022/08/18(木) 09:19:43.25ID:X/mZUHYK
>>567
> 以前にインスタンスがスタックフレームに存在することを保証するスマート変数
それなんの意味があるんだ？
てかC++ならスタック上にインスタンス生成すればよくね？
0571はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/18(木) 10:26:05.65ID:KKIhvA0h
大抵の環境でデフォルトのスタックサイズはそれほど大きくない。
数メガバイトというのは現代的な感覚では極端に小さいようにも見える。

でもまあだいたいこれで足りるし、足りるように書くのが普通なんじゃないの。
0572デフォルトの名無しさん
垢版 |
2022/08/18(木) 11:28:19.94ID:p/limWqp
C > Nim > C++ > Rust
0573デフォルトの名無しさん
垢版 |
2022/08/18(木) 11:29:37.71ID:p/limWqp
>>569
GC要らなくなる
0574デフォルトの名無しさん
垢版 |
2022/08/18(木) 11:47:13.53ID:u9P7LJR3
>>571
スタックオーバーフローしたら Linux/Unix は自動拡張しなかったっけ？
Windows はなぜか（オプションで可変出来るけどスレッド起動後は）固定なんだよね
0576はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/18(木) 12:03:37.12ID:KKIhvA0h
>>574
割り当てが足りなくなれば拡張するが、その上限の設定がデフォルトでは 8MB になっている。
0578デフォルトの名無しさん
垢版 |
2022/08/18(木) 12:35:06.23ID:R9m+Nq0X
ポインタたくさん使う人っておじさんですよね？
実年齢か精神年齢かはともかく
0579デフォルトの名無しさん
垢版 |
2022/08/18(木) 12:37:54.86ID:ywzuYu7m
>>577
ちょっと補足。
スマートポインタがスタックにあるのなら、shared ptr の参照とかポインタみたいなヤバイのもそこそこ安全に扱える。余計なインクリメントデクリメントも発生しなくて良くなるし。
0582デフォルトの名無しさん
垢版 |
2022/08/18(木) 13:29:45.98ID:KxsikMs2
>>563
つまりコンパイル時に参照数が決まらない場合はRustも参照カウントする

>>529
>・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるが
> Rustではそのコストを必要としない
従ってこれは間違っている
0583デフォルトの名無しさん
垢版 |
2022/08/18(木) 13:34:11.90ID:AgenDKWc
>>579
一見その通りだけど
関数で参照を返したい時に、その実体が呼び出し元(かそれ以前)のスタックフレーム上なのか、
それとも消え去る現在のスタック上なのか、安全を保証するために区別する情報が必要となる

そのためにはライフタイムをもっと明確化すればよく、参照が指す実体がスタック上でより深く(か同じ)ことを保証できればよい

すると更に大きな利点が生じる
実体がスタック上に無くてヒープ上に有っても、それを管理するスマポ相当がスタック上にあればライフタイムは同じとなるからだ
結局、スタック上かヒープ上かよりも、ライフタイムを明確化することが重要であると分かる

以上を言語仕様に組み込んだのがRust
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況