結局C++とRustってどっちが良いの？ 7traits

**デフォルトの名無しさん** · 2023/08/31(木) 12:16:53.23

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 6traits
http://mevius.5ch.net/test/read.cgi/tech/1690610746/

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/08/31(木) 13:29:13.22

>>12
>簡単で自明なデッドロックのよくある例が検出できただけであれは学習マッチングだよ
>実用的じゃない
そうなのかどうかは私も分からんので反例を1つ示して反駁してくれ

>理論的にデッドロックの静的な検出は不可能なのは知っているよね？
人間はできるよね? <- 反例

**デフォルトの名無しさん** · 2023/08/31(木) 13:34:06.16

>>13
人間にもデッドロックの静的な検出はできません
そのため実行時のデッドロック検出ツールが使われています
この分野はGPTにも無理です

**デフォルトの名無しさん** · 2023/08/31(木) 13:39:30.11

>>14
>人間にもデッドロックの静的な検出はできません
お前はソース見てもデッドロックをデバッグできないんだなw
「静的な検出」に限定する必要はないのだよ

**デフォルトの名無しさん** · 2023/08/31(木) 13:41:32.63

>>9
むしろGPT支援でRustが有利になった
GPT自体は安全性の保証をできなくて間違いも犯すけど
GPTへRustコンパイラを通すように指示すればRustコンパイラにより必ず安全性が保証される

**デフォルトの名無しさん** · 2023/08/31(木) 13:48:22.11

まだ読んでない人もついてこれるように
>>12が学習マッチングと言ってるのは前スレの>>289だよ
http://mevius.5ch.net/test/read.cgi/tech/1690610746/
確かに検証したソースはシンプルで
1. ソースの規模が大きくなるとこれは検出できなくなるのか?
2. もしできなくなるとしたらどのくらいの大きさが限界なのか?
3. あるとしてその限界は実用的なのか?
など謎が多く興味深い

**デフォルトの名無しさん** · 2023/08/31(木) 13:49:39.59

>>15
デッドロックは簡単なものを除いて見つけるのが極めて難しくて
コードを解析してもデッドロックを見つけることは無理だと証明されてる分野
そのため検出デバッグコード入りでデッドロックが起きるまで実行させて検出しているのが現状
だからGPTも同じように長期間実行させないとデッドロックを見つけられない

デッドロックはロックの順序さえ決めて守れば発生しないので
ほとんどのプログラムはそうすることでデッドロックを回避してる

**デフォルトの名無しさん** · 2023/08/31(木) 13:51:16.54

>>18
反例出しなよ
1個だよ

**デフォルトの名無しさん** · 2023/08/31(木) 14:19:56.37

今度はデッドロックで埋まるのか

**デフォルトの名無しさん** · 2023/08/31(木) 14:36:00.57

デッドロック検出の現実的な需要がないので無意味だな
各ロックの依存関係が階層構造となるよう制限して設計すればデッドロックは絶対に発生しない
実用的なプログラムにおいてその制限はなんら支障をもたらさない
つまりその制限を課すだけでデッドロック問題は発生することなく終わる

**デフォルトの名無しさん** · 2023/08/31(木) 14:46:26.78

反例をあきらめたか
デッドロックの検出に限らず
GPTによるデバッガ（にも限らないが）の開発環境への統合は
今日のプログラミング言語に求められる要件を大きく変えるだろうね
Rustはこの先生きのこれるのだろうか?

**デフォルトの名無しさん** · 2023/08/31(木) 14:56:20.19

GPTのおかげでRustだけが有利になってしまった
ミスもするが命令すれば何度でもやり直すGPT
必ず安全なコードのみを通すRustコンパイラ
この二つを組み合わせると必ず安全なコードを生成できる

**デフォルトの名無しさん** · 2023/08/31(木) 15:15:28.97

そういう異世界が有っても良いとは思うが
こっちの世界はそうじゃないしならなくても良いわ

**デフォルトの名無しさん** · 2023/08/31(木) 15:19:12.60

＞989
C++でもRustでも所有権を持つものがいなくなった時に自動的に解放される仕組み
所有権は移動(ムーブ)できるがC言語から所有権は当然やって来ない
だからCで確保したメモリがC++やRustで自動的に解放される危険はない

**デフォルトの名無しさん** · 2023/08/31(木) 15:36:45.71

ひさしぶりにこのスレ見にきて
>>1 に完璧な結論が書いてあって吹いた

**デフォルトの名無しさん** · 2023/08/31(木) 16:26:48.65

>>1
「Aに固執するのは老害、柔軟な若者はBを好む」などという
説はよくあるが、後者は、別の新製品が出てくれば、そっちに
移るので定着しないと言われている。なので、ターゲット層
としては気をつける必要があるとされる。

**デフォルトの名無しさん** · 2023/08/31(木) 16:36:45.32

>>7
>しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。

Rustについても十分な知識なんて持っておらず
自信満々に間違ったこと書くから注意してね

**デフォルトの名無しさん** · 2023/08/31(木) 18:13:47.28

>>23
結局カットオフがあるんでアップデート後の内容に対応できてないように見えるけど。

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

>>5
仕上げられる人間はそんなまどろこしいことしないよ
それにaiが劣化した途端詰みですね

**デフォルトの名無しさん** · 2023/08/31(木) 18:40:59.47

GPTにはコード生成だの検証だのくだらんことやらせてないで証明を生成させていけッ
ttps://leandojo.org/

**デフォルトの名無しさん** · 2023/09/01(金) 11:21:35.62

>>27
一理あるな
Nim やめて Codon とか
Rust やめて Mojo とか
言い始めてるし
https://twitter.com/Comamoca_/status/1669992610738634752
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2023/09/01(金) 11:30:00.17

こんなツボ外し記事もある
https://kinsta.com/jp/blog/rust-vs-python/

**デフォルトの名無しさん** · 2023/09/01(金) 11:39:10.28

こっちの方がはるかにマシ
https://qiita.com/kenmaro/items/676139f04adb183037a9

**デフォルトの名無しさん** · 2023/09/01(金) 12:19:56.36

QiitaとNimスレで話題に上がっていたダブル再帰フィボナッチなんだけど
ちょといじったらNimでRustの700倍速出た、もちろんチートなしで

**デフォルトの名無しさん** · 2023/09/01(金) 12:35:29.32

700倍も差が出れば簡単に原因わかるよね？

**デフォルトの名無しさん** · 2023/09/01(金) 12:59:23.02

知らんけどgccとの相性が良いと言う話になっている、俺はwandbox回しただけだから

**デフォルトの名無しさん** · 2023/09/01(金) 13:02:56.23

wandboxさらそうかと思って保存したけど
知恵付けさせたくないから自分でやれる人だけやれば良いよ

**デフォルトの名無しさん** · 2023/09/01(金) 13:14:13.41

チップベンダが提供するライブラリを使うのがだいたいさいつよ
…といいつつ、一度は・多少は、自分でやってみるのは基礎力が付く
ライブラリをおかしな風に呼ぶ・まわすことが減ると思う

そういや、OneAPIの近々の更新で、iccの同梱提供やめるっていってるから、
プロプラのコンパイラもひとつ押さえとくか…って思ってる人は、オフラインインストーラ取りに行っておくといいぞ
icc系やめて、dpcpp系に収束するとかだったと思う

ガセだったらごめそ「登録を飛ばしてDL」ってのちゃんとあるからゆるしてちょ

**デフォルトの名無しさん** · 2023/09/01(金) 13:48:11.87

>>35
両方のコードウpキボン

**デフォルトの名無しさん** · 2023/09/01(金) 14:00:07.92

zig も良いな
https://www.youtube.com/watch?v=kRrxbRLWsBo

**デフォルトの名無しさん** · 2023/09/01(金) 14:02:01.75

>>40
ソース貼らない貼らない連呼する香具師がうるさいスレ
>>35 の理由は >>38 に描いてある

**デフォルトの名無しさん** · 2023/09/01(金) 16:50:34.24

>>42
計算した項のオーダーは？

**デフォルトの名無しさん** · 2023/09/01(金) 17:05:44.06

フィボナッチはヤツの縄張りだからな
ここで喧嘩を売ると何かと面倒だ

**デフォルトの名無しさん** · 2023/09/01(金) 17:24:24.66

wandboxでやったら>>32のcodonのZenn記事は3年以上古いgcc使っているっぽい

g++ 14.0.0 (HEAD)
ackermann(3, 11) = 16381
elapsed time: 57 [ms]

g++ 9.3.0 (March 12, 2020)
ackermann(3, 11) = 16381
elapsed time: 134 [ms]

clang++ 18.0.0 (HEAD)
ackermann(3, 11) = 16381
elapsed time: 156 [ms]

**デフォルトの名無しさん** · 2023/09/01(金) 17:31:47.41

>>45
3, 11はコマンドライン引数にしてある

>>43
>>35-37だけど42は別人だ
44
不便すまない、詳細は元のQiita記事かレスをたどってくれ

**デフォルトの名無しさん** · 2023/09/01(金) 17:36:10.48

>>35
タイムを一応書いておく
Rustのwandboxが見当たらないからclang比較で1.6秒として
改良Nimは0.0022~0.0023秒が出たので700倍

**デフォルトの名無しさん** · 2023/09/01(金) 17:41:20.75

数倍の差ならともかく700倍ともなるとネイティブ同士の言語で発生する差じゃないからな
コードがまともじゃないか比較方法がまともじゃないのは明らか
いちいち中身を見る必要もない

**デフォルトの名無しさん** · 2023/09/01(金) 17:54:14.28

>>48
来ると思った
だから改良Nimのwandbox貼るのやめた

**デフォルトの名無しさん** · 2023/09/01(金) 18:37:56.38

フィボナッチ全盛期の荒れようでも貼っとくか
https://mevius.5ch.net/test/read.cgi/tech/1652347700/

**デフォルトの名無しさん** · 2023/09/01(金) 18:41:52.45

おじさんが出没してた過去スレって
C++ vs Rust
ワッチョイなしのほうの次世代言語スレ
ワッチョイなし時代のC++相談室
あと何があったっけ

**デフォルトの名無しさん** · 2023/09/01(金) 18:42:24.54

＞C(gcc)よりNimが3倍も速い

Nimがおかしい

**デフォルトの名無しさん** · 2023/09/01(金) 18:56:13.90

そうやな
るstより早いはともかくcより3倍早いはなんかインチキはいってるくさい

**デフォルトの名無しさん** · 2023/09/01(金) 20:48:12.17

Nimすげーな。
最新の情報科学を総力して作られたNimだから
Rustより700倍、Cより3倍も速く出来たんだろ。
で、10年後にはさらにすごい言語が出ているんだろうが

**デフォルトの名無しさん** · 2023/09/01(金) 21:00:39.20

アルゴリズムまで最適化するんだろうか？

**デフォルトの名無しさん** · 2023/09/01(金) 21:03:10.49

Nim「なんじゃこのトロくさいコード？こうした方が何倍も早いと分からん？手間かけさせやがって」

**デフォルトの名無しさん** · 2023/09/01(金) 21:04:42.86

コードを見ないとなんとも言えんが、Nimの方はループにでも展開したんじゃない？
cは最適化無しとか。

**デフォルトの名無しさん** · 2023/09/01(金) 21:05:59.18

nimが吐いたcのコード見ればわかる

**デフォルトの名無しさん** · 2023/09/01(金) 21:20:44.34

>>58
人間が理解できないすごいコードを吐き出しているんじゃないのか

**デフォルトの名無しさん** · 2023/09/01(金) 22:00:52.55

そんなに癖が強いのか

**デフォルトの名無しさん** · 2023/09/02(土) 05:51:36.66

トランスパイラが、想定以上に事前計算を進めちゃうんじゃないかｗ

**デフォルトの名無しさん** · 2023/09/02(土) 06:06:22.50

まともなベンチマークでは静的な事前計算ができないようにする
だからそんなことは起きない

**デフォルトの名無しさん** · 2023/09/02(土) 09:44:56.85

=T=i=k=T=o=k（←迷惑でしたらこちらをNGしてください。）

更にご家族にも紹介して、追加で￥3500を入手できる
https://i.imgur.com/EIoUA4P.jpg

**デフォルトの名無しさん** · 2023/09/02(土) 11:03:33.99

>>63
もう現金化してアンインスコしてる。

**デフォルトの名無しさん** · 2023/09/02(土) 21:58:35.01

>>35
C/gccのダブル再帰の最適化本気スイッチの入れ方わかった
全てローカル、(Cは)C++chrono計測、Nimはcputicks

ダブル再帰最適化本気スイッチ版C
C/gcc
Time= 1.176ms fib_c_trigger(44)= 701408733
Time= 1.782ms fib_c_trigger(45)= 1134903170
Time= 2.424ms fib_c_trigger(46)= 1836311903
Time= 3.090ms fib_c_trigger(47)= 2971215073
Time= 3.873ms fib_c_trigger(48)= 4807526976
Time= 5.365ms fib_c_trigger(49)= 7778742049
Time= 7.337ms fib_c_trigger(50)= 12586269025
Time= 10.149ms fib_c_trigger(51)= 20365011074
Time= 13.961ms fib_c_trigger(52)= 32951280099
Time= 18.983ms fib_c_trigger(53)= 53316291173
Time= 26.660ms fib_c_trigger(54)= 86267571272
Time= 36.483ms fib_c_trigger(55)=139583862445
Time= 50.876ms fib_c_trigger(56)=225851433717
Time= 70.201ms fib_c_trigger(57)=365435296162

**デフォルトの名無しさん** · 2023/09/02(土) 22:00:43.37

本気スイッチ版Cは不自然な書き方になるが再帰コール二つはループ化したりしていなくて
gccの何かの最適化が本気モードになる

改良Nim
Nimはキレイなシンプル再帰のままでここまで出る
Nim/gcc
Time= 1.368ms fib_nim(44)= 701408733
Time= 1.634ms fib_nim(45)= 1134903170
Time= 2.255ms fib_nim(46)= 1836311903
Time= 3.121ms fib_nim(47)= 2971215073
Time= 4.261ms fib_nim(48)= 4807526976
Time= 5.989ms fib_nim(49)= 7778742049
Time= 8.224ms fib_nim(50)= 12586269025
Time= 11.304ms fib_nim(51)= 20365011074
Time= 15.644ms fib_nim(52)= 32951280099
Time= 22.103ms fib_nim(53)= 53316291173
Time= 31.147ms fib_nim(54)= 86267571272
Time= 41.306ms fib_nim(55)=139583862445
Time= 58.134ms fib_nim(56)=225851433717
Time= 78.528ms fib_nim(57)=365435296162

**デフォルトの名無しさん** · 2023/09/02(土) 22:02:10.21

本気スイッチ版Cでもclangでは遅いまま

C/clang
Time=1438.212ms fib_c_trigger(44)= 701408733
Time=2310.675ms fib_c_trigger(45)= 1134903170
Time=3746.923ms fib_c_trigger(46)= 1836311903
Time=6040.876ms fib_c_trigger(47)= 2971215073
Time=9779.249ms fib_c_trigger(48)= 4807526976
Time=15877.302ms fib_c_trigger(49)= 7778742049
Time=26151.375ms fib_c_trigger(50)= 12586269025
Time=42241.553ms fib_c_trigger(51)= 20365011074
Time=67936.930ms fib_c_trigger(52)= 32951280099
Time=110828.012ms fib_c_trigger(53)= 53316291173
Time=176305.471ms fib_c_trigger(54)= 86267571272
SIGINT: Interrupted by Ctrl-C.
推定
55 --> 287秒
56 --> 463秒
57 --> 750秒

**デフォルトの名無しさん** · 2023/09/02(土) 22:03:36.41

シンプル再帰版 C/gcc
Time= 625.499ms fib_c_simple(44)= 701408733
Time= 995.294ms fib_c_simple(45)= 1134903170
Time=1568.026ms fib_c_simple(46)= 1836311903
Time=2497.401ms fib_c_simple(47)= 2971215073
Time=4059.698ms fib_c_simple(48)= 4807526976
Time=6563.932ms fib_c_simple(49)= 7778742049
Time=10696.766ms fib_c_simple(50)= 12586269025
Time=18117.324ms fib_c_simple(51)= 20365011074
Time=30850.988ms fib_c_simple(52)= 32951280099
SIGINT: Interrupted by Ctrl-C.

シンプル再帰版 C/Clang
Time=1556.296ms fib_c_simple(44)= 701408733
Time=2491.174ms fib_c_simple(45)= 1134903170
Time=4019.549ms fib_c_simple(46)= 1836311903
Time=6543.637ms fib_c_simple(47)= 2971215073
Time=10584.639ms fib_c_simple(48)= 4807526976
Time=17254.294ms fib_c_simple(49)= 7778742049
Time=27799.040ms fib_c_simple(50)= 12586269025
Time=45090.030ms fib_c_simple(51)= 20365011074
Time=73155.917ms fib_c_simple(52)= 32951280099
SIGINT: Interrupted by Ctrl-C.

nim 2.0.0
gcc 13.2.0
clang 16.0.5

**デフォルトの名無しさん** · 2023/09/02(土) 23:49:38.43

コードも出ず一般的な副作用のある問題への適用可能性もわからないが
速度が必要なところでは始めからループを使い再帰は通常使われない
今回のような問題ならメモ化の方が高速化に対して効果的
さらにフィボナッチ漸化式の場合はそのまま二つ分のみのメモ化としレジスタ(ローカル変数)で演算していくようにプログラミングするのが常識

**デフォルトの名無しさん** · 2023/09/03(日) 01:40:05.47

>>69
それ今回の目的と手段が逆じゃね？
今回のは、より高速なフィボナッチが目的じゃなく、速度計測の一つの手段として再帰のフィボナッチを使ってるんじゃね？

**デフォルトの名無しさん** · 2023/09/03(日) 02:08:27.39

言語の速度計測でフィボナッチを使うのは無意味となるためやるべきでない

ダブル再帰の計算量O(1.6^n)をどこまでアルゴリズム変換して計算量をどこまで減らせるかは言語の優劣と関係ない
フィボナッチの場合は究極的にO(n)にすることもできるが汎用的ではなくこれを言語が頑張っても意味がない
>>66もまだO(n)になっておらずさらなる改善の余地が大いにあるが仮にその対応をしてもその言語が速いことにならない

計算量を激減可能なアルゴリズムで言語間の速度を計測しても意味がない

**デフォルトの名無しさん** · 2023/09/03(日) 02:23:40.00

じゃあお前はこの話についてこなくていいよ

**デフォルトの名無しさん** · 2023/09/03(日) 02:32:28.82

5ch は中毒性あるからホドホドにね

**デフォルトの名無しさん** · 2023/09/03(日) 02:35:49.88

NimがCの3倍速いという話はそういうことだったのか
まともなベンチだとNimは遅くてNimを使う意義ないもんな

**デフォルトの名無しさん** · 2023/09/03(日) 08:30:48.70

違うアルゴリズムで組んで速度比較したって事？

**デフォルトの名無しさん** · 2023/09/03(日) 09:13:46.86

再帰とかじゃなくてコンパイラとかリンカとかの実用的なプログラムで同じロジックでコード書いたときに、CよりNimの方が最適化すごかったりするの？

仮にそうなら競プロでなんでnimがもっと流行らないんだろう

**デフォルトの名無しさん** · 2023/09/03(日) 09:28:46.76

>>75
逆にそれ以外で700倍の差をつける方法あるのか？

**デフォルトの名無しさん** · 2023/09/03(日) 09:32:31.02

実用的なプログラムではNimが遅い

**デフォルトの名無しさん** · 2023/09/03(日) 09:35:19.44

違うアルゴリズムで比較とかあまりにも想像絶する

**デフォルトの名無しさん** · 2023/09/03(日) 09:44:59.77

コンパイル時にほとんどを解決してたってこと？

**デフォルトの名無しさん** · 2023/09/03(日) 11:51:45.92

結局この種の速度なんてメモリに触る部分をどれくらいカスタマイズできるか、しなきゃならんかって
話なわけで、
その辺いじってないバカほどベンチガーになる。

**デフォルトの名無しさん** · 2023/09/03(日) 13:07:12.78

フィボナッチなんてキャッシュすると(メモリ触れば触るほど)速くなるだろ

**デフォルトの名無しさん** · 2023/09/03(日) 13:20:45.65

>>82
それは遅くなる
f(n)の計算のためにf(0)からf(n-1)までn個のメモリをメモ化で使うのと
nを順に大きくして行きメモ化は常にf(n-1)とf(n-2)の2個のみのメモリ(レジスタも可)を使うのと
どちらが速いと思う？

**デフォルトの名無しさん** · 2023/09/03(日) 13:46:53.98

nはランダムに指定するんじゃなくて必ず順に取り出すルール？
そんなの使い物にならんで

**デフォルトの名無しさん** · 2023/09/03(日) 13:59:25.38

当然nはランダムに一つのみ指定される

**デフォルトの名無しさん** · 2023/09/03(日) 15:10:52.83

まーた複オジが壮大な勘違いをして頓珍漢な自説唱えてるよw

**デフォルトの名無しさん** · 2023/09/03(日) 16:55:12.08

問題を勝手に決めて自分に都合の良い解釈だけで突っ走る人だから議論が成立しないよね

**デフォルトの名無しさん** · 2023/09/03(日) 18:15:12.53

Rustの悪口は許せないんだろうな

**デフォルトの名無しさん** · 2023/09/03(日) 18:41:52.70

今回のはRustと全然関係ないような

**デフォルトの名無しさん** · 2023/09/03(日) 19:09:26.28

>>84
元記事でもこのスレでもnはランダムでもなんでも関数に渡ってくる引数だよ
そのフィボナッチ計算のアルゴリズムは最適化できれば自由で途中の計算のメモ化もアルゴリズムの範疇で自由だよ
ただし関数だから以前に呼ばれた時の計算結果のメモ利用だけはダメ
それを許したらconstexprでメモつくっておいて即答になり計算測定の意味なくなるからね

**デフォルトの名無しさん** · 2023/09/03(日) 20:45:15.50

>>35だけど
メモ化とかしていない
asmレベルは知らないけど増加度を見れは推測はつく

**デフォルトの名無しさん** · 2023/09/03(日) 20:53:12.27

煽れば情報が出てくると思っている輩が多いな

>>90
実際に試したのかどうかまでは読み取れないけど、記事は見たようで何より

**デフォルトの名無しさん** · 2023/09/03(日) 20:58:09.55

軽く煽った後は、本業に戻る、だよ急がないし

**デフォルトの名無しさん** · 2023/09/03(日) 22:52:15.27

>>89
Rustと関係ない話をしていても心は常にRustが憎いからさ

**デフォルトの名無しさん** · 2023/09/04(月) 07:41:36.53

>>83
>>85
IDかぶってんの？自演バレ？

**デフォルトの名無しさん** · 2023/09/04(月) 16:41:39.63

C言語の高速化のしやすさは半端じゃないな。ただ、Rustと違って時々メモリの解放忘れとかでやらかすのはあれだけだど。
gcc -O3 -march=nativeってすると爆速だもんな。Rustでこれに対応するのはあんのかな？cargo run --releaseでもgccの最適化に比べるとかなり物足りなく感じる。

**デフォルトの名無しさん** · 2023/09/04(月) 17:35:48.90

LLVMベースなんだから、そのうち同等か近いところまでくるでしょ

**デフォルトの名無しさん** · 2023/09/04(月) 18:26:01.51

Rustのsafeモードでは効率よく使えないアルゴリズム
がある。
また、その場合、関数の中にunsafeを閉じ込めることも
不可能であることが分かっている。
ここの人は馬鹿なので理解できないので説明しない。

**デフォルトの名無しさん** · 2023/09/04(月) 18:44:20.41

だめじゃん

**デフォルトの名無しさん** · 2023/09/04(月) 18:54:40.00

「safeモード」
この言葉だけで理解してないのが分かるよね

**デフォルトの名無しさん** · 2023/09/04(月) 19:05:16.04

他人の無能を強調するタイプのコミュニケーションやめたほうがいいよ

**デフォルトの名無しさん** · 2023/09/04(月) 19:14:49.30

>>98
いつもの嘘つき登場か

**デフォルトの名無しさん** · 2023/09/04(月) 20:11:29.90

>>98
ソースプリーズ
根拠がなきゃ他人は説得できない

**デフォルトの名無しさん** · 2023/09/05(火) 00:55:10.57

俺は趣味だからC++で良いよ。仕事で使うわけではないし。
AppleとかGoogleとかMicrosoftが使っているとか関係ねえ。

**デフォルトの名無しさん** · 2023/09/05(火) 01:14:55.37

>>98
あなたがC++でソースを例示してここの人達にRustで書けるか
挑戦者を求めれば良いだけでは？
「説明しない」では誰にもさっぱり伝わらん

**デフォルトの名無しさん** · 2023/09/05(火) 01:42:09.14

Rustスレでコテンパンにされたのがそんなに堪えたかw

**デフォルトの名無しさん** · 2023/09/05(火) 04:59:27.85

お前らにはわかるまい、ってよくマンガで悪役が言うけどさ、

そう言ってる間に基礎鍛錬するから、高尚なことはいまはいいや

**デフォルトの名無しさん** · 2023/09/05(火) 10:25:22.07

調べてみたらRustのコンパイルオプションにも-C target-cpu=nativeというオプションがあるっぽい。これがgccの-march=nativeに対応する模様。ただ、どちらの方が最適化性能が高いかは計測してないのでわからん。

**デフォルトの名無しさん** · 2023/09/05(火) 10:28:47.45

gccrs使えば良いのでは?

**デフォルトの名無しさん** · 2023/09/05(火) 14:25:20.49

C の vector とか map とか ordered_map から
Rust の Vec とか HashMap とか BTreeMap に変換してくれる crate ってありますか？
(また逆方向も)
map の vector だったり vector の map だったりしても再帰的に処理してくれるものを希望
っていうか copy とか clone とかせずにそのままアクセス出来れば尚良し

**デフォルトの名無しさん** · 2023/09/05(火) 17:45:36.54

>>110
cxx crateを見るといい
mapは対応してないけどvectorは対応してる
基本的に所有権があるから値をコピーせずに言語またいでowned valueを作ることはできない

**デフォルトの名無しさん** · 2023/09/05(火) 18:26:01.00

所有権の行き来の情報を付けて、C/C++が収受できるようなればいいんだよな

RustがC/C++を追い抜くなら、かならずそれもできるようになるはず