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/
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