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

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

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/11(土) 23:24:45.49

>>218
ユーザーフォーラムのしかもたった二人の回答を「公式コミュニティの見解」にしてしまうオツムの人達だからさ一般常識があると思ったら大間違い

**デフォルトの名無しさん** · 2023/03/11(土) 23:30:52.30

>>219
3行目は全否定しておく

CやC++に複数の実装があった第一の要因は開発ツールが売れたという背景がある
Rustに限らず開発ツールは最早ビジネスとしては成り立たなくなってしまった

**デフォルトの名無しさん** · 2023/03/11(土) 23:34:33.13

>>220
あれ痛いよね
でもピン留めして晒し上げるのはさすがにどうかと思うわ

**デフォルトの名無しさん** · 2023/03/11(土) 23:39:25.95

Rustは公式が提供するcargoやrust-analyzerで開発環境は十分だもんな
もちろんrust-analyzerはLSPなのでVScodeなどの既存の統合開発環境で使える

**デフォルトの名無しさん** · 2023/03/11(土) 23:51:17.37

>>220
Rustユーザーの大半は英語のドキュメントを直接見てるからな
同じRustユーザーというだけであのリテラシーレベルと同類扱いされるのは誠に遺憾

**デフォルトの名無しさん** · 2023/03/12(日) 06:07:53.91

>>212
一目瞭然ってことはないよ。
わかってるやつにはわかるっていうレベル。
特にmodule and use以下で戸惑うと思うよ。

Rustはプログラミング言語としてはCとかで神経使っていたところで楽させてくれる感じだけど、新人を呼び込むにはドキュメントがまずいかなあ。

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

前にもこれどこかで同じレスしたことあるけど
Javascriptってドキュメントすっごい充実してるよな
2000年以前はHTMLとJavascript一緒になった解説本の最後の方に申し訳程度に乗ってたくらいで
あとは某とほほサイト見るくらいしかなかったけど

最近ちらっとみたらすごいのな
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/find
これは適当にクリックした特に選んでない一例だけど
ちょっと過剰なくらい説明と例が乗っててスゴイと思ったわ
Rustにここまでを要求したほうがいいとも思わんけど
いつかみんなが使う言語になったときはそうなってるのかもしれん

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

udemyからrust勉強すれば良いと思う

**デフォルトの名無しさん** · 2023/03/13(月) 11:30:57.14

C++は既に意味不明な域に来ていて、誰も新規に習得しようとはしないだろう

**デフォルトの名無しさん** · 2023/03/13(月) 12:04:07.60

>>226
ほんと。自分もノーマークだったけどすごいね。
Rustも「英文ドキュメント読め」みたいに突っぱねいようにしなくちゃね。

Rustのサイトで各国語にトランスレートされたもののリンク先の更新日付を眺めてると、中国語版に負けてる感じだね。

**デフォルトの名無しさん** · 2023/03/13(月) 12:11:38.79

中国なんてどうでもいい

**デフォルトの名無しさん** · 2023/03/13(月) 12:13:17.03

MDNもMDNで英語読まないとやってられない記事はちょいちょいあるけどね
CSSのpositionとか

**デフォルトの名無しさん** · 2023/03/13(月) 14:43:06.35

少なくとも手解き用として、TheBookの日本語版ではねえ。
で、メモリ安全ってことだけをひたすらリピートするだけでは、新しい人は来ないでくださいと言ってるようなもん。

まあ、その方がチンケな優越感に浸れて良いのかもしれないけど。

**デフォルトの名無しさん** · 2023/03/13(月) 15:10:59.37

>>231
Wasmのところも日本語版は古い情報のままなので肝心なAPIが足りていなくて英語版を見ないと致命的
リンク先が訳せてなくて英語版を指しているのは次善策としてまだマシ

英語版
https://developer.mozilla.org/en-US/docs/WebAssembly#api_reference
日本語版
https://developer.mozilla.org/ja/docs/WebAssembly#api_%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9

**デフォルトの名無しさん** · 2023/03/13(月) 15:27:59.03

メモリ安全ってのは個人が始める動機としては弱い
スマートポインタで充分なんだし
チームで書くときにメモリ管理が怪しい奴が混ざり得るときに
Rustで書くことを強制されるってシチュエーションはありえるかもね

**デフォルトの名無しさん** · 2023/03/13(月) 15:42:51.26

>>234
両方書いてると差は歴然
Rustは可読性もよいし開発効率もよく
特に実行時デバッグが激減するのも大きい
やむをえない場合を除いてC++を使い続けるメリットはない

**デフォルトの名無しさん** · 2023/03/13(月) 15:54:03.52

>>235
>Rustは可読性もよいし開発効率もよく
そんなのは人によるとしか言えない
所有権に割と馴染みがあるC++プログラマはともかく
他の言語からだと文法の解離に抵抗はあるだろうね
これからプログラミングを始めようという人は
特にRustだからという抵抗はないだろう
実績が増えればRustからって人が増えるかもね

**デフォルトの名無しさん** · 2023/03/13(月) 16:03:04.23

C++はコンパイラ買う時にデバッグツールもあって、そこでメモリリーク含む大体の解析が出来ることが多いから、今の所メモリ安全で困ったことはないな。
それよりもRustはまだ新しいから、何かしら思わぬ脆弱性が潜んでいることも考えて、まだ弄りながら様子見って感じ

**デフォルトの名無しさん** · 2023/03/13(月) 18:05:23.37

C++の有料コンパイラってそんなすげえのか？

**デフォルトの名無しさん** · 2023/03/13(月) 18:37:31.12

>>236
初心者や素人はC++でもRustでもなくBASICやPythonをやっていればいい
C++もRustも書きこなせる人なら自明なようにRustがはるかに効率いい

**デフォルトの名無しさん** · 2023/03/13(月) 19:04:23.67

>>237
デバッグツールを持ち出さなくてもRustはコンパイル時点でほとんど解決する点で圧倒的に優れている
Rustはメモリ安全性だけでなくデータ競合がないことがコンパイル時点で保証される
ポインタ以外の汎用的なヌル安全とエラー処理忘れ防止もRustは標準ライブラリ全体でOptionとResult利用により保証される
C++と比べて開発効率が段違いに良くなる

**デフォルトの名無しさん** · 2023/03/13(月) 19:17:45.07

C/C++のメモリリークと隣合わせなスリルがいいんだよ
Rustなんて補助輪付きの言語はプロのプログラマッには温すぎる
コーディングに自信がない奴や素人向けだな、Rustは

**デフォルトの名無しさん** · 2023/03/13(月) 19:49:16.47

>>241
C/C++はプログラマとして成長させてくれるよね

**デフォルトの名無しさん** · 2023/03/13(月) 19:51:01.09

>>241
C++はデバッグ時間のムダ

**デフォルトの名無しさん** · 2023/03/13(月) 20:02:48.32

別にスマートポインタでええがな

**デフォルトの名無しさん** · 2023/03/13(月) 20:04:22.18

Rustは規格が出てからだな

**デフォルトの名無しさん** · 2023/03/13(月) 20:07:14.22

マ板でやれバカども

**デフォルトの名無しさん** · 2023/03/13(月) 20:22:48.71

>>239
変わった言語なので
まず初めに学んだほうが先入観がなく覚えられるよ
そのためにも日本語のドキュメントは
整備したほうが良い

**デフォルトの名無しさん** · 2023/03/13(月) 20:39:22.66

トラ枝 5月号 Rust 特集

**デフォルトの名無しさん** · 2023/03/13(月) 20:45:38.95

>>243
その通りでC++は無駄なデバッグ時間が必要となるけど
テストで発見できなかった分はデバッグもされず実行時のセキュリティ含めたバグとして残ってしまう
Rustならばコンパイル時点ですべて排除できる

>>244
勉強不足すぎだ
C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない

**デフォルトの名無しさん** · 2023/03/13(月) 21:04:50.75

>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
他は?

**デフォルトの名無しさん** · 2023/03/13(月) 21:41:54.90

>>250
そんなことも知らずにこのスレで書き込み続けているのかよ
他の人たちの書き込みを読んでないのかよ

**デフォルトの名無しさん** · 2023/03/13(月) 21:46:41.78

>>251
他は? GCしか書けない人なのかな?

**デフォルトの名無しさん** · 2023/03/13(月) 22:00:51.65

>>250
既にたくさん書いて伝えた
理解できなかったのか？

**デフォルトの名無しさん** · 2023/03/13(月) 22:16:19.15

絵に描いたような負け犬のセリフw

**デフォルトの名無しさん** · 2023/03/13(月) 22:35:49.32

>>253
本当にGCしか知らないんだな

>>249
>勉強不足すぎだ
熨斗をつけてそのままお返ししよう

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

>>252
C++もRustもGC無いぞ

**デフォルトの名無しさん** · 2023/03/13(月) 22:43:20.72

>>256
んなことぁ誰でも分かってる

**デフォルトの名無しさん** · 2023/03/13(月) 23:26:56.50

>>255
GC言語も使うしC/C++/Rustも使う
速さと省メモリの点でGC言語は不利だから使い分ける

**デフォルトの名無しさん** · 2023/03/13(月) 23:40:00.84

>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
だから他は?

**デフォルトの名無しさん** · 2023/03/13(月) 23:52:11.42

>>244
C++スマートポインタは
unique_ptrは使わずともRustでは標準で全て自動解放されるよ
shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ

**デフォルトの名無しさん** · 2023/03/14(火) 00:08:40.65

>>260
別にunique_ptrやshared_ptrでええがな
難しくないよ

>shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
効率的をも少し詳しく!

**デフォルトの名無しさん** · 2023/03/14(火) 00:17:28.43

C/C++でスレッドセーフな並列処理を作ろうと思ったら一苦労だけど、Rustだとそうでもないんかな。

**デフォルトの名無しさん** · 2023/03/14(火) 00:51:48.86

>>261
shared_ptrは常に排他制御されコストが高い
共有を増減すると排他制御のコストがかかる
さらに単なる受け渡しも要注意でmoveしないとそのコストが無意味に余分にかかってしまう
一方でRustは排他制御するArcとしないRcの2つが用意されていてそれらの問題なく使い分けられる

>>262
Rustはコンパイルが通った時点でデータ競合がないことを保証されるのでかなり楽

**デフォルトの名無しさん** · 2023/03/14(火) 00:58:40.53

うわっw
排他制御の意味も知らないのかよこいつw

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

shared_ptrは排他制御してリファレンスカウンタの増減を行うからスレッドセーフ
その代わり重い

**デフォルトの名無しさん** · 2023/03/14(火) 01:26:54.27

>>263
なるほどね
std::shared_ptrには参照カウンタの排他制御をオフにする機能はなかったかな?
boost::shared_ptrだと美しくないけどBOOST_SP_DISABLE_THREADSマクロで切り替えられる
最近使ってないがLoki::SmartPtrは確かテンプレートパラメータで切り替えできたかな?

**デフォルトの名無しさん** · 2023/03/14(火) 01:58:37.91

Rustでは共存可能
スレッド内のみの共有はRc
スレッド間での共有はArc
切り替えでなく最初から二種類が用意されるべき

**デフォルトの名無しさん** · 2023/03/14(火) 02:06:25.73

>>267
同意
std::shared_ptrもLoki::SmartPtrみたいに
テンプレートパラメータで切り替えできれば良いのにね
ただしstd::shared_ptrを規格に入れた時点で
既にboost::shared_ptrもLoki::SmartPtrもあったことを考えると
参照カウンタが競合する機会はほとんどないという見立てで
実装を単純化したのかなと予想する
誰か経緯を知らんかな?

**デフォルトの名無しさん** · 2023/03/14(火) 02:13:23.45

苦肉の策としては
#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>;

**デフォルトの名無しさん** · 2023/03/14(火) 02:59:21.97

shared_ptr単独では完全なスレッドセーフではない、という問題もある。
shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
C++ではプログラマーがこれらの誤解や見落としやミスを全くしないことを求められ、それに依存するためプログラムの安全品質は危うい。

Rustではその点も安全で、Arc<T>はTへの書き込みが出来ないため、排他制御の問題は起きない。
書き込みしたいならば、Arc<Mutex<T>>やArc<RwLock<T>>など必要となる排他制御の種類に合わせて選び、組み合わせて利用する。
それら組み合わせにより、Tへの書き込みができるようになるが、必ずロックで排他制御されるため問題は起きない。
たとえプログラマーが見落としやミスや使い間違えをしても、Rustコンパイラがエラーを出し、該当箇所を教えてくれるため、常に安全性が保証される。

**デフォルトの名無しさん** · 2023/03/14(火) 03:15:26.07

>>270
Mutex <T>を書けば良いのではないかな？

**デフォルトの名無しさん** · 2023/03/14(火) 03:19:38.24

>>270
>shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
>したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
想定してるレベルが低すぎる
マルチスレッドで書くやつにそんなやつはいない
議論が無理やり過ぎ

**デフォルトの名無しさん** · 2023/03/14(火) 03:33:56.57

>>272
その件に限らずすべてにおいて、勘違い、見落とし、ミスなどは発生する。
複雑化したときにmutex忘れも、shared_ptr忘れも、間違えてunique_ptr使いも、その他のミスも、何でも実際に起きている。
Rustではそれらが起きてもコンパイラが通さないことで、常に安全性が保証され、無駄なデバッグを避けられる。
C++では無駄なデバッグを招くか、もしくは、そのままリリースしてセキュリティの穴が生じてしまう。
現実にC++が多数の問題を引き起こしてきた。

**デフォルトの名無しさん** · 2023/03/14(火) 12:05:32.83

暇を持て余すニートの日記

**デフォルトの名無しさん** · 2023/03/14(火) 12:21:44.83

>>273
「Rustはコンパイルが通っていればマルチスレッドで
競合問題が起きないことが保証される」
これで正しい? 正しいとすれば
マルチスレッドを習得したときの苦労を考えると有用なので
新しくプログラミングを始める人には勧めたい動機になる
俺自身は困ってないので使おうとはあんまり思わんけどね

**デフォルトの名無しさん** · 2023/03/14(火) 12:39:04.29

Rustが流行るとすればどの分野になるんだろうか？
一番は安全装置とかに使われる小規模な組み込みソフトかな。
CPUとか開発環境とかがまだ整ってないだろうから、ゆっくりだと思うけど

**デフォルトの名無しさん** · 2023/03/14(火) 12:50:59.56

普及するのにはキラープロダクトが必要
UNIX（C）やMFC（C++）や.NET（C#）のように
大手がプロダクトに採用してトップダウンで流行らせるしか
普及の道はないと思う
ゆっくり普及なんてのはないと思う

**デフォルトの名無しさん** · 2023/03/14(火) 19:34:32.70

Visual Studio Rust .Netがでるまで待とう

**デフォルトの名無しさん** · 2023/03/14(火) 19:40:00.62

あらためてJavaって良い言語だなって思うわ
ここ十数年だと人類一番の功績じゃね

良い点：
シンプルさ。C#で言う値型を入れようかどうか迷ったときもあったんだろうけど（想像）、
プリミティブと参照型変数の二個だけでやってくという線引がセンスある。

悲しい点：
立てまし。個人的にはジェネリクスもいらんかった。
C++のテンプレートを潔く排除して出てきたのすごいすっきり感あった。
でもあとでジェネリクスは押し負けて？付いてきちゃったけど。
あと貧相な貧相なラムダ式。クロージャを期待したけど結局はanonymous classのといっしょ。

異論は無いと思う

**デフォルトの名無しさん** · 2023/03/14(火) 22:31:24.61

>>275
Rustはマルチスレッド時でもマルチタスク時(＝グリーンスレッドをRustではタスクと呼ぶ)でも
データ競合を起こさないことが静的に保証されている
唯一のプログラミング言語

**デフォルトの名無しさん** · 2023/03/14(火) 23:07:45.86

んなわけねえだろ

**デフォルトの名無しさん** · 2023/03/14(火) 23:17:29.22

>>281
Rust以外の言語があるならば教えて

**デフォルトの名無しさん** · 2023/03/14(火) 23:54:49.43

Ownershipの元ネタのCycloneはやってねーのけ？

**デフォルトの名無しさん** · 2023/03/15(水) 02:10:25.53

Rust、コンパイル遅いっていうけどどれ程なの？C++と比べて遅い？

**デフォルトの名無しさん** · 2023/03/15(水) 02:53:43.28

コンパイル後の実行デバッグ時間が激減したのでトータルで要する時間は減少した

**デフォルトの名無しさん** · 2023/03/15(水) 03:26:18.55

現状はバカがイキる為だけに持ち上げられるRust
万一普及したとしてバカが使いこなせるはずもなく

**デフォルトの名無しさん** · 2023/03/15(水) 07:08:24.89

今まで C++ で制御して成功率 99.99% だった
ロケットをわざわざ Rust で描き替えて墜落しても
Rust は悪くない悪いのは GC のせいだと言い張るのが
Rust 信者

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

>>277
Android(Java)
iOS(Objective-C++)

**デフォルトの名無しさん** · 2023/03/15(水) 09:51:38.96

ロケットでGCは無いわ

**デフォルトの名無しさん** · 2023/03/15(水) 10:13:26.89

>>287
C++もRustもGCないよ

**デフォルトの名無しさん** · 2023/03/15(水) 10:52:34.36

プログラミング言語「Rust」は世界のセキュリティレベルを底上げする
https://wired.jp/article/rust-secure-programming-language-memory-safe/

Androidでは今、暗号鍵を管理する機能の多くがRustで書かれているとGoogleのクライダーマーカーは話す。
たとえば、暗号化したインターネット通信の機能である「DNS over HTTPS」、新バージョンの超広帯域無線（UWB）チップスタック、
そしてグーグルの独自のチップである「Tensor G2」で使用される新しい「Android 仮想化フレームワーク（AVF）」などもRustで書かれている。

また、BluetoothやWi-Fiなどの通信接続に使われるスタックも、Androidの開発チームによってRustへの変換が積極的に進められている。
理由は、これらが業界の複雑な標準規格に基づいており、脆弱性を多く含む傾向にあるからだとGoogleのクライダーマーカーは付け加える。
つまり最も狙われやすい、あるいは最も重要なソフトウェアの部分からRustに書き換えて、
そこから徐々にRustで書く範囲を広げることで段階的にセキュリティ上の恩恵を受けようという戦略である。

**デフォルトの名無しさん** · 2023/03/15(水) 10:57:42.49

>>280
デッドロックは静的検出はできないでしょ?

**デフォルトの名無しさん** · 2023/03/15(水) 12:50:04.82

やっぱりC++だよね

**デフォルトの名無しさん** · 2023/03/15(水) 15:17:28.42

段階的に置き換えることができるだけのお金と能力のあるエンジニアを確保できるアメリカの大企業ならいいんだろうけどね
両方無い日本企業には無理無理カタツムリ

**デフォルトの名無しさん** · 2023/03/15(水) 19:11:32.56

能力ない人の発想だね

**デフォルトの名無しさん** · 2023/03/15(水) 19:46:51.43

まず初めにの人はRustは選ばんと思う
Rustがターゲットとしているところで
プログラミングをやるなら
現状でCの習得は避けて通れない
となると学習コストの問題で
文法がほぼ包含関係にあるC++を選ぶことになる
OSの基盤からRustにしないと一向に増えないよ

**デフォルトの名無しさん** · 2023/03/15(水) 19:49:13.81

>>3で終わってんだよこのスレ
うだうだ続けたい奴はコード書く能力もないからここで自己顕示欲発揮しちゃうんだろｗ

**デフォルトの名無しさん** · 2023/03/15(水) 19:50:50.82

能力ある人からRustへ移行していってる

>>294
ほとんどのシステムは複数のプログラムから構成されているため
それら各機能をグレードアップで更新するときにRustへ書き換えることで進んでいる
もちろん新規システムは最初からRustで書くことが多くなっている

**デフォルトの名無しさん** · 2023/03/15(水) 19:55:49.97

Rustユーザが増えるストーリーは
トップダウンで基盤を整備するしか有り得ない
Cと文法が乖離してるのはメリットもあるだろうけど
普及にはデメリットとして働いている

**デフォルトの名無しさん** · 2023/03/15(水) 20:02:03.89

セキュリティ観点から新規システムはC/C++禁止でRust必須が要件になっていってる
この動きはそれが出来るところから着実に進んでいるので止めようがない

**デフォルトの名無しさん** · 2023/03/15(水) 20:52:20.68

>>300
>新規システムはC/C++禁止でRust必須が要件
どこで?

**デフォルトの名無しさん** · 2023/03/15(水) 21:00:17.63

デファクトスタンダードの強さは
MSを見ていればまぁ自明だわな

**デフォルトの名無しさん** · 2023/03/15(水) 21:15:24.65

結局コンパイルってどのくらい遅いの？

**デフォルトの名無しさん** · 2023/03/15(水) 21:55:22.51

今日のMicrosoftの発表が面白い
発表デモでなぜかPythonからRustへ

https://www.msn.com/en-us/news/technology/microsoft-s-new-bing-ai-chatbot-arrives-in-the-stable-version-of-its-edge-web-browser/
2023/03/15
本日マイクロソフトは、Edgeウェブブラウザの安定バージョンのサイドバーに、新しいBing AIチャットボットが含まれるようになったことを発表しました。
デモンストレーションで、AIにStack Overflowのヒントを調べながらコードのスニペットを書くように依頼しました。
AIはPythonコードをRustに変換することができました。

**デフォルトの名無しさん** · 2023/03/15(水) 21:58:57.19

>>304
正しいURLはこれ
https://www.msn.com/en-us/news/technology/microsoft-s-new-bing-ai-chatbot-arrives-in-the-stable-version-of-its-edge-web-browser/ar-AA18CPK2

**デフォルトの名無しさん** · 2023/03/15(水) 22:07:43.40

Rust普及はMSの動向が鍵だよ
自然に増えるもんじゃない

**デフォルトの名無しさん** · 2023/03/15(水) 22:20:44.44

Microsoftは自社製品のRust化を進めると同時に普及も進めてるね
日本語ドキュメントも充実してる

Rustを使用したWindowsでの開発
https://learn.microsoft.com/ja-jp/windows/dev-environment/rust/overview

**デフォルトの名無しさん** · 2023/03/16(木) 00:10:36.78

PriorityはF#の次だな
https://learn.microsoft.com/ja-jp/windows/dev-environment/

**デフォルトの名無しさん** · 2023/03/16(木) 00:12:05.34

「C++とCの概要」の位置に来ないと普及には程遠い

**デフォルトの名無しさん** · 2023/03/16(木) 00:25:01.88

RustがC++と同じ土俵へ採用されてしまった時点で
何もかも優れているRustの勝利

疑われる「C++」の安全性、今後の動きはどうなる
https://japan.zdnet.com/article/35199018/

**デフォルトの名無しさん** · 2023/03/16(木) 06:24:59.05

次の10年はRustが取った、となると、APIがRustになる
ならば、RustなAPIにC++がきちんと接続できるようになってもおかしくない
そうすると、Rustが実績を積んだ「正しい縛り」を、C++でも使えるようになってくるんではないだろうか

もうそういう試みある?

**デフォルトの名無しさん** · 2023/03/16(木) 08:50:45.88

何言ってんだこのバカ

**デフォルトの名無しさん** · 2023/03/16(木) 09:08:29.35

>>311
既にRustとC++の相互呼び出しは実現されているが
Rustから見てC/C++部分は当然unsafe扱い
最終的にC/C++部分が無くなる形で完成することになる

**デフォルトの名無しさん** · 2023/03/16(木) 09:15:14.89

OSもアプリケーションも、pure Rustになるんだろ、理想論としては
だとしたら、境界面であるAPIには、縛りにかかる属性情報が露出するはず
C++がそれに対応できないなら、今後C++ではアプリケーションを書けないことになってしまう

**デフォルトの名無しさん** · 2023/03/16(木) 09:54:57.99

慣れて使いこなせるようになると、
Rustの方が書きやすいとほとんどの人が言うほど差があるのだから、
C++がいずれ消えるのは間違いない。

**デフォルトの名無しさん** · 2023/03/16(木) 10:39:34.81

>>298
>能力ある人からRustへ移行していってる
まるでKENYAの作文だな

**デフォルトの名無しさん** · 2023/03/16(木) 10:43:46.43

Rustからインラインアセンブラでレジスタいじって安全性が担保されつつC++と遜色ないならもういらんわな

**デフォルトの名無しさん** · 2023/03/16(木) 10:45:31.49

ここでぐちゃぐちゃ言っても何も変わらないからさっさとC/C++で書かれた森羅万象の移植やってこいよ

**デフォルトの名無しさん** · 2023/03/16(木) 10:57:52.25

>>317
もちろんRustの変数を使う形でインラインアセンブリをRustでは記述できるが
当然ながらRustコンパイラによる保証範囲外となるunsafe部分になる
Rustはunsafe部分のみ人間が安全性を担保すれば全体についてはRustコンパイラが保証する形で役割分担できる
その点でプログラム全体が常にunsafe状態となってしまうC/C++とは根本的に異なる