C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

闘え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
C vs C++ vs Rust Part.2
https://mevius.5ch.net/test/read.cgi/tech/1639539350/

**デフォルトの名無しさん** · 2022/03/30(水) 22:42:11.12

>>872
どこにもC++のことを否定していない書き込みに対して唐突のイチャモンやな

それならC++だけでなく
Cでもできるわけだが？

**デフォルトの名無しさん** · 2022/03/30(水) 22:47:22.15

>>860
君は頭が悪いな
C#のdynamic型は失敗仕様であるという話だぜ
メモリが十分にあっても実行時エラーや例外で死んでしまう
コンパイラが検知できない仕様なためミスがあっても通してしまうからだ

**デフォルトの名無しさん** · 2022/03/30(水) 22:50:27.28

>>869
いや、マジで勉強したほうがいいぞ
using はスコープから拔ける時に Dispose 呼ぶだけ
寿命に感知はしないよ

**デフォルトの名無しさん** · 2022/03/30(水) 23:09:24.22

dynamic自体は名前がわかってるreflectionをいちいち書くのダルいから妥当な導入ではある

ジェネリクスにC++20のrequiresみたいな制限があればdynamicなんていらなかったのは確かだが

**デフォルトの名無しさん** · 2022/03/30(水) 23:15:44.80

実行時になってようやくエラーを引き起こし得るdynamicはC#の設計ミス
C++やRustは異なる解決をしている

**デフォルトの名無しさん** · 2022/03/30(水) 23:59:52.46

dynamicってそもそもリフレクション＋式木でしょうが
こんなもん使うな
ジェネリック使え

**デフォルトの名無しさん** · 2022/03/31(木) 00:03:05.89

tagged-unionだよ

**デフォルトの名無しさん** · 2022/03/31(木) 00:24:36.68

ミスった時にコンパイルエラーを出せない仕様はよくないな

>>859
Rustでの対応は3種類だな
(1) ジェネリックにトレイト境界で制約して静的にモノモーフィゼーション
(2) ジェネリックにトレイト境界で制約して動的にディスパッチ
(3) enumでタグ付け収容して処理時分岐
いずれもプログラミングでミスれば実行時ではなくコンパイル時に早期エラー発覚できる

**デフォルトの名無しさん** · 2022/03/31(木) 01:54:42.49

>>855
std::ofstreamのコンストラクタで例外を投げるってマジ？
普段からC++使ってるの？

**デフォルトの名無しさん** · 2022/03/31(木) 15:47:20.37

>>832
リソース解放って構造体と紐づけるのは結構無理があると感じることが多い。
もっとコンテクストによるって方が一般的感覚だと思うわ。
そういう意味でdeferのが馴染む。

**デフォルトの名無しさん** · 2022/03/31(木) 16:56:25.59

>>882
上にも書いたけど自由度は高いと思うけど忘れたり間違えたりしそうで怖い

**デフォルトの名無しさん** · 2022/03/31(木) 17:43:45.66

デストラクタを正しく書く方が簡単で間違いと考えてる？あんまり理解できんな。

**デフォルトの名無しさん** · 2022/03/31(木) 18:24:33.50

>>884
デストラクタは一度書けばいいけどdeferは使う度に書かないとだめでしょ？
どっちが間違いやすいかは考えるまでもない

**デフォルトの名無しさん** · 2022/03/31(木) 18:47:26.32

>>884
必要なものはだいたい標準ライブラリに入ってるから手書きで頑張る必要はないのでは
例外安全にするのがめんどくさいとかそういう話？

**デフォルトの名無しさん** · 2022/04/02(土) 20:19:43.92

https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377
clangの独自拡張としてだけどC++にlifetime入れようという議論があるんだね

**デフォルトの名無しさん** · 2022/04/02(土) 20:54:43.62

ライフタイム導入すればコンパイル時点でバグを発見できて
実行時の無駄なデバッグを減らせるし
メモリ関係の未知のセキュリティバグもコンパイル時点で検出できるもんな

**デフォルトの名無しさん** · 2022/04/02(土) 22:41:04.77

これ以上C++を接ぎ木してこねくり回すの止めにしたら

**デフォルトの名無しさん** · 2022/04/03(日) 11:55:08.48

>>887
でもrustと同じならdoubly linked listは表現出来ないんでしょ？

**デフォルトの名無しさん** · 2022/04/03(日) 12:04:52.85

>>889
C++ってかわいそうな運命だよなあ

**デフォルトの名無しさん** · 2022/04/03(日) 16:13:05.78

>>890
それはlifetime関係なくてxor mutabilityの話だよね

**デフォルトの名無しさん** · 2022/04/03(日) 16:37:52.29

>>892
なるほど

**デフォルトの名無しさん** · 2022/04/03(日) 17:12:35.56

>>890
Rustでは出来るよ

**デフォルトの名無しさん** · 2022/04/03(日) 17:28:58.27

>>885
そんなの一行書くだけろ。。むしろ意図通りのデストラクタが動いてるか怪しい挙動するデストラクタのが問題起こりまくりだわ。

**デフォルトの名無しさん** · 2022/04/03(日) 17:44:36.67

>>895
> そんなの一行書くだけろ。。
できないプログラマーの典型で草
一行書くだけだから確実にできると言うならバグは無くなるわ

> むしろ意図通りのデストラクタが動いてるか怪しい挙動するデストラクタのが問題起こりまくりだわ。
それはお前の能力が足らんだけ

**デフォルトの名無しさん** · 2022/04/03(日) 17:49:59.46

>>895
defer使えば怪しい挙動は絶対しないとでも？

**デフォルトの名無しさん** · 2022/04/03(日) 17:57:55.57

デストラクタでリソースが解放されることを保証するのはデータ構造を定義する人だけど
deferの場合はデータ構造を使う人の責任になる

データ構造を定義する回数と使う回数では普通は後者の方が多くなるから
deferの方が間違いを起こしやすいと

**デフォルトの名無しさん** · 2022/04/03(日) 19:34:48.12

>>894
実行時にオーバヘッドが出る形でしか実現できないやん

**デフォルトの名無しさん** · 2022/04/03(日) 20:40:47.40

>>899
オーバーヘッドが出てるのって具体的に何のこと？
stdのLinkedListの実装にもオーバーヘッドあるの？

**デフォルトの名無しさん** · 2022/04/04(月) 09:02:06.19

>>900
LinkedListってunsafeで実装されてるんだけど静的にメモリセーフティを実現する言語機能があるRustでそれをするっておかしいよね？
それって行儀よく実装するとオーバーヘッドが出ることの裏返しだよね？ちょっとは頭を使おうか？

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

>>901
えっ、じゃあなんでunsafeという機能がわざわざ用意されてるの？
頭使って考えてみて

**デフォルトの名無しさん** · 2022/04/04(月) 09:31:58.76

>>901
linked listに限らず何でもunsafeで作られているよ
unsafeは悪ではなく、安全なインタフェースを備えた型やモジュールの内部に閉じ込めるもの
その結果Rustではプログラム全体の安全性を保証できる
悪なのはプログラム全体がunsafe状態なC/C++

**デフォルトの名無しさん** · 2022/04/04(月) 09:56:40.12

>>902
そりゃRustの型システムがオーバーヘッドが起こるやり方でしか安全性を保証できないからでしょ？
頭使えないんだねかわいそう

**デフォルトの名無しさん** · 2022/04/04(月) 10:04:31.11

>>904
そうそう、コンパイラとプログラマの責任範囲を明確化するための仕組みだよね
結局 >>899 で言いたかったのは safe rust だけで LinkedList を実装するとオーバーヘッドが生じると言うことだったんだね

**デフォルトの名無しさん** · 2022/04/04(月) 10:09:11.84

>>903
それってRustの型システムに基づいて行儀よく実装するとオーバーヘッドが出ることへの反論になってないよね？
つまりRustの型システムはdoubly linked listを含めたあらゆるデータ構造をオーバーヘッドなく実装できるほどの表現力がないってことだよね

**デフォルトの名無しさん** · 2022/04/04(月) 10:23:50.48

>>906
safe rustの範疇ではあらゆるデータ構造を表現できないのはその通り
なのでunsafeというescape hatchを用意している
rustはpureな言語ではないのでコンパイラですべての安全性を保証することは最初から狙ってないよ

**デフォルトの名無しさん** · 2022/04/04(月) 10:34:53.41

>>906
それは違う
例えばVec(ベクタ)はRustが標準ライブラリで提供している型だが
LinkedList(二重リンクリスト)もRustが標準ライブラリで提供している型である
VecもLinkedListも内部でunsafeを用いているが安全なインタフェースのみを公開している
その両者に違いはなくRustによる安全性の保証に何も問題を及ぼしていない

**デフォルトの名無しさん** · 2022/04/04(月) 13:39:53.90

オーバーヘッドwってことでいいじゃん
中途半端な知識でムキになるから無駄なやり取りが続くんだよ

**デフォルトの名無しさん** · 2022/04/04(月) 15:17:06.36

>>908
> VecもLinkedListも内部でunsafeを用いているが安全なインタフェースのみを公開している

ホントかなぁ。　ベクターやリストが管理するオブジェクト参照を、別の参照ポインタ
に代入して、ベクターやリストを破棄した後で参照を使うとぬるぽになりそうだけど？

これを防ぐには、ベクターやリスト自体はもちろん、各要素や生ポインタを含めて
あらゆる変数に参照カウンタを設けた上で、参照数が0になったタイミングでオブ
ジェクト自動破棄する必要があるが、まさにオーバーヘッド。

**デフォルトの名無しさん** · 2022/04/04(月) 18:59:43.72

rustって、unsafe使っていても
メモリ安全のチェックはしてくれるって事であってる？

**デフォルトの名無しさん** · 2022/04/04(月) 19:11:22.90

>>911
そんなことはない。
ttps://doc.rust-jp.rs/book-ja/ch19-01-unsafe-rust.html

**デフォルトの名無しさん** · 2022/04/04(月) 19:18:31.93

rustって、制限きついなら制限緩い他の言語に変換しやすいとかある？

**デフォルトの名無しさん** · 2022/04/04(月) 20:04:42.98

標準ライブラリに問題がないって言い切れるの?
コンパイラとか標準ライブラリを盲信できるほど完成度高いんですかね
盲信してると不具合の発見に支障が出そう

**デフォルトの名無しさん** · 2022/04/04(月) 20:07:34.39

嫌なら使わなければいいだけやろ

**デフォルトの名無しさん** · 2022/04/04(月) 20:19:31.81

>>910
そんなRustの初歩くらいは学んでからレスしようぜw

**デフォルトの名無しさん** · 2022/04/04(月) 20:23:28.80

>>914
プログラムがバグった時にまず自分のコードを疑うべきと言える程度には信頼できると思うよ

**デフォルトの名無しさん** · 2022/04/04(月) 20:28:34.57

>>916
オーバーヘッドなのは否定できてなくて草

**デフォルトの名無しさん** · 2022/04/04(月) 20:41:28.56

>>910
> ベクターやリストが管理するオブジェクト参照を、別の参照ポインタ
> に代入して、ベクターやリストを破棄した後で参照を使うとぬるぽになりそうだけど？

以下のようなコードを意図してるんだと思うけど rust だとコンパイルエラーになるよ

let v = vec![Box::new(1), Box::new(2)];
let ptr = &v[1];
drop(v);
println!("{ptr}");

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=f4b4be3e93f71ec0828c6039dd156cb7

**デフォルトの名無しさん** · 2022/04/04(月) 20:48:51.57

>>914
今までにコンパイラやライブラリのバグ見つけたことある？
自分が作り込んだバグとどっちが多かった？

**デフォルトの名無しさん** · 2022/04/04(月) 21:00:31.84

殆どの言語が標準ライブラリはバグってたりセキュリティの穴見つかったりして更新し続けてるがな。

**デフォルトの名無しさん** · 2022/04/04(月) 21:11:15.35

メモリ安全性に関していえば
Rustなら不具合の可能性があるのはコンパイラとライブラリのunsafe領域だけだけど
（しかもそれらはそこそこの人数でチェックされている）
C/C++の場合ありとあらゆる箇所で可能性があるからな
盲信とかでなく単純に引く確率が低い

**デフォルトの名無しさん** · 2022/04/04(月) 21:11:46.66

libcにもバグあるしそれどころか
カーネルもヤバい問題発覚することがある
もうパソコンを窓から投げ捨てよう

**デフォルトの名無しさん** · 2022/04/04(月) 21:41:12.90

>>921
だからそれお前が見つけたのか？

**デフォルトの名無しさん** · 2022/04/04(月) 22:18:49.72

初心者ほど「コンパイラのバグ」などと言い出す
ダニング＝クルーガー効果である

**デフォルトの名無しさん** · 2022/04/04(月) 23:05:18.52

>>910
あまりにも無知なその知識でRustを叩くのは無理がある
そういうケースも含めて検出してくれるのがRust
だからRustはC++よりも圧倒的に優れている

**デフォルトの名無しさん** · 2022/04/05(火) 06:13:13.50

そろそろ飽きろよこの流れ

**デフォルトの名無しさん** · 2022/04/05(火) 09:01:35.21

>>926
Rustはunsafe内のメモリ関連のバグまでは検出しないけど？
例えRustには無知だとしてもunsafeという語感からだけでunsafe内では何も保証されないってことは推測できるよね？

**デフォルトの名無しさん** · 2022/04/05(火) 09:22:45.52

>>928
もちろんそう
それ以外の部分をRustは保証してくれるから大手IT企業を初めとして皆が採用している
全てがunsafeなC++を捨てつつある、

**デフォルトの名無しさん** · 2022/04/05(火) 11:55:20.23

2038年問題を再発させるコードが多数の場所にコピーされてしまっている
ttps://gigazine.net/news/20220330-2038-problem/

> エイドリアンさんが調べた限りでは、下記のリポジトリにて問題のあるコードが使用されていたとのことです。
>
> O3DE
> Dokany
> Ceph-Dokan
> libarchive
> ghc::filesystem
> ImageMagick
> Cxbx-Reloaded
> ReactOS
>
> また、下記のリポジトリについては記事作成時点で既にエイドリアンさんの指摘を受けてコード修正済みとなっていました。
>
> OpenRCT2
> DuckStation

**デフォルトの名無しさん** · 2022/04/06(水) 03:36:26.34

>>919
それ、子スレッドで実行する関数に引数として渡して、スレッド終了を待たずに
親スレッド側で解放するとかしたら、コンパイルエラーにならないと思うけど？

**デフォルトの名無しさん** · 2022/04/06(水) 03:42:32.00

>>931
そんなことは不可能だろう
まずは基本的知識を学べや

**デフォルトの名無しさん** · 2022/04/06(水) 04:46:14.51

エスパーさせんな、コードで示せ

**デフォルトの名無しさん** · 2022/04/06(水) 09:00:45.09

>>931
見事な恥の上塗りでワロタ

**デフォルトの名無しさん** · 2022/04/06(水) 09:22:57.25

>>932
何が不可能なの？　参照渡しされた場合、スレッド関数側ではメインスレッド側で
解放される変数の寿命が判らないから、参照カウントで実行時にはオブジェクト
寿命を管理できても、少なくともコンパイル時のエラーにはならないと思うが？

>>933
Rustやってないし、やる気もない。

ちなみに、919みたいなケースは実際にはそもそも書かないが、コンパイラ依存だけど
戻り値としてローカル変数への参照を返すとかは、最近のC++だと警告が出る。

可変引数のprintf()等でも、昔は書式制御文字列と引数の数や型が一致していなく
てもノーチェックだったけど、最近は警告が出るし。

**デフォルトの名無しさん** · 2022/04/06(水) 09:29:13.74

>>935
妄想で思い込みをして架空の意味のない話を進めて批判している
なんと愚かなことだろう

**デフォルトの名無しさん** · 2022/04/06(水) 10:57:59.47

>>931
エラーになるよ

use std::{thread, time::Duration};

fn main() {
let v = vec![Box::new(1), Box::new(2)];
thread::spawn(|| {
thread::sleep(Duration::from_secs(100000));
let ptr = &v[1];
println!("{ptr}");
});
drop(v);
}

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=6ffcf2e259e138e27d653db6fdd4fc98

**デフォルトの名無しさん** · 2022/04/06(水) 11:01:15.13

>>935
C++相当のコードか擬似コードでもいいからお前が言う操作のコードを出せ

スレッド間操作か参照の使い方周りでC++でもぶっ壊れるやつな

Rust使いの誰かがコンパイルの通しようがないって教えてくれるだろうよ

**デフォルトの名無しさん** · 2022/04/06(水) 11:41:09.81

>>397
それ、同じmain()スコープの中で宣言しているローカル関数だからでは？

普通、そんな書き方せんでしょ。

thread::spawnで起動している、無名関数を、引数ありの独立した関数として
定義して、参照渡しとしてスレッド実行した場合、コンパイル時の静的解析
ではエラー検出できない。

**デフォルトの名無しさん** · 2022/04/06(水) 11:55:40.05

流石にこのレベルの人を叩いて悦に入るのはやめようぜ

**デフォルトの名無しさん** · 2022/04/06(水) 12:00:23.11

>>939
意味不明だな
実際にそういうコードをわかるように書いてくれ

**デフォルトの名無しさん** · 2022/04/06(水) 15:45:42.18

thread::spawnには引数無しのクロージャしか渡せません
pthread_createとかで明示的にvoid *を渡すのに相当する処理は、Rustだとこの引数無しクロージャにキャプチャさせる方法で実現されます

で、それをやってるのが>>937です

**デフォルトの名無しさん** · 2022/04/06(水) 16:11:31.38

>>924
VCいじってりゃ嫌でもforループ前の初期化バグにぶち当たるわ。
最適化オプション下げるとか、for内でやるのをやめるとかいろいろ修正方法はあるが。
むしろいままでコンパイラバグに当たらない方が不思議。
お前仕事してんのかって疑われるレベル。

**デフォルトの名無しさん** · 2022/04/06(水) 16:23:15.68

forループ前の初期化バグってどんなの？

**デフォルトの名無しさん** · 2022/04/06(水) 17:07:47.57

>>931
こういうこと？これもエラーになる。

use std::{thread, time::Duration};

fn main() {
let v = vec![Box::new(1), Box::new(2)];
thread::spawn(|| sub(&v[1]));
drop(v);
}

fn sub(ptr: &i32) {
thread::sleep(Duration::from_secs(100000));
println!("{ptr}");
}

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=d90b955b8539696c776b1d44b0e8c5a9

ちなみにこれはコンパイルが通る
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=38157f3760d2ce9dde7d9d22c74195ad

これは通らない
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=38157f3760d2ce9dde7d9d22c74195ad

**デフォルトの名無しさん** · 2022/04/06(水) 17:09:04.34

>>945
URL間違えた
コンパイル通るやつ
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=10577ae2a6cdd42a9815971f82772c3a

コンパイル通らないやつ
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=9080880c0cab4626cd94cf4806b2e5a2

**デフォルトの名無しさん** · 2022/04/06(水) 17:18:09.35

>>943
具体的に書けよw

**デフォルトの名無しさん** · 2022/04/06(水) 18:45:31.77

>>945
> こういうこと？これもエラーになる。

Rustの文法がよう判らんけど、おおむね合ってると思う。

ちなみに、C/C++だと大規模プログラム開発を想定して、ソース分割による分割
コンパイルや、ライブラリ化という仕組みがあるわけだが、Rustの言語仕様って
そのあたりどうなん？

例えば、スレッド関数「fn sub(ptr: &i32)」が、「fn main() 」を別のファイルに
(例: main.cpp, sub.cpp のように)実装してビルドするとか、スレッド関数の
「fn sub(ptr: &i32)」だけをライブラリ(dllまたはlib)化するとかできるの？

そもそも、Rust でライブラリを書いたり、Rust で書いたプログラムって、他の
言語で書かれたライブラリ(OpenCVとか)とリンクできるのか？

**デフォルトの名無しさん** · 2022/04/06(水) 18:47:00.11

pythonのライブラリとかgithubにいくらでもあるけど？

**デフォルトの名無しさん** · 2022/04/06(水) 18:52:54.88

>>948
モジュール分割は普通に備えてる
というかC/C++のモジュール分割は貧弱な方で、大半の言語はまともな仕組み備えてるよ

Rustでライブラリ作ってCから呼び出したり、CのライブラリをRustから呼び出すこともランタイムとかめんどくさいこと考えずに普通にできる

**デフォルトの名無しさん** · 2022/04/06(水) 22:27:56.00

Rustのモジュール分割はC/C++の分割コンパイルとはちょっと違う気がする
C/C++だとソースファイルごとにコンパイルしてオブジェクト（.o）作ってからリンカでまとめるけど
Rustは最初にcrate内のソースを１つにまとめてから一気にコンパイルする感じ
（見えない部分で分割してるっぽいけどソースファイル単位じゃないしプログラマは意識しない）

C/C++の.dllとか.libに対応するのはRustだとcrateになるからsubだけライブラリ化するなら
ファイルを分けるというよりプロジェクト（crate）を分ける感じになるかな

C/C++の.oに相当する中間ファイルはRustだと存在しないはず

**デフォルトの名無しさん** · 2022/04/07(木) 06:01:34.50

いやgolangよりCとの相互利用はマシだけど、褒められるほどRustにCとの互換性はないよ。Dとかのほうがまだまし

**デフォルトの名無しさん** · 2022/04/07(木) 07:14:19.71

RustとC++の相互呼び出しはCXXで完璧や

**デフォルトの名無しさん** · 2022/04/07(木) 07:28:15.01

ぶっちゃけモジュール分割がなんでよしとされてるのかがわからない
過大評価やろ
parseにオーバーヘッドあると言われているけどC/C++のような分割コンパイルの方が並列化できるしええやん

**デフォルトの名無しさん** · 2022/04/07(木) 09:21:09.02

C++にはモジュール導入したいという
話はずっと前からなかったっけ

**デフォルトの名無しさん** · 2022/04/07(木) 09:32:06.83

分割コンパイルはgenericsとかtemplateと相性が悪いんだよね（C++の悩みの種になってるはず）
Cの時代のマシンパワーだと最適解だったと思うけど
Rustの
// main.rs
mod foo { pub fn f() {} }

と

// main.rs
mod foo;

// foo.rs
pub fn f() {}

を等価とみなせる言語設計は分かりやすくて余計な悩みが少ない

**デフォルトの名無しさん** · 2022/04/07(木) 12:15:13.87

>>951
ちょっと調べてみたが、RustってFlutterと同様、結局のところ単なるコンパイラ
コンパイラ(Rust→C++, Dart→C++)じゃんよ。

だから、どちらもターゲットプラットフォーム用のC++コンパイラ(Windowsなら
Visual Studio(Build Tools)または MinGW、macOSならXcode)が要る。

> C/C++の.oに相当する中間ファイルはRustだと存在しないはず

隠蔽されているだけで、vclやgccが動いてリンカーに渡す段階で、オブジェクト
ファイル(.oや.obj)が生成されている。　スタティックライブラリ(.aや.lib)は、
単なるオブジェクトファイルの寄せ集めなので、他のOSS含めてリンクできる。

オブジェクトファイル自体に対応していなけりゃスタティックライブラリをリンク
できないし、ELFフォーマットのデバッガも使えないし、malloc()等のランタイム
との内部整合性も取れないからな。

自転車に乗れない(C++で安全なプログラムが書けない)プログラマ向けの補助輪
みたいなもんか？

**デフォルトの名無しさん** · 2022/04/07(木) 12:27:13.60

>>957
前半は何言ってるのかわからんが
codegen unitごと.oファイルが生成されるのはその通り
codegen unitはソースレベルのmoduleごとに2つずつ作られcodegen単位で並列化される

**デフォルトの名無しさん** · 2022/04/07(木) 12:32:34.52

>>957
デタラメすぎる
RustコンパイラはCコードやC++コードを生成しません
あなたの書いていることは全て間違っています

**デフォルトの名無しさん** · 2022/04/07(木) 12:44:03.67

>>957
main.cに対応するmain.oが存在しないという意味で書いたつもりだった
混乱させたみたいですまない

**デフォルトの名無しさん** · 2022/04/07(木) 12:45:05.63

>>957
補助輪、というより電動機かな
同じ自転車だけど、少ない力でこげる
結果的に同じ体力でより遠くへ行ける

**デフォルトの名無しさん** · 2022/04/07(木) 13:35:54.27

Rustやる気ないとか言う割にはずいぶんと熱心じゃん
The Bookあたりから読み始めてみては？

**デフォルトの名無しさん** · 2022/04/07(木) 13:49:05.41

>>959
> RustコンパイラはCコードやC++コードを生成しません

だったら、Visual Studio (Build Tools)や、Min-GW、Xcode等がインストール
されていない環境で、Rustだけをインストールしてバイナリ生成してみな。

下請けにプラットフォーム固有のC++コンパイラを使っているから、ターゲット
プラットフォーム毎に、オフラインインストーラ―が存在するんだよ。

ttps://forge.rust-lang.org/infra/other-installation-methods.html

**デフォルトの名無しさん** · 2022/04/07(木) 14:01:29.41

>>963
それはできない
ただしその理由はコンパイラを下請けとして利用しているからじゃなくて、リンカを下請けとして利用しているからだよ

> Why might one not want to install using those instructions?
> * Offline installation. ...

斜め読みしすぎじゃないですかね？
オフラインインストーラがあるなんてどこに書いてある？

**デフォルトの名無しさん** · 2022/04/07(木) 14:32:47.76

空想上のRustに似た言語叩きする人多いな

**デフォルトの名無しさん** · 2022/04/07(木) 14:49:00.36

LLVMを知らないんだろ
もう引退するお年頃

**デフォルトの名無しさん** · 2022/04/07(木) 15:03:24.56

5chに常駐してるようなC++民はビックリするほど見識が狭いよな
ある意味コボラーと同じ人種

**デフォルトの名無しさん** · 2022/04/07(木) 15:09:08.48

> オフラインインストーラがあるなんてどこに書いてある？

折角リンクを貼ってやったのに英語読めないの？　「Standalone installers」って
とこ。

> The official Rust standalone installers contain a single release of Rust,
> and are suitable for offline installation.

その下にリンク集の表があるでしょ。　以下、直リンク抜粋

Windows+GCC(32-bit)用
https://static.rust-lang.org/dist/rust-1.59.0-i686-pc-windows-gnu.msi
Windows+MSVC(32-bit)用
https://static.rust-lang.org/dist/rust-1.59.0-i686-pc-windows-msvc.msi
Windows+GCC(64-bit)用
https://static.rust-lang.org/dist/rust-1.59.0-x86_64-pc-windows-gnu.msi
Windows+MSVC(64-bit)用
https://static.rust-lang.org/dist/rust-1.59.0-x86_64-pc-windows-msvc.msi

**デフォルトの名無しさん** · 2022/04/07(木) 15:34:45.27

>>968
それは単にプラットフォーム毎にビルド済みのRustコンパイラと標準ライブラリが違うだけ
いずれにしてもC++に変換してC++コンパイラを使ってるなんて事実はない

**デフォルトの名無しさん** · 2022/04/07(木) 15:35:55.43

>>968
ああそこはこちらの勘違いでしたね
すみません

**デフォルトの名無しさん** · 2022/04/07(木) 15:55:01.85

ちんちんシュッ！シュッ！シュッ！

**デフォルトの名無しさん** · 2022/04/07(木) 18:28:45.48

>>954
クソデカヘッダファイルのパースコストは馬鹿にならないよ
コンパイラはプリコンパイル済みヘッダファイルを用意したり、涙ぐましい努力をしている

>>957
rustが必要としてるのはVS Build Toolのリンカやランタイムで、コンパイル自身はrustcというかLLVMがやっている
vclは動かないよ