Rust part20

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 11/12 15:27 / Filesize : 289 KB / Number-of Response : 1017
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part20

1 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 00:45:28.73 ID:vTVY069B.net]: 公式
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 part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/
577 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 03:35:24.21 ID:mYje0a9y.net]: >>563
それは言語の書きやすさではなく
その個人が慣れか不慣れかだろ

言語の書きやすさはその言語に十分慣れた上で
言語の機能が不足していて書きにくい点がないかどうかなどで決まる
その比較例だとJavaとRust両方に慣れた人たちにとって全員がJavaに❌をつける
578 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 04:14:00.36 ID:PASEDR7I.net]: 別の言語を長くやってても面倒臭いなって思う点は出てくるじゃん
例えばJavaやってるとC#のあの機能欲しい
なんでJavaには追加されないんだろとかさ
579 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 04:15:46.17 ID:mYje0a9y.net]: だから全員がJavaに✕をつける
580 名前：デフォルトの名無しさん [2023/06/07(水) 10:36:40.93 ID:o7otWeXk.net]: >>563
わかるやん、てあなたが勝手に言ってるだけですやんw
581 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 15:06:17.70 ID:3M1fBRd0.net]: でも、多数決では、Rustが最下位なんだよな。
582 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 15:44:42.75 ID:3M1fBRd0.net]: Rustの問題点を指摘すると、「それはあなたが・・・」
「馬鹿だから」「老害だから」「じじいだから」「化石みたいな人だから」
みたいな事言って人いるけど、それは
「若くて頭のいい人々が使うんだから、老害/馬鹿は黙っとけって」ことになるが、
それでは一般人に普及する言語には成れないであろう。
そもそも、高級言語の目的とは、簡単に安全にやりたいことが出来ると言う
ことであり、しかも、一部の人を除いては簡単にも思えないようなものであっては
普及は遠い。
583 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 15:54:04.41 ID:3M1fBRd0.net]: >>565
あなたは、そうやって、ここで、市場調査をして、次なる改良言語のネタに
したいということですね。
帰れ。
584 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 16:20:31.76 ID:QsxM8200.net]: 書きやすいか否かという話より、rustは意外にタイピング量は多い思想は考え直してほしい。
std::fmtなどの「::」だとか引数名・変数の後の型の「:」だとか、むろんmutも、戻り値の「->」もなぜ引数の「:」と戻り値の「->」を同じにしなかったのか？思想面が分かる人に教えてほしい。
ほかにもなぜマクロ呼び出しに「!」をいちいち付けるのかとか、関数はfnやpubで省略しているのに？アトリビュートも#[xxx]と異様に見える。なぜ@xxxでは駄目だったのか？
まあセミコロンはC/C++からの移行を重視したのだろうけど。言語をディスってる訳じゃなく完全論破されることを願う
585 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 16:59:17.90 ID:MyTs/b4R.net]: 細かい構文は互換性やらが重視されて一定の思想が徹底してないことも多いでしょうよ
暇ならissue掘り返してみればいい

とりあえず::はC++由来でattributeはC#由来
586 名前：デフォルトの名無しさん [2023/06/07(水) 18:36:58.20 ID:Rjy197CJ.net]: Rustが難しいと感じるのは経験不足だと思うわ
困難に立ち向かった経験が少ない
587 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 18:50:18.58 ID:JMx9Ekkp.net]: >>573
マクロ呼び出しに「!」を付けるのはコンパイラと人間の両方がマクロ呼び出しをすぐに識別できるようにするため
コンパイラの実装方法によっては無くすことは不可能ではないだろうけど効率が悪くなるし実装も難しくなる

最初は俺も無いほうが良いと思ってたけど
「!」をつけないといけないから不必要にマクロを作らなくて
結果的にメンテしやすいコードにつながってるので考え方変わった
588 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 19:54:20.54 ID:6MUTDsao.net]: >>573
タッチタイピングできない人？
もしくはVSCode使ってない人？
文字数なんて気にするやつ初めて見たぞ

::はC++由来
->はHaskell由来だよ
マクロの!や?はおそらくRuby由来だが別の意味で使ってる
#[]はわからん
589 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 20:20:10.95 ID:MyTs/b4R.net]: >>577
煽るなら最低限公式ドキュメントの内容はすべて頭に入れてからにしたまえ
https://doc.rust-lang.org/reference/influences.html

>>573が言いたいのはTypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
trait boundとの曖昧性が生まれる状況があるのかなと思ったが、ちょっと具体例が思いつかないので違うかも
590 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 21:01:38.64 ID:MyTs/b4R.net]: というかRustは元々めっちゃタイプ数気にする系言語だったんだよねむしろ
1.0以前にはreturnがretだった頃もあった
今日まで残るfnとかimplとか、比較的新しいdynもそうだが
実際かなり略したがりな言語ではあると思うよ
591 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 22:03:46.79 ID:juXVB+W2.net]: >>573
あらゆる言語で同じことが言えるが
基本的な文法記述方法を考え直してほしいと要求しても
今から変わるわけがないし変わったら利用者が困る
無意味な破壊的な要求をしていることになる

タイピング量が多いといってもわずかな誤差であり
ほとんどの記述方法は既存のメジャーな言語で実績があるものと同じ
現在のメモリCPU開発環境からも余裕で許容される範囲でもある
個人的に気に入らないと主張しているのと変わらない
592 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 22:23:55.97 ID:gvoW4qh7.net]: 記述方法が気に入らないのであれば
自分で変換器を作ればいいだけなのでは?
593 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 22:42:25.08 ID:JMx9Ekkp.net]: >>578
>TypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
基本的には視認性の問題
TypeScriptも関数の型を明記するときはファットアローを使ってる
594 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:12:17.03 ID:Y4/HSuwV.net]: 気に入らない部分くらいあってもいいだろうに過剰に攻撃的な人は落ち着いて欲しい
どんな人もある程度は興味があってきてるんだろうから建設的に話をしましょうよ
気に入らない部分も背景知ると納得できたりするしそういう情報知るの楽しいから書いてくれてる人はありがたい
595 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:20:10.61 ID:C+WmTRhv.net]: 戻り値型指定の->には returns や maps to 的なニュアンスを感じられるから個人的には好き
596 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:44:37.64 ID:ZHL7BfYm.net]: ->ってでも実際は不要でしょ？
無駄
597 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:52:00.89 ID:PbTa+35j.net]: >>573が、Rustの思想を考え直して欲しい、と攻撃的にスタートしたのはマズかったかもね。
戻り値の型指定がなぜ「:」ではなく「->」なのかと、素直に質問すればよかったかも。
理由は視認性の良さに加えて、C++の関数の戻り型の後置記法「-> int」と、同じ記法にしたためでしょう。
例えばCarbonでは「-> i32」と、Rustと同じになります。
598 名前：デフォルトの名無しさん [2023/06/07(水) 23:58:55.09 ID:KhstQSkV.net]: int foo() {}　C/C++前置
auto foo() -> int {}　C++後置
fn foo() -> i32 {}　Carbon
fn foo() -> i32 {}　Rust
599 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:28:36.11 ID:EE2g7bKF.net]: Cと似ても似つかない。
600 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:35:35.53 ID:EE2g7bKF.net]: 嘘つき大国アメリカには、良いソフトウェアは作れない。
独占によって維持するのみ。
601 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:36:59.06 ID:EE2g7bKF.net]: 日本人を大量虐殺したことを反省せず、今度はウクライナとロシア人を
殺している。
そんな国に良いものは作りえない。ずるするのみ。
602 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:48:48.98 ID:EE2g7bKF.net]: 平均寿命がアメリカは日本より5歳も低いことをみんな知らない。
そんな後進国を先進国扱いしている。
603 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:53:24.84 ID:EE2g7bKF.net]: 特に、githubなんかは、わけの分からんソフトを作ってる人に別の左翼が
寄付する。左翼は相互扶助で虚構世界を作るのが好き。一般需要が全く無い
ソフトウェアに大金が寄付される。
このように、左翼は日本やアメリカにあってもお互いに虚構を流し合うことで
脳内で言論統制し合い虚構世界を生きている。
604 名前：デフォルトの名無しさん mailto:sagesage [2023/06/08(木) 03:00:18.36 ID:EE2g7bKF.net]: アメリカのやり口:
・需要が無いのに無理やり使わせる。
・不便なのに無料化することで構造上それしか存在しない状態になっている。
・無料化することでどんなに粗悪品でも対抗製品が現れ得ないからである。
・からくりは、検索エンジンの広告料で大金を永遠と稼ぐことで、ソフトを
　無料化し、検索エンジンを持たない通常企業の参入を永久阻止しているのである。
605 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 03:40:00.34 ID:aft4Kt1Y.net]: うーん
やはりﾜｯﾁｮｲなしスレは放棄する他ないか
606 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 03:57:30.29 ID:VBjeYwpm.net]: >>593
各プログラミング言語の本スレを無関係な話で荒らすのはマナー違反なので止めなさい
この一線だけは守りなさい
607 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 04:06:08.75 ID:EE2g7bKF.net]: >>595
アメリカは、基本ルールを守ってないので個別製品の話にまで進まない。
中国の知的財産権違反や著作権違反、不正コピーを言う前に、アメリカこそ、
まずは、基本ルールを守らないと。
608 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 04:07:01.06 ID:EE2g7bKF.net]: アメリカは基本ルールが守れて無いのに、Rustの仕様なんて語る権利が無い。
609 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 04:10:05.28 ID:EE2g7bKF.net]: 要は、アメリカは人殺しが刑務所で書いた本が売れて億万長者になっているようなものだ。
610 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 07:29:01.96 ID:ABj73STK.net]: C言語の戻り型の前置記述だとC++で色々と不便なことがわかり
C++11では戻り型を"->"により後置できるようになった
ラムダ式でも戻り型を指定する時に同じく"->"で後置する
つまりC++11の時点で"->"による戻り型の後置記法が導入されている
そして>>587のようにRustとCarbonもC++11の"->"を踏襲している
611 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 08:51:14.64 ID:9HUG8roo.net]: 他言語とか視認性置いておいてもfn f(x: T): Uは一貫性ないんだよな
Tはxの型だがUはfの型ではないわけで
:の左辺が名前で右辺が型という原則に従うなら fn f: (x: T) -> U となるはず
612 名前：デフォルトの名無しさん [2023/06/08(木) 08:52:05.56 ID:u/DD3jzo.net]: うちはインターンの女子大生すらRust使い始めたわ
ﾍﾟﾁﾊﾟｰには辛い世界になっていくだろうな
613 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 09:22:42.20 ID:c1TL2iD8.net]: >>573
お爺ちゃん🥺
614 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 13:15:19.62 ID:5t64h36a.net]: >>600
左辺が式だと思えば筋は通るやん？
615 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 14:14:27.48 ID:Iro3x2NJ.net]: >>573
関数を評価した結果の型と関数の型は違うものだから表現も異なる。
同じであると誤解するような説明がどこかにあるのならそれを指摘してほしい。
616 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 14:32:27.10 ID:5t64h36a.net]: 隔離スレにコピペしたからあとはあっちで頼むわ
617 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 15:00:38.73 ID:ybwEaSV3.net]: >>603
どう見ても式ではないが
仮に式っぽい何かだとしても関数宣言にだけ特別に書けるならやっぱり一貫性はないってことになるし
618 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 20:13:04.97 ID:rV/cB3of.net]: 関数型言語から拾っただけで深い考えはないだろ
関数型言語は　引数　-> 戻り値　とか　引数 ->　引数　-> 戻り値でカリー化したら引数の数が減ったりするので意味は通じるけど…
619 名前：デフォルトの名無しさん [2023/06/08(木) 20:15:30.41 ID:4tjPz2+ ]: [ここ壊れてます]
620 名前：B.net mailto: オレオレ一貫性w
全然一貫してない []: [ここ壊れてます]
621 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 20:45:27.43 ID:ABj73STK.net]: 「-> 戻り型」を批判してる人は先に採用したC++に対しても批判しているの？
ML系で何十年も使われて来た実績と視認性の良さからベストな記法
622 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 21:09:50.06 ID:6OsjtmDb.net]: ML系は関数呼び出しにかっこを使わないし
関数定義と型注釈を分けて書くし
Cスタイルとはだいぶ違う文法体系だよね
同じ記号を使っているという以外に共通点はないと思うよ

そしてx: TはPascalスタイルの型の付け方なんですね
TypeScriptの他にもScala、Kotlin、HaxeなどがPascalに従って(x: T): Uのように戻り値型注釈をつけます
参考までに
623 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 02:12:57.64 ID:vRGkF7ww.net]: sigplan noticeではindentationとlexical syntaxの話は禁止だったw
624 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 17:20:52.23 ID:3c0vm8Dw.net]: syntaxで言うならライフタイムのsyntaxは今でも違和感あるわ。
具体的に使うわけでもない変数を定義するようなのはどうにかならんかったのか。
625 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 18:41:37.13 ID:2zdGi9Wu.net]: >>612
型変数と同じじゃない？
あれも変数として使ってるわけじゃなく、こことここの型は同じってことを示すだけの変数なわけで
626 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 18:57:57.14 ID:2zdGi9Wu.net]: 変数として使ってないわけじゃないな
具体的なインスタンスが生成されるときに具体的なライフタイムが代入されると思うべきか
627 名前：デフォルトの名無しさん [2023/06/09(金) 18:59:26.79 ID:FpUIfFmd.net]: 型パラメータは変数じゃありません
628 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 19:10:21.66 ID:9O24uU1k.net]: 違和感あるようにしてるんだぞ
Bad Partsはあえて汚くなるような構文を選んでる
629 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 19:42:24.19 ID:9O24uU1k.net]: >>610
Haxe草
君のバックボーンはなんとなくわかったよ
630 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 20:20:27.29 ID:JRGzkE91.net]: rustのstructってなんで中身をカンマで区切るんですか？
C/C++/C#/Swiftはセミコロンだし、影響受けたとされるhaskellの直積型はスペースですよね、デフォルトでメモリースペースが最小になるように再配置されるから？
でもそれだと配列のように直線的に配置されるように感じてしまう気がするのだが
631 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 20:32:17.49 ID:j7wYaK9P.net]: 内容の列挙だからカンマの方が自然だと思うけどセミコロンが使われがちなのは
構文解析（エラー復帰）しやすいからなのかな

let Point { x; y; } = p;
だと気持ち悪いからパターンマッチと関係あるかもしれない
632 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 22:10:43.24 ID:JRGzkE91.net]: >>619
なるほど?構文解析が楽だからという理由はある程度は納得できるが、自然と感じる理由が個人的な嗜好で何となくなのかな?
ほかにカンマを使う場面は分割代入(destructuring)があるので、structを分解するときに対称性が良いからなのかと考えたり
633 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 08:59:06.95 ID:gJM3u8Zc.net]: cでエンディアン確認するとき

unsigned long x = 0x12345678;
for( int i = 0; i < sizeof(long); i++ ){
634 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 09:07:47.23 ID:gJM3u8Zc.net]: cでエンディアン確認するとき

unsigned long x = 0x12345678;
unsigned char *px = (unsingned char *)&x;
for( int i = 0; i < sizeof(long); i++ ){
　fprintf(stderr, "%X ", *px++ );
}
fprintf(stderr, "\n" );

てのをrustならどー書いたらええの>
635 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 09:44:12.87 ID:NYFdP8Rk.net]: それと同じこともできるけど、単にエンディアン知りたいだけならこんな感じで

if cfg!(target_endian = "big") {
// big endian
} else {
// little endian
}
636 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 09:56:44.54 ID:gJM3u8Zc.net]: >>623
エンディアンと書いたのは一例で
実際用意された型にバイトデータがどう格納されてるかを知りたい
ポインタキャストどー書くの?

forとかも変なことなってるけど
条件判断と goto ラベルさえあれば繰り返しは実行できるんだが,
rustにC/C++にあるgotoとかラベルってあるの?
637 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:05:08.69 ID:NYFdP8Rk.net]: >>624
その場合はtransmuteかな
https://doc.rust-lang.org/std/mem/fn.transmute.html

gotoはない
ラベルはネストしたループから脱出するためのはある
638 名前：デフォルトの名無しさん [2023/06/10(土) 10:07:35.39 ID:n814OtyQ.net]: >>622
let x: i32 = 0x12345678;

// 直訳すると生ポインタなのでunsafe
use std::mem::size_of;
let mut px = &x as *const i32 as *const u8;
for _i in 0..size_of::<i32>() {
print!("{:x} ", unsafe { *px });
unsafe { px = px.add(1); };
}
println!();

// byte列とみなすメソッドを使うとsafe
for b in x.to_ne_bytes() {
print!("{b:x} ");
}
println!();
639 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:13:46.29 ID:udyVxmRJ.net]: エンディアン君を、ウッカリ助平と命名したい....
640 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:25:42.92 ID:gJM3u8Zc.net]: >>625
>>626
641 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:26:30.43 ID:gJM3u8Zc.net]: >>625
>>626
わざわざありがと
勉強になります

>>627
何ソレ?
642 名前：デフォルトの名無しさん [2023/06/10(土) 10:35:25.62 ID:n814OtyQ.net]: to_ne_bytesのneはnative endianの意味でleやbeもある
neを使ってlittle endian環境ならば
assert_eq!(0x12345678_u32.to_ne_bytes(), [0x78, 0x56, 0x34, 0x12]);
assert_eq!(0x12345678, u32::from_ne_bytes([0x78, 0x56, 0x34, 0x12]));
643 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 15:12:50.25 ID:PsHn2Fx3.net]: テキストデータを画像にレンダリングして最終的に2値モノクロ画像を得たいんだけど
今だとどんなクレートを使うのがいいかな？
フォントレンダラはfont-rs・・・は放置されているしからfontdueとか？
2値化に影響するディザリングのオプションとかを指定できるとありがたい
644 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 15:48:41.24 ID:UQF9pDDb.net]: rusttypeとかab_glyphってのがダウンロード数多いみたい
645 名前：デフォルトの名無しさん [2023/06/12(月) 12:58:17.77 ID:oql3AWnL.net]: ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？
646 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 13:04:11.65 ID:RXOqFmSk.net]: ？
647 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 14:15:17.58 ID:krlNNb+N.net]: ちょっと何言ってるかわからない
648 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 16:35:03.90 ID:snPhjFNJ.net]: メモリセーフかどうかと
メモリを無駄使いしてるかどうかに直接の関係はない
649 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 16:47:01.05 ID:/yLe7ykR.net]: メモリ安全性とメモリの利用効率に関係はないが、
安全性のために導入したライフタイム管理が最適化に影響する部分がないとは言えない。
依存関係が明瞭だからエイリアス解析がしやすく、
結果的に効果的に最適化しやすい可能性は高い。

しかし実行時でないと安全なアクセスであるかどうか検出が不可能な場合もあるから
それも込みで考えると Rust のほうがやや不利であると言える要素もある。
全体的な性能は互角か Rust のほうがやや遅いくらいじゃないの。知らんけど。

性能が互角くらいでより安全ならそのほうがいいじゃろ。
650 名前：デフォルトの名無しさん [2023/06/12(月) 18:28:52.16 ID:EF0TFJgA.net]: メモリ安全にするために過剰なコピーや長いライフタイムになる実装をしてしまうことがあり、それをコンパイラがガードしてあげるからルールに従って書いてねってのがRustの思想だと思う。
逆に適当に書いても安全にするし出来るだけメモリ効率も配慮するよってのが他のGC言語
651 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 18:44:13.30 ID:A48fS+G5.net]: そんな話一般論で語れる訳ないぞ
コードを出しな？
652 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 20:02:49.65 ID:dpH2J6Rw.net]: >>637
そんなことはなくRustも適切な方法を選べる
そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
653 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 21:33:36.66 ID:/yLe7ykR.net]: >>640
ここではメモリ安全性が実行効率に寄与するわけではないというのがトピックなので
安全性 (自動的な安全性の検証) を捨てることも出来るというのは話題の外。
654 名前：デフォルトの名無しさん [2023/06/12(月) 21:39:50.33 ID:MIVgoZU9.net]: 意味のない議論がほんと好きだねー
655 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 21:44:05.58 ID:G7kVZgOF.net]: コードが一切出てこないのが本当不思議
656 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 21:45:00.87 ID:dpH2J6Rw.net]: >>641
Rustは実行効率を保ちながら安全性もある
Rustがやや不利でやや遅いと思い込んでいる具体的なケースのコードを出してごらん
657 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 11:32:39.43 ID:dzy+ZzAL.net]: >>640
>そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
ややどころか、大幅に遅くなるケースもあるぞ。
俺はこれ以上指摘しない。自分で分かるかどうかが技術力の試金石だ。
658 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 11:35:33.48 ID:dzy+ZzAL.net]: また、
　「Rustは、どんな場合でも、効率を下げずに少数の関数の中に unsafe 箇所を閉じ込められる」
というのも嘘。
659 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 11:43:16.69 ID:+SMK6i6B.net]: ならお前はこれ以上指摘すんなよ未来に渡って
660 名前：デフォルトの名無しさん [2023/06/13(火) 11:53:41.84 ID:+a/cV++y.net]: >>645
デタラメ屋さんまた来たのか
661 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 14:38:11.20 ID:oknE//uE.net]: >>648
俺は一般プログラマより生まれつきだいぶ頭がいいので、通常のプログラマには
分からないのかも知れない。
662 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 18:50:01.53 ID:t3PG4UqW.net]: >>649
ぷw
663 名前：デフォルトの名無しさん [2023/06/13(火) 23:11:29.90 ID:/Z2+rRnG.net]: >>649
だいぶ頭良いプログラマーはこんなとこ来ねーからw
664 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 17:49:14.80 ID:yJueN6KQ.net]: 可変長のバイナリデータを扱う場合の型ってやっぱvec<u8>あたり？
独自の型を定義する以外に他によさそうな型って何かあるかな
665 名前：デフォルトの名無しさん [2023/06/14(水) 20:22:43.85 ID:kb1QmHED.net]: >>652
Trait std::io::Readのrequired methodが
fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
であるように&[u8]でアクセスできれば何でもよい
そのうち可変で最もお手軽なのはVec<u8>
Trait std::io::Readのprovided methodの一つ
fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { ... }
もVec<u8>の可変参照を渡す仕様
666 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 20:28:50.68 ID:MiDa+oME.net]: よくわからないんだけど
ライフタイムの例でよく出てくる関数の引数a,bを同じライフタイムの指定にするってやつは
どちらが選ばれるか分からないから使わないほうも長い方の寿命に合わせて残しておきますと言う解釈でいいの？
667 名前：デフォルトの名無しさん [2023/06/14(水) 20:57:15.56 ID:VhTmt6N9.net]: >>654
その例となってる関数のコードくらいは書けよ
668 名前：デフォルトの名無しさん [2023/06/14(水) 23:11:40.84 ID:kb1QmHED.net]: たぶんこういう例のことかな
fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
if s1.len() >= s2.len() { s1 } else { s2 }
}
ここである呼び出しの時に
s1が'staticでs2が'x (!= 'static)だったとすると
'aとして寿命が短い'xの方が採用される
ただしこれはcovarianceである&Tの場合の話
invarianceである&mut Tの場合は逆になるので注意
669 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:20:37.20 ID:yJueN6KQ.net]: >>653
サンクス。やっぱvec<u8>が無難か
読みやすさだと構造体だけど要unsafeな上に
環境依存性も出ちゃうからな
670 名前：デフォルトの名無しさん [2023/06/14(水) 23:43:12.09 ID:kb1QmHED.net]: 構造体とか要unsafeとか何をしたいのかわからないが
上限を決めてもよい用途ならば
ヒープを使わずともArrayVec<u8, CAPACITY>がスタック上のみで動く
671 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:49:13.19 ID:yJueN6KQ.net]: データの一部だけ可変長とかブロック構造の個数が
可変(ブロックの中身は固定)とかね
672 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:54:41.98 ID:MiDa+oME.net]: staticは消滅しないから実質参考にならんので無視して短い方をaとする
これは対象が2つだからであって
static 1
その他　2
ならその他2の長い方になると言う考えでいいのかな？
673 名前：デフォルトの名無しさん [2023/06/14(水) 23:58:17.85 ID:CT9YbjmP.net]: もう何言ってんだよ
674 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:59:42.49 ID:hllwji0O.net]: >>656
ライフタイムに関しては&も&mutもcovariantなので違いはありません
675 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 00:08:38.46 ID:wST3qwRf.net]: Tに対して&Tはcovariant
Tに対して&mut Tはinvariant
676 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 08:25:03.26 ID:9aol5+Qr.net]: >>548
OptionとOnceCellの違い

&Tを得ることをgetと呼ぶようになった
【Option】fn as_ref(&self) -> Option<&T>
【OnceCell】fn get(&self) -> Option<&T>

&mut Tを得ることをget_mutと呼ぶようになった
【Option】fn as_mut(&mut self) -> Option<&mut T>
【OnceCell】fn get_mut(&mut self) -> Option<&mut T>

空にしてTを得ることをtakeと呼ぶのは同じ
【Option】fn take(&mut self) -> Option<T>
【OnceCell】fn take(&mut self) -> Option<T>

空(default)を作成することをnewと呼ぶこともできるようになった
【Option】fn default() -> Option<T>
【OnceCell】fn default() -> OnceCell<T> または fn new() -> OnceCell<T>
677 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 11:48:36.10 ID:7LFutjAG.net]: トヨタの車載OSってRUSTなんだ
678 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:17:26.02 ID:wrhp+okP.net]: ライフタイムもtraitも難しすぎてマジでわからん
679 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:21:52.25 ID:WlvOik+R.net]: ライフタイムの質問してたものだけど
コードを書いてて完全に誤解していたことに気が付いた
コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
多分一般向けには流行らないわな
680 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:38:09.80 ID:Ah9v0OFJ.net]: ライフタイムって該当のメモリがいつまで確保されているかって話であって難しいところはなくね？
所望のタイミングまで開放してほしくないがどのようにするのが望ましいか？って話ならまだわかるが
681 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:40:44.72 ID:QZKQzk+I.net]: 自明なときに省略できるせいで理解しづらくなってる気はする
682 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:44:18.80 ID:WlvOik+R.net]: 日本語がおかしかった
関数では引数に依存する戻り値の寿命がわからない
それで基本的に指定した複数の引数のライフタイムの一番短い奴に合わせて解釈する
そのライフタイムを元にコンパイル時にチェックしてダングリングを防いでる

一番寿命が短い奴に合わせてチェックしたら他はそれより長いのでダングリングが起こらないだろうと
こういうふうに言う人間があまりいないのが現状
683 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:47:34.83 ID:WlvOik+R.net]: 普通にコードを書いた時点でスコープや借用の関係で寿命は決まってる
それが範囲外になるかどうかボローチェックしてるんだけどそいつのためにライフタイムを明示してる

ライフタイムを明示してもコード上の寿命は伸び縮みしないけどエラーを見てコードを書いた人は修正ができる
684 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:52:46.39 ID:WlvOik+R.net]: と言う解釈なんだけど今のところ
普通に違ってるかもしれない
685 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:57:24.57 ID:uU1WiW+l.net]: OnceCellってようやく俺たちの欲しいものが来てくれたか
RefCellもCellも複雑なデータ構造作ると面倒だったからな
686 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 20:40:26.65 ID:bvsZhoj8.net]: Cellの種類が増えるってのは悪い兆候だね
687 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 20:43:39.64 ID:vyb4HXQ7.net]: Cellを使ったら負け
他の言語からの移植だと、なぜか増えてしまう
688 名前：デフォルトの名無しさん [2023/06/15(木) 21:23:13.49 ID:jjsgM8WL.net]: >>670
結構何を言ってるか分からないが引数のライフタイムを省略した場合は全部同じライフタイムを持つことになるよ
689 名前：デフォルトの名無しさん [2023/06/15(木) 21:54:27.47 ID:o+xWcDso.net]: >>670
main()→sub()→...と呼ばれている時に
'mainと'subをそれぞれの関数で持っている分の寿命とすると
寿命の長さは'static＞'main＞'subだが
「'sub以上の集合」⊃「'main以上の集合」⊃「'static以上の集合」なので
実は'staticの方がサブタイプ(下位)

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str において
寿命'aはジェネリックなパラメータなので
longest('main, 'static)と呼び出されれば'aは上位の'mainとなり
longest('main, 'sub)と呼び出されれば'aは上位の'subとなる

一方で
fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'b str という関数だと
foo('main, 'static)と呼び出されれば'bはそのまま'staticとなり
foo('main, 'sub)と呼び出されれば'bはそのまま'subとなる
この場合はもちろん引数の短い方の寿命になるわけではない

fn bar<'a, 'b>(x: &'a str, y: &'b str) -> Bar<'a, 'b> という関数は
返り型が構造体(か何か)のBarでその内部に寿命'aのものと寿命'bのものを持つ
このように様々なケースがある
690 名前：デフォルトの名無しさん [2023/06/15(木) 22:01:26.73 ID:o+xWcDso.net]: >>673
OnceCellは前からあって広く使われていて今回stdに採り入れられた
once_cell::unsync::OnceCell が std::cell::OnceCell となった
staticで使われてきたSyncなOnceCellの方は別名となり
once_cell::sync::OnceCell が std::sync::OnceLock となった
691 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 22:08:16.03 ID:yL2pOlPY.net]: >>670
データフロー解析を知らないのだろうか?
692 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 22:11:21.57 ID:R+Rv2ggs.net]: >>667
>コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
この”揃える”っていう感覚になる理由がこんがらがってる原因と見た
693 名前：デフォルトの名無しさん [2023/06/15(木) 22:12:42.39 ID:o+xWcDso.net]: >>675
負けではない
むしろCell類は内部可変性を与えてくれる便利で良いもの

>>674
性質の異なるものを使い分けられるから良いこと
コードの自由度や可読性も上がる
694 名前：デフォルトの名無しさん [2023/06/15(木) 22:15:38.46 ID:EOr7Ahlr.net]: >>677
上位下位にサブタイプにsubて嫌がらせか！
695 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 22:39:43.11 ID:WlvOik+R.net]: >>676
まずこれは間違いだよね？
ライフタイムを省力すると全部別扱い

>>680
こんがらがってはいない
違うなら違う個所を訂正したらいいけど君には出来ないとみた

引数側のライフタイムは戻り値のライフタイムの検証のためのヒント
696 名前：デフォルトの名無しさん [2023/06/15(木) 23:12:41.78 ID:ZgEGySwy.net]: >>683
こんがらがってないならまずは他人に理解できる日本語とコード例を書いてくれよ
間違いを指摘するとか以前に何を言いたいのかわからないんだって
俺だけじゃなくて何人も君が何を言いたいのか分からないって書いてるでしょ？
697 名前：デフォルトの名無しさん [2023/06/15(木) 23:29:09.39 ID:iPvlEIxp.net]: >>683
>まずこれは間違いだよね？
>ライフタイムを省力すると全部別扱い
コンパイルエラーになるケースを含めて言えば「省略したら」全部別扱いは正しい
コンパイルエラーにならずに「省略できるのは」基本的に入出力で同じライフタイム扱いになる場合だから>>676の感覚もよくわかる
&と&mut違いで推論できる場合だけ例外
698 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 23:59:14.48 ID:sGVU6kWB.net]: >>683
ライフタイムの「仮引数」としては省略されると全部同じ扱いで合ってるよ。
https://doc.rust-lang.org/reference/lifetime-elision.html

一方で呼び出す側が認識しているライフタイムの「実引数」は違っていてもいい。
>>656の例で言えば、呼び出す側が x: &'b str と y: &'c str を渡して戻り値を z: &'d str に束縛するなら、'a は 'b: 'a, 'c: 'a, 'a: 'd を満たす最小のライフタイムに推論される。
そのような 'a があれば、&'b str <: &'a str etc. の部分型付け関係に基づいて、引数はすべて一度 &'a str にアップキャストされると思っていればいい。はず。
適切な 'a が無ければライフタイムに関するコンパイルエラーになる。
https://doc.rust-lang.org/reference/subtyping.html
https://rust-lang.github.io/rfcs/2094-nll.html
699 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 00:20:26.24 ID:Ej8ifuNd.net]: Rustのコードが'まみれになるのはそういう理由だよね
700 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 00:24:30.59 ID:0npxuivH.net]: >>686
＞　パラメーター内の省略された各ライフタイムは、別個のライフタイムパラメーターになります。
701 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 00:30:18.44 ID:rJ7TTESK.net]: >>686
いや、全部別になる
参照引き数が2つあれば'aと'b別になる

ソース
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

The first rule is that the compiler assigns a lifetime parameter to each parameter that’s a reference.
In other words,
a function with one parameter gets one lifetime parameter: fn foo<'a>(x: &'a i32);
a function with two parameters gets two separate lifetime parameters: fn foo<'a, 'b>(x: &'a i32, y: &'b i32);
and so on.

(snip)

Let’s look at another example, this time using the longest function that had no lifetime parameters
when we started working with it in Listing 10-20:

fn longest(x: &str, y: &str) -> &str {

Let’s apply the first rule: each parameter gets its own lifetime.
This time we have two parameters instead of one, so we have two lifetimes:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {

このようにコンパイラは解釈する
そして戻り値が一意に決まらないのでコンパイルエラーとなる
そのためコンパイラは改善提案の一つとして全部同じにする提案コードを出す
fn longest<'a,>(x: &'a str, y: &'a str) -> &'a str {
全部同じ扱いと思い込んでいる人はこの提案をコンパイラが解釈したと逆に思ってしまったのではないか
702 名前：685 mailto:sage [2023/06/16(金) 01:37:43.97 ID:0a1PgEj3.net]: ほんまや申し訳ねえ
>>686はelisionのくだりは無視して明示した場合の話のつもりで読んでくだせえ
703 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 05:23:01.54 ID:VMczRTMU.net]: 厳格な言語て嫌いでな
Verilogはなんの問題もなかったのに
VHDLはとうとう挫折した
てか予約後長いし,マクロがないのが許せなかったんだが
その意味でJavaも結局書く気にもならなんだわ
704 名前：デフォルトの名無しさん [2023/06/16(金) 14:09:49.37 ID:J436PiNE.net]: >>676
だけど思い込みを書いてしまってごめん
勉強になりました
705 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 14:58:22.19 ID:KrMgX33B.net]: 水ノ都さんこんにちは
706 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 17:51:24.52 ID:fkGXFirN.net]: 組み込み向けの解説記事でよさそうなのってない？
The Embedded Rust Bookは有名だけどSTM32ありきで書かれているしリンカとか肝心な部分の説明もないように見える
日本の人が書いているっぽいEmbedded Rust Techniquesの方がマシだがこれでも最低限か・・・
707 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 18:25:34.38 ID:b/MZV ]: [ここ壊れてます]
708 名前：iq+.net mailto: >>694
The Book以外のドキュメントなら https://docs.rust-embedded.org/ からいろいろ探せるよ
あるいはEmbedded Rust Techniquesの人が書いてる「基礎から学ぶ組み込みRust」って本とか []: [ここ壊れてます]
709 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 18:39:22.38 ID:dwgGWWV8.net]: Rust好きがまあまあ見てそうなこのスレでもこのレベルなんだから一般に広まるのは無理ゲーだと思うわ
710 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 19:23:08.87 ID:PpmLuWiO.net]: 問題点を具体的に言えずに曖昧に批判してるつもりの人がいるね
711 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 19:40:36.76 ID:dwgGWWV8.net]: 自分でスレを読めばいい

お前の足りない脳を誰かがフォローしてボローチェックまでしてくれるなんて思うなよ
712 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 19:42:26.19 ID:QEmhRLek.net]: 言語の良し悪し以上にライブラリの分量が効いてくるんだわ。
そんでその大量にあるライブラリが利用しやすければなお良い。

やりたいことにマッチするライブラリがあるなら
自分で書かなくてよい部分が多くなるわけだし、
書く部分が少なければ少々の面倒くささなんてどうでもよくなる。

C や C++ の歴史の長さ故の物量に対抗するのは難しいけど
Rust は利用しやすさではかなり上回ってると思うので時間の問題だろ。
713 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 23:38:46.36 ID:KXgq6I38.net]: >>696
単に5chがオワコンなだけだぞ
714 名前：デフォルトの名無しさん mailto:sage [2023/06/17(土) 20:33:46.40 ID:pjy0GOzk.net]: >>684
ときにアセンブラで書必要に迫られる組込でRustあ日の目をみることなんてない
715 名前：デフォルトの名無しさん mailto:sage [2023/06/17(土) 21:26:17.31 ID:iUJ74AnJ.net]: >>695
その人は本を出していたのか。今度都内へ行ったときに見てみるか
716 名前：デフォルトの名無しさん mailto:sage [2023/06/17(土) 23:07:17.38 ID:H9lc23A5.net]: 今日たまたま本屋で見かけた
売れるんかこれと思ったけど買う人がいる
717 名前：デフォルトの名無しさん [2023/06/18(日) 01:17:21.64 ID:PsNivFBp.net]: Rustでlinuxに機能を追加するならどんな機能が欲しい？みんな自由に言ってみて。
718 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:07:15.46 ID:JHhjqwBk.net]: >>696
ほんそれ
719 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:08:49.10 ID:JHhjqwBk.net]: >>699
crates.io はゴミだらけのイメージ(もちろんゴミじゃないのもあるがSN比が絶望的に悪い)
720 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:13:33.05 ID:JHhjqwBk.net]: >>704
これと言って無いし今のlinuxで満足(不満もあるけどそれがRustで解決するとも思わない)
カーネルもシェルもAPIもRust化しないと意味無くね？
どうせ unsafe! unsafe!! unsafe!!!
721 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:15:13.52 ID:QTU736PH.net]: >>706
まぁそれは何を比較するかじゃない？
ディストリビューション配布のCライブラリだと厳選されてるから当然クォリティ高いけど
GitHub上から探すとC系の方がS/N悪い（そもそもビルドできないとか）と感じるし
722 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 10:10:46.67 ID:dnSpWVpE.net]: rustは他の言語からの移植性が著しく悪い
移植と言うより最初から作ってるのと変わらない
723 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 10:29:41.24 ID:dnSpWVpE.net]: c　→　rustの移植が楽ならほおっておいても全部rustになる
その視点が欠けてる

ライナスがLinuxやGit作ったときのようにその他の勢力がおバカさんで実質アシストしてる時と同じような状況
Cust作るためのおぜん立てをしてるようにも見える
724 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 10:37:34.85 ID:dnSpWVpE.net]: 後世から見たらライナスはlinuxとgitとcustを作った偉人ですと言うことになるんだろう
725 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 12:12:13.93 ID:kd/h5bzN.net]: 仮にkernelや主要コマンドが全部rustに移植されたらその部分は安全にはなるわな
しかし現状そこまで行くかはわからん
なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
つまり主要なlibも全部rustで書き変えないとunsafeからは逃れられないけどものすごい作業量になりそう
いけるのかな？
726 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 13:00:20.06 ID:TBj+uqoQ.net]: >>699
>Rust は利用しやすさではかなり上回ってると思うので
一部の需要に対してのみは、そういう傾向があるかもしれないとは思うが、
全般に対しては違う。
727 名前：デフォルトの名無しさん [2023/06/18(日) 13:12:59.30 ID:aPOK9VRV.net]: >>701
Rustはインラインアセンブリが書けてRustの変数と連動できるため困ることはない
叩く前に勉強しよう
728 名前：デフォルトの名無しさん [2023/06/18(日) 13:26:34.81 ID:PsNivFBp.net]: >>713
個人的にRustはあれだけの実行速度、安全性の割にはかなり文法がシンプルで好きだけどね。
729 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 14:02:54.81 ID:TBj+uqoQ.net]: >>715
蓼食う虫も好き好きだね。
730 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 16:08:38.91 ID:aKqZwOD/.net]: >>706
それ他の言語も同じだ
そういう宿命

>>709
だから安全なんだよ
731 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 23:54:05.72 ID:V79KPNHt.net]: >>704
その発想からしてRustのパラダイムから逸脱しており反Rust
732 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 17:00:50.46 ID:Dvlv0UV+.net]: >712
>なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
これ知るとRust安全神話なんて嘘八百八町なんよね
金儲けのために保守気取ってましたーに通じる
733 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 19:31:43.67 ID:WU95hkUv.net]: >>719
こういう言説聞くと甘えにもほどがあるって思うけど、
そういう不満から Pure Java みたいに Pure Rust なライブラリが発展していけばいいね。
734 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 19:54:19.85 ID:kXFGlrCh.net]: unsafe=危険=意味なしみたいな人はRustを使うことが目的だと思っているんだろうね
安全なソフトウェアやシステムを開発することが目的ならそういう発想にはならないはずだ
735 名前：デフォルトの名無しさん [2023/06/20(火) 20:03:45.82 ID:2T4Y6uqL.net]: 純粋なRustのライブラリはまだ完成度が微妙なんだよな。PythonとかC,C++と比べると。勿論、他言語のバインディングのライブラリは結構豊富なんだけど、それだとRustを使う意義がないからな。
736 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:20:14.97 ID:IIzrqfbq.net]: >>719
部分的にでもマシになるなら意味あるやん。
論理的な破綻がないように定理証明器をベースにした言語とかもあるけど、
そのために既存のライブラリが使えないようだとそれこそ使い物にならんだろ。

結局はバランスおじさん「結局はバランス」
737 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:41:02.57 ID:7CvaHT3W.net]: >>719
それはunsafeとは何かを理解できていなくて初心者なのかも知れないけどかなりヤバイよ
ffiなんて例を出す必要はなくメモリ空間へのアクセスは最終的に生ポインタとなって当然unsafeになる

例えばslice[index]やslice.iter()の内部は当然unsafeな生ポインタを使って実装されている
ではunsafeで実装されているslice[index]やslice.iter()は危険か？となるがもちろん完全に安全だ
なぜならunsafeを内部に閉じ込めて安全なインタフェースを提供しているからである
これがRustの基本原理

ffiについても同様で例えばファイルのオープンや読み書きは通常OSへのシステムコールとなり通常ffiとなるため当然unsafe
しかしRustの標準ライブラリではそのunsafeを内部に閉じ込めて安全なインターフェイスとして提供している

このようにメモリアクセスもOS呼び出しもそれ自体は当然unsafeだがそれはモジュールの内部に閉じ込められている
そしてそれらを利用する側のプログラマーは安全なインターフェースのみを用いてsafeにプログラミングすることができる
そしてsafeな部分なコンパイラにより様々な安全性が自動的に保証されるという至上の恩恵をもたらすのがRust
738 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:48:07.86 ID:FDgZeyem.net]: 話の流れとは直接関係無いが、豆知識:
バグと言うものは、64BIT 整数を 32BIT 整数で受けたり、符号付きを符合なし
で受けたり(その逆でも)するだけでも起きるし、メモリ関連バグだけでは無い。
739 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:50:12.42 ID:FDgZeyem.net]: 例えば、OSの一度に行なえるファイル読み書きが10MBに制限
されている場合に、それを知らずにバイト数に20MBを指定して
しまったら、バグとなる。
テストでは10MBを超えるファイルを扱っていなかったら気付かない。
740 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 21:06:06.55 ID:wgbzrV/N.net]: >>726
テスト仕様が10MB超えるファイルを扱うパターン記載されてないなら仕様じゃん

その場合仕様ミスではあるがバグとは呼ばない
バグってのは仕様通りに動いてない事を指すんやで
741 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 21:17:59.27 ID:7CvaHT3W.net]: >>725
Rustは強い型安全性が保証されるためそれらのバグも起きない

>>726
それはプログラミング言語とは独立した無関係な話
制限があるのにエラーを返さないOSがあるならそれ自体の問題でありプログラミング言語は関係ない
エラーを返すならそのエラーの対処を正しくしていればバグは起きない
742 名前：デフォルトの名無しさん [2023/06/21(水) 20:47:56.17 ID:DnSmyfOL.net]: Rustで最初に出したバグはデッドロックだったな
コンパイルエラーにしてくれるもんだと油断していた
743 名前：デフォルトの名無しさん mailto:sage [2023/06/21(水) 21:05:00.78 ID:W7d/0xn7.net]: 静的解析でデッドロックを検出するのは不可能
もちろんRustでも無理
744 名前：デフォルトの名無しさん mailto:sage [2023/06/26(月) 18:26:13.57 ID:H3+gGIMJ.net]: すいません、くだらない質問かもしれませんけど割り込ませて下さい
Haskellとかだと二項演算子(+)はNum classに属する型なら適用できます
自分が作った型でもその型において(+)をどう実装するか定義すれば(+)が利用できるようになります
例えば5元体の計算を行うF5 型を定義してそこで足し算とかをするには

data F5 = F5 Int deriving (Eq,Show) -- 型F5を作成
instance Num F5 where -- F5がNum classに属する宣言
　(F5 x ) + ( F5 y) = F5 $ mod (x+y) 5
...略...

のようなものを作れば例えば

print $ ( F5 3 )^4

でF5 1を得る事ができます
同じような事はRustでできますか？
自分でこのような5元体の計算を行うための型を自作しそれの計算を二項演算子(+),(*)を用いた表記を可能にする方法とかありますか？
745 名前：デフォルトの名無しさん mailto:sage [2023/06/26(月) 18:32:46.35 ID:DZPgqn/v.net]: >>731
std::ops::Add を実装すれば + が使えるし
std::ops::Mul を実装すれば * が使えるよ。
https://doc.rust-lang.org/std/ops/trait.Add.html
https://doc.rust-lang.org/std/ops/trait.Mul.html
746 名前：デフォルトの名無しさん mailto:sage [2023/06/26(月) 19:00:39.37 ID:PhkZx7XR.net]: >>732
ありがとうございます
やってみます
747 名前：デフォルトの名無しさん mailto:sage [2023/07/04(火) 01:09:18.95 ID:2CEMaM2m.net]: 神クラス的なArcMutexのstructをごっそり差し替えし始めたらrust analyzerが糞遅くなって書くのが辛い
コード戻したくなる
助けて
748 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 03:39:28.67 ID:kPVzZee0.net]: キー�
749 名前：{ードの何かのキーが入力されてるか調べるけど 何もない場合は止まらずにそのまま次の処理を続けるはどうすればいいの？ []: [ここ壊れてます]
750 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 04:25:29.10 ID:hz58RfSC.net]: >>735
C言語の時と同じ
ノンブロッキング指定するだけでなく
cooked modeではなくraw modeをICANONに指定
これでバッファリングされることなくブロックされることなく読み出せる
libc叩かなくてもtermioなど好みのクレートを使う
751 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 07:46:14.85 ID:kPVzZee0.net]: なるほど
752 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 08:39:38.42 ID:kPVzZee0.net]: 窓だからGetAsyncKeyState呼び出すのが楽っぽい
753 名前：デフォルトの名無しさん [2023/07/13(木) 13:31:51.91 ID:B+tQlcfl.net]: Rust言語で開発したWindowsカーネル、Canaryチャネルで展開開始
https://news.yahoo.co.jp/articles/de16ce55a291d59f7364096690fd601c5ee2ece2
754 名前：デフォルトの名無しさん [2023/07/14(金) 11:16:58.08 ID:tzjfWmow.net]: 値をコピーせずに参照を切り替えてFibonacci数列を計算したい

https://ideone.com/lnMyvH

はいけるんだけど

https://ideone.com/VerTGV

は

error[E0658]: destructuring assignments are unstable

と怒られます
どなたか対処法わかりますか？
755 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 11:27:16.72 ID:Jafjy1es.net]: >>740
これでどう？
https://doc.rust-lang.org/std/mem/fn.swap.html
756 名前：デフォルトの名無しさん [2023/07/14(金) 12:09:03.76 ID:8J2hXx2d.net]: >>741
おお、素晴らしい
あざっす
757 名前：デフォルトの名無しさん [2023/07/14(金) 12:17:12.18 ID:8J2hXx2d.net]: ちなみにコレxとyの参照してる値を保持してる内容を入れ替えてませんよね？
xとyの参照してるアドレスの入れ替えをしたいんですけど
それどうやって確かめたらいいんでしょう？
758 名前：デフォルトの名無しさん [2023/07/14(金) 12:25:35.09 ID:8J2hXx2d.net]: そもそもうまく行ってると思ってたほうもうまくいってなかったorz

https://ideone.com/rny4y8

xとyの参照が切り替わってるんではなくて値そのものこくかんしてやがる
xとyの値に触らずxとyの参照先アドレスだけ切り替えるのってできないんでしょうか？
759 名前：デフォルトの名無しさん [2023/07/14(金) 12:36:55.78 ID:8J2hXx2d.net]: ちょっと長くなるけどやりたい事書きます
例えばFという処理があってそれを初期値a0に何度も適用したいとします
Fの値を計算する関数を入力バッファと出力バッファのアドレスをとって入力バッファ側のデータを読んで出力バッファに書き出す関数を作ったとします
それを何度も繰り返す場合、出てきた出力バッファの内容をもう一度入力バッファにコピーする作業はあまりにも無駄なので出てきた出力バッファを今度はそのまま出力バッファとして使用したいんです
でもx,yは参照型でy=xとしたら何故かxの内容をyの内容に置き換えてしまってるみたいですけどコレ何故なんでしょう？
なんとかならないんですか？
760 名前：デフォルトの名無しさん [2023/07/14(金) 12:57:26.91 ID:KGL+WmuV.net]: 自己レス

わかりました
こうですね

https://ideone.com/sl7Q9v

ここまではうまく行った
761 名前：デフォルトの名無しさん [2023/07/14(金) 13:20:43.04 ID:bUq24laG.net]: そして教えていただいたsys::mem::swapで確認
うまく行ってる感じです
素晴らしい
あざっす

https://ideone.com/1pWNZ7
762 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 13:21:19.50 ID:i4/iEcAZ.net]: そもそもE0658がideoneのrustcのバージョンが古すぎるせいだから>>1のPlayground使ってろ
763 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 19:05:41.95 ID:qocfo89A.net]: 亀だが
>>695
>基礎から学ぶ組み込みRust
見てきた。あの内容じゃWebの記事読んでおけば十分な感じだった
肝心の低レイヤー(CPUやペリフェラルとのインターフェイス)の解説がペラい
特に現状ではメーカーのサポートが得られない以上HALやBSPに相当する部分を
自前で用意せざるを得ないケースは少なくないと思うけど
その辺が十分に解説されているようには見えなかった
764 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 21:27:06.52 ID:+dZRH6iE.net]: そりゃマイナーなチップのHALを自分で作るなんて
マニアックすぎる内容で商業出版は無理だろ
そこまでやるならもう既存の実装見に行ったほうが早いよ
765 名前：デフォルトの名無しさん mailto:sage [2023/07/17(月) 14:57:59.69 ID:ckC6D+AP.net]: 期待してたけどめちゃくちゃ頼りないスタイルガイドが出てきたな
「こういう場合はこうフォーマットしましょう」だけじゃなくもう少し踏み込んで欲しかった
https://doc.rust-lang.org/nightly/style-guide/statements.html
766 名前：デフォルトの名無しさん mailto:sage [2023/07/17(月) 15:40:03.84 ID:qDsaxMYb.net]: スタイルガイドの目的はrustfmtの挙動を文書化して開発を進めやすくするってことだから
まさに「こういう場合はこうフォーマットしましょう」のための文書だよ
767 名前：デフォルトの名無しさん [2023/07/17(月) 17:17:17.76 ID:WT/Een/k.net]: もう少し踏み込んで欲しかった、と言ってる人にそれを言ってもどうもならないわな
別にスタイルガイドの定義の話あなたが勝手に始めただけですよね
論破ですよね
768 名前：デフォルトの名無しさん mailto:sage [2023/07/17(月) 17:39:41.44 ID:Lx49eL3d.net]: なにいってだこいつ
769 名前：デフォルトの名無しさん mailto:sage [2023/07/18(火) 03:22:09.12 ID:wb1VWGHJ.net]: >>745
ポインタとポインタのポインタの違いだな

>>747
そう
ポインタのポインタをswapに渡せばポインタが書き換わる
770 名前：デフォルトの名無しさん mailto:sage [2023/07/18(火) 03:37:10.43 ID:wb1VWGHJ.net]: >>751
従来の言語のスタイルローカルルールの乱立やルール解釈の違いなどの反省から
Rustの標準ではrustfmtを使うことに尽きるわけだがそれ以上にどんな記述を求めているのだろうか
771 名前：デフォルトの名無しさん [2023/07/18(火) 09:14:53.67 ID:nuoH1aU3.net]: 一般的なスタイルガイドを知ってる人と知らない人の違いだね
常識だと思ってた
772 名前：デフォルトの名無しさん [2023/07/18(火) 13:02:43.58 ID:W9LkQalw.net]: 公式のスタイルガイドはrustfmtに実装するフォーマッティング以外はスコープ外
フォーマッティングガイドラインと改名したほうがいいわな
773 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:14:31.27 ID:HXkvqxP4.net]: 関数呼び出しの質問です
私の認識では
「rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される、ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない」
であってますか？
それでお聞きしたいのはrust compilerって呼び出した関数側が実際引数を変更するかしないか判定して“immutatibleな変数を変更しようとした、なめとんかボケ”って怒ってくることがあります
コレ逆に言えば例えプログラマが変更しない変数をmutableで呼び出しを指定してもcompilerはどうせ変更されないんだからコピーもしないでいいよねと気を利かせてコピーしないとかしてくれると考えて大丈夫ですか？、
774 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:21:25.92 ID:yw4UHEnD.net]: >>759
言ってることが意味不明なので回答できない。
何か根本的に勘違いしていると思う。
コードで説明してみて。
775 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:41:04.52 ID:HXkvqxP4.net]: すいません
具体的なコーどはちょっと用意します
別件なんですけど

let mut i : u64;
let p : u64 = 2u64.pow(32)-2u64.pow(10)+1;
for i in 2..100000 {
if i.pow(524288)%p != 1 && i.pow(1048576)%p == 1 {
println!("{}",i);
}
}
と書いたところ
error[E0689]: can't call method `pow` on ambiguous numeric type `{integer}`
--> compiler.rs:136:8
と怒られます
u64って指定するだけではダメなんでしょうか？
どう書いたら通してもらえますか？
よろしくお願いします
776 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:47:10.22 ID:x9es5cRL.net]: unsafe { 引数のポインタ拾って描き替えたら }
呼び出し側も描き換わってたでござる
777 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:49:41.95 ID:x9es5cRL.net]: >>761
for i in 2..100000u64 {
778 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:51:21.32 ID:x9es5cRL.net]: >>763
あと mut i: u64 の i は for では使われてないし警告出てない？
779 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:00:23.67 ID:HXkvqxP4.net]: ダメでした

error[E0308]: mismatched types
--> compiler.rs:136:12
|
136 | if i.pow(524288u64)%p != 1 && i.pow(1048576u64)%p == 1 {
| --- ^^^^^^^^^ expected `u32`, found `u64`
| |
| arguments to this function are incorrect
|
note: associated function defined here
= note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: change the type of the numeric literal from `u64` to `u32`
|
136 | if i.pow(524288u32)%p != 1 && i.pow(1048576u64)%p == 1 {
| ~~~

となります
powってu64はダメなんでしょうか？
780 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:07:25.53 ID:HXkvqxP4.net]: ideoneでもダメです
https://ideone.com/FaBKXh
781 名前：デフォルトの名無しさん [2023/07/19(水) 12:11:42.11 ID:a/a2TjKK.net]: エラーメッセージから「ダメ」かどうかの１ビットしか読み取らない人にプログラミングは難しい。
782 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:12:42.07 ID:HXkvqxP4.net]: あ、そもそもコレダメですね
仮にu64受け付けてくれてもダメやん
powは自作します
しかしu64版のpowってないんでしょうか？
783 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:14:10.94 ID:x9es5cRL.net]: overflowは知らん自己責任でやれ
https://ideone.com/JR2FhX
784 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:17:18.80 ID:x9es5cRL.net]: >>768
https://crates.io/crates/rust-gmp
785 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:25:20.07 ID:YST94QZy.net]: いろいろキッツいなぁー

loop-variableはfor-loopのブロックスコープ
u64::powはfn pow(self, exp: u32) -> u64
(u32以上の値をとってもオーバーフローするから)

>「rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される、ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない」
>であってますか？
もちろん間違ってます
786 名前：デフォルトの名無しさん [2023/07/19(水) 12:29:53.08 ID:hsqLjzEB.net]: 余りをとっているから繰り返し自乗法を適当に実装すればオーバーフローは回避できる
787 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:30:35.45 ID:HXkvqxP4.net]: >>771
間違ってるんですか？
どこが違いますか？
788 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:41:14.04 ID:HXkvqxP4.net]: >>772
そうなんですよ
毎回あまり取らないとダメですよね
pの値も間違ってたし
やりたかったのはバッファサイズが1048576の有限体のフーリエ変換のための素数と位数1048576の元zetaを見つける作業でpはすぐ見つけてたんですけどzetaで手こずりました
まだrust慣れてないもので
これで行けました
https://ideone.com/haw9t8
見つけたzetaの候補３つ
4293918721
1557
7183
8874
789 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 15:49:39.29 ID:HXkvqxP4.net]: やはりダメです
型の指定の書き方がわかりません
次のコードです
https://ideone.com/QLw12c
有限体上のFourier変換を書きたいんですけどmutの書き方がらみで怒られます
どうすれば通せますか？
790 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 16:22:53.10 ID:HXkvqxP4.net]: とりあえずmutを全部につけまくったら通りました
https://ideone.com/EF9EEJ
791 名前：デフォルトの名無しさん [2023/07/19(水) 17:34:17.58 ID:g8hXxOtp.net]: >>775
>どうすれば通せますか？
The Bookを読んで基本を身につければ通せます。
https://doc.rust-lang.org/book/
まずはplygroundとエラーメッセージの読み方から学ぶことをお勧めいたします。
792 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 17:52:11.79 ID:HXkvqxP4.net]: ありがとうございます
コンパイルは無事通ったんですけどstack overflowで実行できませんでしたw
どうせならどでかいのでやってみようと欲張ったらダメでしたw
まぁ縮める分には見つけたpやzetaはそのまま使えるのでまた時間ある日に続きやります
やっぱり新しい言語挑戦するのは時間かかりますね
ついでにひとつお聞きしたいんですけど、今回は「Rustの売りのなるべくstuckでやる」でやってみたんですけど流石にこのサイズはstackにとれないようです
コレ同じ事ヒープでやってもRustコンパイラはフラグメンテーションが怒らないように良きにはからってくれますよね？
コードは>>776です、まだ作りかけですけど
Fourier変換でO(n log n)で掛け算するプログラムの実装の演習の自習中です
793 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 23:54:55.34 ID:6nPpRSza.net]: >>759
>> rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される

Rustは常にcall by valueでvalueをコピーする
大きなものをコピーされたくないならば
渡すvalueとしてその参照を指定する
すると参照すなわちポインタ値のみがコピーされて渡される

>> ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない

immutatibleな呼び出しなんて概念はない
immutableな参照を渡すかmutableな参照を渡すかの選択肢はある
そのポインタ値は常にコピーされる

ポインタ値のコピーはどんな速い言語を作っても避けられずそれが最速
ただし例えば数値単体を渡すなら参照(ポインタ値)を渡すよりも速い

>>778
数MBのデータはスタック領域に入らないのでヒープ領域に開始時に確保すればよい
794 名前：デフォルトの名無しさん mailto:sage [2023/07/20(木) 15:25:39.14 ID:6BSTmMYa.net]: >>779
>Rustは常にcall by valueでvalueをコピーする

何でもかんでも #[derive(Copy, Clone)] 描く習慣は良くないな
795 名前：デフォルトの名無しさん [2023/07/20(木) 16:14:28.16 ID:zz9s86Uo.net]: 古典的なcall by valueの定義におけるコピーと
そのCopyとはまた違う話

ついでに言うとRustにおけるcall by valueの定義と
古典的call by valueの定義は違うので要注意
現代では古典的定義でcall by valueかどうかを考えるのはあまり意味がない
796 名前：デフォルトの名無しさん mailto:sage [2023/07/20(木) 19:56:50.64 ID:neDY19sM.net]: >>780
そのコピーはビットコピーの話でCopy実装型の話とは別
Copy非実装型でもムーブするとビットコピーされる
そもそもCPUやメモリにムーブなんてものは存在しなくてMOV (MOVE)命令ですらビットコピーが行われる

ただしビットコピーは最適化で消えうる
例えば別の変数にムーブしても最適化でビットコピーは消えうる
サイズの大きな値を関数でムーブ返ししてもRTO (Return Value Optimization)により呼び出し元スタックフレームに直接生成できるならビットコピーは消えうる
サイズの小さい値を関数でムーブ返しするとレジスタ返しとなる等
797 名前：デフォルトの名無しさん [2023/07/20(木) 22:07:49.98 ID:YJW86g9/.net]: call by valueのコピーはビットコピーなんて定義はない
ビットコピーかどうかはimplementation detail
798 名前：デフォルトの名無しさん mailto:sage [2023/07/20(木) 22:17:52.36 ID:mzA35L2k.net]: レジスタかメモリへのビットコピー以外に渡す手段はない
現行のコンピューターでは
799 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 01:08:25.26 ID:9fslOp72.net]: メモリ管理について質問です
Rustは「GCをしない言語」を謳っています
一応「GCを心配する必要はない、フラグメンテーションなも起きない、メモリ不足になったらそれはフラグメンテーションではなくて元々のメモリ不足」と言い切れればいいんですけど、実際にはそうではなく、下手なデータ管理をすればフラメンテーションは発生するようです
まぁそりゃそうなんですけど
https://hackernoon.com/ja/Rust%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7%E3%83%92%E3%83%BC%E3%83%97%E3%81%AE%E6%96%AD%E7%89%87%E5%8C%96%E3%82%92%E8%A6%8B%E3%81%A4%E3%81%91%E3%81%A6%E5%9B%9E%E9%81%BF%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
ということはプログラマ極力フラグメンテーションが発生しないように注意したいところですが、しかしRustのアロケータはどういう状況でフラグメンテーションを発生させるか、どうやれば防げるかの資料が見つかりません、なので先のリンクの人は自分で調べてたみたいです
これ誰かご存知の方いますか？
具体的には同じ型のSizedのデータA,を作成して先にAを消し、その後同じ型のCを作った場合、Rustシステムはその時点で開いてる穴のAの抜け穴を利用してそこにCを割り当ててくれるんでしょうか、
それともBが消えるまではAのあった場所も“欠番扱い”になるんでしょうか？
800 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 02:40:42.91 ID:htX2UcZa.net]: >>785
アロケーションやフラグメンテーションはRustの言語システムの範囲外
例えばOSがない環境も含めてアロケータを自作もできるようになっている
普通にOSなどある環境を使うとRustはそこでの標準のアロケータをそのままグローバルアロケータとして用いる
つまり環境毎に異なるものが使われていてRustとは全く関係がない問題であることがわかる

もちろんRustでは自分でアロケータを変えることもできる
グローバルアロケータを丸ごと変える方法とBoxやVecなどで個別にアロケータを指定する方法がある
使用環境の標準のアロケータで何か問題が起きていると感じたらその例のように別のものと交換して比較してベストなアロケータを選べばよい

もう一つ全く別のアプローチとしてそれらアロケータに頼るのではなくプログラムのレベルでまとまったメモリの割り当て管理する方法もある
この方法は全て自分の制御下におけるため様々な特性のあるクレートがありもちろん自作もできる
801 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 02:50:52.30 ID:htX2UcZa.net]: >>785
後半の質問はもちろん再割り当てしてくれる
どの環境の標準アロケータでもそのような普通のことは当然している
だからアロケータの変更などは何か問題が起きてから考えればいい
質問の挙動ならばアドレスを表示させればわかる

fn main() {
// aを割り当て
let a = foo(123);
println!("a: {:p}", &*a);
// bを割り当て
let b = foo(456);
println!("b: {:p}", &*b);
// aを解放
std::mem::drop(a);
// cを割り当て
let c = foo(789);
println!("c: {:p}", &*c);
// aとcは同じアドレスになっている
}

fn foo(init: i32) -> Box<[i32; 1000]> {
std::boxed::Box::new([init; 1000])
}
802 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 08:56:00.85 ID:40PxJ+ku.net]: やはりそうですね
Rustはヒープエリアのメモリ管理は言語システムでは提供しない、その性能については規定しない立場なんですね
なので先の質問のような場合「Rustでは必ずうまいことやってくれる」とは言えず「コンパイラ××、実行環境××で実測したらうまく行った」程度しか言えず、同じソースを別の環境に持ってやったらダメだったもありうるんですね
結局ヒープを使わざるを得ない場合には「自分でメモリ割り当てをうまいことやる」しかないんですね
今やってる例だとスタックには入らないって怒られるし、ヒープ使うなら、うまくいくかはやってみるまでわからないというのはちょっと面白くないなぁ
803 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 09:24:29.44 ID:htX2UcZa.net]: >>788
OS環境などが提供するアロケータ(＝Rustのデフォルトのアロケータ)をそのまま使う時だけ環境依存になる
これはRustに限らずそれをそのまま使う全てのプログラミング言語で起こるためRustの問題ではない
しかもRustは次のように解決策がある言語だ

アロケータ含めて同じソースを持っていってそれを使うならば動作も同じになるので大丈夫
例えば先ほどのケースのようにjemallocをアロケータとして指定して使えば環境依存ではなくなる
よほど特殊なケースでの特殊な効率化を目指さない限り自分でアロケータを書く必要はない
804 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 09:54:09.20 ID:JFG0S3Tm.net]: まぁそうですね
Rustにしたら今までのプログラミング言語で常に問題視されてたアロケーション問題が魔法のように解決するなどという事があるはずはないですね
805 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 09:59:59.87 ID:htX2UcZa.net]: 何を問題にしているのか明確にせよ
Rustはアロケータすら自由に入れ替えられる
つまり理論上可能なことはRustならば解決できる
806 名前：デフォルトの名無しさん [2023/07/22(土) 10:40:08.11 ID:S6pKsqQS.net]: 複オジーww
807 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 10:45:39.31 ID:xU//sEEH.net]: 問題は普通のプログラミング言語の“メモリ割り当て問題”です
別にRust特有の問題ではなく、どんなプログラミング言語でも発生する問題ですよ
Rustではどういう戦略で当たってるのかなと
もちろんこの戦略に関して“どんな場合でもうまくいくまほうのような解決策”などありません、そして多くの場合この処理は大変重たい処理でとても重大な問題を引き起こします
画像処理、動画処理、AIの機械学習の処理などで大きなデータの割り当て、更新、消去は処理中かなり頻繁に起こり、データサイズによってはフラグメンテーションが大きな問題になる事などしょっちゅうです
結局プログラマはほとんどの場合自前でアロケーション問題を解決させられるわけでそこにもはや“言語のデフォルトに任せておけばいける”幻想は抱いてません
しかしRustはどうしてるんだろうと、もしRustでやれといわれた場合があったと妄想して自分にそれができるようにしときたいなと思って自習中なんです、まぁ絶対なさそうですが
今まで色々資料読んだ範囲内だと感覚的には「Rustはメモリ管理に関しては言語内部的には頑張らない、外部環境で処理するか、可読性を犠牲にガチャガチャしろ」というスタンスで提供されてる感じはしてます
808 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:31:54.16 ID:l0FUWY0y.net]: >>793
Rustは可読性を一切犠牲にすることなく、ソースコードそのままで、グローバルアロケータ指定だけを追加すればアロケータを変更できる
この件に関してRustは最も融通が効く優れた言語の一つ
809 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:35:08.26 ID:nQhdUCcc.net]: この人はそういう人なので適当に切り上げることをおすすめします
810 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:38:03.03 ID:xU//sEEH.net]: まぁ無理です
できないことをできると言い張るのはもはや学問ではなく信仰です
811 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:49:43.86 ID:YLqzZrt5.net]: A造る
B造る
A消す
C造る
AのサイズよりCのサイズが小さいとき
A-Cのサイズ分のフラグメントが発生
812 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 12:06:07.26 ID:24bvSiNd.net]: >>793
>> 今まで色々資料読んだ範囲内だと感覚的には「Rustはメモリ管理に関しては言語内部的には頑張らない、外部環境で処理するか、可読性を犠牲にガチャガチャしろ」というスタンスで提供されてる感じはしてます

メモリ管理の階層の違いを理解できていなさそうだが
メモリアロケータの話ならばRustはC++と同様に交換自由でライブラリ選択可能
可読性を犠牲にガチャガチャする必要はなくRustでは#[global_allocator]で指定するだけで交換可能
813 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 13:41:17.13 ID:7Mz5wCRP.net]: 理解できてなかったらしい
もういいや
814 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 13:57:51.76 ID:u4m8T///.net]: >>793はC言語でたとえるとmallocを使ったメモリ管理とmallocの中のメモリ管理の違いをわかっていない初心者かな
815 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 13:58:55.74 ID:NWfMWzFP.net]: そうです
初心者でした
お騒がせして申し訳ありませんでした
816 名前：デフォルトの名無しさん [2023/07/22(土) 14:25:05.31 ID:AxAuiZIS.net]: >>797
AのサイズよりCのサイズが大きいときは
フラグメントは発生しないのかな？
817 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 14:42:32.24 ID:QLIAp4G5.net]: >>802
そんなに単純じゃないよ。
確保しようとする大きさによって違う領域から割り当てるような実装も普通。
順序良く割り当てるわけではなく、
そのときの状況によって効率的になるように采配する。

仮に断片化を意図的に起こしてでも総合的に断片化の確率を減らすような
戦略を持っているのかもしれないし、
よほど深刻な場合を除いて使う側はアロケータの中なんぞ忘れておくのが吉。
818 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 14:54:17.36 ID:NWfMWzFP.net]: もちろん発生しますよ
どんな場合でも最高次数にうまくいく魔法のような戦略なんてありません
なのでケースバイケースで場合に応じて戦略を使い分けなければならない
しかしOSの実行環境なんかのアロケーターはプログラムの内部情報を何一つ持ってないから「開きメモリのリストを持っておいて最初に見つかったスキマにアサインする、足りなくなったらGC」以外に戦略の採りようがない、だから従来のプログラミング言語は自分でGCするわけです、少なくともコンパイラはコンパイルする時点でどれくらいの頻度でどれくらいのサイズのアロケーション要求が発生するかある程度情報が得られるからそれを利用してよりよい割り当て戦略をとれるチャンスがあるからです、なんならその情報をコンパイラに教えるnotificationをつけられるように設計する事もできる
しかしそれとて限界がある、だからRustはもうそれすらやらない、アロケーションは自分でやれ、そのためのツールはある程度は言語内部で用意する、ダメなら言語外部のツール使え、という「無理してやってもどうせ“最適”には程遠いからやらない」んでしょう
逆に言えばRustでプログラム組むとき、特にでかいデータの作成、廃棄を繰り返すような場合はプログラマはかなり練度が必要になるんでしょう
立ち位置としてそれくらいの事がこなせるユーザーをプログラマとして想定してるという事です
学習コストが高いんじゃなくてそもそもプログラマに要求されてる水準が高めなんですね
819 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 16:19:13.40 ID:2BLjTz4O.net]: >>804
間違い多いな
まず一般的にGCはフラグメンテーションを解決しない
特にマークアンドスイープ方式のGCや参照カウント方式のGCはフラグメンテーションは放置で関与しない

Rustについての記述は間違いだらけでなんとも言いようがない
言語外部のツール使えとはトンデモすぎて何を言ってるのかもわからない

フラグメンテーションを起こし得るメモリアロケーターについてRustはC/C++と同じ立場で同じものを使う
C/C++/Rust共通の話として同じようにjemallocなど別のメモリアロケーターを使うことができる
Rustだけ特別な方法をとったり特別な性質をもったりはしておらずフラグメンテーションについてもC/C++と同じ
820 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 16:41:16.06 ID:NWfMWzFP.net]: 素人なものですいません
スレ汚しすいませんでした
821 名前：デフォルトの名無しさん [2023/07/22(土) 17:02:30.53 ID:NRmzieuj.net]: >まず一般的にGCはフラグメンテーションを解決しない
マーク&スウィープ方式は一般的にコンパクションもやってるぞ
822 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 17:07:41.36 ID:2BLjTz4O.net]: >>807
コンパクションをするかしないかは独立した問題
マークアンドスイープ自体はコンパクションを伴わない
823 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 17:59:22.96 ID:QLIAp4G5.net]: >>808
再配置できないならそもそも論外なんだから
無関係ではないだろ。
824 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 18:05:22.75 ID:YLqzZrt5.net]: そういえば君らのメモリ管理の会話でLinkedListの使い道思い出したわ
Rustやその他の言語側じゃなくてOS側のメモリ管理にLinkedList使われてるわ
825 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 18:42:28.71 ID:2BLjTz4O.net]: >>809
再配置するのはコピーGCで使用中データ全移動と全ポインタ書き換えとなる
マークアンドスイープGCはその名の通り使用中を辿りマーク付けしてマークされなかったものを再び未使用領域とする
826 名前：デフォルトの名無しさん [2023/07/22(土) 19:01:55.55 ID:TsQs+vXV.net]: >>808
論点は”一般的”にやってるかどうかだろ
君は一般的にやってないと言ってるわけで
JavaもC#もJavaScriptもみんなGCでcompactionやってる
827 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 19:18:33.46 ID:2BLjTz4O.net]: >>812
compactionをする前にマークアンドスイープGC自体は既に終わっていて独立した別の行為
実際にそれら言語では世代別GCが行われていていて新入り若手のオブジェクトはコピーGCを行なうが古いオブジェクトはマークアンドスイープのみで再配置しない方法が一般的
828 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 19:31:27.25 ID:nB6v7J6K.net]: 隔離スレ行けアスペジジー
829 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 20:04:44.58 ID:2BLjTz4O.net]: 再配置はデータコピーとそこへのポインタ全て書き換えでコストが大きすぎるから可能な限り避けるのが正しい
世代別GCで若手オブジェクトだけに限ってコピーGCの対象にするのも若手の大半は一時的利用でコピーしなくて済むため

Rustではそんなコストをかけないだけでなくヒープ確保解放のコストすら減らすことと一石二鳥で解決する方法も取られている
例えばbumpalo crateはまとまった領域を持って追記していくだけで個別の解放コストゼロ(＝何もしない)と個別の確保コストも最小(＝追記のみor足りないとまとまったお代わり)のアリーナアロケータ
つまり未使用領域の再利用をしないことで管理不要となり最高速になるとともにまとめて一気に最高速で返す
具体的にはサーバーまたはバッチ処理で各対象固有データのみそこから確保してその対象を終える時に破棄
これはフラグメンテーションを防ぐのに非常に効果的な方法
830 名前：デフォルトの名無しさん [2023/07/22(土) 21:33:49.24 ID:kHWj4RWJ.net]: まーた複オジが知ったかぶりして無知晒してるw
初心者かなww
831 名前：デフォルトの名無しさん [2023/07/22(土) 22:04:25.70 ID:kdu4dn9d.net]: Rust使うくらいならJavaかC#で良いのでは？
832 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 22:08:51.83 ID:wR/xGD2g.net]: RustとC#だとどっちがいいの？
833 名前：デフォルトの名無しさん mailto:sage [2023/07/23(日) 02:44:41.28 ID:lmJrnSr9.net]: >>815
GCのないRustが速いわけだ
834 名前：デフォルトの名無しさん mailto:sage [2023/07/23(日) 11:09:10.60 ID:kMNWXVHy.net]: >>815
C/C++でも同じアルゴリズムのアロケータあるで
835 名前：デフォルトの名無しさん mailto:sage [2023/07/23(日) 11:10:16.97 ID:dOw1chPf.net]: >>817
🤮
836 名前：デフォルトの名無しさん mailto:sage [2023/07/25(火) 06:32:45.09 ID:7X7HwnNv.net]: >>820
言語に関係なくそこへ行き着くんだよな
もちろん通常はフラグメンテーションなんか気にせずに普通にコードを書けばよく
稼働時間の長いプロセスでフラグメンテーションが実際に起きた時の解決策の一つ
837 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 13:16:19.02 ID:/bGsBsBb.net]: play-rustのコードのコピペのやり方教えて下さい
具体的にはお題スレの

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f627f3a5de4a0c467f015a8b1527c141 <
838 名前：br> のコードコピペする方法がわかりません よろしくお願いします []: [ここ壊れてます]
839 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 14:04:04.46 ID:90/I2Z5n.net]: rustは型推論をしてくれると聞いたのですけど、結果どういう型になったか調べる方法はありますか？
Haskellのghciの:tに当たるやつです
例えはghci内で
prelude> let f n = sum [ x^n | x<- [1..5] ]
として
prelude> :t f
とすれば
( Num a, Integral b ) => b -> a
のように返してくれます
rustでコンパイラの型推論の結果どういう型に決定したのか調べる方法はありますか？
840 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 14:28:57.60 ID:p+3LvAw4.net]: >>824
LSP 対応のエディタ (VSCode など) を使ってるならそのへんにカーソルを合わせるだけで型は見れるよ。
841 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 21:59:53.82 ID:x4QyUuiY.net]: >>824
安直な方法としては関数の戻り型なら -> i32と嘘の型宣言を指定すれば型不一致で正しい具体型をコンパイルエラーに表示してくれる
プログラムで表示したいならこれ
fn get_type<T>(_: T) -> &'static str {
std::any::type_name::<T>()
}
842 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 23:11:30.70 ID:sTDTKxns.net]: >>825
>>826
あざっす
843 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 23:12:33.60 ID:paov2RlH.net]: rustの型推論って曖昧なことを許容したっけ？
すべて一意にならないとならないと思ってたけど
844 名前：デフォルトの名無しさん mailto:sage [2023/07/28(金) 19:39:32.86 ID:4cjf/6GX.net]: >>828
正しい
ジェネリックであってもパラメタは各々で必ず一意に静的に確定せねばならず
impl Traitで型宣言しても各々で一意に具体的な型に静的に確定する
特にそれが関数の引数ならば生成コードは単相化される

ただしdyn Traitはそれらが静的ではなく実行時のオブジェクト生成毎に個別に一意の具体的な型に確定する点で異なる
コンパイル時の静的な生成コードは複数の型で共有となるためvtableを持って対処している
845 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 16:54:29.41 ID:Nh9kevR9.net]: なるほど
Rustは最終的にコンパイルが終わって型が完全に推論が終わって単相型が決定した状態でしかわからないのかな
当然get_typeで得られるstrは推論終わって単相型が割り当てられた後の型しかわからないんやな
846 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 18:53:43.03 ID:nTghkNr5.net]: コードを書いた時点で型は決まるし書いた人は型を把握できる
ジェネリックな関数だとしても型パラメタ以外の部分は確定している
その関数を呼び出す側が最後のピースとして型パラメタを指定して完全確定する
847 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 19:01:27.37 ID:mkN3FcGi.net]: そうなんよねぇ
ML型型理論ならexpression毎に最も一般的な型が決まる
Haskellは型を指定しない場合自動的にその最も一般的な型を確定させてghciとかで調べられる
今のところ上がってる方法ではRustではそれに該当する方法はなさそう
848 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 19:02:57.30 ID:mkN3FcGi.net]: イヤまだvscideとかのやつは試してないな
これならできるんかな？
849 名前：デフォルトの名無しさん [2023/07/29(土) 20:36:12.76 ID:JeVM9tS2.net]: こいつダメだわ
ある意味複オジ2世
850 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 21:40:33.16 ID:EPaDIYai.net]: >>830
> Rustは最終的にコンパイルが終わって型が完全に推論が終わって単相型が決定した状態でしかわからないのかな
いやもうrustは変数宣言時に定義した型の変更を許さないのよ（基本的に）
だから型推論は変数宣言時のものを利用したり、関数の場合は返値、手打ちの数字の場合はデフォルトの型に決め打ちされて型推論されるわけ
いちいち型を調べる必要がない
ジェネリックに関しても基本的に場合分け
851 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 21:44:15.48 ID:EPaDIYai.net]: pythonとかjavascriptとか勝手に型を変更する（ような振る舞いをする→変更するとは言ってない）
言語なんてサイテーだと個人的には思う
852 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:05:07.65 ID:2dUASh9D.net]: >>835
どゆこと？
rustの型システムはしゃないの？
853 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:10:13.37 ID:2dUASh9D.net]: ごめん、誤字った
rustの型システムはMLじゃないの？
いわゆる型の全体と命題論理の全体を一対一に対応させる
で、その命題論理の目モデルを探す事＝単相型を決定する事がMLの型推論システムで、Rustもそれ採用してるんだと思ってるんだけど
で単相型が割り当てられる“命題”に対応してるものが多相型と呼ぶんだと教えてもらった事あるけど
854 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:19:51.45 ID:381IW7f/.net]: も少し書くなら基本的にrustもhaskellも型システムは基本的な原理は同じじゃないのって話
それを説明する用語としてRust特定の説明の仕方をしてるのかもしれないけど説明の仕方や用語の使い方を変えたところでどっちもカリーハワード理論に基づく型システムじゃない？
855 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:51:50.32 ID:381IW7f/.net]: もし同じならHaskellと同じく例えば

mysum [] = 0
mysum (a:as) = a + ( mysum as )

なら　Haskell ならmysumの型は

( Num a ) => [ a ] -> a

と推論されます
RustでもML型システムである限り少なくとも内部的には同じような型が割り当てられてるはずだと思うんですけど
もちろんこれら推論された型を全部総合して実装時には特定の単相型が割り当てられます
この辺のメカニズムはHaskellもRustも同じじゃないんでしょうか？
856 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:06:20.41 ID:MBm8IaU2.net]: まずRustの数値リテラルはHaskellと違って多相な型を持たないです
857 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:25:14.79 ID:I6XWshKt.net]: >>840
分かってる気になっておかしなことを書く癖を直したほうがいいと思うが…
858 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:36:28.14 ID:I6XWshKt.net]: 人間としての推論機構が間違っている

基礎を勉強してルールとしてそれを覚えてから
それを基に推論を行わないと意味がないと知るべき
859 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:51:52.56 ID:nTghkNr5.net]: >>832
最も一般的な型ではダメでRustは唯一に確定しなければならない
Rustは関数(メソッド)の引数も返り値も型宣言が必須だけど
そこでの型はジェネリックで型パラメータを持つものも多く
その型パラメータのトレイト境界などによる制約とそのトレイト実装をする型が複数あることから複数解も生じる
複数解がありうるならばコンパイルエラーとなり明示的な型指定を求められる
唯一の例外が数値リテラルの利用により数値型までは確定している時でそれが整数ならば自動的にi32型に解決される
860 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:16:28.33 ID:psEFm3Dt.net]: >>841
その説明はよくrustの解説本にあるけど多分字面通りの意味にとってはいけないんじゃないかと
だってプログラム全体を見なければ型なんか決められるはずない
ML型の型システムである限りHaskellのexpressionから定まる最も一般的な多相型持ってると思う、でなければML型型システムと呼べない
さっきあげたmysumなんかその典型、あのmusumはnum classに属するすべての型で使うことができる、もしこのような多相型を持たない理論ならすべての足し算を持つクラス全てにほとんど同じsumを定義させられることになる、それを避けられるのがML型システムの1番の売りなんだから
てか上の例のmysumに相当する書き方Rustでもできるんでしょ？
無理なん？
861 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:18:56.60 ID:psEFm3Dt.net]: ML型システムと呼べないは言い過ぎかな？
まぁ型宣言省略しても型推論してくれるならML型型システムと呼べなくはないけど、でも流石にさっきのmysumみたいな記述は許されてるんじゃないの？
862 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:19:43.44 ID:dT6HJfPv.net]: ハスケル！
ハスケル！
ハスケル！

その毎度のハスケルおじさんに構うのは止めとけよ
Rubyおじさんと変わらないんだからさあ
自覚のない荒らしだよ
863 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:19:47.09 ID:psEFm3Dt.net]: >>844
そうなん？
じゃあさっきのmysumみたいな書き方はRustではできないのあ？
864 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:21:02.70 ID:dT6HJfPv.net]: Haskellおじさんは自分の思いをここに書かないと死んじゃうの？
なんでRustをRustとして扱いたくないの？
865 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:21:05.69 ID:psEFm3Dt.net]: >>847
目障りなら無視してくれていいけど純粋に新しいプログラミング言語に挑戦してるだけだから邪魔しないでくれる？
君は一生ひRustに捧げればいいやん
866 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:22:04.96 ID:dT6HJfPv.net]: ハスケルおじさんは壁に向かってハスケルハスケル行ってればいいのに
867 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:24:01.50 ID:dT6HJfPv.net]: マクロしらんの？
868 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:24:09.72 ID:psEFm3Dt.net]: >>849
すでに習得した言語の対比して新しい言語に挑戦するのは当たり前やろ？
Haskellの型システム理解するのにどれだけの時間をかけて教科書を読み、論文を読み、プログラミングを組んでみたか、その資産を使いたいとおもうのがそんなに悪いんか？
黙っといてくれよ
869 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:24:40.66 ID:dT6HJfPv.net]: >>853
悪いに決まってるだろ？
そんなこともわからんの？
870 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:26:23.01 ID:dT6HJfPv.net]: 論文読まないとプログラム言語が理解できないんだから困ったやつだろ
推論システムが変
871 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:29:41.31 ID:dT6HJfPv.net]: まずは"真面目にRust学習"しろ
そして習得しろ
そして疑問を解決しろ
872 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:32:06.97 ID:psEFm3Dt.net]: >>855
すまんけどオレは論文なんか読まなくても理解できるような天才じゃないんだよ
君は論文なんぞ読まなくても何もかもわかる天才なのかもしれんけど世の中そんな天才ばかりじゃないんだよ
オレみたいに寝食忘れて努力に努力を重ねてやっと話しが分かる鈍才もいるんだよ
鈍才が悪あがきするの邪魔せんでくれ
873 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:33:26.30 ID:psEFm3Dt.net]: >>856
もうオレに関わらないで
その方が双方幸せじゃないか？
874 名前：デフォルトの名無しさん [2023/07/30(日) 02:16:35.97 ID:ArPWIRVu.net]: 大先生3人に共通するのは
自分は分かってるという根拠のない思い込みと
何度指摘されても全く反省せず同じことを繰り返す傍迷惑な行動
875 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 02:39:34.14 ID:g1ghpAt+.net]: >>848
consセルを使った簡易なリスト操作表記をRustは言語仕様レベルではサポートしていない
だからそのHaskellのmysumをその表現のまま移植するのは本質的ではないため
意味だけを重視してリストをイテレータで表現し再帰定義している点を尊重すると

use std::ops::Add;
use num::Zero;

fn mysum<T>(mut iter: impl Iterator<Item = T>) -> T
where
T: Zero + Add<Output = T>,
{
match iter.next() {
Some(n) => n + mysum(iter),
None => T::zero(),
}
}

一例としてこのようにmysumはジェネリックに書ける
mysumに最低限必要なトレイト境界(Zero + Add)のみを課している
もちろんこの関数だけで以下のように機能して計算結果も合う
assert_eq!(15, mysum([1, 2, 3, 4, 5].into_iter()));
876 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 02:43:03.72 ID:g1ghpAt+.net]: >>860のmysumでトレイト境界はZeroとAddさえ満たしていれば通常の数値でなくても構わないので
例えば以下のようなHoge型を定義して必要なトレイト境界(ZeroとAdd)を実装すると

#[derive(PartialEq, Debug)]
struct Hoge(usize);
impl Zero for Hoge {
fn zero() -> Self { Hoge(0) }
fn is_zero(&self) -> bool { self.0 == 0 }
}
impl Add for Hoge {
type Output = Self;
fn add(self, rhs: Self) -> Self {
Hoge((1 << (self.0.trailing_ones() + rhs.0.trailing_ones())) - 1)
}
}

先程と同じように「15 = 1 + 2 + 3 + 4 + 5」をHoge型で表現することで
Hogeについてもmysum()は以下のようにきちんと計算できていることがわかる
assert_eq!(Hoge(0b111111111111111), mysum([Hoge(0b1), Hoge(0b11), Hoge(0b111), Hoge(0b1111), Hoge(0b11111)].into_iter()));

Haskellに全く詳しくないので逆に質問というか教えてほしい
このHoge型をHaskellで定義(実装)するにはどのようなコードになるのか？
そしてこのHoge型に対してもHaskell版>>840のmysumで使えるようにするにはどうするのか？
たぶん型クラスNumの代わりに型クラスZeroとAddを指定するだけで済むのだろうけど
もしHaskellに型クラスZeroやAddがなければそれを定義する形になるのだろうか？
よろしくお願いします
877 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 10:57:59.43 ID:TSIasAnA.net]: >>861
Haskellではこうなります
https://ideone.com/PKy694

mysum [] = 0
mysum ( a : as ) = a + ( mysum as )

hogePlus a 0 = a
hogePlus a b | even b = 2 * (hogePlus a ( div b 2 ) )
hogePlus a b = 1 + 2 * (hogePlus a ( div b 2 ) )

data Hoge = H Integer deriving Show

instance Num Hoge where
( H x ) + ( H y ) = H ( hogePlus x y )
fromInteger = H

main = do
print $ mysum [ 1..5 ]
print $ hogePlus 3 7
print $ mysum [ H 1, H 3, H 7, H 15, H 31 ]
878 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 10:58:19.77 ID:TSIasAnA.net]: この例だとmysumの型は
mysum :: ( Num a ) => [ a ] -> a
と推論されます
すなわちmysumは

　aがNum class に属する型aに対して[a]型の値に対してa型の値を返す関数の型

です
よってmysumをある型Hogeで利用するにはHogeにNumインスタンスを導入しなければなりません、すなわちRustでは
impl Num for Hoge { ... }
のように書く部分です( >> 860 のAdd,Zeroを実装してる部分に該当します)
本来はNumのminimal complete definition全部実装するべきでHaskell1990までは“定義が揃ってない”とおこられましたが。2010以降は必要な分だけ実装すれば良い、ただし実行時エラーは覚悟しろという風に変更されてるようです(未確認、コンパイラがエラー吐かなくなったので)
879 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 12:33:59.93 ID:g1ghpAt+.net]: >>862
RustのAddトレイト実装によって足し算(a + b)のみを他の型でも自由に使えるようにできる機能をHaskellは持っていないということ？
そのためHaskellではやむを得ない代替処置としてHoge型を型クラスNumへ入れてしまうことで解決したということ？

例えばRustではStringについてもAddトレイト実装があり
let s = String::from("abc");
assert_eq!(s + "xyz", String::from("abcxyz"));
といったこともできます
同様に自作の型に対しても足し算のみの実装が可能です
Haskellではこのようなケースでもオーバースペック気味にNumを使うしかないのでしょうか？
880 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 12:37:15.22 ID:g1ghpAt+.net]: >>863
Haskellでは実行時エラーを覚悟しろという点は非常に困りますね
今回のケースも無理やりにNumへ入れてしまったのに足し算しか実装していないから引き算や掛け算などで実行時エラーとなるわけですよね

ちなみにRustのnumクレートでは
trait Num: Zero + One + NumOps + PartialEq とトレイト境界があり
impl NumOps for T where T: Add + Sub + Mul + Div + Rem {} の実装があります
つまり自作の型で使う場合は全ての演算を実装した上で更に加えて
impl Num for Foo とするとようやくNumになれます
したがってRustでは不備があればコンパイル時エラーとなり安心して安全に使うことができます
881 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 12:47:58.55 ID:wjjxPYUe.net]: そろそろ隔離スレ行ってろカスども
882 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 14:02:34.57 ID:iwDEPHME.net]: Haskell 的には演算子オーバーロードを目的として型クラスを使うことはしない。
Num な性質を持つ値の操作として + という名前の演算子もあるというだけで、
演算子として + を使いたいから型クラスの実装を定義するということはしないってこと。
それに、 Num はいくつかの演算子を使えるというだけではなく
それらの演算子の関係で満たさなければいけない性質があるので個々の演算子 (に結び付く型クラス) として分解できない。
https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#t:Num

価値観が違う。

なんせ Haskell では記号を組み合わせていくらでも演算子を作ることが出来て
たとえば <$> とか >>= とかいう変な演算子を必要なだけ作れるので少ない演算子を取り合う必要がない。

Num の性質の中で + を使うってのと、
なんらかの足し算っぽい操作は別の名前で定義されているべきだし、
Haskell ではそれで困らない。

価値観が違う。
883 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 18:06:30.12 ID:mgfeU+D6.net]: 新設の見慣れぬ演算子の種類を勝手に増やして各々が異なる意味付けすることは可読性を下げるのみで百害あって一利無し

>>863
コンパイラがエラーを吐かずに実行時エラーとなるのはマズいな
Haskellの価値観はよくない
884 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 19:58:32.75 ID:Llc746TG.net]: すいません、筆が滑りました
もちろんコンパイル時にエラー吐きます
以前のHaskellだと例えそのプログラムで使われてない場合でも実装しないとエラー吐いてました
しょうがないのでwhere句に使いもしないのに
_ * _ = undefined
signum _ = undefined
....
を書いてました
流石に無意味すぎて使わないのは書かなくて良いことになったようです
使ってるのに未実装はもちろんコンパイラが見つけてくれます
885 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 20:06:02.24 ID:iwDEPHME.net]: どうでもいいけど signum という名前を見るとヴォルケンリッターを連想してしまう……
886 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 08:16:09.72 ID:G+nEO2Oo.net]: どうでもいいなら・・・煽りたくなるな
887 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 10:23:47.98 ID:8wbRk2dY.net]: use Hoge::prelude::*; って良く観るがダサいなー
888 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 10:35:07.69 ID:i3Lje9zm.net]: でもまあ機能ごとにモジュールを整理しても
それとは別によく使う集合があるのも現実だし。
889 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 11:07:00.50 ID:sgBBFIN2.net]: global 禁止(キリっ
890 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 12:25:28.59 ID:lZja90Kc.net]: >>872
preludeは邪道で非推奨
自動適用される標準ライブラリのprelude以外は使わない＆設けない
例えばtokio::preludeも廃止された
891 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 12:34:21.81 ID:eCR2qI4e.net]: Rustで、Vecに要素を追加したとき、メモリ不足で
メモリ確保に失敗した場合、どうなるんですか？
C++の場合は「例外」がthrowされますが。
892 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 14:38:56.18 ID:uDpaCeqo.net]: pqnic
893 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 16:40:54.67 ID:cE0Z6rmj.net]: ﾋﾟｸﾆｯｸ?
894 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 17:53:43.20 ID:1dCFbVL1.net]: fn っていちいち略さなくても function でよくない？

書き込める変数の宣言に mut ってつけるのもダサい
895 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:05:43.81 ID:+bjI2PCn.net]: mutはガチでダサい
何かいい記号はなかったのかとｗ
896 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:13:53.64 ID:+bjI2PCn.net]: 英語圏の人たちはmut見てcoolに感じるとか日本人と感性が違う可能性がある
897 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:38:57.32 ID:9nT3Yxeb.net]: >>879
感性が古いよ
898 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:48:05.02 ID:STr6yd2M.net]: 今までミュートと読んでいた
899 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:49:54.52 ID:A3cMstwB.net]: unicode解禁にして変にすればいい
900 名前：デフォルトの名無しさん [2023/07/31(月) 20:49:15.69 ID:X0OEUfKN.net]: >>882
短い略語を使いたがるのはメモリ容量が少なかった昔の習性・感性だろ。
昔に作られた言語のFortranとPascalですらfunctionは略さなかったのに、
今になって変な略語を採用したRust開発者は工学的センスも美的センスもない。

比較的新しい言語のF#はmutと略さずにmutableと書く。
901 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 21:15:27.96 ID:+bjI2PCn.net]: BASICの頃はDEF FNと言うので関数を定義してた
902 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 21:25:40.03 ID:4/4p/Sxt.net]: 様々なプログラミング言語があって千差万別な中
大した問題ではないキーワード名やその多少の長さに文句をつける人はダメな仕事できないやつ
仕事できる人は文法とその意味論を比べる
903 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 21:34:38.41 ID:+bjI2PCn.net]: ダサいのはダサい

今後何があってもbegin end区切りの言語は使わないと思う
delphiやってた時もimplementationと言うのを見てクソダサいなと感じた
Objective-Cも二度と接することはないだろう
904 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 22:59:44.59 ID:i3Lje9zm.net]: kotlin や swift の前で同じこと言えるの？
905 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 23:19:46.93 ID:+bjI2PCn.net]: implementation　Point　{
public function ...
｝
906 名前：デフォルトの名無しさん [2023/08/01(火) 03:00:40.65 ID:8wU+ches.net]: >>881
constより2文字も短い！かっけええぇぇぇ！！！
かもな
同意しないけど
907 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 03:53:49.10 ID:enF/Vqu1.net]: constは定数だからコンパイル時に静的に確定する
immutableかmutableかというのはconstとは無関係な概念で実行時の変数の値が書き換わるかどうか
つまりRustの非mut (immutable)は定数ではなく実行時に値が決まる変数
908 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 11:16:59.87 ID:AvEKEx5a.net]: let x : u32 = 1234;
と
const x : u32 = 1234;
は違うんですか？
909 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 11:22:28.49 ID:AvEKEx5a.net]: なるほど、const = の右辺値はconst 文脈で書かれていてコンパイル時に決定できないといけないけど let = の右辺はその制約がないのか
910 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 17:52:49.94 ID:3uGNwlqu.net]: constはコンパイル時に値が決まる定数となり定数名は大文字で書く
letは(mutの有無に関係なく)実行時に値が決まる変数となり変数名は小文字で書く
mutの有無はその変数の値が書き換えられるかどうかだけの違い
911 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 18:49:11.32 ID:Nt/KTAzO.net]: 自分は素人だけどそれじゃあ型に対する言及が抜けてないですか？
912 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 20:27:35.06 ID:3uGNwlqu.net]: 型とは直交する概念なので型とは無関係
任意の型で成り立つ
913 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 22:08:28.57 ID:YdsBZTXH.net]: 'static
914 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 22:38:58.55 ID:Nt/KTAzO.net]: constはシャドーイングは行われない
変数と違い型を必ず明示しなくてはならない
915 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 00:09:43.49 ID:IOFZl0B3.net]: >>899
なんでですか？
constシャドーイングしてなんか不都合あります？
916 名前：デフォルトの名無しさん [2023/08/02(水) 00:12:43.58 ID:/ED8qpF1.net]: >>893
constならROM領域に置ける
917 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 00:12:59.71 ID:IOFZl0B3.net]: あ、わかった
そりゃそうだ
918 名前：デフォルトの名無しさん [2023/08/02(水) 09:00:43.40 ID:4pI1Wfnv.net]: 関数名というか関数を格納した変数？にもmut付けるときあるけど
動作中に関数を変えるのが目的？って表明以外の意味ある？
919 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 13:19:46.95 ID:MBDISWVo.net]: 関数ポインタかラムダ式（クロージャ）かで意味が変わりそうだな

関数ポインタの場合は途中で別の同型の関数に差し替えるときにmutが必要
クロージャの場合は途中で内部の変数が変更される（FnMutになる）ときにmutが必要
（クロージャは型の関係で別の関数に差し替えることはできないはず）

下の例だとf,gのどちらもmutがないと怒られる

fn print_foo() { println!("foo"); }
fn print_bar() { println!("bar"); }

fn main() {
let mut f: fn();
f = print_foo;
f();
f = print_bar;
f();

let mut i = 0u32;
let mut g = move || { println!("{i}"); i += 1; };

for _ in 0..5 { g(); }
}
920 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 13:23:57.98 ID:MBDISWVo.net]: そこに置かれてる値（関数ポインタ or クロージャ）が変更されるという意味では同じか
921 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 18:24:39.32 ID:SI51iZ7R.net]: let mut hoge; じゃなくて

むしろ let hoge = 3; と mut hoge = 3; の二種類に分ければ美しくてよ
922 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 19:02:02.79 ID:F3jAz55G.net]: static mut もあるし
letはパターンマッチ文だからlet (mut a, b) もあるし
if let Some((ref mut p, ref q)) もあるし
923 名前：デフォルトの名無しさん [2023/08/02(水) 20:18:56.34 ID:/ED8qpF1.net]: >>906
それは無い
924 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 07:43:41.06 ID:9tsUh6Bs.net]: 速い！安全！ださい！
925 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 08:17:38.34 ID:8npqW66R.net]: >>907
mutを単独キーワードに分離したRustの設計方針の勝利だな
926 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 10:00:57.61 ID:W+hOnHrE.net]: かわいい
北朝鮮みたい
927 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 21:15:21.47 ID:j7849mpF.net]: こんなスレ見てるなんてダサいぞ！
928 名前：デフォルトの名無しさん [2023/08/04(金) 09:07:52.99 ID:XLfSEGlw.net]: かわいい
埼玉県みたい
929 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 17:59:34.17 ID:xBSreVT+.net]: 任意長整数型演算の実装の演習してるんですけど

・和の時には下の桁から、大小の比較の時は上の桁から順次比較するので双方からのアクセスをO(1)で行いたい
・任意長なので加法のときにover flowしたときitemの追加ができないとダメ

この場合どのcollection型が有利ですか？
ソースが難しすぎてわかりません
情報お願いいたします
930 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 19:27:39.64 ID:3wcIZOky.net]: 自分ならVec使う
931 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 19:29:40.12 ID:lVXXe/mp.net]: >>914
何を問題にしているのかわからない
言語に関係なく連続体のデータ型(配列やベクタなど)の順次アクセスは
前から後ろから関係なくサイズNに対して総コストO(N)で1つあたりO(1)
それらのうち固定長ではなくサイズを伸ばせるデータ型(ベクタ)なら要素を追加できる
RustならVec
932 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:21:24.84 ID:xBSreVT+.net]: >>916
各collectionの内部構造がよくわからないんですよ
ソース全部読めてなくて
vecってLinkedLustみたいな数珠繋ぎじゃないですよね？
933 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:24:19.56 ID:xBSreVT+.net]: >>915
ありがとう
確かに片方だけ伸ばすならbecで良さそうなんですよね
しかし後でよくよく考えたら掛け算の時に一の位の方向にも伸ばせた方が便利な気もしてきて
でもそっちは絶対じゃないんですよね
なんせvecのソースがむずい
934 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:32:19.03 ID:Mgx3ApDu.net]: ソースよりドキュメントを見なよ。
図つきで解説されてるから。
Vec は必要に応じて自動で再配置する配列ってかんじ。
要素は連続して配置される。
935 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:50:29.31 ID:WEauDaB9.net]: >>919
https://doc.rust-lang.org/std/collections/index.html
とか読んだんですけどよくわからないんですよ
rust専用スレならstd::vec全部目を通せてる人いるかなと
連続して確保される領域の幅とかは指定できます？
936 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:51:36.50 ID:lVXXe/mp.net]: >>917
性質が重要なのであってよほどのことがないかぎり実装内部のソースを知る必要はない
LinkedListは極一部の用途を除きほとんどの用途で遅く不利になり今回も考える必要はない
これらは言語と関係なく一般的な話
937 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 21:11:21.94 ID:kGEgc8zj.net]: >>921
とりあえず今はガロアの連分数使って円周率の計算でもやってみようと思ってるんですけど、その場合計算する項のlog orderで桁数が増大していきます
でも例えばbinary splittingとかにすれば桁数の上昇具合が変わってきます
そういう用途に応じて適切なcollection型の使い分けできるようにしたいんですよ
あくまで練習なので
ソース読みはまぁ趣味みたいなもんなんですけどそもそもRustの自習が趣味なので
938 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 21:11:35.12 ID:Mgx3ApDu.net]: >>920
だからドキュメント読めってば。
Vec はポインタとキャパシティと長さを管理する仕組みだと書いてある。
https://doc.rust-lang.org/std/vec/struct.Vec.html#guarantees
実体が配列だからスライスの形で扱うことも出来る。
もし C++ を知ってるなら設計理念的には vectorと同じ感じとおもっていいと思う。
939 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 21:16:41.06 ID:kGEgc8zj.net]: >>923
まぁ実はちょっと立場上普通の人より深く知ってる事を要求されることが多いんですよ
もちろんRustを並の人より知ってると言えるには後何年か修行しないといけないんでしょうけど、そもそもRustについては趣味なのでそこまで深く理解しなくてもいいとは思ってます
まぁ趣味なのでボチボチ読みます
ありがとうございます
940 名前：デフォルトの名無しさん [2023/08/06(日) 21:39:48.28 ID:+jzrd7Vj.net]: Haskell君と同じ臭いがしますね～w
941 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 22:09:28.45 ID:lVXXe/mp.net]: >>922
何度も書いて伝わっていると思うが各データ型の性質や各用途への向き不向きは使用言語と関係ない話
その適切なcollection型の使い分けというのが仮に必要だとしても各言語と関係なく抽象的なレベルで考えて可否を判断すべきこと
その上でベクタ型のデータ構造では何がいけないのかの問題点も見えてこない
942 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 22:29:25.87 ID:jEjmg3Hf.net]: やっぱり>>914のようにサイズが不定である場合にはダメですね

The capacity of a vector is the amount of space allocated for any future elements that will be added onto the vector. This is not to be confused with the length of a vector, which specifies the number of actual elements within the vector. If a vector’s length exceeds its capacity, its capacity will automatically be increased, but its elements will have to be reallocated.

まぁ一般論ではなくて××桁まで計算するとか決めうちして使います
どのみち掛け算最終的にはFourier変換でやってみるつもりなのでその場合不定長だとメチャクチャ難しいし []; [ここ壊れてます]
944 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 22:59:01.67 ID:lVXXe/mp.net]: >>927
不定長なら再配置を含めてもVecが有利
再配置コストは例えば2^nから2^(n+1)へ広げる度にしか発生せず誤差となる
それよりも連続領域に配置されることによるメモリキャッシュ効果が絶対に効く
945 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 23:14:54.40 ID:vwDBawzd.net]: >>928
そうなんですか？
でもドキュメントには続いて

For example, a vector with capacity 10 and length 0 would be an empty vector with space for 10 more elements. Pushing 10 or fewer elements onto the vector will not change its capacity or cause reallocation to occur. However, if the vector’s length is increased to 11, it will have to reallocate, which can be slow. For this reason, it is recommended to use Vec::with_capacity whenever possible to specify how big the vector is expected to get.

とありますよ？
946 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 23:50:23.90 ID:lVXXe/mp.net]: それを読んで再配置があった場合でも1回あたりO(1)で済んでいることが理解できないならば
Rustの勉強でもなくプログラミングの勉強でもなくCSなどの基礎から学ぶことをおすすめする
そういう基礎を理解しないままO(1)で行ないたいと最初の質問で書いていたのもヤバい
何度も伝えているが各言語と関係なく成り立つ話なのだから各言語に立ち入る前に理解を済ませておくべき
947 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:14:34.21 ID:KoOATDug.net]: >>930
>CSなどの基礎から学ぶことをおすすめする
任意長整数型演算の実装の演習をするような人ならCSで学ぶ程度の知識はあるんじゃなのか
当然、データ構造についても一通りの知識はあると思うが
948 名前：デフォルトの名無しさん [2023/08/07(月) 00:41:08.66 ID:Sa+WohTx.net]: “amortized O(N)”を”1回あたりO(1)”に変換するあたりは流石オジ
でもCS基礎を学べというオジの主張に今回ばかりは同意するよ
949 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:47:42.86 ID:uTLlh+jk.net]: >>930なんでO(1)で済むんですか？
そもそもデータ全体を連続領域に確保するんでしょ？
その延長する部分のヒープがもう埋まってたらデータ全部丸写しするしかないんじゃないですか？
大体そもそもデータを連続領域に確保して前からも後ろからも関係なくアドレス1発でアクセスもできて、その上データの追加もO(1)でできるとかなら無敵じゃないですか？
そんな魔法のよなメモリ管理できるハズないのでは？
950 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:48:41.30 ID:Lr/s88yL.net]: Vecって単純過ぎてデータ構造では扱わなかったりするのかな
ならし解析では最初に出てきそうなネタだけど
951 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:50:22.19 ID:uTLlh+jk.net]: ああ、データの読み書きが一回あたりI(1)ですか
でも今データの追加は整数の桁数が一上がるごとに発生するんですよ？
あらかじめデータの桁数が不明でそれが難しいと言ってるじゃないですか
足し算のたびにコピー発生しますよ？
952 名前：デフォルトの名無しさん [2023/08/07(月) 00:53:46.05 ID:O5oF7I6f.net]: こいつぅ
絶対わかってないやんw
953 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:53:52.95 ID:++BmxY1A.net]: 実際バイナリスプリッティングでマクローリン級数で足し算する場合とかどうやってあらかじめ必要桁数予言するの
954 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:54:45.54 ID:eXrQj8ZH.net]: 実際どんな用途かも具体的に書いてるのに
955 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 02:21:35.00 ID:pearvhja.net]: 2年くらい前の過去スレと今の状況見比べて泣いちゃった
956 名前：デフォルトの名無しさん [2023/08/07(月) 10:50:23.98 ID:wl/Lx6N5.net]: ここまでvecdeq無しとは
957 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 18:18:54.25 ID:UTlzilSe.net]: VecDequeもその名の通りVec(正確にはどちらもRawVec)で作られていて
確保されている連続領域に対して未使用領域が末端か途中かの違いしかない

>>933は確保されている連続領域が埋まった時のコストを気にしているようだが
サイズNが埋まるまでの再配置の総コストは最悪ケースでもわずかN-1回の読み書きコストで済む

例えばサイズN/2が埋まった時にその倍のサイズNの新たな連続領域へ再配置するためにはN/2回の読み書きが発生
仮に最悪ケースでサイズ1からスタートしてもそれまでの累積の再配置コストはN/2+N/4+N/8+...+1 ＝ N-1が上限値となる
つまりサイズNが埋まるまでの再配置の総コストは最悪のケースで読み書きN-1回でありO(N)で済む

一方でサイズNが埋まるまでの再配置以外の読み書きが何回行われるかを今回のケースで考えると
次々とサイズが倍々に増えていく計算の場合は最小でも合計O(N)回の読み書きが起こり
次々とサイズがリニアに増えていく計算の場合は最小でも合計O(N^2)回の読み書きが起こり
もっと緩やかにサイズが増える場合や上述の増え方の場合でも普通に読み書きが多い計算なら合計O(N^2)を超える
現実のほとんどの計算においてVecの再配置コストO(N)は誤差となる
958 名前：デフォルトの名無しさん [2023/08/09(水) 00:49:09.66 ID:52BV6d5f.net]: >>931
＞当然、データ構造についても一通りの知識はあると思うが

今までのレス読んでそう思う？
959 名前：デフォルトの名無しさん mailto:sage [2023/08/09(水) 18:58:03.94 ID:2XWtgL1F.net]: でも競プロでvec.insert(0, value)でタイムアウトしたけどvecdeque.pushfront(value)ではタイムアウトしなかった経験があるな
960 名前：デフォルトの名無しさん mailto:sage [2023/08/09(水) 19:31:59.29 ID:X5pmvNGk.net]: VecDequeはring bufferだから連続性は保証されないね
VecみたいなDerefがないから&[T]に渡せない
slice未実装かと思ったら2つのsliceで返すas_slices()が実装されてて思ったより芸が細かかった
961 名前：デフォルトの名無しさん mailto:sage [2023/08/09(水) 22:17:02.23 ID:5oPtG5Gl.net]: >>943
そのinsertはずらすコピーが毎回O(N)かかるからサイズNになるまでの累計はO(N^2)になってしまう
一方で満杯になったときの自動再配置コピーコストの方は累計でO(N)だからさほど気にしなくていい

>>944
その時の状態配置に応じて最小コピーで連続領域にしてくれるmake_contiguous()で
連続1本になった&mut [T]を得られるのでVecDeque内でのsort()なんかもできちゃうね
962 名前：デフォルトの名無しさん [2023/08/10(木) 04:07:06.41 ID:GpbD/XFE.net]: >slice未実装かと思ったら2つのsliceで返すas_slices()が実装されてて

He-
963 名前：デフォルトの名無しさん [2023/08/10(木) 04:08:51.37 ID:GpbD/XFE.net]: vecdequeはlinkedlistじゃね
964 名前：デフォルトの名無しさん mailto:sage [2023/08/10(木) 06:08:17.32 ID:74A6gUuN.net]: vecdequeはもちろんvecで構成
linkedlistは他のデータ構造(vector, binary tree, hash table)と比較してほとんどの用途で遅く不利なため極限られた用途でしか用いられない
linkedlistが用いられる限られた用途でもlinkedlistの欠点を補うため同時にhash tableやbinary treeなどと組み合わせて用いられることも多い
965 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 08:01:08.13 ID:4oMIZBsG.net]: >>931
データ構造なんて知らなくてもできる
中学生の頃やってた

大学入った1年の前期でプログラム実習があってそこでも多倍長整数演算の計算をやった
配列で計算すんの
何も難しいことはない
966 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 08:22:37.37 ID:6e7vDYNE.net]: RustやるならCSでもまず計算モデル(特にスタックフレームモデル周辺)だろ。
967 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 08:37:22.11 ID:/t3LBfIN.net]: >>949
その配列というのが長さと場所を固定した連続領域を取るデータ構造なのよ
Vecは同じ連続領域だけど長さと場所は可変なデータ構造
VecDequeはVecを用いたリングバッファで連続領域を確保して使っているけど使用データ自体は最大二つの領域に分かれるデータ構造
LinkedListは連続領域を使わない連結リストといったようにいろいろあるデータ構造の中で質問者はどれを使うべきか悩んでるみたい
968 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 11:19:59.50 ID:4oMIZBsG.net]: 最近おかしな議論が複数のスレにまたがって続いてるけど
多倍長整数というワードすら出てこないんだからなあ
969 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 12:40:08.98 ID:v1edpQDw.net]: 複オジと厨房と二人いるのか？
それとも厨2病をこじらせた複オジか？
970 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 13:08:17.16 ID:1cDd+Y+T.net]: >>952
ユーザーは多倍長整数ライブラリを使えばいい
しかし彼は作る側でどのデータ構造を使って実装するとよいかの相談
Rustの話ではなく普遍的な基礎知識の話だけどな

>>914
>>任意長整数型演算の実装の演習してるんですけど
>>(略)
>>この場合どのcollection型が有利ですか？
971 名前：デフォルトの名無しさん [2023/08/11(金) 14:32:24.16 ID:8y9raxy5.net]: >>953
最近はこじらせてる人が3～4人いるよ
複オジは>>954
972 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 14:38:02.18 ID:WGGkjKOg.net]: 複オジ認定される人は複数いると思われ
973 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 06:55:54.99 ID:H/leygs+.net]: 誰かに雇われてるのかもな
974 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 17:12:05.53 ID:uYfXOEbY.net]: 詳しい人がいたらアドバイスをもらえると嬉しいです
やりたいこと
　入力系イベントの変換及び送出
　例えば所定のウインドウがアクティブ時にピンチインが入力されたらCtrl+「-」を送出とか
OS
　WindowsとLinux。同じコードで両OSに対応する必要はない
UI
　とりあえずCLIでも構わない
技術要素
　入力系イベントのグローバルフック。Rustではどうやる？
というか言語を問わずグローバルフックを使った新しい記事ってめっちゃ減っている気がする
現行の環境でどのような実装が良いのかよくわからない
975 名前：デフォルトの名無しさん [2023/08/12(土) 18:35:08.55 ID:Vg3fIeNP.net]: XY問題の上にRust関係ないな
976 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 20:05:24.91 ID:uYfXOEbY.net]: 今でもピンチイン/ピンチアウトで縮小拡大できないデスクトップアプリは珍しくないからね
特にエンジニアリング系アプリは有名どころでもタッチやペンに対応していなかったりするし
あと今から作るならRustを使いたいけどフックなどの実装は処理系依存になりやすく
システム言語を自称するRustでどこまでできるのかという点も興味ある
977 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 21:12:06.35 ID:ufIhf+ig.net]: 言語と関係なくね？
978 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 22:08:53.37 ID:ysM/YNb0.net]: >>961
言語の話ではないが、まぁ、RustでWinやLinuxのアプリを作るときには(激システム依存だろうが)関係するからな
WinならWinのapiを使うためのクレート
https://learn.microsoft.com/ja-jp/windows/dev-environment/rust/rust-for-windows
で頑張るとかになるだろうが。
979 名前：デフォルトの名無しさん [2023/08/12(土) 22:11:27.89 ID:ecBv/yaX.net]: アタオカがまた別のアタオカを呼ぶ
980 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 22:58:19.87 ID:SnIoCjjg.net]: >>958
今風のやり方は知らないが大昔にCでxlib使ってx11のイベント通知もらって何でもできた

>>960
CでできることはRustでできる
各分野についてRustだけで書かれたクレートもあれば
Cのライブラリを呼んでほぼ生で提供するクレートから
それをRustなインタフェースで提供するクレートもある
レアな分野で誰もクレート作ってなければ自分で作るのも難しいことではない
まずはcrates.ioでクレート探しからスタート
もし何を探すべきかがわからないのならばそれはRust以前の問題
981 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 23:35:32.02 ID:pSdIUbms.net]: まぁ仕事でRust使う人は皆無だろうからな
そして仕事でなければコンソールアプリで十分やし
家でサンデープログラミングするのにわざわざwindows sdk引っ張り出さないし
982 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 23:49:38.13 ID:SnIoCjjg.net]: むしろ仕事でWindowsを使わない
人それぞれだろう
983 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 23:52:35.31 ID:3Gp8Ilch.net]: システムプログラミング向けの言語だからデスクトップアプリでは活況ではないんじゃないかな
984 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 00:01:39.02 ID:lcT7JkgH.net]: そうか、サーバサイドの人は使わんわな
985 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 00:04:16.66 ID:RW198XaM.net]: 好きにプロセス消失してもいい系のWebサーバ向けアプリには
あんまメリットないわな。
986 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 01:00:38.38 ID:IKXyPV6w.net]: >>968
>>969
WebサーバーサイドはRustが最も適している
そしてRustが毎年調査しているAnnual Survey ReportでもRustの業務利用目的の調査トップがWebサーバーサイド＆バックエンド
https://gihyo.jp/assets/images/article/2022/09/rust-monthly-topics/in_what_technology_domain_is_Rust_used_at_your_company.png
987 名前：デフォルトの名無しさん [2023/08/13(日) 11:45:17.49 ID:mxfdwtiA.net]: また現状認識ズレた人が不況に熱心なこと
988 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 12:47:43.44 ID:tlLZmbuO.net]: クラウドはリソース(演算能力やストレージ)を使った分だけ金がかかるという話は何度も言及されているやで
989 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 13:12:36.18 ID:1wlKIUZg.net]: ずっとそれ勘違いして言い続けてるよね
急になんJ民の振りしてもバレバレ
990 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 13:31:43.04 ID:4YjHceGO.net]: >>972
オンプレミスも同じ
遅い言語を用いていると無駄にサーバー数が必要となりその電気代が固定費となってしまう
C/C++にはtokioのような非同期並行並列でCPUマルチコアを使い切れるスケジューリング環境もないため
現状Rust一択
991 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 16:16:11.90 ID:QszCfK1u.net]: オンプレでも最終的にはそうなんだけど、クラウドの力でリソースの割り当てが柔軟に出来る状況になったので
「(開発初期は) まだ余っているリソースのチューニングは後回しにする」ということが出来なくなった。
余りなど存在しないので。
992 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 20:12:32.36 ID:NbQv8fjv.net]: 費用ならjavaやc#の方が安い
利用者が多くエンジニアを集めるコストが低いので
993 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 21:37:06.42 ID:lTJXvUOS.net]: Webサービス分野だと小規模なサービスは人件費 > サーバー費用だからRustは早すぎる最適化になりがち。
とはいえ開発体験もかなり優秀な部類になってきたから初手でRust選ぶのが開発者のオナニーとは言い切れなくなってきてるよな。
994 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:11:07.62 ID:QszCfK1u.net]: ウェブサービスというものが根本的に手探りだった時代は
素早く変更してサービスに反映させられる言語が重要だったけど
今は部品が確立してそれを組み合わせる形に変わっているから
部品が充分に揃っていると仮定できるなら言語 (処理系) の性能差で差がつく。
995 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:21:31.33 ID:26EPBWum.net]: でも実際問題としてRustで組んだ人いる？
996 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:35:27.66 ID:4YjHceGO.net]: 世界のウェブインフラもRust製

【CDN世界トップシェアCloudflare】
https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。

【クラウド世界トップシェアAWS】
https://japan.zdnet.com/article/35183866/
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」、
「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」などがある。
997 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:57:04.72 ID:otTwfC5P.net]: >>980
イヤ、そうじゃなくてこういうとこで雑談するレベルの話で実際に仕事でRust使うような実例を持ってる人いるかって質問
別に煽ってるわけじゃないよ
まずそこまで流行ってないと思うしかない、仕事で実際使った人いるならどういう経緯で使うことになったのかなぁと
998 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:15:24.43 ID:QyDGXVub.net]: 自分は仕事で書いてるし、直接の知り合いで仕事で使ってる人10人くらいはいるかな
なんで国内でも数十社くらいは使ってるんじゃないかと思う
999 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:48:35.51 ID:iO5PvBbd.net]: そうなんや
それは言語はなんでもいいから好きなので書いていいん？
それともRustで書くように指示された案件？
1000 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:48:42.00 ID:427/I8XL.net]: > 自分は仕事で書いてる

開発の仕事じゃなさそう
くだらないウェブ記事書いてお小遣いもらってそう
1001 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:51:53.47 ID:6khxmh9H.net]: うちはバックエンドの一部をRust製にした
最終的には全てRust製へ置き換えるが着実に一つずつ
1002 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 00:03:15.79 ID:SMR2domD.net]: へぇ、意外にRust導入されてるんやな
1003 名前：デフォルトの名無しさん [2023/08/14(月) 02:41:34.96 ID:QUiVDENJ.net]: 蝦出んす
1004 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 06:54:36.10 ID:BvDmcvEg.net]: >>983
うちの場合はC++で書かれた部分をRustに移行した感じ
開発言語は実担当者に任されてるから自分のチームの数人で話して決定
皆C++書けるからRustも結構すぐ書けるようになってた
1005 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 08:31:01.38 ID:YSmL6IQ6.net]: こちらはNode.jsからRustへ移行だったけど
どちらもasync/awaitによる軽量タスクコードだから意外に簡単だった
1006 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 22:05:11.92 ID:VoYfevle.net]: どれも具体性が薄すぎてニートが妄想で書いてるんかってレベルやな

何の目的があってRustが選択されたのか
他の候補として何が検討されたか
最終的に目的はどの程度達成されたのか
大きな課題としてどんなものが現れたか
その課題はどう解決したか（しなかったか）

一般論じゃなく各論で、そういう特筆すべきことはなんにもなかったんか？
1007 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 22:08:35.90 ID:NTZtQKzP.net]: そうやって情報収集しようとするクセよくないぞ
自分でしらべろや
1008 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 22:13:54.79 ID:sy90BXR1.net]: このスレにいる以上は Rust に関心を持っているのは当たり前なんだから
実務で使ってる事例もそれなりにあるのは全く自然なことだと思うんだが、
そう思えない理由がなんかあるか？

LISP スレですら実務の採用例がそこそこあるのに Rust で無いってこたぁない。
1009 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 23:40:20.02 ID:GBb0r4Vn.net]: 思う思わないレベルの話はいらない
1010 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 23:49:03.15 ID:h0ddCJfE.net]: アンチの相手しなくていいんじゃないかしら
お盆に入ってからの書き込み原文ママ

「仕事でRust使う人は皆無だろう」
「サーバサイドの人は使わん」
「Webサーバ向けアプリにはあんまメリットない」
「開発の仕事じゃなさそう」
「くだらないウェブ記事書いてお小遣いもらってそう」
「どれも具体性が薄すぎてニートが妄想で書いてる」
1011 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 00:22:56.61 ID:0OuVStUx.net]: 無理やで
1012 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 01:10:11.11 ID:eHfmSxwe.net]: >>994
君のとこでは採用してるん？
1013 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 02:40:39.04 ID:ozj7JwYA.net]: 確かにこんなところで調査しても意味ねえわ
1014 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 03:17:19.17 ID:W84SzS8v.net]: NoSQLなデータ扱うマイクロサービス改修を機会にそこをRustにしたよ
1015 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 08:51:26.28 ID:ca01mENm.net]: ウクライナが勝ってるよっていう情報を流すのと同じw
1016 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef