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(水) 07:56:10.67

バツが機種依存やったな
X　俺は>>616で同様の処理
〇俺は>>816で同様の処理

**デフォルトの名無しさん** · 2022/03/30(水) 08:14:44.56

>>834
そのusingブロックを抜けるときに自動でDispose()が呼ばれるという話なら、
C++だとデストラクタでやるってのが>>814が言っていることかと。
usingより簡単だし例外でも問題なし。

**デフォルトの名無しさん** · 2022/03/30(水) 08:18:15.81

>>834
横だけど、std::ostreamてRAII使えなかったっけ？
コードは適当。

if (std::ofstream sw(filename)) {
sw << "test" << '\n';
} else {
std::cerr << "unable to open '" << filename << "'\n";
}

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

>>834
C++向けに設計されたライブラリならデストラクタに終了処理を全部書いてあるのでusing構文自体が不要

スコープアウトでデストラクタが呼ばれる

std::ofstream fs("a.txt");
fs<<"test"<<std::endl;

**デフォルトの名無しさん** · 2022/03/30(水) 08:57:42.45

>>834
C#2.0以降に実装されてた糖衣構文の多くはC++には実装されていない

お前のC++の用語がところどころ違うから無知なようにしか見えない

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

>>834
> ・$"X = {X}"
> ・null合体演算子
まあこれは全然違うレベルの話だけどこう言うところはC#はなかなか良く出来てると思う

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

>>839
>fs<<"test"<<std::endl;

ファイルオープンできてるかどうかわからないのに書き込むのかよwww
C++てファイルオープンできてもないところに書き込んだときに
処理を停止せず、自動でうまく例外処理するおしゃれな機能なんてあったっけ?

using(var sw=new StreamWriter("a.txt")){
sw.WriteLine("test");
}

とじゃ全然意味が違うだろ
なんでエラーチェックしないの?
わざわざチェックしなきゃいけないかどうかの話をしてんだよ
わざと論点ずらすな

>C#2.0以降に実装されてた糖衣構文の多くはC++には実装されていない

その通り
それを問題にしてんの。
そのおかげでC++では生産性の向上が見られない
認めてるじゃねーかwww

**デフォルトの名無しさん** · 2022/03/30(水) 13:54:11.00

C++ vs C#スレ立てるか？

**デフォルトの名無しさん** · 2022/03/30(水) 14:02:35.35

>>842
> ファイルオープンできてるかどうかわからないのに書き込むのかよwww
そういうのが欲しけりゃエラー時に例外を出すようにしとけばいいだけ
C# 使ってりゃそれぐらいわかるだろ

... 使えてりゃねw

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

>>842
>>838は無視かよ。
ずいぶんと都合のいい目をしているんだな。

**デフォルトの名無しさん** · 2022/03/30(水) 18:17:46.54

>>838見ればC++がなぜ衰退していくかよくわかるな

**デフォルトの名無しさん** · 2022/03/30(水) 18:28:11.81

>>846
なんで？
そこまでいうからにはきっちり説明してもらおうか。
説明できなきゃ馬鹿にしようかね。

**デフォルトの名無しさん** · 2022/03/30(水) 20:08:24.48

iostreamなんて今使ってないだろ

**デフォルトの名無しさん** · 2022/03/30(水) 20:21:40.16

> C#のusingみたいな構文

C#の発明と言うより、発祥は、お前らの嫌いな、Visual Basic(VBA)の、With～
End Withじゃないかな？

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

C++は例外がcharベースのwhatしかない時点で日本語Win上では実情と合わなくなるんよね。

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

>>834
Rustだと以下のようになる

> ・using

RustもC++と同じくRAIIなのでusingは不要
let mut file = File::create("a.txt")?;
file.write("test")?;
エラー時は?演算子で即returnとなり例外処理と類似状態になる
スコープを抜ける時に自動的にデストラクタdrop()が呼ばれる
何もしなくてもファイルなら自動closeされてロックなら自動解除される

> ・$"X = {X}"

Rustでは標準マクロ利用でほぼ同様の形式
format!("x={x}")

> ・null合体演算子

Rustは安全重視のため各型にnullやnilといった値が無い状態というものがない
そこで関数型言語と同様に代数的データであるenumを用いてジェネリックにT型に対してenum Option<T>型を使う
Option<T>型はT型の値tが存在する場合Some(t)と存在しない場合Noneの2つのenum値をとる
なのでnullに対応するものはNoneとなるが型が異なるので明白に区別できてミスがあればコンパイル時に検出可能

**デフォルトの名無しさん** · 2022/03/30(水) 20:25:10.41

>>834
> ・null合体演算子

Rustでは>>851という状況なのでnull合体演算子についても少し概念が違ってくるが
xがNoneの時にDEFAULT_VALUEとしたい場合
x.or(Some(DEFAULT_VALUE)) でOption<T>型を得る
x.or(Some(DEFAULT_VALUE)).unwrap() でT型を得る
x.unwrap_or(DEFAULT_VALUE) が上記の簡易版でT型を得る

例えばC#での x ?? y ?? z を全てOption<T>型で表すと
Rustでは x.or(y).or(z) となりほぼ同じシンプルな表現

ちなみに?演算子によるNone時の即retun Noneも可能で
例えば各メソッドがOption<T>型を返すとするとこれでT型を得られる
let output = input.method1()?.method2()?.method3()?;

**デフォルトの名無しさん** · 2022/03/30(水) 20:27:16.59

>>850
その例外ベースだけだとおもってるの？
クラスや型ならなんでも投げられるんだが

**デフォルトの名無しさん** · 2022/03/30(水) 20:31:07.93

それは例外そのものの型のことでしょ。
基本的にはexceptionの派生や孫で作られてるものが大半だからwhatでメッセージ受けるわけだが、
何のエンコードかは定かではない。

**デフォルトの名無しさん** · 2022/03/30(水) 20:33:36.81

>>842
根本的な理解がない、残念君のご様子。

> std::ofstream fs("a.txt");

コンストラクタでOpenする場合、失敗すると例外がスローされるから、関数内
または上位でtry～catchかな。 C#やJavaで毎回NULL参照チェック書いてるか？

いずれにしろ、オープンされていないオブジェクトが

> fs<<"test"<<std::endl;

に渡されることはない。　こうした処理は、オブジェクトのシリアライズ処理を実装
した関数内へ記述して、参照渡しでオープン済のオブジェクトを渡すのが一般的。

**デフォルトの名無しさん** · 2022/03/30(水) 20:43:31.08

Rustにはnullも例外もなく
どちらも代数的データ型であるenumで表現するため
シンプルかつ安全性をコンパイル時に保証できる

**デフォルトの名無しさん** · 2022/03/30(水) 21:06:36.60

RustでC#のdynamicみたいなことやるにはどうするの？

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

>>849
全然ちゃうわww

**デフォルトの名無しさん** · 2022/03/30(水) 21:25:28.30

>>857
C#はdynamic型という間違った方法を取ったため
C#は実行時エラーおよび実行時例外が発生し安全でない

Rustは型とは直行するトレイトがあるため
複数の様々な型に対して共通する振る舞いをトレイトとして実装できる
これらはコンパイル時にチェックされ実行時の安全性が保証される

更に加えてトレイトの利用方法は用途に向けて2種類用意されている
1つは利用時にimpl Traitで宣言する静的なトレイト利用であり
複数の様々な型に対して各々の静的に異なるコードが適用され高速である
もう1つは利用時にdyn Traitで宣言する動的なトレイト利用であり
複数の様々な型に対して実行時にダイナミックにディスパッチし柔軟である
2種類ともにコンパイル時にチェック確定するため
Rustではこれら実行時にエラーや例外が起きることはない

**デフォルトの名無しさん** · 2022/03/30(水) 21:55:25.20

> Rustではこれら実行時にエラーや例外が起きることはない

実行時にメモリが足りなくなったら、Rustで書かれたプログラムは
どんな挙動を返すの？

**デフォルトの名無しさん** · 2022/03/30(水) 21:57:54.53

それだと使えないなぁ。

**デフォルトの名無しさん** · 2022/03/30(水) 21:58:03.62

>>858
おなじだよ。　usingに一時オブジェクトを渡す場合に限って、usingの終わりと
オブジェクト寿命が同じなだけだ。

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

毎度のことながら複オジのアホ解説読むと
Rust勧めてるのはこのレベルの人なのかと悲しくなる
無知にも程がある

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

>>860
それちゃんとよく読めよ
C#のdynamic型に対応するものの話だろ

ちなみにRustではメモリアロケータも変更可能＆自作も可能でベアメタル含めて任意の環境に対応できる
だからメモリ不足時の対応も自由にできてOS等も書ける
もちろん一番単純な対処としてはpanic

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

>>861
C#でのdynamic型で適用してる事項はすべて適用出来るでしょ
反例を持ってこない限りこれはC#側の負けよ

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

>>862
With~End Withだけじゃなくusingも勉強し直した方がいいよ
リアルで恥を掻く前に

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

対象なオブジェクトがrust内にあるわけでも存在してるかさえわからない状態なんだから、
実行時にはエラーや例外が発生すると思うのだが...

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

>>867
どういう想定か曖昧すぎてわからないため一般的な話をすると
Rustにはnullもundefinedもないし
いわゆるtry-catch例外もないから
あるT型が求められる時の関数の返り型は>>851でも触れられているように代数的データ型となって
enum Option<T>型かenum Result<T, Err>型になるよ
これらはT型を取り出すために広い意味での分岐となるだけで普通に処理が進むね

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

>>866
お前がナー

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

>>867
それはC#でdynamic型を使って問題を解決している例ではないのでは？
例えばWebのDOM操作など色んな異なる型が返ってくるときのためにC#ではdynamic型を使う
Rustではそういう時にトレイトを使うので色んな異なる型が返ってきても対応できる

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

>>839
> usingより簡単だし例外でも問題なし。

>>842 は、

> using(var sw=new StreamWriter("a.txt")){

の、newに失敗すると、その時点で例外がスローされることを判ってないん
だろうな。

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

>>864
> ちなみにRustではメモリアロケータも変更可能＆自作も可能

C++でもできるわけだが？

**デフォルトの名無しさん** · 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()等でも、昔は書式制御文字列と引数の数や型が一致していなく
てもノーチェックだったけど、最近は警告が出るし。