23/03/06 23:56:33.22 h8dbx3na.net
>>169
数字でも物理でも定数は静的に定まるものだよ
でもC++はconstをimmutableの意味で間違えて名付けてしまいました
そして定数を表すためにconstを使えなくなりconstexprと名付けたという誰でも知ってる有名な話だよ
176:デフォルトの名無しさん
23/03/07 00:01:46.05 gZ1LpnCS.net
>>175
>でもC++はconstをimmutableの意味で間違えて名付けてしまいました
とあなたが思っているだけではないかな?
C++のconstにあなたなが「間違えて」静的に定まるものを期待しているだけでは?
177:デフォルトの名無しさん
23/03/07 00:09:47.95 6eBCzRN0.net
言われてみれば数字や物理で定数は静的に定まる値だな
どうせC++で静的に定まる値を示すキーワードも必要となるんだから素直にそれをconstにしておくべきだったか
設計ミスだな
178:デフォルトの名無しさん
23/03/07 00:57:00.01 UNnBBHt0.net
>>175 >>177の頭が設計ミス
179:デフォルトの名無しさん
23/03/07 01:08:45.38 gZ1LpnCS.net
>>177
>言われてみれば
www
180:デフォルトの名無しさん
23/03/07 01:27:52.75 phr7A4jU.net
immutableとconstantの違いを区別できていない人がimmutableに対してconstと命名してしまったのかな
そのためconstantに対してconstと命名できなくなってconstexprと命名したと
181:デフォルトの名無しさん
23/03/07 01:31:47.04 CjRtBzJ1.net
同じ言葉や字句でも言語ごとにその概念が指すものは異なる
相対主義的に考えなさい
相手の価値観を理解しなければ説得力は生まれません
182:デフォルトの名無しさん
23/03/07 02:21:18.68 oSHTm7sl.net
・y = ax (a=10である)
aをimmutableと呼ぶかconstantと呼ぶか
・y=f(a) (a=10である)
f(a)をconstantと呼ぶかconstant expressionと呼ぶか
まあ考え方次第だよな
183:デフォルトの名無しさん
23/03/07 02:29:20.82 phr7A4jU.net
>>182
上はxが実行時に値がわかる変数なんでしょ？
それならconstantには成りえないんじゃない？
184:デフォルトの名無しさん
23/03/07 08:05:58.19 oSHTm7sl.net
>>183
かかるaについてなんと呼ぶかって話だから別にxについて気にする必要は無いよ
185:デフォルトの名無しさん
23/03/07 08:10:06.41 X5urLXgj.net
>>182
理解できていなさ過ぎだろｗ
186:デフォルトの名無しさん
23/03/07 08:16:15.53 X5urLXgj.net
>>182
あと例を出すにしても
整数は特殊でconstexprでなくconstでも静的定数になる例外だから例として最も不適切
187:デフォルトの名無しさん
23/03/07 09:21:06.13 hj+ftEk+.net
自演してRustゴリ推し他言語叩きをしてるのは
複製おじさんと呼ばれてるRustスレでは有名な荒らし
しかもそいつが「RustJP公式 」の中の人で間違いなさそうって話だから手に負えない
188:デフォルトの名無しさん
23/03/07 10:27:35.30 QCj9HjAv.net
>>187
「RustJP自称公式 」なのでなんの問題もない
189:デフォルトの名無しさん
23/03/07 11:40:31.33 gZ1LpnCS.net
>>180
それはお前用語なんじゃね?
190:デフォルトの名無しさん
23/03/07 11:55:27.75 CdvGJ9oA.net
y = ax
y も a も x も変数としか言いようがない
191:デフォルトの名無しさん
23/03/07 12:47:12.28 CHI/c7S+.net
aを10としたときにコンパイル時
最適化してしまうかaという入れ物残しとくか更にはf(a)も計算して結果だけ使うか
192:デフォルトの名無しさん
23/03/07 21:59:54.08 6AJw5hNk.net
整数はconstやconstexprの有無に関係なくコンパイル時に最適化されるから整数を持ち出して来ても意味がない
C++ならクラスのインスタンスを生成する場合などを考えるとわかりやすい
コンパイル時点でそのインスタンスを定数化できる時にconstexprを使い静的に定数となる
そうでなく実行時にならないと値が定まらない変数となる時はconstexprを使えない
その変数がimmutableつまり生成以降は値を変更できない時はconstを使う
193:182
23/03/07 22:28:59.56 oSHTm7sl.net
constというものの表現を語るうえで言語依存しない形で書いただけなので
少数でも文字列でも適当に読み替えてね
194:デフォルトの名無しさん
23/03/08 00:26:55.95 Ax/TB2dR.net
>>192
C++の命名ミスだな
定数にconstと命名すべきであり
immutableな変数にconstと命名すべきでなかった
195:デフォルトの名無しさん
23/03/08 00:36:06.87 o1WhyvRq.net
壊れたテープレコーダは生まれてくるべきでなかった
196:デフォルトの名無しさん
23/03/08 00:46:11.75 +ZMcnEdg.net
事後諸葛亮
197:デフォルトの名無しさん
23/03/08 01:01:29.10 qkb67oYH.net
同じ事しか書けない命名君はGC連呼厨なのか
198:デフォルトの名無しさん
23/03/08 01:22:37.49 9h+oJZcX.net
結果的に後からみればC++の命名ミスなんだろうが歴史的経緯で仕方ないだろ
昔はimmutableとconstantの概念の区別が曖昧だった
199:デフォルトの名無しさん
23/03/08 01:53:12.26 CbNEQcSB.net
どうしても`immutable'を使いたければマクロ定義すれば?
#define immutable const
200:デフォルトの名無しさん
23/03/08 02:01:56.79 3vDDzLqz.net
Rustはconstをimmutableとcompile-time constantの両方の意味で使うので一貫性が無い
>>174
201:デフォルトの名無しさん
23/03/08 07:29:50.16 OMAPV4fU.net
>>200
Rustでconstは常に静的な定数を表す
*constはconstとは全く別のものであり予約語を最小限にするための使い回し組み合わせ
両者は種別も異なるため混乱することもない
constは定数の定義なのでこの位置に来る
let foo: i32 = 12345;
const FOO: i32 = 12345;
*constは生ポインタの型を示すのでこの位置に来る
const BAR: &i32 = &FOO;
const BAZ: *const i32 = &FOO;
このように両者は全く別物で出現位置も異なり共存もでき混乱することもない
この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
そのために新たな予約語を消費するのは馬鹿げているため既存の組み合わせという合理的な選択をした
202:デフォルトの名無しさん
23/03/08 07:30:57.28 /qygPgTx.net
constはCからの流れだしな。
元々Cがシステムプログラミング向けだったことを思えば、「リードオンリーセクションに置け」っていうくらいのつもりだったんだろ。
定数は#defineで指定しろって感じかな。
203:デフォルトの名無しさん
23/03/08 08:49:19.07 w2ee/I/N.net
>>201
> この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
safeの範囲で普通に使うけど
参照の同一性比較とか書いたことないの？
204:デフォルトの名無しさん
23/03/08 09:00:01.62 OMAPV4fU.net
>>203
参照の比較は生ポインタ直接比較ではなくstd::ptr::eqを使うのが行儀良いマナー
参照を渡せば*constに自動でcoerceされるためコードに*constを記述する必要はない
205:デフォルトの名無しさん
23/03/09 14:43:18.74 lc0skjdv.net
本題に戻ろう
206:デフォルトの名無しさん
23/03/09 19:02:01.89 33ubz+zP.net
Rustは優秀なんだろうけど、言語仕様が難解なのと、「～の分野ならRust」と言えるものがないから広がりにくいんだろうね
207:デフォルトの名無しさん
23/03/11 11:27:51.97 E47xdjIQ.net
それにRustは左翼的な弱者救済的な雰囲気が漂う。
VBも同じ理由で使ってるだけで駄目プログラマとみなされていったから、
同じようにRustを使ってるだけで駄目プログラマ決定されてしまう気がする。
208:デフォルトの名無しさん
23/03/11 11:29:57.74 E47xdjIQ.net
Excelもそうだ。Excelを使ってるだけで弱者扱いされてしまうようになっている。
VBもそうなったから、中味はそう変わってないのに名前を変えてC#にされた。
しかし、だんだんと、C#もVBと同じように馬鹿プログラマ専用言語とみなされる
ようになってきてる。
Rustもきっとそうなるだろう。
209:デフォルトの名無しさん
23/03/11 14:27:01.34 lvldJuuV.net
Rustも悪くないけど日本語のドキュメントが酷すぎるかなあ。
たとえば第七章のパッケージとグレートの話とかでも
-------
最初に学ぶモジュールシステムの要素は、パッケージとクレートです。 クレートはバイナリかライブラリのどちらかです。 クレートルート (crate root) とは、Rustコンパイラの開始点となり、クレートのルートモジュールを作るソースファイルのことです
--------
英文の方は版が新しいこともあってか
The first parts of the module system we’ll cover are packages and crates.
A crate is the smallest amount of code that the Rust compiler considers at a time. Even if you run rustc rather than cargo and pass a single source code file (as we did all the way back in the “Writing and Running a Rust Program” section of Chapter 1), the compiler considers that file to be a crate.
と、いう具合で以下だいぶ丁寧に解説してる。
パッケージにはa library crateとあるから一つだけなの？とChatGPTに尋ねたら複数入ることもあると断言されたけど。
210:デフォルトの名無しさん
23/03/11 14:31:08.67 +PZMhSrI.net
面倒ならとりあえずDeepLに掛ければ良いのにね
> モジュールシステムで最初に取り上げるのは、パッケージとクレートです。
>
> クレートは、Rustコンパイラが一度に考慮する最小のコード量です。cargoで
> はなくrustcを実行し、1つのソースコードファイルを渡したとしても（第1章
> の「Rustプログラムの作成と実行」でやったように）、コンパイラはそのファ
> イルをクレートと見なします。
211:デフォルトの名無しさん
23/03/11 16:27:23.47 BtFFfdHV.net
>>209
ひどすぎるのには同意するが
それはボランティアによる非公式な翻訳で
識者による監修や査読がされてないから
質が低いのは当然といえば当然
一部専門用語を除くと機械翻訳のほうが
それよりはマシな訳になることが多いので
多少英語が苦手でも公式を見たほうが断然効率がいいよ
212:デフォルトの名無しさん
23/03/11 16:39:48.49 47WJOH0Y.net
>>209
7章の最初のページ見ればそれぞれどういう関係なのか一目瞭然
単数形複数形の違いを丁寧に訳してなければ重要な意味が日本語訳では消えてるかもね
・Packages: A Cargo feature that lets you build, test, and share crates
・Crates: A tree of modules that produces a library or executable
・Modules and use: Let you control the organization, scope, and privacy of paths
・Paths: A way of naming an item, such as a struct, function, or module
213:デフォルトの名無しさん
23/03/11 17:28:34.44 /GMTezZ0.net
>>209
そのページは原文の2年半以上前の状態止まってる
日々改善されてるOSSで数年単位の遅れがあると全く役に立たないから
現状はRustの日本語ドキュメントは無いものと思っておいたほうがいい
214:デフォルトの名無しさん
23/03/11 18:00:56.32 bkYlWMhE.net
>>213
原文のいつの状態を反映した訳なのか全然管理できてないらしいからね
アップデートは望み薄
215:デフォルトの名無しさん
23/03/11 19:45:03.63 +PZMhSrI.net
規格がないので二流感が拭えない
かと言ってC++が登場したときのように
今はプログラミング言語の実装が
いくつも出てくる状況でもないのかな?
216:デフォルトの名無しさん
23/03/11 22:12:18.37 GtLfWJGz.net
>>215
C++での混乱と失敗を繰り返さないことが重要
217:デフォルトの名無しさん
23/03/11 22:59:17.84 +PZMhSrI.net
実装は複数あった方がメリットが大きいよ
218:デフォルトの名無しさん
23/03/11 23:05:20.16 2/rFH0pr.net
>>214
マジかよw
たかだか100個程度のファイルが管理できないってどんだけよ
219:デフォルトの名無しさん
23/03/11 23:19:14.88 ChsfUoNW.net
実装が複数あることはメリットもあるがデメリットも多くユーザを混乱させてきた
一方で言語仕様とその実現方法が確定して枯れた時は複数実装のメリットが上回る
Rustについては更なる理想の言語に向けて公開todoリストも多くまだ発展段階なので複数実装は向いていない
もちろん従来的な使い方ならば現状のRustで既に十分に利用できる
220:デフォルトの名無しさん
23/03/11 23:24:45.49 uRw385pv.net
>>218
ユーザーフォーラムのしかもたった二人の回答を「公式コミュニティの見解」にしてしまうオツムの人達だからさ一般常識があると思ったら大間違い
221:デフォルトの名無しさん
23/03/11 23:30:52.30 +PZMhSrI.net
>>219
3行目は全否定しておく
CやC++に複数の実装があった第一の要因は開発ツールが売れたという背景がある
Rustに限らず開発ツールは最早ビジネスとしては成り立たなくなってしまった
222:デフォルトの名無しさん
23/03/11 23:34:33.13 2T5UBlcf.net
>>220
あれ痛いよね
でもピン留めして晒し上げるのはさすがにどうかと思うわ
223:デフォルトの名無しさん
23/03/11 23:39:25.95 ChsfUoNW.net
Rustは公式が提供するcargoやrust-analyzerで開発環境は十分だもんな
もちろんrust-analyzerはLSPなのでVScodeなどの既存の統合開発環境で使える
224:デフォルトの名無しさん
23/03/11 23:51:17.37 3ENT9RfU.net
>>220
Rustユーザーの大半は英語のドキュメントを直接見てるからな
同じRustユーザーというだけであのリテラシーレベルと同類扱いされるのは誠に遺憾
225:デフォルトの名無しさん
23/03/12 06:07:53.91 b0Zzr0Fl.net
>>212
一目瞭然ってことはないよ。
わかってるやつにはわかるっていうレベル。
特にmodule and use以下で戸惑うと思うよ。
Rustはプログラミング言語としてはCとかで神経使っていたところで楽させてくれる感じだけど、新人を呼び込むにはドキュメントがまずいかなあ。
226:デフォルトの名無しさん
23/03/12 09:19:37.91 XJpeOWKz.net
前にもこれどこかで同じレスしたことあるけど
Javascriptってドキュメントすっごい充実してるよな
2000年以前はHTMLとJavascript一緒になった解説本の最後の方に申し訳程度に乗ってたくらいで
あとは某とほほサイト見るくらいしかなかったけど
最近ちらっとみたらすごいのな
URLﾘﾝｸ(developer.mozilla.org)
これは適当にクリックした特に選んでない一例だけど
ちょっと過剰なくらい説明と例が乗っててスゴイと思ったわ
Rustにここまでを要求したほうがいいとも思わんけど
いつかみんなが使う言語になったときはそうなってるのかもしれん
227:デフォルトの名無しさん
23/03/13 09:18:51.45 65XUJIc/.net
udemyからrust勉強すれば良いと思う
228:デフォルトの名無しさん
23/03/13 11:30:57.14 QpsvkUdl.net
C++は既に意味不明な域に来ていて、誰も新規に習得しようとはしないだろう
229:デフォルトの名無しさん
23/03/13 12:04:07.60 wwEuDEVq.net
>>226
ほんと。自分もノーマークだったけどすごいね。
Rustも「英文ドキュメント読め」みたいに突っぱねいようにしなくちゃね。
Rustのサイトで各国語にトランスレートされたもののリンク先の更新日付を眺めてると、中国語版に負けてる感じだね。
230:デフォルトの名無しさん
23/03/13 12:11:38.79 CJ8zcgHs.net
中国なんてどうでもいい
231:デフォルトの名無しさん
23/03/13 12:13:17.03 bP2+YJD9.net
MDNもMDNで英語読まないとやってられない記事はちょいちょいあるけどね
CSSのpositionとか
232:デフォルトの名無しさん
23/03/13 14:43:06.35 wwEuDEVq.net
少なくとも手解き用として、TheBookの日本語版ではねえ。
で、メモリ安全ってことだけをひたすらリピートするだけでは、新しい人は来ないでくださいと言ってるようなもん。
まあ、その方がチンケな優越感に浸れて良いのかもしれないけど。
233:デフォルトの名無しさん
23/03/13 15:10:59.37 cwbZasxH.net
>>231
Wasmのところも日本語版は古い情報のままなので肝心なAPIが足りていなくて英語版を見ないと致命的
リンク先が訳せてなくて英語版を指しているのは次善策としてまだマシ
英語版
URLﾘﾝｸ(developer.mozilla.org)
日本語版
URLﾘﾝｸ(developer.mozilla.org)
234:デフォルトの名無しさん
23/03/13 15:27:59.03 kyo182dJ.net
メモリ安全ってのは個人が始める動機としては弱い
スマートポインタで充分なんだし
チームで書くときにメモリ管理が怪しい奴が混ざり得るときに
Rustで書くことを強制されるってシチュエーションはありえるかもね
235:デフォルトの名無しさん
23/03/13 15:42:51.26 sbzZb6rB.net
>>234
両方書いてると差は歴然
Rustは可読性もよいし開発効率もよく
特に実行時デバッグが激減するのも大きい
やむをえない場合を除いてC++を使い続けるメリットはない
236:デフォルトの名無しさん
23/03/13 15:54:03.52 kyo182dJ.net
>>235
>Rustは可読性もよいし開発効率もよく
そんなのは人によるとしか言えない
所有権に割と馴染みがあるC++プログラマはともかく
他の言語からだと文法の解離に抵抗はあるだろうね
これからプログラミングを始めようという人は
特にRustだからという抵抗はないだろう
実績が増えればRustからって人が増えるかもね
237:デフォルトの名無しさん
23/03/13 16:03:04.23 UI2Ct8M3.net
C++はコンパイラ買う時にデバッグツールもあって、そこでメモリリーク含む大体の解析が出来ることが多いから、今の所メモリ安全で困ったことはないな。
それよりもRustはまだ新しいから、何かしら思わぬ脆弱性が潜んでいることも考えて、まだ弄りながら様子見って感じ
238:デフォルトの名無しさん
23/03/13 18:05:23.37 QpsvkUdl.net
C++の有料コンパイラってそんなすげえのか？
239:デフォルトの名無しさん
23/03/13 18:37:31.12 cwbZasxH.net
>>236
初心者や素人はC++でもRustでもなくBASICやPythonをやっていればいい
C++もRustも書きこなせる人なら自明なようにRustがはるかに効率いい
240:デフォルトの名無しさん
23/03/13 19:04:23.67 sbzZb6rB.net
>>237
デバッグツールを持ち出さなくてもRustはコンパイル時点でほとんど解決する点で圧倒的に優れている
Rustはメモリ安全性だけでなくデータ競合がないことがコンパイル時点で保証される
ポインタ以外の汎用的なヌル安全とエラー処理忘れ防止もRustは標準ライブラリ全体でOptionとResult利用により保証される
C++と比べて開発効率が段違いに良くなる
241:デフォルトの名無しさん
23/03/13 19:17:45.07 9XZC5W3h.net
C/C++のメモリリークと隣合わせなスリルがいいんだよ
Rustなんて補助輪付きの言語はプロのプログラマッには温すぎる
コーディングに自信がない奴や素人向けだな、Rustは
242:デフォルトの名無しさん
23/03/13 19:49:16.47 zhi7FkgJ.net
>>241
C/C++はプログラマとして成長させてくれるよね
243:デフォルトの名無しさん
23/03/13 19:51:01.09 cwbZasxH.net
>>241
C++はデバッグ時間のムダ
244:デフォルトの名無しさん
23/03/13 20:02:48.32 lNJwESa5.net
別にスマートポインタでええがな
245:デフォルトの名無しさん
23/03/13 20:04:22.18 lNJwESa5.net
Rustは規格が出てからだな
246:デフォルトの名無しさん
23/03/13 20:07:14.22 4NzLTP/2.net
マ板でやれバカども
247:デフォルトの名無しさん
23/03/13 20:22:48.71 4VuAJC20.net
>>239
変わった言語なので
まず初めに学んだほうが先入観がなく覚えられるよ
そのためにも日本語のドキュメントは
整備したほうが良い
248:デフォルトの名無しさん
23/03/13 20:39:22.66 RfKK3GLn.net
トラ枝 5月号 Rust 特集
249:デフォルトの名無しさん
23/03/13 20:45:38.95 sbzZb6rB.net
>>243
その通りでC++は無駄なデバッグ時間が必要となるけど
テストで発見できなかった分はデバッグもされず実行時のセキュリティ含めたバグとして残ってしまう
Rustならばコンパイル時点ですべて排除できる
>>244
勉強不足すぎだ
C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
250:デフォルトの名無しさん
23/03/13 21:04:50.75 kyo182dJ.net
>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
他は?
251:デフォルトの名無しさん
23/03/13 21:41:54.90 Lx/25M/K.net
>>250
そんなことも知らずにこのスレで書き込み続けているのかよ
他の人たちの書き込みを読んでないのかよ
252:デフォルトの名無しさん
23/03/13 21:46:41.78 kyo182dJ.net
>>251
他は? GCしか書けない人なのかな?
253:デフォルトの名無しさん
23/03/13 22:00:51.65 sbzZb6rB.net
>>250
既にたくさん書いて伝えた
理解できなかったのか？
254:デフォルトの名無しさん
23/03/13 22:16:19.15 P8sbSRo2.net
絵に描いたような負け犬のセリフw
255:デフォルトの名無しさん
23/03/13 22:35:49.32 kyo182dJ.net
>>253
本当にGCしか知らないんだな
>>249
>勉強不足すぎだ
熨斗をつけてそのままお返ししよう
256:デフォルトの名無しさん
23/03/13 22:38:39.16 Lx/25M/K.net
>>252
C++もRustもGC無いぞ
257:デフォルトの名無しさん
23/03/13 22:43:20.72 kyo182dJ.net
>>256
んなことぁ誰でも分かってる
258:デフォルトの名無しさん
23/03/13 23:26:56.50 sbzZb6rB.net
>>255
GC言語も使うしC/C++/Rustも使う
速さと省メモリの点でGC言語は不利だから使い分ける
259:デフォルトの名無しさん
23/03/13 23:40:00.84 kyo182dJ.net
>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
だから他は?
260:デフォルトの名無しさん
23/03/13 23:52:11.42 9+eE28f9.net
>>244
C++スマートポインタは
unique_ptrは使わずともRustでは標準で全て自動解放されるよ
shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
261:デフォルトの名無しさん
23/03/14 00:08:40.65 nARWep6y.net
>>260
別にunique_ptrやshared_ptrでええがな
難しくないよ
>shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
効率的をも少し詳しく!
262:デフォルトの名無しさん
23/03/14 00:17:28.43 g2aa4i95.net
C/C++でスレッドセーフな並列処理を作ろうと思ったら一苦労だけど、Rustだとそうでもないんかな。
263:デフォルトの名無しさん
23/03/14 00:51:48.86 mRkuEIyQ.net
>>261
shared_ptrは常に排他制御されコストが高い
共有を増減すると排他制御のコストがかかる
さらに単なる受け渡しも要注意でmoveしないとそのコストが無意味に余分にかかってしまう
一方でRustは排他制御するArcとしないRcの2つが用意されていてそれらの問題なく使い分けられる
>>262
Rustはコンパイルが通った時点でデータ競合がないことを保証されるのでかなり楽
264:デフォルトの名無しさん
23/03/14 00:58:40.53 Ff/IlIXh.net
うわっw
排他制御の意味も知らないのかよこいつw
265:デフォルトの名無しさん
23/03/14 01:09:54.31 gRogmLJe.net
shared_ptrは排他制御してリファレンスカウンタの増減を行うからスレッドセーフ
その代わり重い
266:デフォルトの名無しさん
23/03/14 01:26:54.27 nARWep6y.net
>>263
なるほどね
std::shared_ptrには参照カウンタの排他制御をオフにする機能はなかったかな?
boost::shared_ptrだと美しくないけどBOOST_SP_DISABLE_THREADSマクロで切り替えられる
最近使ってないがLoki::SmartPtrは確かテンプレートパラメータで切り替えできたかな?
267:デフォルトの名無しさん
23/03/14 01:58:37.91 gRogmLJe.net
Rustでは共存可能
スレッド内のみの共有はRc
スレッド間での共有はArc
切り替えでなく最初から二種類が用意されるべき
268:デフォルトの名無しさん
23/03/14 02:06:25.73 nARWep6y.net
>>267
同意
std::shared_ptrもLoki::SmartPtrみたいに
テンプレートパラメータで切り替えできれば良いのにね
ただしstd::shared_ptrを規格に入れた時点で
既にboost::shared_ptrもLoki::SmartPtrもあったことを考えると
参照カウンタが競合する機会はほとんどないという見立てで
実装を単純化したのかなと予想する
誰か経緯を知らんかな?
269:デフォルトの名無しさん
23/03/14 02:13:23.45 nARWep6y.net
苦肉の策としては
#include <memory>
#define BOOST_SP_DISABLE_THREADS
#include <boost/shared_ptr.hpp>
template <typename T> using Arc = std::shared_ptr <T>;
template <typename T> using Rc = boost::shared_ptr <T>;
270:デフォルトの名無しさん
23/03/14 02:59:21.97 u9OB+g2b.net
shared_ptr単独では完全なスレッドセーフではない、という問題もある。
shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
C++ではプログラマーがこれらの誤解や見落としやミスを全くしないことを求められ、それに依存するためプログラムの安全品質は危うい。
Rustではその点も安全で、Arc<T>はTへの書き込みが出来ないため、排他制御の問題は起きない。
書き込みしたいならば、Arc<Mutex<T>>やArc<RwLock<T>>など必要となる排他制御の種類に合わせて選び、組み合わせて利用する。
それら組み合わせにより、Tへの書き込みができるようになるが、必ずロックで排他制御されるため問題は起きない。
たとえプログラマーが見落としやミスや使い間違えをしても、Rustコンパイラがエラーを出し、該当箇所を教えてくれるため、常に安全性が保証される。
271:デフォルトの名無しさん
23/03/14 03:15:26.07 nARWep6y.net
>>270
Mutex <T>を書けば良いのではないかな？
272:デフォルトの名無しさん
23/03/14 03:19:38.24 nARWep6y.net
>>270
>shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
>したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
想定してるレベルが低すぎる
マルチスレッドで書くやつにそんなやつはいない
議論が無理やり過ぎ
273:デフォルトの名無しさん
23/03/14 03:33:56.57 u9OB+g2b.net
>>272
その件に限らずすべてにおいて、勘違い、見落とし、ミスなどは発生する。
複雑化したときにmutex忘れも、shared_ptr忘れも、間違えてunique_ptr使いも、その他のミスも、何でも実際に起きている。
Rustではそれらが起きてもコンパイラが通さないことで、常に安全性が保証され、無駄なデバッグを避けられる。
C++では無駄なデバッグを招くか、もしくは、そのままリリースしてセキュリティの穴が生じてしまう。
現実にC++が多数の問題を引き起こしてきた。
274:デフォルトの名無しさん
23/03/14 12:05:32.83 CPf3ZEOa.net
暇を持て余すニートの日記
275:デフォルトの名無しさん
23/03/14 12:21:44.83 nARWep6y.net
>>273
「Rustはコンパイルが通っていればマルチスレッドで
競合問題が起きないことが保証される」
これで正しい? 正しいとすれば
マルチスレッドを習得したときの苦労を考えると有用なので
新しくプログラミングを始める人には勧めたい動機になる
俺自身は困ってないので使おうとはあんまり思わんけどね
276:デフォルトの名無しさん
23/03/14 12:39:04.29 RkFbHwTA.net
Rustが流行るとすればどの分野になるんだろうか？
一番は安全装置とかに使われる小規模な組み込みソフトかな。
CPUとか開発環境とかがまだ整ってないだろうから、ゆっくりだと思うけど
277:デフォルトの名無しさん
23/03/14 12:50:59.56 nARWep6y.net
普及するのにはキラープロダクトが必要
UNIX（C）やMFC（C++）や.NET（C#）のように
大手がプロダクトに採用してトップダウンで流行らせるしか
普及の道はないと思う
ゆっくり普及なんてのはないと思う
278:デフォルトの名無しさん
23/03/14 19:34:32.70 /poSvH9Z.net
Visual Studio Rust .Netがでるまで待とう
279:デフォルトの名無しさん
23/03/14 19:40:00.62 //qYwEcn.net
あらためてJavaって良い言語だなって思うわ
ここ十数年だと人類一番の功績じゃね
良い点：
シンプルさ。C#で言う値型を入れようかどうか迷ったときもあったんだろうけど（想像）、
プリミティブと参照型変数の二個だけでやってくという線引がセンスある。
悲しい点：
立てまし。個人的にはジェネリクスもいらんかった。
C++のテンプレートを潔く排除して出てきたのすごいすっきり感あった。
でもあとでジェネリクスは押し負けて？付いてきちゃったけど。
あと貧相な貧相なラムダ式。クロージャを期待したけど結局はanonymous classのといっしょ。
異論は無いと思う
280:デフォルトの名無しさん
23/03/14 22:31:24.61 CPQICLea.net
>>275
Rustはマルチスレッド時でもマルチタスク時(＝グリーンスレッドをRustではタスクと呼ぶ)でも
データ競合を起こさないことが静的に保証されている
唯一のプログラミング言語
281:デフォルトの名無しさん
23/03/14 23:07:45.86 5gRl/D4e.net
んなわけねえだろ
282:デフォルトの名無しさん
23/03/14 23:17:29.22 CPQICLea.net
>>281
Rust以外の言語があるならば教えて
283:デフォルトの名無しさん
23/03/14 23:54:49.43 AgG33ThB.net
Ownershipの元ネタのCycloneはやってねーのけ？
284:デフォルトの名無しさん
23/03/15 02:10:25.53 itMePwRG.net
Rust、コンパイル遅いっていうけどどれ程なの？C++と比べて遅い？
285:デフォルトの名無しさん
23/03/15 02:53:43.28 aLgn/lBf.net
コンパイル後の実行デバッグ時間が激減したのでトータルで要する時間は減少した
286:デフォルトの名無しさん
23/03/15 03:26:18.55 DXTHIxnh.net
現状はバカがイキる為だけに持ち上げられるRust
万一普及したとしてバカが使いこなせるはずもなく
287:デフォルトの名無しさん
23/03/15 07:08:24.89 SNoM8taV.net
今まで C++ で制御して成功率 99.99% だった
ロケットをわざわざ Rust で描き替えて墜落しても
Rust は悪くない悪いのは GC のせいだと言い張るのが
Rust 信者
288:デフォルトの名無しさん
23/03/15 09:03:13.60 n0l+w21l.net
>>277
Android(Java)
iOS(Objective-C++)
289:デフォルトの名無しさん
23/03/15 09:51:38.96 d2iGalsS.net
ロケットでGCは無いわ
290:デフォルトの名無しさん
23/03/15 10:13:26.89 aLgn/lBf.net
>>287
C++もRustもGCないよ
291:デフォルトの名無しさん
23/03/15 10:52:34.36 d/hulDPr.net
プログラミング言語「Rust」は世界のセキュリティレベルを底上げする
URLﾘﾝｸ(wired.jp)
Androidでは今、暗号鍵を管理する機能の多くがRustで書かれているとGoogleのクライダーマーカーは話す。
たとえば、暗号化したインターネット通信の機能である「DNS over HTTPS」、新バージョンの超広帯域無線（UWB）チップスタック、
そしてグーグルの独自のチップである「Tensor G2」で使用される新しい「Android 仮想化フレームワーク（AVF）」 などもRustで書かれている。
また、BluetoothやWi-Fiなどの通信接続に使われるスタックも、Androidの開発チームによってRustへの変換が積極的に進められている。
理由は、これらが業界の複雑な標準規格に基づいており、脆弱性を多く含む傾向にあるからだとGoogleのクライダーマーカーは付け加える。
つまり最も狙われやすい、あるいは最も重要なソフトウェアの部分からRustに書き換えて、
そこから徐々にRustで書く範囲を広げることで段階的にセキュリティ上の恩恵を受けようという戦略である。
292:デフォルトの名無しさん
23/03/15 10:57:42.49 QVyWv/mn.net
>>280
デッドロックは静的検出はできないでしょ?
293:デフォルトの名無しさん
23/03/15 12:50:04.82 FGvum1vT.net
やっぱりC++だよね
294:デフォルトの名無しさん
23/03/15 15:17:28.42 6d2zOTAf.net
段階的に置き換えることができるだけのお金と能力のあるエンジニアを確保できるアメリカの大企業ならいいんだろうけどね
両方無い日本企業には無理無理カタツムリ
295:デフォルトの名無しさん
23/03/15 19:11:32.56 Raq+Bs5u.net
能力ない人の発想だね
296:デフォルトの名無しさん
23/03/15 19:46:51.43 rzl5B1H1.net
まず初めにの人はRustは選ばんと思う
Rustがターゲットとしているところで
プログラミングをやるなら
現状でCの習得は避けて通れない
となると学習コストの問題で
文法がほぼ包含関係にあるC++を選ぶことになる
OSの基盤からRustにしないと一向に増えないよ
297:デフォルトの名無しさん
23/03/15 19:49:13.81 N9nUYl96.net
>>3で終わってんだよこのスレ
うだうだ続けたい奴はコード書く能力もないからここで自己顕示欲発揮しちゃうんだろｗ
298:デフォルトの名無しさん
23/03/15 19:50:50.82 zbLR3nEh.net
能力ある人からRustへ移行していってる
>>294
ほとんどのシステムは複数のプログラムから構成されているため
それら各機能をグレードアップで更新するときにRustへ書き換えることで進んでいる
もちろん新規システムは最初からRustで書くことが多くなっている
299:デフォルトの名無しさん
23/03/15 19:55:49.97 rzl5B1H1.net
Rustユーザが増えるストーリーは
トップダウンで基盤を整備するしか有り得ない
Cと文法が乖離してるのはメリットもあるだろうけど
普及にはデメリットとして働いている
300:デフォルトの名無しさん
23/03/15 20:02:03.89 zbLR3nEh.net
セキュリティ観点から新規システムはC/C++禁止でRust必須が要件になっていってる
この動きはそれが出来るところから着実に進んでいるので止めようがない
301:デフォルトの名無しさん
23/03/15 20:52:20.68 QVyWv/mn.net
>>300
>新規システムはC/C++禁止でRust必須が要件
どこで?
302:デフォルトの名無しさん
23/03/15 21:00:17.63 QVyWv/mn.net
デファクトスタンダードの強さは
MSを見ていればまぁ自明だわな
303:デフォルトの名無しさん
23/03/15 21:15:24.65 itMePwRG.net
結局コンパイルってどのくらい遅いの？
304:デフォルトの名無しさん
23/03/15 21:55:22.51 46PmQs8i.net
今日のMicrosoftの発表が面白い
発表デモでなぜかPythonからRustへ
URLﾘﾝｸ(www.msn.com)
2023/03/15
本日マイクロソフトは、Edgeウェブブラウザの安定バージョンのサイドバーに、新しいBing AIチャットボットが含まれるようになったことを発表しました。
デモンストレーションで、AIにStack Overflowのヒントを調べながらコードのスニペットを書くように依頼しました。
AIはPythonコードをRustに変換することができました。
305:デフォルトの名無しさん
23/03/15 21:58:57.19 46PmQs8i.net
>>304
正しいURLはこれ
URLﾘﾝｸ(www.msn.com)
306:デフォルトの名無しさん
23/03/15 22:07:43.40 QVyWv/mn.net
Rust普及はMSの動向が鍵だよ
自然に増えるもんじゃない
307:デフォルトの名無しさん
23/03/15 22:20:44.44 46PmQs8i.net
Microsoftは自社製品のRust化を進めると同時に普及も進めてるね
日本語ドキュメントも充実してる
Rustを使用したWindowsでの開発
URLﾘﾝｸ(learn.microsoft.com)
308:デフォルトの名無しさん
23/03/16 00:10:36.78 srO8KDRm.net
PriorityはF#の次だな
URLﾘﾝｸ(learn.microsoft.com)
309:デフォルトの名無しさん
23/03/16 00:12:05.34 srO8KDRm.net
「C++とCの概要」の位置に来ないと普及には程遠い
310:デフォルトの名無しさん
23/03/16 00:25:01.88 AJSi61e9.net
RustがC++と同じ土俵へ採用されてしまった時点で
何もかも優れているRustの勝利
疑われる「C++」の安全性、今後の動きはどうなる
URLﾘﾝｸ(japan.zdnet.com)
311:デフォルトの名無しさん
23/03/16 06:24:59.05 R4dgmdEC.net
次の10年はRustが取った、となると、APIがRustになる
ならば、RustなAPIにC++がきちんと接続できるようになってもおかしくない
そうすると、Rustが実績を積んだ「正しい縛り」を、C++でも使えるようになってくるんではないだろうか
もうそういう試みある?
312:デフォルトの名無しさん
23/03/16 08:50:45.88 zwODLYWH.net
何言ってんだこのバカ
313:デフォルトの名無しさん
23/03/16 09:08:29.35 wZlU7tIR.net
>>311
既にRustとC++の相互呼び出しは実現されているが
Rustから見てC/C++部分は当然unsafe扱い
最終的にC/C++部分が無くなる形で完成することになる
314:デフォルトの名無しさん
23/03/16 09:15:14.89 3C3pOHVn.net
OSもアプリケーションも、pure Rustになるんだろ、理想論としては
だとしたら、境界面であるAPIには、縛りにかかる属性情報が露出するはず
C++がそれに対応できないなら、今後C++ではアプリケーションを書けないことになってしまう
315:デフォルトの名無しさん
23/03/16 09:54:57.99 hwbAfXXm.net
慣れて使いこなせるようになると、
Rustの方が書きやすいとほとんどの人が言うほど差があるのだから、
C++がいずれ消えるのは間違いない。
316:デフォルトの名無しさん
23/03/16 10:39:34.81 N2/NSeFa.net
>>298
>能力ある人からRustへ移行していってる
まるでKENYAの作文だな
317:デフォルトの名無しさん
23/03/16 10:43:46.43 fxj0X8UB.net
Rustからインラインアセンブラでレジスタいじって安全性が担保されつつC++と遜色ないならもういらんわな
318:デフォルトの名無しさん
23/03/16 10:45:31.49 X3XJCWQc.net
ここでぐちゃぐちゃ言っても何も変わらないからさっさとC/C++で書かれた森羅万象の移植やってこいよ
319:デフォルトの名無しさん
23/03/16 10:57:52.25 n4rBBOEi.net
>>317
もちろんRustの変数を使う形でインラインアセンブリをRustでは記述できるが
当然ながらRustコンパイラによる保証範囲外となるunsafe部分になる
Rustはunsafe部分のみ人間が安全性を担保すれば全体についてはRustコンパイラが保証する形で役割分担できる
その点でプログラム全体が常にunsafe状態となってしまうC/C++とは根本的に異なる
320:デフォルトの名無しさん
23/03/16 10:59:13.64 mkPG1w5O.net
>>303
ここの最後の方に載ってるよ
URLﾘﾝｸ(quick-lint-js.com)
OSによっても違うみたいだけど、C++の方がちょっと早いくらいだね
321:デフォルトの名無しさん
23/03/16 11:04:29.29 srO8KDRm.net
まぁRustでスクラッチから書かれたOSでWindowsやiOSやAndroidを取っ替えるか
スマホみたいな何らかの新しいハードウェアが誕生して
それがRust製で書かれたOSで制御されている状況にならんと普及はせんよ
322:デフォルトの名無しさん
23/03/16 11:11:37.43 r79frV++.net
>>321
頭の弱い子ですね
JavaやPerlやJavaScriptやRubyやPHPやPythonなどで書かれたOSは普及していませんが
それらの言語は普及しました
323:デフォルトの名無しさん
23/03/16 11:19:37.68 srO8KDRm.net
>>322
JavaやPerlやJavaScriptやRubyやPHPやPython使ってるところで普及はするかもね
じゃこれで良い? ニッチと言って分かるかな?
324:デフォルトの名無しさん
23/03/16 11:22:05.57 3C3pOHVn.net
マイコンでRustを使う試みは結構普及してるみたいだね
325:デフォルトの名無しさん
23/03/16 12:18:46.17 xA7F3jfw.net
Rustは電気ドリルや3Dプリンタのような道具なんだから、本当に良いと思えば
自分が使って生産効率を上げたり良い作品を作って披露すれば良いだけなのに、
信者達が無理やり広めようとしているのが嫌だ。
困るのは、C++を使ってる人を馬鹿にすること。
326:デフォルトの名無しさん
23/03/16 12:23:14.36 0EJvJf6l.net
Rust製の高速なwebpack互換バンドラ「Rspack」登場。現時点で5倍から10倍の性能向上 URLﾘﾝｸ(www.publickey1.jp)
327:デフォルトの名無しさん
23/03/16 12:23:28.58 xA7F3jfw.net
C++をディスってC#を上げまくっていた人達が、Rustに鞍替えした模様。
彼らは5chやtwitterで徹底的にRustを褒めまくっている。
どうしてそんなことをするのか。思想家や哲学者なのか。
マルクスもそういう感じで結果、大勢の人々を苦しめた。
328:デフォルトの名無しさん
23/03/16 12:31:35.94 srO8KDRm.net
Rustはポテンシャルはあるけど現状で普及するパスが見えていないですから
Rustを愛する者にとってはそこがフラストレーションなのでしょう
普及するパスが見えたら解消すると思うよ
329:デフォルトの名無しさん
23/03/16 12:37:22.05 3C3pOHVn.net
C++が怠っていた部分を成し遂げたんだから、Rustは誇っていい
エンジニアが本職なら、C++でもRustでも、なんでも読み書きできないといけないだろう
まあ、じきにC++も追いつくだろ 問題はC
330:デフォルトの名無しさん
23/03/16 13:52:30.33 xA7F3jfw.net
本当に優秀なプログラマなら、C++でもRustでもどっちでも簡単に使えるので、
必要あらば、どっちでも使うだろうが、C++でもメモリーエラーなんて滅多に
起こさないし、起きても原因究明して直せるから、敢えてRustに行く動機もない。
別にRustが使えないからC++を使ってるわけじゃないのに、Rust使う人の方が
憂愁みたいに言われるのはおかしい。
331:デフォルトの名無しさん
23/03/16 13:53:26.57 xA7F3jfw.net
>>330
書き間違えた。
憂愁 ---> 優秀
332:デフォルトの名無しさん
23/03/16 13:55:47.65 xA7F3jfw.net
>>329
「Rustは誇っていい」という意味が分かりにくい。Rustを作った人はちょっと
誇っていいかも知れないが、Rustの解説本を書いている人や、Rustを道具として
使っている人が誇っていいわけではない。
333:デフォルトの名無しさん
23/03/16 13:57:50.83 3C3pOHVn.net
ああ、うん
Rust(言語と言語チーム)は誇っていい
その一派につらなる「信者」が誇るのは…まあ人の常かなって
334:デフォルトの名無しさん
23/03/16 14:00:22.48 xA7F3jfw.net
>>333
>その一派につらなる「信者」が誇るのは…まあ人の常かなって
信者が誇って良い分けないと思うが。
335:デフォルトの名無しさん
23/03/16 14:06:46.30 3C3pOHVn.net
Rust派先鋒衆がいうのは、Rustに移れば、大多数の脆弱性は自然につぶれるのに、
C++に固執するのがもうクズ。っていう発想 それもわかるんだけどね
なんでも書けてこそのC++ 縛りを記述できないなんて、欠陥でしかない
だから、C++の進化には期待してる 遅々たるものになるかもしれないけど
336:デフォルトの名無しさん
23/03/16 14:20:33.51 xA7F3jfw.net
>>335
>Rustに移れば、大多数の脆弱性は自然につぶれるのに、
>C++に固執するのがもうクズ。っていう発想 それもわかるんだけどね
本当に優秀ならば、C++でも脆弱性がが入らない。
mozillaやgoogleの社員がタコなだけ。
337:デフォルトの名無しさん
23/03/16 14:30:08.42 srO8KDRm.net
>>314
C++からRustライブラリを呼ぶ場合もRustからC++ライブラリを呼ぶ場合も
文法違いすぎて大変そうだけどどうしてるんかな?
Cのライブラリを呼ぶのはどのプログラミング言語からでも余裕だけども
JavaとC++もかなり歪だよね?
338:デフォルトの名無しさん
23/03/16 14:31:40.01 hABarloL.net
>>336のような勘違いしてる自信過剰なダメな人たちが今までセキュリティの穴を多数あちこちで生じさせてきた
人間は必ずミスをするという当たり前のことも受け入れられない人はキチガイのみ
339:デフォルトの名無しさん
23/03/16 14:33:21.04 3C3pOHVn.net
>>336
一人で作るもんでもないからねえ、大人数だと、体調の悪いヤツとかも混じるだろ
コンパイラに任せたいってのはわからんでもない
俺も、(たとえば)gccとヘッダライブラリに任せて、自分は気楽にごりごり書きたいｗ
340:デフォルトの名無しさん
23/03/16 14:34:51.94 srO8KDRm.net
>>338
自信過剰も何もC++書ける人だとなぜに
スマートポインタで失敗するのか理解不能だよ
原因は生ポインタ使ってるからなんだろうけど
それなら生ポインタをプロジェクトで禁止にするだけで充分
あとマルチスレッドにおけるデッドロックはRustで検出できるのかい?
341:デフォルトの名無しさん
23/03/16 14:37:50.95 srO8KDRm.net
ボローチェッカだっけ? CとC++で実装できんのかな?
342:デフォルトの名無しさん
23/03/16 14:39:57.56 3C3pOHVn.net
ていうか、Rustがもたらそうとしてるのは、プログラミングパラダイムだから、
C++でおんなじように書ければいいんだよ ハズしてたらコンパイルエラーになってくれてだな
Rustは実績を積んだ C++は早くその成果を取り込むべき
ラムダといいコルーチンといい、C++が他に学んだ前例はいくらでもある
>>341
まじそれ
343:デフォルトの名無しさん
23/03/16 15:04:51.89 bO6zkRLm.net
>>338
それはプログラマーのレベルが少なくとも俺よりは低いから。
344:デフォルトの名無しさん
23/03/16 15:07:17.05 3C3pOHVn.net
>>343
お前みたいな優秀なヤツが、【わざと】脆弱性を仕込んだコードをコミットしたりするんだよｗ
他人は信用できねえ
俺クラスになったら、自分自身が一番信用できねえｗｗ
345:デフォルトの名無しさん
23/03/16 15:14:34.72 N2/NSeFa.net
use 描くだけでコンパイル中にダウンロード始まって
何分も待たされたらそりゃ遅いわ！！！ぷんぷんって
怒るアホも出て来るだろうね
346:デフォルトの名無しさん
23/03/16 15:18:25.89 N2/NSeFa.net
>>334
Rust(人気)は俺が育てた！(AA略)
347:デフォルトの名無しさん
23/03/16 15:36:54.04 07ACJDqQ.net
>>341
現状では無理
C++33くらいで可能になるかもね
348:デフォルトの名無しさん
23/03/16 15:38:33.76 07ACJDqQ.net
>>340
>あとマルチスレッドにおけるデッドロックはRustで検出できるのかい?
コンパイルエラーになるかという意味ならならない
その辺はGoとかと一緒でイディオムで対処
349:デフォルトの名無しさん
23/03/16 15:42:21.06 I4Z9PBKv.net
>>348
メモリ安全だけだとあんまり有り難くないな
もしミスってもデバッガで直ぐ分かる訳だし
350:デフォルトの名無しさん
23/03/16 15:51:10.02 TBYrYTSU.net
>>349
メモリ安全だけでなく
C++とは異なりRustはデータ競合を完全に防げる
C++とは異なりRustは広義のヌル安全であることも大きい
351:デフォルトの名無しさん
23/03/16 16:02:01.69 PpEtLqb1.net
>>350
それでも言語が汚いから使いたくない。
352:デフォルトの名無しさん
23/03/16 16:24:46.13 TBYrYTSU.net
様々なプログラミング言語と比較してもRustは美しい側に入るとともに
言語機能が強力で可読性が高い
とくにパターンマッチング
これはC++でも導入しようとしているが進んでいないだけでなく
C++で出ている提案では強力でなく可読性もよくないようにみえる
Rustはパターンマッチングが非常に強力で可読性の向上の最大要因となっている
353:デフォルトの名無しさん
23/03/16 16:52:12.01 3grScBM3.net
>>351
Rustかどうかは別として10年後くらいには
今Rustが実現してるやり方が標準的なものになるのは間違いないから
考え方やメリットデメリット、限界をある程度学んでおいた方がいいかもよ
Rust自体はいいところもあれば悪いところも沢山あるので実際に使うかどうかは状況次第
354:デフォルトの名無しさん
23/03/16 17:04:30.58 YeYGULup.net
結局Rustがもひとつ流行らないのって
①エコシステム
②ライブラリ
なんじゃやいの？
①は流行ってきたら充実するものでニワトリと卵だけど、②はどうなん？
②が中々充実しないのは何かRustのライブラリ書いてやろうと言う人が出てこない理由あるんかな？
355:デフォルトの名無しさん
23/03/16 17:12:09.28 3C3pOHVn.net
採用宣言が大手から出たんだし、そのへんは急ピッチで進むっしょ
>>353
10年後には、いまRustが提示しているものを踏まえた、さらにスマートなものが出ているかもしれない
でも、それを理解するには、ここから10年間、Rustの成果を学び、踏まえるのがいい だから俺はいま学ぶぜ
願わくば、10年後にも、しぶとい感じでC++が現役であってほしいな
356:デフォルトの名無しさん
23/03/16 17:15:50.99 QTF1+6wX.net
C++は次々と新たな機能を増やし続けてきたが増築工事だから色んな点で限界が多い
例えば話が出ている広い意味のnull安全はC++がoptionalの導入をとっくに行っているが
・なかなか普及しない
・既存ライブラリの仕様とのチグハグ
・パターンマッチング機能の導入がまだなので使い勝手が悪い
などの問題が山積みであまり使われていない
C++の他の機能導入でも似たような状況が多い
Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
C++をさっさと棄てるのが現実解であると理解できた
357:デフォルトの名無しさん
23/03/16 17:23:01.97 3C3pOHVn.net
C++はなんでも書けるかわりに、いまや考えなしに勝手に組み合わせると めちゃくちゃになるんだよね
Rustには引き算の美学の成果が入ってる
C++も、先頭で縛りを宣言できるようにして、美しく書けるようになるべきだ 絶対に
358:デフォルトの名無しさん
23/03/16 17:47:47.57 VzH+f4s6.net
ソースコードのコンパイル・ビルドの時点ですべての問題点をエラーで全部弾いてくれたら理想的だね
大抵はテストツールまで書かないと使えない
359:デフォルトの名無しさん
23/03/16 19:59:01.19 srO8KDRm.net
>>350
コンストラクタでlockしてデストラクタでunlockするproxyクラス作って
その一時オブジェクト経由で触れば良いだけなので何を今更という感じ
メモリ安全は別にデバッガですぐ特定できるし
マルチスレッドではRustの利点がない
デッドロックが検出できたらまぁ嬉しいが?
360:デフォルトの名無しさん
23/03/16 20:03:11.00 u3ZLVO1D.net
クラス笑
361:デフォルトの名無しさん
23/03/16 20:03:55.24 srO8KDRm.net
>>354
多くの人に使ってもらおうと思ったらCで書いて
各言語のラッパーを提供するってのが多い
RustにこのCの代わりができれば良いんだけども?
もしRustユーザしかリンクできないライブラリだったら
Rustはそもそもユーザー数が少ないし
Rustで書く動機が減る
362:デフォルトの名無しさん
23/03/16 20:07:00.05 srO8KDRm.net
>>357
多人数でやるプロジェクトにはC++は自由過ぎて
その点は書き方にある程度拘束される意義はあると思う
363:デフォルトの名無しさん
23/03/16 23:56:33.56 ufHOK4fg.net
>>320
ありがと
意外と変わらないんだ
364:デフォルトの名無しさん
23/03/17 00:02:12.50 aeVIJ/KU.net
Rustでゲームエンジンやグラフィックソフト作れたら認めてやるよ
365:デフォルトの名無しさん
23/03/17 00:04:03.80 aeVIJ/KU.net
DTMに使いそうなDAWソフトとかでもいいぞ
書き方はGitHubにいろんなOSSの見本があるから簡単でしょ？
366:デフォルトの名無しさん
23/03/17 00:04:27.28 aeVIJ/KU.net
Rust使いこなせるくらいなら余裕のはず
367:デフォルトの名無しさん
23/03/17 00:14:30.94 o5CBT2m0.net
SDLのRustバインディングはあるけども
Rustで本体を書いて他の言語のバインディングって出来るの?
他の言語との乖離でRustならではの部分が封じられて
あんまり嬉しくないような気もするのだが?
それともRustでライブラリ書いたらターゲットはRustだけになるのかな?
368:デフォルトの名無しさん
23/03/17 00:14:49.50 6s2Kuhdf.net
>>356
>Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
俺とは感覚が違う。Rustを美しく感じない。
369:デフォルトの名無しさん
23/03/17 00:21:48.75 6s2Kuhdf.net
これは理解できるし、はっきりそう書けばよい:
・Rustの本を書きました。Rustは良い言語なので本を買ってください。
・Rust用のライブラリを書きました。Rustは良い言語なのでライブラリを買ってください。
これは理解できないし、問題:
・C++は害悪なのでRustをみんなが使って世の中を良くしよう。
・自分がC++を使いこなせないのに、使いこなせる人が許せないから、使いこなせるRustを普及させたい。
370:デフォルトの名無しさん
23/03/17 00:39:18.46 2hBAQcCo.net
RustはC++なんかよりずっと簡単! <- これならわかる
371:デフォルトの名無しさん
23/03/17 00:51:57.03 6s2Kuhdf.net
>>370
それも意見が分かれそうだ。
372:デフォルトの名無しさん
23/03/17 00:54:59.09 UJajhYy7.net
>>367
出力をcdylibにすれば一般的なCソースのライブラリと同じ形式（soとかdll）で出力されるはず
当然FFI絡みの制約は出てくるしextern指定とかも必要だけど境界部分だけ気を付ければ内部は自由にRustできる
wgpuはRustで書かれたグラフィックライブラリだけどその機能をC/C++から呼ぶためのwrapperでwgpu-nativeがあって
さらにそのC用のwrapper経由で別言語（Pythonとか）のwrapperが作られてたりする
依存関係がややこしいけど
wgpu (Rust製、Rust用Lib出力) ← wgpu-native (Rust製、C用Lib出力） ← wgpu-py (C+Python製、Python用ライブラリ）
みたいな構造
373:デフォルトの名無しさん
23/03/17 01:04:51.03 o5CBT2m0.net
>>372
なるほどー
374:デフォルトの名無しさん
23/03/17 05:58:07.48 HbMAHHRq.net
>>359
Rustならマルチスレッドでもマルチタスク(=グリーンスレッド)でも書きやすく
さらにデータ競合を完全に防げるRustしか現状の言語では選択肢ないと思うよ
各言語で書き比べてみれば一目瞭然
そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
375:デフォルトの名無しさん
23/03/17 10:42:47.45 o5CBT2m0.net
>>374
>>そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
全く進んでいないのだが?w
俺の周りではC++やJavaでマルチスレッドで書く奴の方が多い
というかそもそもRustを使っている奴は一人もいないw
妄想なのか詐欺師なのか...
Linuxでも さもRustの導入が進んでるように言うが実際は>>39だし...
376:デフォルトの名無しさん
23/03/17 10:55:37.94 FKqwIQQI.net
マルチスレッドはまあ普通だけどマルチタスクはめちゃくちゃ書きにくいぞ
単純なWeb Serverくらいならいいがちょっと凝った処理を書こうとするとくっそ面倒くさい
tokio依存なのもダメなところ
377:デフォルトの名無しさん
23/03/17 11:06:44.98 tBmmskox.net
そここそ、OSがRust化するっていうんだから、きれいなAPIが出てきてほしいね
結局、効率を求めたらC API に肉薄することになるし
378:デフォルトの名無しさん
23/03/17 11:15:24.56 TZnQdWAf.net
Linuxの現状はRustでドライバが書けるようになったってだけだよ
誤解なきよう
379:デフォルトの名無しさん
23/03/17 11:17:48.64 RPqYd1dp.net
>>376
マルチタスク(並行)で綺麗に書ける言語はRustとGoだけだな
GoはPromise(Future)使わないあのスタイルに寄せられるのとGC言語であるため
Rustが汎用では筆頭言語になる
380:デフォルトの名無しさん
23/03/17 11:33:47.61 Igk62yzo.net
>>376
だよな
Rustの非同期が簡単だと勘違いしてるやつはチュートリアルレベルしかやったことないやつだと思うわ
381:デフォルトの名無しさん
23/03/17 11:43:37.53 RPqYd1dp.net
>>380
自分でpollしたりするのも含めて色んなレベルで書いているが簡単だぞ
Rustで並行並列が難しいと言うならばとこが難しいのかを具体的に述べよ
そしてそのケースでRustの代わりに使える別言語があるならば述べよ
382:デフォルトの名無しさん
23/03/17 11:51:53.17 UWSndCzi.net
Goと比較したら性能面でも劣ることが多くて同程度の性能を実現したければ手動であれこれやらないといけないからな
383:デフォルトの名無しさん
23/03/17 12:19:57.65 CZQwnfV3.net
>>381
そうやって自分が分かってない事を無料で聞き出してしまおうとする。ずる賢い。
384:デフォルトの名無しさん
23/03/17 12:31:22.55 RPqYd1dp.net
>>382
Goが速い遅いと言ってたのは昔の話
今はGoもRust tokioも改善してほぼ同じwork stealing方式になり似たりよったりの速度
C++をあきらめてRustに対抗できるGoを持ち出すしかないほど追い込まれてるのかね
>>383
Rustで並行並列が他の言語より難しいことはない
難しいと主張するならば何が難しいのかを述べたまえ
もし本当に具体的に困ったことがあるならばアドバイスできる
385:デフォルトの名無しさん
23/03/17 12:38:18.49 YQ2F/Sw2.net
追い込まれてるってなんだろうね
楽しそうだね
386:デフォルトの名無しさん
23/03/17 12:39:30.67 o5CBT2m0.net
この人は妄想癖がある
387:デフォルトの名無しさん
23/03/17 12:56:40.90 LTrpjv8n.net
>>384
>Rustで並行並列が他の言語より難しいことはない
>難しいと主張するならば何が難しいのかを述べたまえ
>もし本当に具体的に困ったことがあるならばアドバイスできる
問題意識があること、気付くこと、それが大事。
あなたにはそれがない。
388:デフォルトの名無しさん
23/03/17 13:03:24.97 Gi38nai6.net
>>383
わかり味
こいついつも教えて君だよなぁ
総論しか書けないところみると
マニュアルだけ読み込んだペーパープログラマーがそれを隠すためのネタを欲してるようにしか見えない
389:デフォルトの名無しさん
23/03/17 13:03:47.55 T8dNhcTz.net
Goはgoroutine間のデータ競合の発見を実行時のランタイムでやるしかなく
Goはあまりお勧めできないなあ
メモリ共有せずチャネルを使う範囲ならGoでもいいけど
Rustでもチャネルはもちろん使えるし
共有メモリで安全にデータ競合を起こさず使えるからRustがいいよ
390:デフォルトの名無しさん
23/03/17 14:28:10.79 ZRpBqjDt.net
ほんと嘘ばっかりだな
391:デフォルトの名無しさん
23/03/17 15:04:18.42 RPqYd1dp.net
>>389
Goに限らずデータ競合を実行時にしか検出できない言語ではデータ競合が時々しか起きない場合のデバッグが難しい
Rustを使うべき理由はデータ競合を静的に検出できる点にある
392:デフォルトの名無しさん
23/03/17 15:55:42.60 LTrpjv8n.net
>>391
それはマルチスレッドプログラミングのアルゴリズムをRustは強く制限しているから。
だから、その制限から外れるようなアルゴリズムは使えないので柔軟性は欠く。
393:デフォルトの名無しさん
23/03/17 16:03:41.59 tBmmskox.net
そこが、新規書き起こしのRustのメリットでもあるわけよな
394:デフォルトの名無しさん
23/03/17 16:05:57.04 LTrpjv8n.net
>>393
そして、独自のアルゴリズムは使えないので、アルゴリズムの研究には向かない。
395:デフォルトの名無しさん
23/03/17 16:11:31.46 TZnQdWAf.net
第n次LinkedListおじさんvsGCおじさん戦争
396:デフォルトの名無しさん
23/03/17 16:16:19.10 tBmmskox.net
頑張ったら書けるんじゃねーの、それもsafeで
そのへんはC++もおなじ 自分も、ニッチすぎる薄いラッパなら頑張って書くし
397:デフォルトの名無しさん
23/03/17 16:20:04.75 KZujdKGk.net
>>392
Rustで記述できないマルチスレッドプログラミングのアルゴリズムなんてものは存在しない
Rustは柔軟性が非常に高い
398:デフォルトの名無しさん
23/03/17 16:32:10.93 LTrpjv8n.net
>>397
嘘を書かないで。
399:デフォルトの名無しさん
23/03/17 16:41:56.97 T8dNhcTz.net
Rustで書けないのがあると主張している人が例を出せばいいんじゃね
Rustにそんな制限はないからすべて書けるよたぶん
400:デフォルトの名無しさん
23/03/17 16:52:07.05 4tGjgBNl.net
結局何年か後にはlinux kernelを全部rustで書くつもりなんかな
401:デフォルトの名無しさん
23/03/17 17:00:34.34 tBmmskox.net
書けなくはないだろ、書きやすいかどうかだ 実際どうなん
C++は、なんでも書けるが、油断すると複雑すぎる代物ができあがる
そんで、「でも例外がくるとー」「でも異常値がくるとー」って
402:デフォルトの名無しさん
23/03/17 17:01:41.44 LTrpjv8n.net
>>399
マルチスレッドのアルゴリズムは非常に多く存在していて、ある意味では無限に
考えられる。Rustは数個しかサポートしていないから、無理。
403:デフォルトの名無しさん
23/03/17 17:26:21.78 T8dNhcTz.net
>>402
Rustで書けない例があると主張したいなら例を出せばいいんじゃね
Rustに何か制限があるわけじゃないからおそらくなんでも書けるよ
404:デフォルトの名無しさん
23/03/17 17:31:51.55 LTrpjv8n.net
>>403
unsafeになる。
405:デフォルトの名無しさん
23/03/17 17:42:50.37 T8dNhcTz.net
>>404
マジ？信じられん
もし本当ならそのunsafeを使わざるを得なかった例を具体的に出せばいいんじゃね
406:デフォルトの名無しさん
23/03/17 17:43:39.56 tBmmskox.net
unsafeをゼロにするよりも、極小なunsafeブロックを組み込んで華麗にキメてほしいね
これはC++も同様
407:デフォルトの名無しさん
23/03/17 17:52:35.17 2s/kFNH6.net
>>400
そういう枯れた古いものをわざわざ書き直すことに熱意を燃やせる人間は少ない
新世代のデータベースやcrypt/blockchainのように金になる新しい成長分野ではc/c++よりもrustがよく使われてる
技術の自然な世代交代は既存システムの置き換えから始まるものではない
408:デフォルトの名無しさん
23/03/17 18:01:30.86 LTrpjv8n.net
>>405
次のことが成り立っていれば教えてもらわなくても自然に分かる:
・マルチスレッドの事を理解している。
・Rustのことを理解している。
・算数的直観力に優れる。
409:デフォルトの名無しさん
23/03/17 18:03:48.04 u99ocdLb.net
複製おじさん vs 100点おじさん
Fight!
410:デフォルトの名無しさん
23/03/17 18:24:08.50 NC4w42Nt.net
>>401
そのへんの問題もRustだと安全安心なのがいいよなー
特に例外機構を無くしたのは大成功
あとResult放置してると警告もしてくれるしな
>>404
そのunsafe使わないと書けなかったコードを出してみ
寄ってたかって添削してやろう
411:デフォルトの名無しさん
23/03/17 18:36:02.65 LTrpjv8n.net
>>410
俺は天才だから、お前みたいな凡人に無料でヒントをくれてやらない。
412:デフォルトの名無しさん
23/03/17 19:13:16.48 tBmmskox.net
Rustって、削ぎ落したものは復活させません、って宣言とかしてるん?
413:デフォルトの名無しさん
23/03/17 19:55:25.86 9o1NNcpX.net
>>408
Rustをあんまり知らんけど言語間に根本的な差はなくね？
414:デフォルトの名無しさん
23/03/17 20:02:50.35 kImSYq8C.net
>>408はいつものキチガイ
RustもC++もコードを書けたことがない
相手にするだけ無駄
415:デフォルトの名無しさん
23/03/17 20:19:10.88 TZnQdWAf.net
>>414
今さらなに言ってるんだ？
ここにはキチガイしかいないぞ？
俺もお前もな
416:デフォルトの名無しさん
23/03/17 20:29:34.70 Zxg/DnHC.net
>>413
ん？だから何？
417:デフォルトの名無しさん
23/03/17 21:29:42.97 o5CBT2m0.net
>>416
アルゴリズムを書ける書けないの差はでない
418:デフォルトの名無しさん
23/03/17 23:44:57.66 Lcw0Ean/.net
Rustほとんど知らん俺でも総合的にRustのほうがC++よりはいいだろと思う
C++より後発言語で、で、ライバルになるC＋＋に劣っているようじゃダメだからな
で、お前らは、すごいRustで具体的に何を作っているんだ？
419:デフォルトの名無しさん
23/03/18 00:11:15.51 6kQD14Ek.net
ChatGPT先生に聞いてみた
>>404の言う通り
template <typename T>
class LockFreeStack {
public:
void push(const T& value) {
Node* new_node = new Node(value);
new_node->next = head.load(std::memory_order_relaxed);
while (!head.compare_exchange_weak(new_node->next, new_node,
std::memory_order_release,
std::memory_order_relaxed));
}
std::shared_ptr<T> pop() {
Node* old_head = head.load(std::memory_order_relaxed);
while (old_head && !head.compare_exchange_weak(old_head, old_head->next,
std::memory_order_acquire,
std::memory_order_relaxed));
return old_head ? std::make_shared<T>(old_head->value) : nullptr;
}
private:
struct Node {
T value;
Node* next;
Node(const T& value) : value(value), next(nullptr) {}
};
std::atomic<Node*> head{nullptr};
};
420:デフォルトの名無しさん
23/03/18 00:31:48.86 jelBOeFa.net
先生にからかわれとるぞｗ
421:デフォルトの名無しさん
23/03/18 00:53:02.93 rMRLIFsD.net
>>419はこれと同じのをRustで書いたらunsafeになる(だろ?)
って言いたいんだろ
偉大なるChatGPT先生が言うんだから間違いないだろな
422:デフォルトの名無しさん
23/03/18 00:58:57.68 6kQD14Ek.net
>>421
いやChatGPTは信用しない方が良い
俺はRustは良く分からんがChatGPT曰く
>Rustには、このようなロックフリーなデータ構造を提供する
>クレート（ライブラリ）が存在します。その一つがcrossbeamです。
>このクレートは、スレッドセーフで効率的なデータ構造を提供しており、
>crossbeam内でUnsafeな操作が行われているにもかかわらず、
>APIを通じて安全に使用できます。
だそうな
crossbeamってRustで書かれとらんのかな?
423:デフォルトの名無しさん
23/03/18 01:14:24.86 pMxUNH+f.net
>>422
本当は、ライブラリの中だけをunsafeにして、アプリ側はsafeに出来るケースも有れば、
アプリ側も unsafe を消せないケースもありえる。
424:デフォルトの名無しさん
23/03/18 01:17:39.13 6kQD14Ek.net
unsafeってキーワード使えばチェックをオフにできるのね
425:デフォルトの名無しさん
23/03/18 01:29:02.55 6kQD14Ek.net
>>420
Rustで書いてみよう！
426:デフォルトの名無しさん
23/03/18 04:35:18.48 +IGrKU6n.net
ArcとAtomicでほぼそのまま書けるけど
pointer dereferenceのためにunsafeは必須
427:デフォルトの名無しさん
23/03/18 10:03:55.24 fNuha5Rk.net
言語マウントごっこにしか使われてないrust
428:デフォルトの名無しさん
23/03/18 10:25:46.77 fSPMk7mF.net
no chance
429:デフォルトの名無しさん
23/03/18 11:41:47.24 ux4diyjf.net
平日の昼にID真っ赤なのは仕事か
板違いのスレで必死に毎日お疲れさん
430:デフォルトの名無しさん
23/03/18 14:02:46.54 d2/CRNVk.net
ちょうどオライリーから「Rust Atomics and Locks」という本が出てるよ
基本的な内容を説明してる本なのでC++でatomicsやmemory orderingに慣れ親しんでる人がわざわざ買うほどのものではないかもしれないけど
かなりわかりやすくまとまってるのでRustでこの辺りの機能を使ったコードを良く書く人は読んで置いて損はないと思う
431:デフォルトの名無しさん
23/03/18 16:09:57.63 fSPMk7mF.net
ほう
URLﾘﾝｸ(bokuweb.github.io)
432:デフォルトの名無しさん
23/03/18 18:42:10.12 kFUsfJhu.net
Lock-Freeなデータ構造を自分で作りたい人はこれを見るといい
Porting Java's ConcurrentHashMap to Rust (part 1)
URLﾘﾝｸ(www.youtube.com)
433:デフォルトの名無しさん
23/03/19 12:22:41.89 LfQxDddq.net
> cargo new hoge
> cargo run
→ 3MB
main.rs に
use clap::Parser;
追加すると
> cargo run
→ 100MB 超えるんだが
どうすれば容量減らせるん？
434:デフォルトの名無しさん
23/03/19 12:44:51.20 TIfaDrwo.net
とりあえず--releaseつける
435:デフォルトの名無しさん
23/03/19 13:32:03.94 fPDrKYk/.net
しらんけど
URLﾘﾝｸ(igaguri.)<)
436:デフォルトの名無しさん
23/03/19 13:35:18.59 fPDrKYk/.net
とりあえずは
cargo clean
で良いはず
最初から余計なのは造りたくないって言う話ならほんまにしらん
437:デフォルトの名無しさん
23/03/19 14:03:33.37 4KWNgnTF.net
>>436
ありがとうございました
438:デフォルトの名無しさん
23/03/20 08:59:55.73 8VwEKWf+.net
やっぱC++にもボローチェッカ欲しい
なんならCにも欲しい
attributeとか併用したら、やってできないことはないんじゃねーの
439:デフォルトの名無しさん
23/03/21 17:20:17.93 icU0z8mb.net
rg3d はなぜ
URLﾘﾝｸ(github.com)
から
URLﾘﾝｸ(github.com)
に改名したのですか？
440:デフォルトの名無しさん
23/03/21 17:50:34.39 5MGYYNx+.net
rustの読み物公式が面白いのしっかり出してるから
それ読むだけでも大分良い
後発言語らしくイイトコどりしまくってる
null無くした代わりになんでもかんでもラップしてるから若干だるいけど
すげー面白い
441:デフォルトの名無しさん
23/03/21 19:41:09.03 4irMO5jk.net
Unity超えるゲームエンジン作ってから言え
442:デフォルトの名無しさん
23/03/21 19:42:14.14 4irMO5jk.net
Blenderとかでもいいよ
443:デフォルトの名無しさん
23/03/21 21:54:25.24 gItZ+a0F.net
cpp2rsみたいのがじきできるから、そしたら一発
ただ、それだと、safeではあるけど、Rustのシンプルさは(メリットとして)失うな
444:デフォルトの名無しさん
23/03/22 07:30:44.03 7nCtmzjD.net
>>443
ほんとにできる？
445:デフォルトの名無しさん
23/03/22 09:09:27.85 II3LrhVD.net
文法がRustなだけで
Rustのコードとして使い物にならん
ゲテモノが出て来るわ
今のGPTも酷い
446:デフォルトの名無しさん
23/03/22 09:47:28.48 RLKJ2atP.net
ああ、あと全自動とは言わない あっちこっちで、あれなおせーこれなおせーって言われるかと
447:デフォルトの名無しさん
23/03/22 10:40:01.19 Motackg9.net
たしかに、C++でメモリ安全性を静的チェックするツールを作るのはなかなか難しいもんかね？
448:デフォルトの名無しさん
23/03/22 12:19:59.74 jZlOcGNt.net
gccだとvargrindとかあるけどね
449:デフォルトの名無しさん
23/03/22 14:27:48.09 RqRpj7Ax.net
valgrindはgcc関係なくないか？
rustでもメモリリークの確認に使う
有用なツールだけど静的チェックと呼べるのかは疑問
450:デフォルトの名無しさん
23/03/22 21:31:28.83 vDLoPLCP.net
valgrindは実行時チェックだから出現レアケースだと時間内に検出できない
451:デフォルトの名無しさん
23/03/22 21:43:05.82 jZlOcGNt.net
AddressSanitizerでもValgrindでもmtraceでも好きなの選べ
URLﾘﾝｸ(kivantium.hateblo.jp)
452:デフォルトの名無しさん
23/03/22 21:46:10.74 vDLoPLCP.net
全て実行時チェックだな
453:デフォルトの名無しさん
23/03/22 21:54:30.07 jZlOcGNt.net
静的ツールだとこんなのもあるね
URLﾘﾝｸ(cppcheck.sourceforge.io)
スマートポインタ使えばそもそもいらんがね