Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/10(火) 00:00:07.29

そしてスタック上のTであろうがヒープに確保したBox<T>やRc<T>であろうが
そのT部分への参照は同じ&T型となりその値は(スライスなどを除いて)アドレス値のみで構成される
そこでスタック領域かヒープ領域かの区別はない

そしてそこには参照のカウント値は当然なくてライフタイム値も存在しない
参照の有無やライフタイムの妥当性はコンパイル時のみ把握されて問題があればコンパイル時にエラーとなる

**デフォルトの名無しさん** · 2024/09/10(火) 11:45:49.01

>>804
すまんその通りや
継承関係ないわw
C++だとスマートポインタにするか生ポインタをクラスに隠すかみたいなことが頭をよぎってあぁぁぁってなるのよ

**デフォルトの名無しさん** · 2024/09/10(火) 13:35:20.41

>そこでスタック領域かヒープ領域かの区別はない

これもコンパイル時のみの話では

**デフォルトの名無しさん** · 2024/09/10(火) 18:55:33.96

参照があるかないかライフタイムを満たしているかといった情報はコンパイルの時しか持たないけど
参照のアドレス値は実行時にも当然ある
ただしそれがヒープを指すかスタックを指すかは把握できないから区別しない
そして区別しなくてもよい方法をRustは導入した

**デフォルトの名無しさん** · 2024/09/10(火) 18:58:00.79

なぜどちらを指しているか把握できないのか？
それは次のようなコードも書けるため

fn bigger<'a: 'c, 'b: 'c, 'c, T: PartialOrd + ?Sized>(x: &'a T, y: &'b T) -> &'c T {
if x > y { x } else { y }
}

二つの引数にヒープを指す参照とスタックを指す参照を渡した場合
関数から返ってくる参照がどちらなのかは各実行毎のデータが揃うまでわからない
そして実は参照が指す領域がどちらなのかを把握する必要がないのが結論
ライフタイムさえ満たしていれば区別する必要がなくなった

**デフォルトの名無しさん** · 2024/09/10(火) 20:21:44.39

なるほど

**デフォルトの名無しさん** · 2024/09/10(火) 21:08:40.00

>>805の疑問とは何の関係もないよね
騙されてるやつが訳1名いるみたいでご愁傷様だけど

**デフォルトの名無しさん** · 2024/09/10(火) 21:31:43.71

Rcは参照の数を管理するものではない
Rcはヒープ領域を確実に解放するためにその所有者の数を管理する
当然Rcはヒープ領域だけを扱う
スタック領域はRAIIで確実に解放される

**デフォルトの名無しさん** · 2024/09/10(火) 22:01:22.00

誰かがArc/Rcはborrowの数を管理してると言ってる？
文脈によって意味が変わる「参照」とか「reference」という言葉を勘違いしてるだけじゃない？

Arc/Rcはreference counting pointerなんだから当然参照の数は管理してる
同じアロケーションを参照してるowning pointerの数を管理してる

**デフォルトの名無しさん** · 2024/09/10(火) 22:08:07.24

Rcのソースコード解説あったわ。
qiita.com/qnighy/items/5b2fbf27e3ee36e57b8d

誰かソースコード読んだ？

**デフォルトの名無しさん** · 2024/09/10(火) 22:23:36.52

>>815
そんな言葉遊びをして混乱させるのはよくない
Rustで参照といったらTに対する&T
一方でRcはヒープ解放責任の所有者を複数可にする
参照が複数あることと所有者が複数あることは全く別なのでこの違いをはっきりさせて理解するのが正しい

**デフォルトの名無しさん** · 2024/09/10(火) 23:01:44.78

>>817
The BookやRcの公式ドキュメントにも書いてること
例えばThe Bookには「The Rc<T> type keeps track of the number of references to a value」と書いてある
つまり「Rustで参照といったらTに対する&T」とは限らない
文脈次第

>参照が複数あることと所有者が複数あることは全く別なのでこの違いをはっきりさせて理解するのが正しい
その区別ができてないレスとかあった？

**デフォルトの名無しさん** · 2024/09/10(火) 23:09:22.99

Rc/Arcはヒープの解放責任者が複数になるときに対応するものだが
>>805が「ArcやRcってスタックのデータを指せるっけ？」と言い出したのでちょっと怪しい

**デフォルトの名無しさん** · 2024/09/10(火) 23:12:42.09

それで言うなら>>804のほうが明らかに言葉足りてないがなあ
まあよく分からんなら反応すんなってこった

**デフォルトの名無しさん** · 2024/09/10(火) 23:22:45.87

RcはC++にないけどArcがC++のshared_ptrだよ
だから複数所有者については新規性がなくて
Rustが強いのはスタック上かヒープ上かに関係なく両者への参照を混ぜても安全に扱えるようになったことだよ
これでスタック上の活用の幅が広がりさらに速くなった

**デフォルトの名無しさん** · 2024/09/10(火) 23:33:27.03

>>805は元々の認識の方が合ってて、>>804の説明で混乱したと思われる

**デフォルトの名無しさん** · 2024/09/10(火) 23:38:50.48

複オジの読解力不足&的外れはいつものことだろ
騙されるやつにも問題あるんだからもうほっとけよ

**デフォルトの名無しさん** · 2024/09/10(火) 23:41:27.35

C++ではヒープの解放責任が安全性の対象だった
Rustはそれに加えて複数の安全性を導入している
ヒープかスタック上かに関わらずそれらへの参照の有効安全性がその一つ

**デフォルトの名無しさん** · 2024/09/10(火) 23:48:29.99

真正アスペかな

**デフォルトの名無しさん** · 2024/09/10(火) 23:49:26.48

造語してる暇があったらちゃんとイチからC++学ぼうや、じゃないと他人に伝わる言葉で比較することもできんやろ

いや、別にできなくてもいいのか、なんとなくそれっぽい感じのこと書けるならそれで

**デフォルトの名無しさん** · 2024/09/10(火) 23:56:12.12

C/C++がダメなところでもっと重要な点はsingle writer xor multi readersのデータ競合安全性がないところだろ
例えばこれ

std::vector<int> v{0, 1, 2, 3, 4, 5, 6, 7};
int *p5 = &v[5];
assert(v[5] == 5); // OK

*p5 = 123;
assert(v[5] == 123); // OK

v.push_back(8);

*p5 = 456; // p5がまだ使えるので使おうとすると
assert(v[5] == 456); // NG このアサートは通らない

**デフォルトの名無しさん** · 2024/09/11(水) 00:27:46.41

１つのTの値に対するRc<T>はcloneすることで複数存在できるけど
特定のRc<T>を介したその値の参照（&T）はそのRc<T>の生存期間しか使えない
この&Tもいくらでもコピーできるけど同じRc<T>の生存期間に縛られる

T（ヒープ）
↑
Rc<T>（主にスタック上だけどヒープも可）
↑
&T（同上）

みたいに二段階で参照してて
TはRc<T>が全部消えるまで残り続けるけど
&Tは仲介してる特定のRc<T>が存在する間しか使えない

C++のshared_ptrに近いけど使われ方（コピーor複製の戦略）は微妙に変わるかもしれない

**デフォルトの名無しさん** · 2024/09/11(水) 00:51:54.05

>>828
正確にはRc<T>のDerefにより生じる&TがTを直接指すので参照を使うコストや利便性は普通の&Tと同じコストゼロ
そのDerefの時にRc<T>を借用しているため&Tはそれより長生きできず安全性が保たれる
C++で例えるとshared_ptr.get()で直接ポインタを取り出したのと同じなのでカウンタ増減もなくコストはかからない
C++でこれはリスクの高い要注意の行為だがRustでは上述のように安全性とコストゼロを両立させている

**デフォルトの名無しさん** · 2024/09/11(水) 01:53:23.49

声かけで特殊”複”詐欺を未然に防止
5ch有志らに感謝状

**デフォルトの名無しさん** · 2024/09/11(水) 07:05:44.53

>>827
vectorにpush_backして再配置でアドレス変わったんだから当たり前でしょ。それが嫌ならstd::listでも使えば

**デフォルトの名無しさん** · 2024/09/11(水) 07:19:25.98

>>831
Rustではコンパイルエラーとなって未然に防いでくれるから
C++の欠陥の一つだと思うよ

**デフォルトの名無しさん** · 2024/09/11(水) 08:14:31.51

>>832
まともなプログラマはこんな処理書かねーよ
もっとありそうな例だしてくれないかな

**デフォルトの名無しさん** · 2024/09/11(水) 08:40:17.21

しかもasan出て久しいのに、この人ら>>827,832 時間止まってる?

**デフォルトの名無しさん** · 2024/09/11(水) 08:58:17.83

>>827は簡単な例だからデータ競合を起こしてp5がダングリングポインタとなってることに気づくけど
もっと複雑な状況だと気づかずに実行してしまいデバッグでハマるパターンでもある
それをコンパイル時点で指摘してくれるRustは開発効率いいね

**デフォルトの名無しさん** · 2024/09/11(水) 09:10:35.02

>>835
本当にsanitizer知らないレベルだと言語以前の問題
全てが効率悪そう

とんでもないスキルイシューの塊だから
RustでGPLロンダリングしていると吹聴するレベルなんだな

**デフォルトの名無しさん** · 2024/09/11(水) 09:13:53.53

C++はそういう欠陥言語だから仕方ないかと

**デフォルトの名無しさん** · 2024/09/11(水) 09:28:04.51

Rustは安全でC++は危険というきれいな比較図式が成り立たなくなるので、C++さんサイドは静的解析だの動的解析だの姑息な手段を使わないでください
同じ理由でunsafe Rustも自分で書くのは禁止です

**デフォルトの名無しさん** · 2024/09/11(水) 09:43:51.82

「RustでGPLロンダリング」するのも禁止です

「RustでGPLロンダリング」と検索するのも禁止です

**デフォルトの名無しさん** · 2024/09/11(水) 09:56:40.10

>>827
C++コンパイラはpushの後になぜp5を無効にできないの？

**デフォルトの名無しさん** · 2024/09/11(水) 10:26:06.00

予めreserveしてpush_back後も安全にアクセス出来る

**デフォルトの名無しさん** · 2024/09/11(水) 10:27:11.35

>「RustでGPLロンダリング」するのも禁止です

こっちは茶化すなよw

**デフォルトの名無しさん** · 2024/09/11(水) 10:30:47.07

それpushしまくってる途中でreserve超えてvectorが再配置されてダングリングになるバッドパターン

**デフォルトの名無しさん** · 2024/09/11(水) 11:08:50.53

「境界検査は不要」とか「ループの終端検査に集約されるため消える」とか嘘バラまいてる奴が一番unsafeだよねー>>843

**デフォルトの名無しさん** · 2024/09/11(水) 11:25:15.06

落とし穴だらけのC++

**デフォルトの名無しさん** · 2024/09/11(水) 12:02:27.80

死ぬまでｾﾌｾﾌやってんのん

**デフォルトの名無しさん** · 2024/09/11(水) 12:23:08.35

808ですが
>>804の指摘は間違っていることに気づきました
ごめん…

**デフォルトの名無しさん** · 2024/09/11(水) 13:13:12.77

>>847
どこが間違ってる？

**デフォルトの名無しさん** · 2024/09/11(水) 13:51:56.28

人として間違ってる

**デフォルトの名無しさん** · 2024/09/11(水) 18:25:07.18

次スレよろ

**デフォルトの名無しさん** · 2024/09/12(木) 12:20:06.38

Rust の borrow を日本語で参照と
逝ってる人が多いのは木の精か

**デフォルトの名無しさん** · 2024/09/12(木) 12:20:42.74

木の精だな

**デフォルトの名無しさん** · 2024/09/12(木) 13:28:12.61

Primitive Type reference &T and &mut T
https://doc.rust-lang.org/std/primitive.reference.html
A reference represents a borrow of some owned value.
You can get one by using the & or &mut operators on a value, or by using a ref or ref mut pattern.
References have a lifetime attached to them, which represents the scope for which the borrow is valid.

**デフォルトの名無しさん** · 2024/09/12(木) 15:10:13.30

borrow は貸借

**デフォルトの名無しさん** · 2024/09/12(木) 16:35:38.17

いちいち漢語使うなよ
貸す、借りるでいいだろ

**デフォルトの名無しさん** · 2024/09/12(木) 16:59:56.29

borrow は桁借り

警備員[Lv.5][新芽] · 2024/09/12(木) 21:13:06.55

借りてboroboro。70年代のネタあるね

**デフォルトの名無しさん** · 2024/09/12(木) 21:33:10.32

Rustを学習していてよくわからなくて、大きく2点について教えて欲しいんだけどさ
1 参照型で含まれるポインタ相当部分を可変、参照先のデータを不変にすることってできるの？
2 構造体Aのフィールドに構造体Bがあるようなとき、(I)A可変・B不変だった場合、(II)A不変・B可変だった場合、それぞれどの範囲で可変・不変になるの？

**デフォルトの名無しさん** · 2024/09/12(木) 22:20:10.46

>>858
1. できる
let vec = vec![];
let mut xs= &vec;
xs.push(100); // Error

let vec2 = vec![1, 2, 3];
xs = &vec2; // OK

**デフォルトの名無しさん** · 2024/09/12(木) 22:39:45.93

>>858
2. 変数のmutabilityはownership treeの最上位にある変数(owner)のmutabilityに従う
なのでAが可変ならBも可変、Aが不変ならBも不変
ただし、RefCell等のinterior mutabilityの仕組みを使えばAが不変でもBを変更することは可能

&Tと&mut Tという参照の型のmutabilityと
let mut xのような変数のmutabilityと関連はあるけど別のものなので分けて考えたほうがいい

**デフォルトの名無しさん** · 2024/09/12(木) 22:48:18.57

>>858
2:
構造体Aが構造体Bの参照を持つという話なら、Aのmutabilityは「参照先を変更できるか」に関係し、Bのmutabilityは「参照先の値を変更できるか」に関係する

struct B {data: i32}
struct A {bref_1: &B, bref_2: &mut B}

let b1 = B::new();
let mut b2 = B::new();
let b3 = B::new();

// a1 は不変なので参照先を b3 に変えることはできない、
// b2は可変参照なので a1.bref_2.data = 1 のような操作はできる
let a1 = A::new(&b1, &mut b2);

// a2 は可変なので参照先を b3 に変更できる
// フィールドb1は不変参照なので a2.bref_1.data = 1 のような操作は不可
let mut a2 = A::new(&b1, &mut b2);
a2.bref_1 = &b3;

構造体Bを参照ではなく値型のフィールドとして持つという意味なら、Rustは (C++のconstのように) フィールドごとにmutabilityを指定する方法はないので、Aのmutabilityに従う
回避する方法として RecCell や Cell, Mutex といった型がある (これは C++のmutableみたいなものだけど、より厳格にチェックされる)

**デフォルトの名無しさん** · 2024/09/12(木) 22:55:09.24

個人的な意見だけど参照先を変える場面ってあまり無い気がする
「aをmutなしに宣言しているのにaが参照するbの内容を変更できる」ことに少し違和感があるかもしれないけど、それはフィールドの型を &mut で指定しているからそういうもの

**デフォルトの名無しさん** · 2024/09/12(木) 23:04:50.13

> struct A {bref_1: &B, bref_2: &mut B}
書き忘れたけど上記はライフタイム注釈を付けないとコンパイルに失敗する

**デフォルトの名無しさん** · 2024/09/12(木) 23:35:16.53

>>858
Rustの不変・可変はデータ競合を避けて安全性を保証するためにあるため
以下の単純なルール
・値は別の変数等へムーブ(・コピー)することでいつでも不変↔可変にできる
・参照は可変参照→不変参照は可能だが不変参照→可変参照にはできない
・不変参照しかなくてもMutexなど内部可変性を提供するものは排他制御しながら内部を可変に扱える

struct Foo(i32);
let f1 = Foo(100); // 不変
let mut f2 = f1; // ムーブして可変
f2.0 = 111; // 書き換えOK
let r1 = &f2; // 不変＆不変参照
let mut r2 = r1; // 可変＆不変参照
r2 = &mut f2; // 可変＆可変参照→不変参照になる
// r2.0 = 234; // 不変参照なので書き換えられずエラー
let r3 = &mut f2; // 不変＆可変参照
r3.0 = 234; // 可変参照なのでOK
let mut r5 = r3; // 可変＆可変参照

**デフォルトの名無しさん** · 2024/09/13(金) 13:37:30.00

struct A {bref_1: &B, bref_2: &mut B}

lifetime無いとだめなんじゃね

**デフォルトの名無しさん** · 2024/09/13(金) 13:38:15.45

>>863
ああ断りがあったわスマソωωω

**デフォルトの名無しさん** · 2024/09/13(金) 13:47:53.90

なんていうか
質問が曖昧な時ってどういうことか問い直すだけで曖昧さが消えて勝手に解決することのほうが多いんじゃないかって

**デフォルトの名無しさん** · 2024/09/13(金) 13:49:36.00

moveされたものはともかく
copyされたものが可変になっても嬉しくないパターンが多い

**デフォルトの名無しさん** · 2024/09/13(金) 13:51:25.85

unsafe {
参照は
可変参照→不変参照は可能
不変参照→可変参照も可能
}

**デフォルトの名無しさん** · 2024/09/13(金) 14:55:43.09

OpenAIが複雑な推論能力をもつAIモデル「OpenAI o1」と「OpenAI o1-mini」を発表、プログラミングや数学で高い能力を発揮
https://gigazine.net/news/20240913-openai-o1/

**デフォルトの名無しさん** · 2024/09/13(金) 16:25:09.37

>>617
>NimはCより2倍速いと主張している人がまずはその比較コードとベンチ結果を示す義務がありますよ

下記のNim2.0ベンチマークより速くできなかったら、今度こそ本当にRustはNim2.0より劣る言語と理解してもよろしいでしょうか？
Rustは変数の所有権や借用を開発時に考慮する必要があり、とても学習コストが高いです。

Nim2.0ではコンパイラがソースコードを解析し、スコープと所有権に基づくメモリ管理を開発者が考える必要がなく自動で行います。

Nim2.0では開発者はプログラムをスクリプト言語のように書け、所有権や変数の寿命を意識する必要はありません。
しかし内部ではRustと同じメカニズムでメモリ管理を行っています。

フィボナッチ数列(回帰関数)のベンチマークはNim 2.0がダントツの速さでした
fibonacci(44)の計算

Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
https://wandbox.org/...ink/cpYesJtnlRNJiu7Z
>Time= 0.197s Result=701408733

Nim(44はコマンドライン引数)
https://wandbox.org/...ink/WoYP0STRKxaRBGCY
>Time= 0.240s Result=701408733

C/gcc(44はソース直書き)
https://wandbox.org/...ink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang(44はソース直書き)
https://wandbox.org/...ink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

**デフォルトの名無しさん** · 2024/09/13(金) 16:48:36.51

>>871
リンク訂正

fibonacci(44)の計算

Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/cpYesJtnlRNJiu7Z
>Time= 0.197s Result=701408733

Nim 2.0.0 + gcc 12.2.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u
>Time= 0.250s Result=701408733

C/gcc -O2 (44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang -O2 (44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

**デフォルトの名無しさん** · 2024/09/13(金) 18:49:24.01

これは荒れるぞ…！

**デフォルトの名無しさん** · 2024/09/13(金) 18:54:08.50

C言語よりNimが4倍速いと確定
メモリ管理に優れたNimはフィボナッチ計算でも速い

**デフォルトの名無しさん** · 2024/09/13(金) 20:47:19.98

低知能さんは即NGされるだけやで

**デフォルトの名無しさん** · 2024/09/13(金) 21:30:58.64

https://wandbox.org/permlink/EZG1tVHViP2HfZsH
Time=0.00000s Result=701408733

シンプルな書き方ではなくなるけど、ちゃんと最適化すると早くなるぞ
(nimでも同じことはできるかもしれないが)

元のコードでもCの方はインライン化されてるのかが気になった
inline 付けるとエラーになる (wandbox の仕様？不具合？) から試せなかったけど

**デフォルトの名無しさん** · 2024/09/13(金) 22:25:18.35

う～ん高知能

**デフォルトの名無しさん** · 2024/09/13(金) 22:29:46.65

普通に書いてCの4～5倍速いNimが最速プログラミング言語でよろしいでしょうか？

**デフォルトの名無しさん** · 2024/09/13(金) 22:42:17.50

マイクロベンチマークは特性の把握に使うものであって優劣を決めるものじゃないよ。
単純な再帰の速度を計測してわかるのは単純な再帰のときの速度だ。
それが想定するユースケースにマッチしてるならそれでもいいけど……。
フィボナッチ数を計算するのが Nim の典型的な用途ってわけじゃないだろ？

警備員[Lv.29] · 2024/09/13(金) 22:52:41.76

nimってCに落とすんじゃ無かったっけ？

**デフォルトの名無しさん** · 2024/09/13(金) 22:56:11.85

Nimはメモリ管理が良いという話なら、ヒープを使わないコードで比較しても意味がないと思う
再起呼び出しの速さだけ見て何になるんだ

**デフォルトの名無しさん** · 2024/09/13(金) 23:00:41.14

>>880
Nimが吐いたCコードを見ると謎が解けるわけだ
ちゃんと再起呼び出し計算しているのかとうか

**デフォルトの名無しさん** · 2024/09/13(金) 23:12:47.89

Cの4-5倍も速いのに全く普及する気配がないのは何故かを気にしたほうがいいと思うけど…

**デフォルトの名無しさん** · 2024/09/13(金) 23:13:27.70

俺環(Nim2.0.8)だと-d: dangerで-O3になる
Cを同じ-O3にすると所要時間はほぼ同じになる(ややCのほうが高速)
-d:releaseと-O2で比べるとNimのほうが有意に遅い

pragmaとコンパイルオプションと環境を揃えればそんな差が出るわけがない

**デフォルトの名無しさん** · 2024/09/13(金) 23:18:25.01

生成されたCのコードはNimのコンパイラ作ってる人間ならともかく普通の人間が読むのはキツイな

**デフォルトの名無しさん** · 2024/09/14(土) 00:15:56.82

https://wandbox.org/permlink/MN8P2xOdeXQRYrEB
関数呼び出しコストの話とはあんま関係ないけど、小さな再帰関数なら数段分を別関数に分けると爆速になるという気づきを得た
たぶん数段分がひとつの関数内にインライン展開されてる

**デフォルトの名無しさん** · 2024/09/14(土) 01:41:16.01

structoptクレート外したら、リリースビルドで2.5MB小さくなった
たかがオプション解析でコードサイズでかすぎだろ

**デフォルトの名無しさん** · 2024/09/14(土) 13:43:40.74

>>872
糞リンク貼ってると誰の自演かバレるなω

**デフォルトの名無しさん** · 2024/09/14(土) 13:46:57.51

Nimが、Cのトランスパイラのままなら、
Cを超えることは、出来ないんだけど。
C以外との比較なら、まだわかる。

**デフォルトの名無しさん** · 2024/09/14(土) 14:59:24.39

Rust の std::sync::atomic::fence って C++ の std::atomic_thread_fence 相当？

**デフォルトの名無しさん** · 2024/09/14(土) 18:16:26.88

C/C++コードをパクろうとしているか？

RustでGPLロンダリングするな

**デフォルトの名無しさん** · 2024/09/14(土) 18:32:44.15

メモリモデルが C++ のパクリだしそっちのほうが資料が豊富なんだからしょうがないじゃん

**デフォルトの名無しさん** · 2024/09/14(土) 19:17:14.39

そんなことよりCarbon Languageの話をしようぜ

**デフォルトの名無しさん** · 2024/09/14(土) 20:13:02.31

スレチ

**デフォルトの名無しさん** · 2024/09/15(日) 09:30:53.13

Rustでreplaceするとロンダ楽なのか
良い話を教えてもらった

**デフォルトの名無しさん** · 2024/09/15(日) 13:04:00.82

specialization って unsound なんですか？

**デフォルトの名無しさん** · 2024/09/15(日) 14:09:53.01

full specializationはunsoundな問題を抱えている
それが君の言う「specializationはunsound」の定義なら答えはyes

**デフォルトの名無しさん** · 2024/09/15(日) 14:54:57.41

Nimって初めて聞いたけどCのコード出力するんか
ならNimがCより早い、じゃなくてNimがおまえより早い、じゃね？

**デフォルトの名無しさん** · 2024/09/15(日) 15:02:55.04

>>897
あっうん、それは分かってて聞いたんだ
具体的にどういうコードだと UB になるのか
それを回避しているらしい min_specialization はどういう制約が付いたサブセットなのか
そういうのが知りたかったかな……

**デフォルトの名無しさん** · 2024/09/15(日) 18:34:12.34

>>899
Tracking Issueを読んでね
特にまとめ的なこの2つのコメントを
https://github.com/rust-lang/rust/issues/31844#issuecomment-1712327948
https://github.com/rust-lang/rust/issues/31844#issuecomment-1707023896

**デフォルトの名無しさん** · 2024/09/15(日) 23:40:25.17

>>6
トヨタもRustかよ

**デフォルトの名無しさん** · 2024/09/15(日) 23:50:17.65

Rustのビルド中間ファイルってなんであんなにでかくなるの？
Tauri使ったちょっとしたツールで20GBぐらい行ったりする
LLVM使ってる言語はみんなそうなの？

**デフォルトの名無しさん** · 2024/09/16(月) 14:06:23.46

cargo clean
cargo update
これ毎回やってる

**デフォルトの名無しさん** · 2024/09/16(月) 14:06:47.97

Tauriは特に糞

**デフォルトの名無しさん** · 2024/09/17(火) 23:55:54.51

>>829
そこまで使い勝手が違うならshared_ptrとは別物と認識した方がよさそうだ

**デフォルトの名無しさん** · 2024/09/18(水) 11:56:36.10

Zigだんとつやんけ
ver1.0早う
github.com/kostya/benchmarks?tab=readme-ov-file#primes

**デフォルトの名無しさん** · 2024/09/18(水) 12:51:56.38

>>906
ソース見たらコストの高いハッシュ衝突安全性を必要としない計算ベンチでそれを使っているいつもの話だった
知識がないとそういうミスをしてしまいがち
他にもVecをインデックスでシーケンシャルアクセスしたりRustに不慣れすぎ