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/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は動かないよ

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

Rustの集大成と言えるFirefoxが世界で一番固まるブラウザとして名高いのだから、ユーザーに嫌がらせしたいプログラマはRustを使うべき。
タブレットモードで使ってると毎日一回は操作不能になるからね。
電源ボタン長押しして強制リセットするしかなくなる。

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

>>963
コンパイラとリンカを一緒くたにされてもなぁ。
それ言ったらc/c++も結局アセンブラ必要じゃん。
c/c++なんてアセンブリ言語使えない奴向けの補助輪じゃん。

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

そいやRUSTってオプションでアセンブラ出力させたり出来るの？

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

>>973
まだservoとかだけでしょ？

**デフォルトの名無しさん** · 2022/04/08(金) 00:19:49.85

>>973
アプリケーションのせいで電源強制断を要求されるのはOSが悪いのでは...
というのはさておきfirefoxの悪い部分がrustに依るものってのはどうやって調べたの？

**デフォルトの名無しさん** · 2022/04/08(金) 01:42:20.81

それにマジレスするか

**デフォルトの名無しさん** · 2022/04/08(金) 06:18:52.60

>>973
もしそれが本当ならばWindowsでの問題でしょう
LinuxでFirefoxを使っているけど一度も固まったことがない

**デフォルトの名無しさん** · 2022/04/08(金) 07:35:26.61

俺はwindowsでEdge使ってるけど一度も固まったことないな

**デフォルトの名無しさん** · 2022/04/08(金) 07:40:49.60

Rustを叩くために>>973が適当なホラを吹いてるのだろう
毎日固まるブラウザなんてあるわけないし
頻出するバグがあったらすぐに修整される

**デフォルトの名無しさん** · 2022/04/08(金) 07:57:10.73

そもそも>>725が書いてるけどrustはまだ全体の１割位しか使ってないのにrustの集大成とかアホ晒しすぎw

**デフォルトの名無しさん** · 2022/04/08(金) 08:00:48.24

firefoxは固まるもの。
固まったところで誰も気にしない

**デフォルトの名無しさん** · 2022/04/08(金) 08:02:17.06

>>983
どんな環境で使っている？
一度も固まったことない

**デフォルトの名無しさん** · 2022/04/08(金) 09:36:43.82

>>982
登場して10年で1割ですか。100年後もfirefoxが動いてるといいですね。

**デフォルトの名無しさん** · 2022/04/08(金) 09:59:58.15

既に昔からある動いているモジュールを書き換える無駄なことはしないからそんなもんじゃね？
そもそもRust自体も他の言語と同様にlibc含めて鉄板のC製ライブラリ使いまくるしな
どの言語でもそのへんは同じだろ

**デフォルトの名無しさん** · 2022/04/08(金) 14:54:35.66

firefox は固まるっていうかメモリリークだな
rust のコードが unsafe だらけになっているのかは知らんが
タブを閉じても使い終わったメモリを開放しない
ひたすら使用メモリが増え続けswapがいっぱいになって固まる

**デフォルトの名無しさん** · 2022/04/08(金) 14:59:41.50

>>987
両方を使ってみればわかるが
メモリをバカ食いするのはChromeの方

**デフォルトの名無しさん** · 2022/04/08(金) 15:37:14.24

>>988
自分は firefox で swap に悩まされてて
その後 chromium 系の vivaldi とか brave にして一気に快適になった
メモリ４Gのマシンに linux 64bit を入れてた時の話だけど

**デフォルトの名無しさん** · 2022/04/12(火) 07:13:47.72

firefoxのせいで、スレまでの流れまで止まったな

**デフォルトの名無しさん** · 2022/04/15(金) 14:27:51.53

>>957
なるほど
最初のころのC++といっしょで
単なるトランスレーターなんかrustって

**デフォルトの名無しさん** · 2022/04/15(金) 14:38:25.40

>>987
通信障害起こしてるのをfirefoxのせいにされてもなww
firefox使ってる最中に固まったことあったよ
使ってる最中にSSDが死んでアクセス不能になったのが原因だった

**デフォルトの名無しさん** · 2022/04/15(金) 15:14:39.30

>>991
ちがうよ
rustでのビルド必要なのはターゲットプラットフォーム用のリンカであってC++コンパイラは不要

RustはLLVM使ってるからLLVM bitcodeへのコンパイラとは言えるかも知れないけどC++は一切関与しないよ

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

>>991
バカそうなやつ

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

リリースされて10年経過する言語に思いを寄せてるのは馬鹿の骨頂だろwww
お前といっしょでもう終わってんだよハナタレ
せめてIARあたりがリリースしてたんなら話は別だがな
どこぞのチップメーカでrustコンパイラ出してるとこあったけ?
チップメーカが見向きもしない言語それがRust って認識でFA?
あ、そーそ、SystemC rustで書けるか?
これぐらい書けなきゃC++はreplaceできない
C++をreplaceが目標じゃなかったっけ?

**デフォルトの名無しさん** · 2022/04/15(金) 20:14:02.55

大体
Rustなんてネーミングがセンスなさすぎだろ。あほすぎて。これで洒落たつもりかよ。
これからぴかぴかの新製品投入するときにRustてwwww
機械メーカなら絶対採用したくい名前だろこんなもん

**デフォルトの名無しさん** · 2022/04/15(金) 20:26:31.06

>>995
LLVMって知ってる？

**デフォルトの名無しさん** · 2022/04/15(金) 20:35:07.13

>>996
確かに

**デフォルトの名無しさん** · 2022/04/15(金) 20:37:43.23

というか何故か言語って大概ネーミングに疑問符がつくような感じだよね

**デフォルトの名無しさん** · 2022/04/15(金) 20:38:50.95

rustてさび以外に
"役に立たない"
て意味もあるのな
まさに、理念のみの

　役　た　た　ず　言　語

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 77日 22時間 19分 4秒