Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust part8
https://mevius.5ch.net/test/read.cgi/tech/1579834072/

**デフォルトの名無しさん** · 2021/03/19(金) 01:48:07.52

この人何と戦ってるの

**デフォルトの名無しさん** · 2021/03/19(金) 02:08:13.91

日本語不自由なの多すぎか

**デフォルトの名無しさん** · 2021/03/19(金) 08:05:42.69

C++だって処理系によってABI違って互換性無いのになに寝ぼけた事言ってんだ状態

**デフォルトの名無しさん** · 2021/03/19(金) 08:22:46.12

ﾋｴｯ…日本語でどづぞ

>>877
処理系がABIを決めるケースはまれ
宇宙誕生以来一桁あるかどうか

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

メーリングリストでそれらを主張してみてはどうか？ここで言ってもrust下げとしか見られない

**デフォルトの名無しさん** · 2021/03/19(金) 10:06:03.26

さっぱりわかんねえんだが、
＞先頭部分は同じレイアウトであって欲しい、みたいな要請がある場合は
こんなクソみたいな要請がある案件の場合はrepr(c)でいいんちゃうん？

**デフォルトの名無しさん** · 2021/03/19(金) 10:57:59.03

ｽﾏﾝ>>878はstdcallを念頭に言ったがcdeclはC言語処理系によって決まったと言ってよいかもしれませんねーorz
stdcallの発祥がWindowsとPascalのどちらが先なのかは知りま栓、

>880
>こんなクソみたいな要請がある案件の場合はrepr(c)でいいんちゃうん？
禿げしく同意

**デフォルトの名無しさん** · 2021/03/19(金) 11:33:49.63

なにこいつ……

**デフォルトの名無しさん** · 2021/03/19(金) 14:44:53.99

>>871
言われてみれば確かに。
alignmentはCPUのBIT数が同じであれば大体同じなので、自動でやってくれもよい
場合も有るが、順序まで変えたのでは困るな。

**デフォルトの名無しさん** · 2021/03/19(金) 15:07:57.84

repr(C)をつけるのでは駄目な理由は誰も言えないのか

**デフォルトの名無しさん** · 2021/03/19(金) 15:11:24.58

おじいちゃんが今際の際に｢repr(C)は使うな…ｶﾞｸｯ｣って言ってたんよ…

**デフォルトの名無しさん** · 2021/03/19(金) 17:24:40.30

不満があっても使い続ける必要があるなら、
フォークしちゃえばいいじゃん。
もやもやしつつ使い続けるのは、良くないよ。

**デフォルトの名無しさん** · 2021/03/19(金) 17:49:26.38

C/C++をいまさらフォークしたところで誰も見向きもせず
個人で使うだけで消えていくだけだろうが
rustなら「おっ、おれもこういうのが欲しかった!」
ってやつがむらがってきてワンチャン有名なれる・・かも？

**デフォルトの名無しさん** · 2021/03/19(金) 18:09:28.62

ナイナイ(ヾﾉ・∀・｀)

**デフォルトの名無しさん** · 2021/03/19(金) 18:46:02.05

>>887
一貫性のあるc--ができたら可能性あるよ。

**デフォルトの名無しさん** · 2021/03/19(金) 19:57:51.38

>>885
同じおじいちゃんが原理主義者になるなってのも言ってただろうに。

**デフォルトの名無しさん** · 2021/03/19(金) 22:01:04.37

Cargo.tomlかなんかでデフォルトのreprを設定できればいいんすか？
俺は要らんけど

**デフォルトの名無しさん** · 2021/03/19(金) 23:27:54.25

repr(C)がついてないデータ型に警告出すようなlint書いてclippyにpullreq出せば良いのでは

**デフォルトの名無しさん** · 2021/03/20(土) 05:48:46.20

別に
構造体XのメモリレイアウトをRustのデフォルトとすべきなのかrepr(C)で扱ってほしいのか（あるいはその他か）は
構造体Xを定義したときに定義した人の意向で決まるから何の問題も無い
別の人が構造体Xを間違ったメモリレイアウトで解釈するプログラムを書く危険性は
（わざとそうするのでもない限り）無い

**デフォルトの名無しさん** · 2021/03/20(土) 05:53:57.90

、と思うんだけどrepr指定が異なる構造体はちゃんと別の型とみなされるの？
つまりrepr(C)のメモリレイアウトな構造体を、（例えば）repr(PACKED)なメモリレイアウトな構造体を引数にとる関数に
渡せてしまうとかあると悲劇なわけだが

Rust使ったことないからよくわからないので教えてくだちい、

**デフォルトの名無しさん** · 2021/03/20(土) 11:19:17.36

>>894
一つの型には一つしかrepr指定できないから指定を変えたければ別の型にするしかないよ
unsafeなtransmuteで強引に変換することは可能だけど、それは当然変換した人の責任

**デフォルトの名無しさん** · 2021/03/20(土) 11:59:39.96

>>874
組み込みの場合、rustのランタイムの大きさ考えたらその程度じゃ全然埋まらないんだが。。
結局まともなユースケースを考えてないんだろうね。

**デフォルトの名無しさん** · 2021/03/20(土) 12:09:06.74

Rustにランタイムなどないが

**デフォルトの名無しさん** · 2021/03/20(土) 12:20:42.44

実行ファイルの大きさの事かな？

**デフォルトの名無しさん** · 2021/03/20(土) 12:34:10.54

stdがでかいって話かな？
なんかそれも問題になって対応策はあった気がするけど

**デフォルトの名無しさん** · 2021/03/20(土) 12:46:24.31

デフォルトでは利便性やリンクの高速化のために大きくなってるけど
組み込み用途ならちゃんと最小化する方法はあるし
Cと同程度まで縮むよ

**デフォルトの名無しさん** · 2021/03/20(土) 13:08:56.08

>>896
下記の記事の Executable sizes の節で実行ファイルのサイズについてCとの比較を考察してた
サイズ削減する方法も書いてあったよ

https://kornel.ski/rust-c-speed

**デフォルトの名無しさん** · 2021/03/20(土) 13:44:30.39

ちょびっとだけどついにlinux-nextにrustで書かれたコードが入ったか

**デフォルトの名無しさん** · 2021/03/20(土) 15:24:30.80

>>896
組み込みデバイスでrustを使いやすくしようとしてるワーキンググループあるから
どういうところで不便に思っているのかコメント寄せてあげたら良いのでは
https://github.com/rust-embedded/wg
issueでコメント募集してるよ

**デフォルトの名無しさん** · 2021/03/21(日) 22:19:00.80

依存しているクレートが多いとビルドが長い、いい加減にしろ。なんじゃこりゃ

**デフォルトの名無しさん** · 2021/03/21(日) 22:47:11.34

>>901
だから考えてるスケールが全然違うっつーの

**デフォルトの名無しさん** · 2021/03/22(月) 01:13:43.80

具体的な話を出さないでキレられても困るよ

**デフォルトの名無しさん** · 2021/03/22(月) 01:39:21.20

Rust の実行ファイルが大きくなりがちなのは何でもかんでもスタティックリンクする文化であって、
そうしてでもうんざりするような (実行時の) 依存関係に悩まされたくないという話なので、
不要なもので肥大化しているわけじゃないよ。本来必要なものがあるだけ。

もちろん制約の大きい組み込み環境でごく基本的なライブラリすら制約してまで
大きさを削ったら使い勝手は悪いだろうけど、
それは Rust に限った話でもない当たり前のことだし。

メモリが数キロバイトとかいうレベルだったら (少なくとも現時点では) Rust が不向きというのはそうかもしれない。
そんで特に Rust を使いたいというケースでもない。

**デフォルトの名無しさん** · 2021/03/22(月) 02:21:57.65

>>906
具体的に言語化できる能力あったらこんなとこで愚痴垂れてないでしょう

**デフォルトの名無しさん** · 2021/03/22(月) 03:18:48.61

Linuxのディストロだとなるべくダイナミックリンクにするようにしてると思うんだけど
Rust製ツールとその方針の相性悪い気がする

**デフォルトの名無しさん** · 2021/03/22(月) 13:19:06.90

Q. Rustの倒し方を教えて下さい

A. まずデータセンターを燃やします

フランスのデータセンターで火災…『Rust』に復元不可能なデータロストが発生するなど大規模被害に発展 | エンタメウィーク
https://ent.smt.docomo.ne.jp/article/8989583

**デフォルトの名無しさん** · 2021/03/22(月) 14:05:31.64

Rustってなんか日本人的にわびさびっぽい名前でいいよな

**デフォルトの名無しさん** · 2021/03/22(月) 14:14:36.76

ググラビリティがGoより低いと思ってる元凶な

**デフォルトの名無しさん** · 2021/03/22(月) 14:52:55.38

そこんところは golang とか rustlang とか書く風習が出来てるから
たいした問題ではないんだが、 C のことを clang とか書き始めるやつが出てきてクソッタレという感じ。
よそでどんな習慣が出来てもいいけど変な汚染するなよな～～という。

**デフォルトの名無しさん** · 2021/03/22(月) 16:00:21.60

LLVM ClangはふつうClangて書かない？

**デフォルトの名無しさん** · 2021/03/22(月) 16:55:21.38

Clang は Clang のことなので
C のことを Clang っていわれると困るって話

**デフォルトの名無しさん** · 2021/03/22(月) 17:14:35.17

あ,なる.

**デフォルトの名無しさん** · 2021/03/22(月) 18:00:28.80

>>909
というよりその方針だとsoのバージョン非互換で問題が起きて大変なので
GoやRustなど最近の言語はダイナミックリンクを避けている。

**デフォルトの名無しさん** · 2021/03/22(月) 18:02:24.77

GCCもClangだし

**デフォルトの名無しさん** · 2021/03/22(月) 20:15:31.61

>>917
ディストロがビルドして配るバイナリの話だからバージョン非互換は関係ないのでは
非互換が問題になるならソースにパッチ当てられる訳だし
goも同じ問題があるというのはそうだけど

**デフォルトの名無しさん** · 2021/03/22(月) 21:30:42.61

>>919
そもそも最近はディストロのパッケージ管理システムに乗りたくなくなっているのでは？いろいろなディストロのいろいろなバージョンに対してバイナリを提供すること自体が大変で。
Gentooやってると依存関係ミスっててコンパイルこけるとかよくある。
（そういう意味でもGoやRustはかなりコンパイルに失敗しづらくて安心感はある）
退化している感もあるけど、GitHubで全ディストロ対応のシングルバイナリ配るのが結局楽だった、という感じなのかも。

**デフォルトの名無しさん** · 2021/03/22(月) 22:38:58.65

>>918
え？

**デフォルトの名無しさん** · 2021/03/22(月) 22:40:19.34

場合によっては違うバージョンのライブラリが共存することもあるし
ファイル名のルールでどうにかしたりはすごく面倒

近頃はコンテナにまるごと突っ込むとか言った解決法も取れるが、
それなら全部スタティックリンクしたらええやんというのは
順当な方針だよな

**デフォルトの名無しさん** · 2021/03/22(月) 22:41:18.91

パッケージのバージョン管理とかRustは最近のnpmばりによくできてるんじゃないの
知らんけど

**デフォルトの名無しさん** · 2021/03/22(月) 22:42:28.95

>>921
gcc コマンドの実態が clang の環境が
存在するのでそれを茶化したジョークだと思う

**デフォルトの名無しさん** · 2021/03/22(月) 23:22:40.71

Ruby, Python, Rとか言語独自のパッケージ管理システムもありつつ
同時にディストロのパッケージ管理システムにも有名ライブラリだけは乗ってたりして
なんか二重管理みたいな変な事になってる

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/23(火) 01:05:05.52

開発環境が用意するパッケージ管理は開発環境の管理だし
ディストリビューションの管理は実行環境の管理なんだけど、
ライブラリが実行環境なのか開発環境なのかは不可分な部分もあって単純に二分できんのよ。

C/C++ のライブラリのパッケージ管理が発展してないのは伝統的に
ディストリビューションのパッケージ管理に全力で乗っかる文化があったからで、
モダンな開発環境は分けようとしてかえってややこしくしているような気もする。
元々あった問題があぶりだされただけかもしれんけど。

**デフォルトの名無しさん** · 2021/03/23(火) 01:20:30.89

まあlibcのバージョン違いで困った経験あると、スタティックリンクはやむ無しって思うけど。

**デフォルトの名無しさん** · 2021/03/23(火) 02:36:10.01

>>913
コンパイラをclangという名前にしてしまったAppleが馬鹿なだけ。
ライバルにMSのcl.exeというものが30年ほど前からあるだけでも
ややこしいのに。

**デフォルトの名無しさん** · 2021/03/23(火) 09:53:23.27

>>926
C/C++全盛の頃はコードを書く人と使う人が一致してることが多かったから問題なかった気がする。
自分の環境さえ正しくセットアップすればそれで問題ないという。
今みたいにGitHubでコード共有するのが当然って世界だと違う環境でビルドするのが困難ってのはきつい。
OSSのC++ライブラリを使おうとしたときに、作者と違うディストリビューション使ってる場合、ほぼ確実になんらかのトラブルにはまる印象だなぁ。

**デフォルトの名無しさん** · 2021/03/23(火) 12:53:42.65

てか低レイヤー依存のパッケージは言語パッケージ管理じゃ扱いづらいだろ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/23(火) 15:23:13.29

>>928
自分の開発環境に cl.exe があるのを見つけて
「あれ？ Common Lisp なんか入れたっけ？」って思ったことがある。

**デフォルトの名無しさん** · 2021/03/23(火) 16:03:34.41

Rustと関係ない雑談はそろそろよそでやって下さいね

**デフォルトの名無しさん** · 2021/03/23(火) 16:25:13.28

次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/

あっちのスレの流れの中に投下するものがこっちに誤爆して話題が続いてるだけだぞ

◆QZaw55cn4c · 2021/03/23(火) 20:22:26.82

>>918
？？？

**デフォルトの名無しさん** · 2021/03/23(火) 22:26:53.30

>>934
>>924

**デフォルトの名無しさん** · 2021/03/26(金) 17:08:58.51

Rust 1.51 replaced
https://mag.osdn.jp/21/03/27/103000

**デフォルトの名無しさん** · 2021/03/26(金) 17:18:42.33

X replaced
O released

**デフォルトの名無しさん** · 2021/03/26(金) 17:25:28.62

親善試合のプレー中でもないのにパンチを繰り出し、歯を折る韓国人の本質

**デフォルトの名無しさん** · 2021/03/28(日) 01:28:47.05

>>905
こういうのはどう？
https://www.infoq.com/jp/news/2020/05/zz-formal-verified-c-dialect/

**デフォルトの名無しさん** · 2021/03/28(日) 01:44:52.75

>>939
証明論関係はプロトコル検証なんかには使えるかもね。

**デフォルトの名無しさん** · 2021/03/28(日) 12:03:39.58

PDA以上の機械はどうやって機械的に証明したらいいんじゃ……

**デフォルトの名無しさん** · 2021/03/30(火) 10:38:53.80

>>2
日本語版ねーの？

**デフォルトの名無しさん** · 2021/03/30(火) 12:16:47.56

>>942
https://doc.rust-jp.rs/

**デフォルトの名無しさん** · 2021/03/31(水) 07:40:52.59

なんなのこのゴミ言語

早く消えろよゴミ

**デフォルトの名無しさん** · 2021/03/31(水) 07:59:36.54

使わなきゃいいだけだろ？

**デフォルトの名無しさん** · 2021/03/31(水) 15:12:27.84

やってることはアフィカスと同じクズ言語

**デフォルトの名無しさん** · 2021/03/31(水) 15:45:22.05

ZDNet Japan: トーバルズ氏が考える、LinuxにおけるRustの居場所とは.
https://japan.zdnet.com/article/35168533/

**デフォルトの名無しさん** · 2021/03/31(水) 17:49:52.55

git も浪費が激しいゴミ

**デフォルトの名無しさん** · 2021/03/31(水) 22:41:28.27

>要するに、Linuxの記述言語がCからRustへと変わる日は当面の間やってこないだろう。その一方で、Rustベースのプログラムやドライバーをユーザー空間で実行するということに対する関心は高く、それに向けた動きは数多くあるため、いつの日にかLinuxというOSでRustベースのカーネルが採用されるだろう。
まあ当たり前の結論だわな。

**デフォルトの名無しさん** · 2021/04/01(木) 09:50:04.35

Javaやpythonのようなバブルは無いだろうが一定の需要はあるだろう

**デフォルトの名無しさん** · 2021/04/01(木) 10:21:51.12

競技プログラミング分野で謎の注目を集めてるよRust
短時間とか早解きが重要なコンテストでは雑に書けないので使いづらいが、長期間のコンテストでは重宝されてる
強い人たちが使ってるのもあって

**デフォルトの名無しさん** · 2021/04/01(木) 10:53:00.87

AndroidのBluetoothスタックがRustで書き直されたっぽい
https://android.googlesource.com/platform/system/bt/+/master/gd/rust/

Hacker NewsでAndroidのBluetoothの接続性やバグの多さが叩かれまくってて笑った
https://news.ycombinator.com/item?id=26647981

**デフォルトの名無しさん** · 2021/04/01(木) 11:55:32.05

まあ９割は単なるファッションだろ。
実際使ってみるとc++で気をつけるのとほぼ変わらんしそれができる輩しかまともに使いこなせん。

**デフォルトの名無しさん** · 2021/04/01(木) 12:46:37.61

そもそもデバドラならC++でもいいんちゃうん？
Linusが問答無用で許さない感じ？

**デフォルトの名無しさん** · 2021/04/01(木) 13:00:07.82

>>954
昔LinusはC++をボロクソに言ってた。特に例外周りがカーネルとは合わないとかだったかな。
今の改心したLinusなら違うかもしれないが。

**デフォルトの名無しさん** · 2021/04/01(木) 13:04:33.77

C++は罵詈雑言で二度とそんなこと言うな
ぐらいで叩いてた

**デフォルトの名無しさん** · 2021/04/01(木) 13:36:29.59

思いっきり皮肉だけど｢C++独自の機能を使わないならC++でも構わない｣みたいなこと言ってなかったっけ

**デフォルトの名無しさん** · 2021/04/01(木) 13:53:28.54

オブジェクト指向はクソみたいなのも言ってた気がするし、
当時Linusが文句言ってたポイントをRustはうまく回避してるかも。

**デフォルトの名無しさん** · 2021/04/01(木) 14:57:07.23

linusはオブジェクト指向はファイルシステム周りでは有効って昔から言ってる。
流石にこの辺りの感覚は鋭いわ。

**デフォルトの名無しさん** · 2021/04/01(木) 15:03:37.19

あぁ確かにオブジェクト指向というよりC++のそれにまつわる機能がクソって話だったね。

**デフォルトの名無しさん** · 2021/04/01(木) 15:42:58.54

そうは言ってもリナス自身が言語処理系に手を出す事は無いんだろうな

**デフォルトの名無しさん** · 2021/04/01(木) 15:48:42.19

>https://japan.zdnet.com/article/35168533/
これも年取ったからだいぶ穏やかに答えてるけど内心は
「とりあえずデバイスドライバーで実装してみろやwやれるもんならなw」って感じだと思うぞ。

**デフォルトの名無しさん** · 2021/04/01(木) 16:12:38.28

>>962
さすかに読み方ひねくれすぎ

**デフォルトの名無しさん** · 2021/04/01(木) 19:45:16.51

>>955
https://tabesugi.net/memo/2009/1a.html
Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST)
Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org>

C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

**デフォルトの名無しさん** · 2021/04/01(木) 19:48:28.85

>>956
＞C++は罵詈雑言で二度とそんなこと言うな
＞ぐらいで叩いてた

>>964
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

◆QZaw55cn4c · 2021/04/01(木) 19:49:27.24

>>957
＞思いっきり皮肉だけど｢C++独自の機能を使わないならC++でも構わない｣みたいなこと言ってなかったっけ

>>964
＞唯一まともで、効率がよくて、システムレベルで使えて、移植性があるC++ ってのは、基本的に C で使える機能だけに限ったときなんだ。

◆QZaw55cn4c · 2021/04/01(木) 19:50:55.20

>>958
＞オブジェクト指向はクソみたいなのも言ってた気がするし、

>>964
＞C だけに限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
＞ついでに沢山のプログラマが実際に低水準の問題を理解することができて、
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
＞アホらしい「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

**デフォルトの名無しさん** · 2021/04/01(木) 20:34:15.03

しかしこの話ももう15年近く前だし、C++20についてどう思ってるのかは気になるな。
相変わらずボロクソなのか、もう少し丸くなってるのか。

**デフォルトの名無しさん** · 2021/04/01(木) 20:47:29.36

>>963
残念ながらlinusは俺の１０倍はひねくれてるよ

**デフォルトの名無しさん** · 2021/04/01(木) 20:49:11.47

色々な言語を扱ってみればどんな言語でも"トンでもなく悪い設計の元になりうる"のは
Linusも気がついてるんだろうが、こういう手合いは
単に自分の好みで気にいらない事を否定するのに「一般的に良くないものだ」という
主張を持ちだすから始末がわるい
またこの手の攻撃的な人物は自分の周囲の人間が一般的であると思い込む傾向もあり
たしかにLinuxとオープンソース界隈の人間がC++を使いまくると"トンでもなく悪い設計"に
なりやすいだろうなというのもわかる(そういう界隈の人間は基本的に自由であり
自由にできる幅があるときは自分の思いついた"カッコイイやりかた"をすぐ人におしつけたがる)

**デフォルトの名無しさん** · 2021/04/01(木) 21:18:43.80

C++ネタになると書き込みするやつが急に増えるんだからwww
いい加減C++スレでやってね

**デフォルトの名無しさん** · 2021/04/02(金) 02:22:20.02

C++に勝てるっていう宣伝文句に惹かれて興味を持った人が多いのだから、本当にC++より良いのかっていうところに焦点が当たるのは宿命

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/02(金) 02:45:25.02

>>953
C++ の仕様に違反せずに書くために「気を付ける」程度で本当に足りるのか？
足りないからそこそこの規模のプロジェクトになったら valgrind とかのツールを導入するはめになるんだろ。
十分に知識を持っていても隅から隅まで 100% に配慮するのは無理ってのがわかってるから、
C++ で気を付けるのとほぼ変わらんなら Rust を導入する意義はある。

**デフォルトの名無しさん** · 2021/04/02(金) 07:23:26.60

規模が大きくなって関わる人数も増えれば気を付けるのもかなりのストレスだしなあ