C++相談室 part161

**デフォルトの名無しさん** · 2022/05/21(土) 21:23:29.59

前スレ
C++相談室 part160
https://mevius.5ch.net/test/read.cgi/tech/1649979572/

**デフォルトの名無しさん** · 2022/08/16(火) 14:16:34.26

c++ってまだまだ需要あると思いますか？
私はあるかなと思うんですけど...意見ください。

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/16(火) 14:22:21.76

何年も前だがインライン展開の基準を指定する GCC のオプションで
めちゃクソに緩めの数値を指定 (つまりインライン展開されまくる) して
ベンチマークをとった記事が話題になったような覚えがある。

結論を覚えてないし、どこで見たのかも覚えていないので役に立たん話ですまぬ。

**デフォルトの名無しさん** · 2022/08/16(火) 14:48:39.55

>>481
C++は需要が減り衰退していく
昔はともかく現代の視点からは、設計が悪くそこへ建て増しを繰り返しているため、言語として劣っていて使いにくい
そのため次第に既存システムの保守がメインの言語となっていっているが、それさえGoogleの発表したCarbonのような言語の方がプログラマーにとってもありがたい
もちろんそのCarbonでさえそのFAQにこれはあくまでも既存の保守用の言語でと書かれている

**デフォルトの名無しさん** · 2022/08/16(火) 14:52:39.64

設計思想のないバカがさわるとえらいことになる言語だからな

**デフォルトの名無しさん** · 2022/08/16(火) 15:07:03.88

>設計が悪くそこへ建て増しを繰り返している

言語仕様がそうなっていることは認めるが
設計が悪い部分は無理して使わず良い部分だけ使えば良い話でもある

**デフォルトの名無しさん** · 2022/08/16(火) 15:17:41.42

皆が皆そうしてくれないから自然に淘汰されていく訳だが

**デフォルトの名無しさん** · 2022/08/16(火) 15:24:11.24

>>481
需要で言えばCOBOLでさえ無くなっていないからなぁ。

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

個人的にはRustを参考にした初心者向けのサブセットC++か、Rustの複雑さをマイルドにしたスタックフレーム指向の新言語が出てくると思う。

**デフォルトの名無しさん** · 2022/08/16(火) 15:54:40.98

msvcはインライン展開あんましてくれないな

**デフォルトの名無しさん** · 2022/08/16(火) 15:57:43.55

>>487
誰が見てもC++よりRustの方が言語仕様も小さいしシンプルで洗練されていて学習しやすいよ
これは両方を使っている人なら必ず分かるから>>487は知らないものを妄想で語っている？
ちなみにRustはコンパイラによるアドバイスが非常に親切でプログラミング言語の中でもトップクラスな点でもC++との差異が大きいね

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/16(火) 16:21:45.34

どうだろうなぁ。
C を学んでいる人が多かったというところから実務に使いながら少しづつ C++ に習熟していくという動線があったわけで、
C という前提が崩れたら Rust のほうが合理的に設計されていて楽かもしれないとは思う。
ただ、その一方で C++ が消えてなくなるほど劣勢になる気はしないんだよな。

**デフォルトの名無しさん** · 2022/08/16(火) 16:38:57.39

c++とかcやってからじゃないと到底無理
ってよく聞くんですけど
どういうことですかね？

**デフォルトの名無しさん** · 2022/08/16(火) 16:39:15.94

class b:a{};
class a{};
このコードはコンパイルできませんが、aを前方宣言せずにコンパイルを通す方法ってありますかね?

**デフォルトの名無しさん** · 2022/08/16(火) 17:52:12.39

1.
class a;
class b:a{};
class a{};

2.
class a{};
class b:a{};

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/16(火) 17:53:02.94

>>491
個々のルールを頭に詰め込むだけってのはしんどい。
思想に沿うように個々のルールが制定されているので思想が分かればある程度はルールの想像がつく。
低レイヤで何が起こるかある程度は認識していると思想が把握しやすい。

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

ただ、 C++ の「汚くていいんだ」というのもそれはそれで優しい世界なので私は好きだよ。

**デフォルトの名無しさん** · 2022/08/16(火) 19:22:32.37

>>489
初心者からすればC++とRustの差なんて無いに等しい。コード１行書くのにいくつのルールを守る必要があるんだよ。
シンプルで洗練されている言語が初心者に良いというなら、RustよりFORTH(とその末裔)の方が初心者にふさわしいと思うわ。

**デフォルトの名無しさん** · 2022/08/16(火) 21:48:30.73

母国語みたいなもんなんでCの覇権は変わらない

**デフォルトの名無しさん** · 2022/08/16(火) 22:17:19.28

>>495
FORTHはCと同等の速さを出せないし問題のすり替えはみっともない
RustはCと同等の速さを出しつつ現代的なプログラミングしやすい様々なパラダイムを洗練してシンプルにまとめている
FORTHを入れてC/C++/Rustの四者で比較してもRustがプログラミング効率も良いと同意できるだろ

**デフォルトの名無しさん** · 2022/08/17(水) 02:44:27.88

夏厨って夏に湧いて出る厨房の事を指す言葉だったはずだけど
その厨房も今じゃ中年おじさんなんだよな

**デフォルトの名無しさん** · 2022/08/17(水) 04:51:00.22

>>497
Rustは初心者が学習しやすい言語ではないし問題のすり替えはみっともない

**デフォルトの名無しさん** · 2022/08/17(水) 05:49:59.92

>>499
そうかな
C++(スマポ必須で所有権)よりはRustがシンプルではっきりと初心者向けだよ
自動解放で安全が前提でないと困るからその二つが比較対象で合っているよね

**デフォルトの名無しさん** · 2022/08/17(水) 07:00:37.46

皆さんのオブジェクト指向に対する考え方
おください!

**デフォルトの名無しさん** · 2022/08/17(水) 08:26:24.61

>>500
C++との比較なんてしていない。よく読め。
C++が駄目なのと同じくらいRustも初心者の学習コストはダメ。
C++はまだ部分的に汚く使う柔軟性を持つから、better c くらいのところから段階的に使う余地はある。しかしRustはいきなり複数の概念(所有権とか参照とかmoveとか)を使わないとプログラムが書けない絶壁の学習コストをしているから、「とりあえず使う」という選択肢が無い。初心者の選ぶ言語にはならんよ。

**デフォルトの名無しさん** · 2022/08/17(水) 08:34:18.80

>>501
オブジェクト指向のオブジェクトは主体/客体のサブジェクト/オブジェクト。
プログラマー(主体)が操作・命令する対象(客体)をまとめて整理する考え方＆手法がオブジェクト指向。

**デフォルトの名無しさん** · 2022/08/17(水) 08:40:13.74

>>502
C++のスレで「C++と比較していない！」と言い出すそなたの頭のネジが飛んでるとしか

**デフォルトの名無しさん** · 2022/08/17(水) 08:43:38.31

C++のスレでRustの話をする人の頭のネジは緩んではいないのか

**デフォルトの名無しさん** · 2022/08/17(水) 08:50:31.11

他の言語との類似や相違など色んな話題が出てもええんちゃう
特にRustはC++後継言語の一つでもあるし

**デフォルトの名無しさん** · 2022/08/17(水) 08:54:01.88

勝手に決めんな

**デフォルトの名無しさん** · 2022/08/17(水) 09:18:05.65

GAFAMがRustをC++の後継言語の1つとして位置付けてRust Foundationを共同で設立したりしてますもんね
ただしGoogleは既存コードのメンテ用としてはCarbonもC++の後継言語の1つとして実験していますね
Rustはシステム更新時や分離できる新たな部分に対してC++の後継言語となるのでしょう

**デフォルトの名無しさん** · 2022/08/17(水) 09:43:49.92

>>504
C++関連としては>>487。
あとは「Rustは初心者向けじゃないからC++後継できるところまでは行かん」という主張に対する話。C++だって学習障壁から初心者取り込みできずにユーザー規模が縮小しつつあるのに、もっと絶壁のRustが普及するとは思えん。
C++後継としてはRust以外の初心者に配慮した言語が来るんじゃない？

**デフォルトの名無しさん** · 2022/08/17(水) 10:06:28.08

スマポすなわち所有権を使ってるC++プログラマーならRustは簡単で楽勝
まともな案件ならばスマポ使っているし、急にではないけど、より安全なRustへ徐々に少しずつ移っていくんだと思うよ

**デフォルトの名無しさん** · 2022/08/17(水) 10:18:24.59

>>506
それなら類似や相違など語り合うスレのほうがいいのでは？
無いなら立てれば良いし
C++の相談に来ているスレで今はRustだよなんて言われてもね

**デフォルトの名無しさん** · 2022/08/17(水) 10:27:35.49

学習障壁でユーザー規模が縮小って
なんかCOBOL臭えな

アホフィルタを外すより待遇を改善すべきだろ
マ板でやるべき内容だな

**デフォルトの名無しさん** · 2022/08/17(水) 10:30:15.50

rustはアホでも書ける言語ではないよな
良いか悪いかはさておき

**デフォルトの名無しさん** · 2022/08/17(水) 10:41:14.61

は？「C++が使える」アホは俺でも知ってるが
それがこの話と何か関係あるのか？

**デフォルトの名無しさん** · 2022/08/17(水) 10:45:01.06

お前が知ってるかどうかなんか知るかよ
荒らしたいだけなら少し黙ってろ

**デフォルトの名無しさん** · 2022/08/17(水) 11:20:40.84

きみらはなぜ些細なことですぐ喧嘩するのか・・・

**デフォルトの名無しさん** · 2022/08/17(水) 12:01:52.68

>>509
Rust++ですね判ります

**デフォルトの名無しさん** · 2022/08/17(水) 12:03:04.79

都合が悪くなると荒らしたいだけとか全く
C++相談室でRustを連呼するやつに言われたかねえな

**デフォルトの名無しさん** · 2022/08/17(水) 12:06:02.53

相談者はチームで突然、Rustに変えようと言い出せば
解決につながるとでも言うのか
そんな力のあるやつが相談に来るとでも？

**デフォルトの名無しさん** · 2022/08/17(水) 12:31:04.58

シンプルで現代的なZig言語、RustやC++が複雑すぎると嘆く人の福音となるか
https://news.mynavi.jp/techplus/article/programinglanguageoftheworld-44/

**デフォルトの名無しさん** · 2022/08/17(水) 12:50:49.80

手動メモリ管理のZigでは無理だよ
手動メモリ管理で複雑化したときにどうしても発生している穴を防ぐことがどのIT企業でも課題となっている

**デフォルトの名無しさん** · 2022/08/17(水) 13:33:15.30

自動にしてもjavaみたいにメモリバカ食いしてるのも大概だけどな

**デフォルトの名無しさん** · 2022/08/17(水) 13:46:04.27

shared_ptrやunique_ptrで特に問題ないと思うが?
手動メモリ管理ってパフォーマンスでも気にしてるの?

**デフォルトの名無しさん** · 2022/08/17(水) 14:31:54.15

shared_ptrはほんとに良いものなのかちょっと疑問だわ

**デフォルトの名無しさん** · 2022/08/17(水) 15:14:20.93

>>522
それはJavaがGC言語だからしょうがない
非GC言語でプログラマーによるコードに依存せず自動メモリ解放して欲しいならば現状Rustしかない

**デフォルトの名無しさん** · 2022/08/17(水) 15:36:27.49

shared_ptrやunique_ptrで何か問題があるかな?

**デフォルトの名無しさん** · 2022/08/17(水) 15:37:16.76

いらんわ
まさかそんなくだらん話だったとは
買い被らせやがって

**デフォルトの名無しさん** · 2022/08/17(水) 15:53:30.62

>>523
正確にはスタックフレームに積む or スマートポインタを使ってヒープに置く、だな。

shared ptrは関数呼び出し時の値渡しのインクリメントデクリメントコストが気になるところ。
スタックフレームに存在するかどうかで参照渡しか値渡しかを自動で切り替えると便利そうだけど、最適化で上手く処理してくれたっけ？

**デフォルトの名無しさん** · 2022/08/17(水) 15:54:04.11

>>526
使い忘れと使い方ミスを常に完全にゼロにできるならばunique_ptrとshared_ptrでOK
しかし複雑化した時にミスを常にゼロにすることは不可能だと判明している

一方でC++からRustにすると以下のようなメリットが山のようにある
・Rustでは使い忘れや使い方ミスをするとコンパイラが必ず指摘してエラーとしてくれる
・Rustでは何も指定しない標準状態でC++のunique_ptrより高機能であるため記述がスッキリそして分かりやすい
・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるがRustではそのコストを必要としない
などなど

**デフォルトの名無しさん** · 2022/08/17(水) 16:16:02.25

殺虫剤のパラドックスてやつ

**デフォルトの名無しさん** · 2022/08/17(水) 16:31:22.99

こんなとこで Rustの宣伝されてもな・・・

**デフォルトの名無しさん** · 2022/08/17(水) 17:56:04.99

この手の議論って「全てのプログラマがポインタを直に操作する必要に迫られている」という詭弁に基いていて辟易するんだよな

**デフォルトの名無しさん** · 2022/08/17(水) 18:05:51.06

RustなんかやめてDelphiにしようぜ

**デフォルトの名無しさん** · 2022/08/17(水) 18:34:02.81

最近ポインタ使わんよね

**デフォルトの名無しさん** · 2022/08/17(水) 18:40:18.95

>>532
ある程度の大きなデータは抽象的な意味でcall by reference (pointer) により受け渡しすることになり実装的にはポインタを使わざるをえない気もする

**デフォルトの名無しさん** · 2022/08/17(水) 19:39:41.85

>>529
Rustの変数をunique ptrと比較している時点でRustの利点を理解出来ていない。
Rustの変数に対応するのはあくまで自動変数で、unique ptr に対応するのはBox<T>。

Rustは「高速化と自動化のためにできるだけスタックフレームを活用する」という基本的な考え方があって、そのためにあの窮屈なルールで自動変数を高機能化している。
Rustの変数がデフォルトムーブだからといって、Rustの変数はunique ptr みたいなものとするのは理解の足りない粗忽者のやることだわ。

**デフォルトの名無しさん** · 2022/08/17(水) 19:59:51.79

>>536
ある意味それも正しいが現実問題じゃないな
例えばi32を10個返す関数を作るとして
その型を[i32; 10]、Box<[i32; 10]>、Vec<i32>のそれぞれにした場合に生成コードはどうなりどれを選ぶべきか考えるとBoxの意義がなああ
結局Rustではもっと最適なものを選ぶからunique_ptr相当すら使うことがレアだよな

**デフォルトの名無しさん** · 2022/08/17(水) 20:32:26.88

>>491
C++ちょっと分かったなーって気持ちになれるまでの遠い道のりを考えると、Cができるなんて入口にすら立ってない感じ。
だからC知ってたくらいではアドバンテージないよ。個人の感想です。

**デフォルトの名無しさん** · 2022/08/17(水) 21:07:14.75

>>529
>・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるが
>Rustではそのコストを必要としない
本当にコストは必要ないのかな?
本当に参照カウントしないのかな?

**デフォルトの名無しさん** · 2022/08/17(水) 21:11:48.18

>>536
unique_ptrはmemory allocationとは全く関係ありません

**デフォルトの名無しさん** · 2022/08/17(水) 21:31:24.12

unique_ptrなんて自動変数と変わらんじゃろ

**デフォルトの名無しさん** · 2022/08/17(水) 21:37:14.43

>>539
Rustは借用(とライフタイム)があるから、
複数の参照が同時に必要となっても、
所有者は一人のまま何も変わらず、
複数の借用を普通に使うだけで済んでしまい、
付加コストの発生は無し。

一方でC++は、
複数の参照が同時に必要となる場合、
unique_ptrではもちろんダメなので、
shared_ptrを使わざるを得ず、
参照カウンタ増減という付加コストが発生。

**デフォルトの名無しさん** · 2022/08/17(水) 21:39:05.15

>>540
デフォルトはヒープを想定しているだろ。
Rustの変数はデフォルトスタックを想定している。

**デフォルトの名無しさん** · 2022/08/17(水) 21:40:11.05

そんなん設計でどうにでもなる
ありきたりの道具使ってばっかいるからアタマが退化してんだろ

**デフォルトの名無しさん** · 2022/08/17(水) 21:41:54.05

>shared_ptrを使わざるを得ず
おまえがそう決め付けているだけで、ここら辺は設計でどうにでもなる

**デフォルトの名無しさん** · 2022/08/17(水) 21:46:20.33

>>545
unique_ptrはコピーできないから複数の参照を用意できない
shared_ptrを使うことになる

**デフォルトの名無しさん** · 2022/08/17(水) 21:51:11.86

同じクラスが重複して定義されたとき、
そのクラスに変数が定義されていてもコンパイルエラーにならないのはなぜですか？
関数が定義されている場合、インライン展開されないとコンパイルエラーになると思います
変数にはそのような指定が無いと思いますが、なぜエラーにならないのでしょうか？

**デフォルトの名無しさん** · 2022/08/17(水) 22:07:13.27

言っている意味がちょっとわからないので最小のコードを提示してもらえるとありがたい

**デフォルトの名無しさん** · 2022/08/17(水) 22:09:46.76

単純に、同じクラスを（同じ定義で）二回定義してもエラーにならんの
便利なようで不思議だよな

**デフォルトの名無しさん** · 2022/08/17(水) 22:10:56.50

>>542 「複数の参照」が借用で済むようなものなら C++ でも T& でコスト要らなくね？

**デフォルトの名無しさん** · 2022/08/17(水) 22:12:24.01

大抵インクルードガードで１回しか通らないようにしてたけど
（クラス定義だけなら）インクルードガードなしで二重に読んでも通るってことなのか…　それはしらんかった

**デフォルトの名無しさん** · 2022/08/17(水) 22:14:06.17

スレタイ読めや
だからRust信者は嫌なんだよ

**デフォルトの名無しさん** · 2022/08/17(水) 22:17:02.42

>>550
それはダングリングポインタになりうるからダメ
C++には借用とライフタイムの概念がないため先に解放されてしまう事態を避けられない

**デフォルトの名無しさん** · 2022/08/17(水) 22:35:58.47

以下のコードをヘッダに記述して複数のソースでインクルードすると、
関数fooは重複定義でコンパイルエラーになります
inline指定にすると、コンパイルは通るようになります

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

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

このとき変数iは何故重複定義にならないのでしょうか？
fooと同様に複数のソースで重複定義になる気がするのですが

**デフォルトの名無しさん** · 2022/08/17(水) 23:24:22.15

>>542
コンパイル時に参照数が決まらない場合は参照カウントしてるやろ?
コンパイル時に決まるよう状況ならC++でもT&で十分

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/17(水) 23:28:24.67

>>554
int i; はメンバ宣言に該当するがそれ自体は定義ではない。
クラス定義の中にメンバ宣言があるってのがようわからん理屈だがその時点では実体が作られない、
逆に言えばその型のオブジェクトを生成するときになって初めて実体が作られるので
この段階では重複として排除する必要がない。

**デフォルトの名無しさん** · 2022/08/17(水) 23:31:25.13

>>553
参照を渡した先でどこかに参照を格納・保持して後で使う必要があるなら shared_ptr で
渡すのがいい状況になりそうだけど、その場合は Rust でも借用では済まないのでは？

**デフォルトの名無しさん** · 2022/08/17(水) 23:51:08.75

>>556
ありがとうございます
グローバルスコープに定義するときは、
int i;
この記述で定義になるので、複数のソースでインクルードすると当然重複定義になります
クラス内では宣言のみになるとは思いませんでした
そういうものと覚えるしかなさそうですね

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/18(木) 00:07:40.00

>>553
C++ にもライフタイムの概念はあるよ。
コンパイラが検査してくれないってだけ。
ダングリング参照を作ってはいけないというルールは C++ でも Rust でも同じ。

**デフォルトの名無しさん** · 2022/08/18(木) 02:53:41.59

>>555
スマポを使っている限りは安全だと客観的にも保証されるけど
そこでT&を使ったら自己責任の世界に戻ってしまい意味なしとなってしまう

**デフォルトの名無しさん** · 2022/08/18(木) 04:29:06.72

>>559
決定的な違い
Rustではダングリング参照するプログラムを絶対に作れない（コンパイラがエラーとする）
C++ではダングリング参照するプログラムがうっかり容易く生じてしまう（そしてコンパイラが通してしまう）

**デフォルトの名無しさん** · 2022/08/18(木) 04:53:19.13

>>561
話変わってるだろ
検査してくれるかどうかじゃなくて
> ・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるがRustではそのコストを必要としない
の話だったと思うが？

**デフォルトの名無しさん** · 2022/08/18(木) 05:23:06.33

>>562
それはC++で安全を保証しようとすると
複数の参照を用いるならば常にshared_ptrの使用を必須とするしか安全を保証できないのに対して
Rustは複数の参照だけなら借用のみで安全を保証できるという話ではないか

ちなみにRustでは複数の参照ではなくもっとレアケースである複数の所有が生じた時に初めてコンパイラがRcを要求する
つまりRustでは参照と所有が明白に分離されているところが大きな違いとなる

**デフォルトの名無しさん** · 2022/08/18(木) 05:36:06.77

>>563
安全の保証をコンパイラがやるのかプログラマーがやるのかの違いなんて議論してないよ

**デフォルトの名無しさん** · 2022/08/18(木) 07:06:14.45

C++11以降のマナーでは、ダングリングは発生しない。
設計を見直すべきでは？

旧い規格、例えばDOMを実装する場合、設計を見直すことはできない。
ところで、DOMについて、C++によるGoogle Chromeの実装は素晴らしい洞察で問題を回避している。
後学のために読んでみるとよい。

**デフォルトの名無しさん** · 2022/08/18(木) 07:10:02.07

如何にして安全なスパゲッティ・コードを書くかというのがRustのアプローチなら。
C++の方法論は、「安全なスパゲッティなど存在しない、素麺にしましょう」ということ。
旧式のスパゲッティ・コードを書きたい人にとってC++は役に立たない。

**デフォルトの名無しさん** · 2022/08/18(木) 08:09:28.79

まぁ、c++でももっと積極的にスタックフレームに限定するアプローチは欲しいよね。

以前にインスタンスがスタックフレームに存在することを保証するスマート変数を作ろうとしたけど、インスタンス変数をどうしても制限できなくて挫折したことがある。
スマートポインタが必ずスタックにあるのなら、スマートポインタの参照渡しとかもっと活用できるのにね。

**デフォルトの名無しさん** · 2022/08/18(木) 09:11:59.95

スタックかどうかなんてどうでもよくねえ？
機能の問題でしょ？

**デフォルトの名無しさん** · 2022/08/18(木) 09:19:43.25

>>567
> 以前にインスタンスがスタックフレームに存在することを保証するスマート変数
それなんの意味があるんだ？
てかC++ならスタック上にインスタンス生成すればよくね？

**デフォルトの名無しさん** · 2022/08/18(木) 09:41:11.96

自動変数が嫌いな人一定数いるよね

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/18(木) 10:26:05.65

大抵の環境でデフォルトのスタックサイズはそれほど大きくない。
数メガバイトというのは現代的な感覚では極端に小さいようにも見える。

でもまあだいたいこれで足りるし、足りるように書くのが普通なんじゃないの。

**デフォルトの名無しさん** · 2022/08/18(木) 11:28:19.94

C > Nim > C++ > Rust

**デフォルトの名無しさん** · 2022/08/18(木) 11:29:37.71

>>569
GC要らなくなる

**デフォルトの名無しさん** · 2022/08/18(木) 11:47:13.53

>>571
スタックオーバーフローしたら Linux/Unix は自動拡張しなかったっけ？
Windows はなぜか（オプションで可変出来るけどスレッド起動後は）固定なんだよね

**デフォルトの名無しさん** · 2022/08/18(木) 11:47:44.39

>>573
そりゃ全部スタック上で済むならね...

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/18(木) 12:03:37.12

>>574
割り当てが足りなくなれば拡張するが、その上限の設定がデフォルトでは 8MB になっている。

**デフォルトの名無しさん** · 2022/08/18(木) 12:29:58.75

>>569
単にスタックフレームの入れ子のライフタイムを活用したいだけだな。

**デフォルトの名無しさん** · 2022/08/18(木) 12:35:06.23

ポインタたくさん使う人っておじさんですよね？
実年齢か精神年齢かはともかく

**デフォルトの名無しさん** · 2022/08/18(木) 12:37:54.86

>>577
ちょっと補足。
スマートポインタがスタックにあるのなら、shared ptr の参照とかポインタみたいなヤバイのもそこそこ安全に扱える。余計なインクリメントデクリメントも発生しなくて良くなるし。

**デフォルトの名無しさん** · 2022/08/18(木) 12:41:39.14

なんでスタックである必要があるのかまったくわからん

**デフォルトの名無しさん** · 2022/08/18(木) 13:27:16.43

>>578
おまえさん、いくつなんだ？
工房や厨房までがおじさんに見えるなんて

**デフォルトの名無しさん** · 2022/08/18(木) 13:29:45.98

>>563
つまりコンパイル時に参照数が決まらない場合はRustも参照カウントする

>>529
>・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるが
> Rustではそのコストを必要としない
従ってこれは間違っている

**デフォルトの名無しさん** · 2022/08/18(木) 13:34:11.90

>>579
一見その通りだけど
関数で参照を返したい時に、その実体が呼び出し元(かそれ以前)のスタックフレーム上なのか、
それとも消え去る現在のスタック上なのか、安全を保証するために区別する情報が必要となる

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

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

以上を言語仕様に組み込んだのがRust

**デフォルトの名無しさん** · 2022/08/18(木) 13:54:28.67

>>583
c++も割と明確では
使いやすさはさておき

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/18(木) 14:09:16.33

私もそう思う。 C++ でも明確で、解釈の余地はほぼない。
その上で知ってても人は間違うというところは問題で、チェックを自動化できるように整理したという Rust の功績は大きくはある。
ルール自体の差は C++ と Rust でそれほど大きくはない。

**デフォルトの名無しさん** · 2022/08/18(木) 14:18:54.74

C++のライフタイムはプログラマーにとっては明確でもコンパイラにとっては明確でない
そのためC++では参照の安全性をコンパイラが保証することができない
そして複雑化した時に人間(プログラマー)はミスを無くすことが出来ない
そのためC++で書かれた多くのソフトウェアで常に穴が発生し続けている

**デフォルトの名無しさん** · 2022/08/18(木) 15:34:56.12

unique_ptrやshared_ptrを使えば良いだけではないかな?

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/18(木) 16:15:40.31

>>587
C++ のスマートポインタはやっぱり後付け感はある。
Teratail とかの質問サイトを見てたら (コンパイル時にエラーに出来ない形で) 使い方を間違ってセグフォしてたりするのはちょくちょく有る。
コンパイラがガッツリと検査してくれる Rust はありがたいよ。

**デフォルトの名無しさん** · 2022/08/18(木) 16:20:56.69

無能な働き者の軌道修正には良いかもな

**デフォルトの名無しさん** · 2022/08/18(木) 16:27:29.27

桐蔭トリプルプレーだよ

**デフォルトの名無しさん** · 2022/08/18(木) 16:37:31.46

たまにはweak_ptrのことも思い出して下さい

**デフォルトの名無しさん** · 2022/08/18(木) 16:59:01.63

>>587
unique_ptrやshared_ptrの使い忘れや使い方ミスなどをしてもコンパイラはエラーとすることができないためC++は安全性を保証できない
他にもget()して得たポインタを関数などに渡した後にそのライフタイムを逸脱しないかなどの保証もできない
全ては人間頼みとなるため多数の穴が生じてきた

**デフォルトの名無しさん** · 2022/08/18(木) 19:33:28.16

性能厨としては何でもスタックフレームに置いて集積度を高くしたいところ。レジスタの効率とかキャッシュヒット率とか変わるだろうし。

Rustのスタックへのこだわりはいいんだけど、無駄に抽象化しているから余計に複雑になっている感じを受ける。

**デフォルトの名無しさん** · 2022/08/18(木) 21:49:54.60

C++のスマポは言語機能じゃないから書き方長くてだるいし
外部ライブラリは当然ナマポ使ってるから結局その辺でセグフォの危険を排除できないし
オウムみたいにスマポでいいじゃん連呼してるやつは本当に使ったことあんのか？

**デフォルトの名無しさん** · 2022/08/18(木) 21:58:35.30

>>592
使えば?と私は提案してるので「使い忘れ」は論外として
「使い方ミス」はどんなミスでしょうか?
ミスのしようがないほど単純だと思います

Rustのコンパイル時にチェックしようという設計は
もちろん良いと思いますよ

**デフォルトの名無しさん** · 2022/08/18(木) 22:02:08.08

>>594
ええ
私は最近はメモリ管理で全く失敗ないですね
デバッガの出番がないです

**デフォルトの名無しさん** · 2022/08/18(木) 22:07:53.92

スマポにハンドルを突っ込む方法はないですかねえ‥‥

**デフォルトの名無しさん** · 2022/08/18(木) 22:12:02.34

>>596
君のような勘違い自信過剰な人がうっかりミスを起こして問題を引き起こしてきた
チェックを人間に依存している限りミスは必ず発生する

ソース記事
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と

**デフォルトの名無しさん** · 2022/08/18(木) 22:16:42.90

使われないシステムってバグ出ないんだよね

**デフォルトの名無しさん** · 2022/08/18(木) 22:17:29.31

>>598
> >>596
> 君のような勘違い自信過剰な人がうっかりミスを起こして問題を引き起こしてきた
私は最近はメモリ管理で全く失敗がないので私とは違うな

**デフォルトの名無しさん** · 2022/08/18(木) 22:21:49.94

>>598
$ wget 'https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.1.tar.xz'
$ tar xJf linux-5.19.1.tar.xz
$ find linux-5.19.1 -name *.rs | wc -l
0
2021年4月30日の記事だけどまだコミットがないようだが?
Rustのsuffixってひょっとしてrsじゃない?

**デフォルトの名無しさん** · 2022/08/18(木) 22:29:53.88

>>600
それは貴方がアホだからミスに気付いていない可能性、使われないからバグが未発見なだけの可能性、単純なことしかしていないだけの可能性、…
複雑化すると、どんなにベテランでも、多数の人々がコードをチェックしていても、メモリ管理ミスが現実に起きている現実を受け入れましょ

**デフォルトの名無しさん** · 2022/08/18(木) 22:43:58.49

>>602
俺が>>600で述べたのは俺のことのみだよ

**デフォルトの名無しさん** · 2022/08/18(木) 22:54:56.26

誰もお前なんかに興味無い訳だが

**デフォルトの名無しさん** · 2022/08/18(木) 23:09:02.07

>>604
ごめんごめん
>>598がいちいち私を引き合いに出してきたので否定したまでだよ
>>598の書き込みも冒頭の「君のような」を書かなければ
良いのに何でいちいち書くのかね?

**デフォルトの名無しさん** · 2022/08/18(木) 23:31:07.48

どんな複雑なケースでも一度もミスをしたことがない！今後も絶対にミスをしない！
と言ってる人を信頼できるわけがない

**デフォルトの名無しさん** · 2022/08/18(木) 23:38:25.32

>>606
>一度もミスをしたことがない！今後も絶対にミスをしない！
そんなことは一言もいっとらんがなw

**デフォルトの名無しさん** · 2022/08/18(木) 23:42:25.87

本当にunique_ptrやshared_ptrでミスするかい?
信じられないほど単純なクラスだと思うけど
>>592の「使い方ミス」って何なの?

getで中身取り出して云々は割とあり得るんだろーけど
それはunique_ptrやshared_ptrの外の出来事だし

**デフォルトの名無しさん** · 2022/08/18(木) 23:58:49.20

もちろんgetを使った時点でスマポ管轄外となり保証が全く無くなるが
スマポ自体における使い忘れや使い間違いなども色々とあるぜ
例えば

C++11スマートポインタで避けるべき過ち Top10
https://postd.cc/top-10-dumb-mistakes-avoid-c-11-smart-pointers/

**デフォルトの名無しさん** · 2022/08/19(金) 00:27:49.36

>>609
有難う！読んでみたよ！過ちを列挙すると以下の通り
>過ちその1： uniqueptrで十分なところにsharedptrを使う
>過ちその2： shared_ptrで共有されたリソース/オブジェクトをスレッドセーフにしない
>過ちその3：自動ポインタ（auto_ptr）を使う
>過ちその4： sharedptrの初期化にmakesharedを使わない
>過ちその5：オブジェクト（生ポインタ）を作成してすぐにshared_ptrに割り当てない
>過ちその6： shared_ptrで使用されている生ポインタを削除してしまう
>過ちその7：ポインタの配列にshared_ptrを使用する際にカスタムデリータを使用しない
>過ちその8：共有ポインタを使用する時に循環参照を回避しない
>過ちその9： unique_ptr.release()で返された生ポインタを削除しない
>過ちその10： weak_ptr.lock()を呼び出す際に、有効か否かを確認しない

俺については4はmake_sharedを知らなかった時期にはやってたけど知ってからはないね
3はunique_ptrがstdに入って全部リプレースした
あとは過去にも犯さず使用しできてるよ
みんなはどうだい?

**デフォルトの名無しさん** · 2022/08/19(金) 00:34:39.73

getを使ってしまったらthe endなわけだけど
getの使用を皆無で頑張ってるん？

**デフォルトの名無しさん** · 2022/08/19(金) 00:47:36.81

>>611
外部ライブラリの関数呼ぶのにget使うけど
意味するところを理解しているので
慎重になるから失敗した覚えはないなぁ

当たり前だけど自分の書く関数の引数に生ポインタを使うことはない

**デフォルトの名無しさん** · 2022/08/19(金) 01:36:44.63

>>612
ところで複数の関数呼び出しそれぞれに参照を渡したい時はどうしてる？
生ポインタ使わないからshared_ptr？

**デフォルトの名無しさん** · 2022/08/19(金) 01:38:01.85

なんでポインタ使うんですか？

**デフォルトの名無しさん** · 2022/08/19(金) 02:09:43.59

>>613
その書いている「参照」ってのはC++の参照ではないですよね?

関数にT型のオブジェクトを引数として渡すとき
関数がシーケンシャルに実行されるなら原則としてT &で渡す
中身が無効値である可能性があるならunique_ptr <T> &で渡す
関数が並行に実行されるならshared_ptr <T>を渡す

**デフォルトの名無しさん** · 2022/08/19(金) 03:25:13.02

T&渡した時にそれが他へ転用され保持されて生き残り続ける可能性を考慮しないの？

**デフォルトの名無しさん** · 2022/08/19(金) 05:39:15.80

静的試験を絶対視するなーんにも分かっとらんやつが推すほどイメージが悪くなるな

**デフォルトの名無しさん** · 2022/08/19(金) 07:27:50.77

>>616
だからポインタ使うの？
まあ寿命の長いオブジェクトを駆使しないほうがかっこいいのでは

**デフォルトの名無しさん** · 2022/08/19(金) 08:01:50.73

>>617
動的チェックは不便だし重くて遅いよ
できる限り何でも静的にするのがベター

**デフォルトの名無しさん** · 2022/08/19(金) 08:25:03.05

>>616
は? 詳しく

**デフォルトの名無しさん** · 2022/08/19(金) 08:45:24.08

>>597
constructor destructor関数オブジェクトを用意すれば良かったんじゃなかったっけ？smart ptrの典型的な応用例だから、調べりゃすぐ出てくるよ。

**デフォルトの名無しさん** · 2022/08/19(金) 08:56:07.71

>>619
ふーんチェックなのかpgr

**デフォルトの名無しさん** · 2022/08/19(金) 10:22:48.97

>>617
俺も以前はそう思っていたんだけど
わずかな補助情報を人間が与えるだけで
Rustコンパイラが静的試験してくれて
人間にとって面倒かつ慎重さを必要とする作業から解放してくれるのを知って考えが変わった

例えて言うなら
動的型付け言語を使っていたところを
わずかな型情報を人間が与えるだけで
静的型付け言語のコンパイラが静的試験をしてくれるようになったのと似てる

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/19(金) 11:08:02.29

昔とはソフトウェアの規模感が違う。
そしてプログラミングするのがプログラミングの専門化とは限らない領域が増えた。
(いわゆるエンドユーザー・コンピューティング)

職業的なプログラマにしてもプログラミングの専門化というよりは
別分野のそれぞれの専門化が道具としてのプログラムを作るというような場合も多い。
プログラミングのルールや作法を行きわたらせることは出来ないよ。
検査を強くするのは時代的な背景としても自然に思える。

動的な検査でも静的な検査でもいいが、
C/C++ は検査せずに未定義に突入するのがあまりにも簡単すぎる。

**デフォルトの名無しさん** · 2022/08/19(金) 11:09:58.15

>>623
ナマポひとつロクに扱いきれないスキルと
動的チェックなんて恥ずかしげもなく言っちゃう
バカ用言語があんたにとって有難いのは分かったよ

ここはC++相談室
C++という土俵に立っている者の場だ
落ちこぼれて逃げ出したやつの遠吠えは
誰も聞きたがってない
どっか行け、邪魔なんだよ

**デフォルトの名無しさん** · 2022/08/19(金) 11:17:41.46

自分のミスを道具のせいにするやつ
そういえば法案のミスをワープロのせいにするバカ役人がいたな

こういう手合いは一事が万事

**デフォルトの名無しさん** · 2022/08/19(金) 11:44:22.83

>>616が何を言いたいのか今もって分からない
悩む

**デフォルトの名無しさん** · 2022/08/19(金) 11:53:43.76

一般用語の参照を使ってると思われるあたり
この人（>>613）はC++の参照を知らないレベルだと思うんだよね
C++に関してはほぼ知識がないまま
受け売りでRustが生ポインタを廃止?した利点を主張している
（私もRustのコードは書いたことがないんだけども）
この人は何がしたいんだろうか?

**デフォルトの名無しさん** · 2022/08/19(金) 11:59:22.84

OSのAPIなりその他雑多なライブラリなりでポインタ要るからなあ・・・

**デフォルトの名無しさん** · 2022/08/19(金) 12:19:36.97

動的型付け・・・あー、もしかして動的型宣言のことかな？
だとすると具体的に何言語のことを言ってるんだろう？
Bにはそんなもんないし・・・

**デフォルトの名無しさん** · 2022/08/19(金) 12:44:26.95

昔構造体を値で渡したらポインタにしろっておっさんに怒られたっけ
速度を気にしないんだったらコピーでええのに糞めんどくさかったわ

**デフォルトの名無しさん** · 2022/08/19(金) 12:47:51.92

馬鹿が二人ほど恥を晒しております

**デフォルトの名無しさん** · 2022/08/19(金) 12:51:04.37

>>630
動的型付けを知らないとは素人かね？
動的型宣言という言葉は存在しないぞ

**デフォルトの名無しさん** · 2022/08/19(金) 13:06:02.28

>>633
それwikipediaソースだろpgr
で、あんたdynamic type declarationのことを言ってたの？
それとも他の何かか？ Bにあったものか？

**デフォルトの名無しさん** · 2022/08/19(金) 13:47:12.04

>>634
あまりにも無知すぎて話にならないな
wikipediaでも何でもいいから勉強して出直して来い
動的な型と動的型付けの区別は最低限つけろ
静的型付け言語の中には動的な型と呼ぶものもあるが
静的型付けと動的型付けは基本的に排反の関係だ

**デフォルトの名無しさん** · 2022/08/19(金) 13:54:09.00

>>616が何を言いたいのか今もって分からない
悩む

**デフォルトの名無しさん** · 2022/08/19(金) 14:06:18.12

その一文がわからないようなレベルの奴がメモリ管理で全く失敗ないとか言ってんだもん
みんな呆れてんだよ

**デフォルトの名無しさん** · 2022/08/19(金) 14:08:38.12

>>637
本当に質問の意味が分からんから説明してよ
意味が分かったら返答するからさ

**デフォルトの名無しさん** · 2022/08/19(金) 14:09:02.63

>>635
俺は動的な型と動的型宣言を混同していることを露呈するような失言はしてないぞ
していると言うなら具体的にどこなのかを示せ
誤魔化しても構わんがそれも返事と取るからな

**デフォルトの名無しさん** · 2022/08/19(金) 14:28:41.00

>>628にも書いたけどC++相談室で一般用語の「参照」は
C++の参照と混同するので普通は避けるんだよね
C++で書いた経験が皆無なんだなと俺は判断している
それで>>616のような意味を計りかねる質問をしてしまう

**デフォルトの名無しさん** · 2022/08/19(金) 14:40:23.82

>>639
そこまで恥を再び晒したいなら示す

>>630
> 動的型付け・・・あー、もしかして動的型宣言のことかな？

まず動的型宣言という用語は存在しない
"動的型付け" はググると7万件あり
"動的型宣言" はググると3件である

一般的に動的な型の宣言の話と広く解釈したとしても
動的な型の宣言と動的型付けは異なり互いに包含関係などもない
動的な型の宣言は静的型付け言語においても持つものがある
そして動的型付けは静的型付けの逆であり相反する

**デフォルトの名無しさん** · 2022/08/19(金) 16:45:49.60

>>637
説明が難しいなら簡単なコードでも良いよ
何を懸念しているのかそれで推察できると思うから

**デフォルトの名無しさん** · 2022/08/19(金) 17:07:32.80

栄光在天
聖恩心から感謝申し上げます。
日ごろは激しい摂理の中、プログラム業ごくろうさまです。
さて、C++のコピーコンストラクタおよび代入演算子オーバーロードの質問でございますが、メンバ変数全てを関数定義内部で書き出すととてつもない量になってしまいます。

class Hoge
{
Hoge& Operator =(const Hoge&r);
int hage=0;
char sage=0;
std::unique-ptr<Hagehage> pHagehage;
etc…
Etc…
Eat…
};
Hoge& Hoge::operator=(const Hoge&r)
{
hage=r.hage;
sage=r.sage;
pHagehage=std::make-unique<Hagehage>(r);
Etc etc……
}
メンバにユニークポインタがあるので書き出さないとダメな感じになっちゃうのですが……量がががが(>_<)
これらにおいて、何か楽になるような裏技はありますか？
それとも一つづつ足していかなければならないのでしょうか？
もしかしたらコンパイラやIEDの部門で行うべき変な質問かなとも思いますが……何かやり方やティップがありましたら教えていただければ……
相対的に有田退治にもなります！

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/19(金) 17:19:48.26

>>643
メンバを

Hoge& Operator=(const Hoge&r)=default;

というように宣言すればデフォルトの定義が実装される。
全てのメンバに対して代入演算子を適用したのと同じことになる。
(もちろん全てのメンバを代入するという挙動で駄目な場合は自分で書くしかしょうがない。)

**デフォルトの名無しさん** · 2022/08/19(金) 17:31:34.37

>>641
そのレスには動的な型についての言及がないな
誤魔化したいわけね、返事ありがとう

動的型宣言という言葉は存在しないと言いながら
動的型付けとは【意味が違う】とはどういうことだ？
存在しないものは比較できないはずだぞ
operator<=>でSFINAEだなpgr

**デフォルトの名無しさん** · 2022/08/19(金) 17:35:12.15

>>624-629には沈黙か
大草原

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/19(金) 17:39:10.42

>>643
そもそも代入演算子は特に指定しなくても定義されるはずだな。
(ただし基底とメンバの全てが代入可能であるとき。)

class foo {
public:
int x, y, z;
foo(int x, int y, int z) : x(x), y(y), z(z) {}
foo(void) : x(0), y(0), z(0) {}
};

int main(void) {
foo x(1, 2, 3), y;
y=x; // 代入できる
}

**デフォルトの名無しさん** · 2022/08/19(金) 19:46:49.43

>>645
おかしな人みたいだからこれ以上は相手にするのやめとく
動的型付けを知らなくて間違えたことは仕方ないとしても
それを指摘された後の逆ギレはみっともないから治したほうがいいよ

**デフォルトの名無しさん** · 2022/08/19(金) 19:50:44.27

>>648
勝ったーwww

**デフォルトの名無しさん** · 2022/08/19(金) 19:52:29.50

>>648
負けちゃったね・・・(´・ω・｀)