Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

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

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

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

**デフォルトの名無しさん** · 2020/12/24(木) 12:52:51.59

>>462
そりゃ細かいのはまだあるだろうが。HKTとか？
300件全部見る気もないのでやりたいなら自分でリストアップしてくれ

**デフォルトの名無しさん** · 2020/12/24(木) 13:18:18.43

>>463
453, 454 もその一部に書いてあったものだ。覚えているものだけでも：
・Rustでは、本質ではなくメモリーマネジメントが前面に出たプログラミングとなってしまう。
・もっと良いモデルで書こうとしてもRustが安全性を理解できずエラーになってしまう。
・unsafeモードは悪者扱いされた結果ドキュメントが乏しく進化も遅いため使いにくい。
・長い歴史で実績の有るクラスの継承や例外機構が使えない言語設計。
・抽象化が深すぎて最適化を前提としているので最適化しないと極端に遅い。
・抽象化が深すぎるしマクロが多用されているためデバッガが使いにくくprintfデバッグ中心で行かざるを得ない。
・正確で詳細な言語仕様に乏しいためシステムプログラミングや組み込みには向いていない。
・コンパイラの多様性に乏しい(今のところrustc一個しかない)。
・ターゲットCPUがLLVMのものに限られるため、組み込みには向いていない。
・グラフィックが弱い。
・OpenGL、DirectXと併用するのが難しい。
・コンパイルが極端に遅い。

まだまだある。

**デフォルトの名無しさん** · 2020/12/24(木) 13:20:42.91

>>464
[追加]
・抽象化が深すぎるため最適化無しでは極端に遅くなるため、デバッグ時も
　最適化しなくてはまともに動作確認できない。これもデバッガが使い物に
　ならなくてprintfデバッグ中心になる理由。

**デフォルトの名無しさん** · 2020/12/24(木) 13:35:19.50

>>465
[追加2]
・リンカをVC++のlink.exeに頼っている。
・ツール類がVC++に比べてとても貧弱(赤ちゃんのおもちゃ)。
・unsafeを使わないととても面倒なことが多い。
・C++では、newとdelete以外にはコンパイラが独自提供しているもの(Hooks)
　がないが、Rustでは大量に有る。例えば、Box<T>はソースがあるようにみえて
　実質はコンパイラ提供のものなので途中でソースがなくなっている。
・C++を含めた多くの言語では、コードの位置の任意の一部を切り取って関数化する
　ことは平易に機械的に(一般的に)できるが、Rustだと一般的には出来ない。
　なぜならRustのコードは、その文脈においてのみ有効なコードに過ぎないからである。
　文脈に応じて書き換えなければボローチェッカに文句を言われてコンパイルが通らない
　から。

**デフォルトの名無しさん** · 2020/12/24(木) 13:38:01.51

>>466
[追加3]
・「Rustは独断的な言語です。それは良いことも悪いこともあります。
　あなたがたまたまその意見に同意するならそれは良いことです、
　さもなければそれは信じられないほど迷惑です。」

**デフォルトの名無しさん** · 2020/12/24(木) 13:48:59.29

「システムタイプのプロジェクトでやらなければならないことの多くは、Rustでは実行できず、安全でないコードが必要になります。そしてもちろん、使用する基盤となるモジュールの多くには、安全でないコードが含まれています。したがって、ある意味で、メモリの安全性の約束は実際には真実ではありません。それらのいずれかが、現在または将来、コードの他の場所で量子力学的問題を引き起こす可能性のあるメモリの問題を抱えている可能性があります。もちろん、それを実行する可能性のあるコードの量を大幅に削減しますが、それでもかなりの量があります。」

「RustがC ++の句読点の爆発を起こし、さらに悪化させたように感じます。コードのコンパクトさは、読みやすさに比べてそれほど価値があるとは思いません。Rustはシステムの言語であり、SPAフレームワークではありません。それを速くすることは目標ではありません、それを正しくすることは目標です、そしてそれはそれを何年にもわたって書くよりもそれを読んで編集することに非常に多くの時間を費やすことを含みます。」

「コンパイラには、C ++よりも多くのライブラリへのフックがあります。大規模で完全にコヒーレントなシステムの構築に関心のある私たちの中には、それを困難にしている人もいます。C ++では、基本的に新しく削除され、他のすべては完全に自分で行うことができます。」

「Rustは、例外や継承など、何十年にもわたる成功を無視していると感じています。私は自分が書いているコードを見て、ほとんどすべての呼び出しが？で終わる場所で、手作業で効果的に例外を実行しています。そして、すべてのメソッドは、自動的に伝播される可能性のあるエラーを手動で返す必要があります。」

「Rustの安全規則は、より安全なコードを作成しようとする試みと戦う場合があります。」

**デフォルトの名無しさん** · 2020/12/24(木) 13:57:55.75

僕は絶対にミスはしませんって言って全部unsafeで包もうぜ

**デフォルトの名無しさん** · 2020/12/24(木) 14:21:36.07

>>464
> ・長い歴史で実績の有るクラスの継承や例外機構が使えない言語設計。

クラスの継承や例外機構は長い社会実験の末クソだったって結論出たろ。
だからGoだってわざわざ外してる。
C++にあるものを「実装できない」訳がないよな。わざわざ外してんだよ。

**デフォルトの名無しさん** · 2020/12/24(木) 14:28:12.73

読んだのか、凄いなw
しかし、スルー検定3級不合格です

**デフォルトの名無しさん** · 2020/12/24(木) 14:56:25.90

スル検は難関だからな。

**デフォルトの名無しさん** · 2020/12/24(木) 20:14:08.88

CやC++の批判で同じようにredditでコメント集めたらこんなもんじゃ済まないだろ

**デフォルトの名無しさん** · 2020/12/24(木) 21:01:24.33

c++と結局同じ道を辿ってるというところが一番愚かな点。
rust覚える早道が結局c/c++勉強することっていう。

**デフォルトの名無しさん** · 2020/12/24(木) 21:42:23.65

>>474
低IQだから最初の文と次の文の間の論理が読みとれないので
申し訳ないですがもう少し丁寧に説明して頂けないでしょうか

**デフォルトの名無しさん** · 2020/12/24(木) 21:44:10.79

FFIのデファクトとしてのC ABIはしょうがないけど
C++とか一切触れる必要ないだろ

**デフォルトの名無しさん** · 2020/12/24(木) 22:57:56.32

レディットの負け犬に反論する必要なくない
賢さでいったらポメラニアンと同じくらいの連中なのに

**デフォルトの名無しさん** · 2020/12/25(金) 01:07:22.65

所有権の重要さを実感するのは結局c++やってたやつだけだろ。
本当に一切c++触らないでrustだけで覚えたとかいう奴はいないわ。
いてもまともなコードは書けないだろう。

**デフォルトの名無しさん** · 2020/12/25(金) 02:44:51.30

>>475
俺はそいつじゃないが、二文は繋がってない独立した文。

**デフォルトの名無しさん** · 2020/12/25(金) 02:53:15.82

>>477
redditみたいなアメリカ最大の一般的な掲示板に書き込む人が皆、負け犬なんて
分けはない。
むしろSourceForgeみたいなところは、プログラミング関連の掲示板だから、
プライドだけが高くて力が無い人が集まることも有り得て、ずっと偏りが
あるため、負け犬率が高い可能性がありそこの好きな言語ランキング
なんて信用なら無い。

**デフォルトの名無しさん** · 2020/12/25(金) 02:56:53.96

はっきいり言って、2ch/5chでも人が大量に来る一般的な板は平均程度の
知的レベルはあるが、この板みたいな技術系の板は、なぜか平均より低い人が
集まりがち。
なぜならリアルで認めてもらえない人がストレスのはけ口のようにして
書いてくる率が高いから。
その意味でSourceForgeは一般人より馬鹿が集まり易く、redditは一般人と
同程度のレベルがある。
2ch/5chもニュース意が見たいなのは一般人と同じくらいの知的水準だが
プログラム技術板は一般人よりも何故か劣っている。

**デフォルトの名無しさん** · 2020/12/25(金) 02:59:57.47

githubも負け犬や雑魚が集まり易い。
有名な凄腕シェアウェア作家などはそんなとこに投稿せずに稼いでいる。
自分の腕ひとつでは稼げない人が、最後の手段としてなんとか名声を得てサラリーマン
として雇ってもらうためにgithubに投稿する傾向がある。
SourceForgeも同様。

**デフォルトの名無しさん** · 2020/12/25(金) 03:33:01.51

なんかそういデータあるんですか？

**デフォルトの名無しさん** · 2020/12/25(金) 04:00:24.23

糖質に構ってはいけません

**デフォルトの名無しさん** · 2020/12/25(金) 07:45:07.16

>>483
サンプル数1(自分自身)で100%という調査結果があるんだろう

**デフォルトの名無しさん** · 2020/12/25(金) 13:26:59.56

>>485
なんかそういうデータがあるんですか？

**デフォルトの名無しさん** · 2020/12/25(金) 19:42:11.03

>>486
サンプル数1(自分自身)で100%という調査結果があるんだろう

**デフォルトの名無しさん** · 2020/12/26(土) 02:24:44.32

結局C言語最強？
ならZetZも盛り上がる可能性ある？
https://www.infoq.com/jp/news/2020/05/zz-formal-verified-c-dialect/

**デフォルトの名無しさん** · 2020/12/26(土) 09:20:22.55

>>488
D言語でいう契約を静的に検証できるみたいな感じかな？いいね

**デフォルトの名無しさん** · 2020/12/26(土) 10:09:44.78

いいね
盛り上がりはしないとは思うけど…

**デフォルトの名無しさん** · 2020/12/26(土) 11:37:01.29

OSS界隈で盛り上がる感じはしないけど
自動車とかはそっちのほうが見込みありそう

**デフォルトの名無しさん** · 2020/12/26(土) 13:21:33.22

Vecのget()メソッドがi32とかも受け取ってくれればよかったのにとよく思う
結局、負方面については自分でインデックス内か検証しないといけないし

**デフォルトの名無しさん** · 2020/12/26(土) 15:29:03.87

extension traitとかnewtypeで拡張すればいいんでは？

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=1b575c52e97e24c3ae345e945ec7dbbd

**デフォルトの名無しさん** · 2020/12/26(土) 16:18:17.43

はえ～ありがとうございます！
これ標準ライブラリに採用してほしい（我儘）

**デフォルトの名無しさん** · 2020/12/26(土) 20:14:31.56

貴様だってnewtypeだろうに！

**デフォルトの名無しさん** · 2020/12/27(日) 03:56:05.63

小賢しいことを少年が言うのか！

**デフォルトの名無しさん** · 2020/12/27(日) 04:20:16.63

ガンダムハラスメントはやめてください

**デフォルトの名無しさん** · 2020/12/27(日) 13:57:50.83

たとえばこのように書いたときに

fn zero_bytes<T :Sized>() -> [u8; std::mem::size_of::<T>()] {
[0u8; std::mem::size_of::<T>()]
}

エラーとして

the size for values of type `T` cannot be known at compilation time

となってしまいます。
型の大きさに依存した配列を生成するには (実際にはコンパイル時に確定するはずでも)
Vec などを利用するしか仕方がないのでしょうか？

**デフォルトの名無しさん** · 2020/12/27(日) 16:28:27.67

>>498
配列の要素数はconstじゃないとだめだからジェネリックには今のところできないみたい
どこかで型を書かないと

const SIZE: usize = std::mem::size_of::<i32>();
let foo = [0u8; SIZE];

https://github.com/rust-lang/rust/issues/43408

**デフォルトの名無しさん** · 2020/12/27(日) 19:25:21.46

const fn, lazy_static のあたりは他の言語やってた人にはわかりづらいよな

**デフォルトの名無しさん** · 2020/12/27(日) 20:30:38.54

コンパイル時計算は最近の言語じゃ普通だけどな。
コンパイル時リフレクション使える言語も増えたし。

>>498
ttps://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e09bdfe4323f597481eae11421777cc3

ttps://rust-lang.github.io/rfcs/2000-const-generics.html
ttps://github.com/rust-lang/rust/issues/44580

一時間前にマージされたばかりで1.51.0のマイルストーン完了したからそのうちnightlyに来る。
ttps://github.com/rust-lang/rust/pull/79135

edition 2021には間に合うんじゃないの？

**デフォルトの名無しさん** · 2020/12/28(月) 02:45:21.79

Java では、class Foo{ Bar bar; } で済むところが、Rustでは以下の様な選択肢に悩まされる。

struct Foo { bar: Bar }
struct Foo<'a> { bar: &'a Bar }
struct Foo<'a> { bar: &'a mut Bar }
struct Foo { bar: Box<Bar> }
struct Foo { bar: Rc<Bar> }
struct Foo { bar: Arc<Bar> }

そして特に、'aの部分やBox, Rc, Arcの取り扱いやRcとArcの違いなどに悩まされる
ことになる。
これに加えて実践的にはOption, RefCellなどを何重にも組み合わせて使うことが必要となり
正しく理解するのはC++より遙かに難しい。

**デフォルトの名無しさん** · 2020/12/28(月) 02:52:18.54

>>502
ちなみに、plain Cの場合、
struct Foo { struct Bar *bar; };　// (1)
で済む。C++の場合、もちろんこれでもいけるが、
class Foo { Bar *bar; };　// (2)
1つでも特に問題ない。
uniqu_ptr<Bar>やshared_ptr<Bar>
も使えるが (2)で出来ないことは特に無いし、難しくも無く
Javaのclass Foo{ Bar bar; }
と使い勝手も余り変わらない。
違うのはbarが不要になった時に自分で deleteするだけで、
多くの場合、
class Foo {
　Bar *bar;
　Foo() { bar = NULL; }
　~Foo() { delete bar; }
};
と書けばよいだけで、これはパターンなので丸覚えでも良いし、意味の理解も
難しくも無く、悩むことも無い。
それに比べればRustが如何に複雑なことか。

**デフォルトの名無しさん** · 2020/12/28(月) 02:57:07.20

[補足]
C++の場合も、
class Foo { Bar *bar; };　// (1)
class Foo { unique_ptr<Bar> bar; };　// (2)
class Foo { shared_ptr<Bar> bar; };　// (3)
の選択肢は有るには有るが、常に(1)を使ってもコンパイルエラーに悩まされる
事はないし、できないこともなく、特に危険でもない。
ところがRustの場合、状況に応じて>>502のどれか一つしか選択できない
ことが多く、柔軟性に乏しい。
プログラムに僅かな変更があったときに、C++の場合、(1)なら修正が全く
必要がないが、Rustの場合は>>502のうちのどれかからどれかに修正しなくては
ならないことが多い。

**デフォルトの名無しさん** · 2020/12/28(月) 03:21:57.08

https://matklad.github.io/2020/09/20/why-not-rust.html
「Rust lacks an official specification. The reference is a work in progress,
and does not yet document all the fine implementation details.」
Rustは公式の使用が欠如している。
リファレンスマニュアルの作成は発展途上中(作成中、作業中、進展中)で、
しっかりした実装の詳細を全てドキュメント化してはいない。

Rustのコンパイル時間がとても長いことを直後に指摘した上で、
「A program written in a slower to run but faster to compile programming
language can be faster to run because the programmer
will have more time to optimize!」
実行速度が遅いがコンパイルが速い言語で書かれたプログラムは、
実際には速く実行できるようになる。
なぜなら、プログラマが最適化する時間をより沢山得ることが出来るためだ。

**デフォルトの名無しさん** · 2020/12/28(月) 03:37:08.29

現実のプログラムでは、CやC++とRustのプログラムを連携しなければならない
ということと指摘した上で、Cargoがそれを難しくしているかも知れないことを
指摘している:

「One specific gotcha is that Cargo’s opinionated world view
(which is a blessing for pure Rust projects) might make
it harder to integrate with a bigger build system.」

具体的には、Cargo主張する世界観（これは純粋なRustプロジェクトにとっては
幸いなことです）が、より大きなビルドシステムとの統合を
難しくしているかもしれないということです。

**デフォルトの名無しさん** · 2020/12/28(月) 03:48:47.51

「First, there’s no definition of Rust memory model, so it is impossible to
formally check if a given unsafe block is valid or not. There’s informal
definition of “things rustc does or might rely on” and in in-progress
runtime verifier, but the actual model is in flux. So there might be some
unsafe code somewhere which works OK in practice today, might be
declared invalid tomorrow, and broken by a new compiler optimization
next year.」

第一に、Rustのメモリモデルの定義がないので、与えられた安全でないブロック
が有効かどうかを正式にチェックすることができません。非公式な定義として、
"rustc が行う、または依存しているかもしれないこと "と、進行中のランタイム
ベリファイアがありますが、実際のモデルは流動的です。つまり、どこかに安全
でないコードがあるかもしれませんが、今日は問題なく動作していても、明日
には無効と宣言され、来年の新しいコンパイラの最適化で壊れてしまうかも
しれません。

**デフォルトの名無しさん** · 2020/12/28(月) 03:52:06.86

Second, there’s also an observation that unsafe blocks are not, in fact, modular.
Sufficiently powerful unsafe blocks can, in effect, extend the language. Two such
extensions might be fine in isolation, but lead to undefined behavior if used
simultaneously: Observational equivalence and unsafe code.

第二に、安全でないブロックは実際にはモジュール化されていないという観察もあります。
十分に強力な安全でないブロックは、事実上、言語を拡張することができます。
そのような2つの拡張は単独では問題ないかもしれませんが、同時に使用されると定義
されていない動作になります。観測的等価性と安全でないコードです。

Finally, there are outright bugs in the compiler.
最後に、コンパイラには明らかなバグがあります。
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3A%22I-unsound+%F0%9F%92%A5%22

**デフォルトの名無しさん** · 2020/12/28(月) 08:35:49.12

まあ大体その通りだわな。matkladはわかりやすい文章書くわ。

**デフォルトの名無しさん** · 2020/12/28(月) 11:36:31.94

スマートポインタ絶対に使いたくない理由はよくわからんが
rustでも生ポインタ使えばよいのでは

コンパイル時間についてはcraneliftと差分コンパイルの進化に期待かな

その他の議論については影響は限定的だし
影響を受けない領域でrustを使えば良いのでは
議論の俎上には挙がっているし徐々に改善されていくでしょう

**デフォルトの名無しさん** · 2020/12/28(月) 12:53:26.99

>>510
>その他の議論については影響は限定的だし
ところがC/C++が担ってきた領域ではそれが大問題になることが多いので
RustはC/C++の代替には成りえない。

>議論の俎上には挙がっているし徐々に改善されていくでしょう
少子化も日本の経済衰退も非常に何十年間も議論の俎上に上がっている
のに改善されていく気配は全く無いことからも分かる様に、
そんなことは一般的には成り立たない。

**デフォルトの名無しさん** · 2020/12/28(月) 12:58:19.94

>>510
>rustでも生ポインタ使えばよいのでは
Rustのsafeモードでは生ポインタは使えないんだが。

**デフォルトの名無しさん** · 2020/12/28(月) 13:13:50.09

>>512
実際に安全ではないので unsafe なのはあたりまえだが。
C++ のように常に危険なほうが良いなら C++ を使ってろよ。

**デフォルトの名無しさん** · 2020/12/28(月) 13:15:56.66

>>513
Rustはメモリーマネジメントの仕様がちゃんと公開されて無いので
C++よりずっと危険。

**デフォルトの名無しさん** · 2020/12/28(月) 18:08:21.04

>実行速度が遅いがコンパイルが速い言語で書かれたプログラムは、
>実際には速く実行できるようになる。

最近この苦情よく聞くんだけどどんなもんなの
コンパイル時間のボトルネックなんて
考える時間に比べたらたいしたことなくない
何十分もかからんだろ

**デフォルトの名無しさん** · 2020/12/28(月) 18:22:47.18

お前が弄る小さいプログラムではそうなんだろうね。

**デフォルトの名無しさん** · 2020/12/28(月) 18:27:17.21

どんなん

**デフォルトの名無しさん** · 2020/12/28(月) 18:58:25.81

CIとかでめちゃくちゃ時間かかるのはRustの醍醐味

**デフォルトの名無しさん** · 2020/12/28(月) 19:03:06.03

>>515
今のRustコンパイラはコア数で良くスケールするので
開発用の32コアマシンなら快適だけど、古いノートPCだと辛い、みたいなことはあるな
Actixみたいに大量の依存関係を要求するやつ+しょぼいシングルコアなら数十分かかるかもね

**デフォルトの名無しさん** · 2020/12/28(月) 19:27:10.85

個人的にはクレート単体で遅いと思ったことはなくて、体感では数万行のコードでもgccより速いかな、という感じ
なので遅い要因はほぼ依存関係の多さだと思っている

C++とかだと特定のディストリビューションの特定のバージョンでコンパイルエラー、みたいな地獄のデバッグが待っているので、それを回避するコストとしては十分安いと思うけど

**デフォルトの名無しさん** · 2020/12/28(月) 22:08:45.00

今の方法だとまだ依存crateのコンパイル待ちになるのにスケールする？
>>518に尽きる

**デフォルトの名無しさん** · 2020/12/28(月) 22:37:04.04

>>521
もちろん完全に直列な依存関係はスケールしないよ
もしそういうクレートがあるなら分割すれば改善するかもしれないし
具体的に挙げて欲しい

**デフォルトの名無しさん** · 2020/12/29(火) 01:19:43.87

>>520
>個人的にはクレート単体で遅いと思ったことはなくて、体感では数万行のコードでもgccより速いかな、という感じ
C言語のコンパイル意が遅くなるのは、Win32のヘッダファイルの巨大さが原因
であることが多い。
それが50MB位有ったりして、ヘッダファイルだけで数万行から数10万行くらいあったりする。
そのパースが遅い。
なので、VC++では precompiled header を使っている。

**デフォルトの名無しさん** · 2020/12/29(火) 08:29:57.63

cとc++じゃコンパイル速度は桁違いだけどな。

**デフォルトの名無しさん** · 2020/12/29(火) 10:56:10.54

ライブラリの依存関係を自動で解決するエコシステムがあると
依存関係が巨大になりがちっていうのは
Haskell や JavaScript でもよく聞くけどな。

まあ自分でそのライブラリ群を書く手間、
既存のものを使うにしても導入の仕方を調べる手間に比べたら
多少の時間はかかっても自動でやってくれるほうがマシではあるし、
度を越したときは個別に改善するしか仕方がないんだろう。

**デフォルトの名無しさん** · 2020/12/29(火) 15:03:36.81

依存関係のコンパイルは初回しかやらないんだから多少遅くても気にはならない
CIの場合はtargetディレクトリキャッシュすれば良いし
rust-analyzerの起動時間がちょっと気になるくらい

**デフォルトの名無しさん** · 2020/12/29(火) 23:35:14.28

>>522
昔より増えたapiとimplを分離したクレートは

自分のプロジェクト->api->impl->implが依存するcrate(s)->...

と直列に依存してる。log,slog,serde,thiserror,webrender(etc.)
それに直列に依存するかどうかよりcargoもrustcのフロントエンドもまだ並列化対応が部分的でコンパイル単位の粒度が大きいのが並列ビルドの妨げになるでしょ。

>>526
CIはたしかにキャッシュが効けばいいけど、アナライザの話なら初回しかやらないことはないよ。
アナライザの場合は解析結果が無効になるたびに起きる。
intellij rustはプロジェクト開くたびにやってるし。
JDTみたいにon the fly analyzeするとソースコード変更するたびに解析するから依存グラフは使い回せても他は都度、解析する必要がある。

**デフォルトの名無しさん** · 2020/12/30(水) 00:32:35.13

>>527
言葉足らずですまん
(解析結果をメモリ上にしか持たない設計だから起動時に解析を全部やり直す)rust-analyzerの起動時間が気になるくらい(がコンパイル時間に関して気になる点)
と言いたかった

**デフォルトの名無しさん** · 2021/01/01(金) 09:10:16.97

#![feature(min_const_generics)]だけじゃなく#![feature(const_generics)]も2021に入って欲しいな

**デフォルトの名無しさん** · 2021/01/01(金) 12:06:39.72

全く話は変わるけど、メモリ不足で Box::new に失敗したら、panicが起きて
プログラムがそこで停止するだけ？

**デフォルトの名無しさん** · 2021/01/01(金) 12:08:13.77

>>530
仮にそうだとすると、Cのmalloc()やC++のnew TYPEに比べるとエラー処理は
省ける反面、エラー処理を書きたくてもかけないね。
まあ、滅多に起きないので書いてもしょうがないけれども。

**デフォルトの名無しさん** · 2021/01/01(金) 12:36:28.83

*C++
TYPE *ptr = new TYPE; //メモリ不足の場合ptrにはNULLが返される。
*Java
TYPE obj = new TYPE; //メモリ不足の場合例外がthrowされる。
*Rust
Box<T> obj = Box<T>::new(T()); //メモリ不足の場合panicが生じアプリがダウンする。

Rustは、高度な安全性を要する分野や組み込みでは困るかも。
それに記述が長い。

**デフォルトの名無しさん** · 2021/01/01(金) 12:40:33.89

C++のnewはメモリ不足のとき通常は例外が送出されるぞ
メモリ不足でnullptrを返すにはnew(nothrow)にしないといけない

**デフォルトの名無しさん** · 2021/01/01(金) 12:54:35.66

>>533
昔、
TYPE *ptr;
if ( (ptr = new TYPE) == NULL ) {
　printf( "Memory allocation erro has occured.\n" );
}
みたいに書いていたことがあるけど、これは昔のC++でも間違っていたのだろうか？

**デフォルトの名無しさん** · 2021/01/01(金) 12:57:46.63

Javaは、例外をthrowする関数を呼び出した場合、必ずtryブロックで囲むか、
または、呼び出しもとの関数の宣言の最後にthrow/throws属性をつけるかしないと
いけないんだけど、なぜかnew演算子の場合だけはこの規則の例外で、
tryブロックで囲むこともthrow/throws属性を付ける必要も無いらしい。
ただし、tryブロックで囲んでcatch文でOutOfMemoryErrorという例外を
捉えることは出来るらしい。
意外と良く考えられていて、便利そう。

**デフォルトの名無しさん** · 2021/01/01(金) 17:48:44.20

検査例外等も知らない人が言語仕様にケチつけるなよ

**デフォルトの名無しさん** · 2021/01/01(金) 18:19:22.53

知識が無くてもそれが使いにくいことが分かる人もいれば、
知識があってもそれが使いにくいことが分からない人もいる。
その差はイマジネーションや経験や頭の良さの差。

**デフォルトの名無しさん** · 2021/01/01(金) 19:06:09.23

知識も経験もイマジネーションも頭の良さもない
お前さんどうすんの？

**デフォルトの名無しさん** · 2021/01/01(金) 19:06:27.88

20年以上前？のC++だとNULLが返ってきてたみたいだな
C++98の頃には例外が投げられてる

**デフォルトの名無しさん** · 2021/01/01(金) 19:07:24.81

出た、”地頭”信者ｗ

**デフォルトの名無しさん** · 2021/01/01(金) 19:20:38.81

Rustのpanicはスレッド単位ですよ

**デフォルトの名無しさん** · 2021/01/01(金) 19:55:37.74

プラットフォームにもよるのでは
panic=abort
しかない環境もある

**デフォルトの名無しさん** · 2021/01/01(金) 22:11:27.78

かなり初歩的な質問で申し訳ないんだけど、例えばHashMapをイテレータで舐めてるときに内部でそのHashMapを更新したいときはどうするのがベストなの？
例えば次のようなケースではどうすれば……

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=f6c554ab761450881f28e48faa55bf8c
use std::collections::HashMap;
fn main() {
let mut map: HashMap<_, _> = HashMap::new();
for i in -5..=5 {
map.insert(i, i);
}

for (key, value) in map.iter() {
if *value == 0 {
continue;
}
if let Some(another_value) = map.get_mut(&(-key)) {
// keyの絶対値が同じものを処理して、処理済みにする気持ち
*another_value = 0;
}
}
}

**デフォルトの名無しさん** · 2021/01/02(土) 00:25:45.81

>>543
map.iter() を map.iter().cloned().collect::<Vec<_>>() にする

**デフォルトの名無しさん** · 2021/01/02(土) 00:53:14.75

keyの絶対値が同じものでgroupingしてからイテレート

**デフォルトの名無しさん** · 2021/01/02(土) 02:08:00.06

rust的にはそういうことしないのがベストじゃない
俺だったらキーだけ取り出してループさせる

**デフォルトの名無しさん** · 2021/01/02(土) 09:20:56.29

>>544-546
ありがとう！
しかしRust的には褒められたやり方じゃないんだね
LL言語脳から切り替えないといけないなあ

**デフォルトの名無しさん** · 2021/01/02(土) 14:15:48.62

逆に-keyで絶対値にする言語とかあんの？
Rustではkey.abs()だぞ

> keyの絶対値が同じものでgroupingしてからイテレート
ソース見る限り元キーはそのままで{-1: 0, 1: 0}みたいにしたそうだからグルーピングでは絶対値にキー統一されるからダメだね

**デフォルトの名無しさん** · 2021/01/02(土) 15:20:56.88

>>543
イテレータを回してるときに内部でそのcollectionをいじくる一般的な方法を聞きたかっただけで、そのコードはただ説明のためのモックなのでコードの妥当性とかはどうか気にしないでください……

**デフォルトの名無しさん** · 2021/01/02(土) 16:10:45.39

これは個人的な解釈だけど、ループ中にコレクションをイジるのを許可すると要素の追加削除も許可されるので、動作が想定しにくいから言語に関わらずやるべきじゃないと思う

**デフォルトの名無しさん** · 2021/01/02(土) 17:40:37.90

有名なアルゴリズムでも破壊的に処理を進める物は少なくないから
それらをリソースを押さえたままより安全に実装するかという問題はある

**デフォルトの名無しさん** · 2021/01/02(土) 20:33:28.09

単純に破壊的操作とイテレータの組み合わせが良くないんだと思うけどね
基本的なアルゴリズムの実装でならC++でも大抵インデックスアクセスするし

**デフォルトの名無しさん** · 2021/01/03(日) 01:40:10.34

絶対値で比較されるようなkeyの型を用意してBtreeMapにぶちこんでiter_mut()すれば
絶対値が同じキー同士は連続して現れるからうまいことやればやりたいことはできるのでは
コード複雑になりそうだけど

**デフォルトの名無しさん** · 2021/01/03(日) 02:42:58.53

>>550
C++狂い「安全性よりも論理的、数学的に正しいかが重要」

**デフォルトの名無しさん** · 2021/01/03(日) 15:16:13.09

Rustで大量の敵が同時に出現する2Dゲームを作ろうと考えています。
Amethyst、ggez、Bevyの中で最もおすすめのゲームエンジンはどれでしょうか？

**デフォルトの名無しさん** · 2021/01/03(日) 15:58:43.30

イニダン亡き後の移住先か…！

**デフォルトの名無しさん** · 2021/01/03(日) 17:51:55.22

スライムが5000匹現れた！

**デフォルトの名無しさん** · 2021/01/03(日) 20:23:57.03

>>552
まあ通常そういう場合はint値でモロにインデックスアクセスするわな。
これがrustとは全く馴染まない。

**デフォルトの名無しさん** · 2021/01/03(日) 21:45:20.19

single writer or multiple readerのモデルに沿うようなロジックに変換するか
interior mutabilityを使うかのどちらか

**デフォルトの名無しさん** · 2021/01/05(火) 22:41:10.79

>>555
個人的にはAmethyst。
なぜなら俺が個人的にECSアーキテクチャが大好きだから。
小さなプロジェクトに向かないとか言われるけど知らないそんなの。

**デフォルトの名無しさん** · 2021/01/05(火) 23:32:43.62

RustでTDみたいなブラウザゲー作った猛者おりゅ？

**デフォルトの名無しさん** · 2021/01/08(金) 08:35:58.68

なんでこんなゴミを100M単位でボコボコダウンロードせなならんのや

ゴミ