Rust part16

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


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

Rust part16

1 名前：デフォルトの名無しさん mailto:sage [2022/06/27(月) 08:17:03.45 ID:gDlfKP6u.net]: 公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

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

日本語の情報
https://rust-jp.rs/

※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 part15
https://mevius.5ch.net/test/read.cgi/tech/1652347700/
182 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 04:52:44.77 ID:86ZbPeAT.net]: だから
> ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として利用している場合だ。
の場合だけだろ
お前はそんな特殊なアプリしか作らないのかよw
そもそもノードの識別を全体にばらまいてるとか設計がタコなんじゃね？
183 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 05:08:33.40 ID:WHTTcdQX.net]: >>180
RubyやJava、オブジェクトの「識別番号」が取得できることがあるが、
それはポインタ値だ。通し番号ではない。
つまり、C言語では伝統的に、リンクトリストのノードを識別するために
ポインタ値が使われている。そしてそれこそがリンクリストの本来の使い方。
だれかが間違えて、通し番号で識別する習慣が生まれてしまったが、それは
集団幻覚みたいなもので、誤った使い方だ。
184 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 05:22:06.16 ID:b2cot2gP.net]: で、何が言いたいんだ？
Linked Listをアプリ全体にばらまいてるアホ設計を正当化しようとしてるのか？w
185 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 06:08:27.82 ID:8LqsNmpu.net]: >>177
気に入らないやつを片っ端から複おじ認定するのは荒らしなんだろうか
186 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 06:20:58.64 ID:Nla2AFrI.net]: >>183
その子はキチガイ
>>159でも気に入らない二人だけが書き込みしてるように見えてる
187 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 07:54:16.72 ID:n+I8xvZo.net]: >>181
GC言語では、ポインタと言ってもコストの高いポインタとなっていて、コストの高いガベージコレクションで回収する。
それに加えて、データ競合を防ぐには更に何らかの競合回避コストも加わってくる。

一方で、C/C++ではリンクされたノードリストからノードを外す時に、そのライブラリがノードを解放してしまうと、そこへのポインタを保持していた場合にダングリング発生。
それを回避するためにはshared_ptrなどのコストの高いポインタを使わざるを得ない。
ちなみにC++のshared_ptrはスレッドセーフだからマルチスレッド時でも大丈夫だが、逆に言えばシングルスレッド時には無駄なコストがかかっている。

Rustでは、そこはRcとArcの2種類が提供されており、シングルスレッド時にはコストの低いRc使用、マルチスレッド時にはRcだとコンパイルエラーとなってくれてArc使用と、最小限のコストで済む。
このようにノード解放の観点だけ見ても、考慮すべきことをRustコンパイラは適切に指摘してくれる。
188 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 10:29:00 ID:1zzLwZyb.net]: なんでずっとRustスレでRustのセールストークやってるんだ？
189 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 10:43:19 ID:XxVp5yEy.net]: RustスレでRustのネガキャンやってるやつよりマシだろ
190 名前：デフォルトの名無しさん mailto:sae [2022/07/05(火) 11:28:42.85 ID:UQspXvq+.net]: >>182
C言語が速い秘密はLinkedListとそのノードをアプリ全体でポインタ値で識別している
ことにある。先頭を0として1,2,3と割り振った通し番号を使っていたと
したら、全然速度が出ない。
そしてその証拠が、JavaやRubyなどで「識別番号」が8桁の16進数で表示できる
ことだ。その識別番号とは生ポインタ値のことであり、それがそのオブジェクトを
唯一に特定できる最も効率的な方法である。
他の方法では効率が落ちる。
191 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 11:29:55.08 ID:UQspXvq+.net]: >>185
あなたは、理解が浅い。
RustのRcやArcには欠陥がある。
そんなもので済むならとっくにCやC++でも採用されている。
C/C++の歴史の長さを舐めてはいけない。
192 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 12:22:07.18 ID:KaO4bask.net]: >>188
同じ話を何度も繰り返すなよ、ボケ爺か？
そうであってもそのアプリがCと同じでそれ以外のアプリならRustの方が安全って書いてあるだろ
193 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 12:28:00.80 ID:1zzLwZyb.net]: >>187
他人に説明できるだけの合理的理由が無いことは自覚してるんだな……
194 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 12:32:52.81 ID:84q7aSs+.net]: えっ、なにか説明が欲しかったのか？
スレ読んでりゃわかると思うがw
195 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 13:04:52.14 ID:n+I8xvZo.net]: >>189
欠陥があると主張するならば、その理由を示さなければならない。
さらにC++でも採用されていることを知らないのは無知ではないか？
C++のshared_ptr ＝ RustのArc ＝ SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
それらのスレッドセーフでないコストの安いバージョンがRustのRcである。
これらは、安全にポインタを共有しつつ即時解放を行なうために、必須の機能である。
196 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 13:13:39.59 ID:Fs2kh1Em.net]: >>188
ここでいう効率ってなんの効率？
197 名前：デフォルトの名無しさん [2022/07/05(火) 13:19:57.09 ID:MoDZ63yv.net]: ラスタシアンは何故算数おじさんに触れずにいられないのか
198 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 16:10:20.98 ID:UQspXvq+.net]: >>193
いや、RustのRcなどは、C++とshared_ptrと同じじゃない。
全然違うと言っても過言ではない。
199 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 18:30:15.50 ID:Fs2kh1Em.net]: >>195
なぜか自分のレスには反応してくれないんだよね

>>196
具体的になにが違うの
200 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 23:09:51.67 ID:n+I8xvZo.net]: >>196
違いがあると主張するならば、この議論で意味のある違いがあることを示さなければならない。
さらに前述の、欠陥があると主張した件についても、その欠陥を示さなければならない。
201 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 23:19:42.19 ID:I5LuZ1z+.net]: >>197
>具体的になにが違うの
平日の昼ひまでこのスレにくるおじさん・じじいは
C++のshared_ptrと同じじゃないということを知ってさえいれば激十分なんだよ。
だから、具体的になにが違うかは(知らないから)答えられない。
C++とRustの深い知識あるようなすごい奴が平日の昼暇でここで遊んでいる
なんてことはないだろう。
202 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 11:32:12.50 ID:jpnjV9Mh.net]: Full Stack Rust App Template using Yew + Actix!
https://youtu.be/oCiGjrpGk4A
203 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 11:45:22.14 ID:UGbPogY6.net]: UIフレームワークはスレチだよしんどけ
204 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 12:20:02.69 ID:b0Oxubv9.net]: ここRustプログラミングに関することならば何でも歓迎
各々の関心がないことの和集合を取ると全体集合になる
特定の人にとって関心がないからと言って排除してはいけない
205 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 14:24:50.14 ID:oR52wNCu.net]: 違いが大きすぎるとどこが違うとかいうのを説明するのが難しくなる。
織田信長とオムライスの違いを説明できるか？
まあ shared_ptr と Rc の違いはさすがにそこまで大きくはないけども、
前提となる C++ と Rust の違いも小さくはないので比較する意味を感じないな。
shared_ptr は shared_ptr だし Rc は Rc としか言いようがないだろう。
206 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 16:11:44.19 ID:rco22hfx.net]: リファレンスカウント方式の複製可能なスマートポインタという点では類似のものと言って良いのでは
元々はc++とrustで実行効率に差があるという話だがその観点でどういう差があるのかね
そもそも実行効率が何のことを言っているのかがよくわからんから議論しても仕方ないか
207 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 18:50:47 ID:cl7AdtI8.net]: 原理と詳細を区別できない人はちょっと……
208 名前：デフォルトの名無しさん [2022/07/06(水) 23:39:03.25 ID:DBl9eUwS.net]: >>203
全く別物の比較なら、信長は人間、オムライスは食べ物、というようなザックリした説明で良くなるのでは？
209 名前：デフォルトの名無しさん [2022/07/06(水) 23:45:15.32 ID:DBl9eUwS.net]: Arcとstd::shared_ptr<>が似てるという人に対して、「いや、std::shared_ptr<>とRcは全然違う」と反論するのがおかしいのでは？
210 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 00:18:57.43 ID:6JbvD3+y.net]: >>206
そうだよ。
それを適用するなら
shared_ptr は C++ のスマートポインタ、 Rc は Rust のスマートポインタということしか言えなくなる。
211 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 00:49:54.35 ID:Sq6Pkb7P.net]: >>208
俺らのレベルではその程度の知識で十分だろ
で、スマートポインタでもなんか違いあるの？と質問されても具体的に答えられなくても
全く問題ないからな。
一方、すごい人からすれはstd::shared_ptr<>とRcは全然違うとなるんだろうが
(すごい人敵にはそれらは例えばstd::shared_ptrは信長で人間、一方、Rcはオムライスで食べ物ぐらい違う！
でも、俺らは人間だって餌として食べることができるから同じだろ)
212 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 05:04:39.45 ID:WPmCyDkS.net]: >>196
>>193 は
> C++のshared_ptr ＝ RustのArc ＝ SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
って書いてるんだから同じじゃないとか全然違うとかフワフワしたこと言ってないで
・機能
・スレッドセーフ
・リファレンスカウンタを利用
の各項目について違いを書きなよ
213 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 08:43:50 ID:M+xvnEsX.net]: 共有ポインタって何？
214 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 10:54:08.79 ID:LNwVrqhE.net]: shared pointerじゃね？
215 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 11:14:16.23 ID:xmv5m6Ag.net]: 結局参照カウント方式なのは一緒なんでしょ
216 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 12:48:02.98 ID:kuHYrppG.net]: >>212
だとするとshared pointer方式ってどんな方式？？
リファレンスカウンタを利用しないshared pointer方式もあるってことだよね？
217 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 14:09:00.32 ID:1csywUpz.net]: >>214
shared pointerはc++のが有名すぎるからなんとも言えないなぁ。

参照カウント以外でポインタを共有するのはリンクリスト方式とかあるよ。
218 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 15:30:16.82 ID:jjCeBJbE.net]: ARCで管理してる時点でRustはガベコレじゃないからすごい！って理論は破綻してるんじゃありませんかね？
219 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 15:41:53.87 ID:6JbvD3+y.net]: >>216
誰がそんなこと言ってんの？

静的に管理できるものは静的に管理するし、実行時にしかわからないものは実行時に管理するってだけのことだ。
参照カウンタの適用範囲を間違えてるプログラマがいるならそれはそいつが無能。
220 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 16:01:25.39 ID:HUExG/fK.net]: Rust公式の日本語意訳にはしっかりRustはガベコレじゃないから高速って書いてあるね
221 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 16:16:37 ID:I5wN0SQd.net]: >>216
Objective-C/SwiftのARCとRustのArcは同じ3文字略語だけど別のものだよ
それを理解した上で言ってるのなら別にいいんだけどさ
222 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 18:43:04.02 ID:u5IGnUan.net]: >>216
そもそもRust公式が「メモリリークはメモリ安全の範疇」と言っているしな。
223 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 18:52:31.81 ID:pAImJ0Xg.net]: >>220
それはRustの定義がおかしい
一般的にはメモリリークがあるとメモリ安全だとは言わない
224 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 18:55:30.53 ID:V91F8QUY.net]: 流れぶった切りだけど単純にRustの人たちはGUIどうしてんの？
225 名前：デフォルトの名無しさん [2022/07/07(木) 19:11:09.29 ID:Efq0h4+x.net]: なんだ、じゃあ、バグはセーフティと定義したら、Rustは安全高めなのか。
226 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:29:21.10 ID:webRw0a6.net]: rust にクラスはないのですか？
227 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:39:16.69 ID:6JbvD3+y.net]: >>221
Rust が言語の仕組みによって防ごうと努力する範囲にメモリリークは含まないという定義だよ。
それを表すのに「Rust の仕様の中では」メモリ安全という用語を使っているのであって、
定義におかしいもクソもない。定義なんだから。
228 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:46:35.34 ID:6JbvD3+y.net]: >>224
クラスと名付けられている概念はない。
あなたにとってクラスとは何のこと？何が出来ればクラス？
229 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:48:37.87 ID:UC7ZSmFv.net]: 型クラスの事を聞いてるんじゃない？
230 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 19:49:32.87 ID:idvDnT2E.net]: >>216
ARCで管理しているのはSwift
RustはC++と同じくRAIIなので高速
どうしても共有メモリを使いたい時のみshared_ptrやRc/Arcを用いる
231 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:00:40.75 ID:pAImJ0Xg.net]: >>225
そのRustの仕様の中でメモリ安全性を達成できていないんだから
Rustの仕様の中でメモリ安全性という用語を使うのは不適切
Rustの謳うメモリ安全性は世間一般のメモリ安全性とは異なる概念なんだからそれを表すには他の用語を使うのが適当かと
232 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:06:09.82 ID:idvDnT2E.net]: >>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい
233 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:09:54.71 ID:6JbvD3+y.net]: >>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。
234 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 20:25:04.56 ID:idvDnT2E.net]: >>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい
235 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 21:01:30.61 ID:0wlfNyVX.net]: >>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ
236 名前：ﾌ名無しさん mailto:sage [2022/07/07(木) 21:12:46.12 ID:PQWZgdhj.net]: >>222
windows-rsでunsafe祭りになりながら書いたよ。オススメはしないが。
237 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 21:39:23.64 ID:pHkHW2c/.net]: SwiftのARCとRustのArcの区別がつかない人は論外なので発言を控えてほしい
ただでさえしょうもないのにしょうもなさが倍増するからね・・・

SwiftのARCはAutomatic Reference Counting
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

RustのArcはAtomically Reference Counted
https://doc.rust-lang.org/std/sync/struct.Arc.html
238 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 22:03:40.09 ID:webRw0a6.net]: >>230
継承をやめて委譲にすれば割とまともになると思います
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51
https://mevius.5ch.net/test/read.cgi/tech/1434079972/84
239 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 22:05:44.36 ID:idvDnT2E.net]: >>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速
240 名前：デフォルトの名無しさん mailto:sage [2022/07/07(木) 22:11:56.95 ID:hEh+9Mpq.net]: >>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ
241 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 03:25:18.13 ID:CKdXv9cu.net]: それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね？
242 名前：デフォルトの名無しさん [2022/07/08(金) 03:34:35.68 ID:tnmgUx+u.net]: うーん。
このスレ↓では、Rustはメモリーリークしない、Cはリークすると議論してたからなあ。

https://mevius.5ch.net/test/read.cgi/tech/1650185555/
243 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 07:13:21.57 ID:vMUJBeEa.net]: pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い

それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態

ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ
244 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 07:47:38 ID:ifo4L8le.net]: >>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん！になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な
245 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:02:14.74 ID:i9Nd4OSx.net]: PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。
246 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:04:43.63 ID:pMnIhSXO.net]: >>242
外人の禿げたおっさんはだいたいエスキューエル言うてるやろ
247 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:11:32.47 ID:i9Nd4OSx.net]: コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。

それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。
248 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 08:44:10.67 ID:efA8XUrt.net]: >>240
メモリリークに関しては

まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない

したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い
249 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:06:34.18 ID:ujjjtz1g.net]: ほんと無知って怖いね
250 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:12:01.24 ID:1lqt9Ku2.net]: 「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない......
251 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:29:57.41 ID:L1lQIkzy.net]: ほんとこの種の信者は迷惑だわ
普通は多人数で作業して、データー構造をRc<T>をWeak<T>にあらかじめしておくようなことはしないし、”わざと作成したのだから意図通り”とか
相手（これから学ぶ人や新人）を騙すために都合の良いことを吹き込んでいるようにしか見えない・・・
それなら自動メモリ管理ではないので、作り方/使い方により自然/意図しない使い方でリークも場合もあると明確に認めて、その分だけ
自動メモリ管理ではないないので速度が速いし、メモリー解放のタイミングもある程度コントロール出来ると誠実に話したほうが余程、印象が良いのに。
胡散臭い宗教の勧誘に見えるような態度だから叩かれる
252 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:30:47.62 ID:Gv4jmnae.net]: >>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな

一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね
253 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:41:28 ID:v7XD1ZOP.net]: 循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな
254 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:42:55 ID:QpPOct5C.net]: >>248
新たなプロジェクトが次々とRustを採用している現実を直視しようぜ

>>249
循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ
255 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 09:58:58.97 ID:BqWLp+Ol.net]: RAIIでメモリをケアするのは
GC方式にくらべて高速ってのはまぁそうなんだけど
それよりも
開放タイミングが決定的であることのほうが特徴
オブジェクトの生存期間によってメモリの使用期間もプログラマが管理できて嬉しい
256 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:01:11.06 ID:bBPWEvXX.net]: >>236
参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。
257 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:37:51 ID:4Cg/jdLt.net]: >まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
この時点で嘘だらけなんだから、それ以上読む必要無い

日本語ブログだとこういう複オジレベルの人が多数派なので
Rustを本気で学びたいやつは英語のリソースメインで学ぶことを強くすすめる
258 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:39:17 ID:u4+He/YT.net]: >>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ
259 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 12:42:18 ID:u4+He/YT.net]: >>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている
260 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 14:56:50.59 ID:bBPWEvXX.net]: >>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。

Rustもメモリ解放しない実装なのかね？RAIIならスタック領域しかメモリを確保しないとか。
261 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 16:11:26.76 ID:VZayErSn.net]: >>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い

Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない
262 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 16:24:07.17 ID:atE4xqm8.net]: 短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り

100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ
263 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 16:35:35 ID:VZayErSn.net]: >>260
これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている
264 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 17:23:29.15 ID:cRmlWf2z.net]: copying GCはJavaで使われているのだが

解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの？
265 名前：デフォルトの名無しさん [2022/07/08(金) 18:32:33.29 ID:r9xh0XFc.net]: >>246
C++にもweak_ptr<>あるけど。
266 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 18:32:40.38 ID:IcalP2aj.net]: RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの？
267 名前：デフォルトの名無しさん [2022/07/08(金) 18:42:02.74 ID:r9xh0XFc.net]: でも、Firefox良く落ちるじゃん。
268 名前：デフォルトの名無しさん [2022/07/08(金) 18:45:00.33 ID:r9xh0XFc.net]: でも、JavaはC++も20倍速いってサイト無くなったじゃん。
269 名前：デフォルトの名無しさん [2022/07/08(金) 18:50:36.37 ID:r9xh0XFc.net]: >>261
だって、RustはC++0xのパクリじゃん。
270 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 18:52:55.66 ID:hlO59OkW.net]: >>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ

SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い
271 名前：デフォルトの名無しさん [2022/07/08(金) 18:54:07.09 ID:r9xh0XFc.net]: じゃあ、unique_ptr<>でいいじゃん。
272 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 19:10:19.78 ID:hlO59OkW.net]: >>269
unique_ptrとshared_ptrの役割の違い、動作の違いを理解できていない君が
間違えて用いてもC++ではコンパイルが通ってしまったりして実行時に問題を引き起こす
Rustは間違えて用いるとコンパイルエラーとなり通らないから安全側に救われる
273 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 20:02:01.67 ID:A8oltmgp.net]: >>268
参照型の全てにshared_ptrを利用したら何で遅くなるの？
274 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 21:48:50.65 ID:i9Nd4OSx.net]: >>257
即座に開放というのがOSに返却とか認識してたらアウトだぞ。
アロケーターなに使うかで実際の挙動は変わってくるからな。
普通しないがクソアロケーター使ったら、OSからみたらリーク同然になったりするし。
275 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 21:53:34.22 ID:G/CdBPp1.net]: 所有者がいないとメモリ解放って間違ってるよね？

所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない
276 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:05:32.56 ID:h7kEq7Ot.net]: OSSでうっかり強循環参照作ってしまってた例が過去スレにあったようなと掘り返してみたところ、Part11にて発見

https://github.com/DataDog/glommio/commit/677fe1dfbaf911245fbc5c3eef75532d08d784bf
https://github.com/KWARC/rust-libxml/commit/bd4b120b90b2568ca6d5bfaa368a200573b87d09
277 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:23:05.26 ID:RqLk9Xjf.net]: >>272
そんなバカな認識するのはオマエだけだろｗ
278 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:38:42.99 ID:J0vSCVey.net]: >>273
所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される
279 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 22:51:41.26 ID:j0PLF9Z7.net]: 所有権とは？の話に戻っちゃうな
複製おじさんネタで散々繰り返したやつ
280 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 23:06:47.48 ID:QSUHt/6/.net]: お前ら何回同じ話ループさせたら気が済むの？
281 名前：デフォルトの名無しさん mailto:sage [2022/07/08(金) 23:08:26.12 ID:h7kEq7Ot.net]: なんか合ってるのか分からんけど最近思うこと

Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない？
282 名前：デフォルトの名無しさん [2022/07/08(金) 23:12:47.70 ID:r9xh0XFc.net]: C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。
283 名前：デフォルトの名無しさん [2022/07/09(土) 00:08:13.16 ID:Xo3+Ls6P.net]: コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと？
284 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 03:43:55.29 ID:dAPednzC.net]: >>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ？ゴミのくせにイキって恥かいてんじゃねーわｗ

The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
285 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 06:36:52.71 ID:x6eGZQ2/.net]: >>276
間違ってることを合ってると強弁するのいい加減辞めなよ
286 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 07:31:04 ID:O4my42l1.net]: 認める事を全くせず、大したコードも書いてないのにRustやってる事だけが自尊心だから勝手にアンチだの決めつけて
いつも人を見下して偉そう。プロジェクトチームの雰囲気はそいつがいるだけで常に最悪、チームの重荷・会社の害悪。
口癖は「意味不明」
287 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 10:34:16.63 ID:OnqDT6DB.net]: >>282
実際にコードを自分で書いて理解したほうがいいよ。
その公式Bookに書かれている内容はもちろん正しいし、
その相手>>256の書き込み内容も正しくて、
両者に矛盾はないよ。
288 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 11:42:59.26 ID:lwwTn4Ql.net]: 理解してないと書いてる人間が理解してないことは多いですよね
289 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 11:50:07 ID:lwwTn4Ql.net]: どちらにしてもRust使っても気楽にコーディングできるわけでもなく
メモリ構造考えなければいけないんですね
290 名前：デフォルトの名無しさん [2022/07/09(土) 13:10:56.08 ID:g+WH1rkE.net]: 結局、C++0xのパクリじゃないですか。
C++はそこからさらに10年以上進んでるのに。
291 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 13:14:26.15 ID:lwwTn4Ql.net]: それはないかな…
どっちも一長一短で視点がぼやけます
292 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 13:41:18.89 ID:ByPaZ1uJ.net]: >>279
説明用に作った概念ではあるけどRustの根幹に関わる重要な概念なので
「ただのメタファーでしかない」という言い方は微妙
自分の好き勝手に解釈した内容を公式見解かのように流布する輩を助長することになるから
293 名前：デフォルトの名無しさん [2022/07/09(土) 14:19:07.01 ID:g+WH1rkE.net]: パクリ元のC++で所有権と呼ばれてるからでしょ。
294 名前：デフォルトの名無しさん [2022/07/09(土) 14:21:22.91 ID:g+WH1rkE.net]: C++は高機能すぎて分けワカメなので、初心者用に出来ることを減らしますという、ジェネリクス界のPythonがRustでは？
295 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 14:57:08.15 ID:gD3yh/Bo.net]: >>283
見たけど正しいやん
間違ってる！とウソをつくけど間違ってる点を指摘できないいつもの人かね？
296 名前：デフォルトの名無しさん [2022/07/09(土) 15:04:05.66 ID:g+WH1rkE.net]: 誰も所有してないのに解放されないなら意味ないじゃん。
297 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 15:25:00.91 ID:3oDyg2LH.net]: >>294
ヒープ領域に対して誰も所有(利用)しなくなった時に
・自動解放しない(要手動解放)　←　C　C++(下記除く)
・即座に自動解放する　←　Rust　C++(unique_ptrなど使用時)
・GCする時になってから自動解放する　←　ほとんどのGC言語
298 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 15:36:21.95 ID:lXmK1DKz.net]: Cで書くにしても、今時のCLIツールならヒープなんか解放せず放置しても実用上問題ないよね
299 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 16:18:04 ID:y0LX8Rgp.net]: そもそも間違ってるとは何と照らし合わせて間違ってるという主張なのか
「そうあるべきではない」というべき論なら前提を明確にしない限り知らんがなとしか言えん
300 名前：デフォルトの名無しさん [2022/07/09(土) 16:36:33 ID:g+WH1rkE.net]: >>295
いや、C++はアロケート時にアロケータを選択するから。
デフォルトが準備されてるだけで。
当然、GCもあり得るから。
301 名前：デフォルトの名無しさん [2022/07/09(土) 16:39:05 ID:g+WH1rkE.net]: だめだ、こいつに聞いても無駄だ。
誰かわかるやつ居ないのか。
302 名前：デフォルトの名無しさん [2022/07/09(土) 16:52:06 ID:3+oPDqor.net]: この板で最も勢いのあるスレになりましたな
303 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:15:21.88 ID:ziCGmT1x.net]: >>284
アンチ君は皆に論破されると毎回
思い込みの仮想敵を作り人格攻撃を始めて逃避するようだが
そんな下らないことはアンチスレでやってほしい
304 名前：デフォルトの名無しさん [2022/07/09(土) 17:29:07.29 ID:g+WH1rkE.net]: 自分より詳しいやつは全部アンチか。
それじゃダメだろ。
305 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:45:35.96 ID:bJtJfEbP.net]: Rust信者スレ作ったらそっちに移動してくれますか？
306 名前：デフォルトの名無しさん [2022/07/09(土) 17:54:41.59 ID:g+WH1rkE.net]: つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ？
307 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 17:58:46.63 ID:QKZ/1qEu.net]: >>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな
308 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:04:41.00 ID:SVLGLpJF.net]: Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。
309 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:22:19.04 ID:HoR4NOuF.net]: >>304
C++以外からもいろいろパクってるからその言い方だと不正確に思う
310 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:46:05.22 ID:hyXSHlQu.net]: 正確にはこうだな

プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust
311 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 18:55:55 ID:FBd+xess.net]: 実用的の定義が無いので不正確です
312 名前：デフォルトの名無しさん [2022/07/09(土) 18:58:45 ID:g+WH1rkE.net]: C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。
313 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:05:24 ID:hyXSHlQu.net]: >>309
そこは常識の範囲内で実用的をどのように定義しても>>308を満たすのはRustだけだから問題ない
314 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:22:48.72 ID:kZfneOfi.net]: 別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ
315 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:29:47.99 ID:TbjkUF4v.net]: >>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全
316 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:30:20.48 ID:6ug5/LDh.net]: 難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。
317 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:36:03.58 ID:hyXSHlQu.net]: >>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている
318 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:48:49.13 ID:HoR4NOuF.net]: >>315
rustだけが満たしている根拠教えて
319 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:51:24.99 ID:zb7jG/MW.net]: じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ？安全じゃないんだろ？ぷゲラ
320 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 19:52:51.29 ID:FBd+xess.net]: うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか
321 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:07:34 ID:kZfneOfi.net]: >>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど

>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど
322 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:08:04 ID:TbjkUF4v.net]: >>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない
323 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:29:03 ID:r2wQepG1.net]: C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった
324 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 20:47:42.85 ID:FBd+xess.net]: ― フクオジ書 12:4-5
325 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:21:56.68 ID:6ug5/LDh.net]: >>319
そのレベルの違いが重要なわけじゃん
326 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:26:07.86 ID:rB16NsHU.net]: >>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう
327 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:36:29.93 ID:TbjkUF4v.net]: >>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++
328 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:37:18.68 ID:FBd+xess.net]: 「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな？それともわざとかな？
329 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:40:36.28 ID:N6dBVNoC.net]: マ板のコテハンが常駐するとどのスレも不毛地帯になるな
330 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 21:51:31.23 ID:8h5AdXRe.net]: >>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ

>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない
331 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:07:58.78 ID:dPnpzXnF.net]: アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」
332 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:17:01.66 ID:5J/+jd/X.net]: 話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい
333 名前：デフォルトの名無しさん [2022/07/09(土) 22:18:10.11 ID:GNVCknQf.net]: コテハンとは一体
334 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:29:14.97 ID:FBd+xess.net]: >>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ
335 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:30:12.39 ID:dcG9hbvO.net]: >>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな
336 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:36:53.48 ID:qKBLdUt5.net]: 年寄りはRustに構わないで欲しい
黙ってCでも書いてて
337 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:44:39.49 ID:3KUXTO+D.net]: >>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用
338 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:46:38.67 ID:dcG9hbvO.net]: >>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ
339 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 22:59:01.59 ID:hVKa6Imk.net]: > 287 名前：デフォルトの名無しさん　[sage]　投稿日：2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね

読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと
340 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:05:49.23 ID:dcG9hbvO.net]: >>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな

で、なんでmsvc必要なんだ？
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか
341 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:15:33.27 ID:yHOdCoxc.net]: >>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている

話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか？
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから
342 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:30:15.11 ID:hVKa6Imk.net]: >>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた？
調べたら、その結果をここで報告よろしく
343 名前：デフォルトの名無しさん mailto:sage [2022/07/09(土) 23:45:37.10 ID:yHOdCoxc.net]: >>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
344 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:12:02.83 ID:VXHYDjJa.net]: >>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ
345 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:13:44.27 ID:ZPTgd3k2.net]: >>341
["rust linker cc not found"] [検索]
346 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:16:59.60 ID: ]: [ここ壊れてます]
347 名前：CjJVLv20.net mailto: まあ>>287の書いてるメモリ構造という言葉はメモリレイアウトでもデータ構造でもないのは明らかだけどな []: [ここ壊れてます]
348 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:18:51.99 ID:z1Ut0loV.net]: 隔離スレ復活させないとノイズだらけできつくなってきた
349 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:30:08.21 ID:tvXCky2C.net]: >>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない

プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている
350 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 00:33:22.94 ID:tvXCky2C.net]: >>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う

今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/
351 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:01:37.00 ID:/Pm6re6i.net]: 複オジに絡んだ俺がバカだったわw
352 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:02:48.63 ID:qjKEOyYX.net]: >>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな
353 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:09:37 ID:ZPTgd3k2.net]: https://mevius.5ch.net/test/read.cgi/tech/1657382429/

隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ
354 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 01:48:41.75 ID:LxkGLd0V.net]: >>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ？
355 名前：デフォルトの名無しさん [2022/07/10(日) 04:45:49.56 ID:T5qatPVB.net]: 荒らしてるのはLinux板の連中か。
356 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 08:32:10.98 ID:VKvLuEGz.net]: Cellを使っていて思ったんだが例えば

trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}

impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}

このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな

let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));

身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
https://godbolt.org/z/19c4EbErG
357 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 12:00:25.54 ID:oYFJk9+G.net]: >>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと
358 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 13:59:32.22 ID:blpABUiA.net]: >>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる

自分が排除される側にいる自覚がなければそんなことやらない
359 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 19:54:18.59 ID:/ZDhY4rW.net]: >>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい
360 名前：デフォルトの名無しさん mailto:sage [2022/07/10(日) 23:37:14 ID:nSquZ6Rt.net]: >>308
プログラミング言語界に大革命をもたらした画期的な言語だな
361 名前：デフォルトの名無しさん [2022/07/11(月) 00:14:06.35 ID:triNevnR.net]: 15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の？unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった

今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ

あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ
362 名前：デフォルトの名無しさん [2022/07/11(月) 10:40:05.73 ID:1W23UOpt.net]: const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん
363 名前：デフォルトの名無しさん mailto:sage [2022/07/13(水) 23:59:24.88 ID:qlTJEO+a.net]: >>353
もっと便利にできるぜ

use std::cell::Cell;

trait CellWithMethod<T> {
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R;
}

impl<T: Default> CellWithMethod<T> for Cell<T> {
#[inline]
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R {
let mut inner = self.take();
let result = f(&mut inner);
self.set(inner);
result
}
}

fn main() {
let foo = Cell::new(vec![1, 2, 3]);
foo.with(|v| v.push(7));
assert_eq!(4, foo.with(|v| v.len()));
assert_eq!(7, foo.with(|v| v[3]));
assert_eq!(vec![1, 2, 3, 7], foo.with(|v| v.clone()));
}
364 名前：デフォルトの名無しさん mailto:sage [2022/07/15(金) 21:39:01.85 ID:qV4GyRtM.net]: >>360
CellでVec使えるのか
何か間違って学習していた

https://qiita.com/wada314/items/24249418983312795c08
＞ 1. Cellの中身の型はCopyをimplしていなければならない

https://dev.classmethod.jp/articles/rust-smart-pointer/
＞・Cellの中の型はCopyトレイト実装が必須

https://qiita.com/usagi/items/fc329895cebd3466910e
＞ Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
＞ i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。

https://zenn.dev/mebiusbox/books/22d4c1ed9b0003/viewer/5df75e
＞ Cell<T> の大きな制約として， T は Copy トレイト境界があることです．

実際にはCellはCopyを要求していない
やってみたら>>360のコードが動いてCell<Vec<_>>が使えた
365 名前：デフォルトの名無しさん mailto:sage [2022/07/15(金) 22:48:49.30 ID:fFdw7/F8.net]: #[derive(Clone)]のコーナーケースに遭遇した
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=487e64c7c762fb0e015e1bc9b1267fbd
366 名前：デフォルトの名無しさん mailto:sage [2022/07/15(金) 22:50:32.95 ID:SBkpZpFk.net]: やっぱりrustcはバグが多いね
367 名前：デフォルトの名無しさん mailto:sage [2022/07/15(金) 23:12:58.85 ID:nxNpCMHU.net]: >>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
https://github.com/mcarton/rust-derivative
368 名前：デフォルトの名無しさん mailto:sage [2022/07/16(土) 00:28:56.56 ID:730D9OZt.net]: >>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな
369 名前：デフォルトの名無しさん mailto:sage [2022/07/16(土) 23:27:56 ID:MG4+BxCd.net]: >>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな
370 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 00:26:56.65 ID:XqWqiApN.net]: StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。
371 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 01:36:05.55 ID:bF1qPY0V.net]: >>367
お前の観測範囲が狭いだけ。
372 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 08:04:49 ID:XbfHqe9W.net]: CarbonとかいうRustとC++のあいのこみたいなのが出てきた
373 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 12:35:25 ID:FCfDFeLf.net]: Carbonは最強言語ぞ
374 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 12:39:05 ID:MUkQlR/e.net]: RustがCarbonに勝ててるところが見つからないな
375 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 12:45:18 ID:ThH+Z+BW.net]: Rust vs Carbonスレ立ててそっちでやれ
376 名前：デフォルトの名無しさん [2022/07/20(水) 13:30:14 ID:S6pSKHOi.net]: このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
377 名前：デフォルトの名無しさん [2022/07/20(水) 13:30:16 ID:S6pSKHOi.net]: このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい
378 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 14:11:36.68 ID:xLuB33a9.net]: 1.0が出てからにしてください
379 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 14:52:25.57 ID:IMMZUJf4.net]: CarbonとRustは名称の紛らわしさではどっこいどっこいだな
380 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 14:54:39.84 ID:igxVbWbR.net]: ほーん
https://github.com/carbon-language/carbon-lang
381 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 17:02:14.65 ID:xLuB33a9.net]: とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう
382 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 19:50:56 ID:hGf+NvAH.net]: JSのTypeScript
C++のCarbonって感じかね

どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1かいつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな
383 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:00:37 ID:xdIX6xM1.net]: Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える
384 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:01:46 ID:sReX4jGj.net]: Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど
385 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:33:50.16 ID:sReX4jGj.net]: そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする
386 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 20:52:36.69 ID:oyesoq1v.net]: ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した

どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど…
387 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 21:27:24.19 ID:mJssGRdK.net]: Carbonって中途半端すぎね？
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ
388 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 21:44:56.66 ID:qLBZujX3.net]: >>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる
389 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:16:07.31 ID:gROTqHCf.net]: ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが
390 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:21:24.71 ID:9oJrmZpV.net]: >>386
逆じゃね？企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど
391 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:28:16.35 ID:3tivAU0I.net]: SDGsの流れ的にCarbonは使われなくなる運命
392 名前：デフォルトの名無しさん mailto:sage [2022/07/20(水) 22:43:27.67 ID:xLuB33a9.net]: なる、元素記号Cからの名称か
393 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 00:45:01.09 ID:g1dckGB4.net]: 5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな

モジュールでは全体が見通せない
394 名前：はちみつ餃子 mailto:sage [2022/07/21(木) 00:52:44.62 ID:/hG5LMVG.net]: 話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。

それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。

C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。
395 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 00:54:52.22 ID:0vTmbBj3.net]: 話題が逸れるが、...で読む気失せたわ
396 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 00:58:24.47 ID:MOkaWH3B.net]: >>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである
397 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 01:00:56.06 ID:g1dckGB4.net]: 似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か

モジュールではないな
398 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 01:15:53.78 ID:MOkaWH3B.net]: >>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない

Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる
399 名前：デフォルトの名無しさん [2022/07/21(木) 03:25:39.61 ID:DiLbgRco.net]: いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる
400 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 04:26:36.96 ID:VmE9g8Ff.net]: ポインタあるじゃん
401 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 05:01:15.84 ID:hbmQrHo+.net]: >>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる
402 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 08:09:40 ID:HHuzACnI.net]: >>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。
403 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 13:48:15.98 ID:xy799ZfA.net]: >>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな？
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた
404 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 15:49:13.07 ID:Q1uK5/Rv.net]: >>400
Haskellの型クラスの方が先だろ。

「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。
405 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 16:58:11.12 ID:xy799ZfA.net]: >>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった
406 名前：デフォルトの名無しさん [2022/07/21(木) 17:50:57.39 ID:eNA5340i.net]: traitの画期的な部分はc++のabstract classで実現できないの？
407 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 17:54:16 ID:F7Gtvv1S.net]: >>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何？

associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし
408 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 18:07:36 ID:ySHdWcK4.net]: 自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト

カルト化した人間とまともな議論ができると思うな
409 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 18:19:30.67 ID:xy799ZfA.net]: >>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの？
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ
410 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 19:01:28.92 ID:HGs+QJMA.net]: >>406
そういうのを誘導しないからお前はダメなんだよ。

prev.rust-lang.org/ja-JP/faq.html#how-do-rust-traits-compare-to-haskell-typeclasses

How do Rust traits compare to Haskell typeclasses?
Rust traits are similar to Haskell typeclasses, but are currently not as powerful, as Rust cannot express higher-kinded types. Rust’s associated types are equivalent to Haskell type families.
411 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 19:15:30.44 ID:F7Gtvv1S.net]: >>407
traitの方が表現力低いって言ってるじゃねーか
412 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 20:10:50.68 ID:SY914jbi.net]: レスバスレ使ってくれませんか？
413 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 20:48:28.30 ID:rGFlKcYB.net]: >>407
それURLがprevで始まっているように古い情報ページ
わざわざそれを出すのは何か意図がある？
414 名前：デフォルトの名無しさん [2022/07/21(木) 21:43:04.55 ID:vaotA28G.net]: >>408
正しい情報を啓蒙するのは面倒だということを知らしめる意図じゃない？
415 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 21:59:42 ID:vJeGD7jb.net]: >>404
Rustのトレイトは
トレイト境界を実装で指定できるだけでなく
トレイト境界を型宣言でも指定できるなど
様々な点で型クラスと異なるよね？
416 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 22:56:58.50 ID:crFoTo11.net]: 幽霊型🥺
417 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 23:06:53.32 ID:XUR5FOR ]: [ここ壊れてます]
418 名前：i.net mailto: >>404
associated typeもhaskell由来 []: [ここ壊れてます]
419 名前：デフォルトの名無しさん mailto:sage [2022/07/21(木) 23:56:47.54 ID:vrEITS91.net]: >>412
トレイトに関しては当然Haskellの型クラス由来の部分が多いけど互いに片方にしかないものもあり異なる側面があるわけか
420 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 00:02:56.00 ID:Dec8FkF+.net]: >>412
よくわかんないからコードで書いて
421 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 00:07:23.73 ID:3PGiuxDq.net]: 今のところ型システムは完全下位互換だよ
422 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 00:22:12.08 ID:hXBfLf2I.net]: >>416
普通のこれだろ
struct Foo<T: Trait1 + Trait2> {
　inner: T,
}
423 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 00:32:54.07 ID:/9LzCqck.net]: >>418
これが>>402が言う型クラス以上の意義があるものなの？
424 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 00:45:08.67 ID:hXBfLf2I.net]: 402の話は402に聞け
少なくとも>>418は型定義の時点で制約できるから意義がある
425 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 00:46:45.91 ID:Dec8FkF+.net]: >>418
-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
426 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 01:09:40.70 ID:hXBfLf2I.net]: >>421
いきなり何かわからない話を向けられても困る
解説せよ
427 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 01:43:49.12 ID:kvE65+oR.net]: トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
俺の中ではインターフェースと一緒の扱い

Rustが画期的だったのはOwnership/Referenceルール + Borrow Checker
この点に異論ある人はいないよね？
428 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 02:15:42.10 ID:g+hZIhYV.net]: >>423
一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ

>>419
その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる
429 名前：はちみつ餃子 mailto:sage [2022/07/22(金) 03:26:24.88 ID:fX2QhDiX.net]: >>424
そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。
430 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 03:47:26.49 ID:u1/oKmBi.net]: >>425
それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ
431 名前：デフォルトの名無しさん [2022/07/22(金) 05:52:26 ID:FhKnOINS.net]: C++の欠点は、何でもできること。
その欠点をなくして、わかりやすくしたのがRust。
バイナリ界のJavaと言い換えても良い。
ほとんどのプログラマはC++よりRustを使うほうが良い。
432 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 08:04:03.49 ID:FDKNW5k7.net]: >>410
だから最新情報に誘導しろよ。
無能か？
433 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 09:31:13.18 ID:8cs6kRrX.net]: >>427
これからRustはIT土方専用言語になっていくんだろうなあ
434 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 09:55:09.86 ID:aK9LU/qI.net]: >>424
>一般的なインタフェースなんて
>Trait Boundsもimpl Traitもdyn Traitもないゴミ

言語化できてないから本質を理解できていように見える

Trait Boundはジェネリック型の型制約で一般的なインターフェイスも型制約として機能する
一般的なインターフェイスは動的ディスパッチなのでdyn Trait相当

impl Traitがmonomorphizationのことを言ってるならそれはTraitの機能じゃなくGenericsの機能
C++で20年前から使えるよね？
C++以外でもSwiftみたいに一部の言語はGenericsのspecialization機能があるけど一般的にはオーバーロード使ってstatic dispatchにすることが可能
435 名前：デフォルトの名無しさん [2022/07/22(金) 10:57:57.42 ID:GQh1j6M0.net]: >>418
javaのgenericsでextends使うとできるやつかな？
436 名前：デフォルトの名無しさん [2022/07/22(金) 11:30:46.07 ID:emgmw9dd.net]: Java厨は出て来ないで下さいうざいだけです
437 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 11:34:22.85 ID:LVIZaCij.net]: >>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。
438 名前：デフォルトの名無しさん [2022/07/22(金) 13:14:37.08 ID:GQh1j6M0.net]: >>432
rustの画期的な部分なんだろ？言い返せないのかよダサいなお前

本当に革新的なのは>>423あたりなんじゃないの
439 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 14:36:57 ID:ZDp8+ZKO.net]: kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。
440 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 14:59:23.46 ID:hnGDX2CP.net]: >>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている
441 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 15:43:33.15 ID:yLavWCdC.net]: >>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。

コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。
442 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 17:12:05.71 ID:efNbKFVE.net]: 安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない
443 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 17:40:06.82 ID:whw2xWQR.net]: Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね
444 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 17:44:11.14 ID:t0V8WW9J.net]: >>436
インターフェースの問題とJavaの問題を混同するのが論外
445 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 18:05:15.33 ID:K++ItniC.net]: Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな
446 名前：デフォルトの名無しさん [2022/07/22(金) 19:11:51.06 ID:yoEBUVfk.net]: >>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。
447 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 21:06:16.19 ID:UonvlDt9.net]: キモいな
Javaは遺伝子引き継いでないから代理出産に違いない
448 名前：デフォルトの名無しさん [2022/07/22(金) 21:16:25.55 ID:i57cd+Nw.net]: >>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。
449 名前：デフォルトの名無しさん mailto:sage [2022/07/22(金) 21:29:36.07 ID:zWgtMzpY.net]: >>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。
450 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 04:53:27 ID:Yc68YnRu.net]: >>444
意味不明なこと言わないで
451 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 05:40:41.12 ID:xoLMiefm.net]: >>435
C++だけでなくRustも理解できてない？

＠
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる！」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。
452 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 08:37:27.70 ID:0xKT+wLu.net]: >>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない？
453 名前：デフォルトの名無しさん [2022/07/23(土) 09:37:03.85 ID:bR39w9BX.net]: Googleは金の亡者
454 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 11:55:37.32 ID:8Uydd8B4.net]: >>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw
455 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 13:10:56 ID:RBxCW/xN.net]: OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当

Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある

後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い
456 名前：デフォルトの名無しさん [2022/07/23(土) 16:15:20.09 ID:tefRxlpq.net]: >>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける
457 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 18:34:20.81 ID:u2Y0Vizw.net]: >>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。
458 名前：デフォルトの名無しさん [2022/07/23(土) 19:04:05.94 ID:ehQy/P8s.net]: ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
459 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 19:21:14 ID:NE7ljYY1.net]: C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる
460 名前：デフォルトの名無しさん [2022/07/23(土) 19:57:02.71 ID:uphZtYPd.net]: 正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。
461 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 20:43:26.21 ID:PgM2fTTz.net]: >>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは
462 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 21:05:19 ID:IDFlcwhf.net]: >>454
Hoareはホーアかホアだと思うんだが
ホアレはどこの国の読み方？
463 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 21:18:57.29 ID:91gi6HhK.net]: 日本じゃね？
464 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 21:28:49.17 ID:zqWGCIwO.net]: >>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇言語や〇 langでいける
465 名前：デフォルトの名無しさん mailto:sage [2022/07/23(土) 22:37:12.56 ID:SkYdpzS6.net]: >>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない？

ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ
466 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 09:21:08.56 ID:lG8qI40d.net]: >>461
じゃあいつできたの？
467 名前：デフォルトの名無しさん [2022/07/24(日) 09:29:10.51 ID:TkuAh24s.net]: RustじゃなくてHoareの方が検索性は高かったと思う
言語に自分の名前つけたっていいじゃん、最初だけイタい人扱い受けるだけだし
468 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 12:23:10 ID:A2ivE9+A.net]: でも本当にHoareなんて名前付けたら絶対Tony Hoareのほうだと思われるやろな
469 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 12:53:11.52 ID:lG8qI40d.net]: >>464
ほんこれ
あんな有名人とfamily nameが一緒とかすごい偶然だよな
470 名前：デフォルトの名無しさん [2022/07/24(日) 13:06:01.37 ID:hnBeY/7d.net]: 木村拓哉と苗字が同じ木村君みたいな。
471 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 13:06:50.57 ID:iVL8opWs.net]: すごい偶然ですねえ・・・えっ
472 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 13:35:38.58 ID:q7gbemmZ.net]: Rust-Oneとか見たいな感じの名前が良かったんじゃないかとｗ
473 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 13:48:30.68 ID:q7gbemmZ.net]: 新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…

C java go Perl Ruby Rust ...
474 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 13:53:14.16 ID:iVL8opWs.net]: せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
Javalang、Clang、Golang、Rustlang...
clangは名前衝突するから今更ムリだけど
475 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 14:08:13.51 ID:6QULAMze.net]: RustとかGoはもう今じゃメジャーだから大分マシだけど
上の方に出てるCarbon？だのみたいな新しい知名度低いようなのにとっちゃ検索されづらいのって結構大きいデメリットじゃないのかね
476 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 14:11:15.69 ID:q7gbemmZ.net]: Car-bonおすすめ
477 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 17:26:22 ID:AIK5SBoS.net]: Rustでは検索にこまったことないけどなぁ
CやGoではそれなりに困ったことある
特にC
478 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 17:35:43.91 ID:nz/s3YoW.net]: >>469
perlは違うくね
入れるならpython
479 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 18:34:31.10 ID:kd/zxSl1.net]: Pythonはまさかちょっとしたイタズラ心で命名した言語が
30年経ってこれほどまでに普及するとは思ってないだろうなぁ。
480 名前：デフォルトの名無しさん mailto:sage [2022/07/24(日) 20:35:51.30 ID:T5Io3liY.net]: ゲームのRustが人気になっていても問題なく検索できてるなぁ
481 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2022/07/25(月) 09:42:55 ID:OE8E5RfU.net]: パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
個人情報保護の法律との兼ね合いが難しいみたいだが。
482 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 11:46:03.92 ID:fotNOYOj.net]: RustはCやC++の後継にはならないな。
483 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 12:46:43.99 ID:/yXgS7y/.net]: CはC言語で検索してもC++が出てきやがるからな
迷惑な言語だわC++
484 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 14:10:01.30 ID:fotNOYOj.net]: 全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。
485 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 19:30:13.93 ID:qs4kuyp6.net]: >>456
その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる
486 名前：デフォルトの名無しさん [2022/07/25(月) 20:08:08.67 ID:uz33IoOs.net]: goはgolangって呼び方が一般化してるから問題なくね？
親会社もalphabetだし、仮に一般名詞でも検索してやんよっていう自信の現れなのかも。
あとlisp monsterのほうが可愛いよね
487 名前：デフォルトの名無しさん mailto:sage [2022/07/25(月) 21:31:20 ID:o3/zkeTE.net]: langってなに？
488 名前：デフォルトの名無しさん [2022/07/25(月) 21:42:28 ID:GF1rw+EH.net]: ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府
489 名前：はシリア高原と呼称するそうだぞ。 []: [ここ壊れてます]
490 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 07:10:48 ID:4TZ4RWr2.net]: 今ちいかわってキモいキャラが流行ってるように
Gopherくんもいずれ世界的なマスコットキャラクターになるよ
491 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 08:04:10.89 ID:B/e7/0Va.net]: >>484
それはGolan
492 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 08:15:07.77 ID:RlhOzjvN.net]: 今マイコン用クレートでメジャーなのってどのあたり？
自分で作るにあたり参考にしたいのだが
493 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 08:36:59.30 ID:+EhcIf+H.net]: >>487
おれたちが知るわけないだろバカか？
494 名前：デフォルトの名無しさん [2022/07/26(火) 08:37:23.50 ID:jFWmtimM.net]: 言語の名前がGopherだったらよかったのに
495 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 09:10:32.87 ID:gGUkeHRo.net]: プロトコルの方のgopherについて調べる人が困るでしょ
496 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 09:38:10.98 ID:hAg2HYen.net]: プロトコルはイーサリアムとビットコインで実現出来ます
この2種類以外は今後不要になります
497 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 09:42:41.59 ID:xvJteLGG.net]: 😲
498 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 09:57:43.88 ID:khPn0eWd.net]: >>491
草
499 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 11:19:17.05 ID:wEdk200U.net]: Web3なんて流行るわけねーだろ
スマートコントラクトの開発コスト高すぎ＆不便すぎ
500 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 11:50:54.04 ID:m36KkBXx.net]: それに引き換えBorrow Checkerは開発コスト低くて便利だね
501 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 11:55:05.12 ID:xpFZew7X.net]: Rust=Web3 だからWeb3業界の勢いが無くなったら影響受けるよ
502 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 11:59:58.82 ID:EbLORSqB.net]: >>496
意味不明
503 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 12:14:19.05 ID:/Gebh7sM.net]: Etherはイーサーだけど
Ethereumはァセーリアム
日本語読みだと外人に通じないから注意な
504 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 12:46:34 ID:NppJ7uYb.net]: >>487
AVR-HALとかいうやつ使ってる
505 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 14:54:22.29 ID:6ZBHWj0q.net]: ３年以内にMoveが天下取るとか言われてるけど本当かね
506 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 14:58:00.69 ID:m36KkBXx.net]: 本当だから高くなる前にいっぱい買っておけ
507 名前：デフォルトの名無しさん mailto:sage [2022/07/26(火) 21:01:19.60 ID:WAPUil1D.net]: ʕ◔ϖ◔ʔ
508 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 00:16:39.59 ID:Zq3V4Tcb.net]: >>500
Moveってなに？
509 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 01:54:06.44 ID:qGGsA3uX.net]: >>503
最新のブロックチェーン言語も知らない奴はここから消えて
510 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 05:50:23.11 ID:Zq3V4Tcb.net]: >>504
あれLibraってまだ生きてんの？
ぜんぜん音沙汰聞かないけど
511 名前：487 mailto:sage [2022/07/27(水) 07:28:03.29 ID:6+JEeGDS.net]: >>499
ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・
512 名前：デフォルトの名無しさん [2022/07/27(水) 07:32:05.65 ID:6nSf0k+r.net]: >>503
ダイハツの軽自動車
513 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 10:27:27.45 ID:IW7fj0uw.net]: >>505
名前変えた後継含めて公式に死んでる
514 名前：デフォルトの名無しさん mailto:sage [2022/07/27(水) 19:19:33.01 ID:U29fl458.net]: >>505
世界に殺された
もし生まれたら恐ろしいことになってただろうしな
515 名前：デフォルトの名無しさん mailto:sage [2022/07/28(木) 00:38:58 ID:z/Vvst4i.net]: アレはAptosとして生き残った
大型の資金調達を連発して次の投機の標的になってる
516 名前：デフォルトの名無しさん mailto:sage [2022/07/30(土) 22:19:27.63 ID:wZaxY20D.net]: std::io::Result<()>
↑の()ってなんすか？
Ok(());
↑の()も。
「空」を意味してるってことでいいんですか？
517 名前：デフォルトの名無しさん mailto:sage [2022/07/30(土) 22:34:27.43 ID:PnFWbFUc.net]: 5つの何かを返す関数なら
return (a, b, c, d, e);
0つの何かを返す関数なら
return ();
と考えてもよく何も返さないこと
518 名前：デフォルトの名無しさん mailto:sage [2022/07/30(土) 22:39:27.64 ID:xUdiS2xM.net]: https://doc.rust-lang.org/std/primitive.unit.html
519 名前：デフォルトの名無しさん mailto:sage [2022/07/30(土) 22:41:59.23 ID:wZaxY20D.net]: >>512
>>513
どうもありがとう
520 名前：デフォルトの名無しさん mailto:sage [2022/08/01(月) 16:04:37.53 ID:ElZDPbmW.net]: Meta社のバックエンドにRust推奨だってよ。
https://www.publickey1.jp/blog/22/metafacebookrustpythonchack.html
521 名前：デフォルトの名無しさん mailto:sage [2022/08/02(火) 02:20:06.29 ID:M8Mca9lV.net]: bevy 0.8
https://bevyengine.org/news/bevy-0-8/
522 名前：デフォルトの名無しさん [2022/08/02(火) 23:33:57 ID:FkNkpg49.net]: bevyとFyrox Engineはどちらの方が良いのかな
人気度はbevyな気がするが
523 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 02:28:39.18 ID:xaY+36ag.net]: Rustでプラグインシステム組むならwasiが安牌かな
524 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 09:59:47.35 ID:CkQzFtco.net]: プラグインシステムとは
525 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 12:38:32.91 ID:pLEfRi/j.net]: エディタとかツールの機能拡張だよ。
RubyとかJVMとかある程度の動的さを持つランタイムがあると開発楽だけど、GoやRustみたいにスタティックリンク、シングルバイナリが基本になると
たしかにwasmベースで作るのが筋が良いのかねぇ。
526 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 12:57:45 ID:qyv7p4eK.net]: おいおいww
527 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 13:50:49.10 ID:ck4xiQdl.net]: クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
という条件だとLuaかwasm
528 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 13:51:05.48 ID:ck4xiQdl.net]: JSでも良いが
529 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 15:10:31.96 ID:b+TNnTjV.net]: プラグインというよりマクロの実行環境の話だな
Luaやwasmはホストアプリにランタイムを同梱する必要がある
530 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 15:23:41.09 ID:1k9fnhsy.net]: Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
よほどホスト側にプラットフォームとしての魅力がない限りは成立しないよ
ホストがスクリプトに対して提供している機能以上のことはできないわけだからな
そうじゃなくて、やりたいのはホストにない機能を追加できるプラグイン機構じゃないの？
531 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 15:39:46.71 ID:9TNfUmNd.net]: >>520
Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ
532 名前：はちみつ餃子 mailto:sage [2022/08/04(木) 15:55:10.42 ID:hPtMGH66.net]: そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ？
最終的にどういう結論になったのか追ってないんやが……。
必要な機能は Rust コンパイラの中に全部あってシステムの外とやり取りする必要もないから良い案に思える。
533 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 17:17:23 ID:KbhCPu0a.net]: >>525
Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど
534 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 17:19:43 ID:ck4xiQdl.net]: 動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
それなりの量のグルーコードが必要になるかと
その辺良い感じにどうにかしてくれるcrateがあるかもしれないけど
535 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 17:29:05.26 ID:1k9fnhsy.net]: >>528
そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ？
536 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 17:46:52.95 ID:CkQzFtco.net]: https://qiita.com/dalance/items/1593b56ad3744c469643

コメント欄も含めるとなかなか情報がまとまっています
537 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 17:49:06.27 ID:8PPO9uzK.net]: 良さげ記事
538 名前：はちみつ餃子 mailto:sage [2022/08/04(木) 17:58:11.58 ID:hPtMGH66.net]: >>530
ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ？
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)

制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか……
539 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 18:01:34.69 ID:9TNfUmNd.net]: >>529
> 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった
540 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 18:42:08.03 ID:pLEfRi/j.net]: 野良プラグイン入れて環境壊して上等！って時代でもないからねえ。
ある程度、できること制限できるようにしたプラグイン機構も大事な時代よ。

そういう点でwasmがセキュリティとパフォーマンスのバランスが取れていて魅力という層もあるでしょ。
541 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 18:42:45.33 ID:KbhCPu0a.net]: >>530
そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない

「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの？
542 名前：デフォルトの名無しさん mailto:sage [2022/08/06(土) 12:18:12.84 ID:z/fLyAW1.net]: 今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
同様にTauriで作成されたアプリが10年後でも問題なく使用できるのだろうか
543 名前：デフォルトの名無しさん mailto:sage [2022/08/06(土) 20:40:11.73 ID:6gQA87rg.net]: Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Macとかだと突然仕様変えてきそうで怖いな
544 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 00:00:20.59 ID:pGypWfdH.net]: Rustでライブラリをどうやって選定してんの？
crate.io見て人気のを選んでんの？

GETだけのためにhttpclient使おうとしたらtokio入れて使えとか全然意味わからんしコンパイルしたら
これを使うには2018使えと2022使えが出てくる…

他のに変えても変わらず
GETなんてコピペ産業で実現させてくれよ

use
初期化
GET

これで終わらせてくれ
545 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 00:05:00.47 ID:pGypWfdH.net]: 別に

use
GET

の2行でもいい
546 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 00:19:22.87 ID:thO2Aez3.net]: >>539
まあ今はそういう人向けの言語じゃないからね

とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん
547 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 00:27:13.75 ID:pGypWfdH.net]: crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと

どれもtokio使ってるしCurlコマンドみたいに一発でGETやPOSTって感じでもない
tokio必須と言うことは標準でasyncライブラリの完成度が低いんだろうけど
憶測が当たってるかどうかもよくわからない
548 名前：はちみつ餃子 mailto:sage [2022/08/07(日) 00:48:31.33 ID:yGip1YMx.net]: >>542
Rust は標準ライブラリの中に非同期ランタイムを持ってない。
言語として非同期を扱えるようにしつつ具体的な部分は外部のクレートに任せられるように
分離に成功しているという意味では十分に完成度は高いとも言える。
549 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 01:05:02.63 ID:nCVSRdWl.net]: >>539
簡単これだけ

#[async_std::main]
async fn main() {
let uri = "https://httpbin.org/base64/SGVsbG8sIFdvcmxkIQ==";
let s = surf::get(uri).recv_string().await.unwrap();
assert_eq!(s, "Hello, World!");
}

Cargo.tomlの[dependencies]に適当に
async-std = { version = "*", features = ["attributes", ] }
surf = "*"
550 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 05:20:01.36 ID:FgVTxKNL.net]: 簡単に使いたいなら、非同期じゃなくて同期版のhttpクライアントライブラリ使いなよ
551 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 08:15:04.13 ID:PrNdTuny.net]: Goを素直に使っとけ
標準ライブラリでそのままできる上に非同期もGoroutineを使うだけ
テスト用のライブラリも用意されてるからクライアントサーバーもそのままテストできる
552 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 08:22:19.17 ID:nCVSRdWl.net]: >>546
Goなんていうものは不要
Rustで簡単に使える
553 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 08:29:14.86 ID:PrNdTuny.net]: 標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ

>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする
554 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 08:59:18 ID:9InYic2G.net]: >>548
あまりにも狭い視野と酷い誤解をなさっているようだが
ウェブ関係はRustのメリットが十分にある分野で実際にRustで利用が多い分野
555 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 09:24:53.04 ID:OveVhBWN.net]: 複オジ相手にするのは隔離スレか実質隔離スレの次世代スレだけにしろ
556 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 09:37:06.87 ID:VV/7IoC0.net]: >>548はいつものRustアンチのキチガイかな
RustはOSやドライバ用と嘘をついてそれ以外なら他の言語を使うべきと誘導する書き込みがそっくり
557 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 10:46:09.01 ID:W6kFcilw.net]: キチガイ同士ここ以外で仲良くやっとけよ
邪魔なんだよ
558 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 12:14:32.05 ID:46MSroSz.net]: キチガイ隔離スレのココが機能していてなにより
559 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 12:50:43.08 ID:45kFT7pS.net]: 次世代スレの方もﾜｯﾁｮｲ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
あとは過疎を恐れず移行すれば万事解決です
560 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 13:58:05.65 ID:ZjeWku4d.net]: まだ実証されてないってことね
じゃあバスで
561 名前：デフォルトの名無しさん mailto:sage [2022/08/07(日) 14:08:40.83 ID:XsO6imG4.net]: 過疎やん

【ﾜｯﾁｮｲあり】プログラミング言語 Rust
https://mevius.5ch.net/test/read.cgi/tech/1514107621/
562 名前：デフォルトの名無しさん mailto:sage [2022/08/11(木) 07:14:02.75 ID:wbWFySKV.net]: structに不変なフィールドを持たせるにはどうしたらいいのですか？
const定数ではなく、インスタンスごとに初期化時に値を設定したら、その後は変更不可能。
他のフィールドは変更可能でも。
563 名前：はちみつ餃子 mailto:sage [2022/08/11(木) 10:33:56.78 ID:5k4DsUHs.net]: >>557
直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。
564 名前：デフォルトの名無しさん mailto:sage [2022/08/11(木) 11:32:02.59 ID:wbWFySKV.net]: >>558
ありがとうございます。
565 名前：デフォルトの名無しさん [2022/08/13(土) 13:13:02.04 ID:hNN+KHup.net]: >>45-47
https://www.youtube.com/watch?v=k8x2DiNz4iU
566 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>560
言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー
567 名前：デフォルトの名無しさん [2022/08/16(火) 13:03:21.19 ID:RcKGtcJQ.net]: VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
Borrowed pointer typeの参照先の値ってデバッガ上でどうやったら見れるんですか？
568 名前：デフォルトの名無しさん mailto:age [2022/08/18(木) 15:17:30.09 ID:nMYke7rH.net]: 参考までに、mutはドイツ語で勇気の意味です。
569 名前：デフォルトの名無しさん mailto:sage [2022/08/19(金) 15:36:33.17 ID:MNFQes9z.net]: スレチ
570 名前：デフォルトの名無しさん mailto:sage [2022/08/19(金) 15:56:19.49 ID:WZnrgrRN.net]: 今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
Java Script全盛のこの時代にいちいちコンパイルするなんて面倒で仕方ない
571 名前：デフォルトの名無しさん mailto:sage [2022/08/19(金) 17:51:45.38 ID:jOBplE6P.net]: 釣りは隔離スレでどうぞ
572 名前：デフォルトの名無しさん [2022/08/21(日) 14:52:30.50 ID:j3ukytx2.net]: RUST大流行だな
ほんと紛らわしい
573 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの？
574 名前：デフォルトの名無しさん mailto:sage [2022/08/21(日) 21:36:56.87 ID:RCuqOQsW.net]: 確か燃え尽き症候群で自分から離れたんじゃなかったかな
575 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 嘘のようにボロ負けしたんだろうな
576 名前：デフォルトの名無しさん mailto:sage [2022/08/22(月) 12:22:08.49 ID:+Lu+Ewk5.net]: ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
不要だろ。
jsでカーネルのラードンをつくる猛者まで出てきた
577 名前：デフォルトの名無しさん [2022/08/25(木) 01:05:28.98 ID:YZq8nn1p.net]: Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか？
578 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 02:02:11.07 ID:sE5vq5kZ.net]: 範囲はHashMap全体たが
Arc単体で提供するスレッドセーフはimmutableな共有所有のみ
その例だとHashMapは読み取り専用になる
他を要求するなら他と組み合わせる

まずArcは置いといて単独所有の時
整数やブールならAtomicXxxでスレッドセーフ
一般的な型ならMutex<T>
読み取り同時複数ならRwLock<T>
それぞれコストが異なるので使い分ける

その上で共有所有ならArc<.....>をそれらの上に被せる
579 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 02:06:21.10 ID:mMVVZ1qM.net]: T1, T2がSend/Syncな前提だよね？
580 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 21:50:49.35 ID:sE5vq5kZ.net]: もちろんTがSync+Sendの時のみ
Arc<T>はSync+Sendとなる
581 名前：デフォルトの名無しさん mailto:sage [2022/08/25(木) 23:42:19.60 ID:3Alfspxr.net]: 条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
間違えていても安全でなくてもコンパイルが通ってしまい実行時に酷い目に合う従来の言語
582 名前：デフォルトの名無しさん [2022/08/26(金) 03:34:10.56 ID:7ybirmBf.net]: Test
583 名前：デフォルトの名無しさん [2022/08/26(金) 10:06:51.61 ID:i2SIEm4o.net]: >>576
コンパイル通ったら安心と思い込む馬鹿
584 名前：デフォルトの名無しさん mailto:sage [2022/08/26(金) 10:39:24.20 ID:z3bi9+6P.net]: そいつには触れるな
585 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>578
思い込みで誤読しているあんたが馬鹿っぽい
>>576にはそんなこと書かれていない
586 名前：デフォルトの名無しさん mailto:sage [2022/08/27(土) 02:23:31.10 ID:4TEBlXJK.net]: >>578
日本語読めないバカ
587 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>578
うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。
588 名前：デフォルトの名無しさん mailto:sage [2022/08/27(土) 13:37:40.60 ID:VvCUXBS7.net]: デバッグスキル0の奴がビルドだけでOKとか思いたがるんだわ。
589 名前：デフォルトの名無しさん mailto:sage [2022/08/27(土) 14:27:59.40 ID:fe4GQDaF.net]: >>582
その会社ヤバくない？
大丈夫？
590 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 確証バイアスかな？
591 名前：デフォルトの名無しさん mailto:sage [2022/08/27(土) 20:57:03.41 ID:0qPHVCED.net]: >>585
お前ヤバくない？
大丈夫？
592 名前：デフォルトの名無しさん mailto:age [2022/08/31(水) 02:03:15.88 ID:Lk5NPDCj.net]: 最強無敵言語age
593 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 08:04:44.83 ID:+Igep1U8.net]: >>587
入門者相手には最強だよな。
594 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 急に書き込み減ったけどもう飽きられたの？
Scalaのときもそうだったけどエンジニアがこういう読みにくい言語で現場を遊び散らかして負債だけ残すの何とかして欲しいわ
595 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: ?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
せめて検索性に配慮して記号を決めればな。?::くらいにしても問題ないだろうに。
596 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: ピークを過ぎた感はある
Scalaで遊んでたのはDDDとか高レイヤの好きな意識高い系が中心だったからまあそこまで酷い負債にはなってないけど、
その点Rustの負債はタチが悪そうだな
597 名前：デフォルトの名無しさん [[ここ壊れてます] .net]: Amazonがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/

Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
598 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 10:44:22.32 ID:nTGfEW2M.net]: >>590
そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ？
599 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:13:30.34 ID:Fgf/9Zy6.net]: >>590
文法は場当たり的に学ばないで初学者向けドキュメント読んだ方が良いと思うけどそれは置いておいて、
rust operatorでググって出てくるこれ参照して演算子の意味調べてもう一度ググれば良いのでは
それすらめんどくさい？
https://doc.rust-lang.org/book/appendix-02-operators.html
600 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:30:09.46 ID:836P0mbg.net]: question markとかsemicolonで調べればいいんだよ
601 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 12:34:08.26 ID:J/OAC0EF.net]: 例えば
question mark site:doc.rust-lang.org
で検索すれば必要な解説がすぐ見つかる
602 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>593
公式に「チュートリアル」てあったっけ？
THE Book読めということかしらん？

>>594
Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……

>>595
公式の解説出てこないんだけど、公式には説明無いんかね？
603 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>596
おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。
604 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>597
エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい
605 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 13:39:17.87 ID:lcZ+Kyy5.net]: 所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。
606 名前：はちみつ餃子 mailto:sage [2022/08/31(水) 13:42:22.79 ID:nTGfEW2M.net]: >>597
> THE Book読めということかしら

せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。

なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。
607 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 15:08:14.60 ID:Fgf/9Zy6.net]: >>600
所有権チェックをなくすってどういうこと？
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと？
608 名前：デフォルトの名無しさん [2022/08/31(水) 16:15:20.37 ID:bi3oBo/Y.net]: コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理
609 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 16:22:04.68 ID:UXqUoG+N.net]: ビルドしなくてももっと気軽にわかるようにしろってことか？
linterの領域外れてる気もするが
610 名前：はちみつ餃子 mailto:sage [2022/08/31(水) 16:50:31.19 ID:nTGfEW2M.net]: 細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。
611 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 16:56:11.73 ID:LCT5ihCl.net]: 所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
後から直そうとか思うと結局全部作り直すはめになるから
一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね
612 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 17:04:46.18 ID:BdHQqSBt.net]: マンホールって卑猥な単語じゃね？
613 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 19:07:16.13 ID:th8cAM8K.net]: >>592
そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。
614 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 20:09:18.42 ID:iogMBVhq.net]: >>601
the book読めというのはさすがに初心者殺しだと思うけどなぁ。

公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん？
615 名前：デフォルトの名無しさん [2022/08/31(水) 20:22:19.87 ID:3b0JioqE.net]: 学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう
616 名前：はちみつ餃子 mailto:sage [2022/08/31(水) 20:35:16.89 ID:nTGfEW2M.net]: >>609
えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ？
(俺自身は英語あんまりわからんので日本語訳を読んだ。)
617 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 20:38:24.92 ID:SRFkQuBk.net]: >>609
the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている

？は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる

？をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く
618 名前：デフォルトの名無しさん [2022/08/31(水) 20:53:00.34 ID:bW00GV9W.net]: >>605
>>606
同意。
619 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 21:03:24.41 ID:p14sgl1j.net]: すべてがunsafeな世界になる
620 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 21:22:41.70 ID:rT6IO02J.net]: 生きている限り安全なんてない
621 名前：デフォルトの名無しさん mailto:sage [2022/08/31(水) 23:52:36.28 ID:X48LRlQ+.net]: ポエムはいいです
622 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 00:17:11.56 ID:gQhEx8vQ.net]: そうそうポエムいいよなぁ

みつヲ
623 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 01:28:45.35 ID:v92yFclD.net]: 今時、ネイティブ吐く必要なんて全くない
tsでもvscのようなソフトが作れるんだし。
624 名前： ユーザーランドではネイティブはもはや不要だろ []: [ここ壊れてます]
625 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 02:19:44.48 ID:UU16wx/t.net]: もしかしてelectron知らないのかしら
626 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 08:30:45.73 ID:+imQtRK+.net]: スクリプトって知らないのかしらん？
627 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 09:29:49.86 ID:WQm7Gv/J.net]: vscはコア部は全部C++だけど。
そのうえに薄くjs乗ってるだけやがな。
628 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 09:46:54.90 ID:NH2cx+n6.net]: Tauri (Rust) vs. Electron (C++)の戦いの結果…

＞ Electronの代替を目指す軽量なRust製フレームワーク「Tauri」
＞ https://www.publickey1.jp/blog/22/electronrusttauri.html
＞
＞ Electronはフロントエンドの基盤としてChromiumを組み込んでいますが、
＞ Tauriでは代わりに各OSが備えているWebViewの機能を、抽象化レイヤのwry経由で呼び出すことで、
＞クロスプラットフォームを実現しつつChromiumを不要にしています。
＞フレームワーク内にChromiumを組み込まないことでセキュリティも向上すると、Tauri開発チームは説明しています。

　↓　「マジ？！」と思っていたらマジだった！！

＞開発フレームワーク「Electron」に複数の脆弱性
＞https://news.mynavi.jp/techplus/article/20220818-2426640/
＞
＞Electronは、HTML5やCSS、JavaScriptといったWeb技術を用いてデスクトップアプリケーションを開発することができるフレームワークで、
＞Microsoft TeamsやVisual Studio Code（VSCode）、Discordなどの人気アプリケーションでも利用されている。
＞今回のElectronの脆弱性に関する発表は、米国で開催されたサイバーセキュリティカンファレンス「Black Hat USA 2022」の次のセッションで行われたもの。
＞研究チームがElectronを使用して開発された20のアプリケーションを調査し、そこで発見された複数の脆弱性について報告した。
＞発見された脆弱性の一例としては、以下が挙げられている。
＞・VS Codeにおけるリモートコード実行の脆弱性
＞・Discordにおけるリモートコード実行の脆弱性
＞・Microsoft Teamsにおけるクロスサイトスクリプティング脆弱性
＞・ChromeのCSP（Content Security Policy）バイパスの脆弱性
＞・V8のリモートコード実行の脆弱性
629 名前：デフォルトの名無しさん mailto:sage [2022/09/01(木) 12:18:02.95 ID:Wlby5VAy.net]: >>621
そうなん？わりとネイティブが薄くてTSが主体だと思ってた。
630 名前：デフォルトの名無しさん mailto:sage [2022/09/02(金) 12:29:12.76 ID:EMfEx7SW.net]: GUIがtsの時点でお察し
やたらとモッサリしてんじゃん
631 名前：デフォルトの名無しさん mailto:sage [2022/09/02(金) 22:13:08.24 ID:06QeBluE.net]: --emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある？
gas系っぽく見えるけどちょいちょい判らないのが・・・
632 名前：デフォルトの名無しさん mailto:sage [2022/09/02(金) 22:55:35.95 ID:TRifMPKk.net]: --emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ
633 名前：デフォルトの名無しさん mailto:sage [2022/09/04(日) 14:45:48.94 ID:c9grlmUi.net]: VScodeがもっさりは感じたことないな
ネイティブのVSのほうが重すぎ
634 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの？
635 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 15:19:35.29 ID:TAlRHagA.net]: そんなユースケースあるの？
636 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 15:31:51.51 ID:TaR2CBOa.net]: >>629
隔離スレでドヤりたいというユースケース
637 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 15:54:23.38 ID:vyOP5LW0.net]: いつも隔離スレのここが機能してくれて助かってます
638 名前：はちみつ餃子 mailto:sage [2022/09/05(月) 16:16:12.15 ID:QNR7HRCU.net]: >>628
一旦変換すりゃいいだけなんじゃないの。知らんけど。
639 名前：628 mailto:sage [2022/09/05(月) 17:50:42.31 ID:Y4+oTyIj.net]: 例えばこんなの
fn func(x: u8, y: u8) -> u8 {
　let x32 = x as i32;
　let y32 = y as i32;
　let z32 = (((x32 - y32) * 170) >> 16) + y32;
　return z32 as u8;
}
4行使うのは冗長かなーと思わなくもなく・・・
テンポラリ変数の名前を考えるのもちょっと面倒だし
640 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 17:54:10.85 ID:vXwuqGKm.net]: >>633
シャドーイングできるからテンポラリの変数名は不要だよ
let x = x as u32;
でいい
641 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 19:20:47.36 ID:g3RfqaIY.net]: >>633
行数短くしたいだけなら

fn func(x: u8, y: u8) -> u8 {
　let (x, y) = (x as u8, y as u8);
　(((x - y) * 170) >> 16) + y) as u8
}

とは書けるけどやってることは全く同じだしこれで期待に応えられてるかは分からん
642 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 19:21:35.07 ID:g3RfqaIY.net]: >>635
2行目間違えた
as i32 に読み替えて
643 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>633
その例は手動で最適化すると
fn func(_x: u8, y: u8) -> u8 {
　y
}

それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ
644 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: x < y の場合考慮してなさそう
645 名前：デフォルトの名無しさん mailto:sage [2022/09/05(月) 21:53:26.61 ID:wI2HBmBd.net]: ホントだごめん訂正
fn func(x: u8, y: u8) -> u8 {
　y - (x < y) as u8
}
646 名前：デフォルトの名無しさん mailto:sage [2022/09/06(火) 00:31:42.49 ID:EiVnVIDc.net]: 結局u8で返すなら
途中でi32使わずとも
工夫するとu8のままだけで算出できちゃったりするわけか
647 名前：デフォルトの名無しさん mailto:sage [2022/09/06(火) 00:52:56.28 ID:uJFa29+7.net]: 逆方向にシフトした場合は？
そんな用途があるのか知らんけど
648 名前：デフォルトの名無しさん mailto:sage [2022/09/06(火) 01:12:27.41 ID:EiVnVIDc.net]: >>641
それはu8部分の下位8bitが常にゼロとなって
足しても引いても影響ないかな
649 名前：628 mailto:sage [2022/09/06(火) 11:02:40.94 ID:xGSGq1SQ.net]: スタンダードな書き方みたいなのはないのかな
なら>>634で行こうと思います

あと>>633は右シフトを間違えていました
16ではなく8です
650 名前：デフォルトの名無しさん mailto:sage [2022/09/07(水) 08:11:56.26 ID:8saglJYc.net]: Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの？
651 名前：デフォルトの名無しさん mailto:sage [2022/09/07(水) 08:24:04.31 ID:41cUJGIp.net]: もちろん
そして依存しないよう3種類用意されてる
assert_eq!(0x01020304, u32::from_be_bytes([1, 2, 3, 4])); // big endian
assert_eq!(0x04030201, u32::from_le_bytes([1, 2, 3, 4])); // little endian
assert_eq!(XXX, u32::from_ne_bytes([1, 2, 3, 4])); // native endian
652 名前：デフォルトの名無しさん [2022/09/07(水) 23:31:51.68 ID:qqHULq33.net]: native endianというのは初めて聞いたのですが、これはどういうものなのですか？
653 名前：デフォルトの名無しさん [2022/09/07(水) 23:54:21.35 ID:En8I5Kb5.net]: この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと
特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが
そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います
一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います
654 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 00:04:41.95 ID:nmwPOGZ0.net]: >>645
サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう
デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する
みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった
655 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 00:19:17.65 ID:8UoQH6yi.net]: >>648
操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン
だから原則としてネイティブエンディアンのみでプログラミングする
例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換
656 名前：はちみつ餃子 mailto:sage [2022/09/08(木) 00:23:28.76 ID:MG9wnc1h.net]: >>648
内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。
でも普通はそんな煩雑なことをしたくないから
内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、
言語やライブラリも基本的には一般的な構成に倣っている。
657 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 01:11:28.44 ID:U6/gufpm.net]: >>648
変数やフィールドのメモリ上の表現�
658 名前：ｪ特定のエンディアンにしたいのであれば、 #[repr(C)] struct BeU32([u8; 4]); みたいな構造体を用意して impl Be32 { fn get(&self) -> u32 { u32::from_be_bytes(self.0) } fn ser (&mut self, v: u32) { self.0 = v.to_be_bytes(); } } こういうアクセサを実装すれば良いかと 何の役に立つのかはよくわからないけど、特定のエンディアンでシリアライズされたデータにそのままアクセスしたい場合とかに便利なのかな []: [ここ壊れてます]
659 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 01:21:33.97 ID:5HeI/FQK.net]: mansplainers
660 名前：デフォルトの名無しさん [2022/09/08(木) 15:55:57.30 ID:Vswe11EN.net]: RustをOpenMPIに対応させるようなプロジェクトってありますか？
661 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 16:49:24.48 ID:mLv3aAxt.net]: 「Rust OpenMPI」でGoogle検索
662 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 18:02:42.70 ID:U6/gufpm.net]: OpenMP なのか Open MPI なのかどっち
663 名前：デフォルトの名無しさん [2022/09/08(木) 20:45:38.87 ID:Vswe11EN.net]: 知りたいのはOpenMPIの方です
ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・
664 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 20:53:50.25 ID:RwfCQI7B.net]: 一番上のrsmpiは違うの
665 名前：デフォルトの名無しさん mailto:sage [2022/09/08(木) 21:56:17.41 ID:fa0yFdt8.net]: MPIはHPC以外では使う必要ないです
機械学習でも有用だとは思いますが
そもそもフレームワークが対応していないから
全部自前で作ってるような人以外は必要ないです
666 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 01:14:31.51 ID:4b4Wyf25.net]: Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは
667 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 08:12:49.36 ID:auDHI5c1.net]: 良くありがちな奴だと思うけど
struct ARGB32 {A: u8, R: u8, G: u8, B: u8,}
みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの？
これ小文字にしちゃったら少なからず可読性が落ちるよね
668 名前：デフォルトの名無しさん [2022/09/09(金) 08:31:41.27 ID:WeF8ASv0.net]: #[allow(non_snake_case)]
しかしフィールド名だけ小文字にすれば不要
struct ARGB32 {a: u8, r: u8, g: u8, b: u8,}
そして可読性が落ちると思わない
669 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 09:24:21.25 ID:4b4Wyf25.net]: 構造体名もCamelCaseでArgb32とすべきかな
670 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 12:29:38.55 ID:6YdHvwwi.net]: 識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
略語を使わずに書くとこうかね？

Color<T>{alpha: T, red: T, green: T, blue: T}

CMYはどうなるとか言い出すやつがいると面倒そうだけど。
671 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 12:42:45.67 ID:VsTRsG1f.net]: enum Color {
Red,
Blue,
Green,
RGB(u32, u32, u32),
HSV(u32, u32, u32),
HSL(u32, u32, u32),
CMY(u32, u32, u32),
CMYK(u32, u32, u32, u32),
}
672 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 13:41:22.02 ID:4b4Wyf25.net]: 最低限ガイドには従った方が良いと思う
https://rust-lang.github.io/api-guidelines/naming.html
acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき

あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは
規約に従ってないライブラリも多いけど

そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない
673 名前：はちみつ餃子 mailto:sage [2022/09/09(金) 14:02:11.22 ID:gp9Eay33.net]: API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。
674 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 14:15:33.61 ID:+r9uXbjm.net]: >>661
個人的にはこっちの方が好きだけど
規約的にダメなら仕方ない
675 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 14:42:45.26 ID:4b4Wyf25.net]: >>666
非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、
最初から内部も規約に従ったものにしておいた方が良いと思う
そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では
676 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 15:18:27.40 ID:QLGZdL8Z.net]: mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。
677 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 15:35:09.62 ID:7NqN1r1N.net]: gameraとか？
678 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>669
94年初リリースで98年ソース公開で
数年遅れるとは？
679 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 17:53:00.11 ID:rfSAUeXI.net]: CreateFileW in windows::Win32::Storage::FileSystem - Rust
ttps://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Storage/FileSystem/fn.CreateFileW.html
とかAPIガイドラインもクソもないけど名前だけRustに寄せたところでリファレンスドキュメント(MSDN)との差異が
拡大するだけでメリットはほとんど無いような
680 名前：デフォルトの名無しさん mailto:sage [2022/09/09(金) 21:16:36.10 ID:pyHRaXAz.net]: JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる
681 名前：デフォルトの名無しさん [2022/09/09(金) 22:46:34.35 ID:B0h43lqZ.net]: >>673
同意
682 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 00:32:32.71 ID:qBfKxAEz.net]: >>663
その方向でやってみます

というかこの構造体をArrayに沢山詰めようとすると初期化が難しいのか。どうしようか悩んだ結果こうしてみた
#![no_std]
const LEN: u32 = 640*480;
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};
bitmap[0].red = 0xFF;
アセンブラリストを見る限りは問題なさそう
683 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 01:19:16.36 ID:BhJh8aSd.net]: acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな
一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが
684 名前：デフォルトの名無しさん [2022/09/10(土) 03:00:06.93 ID:Rsh0NV07.net]: Ipv4なんて一瞬なんのことか分からんかったな
結局慣れで、一貫性以上に価値のある好みなんてのはない
685 名前：デフォルトの名無しさん [2022/09/10(土) 07:09:44.43 ID:2MfL7Eat.net]: >>676
その一貫性が崩れるのがいやなんだろ。
ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。
慣れの問題だが、今まで/一般的に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。
686 名前：デフォルトの名無しさん [2022/09/10(土) 07:12:21.94 ID:2MfL7Eat.net]: >>676
問題の大小なんて誰も言ってない。
今までの慣れ/一般的な表記を置き換えるのは抵抗感あるって話。
687 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 12:37:11.73 ID:GXRB1/O5.net]: 命名規則を利用する目的は可読性や開発効率の向上などのはず
一般的な表記から外れるのであればそれなりの理由が必要であろう
「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと
突っ込まれてもしょうがない
688 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 13:03:13.98 ID:jQKLnU5m.net]: JavaScriptのアイツは
XmlHttpRequestと命名されるべきだったのか？
XMLHTTPRequestと命名されるべきだったのか？
689 名前：デフォルトの名無しさん [[ここ壊れてます] .net]: eXtend Markup Language Hyper Text Transfer Protocol Request
690 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、
LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから
表記の慣例とか無視して全部キャメルケースにしちゃうな
691 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 13:50:29.86 ID:TnGNUz3W.net]: ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった
692 名前：デフォルトの名無しさん [2022/09/10(土) 14:31:16.93 ID:/uHulLcW.net]: Rustすれのレベルの低さにガッカリ
Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ
693 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 14:56:40.59 ID:qBfKxAEz.net]: >>675みたいに書いた場合
>let mut bitmap:[u32; LEN] = [0; LEN];
のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし
mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている
参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど
なんか上手い書き方はないのだろうか

この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし
どこを見たらいいのか判らない
694 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 15:47:06.47 ID:BhJh8aSd.net]: >>675
ARGB32にDefault実装して
let mut bitmap : [ARGB32; LEN] = Default::default();
とするのが良いかと
repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う
695 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 15:48:16.32 ID:vDnMZIxl.net]: >>675
初期化難しいかな。こうとか

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=49327f78412221161809733ee34bf013
696 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 15:54:53.07 ID:BhJh8aSd.net]: >>687
[T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった
こっちならOK

let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default());
697 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 最後の手段のtransmuteは安易に使うものじゃないと思う
698 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 16:39:14.44 ID:qBfKxAEz.net]: >>687
すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず
repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが

>>688
CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです
原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ
コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの
切り替え方法が判らない)
699 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 18:12:40.24 ID:n3Y/KVD/.net]: >>686
最初に定義した変数bitmapはmoveしてるだけだからmutは余計でいいと思うけど？
700 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 19:24:52.82 ID:qBfKxAEz.net]: >>692
自分の理解があっているか不安なんですが、mutを付けずにletで宣言すると書き換わらない値として
書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です
言語仕様上mutを付けない宣言でも必ず読み書き可能な領域に配置されるというのであればそれでかまわないと思いますが
とりあえず手元のx64向けのコンパイラではmutを付けずともスタックフレームに配置されるようですが
組み込み向けなど他のコンパイラでも同様の動作を前提として問題ないのか判りません

古いバージョンのBookにはスタックやヒープの解説があったようですが
ttp://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/the-stack-and-the-heap.html#:~:text=Memory%20management&text=The%20stack%20is%20very%20fast,explicitly%20allocated%20by%20your%20program
最新版にこのページはないような・・・しかも
>Rust ‘stack allocates’ by default, which means that basic values ‘go on the stack’.
だとRAMを節約したいからROMに配置する実装もあり得ると読めなくもない
701 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: let bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};

これでいいってことじゃない？
一個目のbitmapは実際書き込んでないからmut不要
二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要
702 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: あぁ言いたいことは分かった
確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね
ただそれは別にmutをつけても保証はされない気がする
703 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:24:18.78 ID:BhJh8aSd.net]: >>691
repr(packed)を指定した構造体のフィールドへのアクセスは未定義動作を引き起こす可能性があるからrepr(packed)は基本的には使わない方が良いよ
https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacked

確かにrepr(C)やrepr(Rust)はパディングされる可能性があるけど、フィールドのアラインメントを適切にするために必要なものなので
パディングが問題になるならフィールドのメンバーの順序やサイズを見直すか、フィールドの値を読むのに std::ptr::read_unaligned を使う必要があるよ
https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html

read_unalignedのドキュメントにも書いてあるけど、アライメントが不適切なフィールドへの参照を作るのすら未定義動作になるという落とし穴もあったり、
repr(packed)な構造体の取り扱いにはいろいろと注意が必要になるので、本当に必要なとき以外は使わない方が良いよ

あと、repr(packed)はrepr(packed, Rust)と同じ意味になるので、構造体のフィールドがメモリ上でどのような配置になるかの保証はないよ
フィールドの定義順とメモリ上での順序を同じにしたいのであれば repr(C) または repr(C, packed) と指定する必要があるよ

いずれにせよ今回は全てのフィールドがu8だからrepr(C)でパディングが挿入されることはなく
無駄にメモリを消費することもないよ

どうしてもパディング挿入が心配なら mem::size_ofやmem::align_ofを使って構造体のサイズとアライメントに関するアサーションを加えるのが良いと思う
704 名前：デフォルトの名無しさん mailto:sage [2022/09/10(土) 20:36:28.31 ID:BhJh8aSd.net]: >>693
let a = ...;
let mut a = a;
みたいに書いた場合、一個目のaと二個目のaは別の変数扱いでそれぞれ個別に領域が割り当てられるよ
二個目のaに格納されるのはaの値で、ポインタじゃないから一個目のaが書き込み不可な領域に格納されていたとしても
二個目のaのために割り当てられた読み書き可能な領域に一個目のaの値がコピーされるような動作になるはず
最適化によって一個目のaと二個目のaが同じ領域を使い回すようになるかもしれないけど、二個目のa定義後はその領域に対する書き込みは可能なことが保証されてるはず

transmuteを呼び出した場合も同じで、
transmute(a) という呼び出しをした場合transmuteに渡されるのはaの値なので、二個目のaの定義後は問題なくaに書き込めるはず

ただし、transmuteに&aを渡して&mutに変換するみたいなことをすると未定義動作になるから注意は必要
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
> Mutating immutable data. All data inside a const item is immutable. Moreover, all data reached through a shared reference or data owned by an immutable binding is immutable, unless that data is contained within an UnsafeCell<U>.
705 名前：デフォルトの名無しさん [2022/09/11(日) 12:51:18.94 ID:6axTKkj4.net]: >>693
＞mutを付けずにletで宣言すると書き換わらない値として
＞書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です

しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。
706 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:08:43.20 ID:3JeGkSLy.net]: 今はしないけどそうなるような最適化は禁止されてないのでは
707 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:49:03.04 ID:7UmicIsS.net]: コンパイル時に値が確定してないとtextセクションに書けないでしょ
708 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:55:35.90 ID:VMVpvyTB.net]: そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない
709 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 13:57:25.52 ID:kEOVMHNm.net]: コンパイル時に確定するような式なら最適化でありえるんじゃないの？
710 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 14:07:54.90 ID:VMVpvyTB.net]: どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される

そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう
711 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 14:40:44.81 ID:ujBIW69o.net]: CloneとCopyについて
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<[u32; LEN], [ARGB32; LEN]>(bitmap)};
と
#[derive(Clone, Copy, Default)]
＆
let mut bitmap:[ARGB32; 16] = [ARGB32::default(); LEN];
で読み書きを
bitmap[0].red = 0x80;
let x = bitmap[0].red;
bitmap[0].green = x;
としてみたけど出力された読み書き部分のコードは同じでした。もっとでかい構造体じゃないとムーブかコピーかの区別は出来ないのかな

>>696
マジか。Rustでもパディングの問題がつきまとうのか。でも
>Accessing unaligned fields directly with e.g. packed.unaligned is safe however.
って事は.redとかでアクセスする場合はコンパイラが良きに計らってくれるのでアクセス境界の問題は起きないって事かな？
画像データのバイトやビットの並びなんてすでに決まっていてプログラムはそれに合わせるしかないのが普通でしょうし
勝手にパディングされても困ります

実は並行してCでも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると
データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます
712 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 14:49:25.24 ID:FOB38Q8d.net]: そのような実装はしたくないわけですか
713 名前：デフォルトの名無しさん [2022/09/11(日) 15:13:19.03 ID:/O1tQPyF.net]: どの言語でも同じ
Rustでも&mutでtransmuteしてもendian依存は避けられないな
let mut x = 0x01020304_u32;
let a = unsafe { std::mem::transmute::<&mut u32, &mut [u8; 4]>(&mut x) };
a[1] = 7;
assert_eq!(x, 0x01020704);
とlittle endianでは7の位置はこうなる
714 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 18:54:24.82 ID:gEyGQ7vE.net]: このスレでよく出てくる μt ってなんなん？
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの？
715 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 20:25:15.55 ID:FOB38Q8d.net]: 自分も思ったけどブラウザによっては & mut がそうなるみたい
716 名前：デフォルトの名無しさん [2022/09/11(日) 20:27:57.44 ID:QYXgEc7E.net]: >>708
そうなんだ。
717 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 20:45:42.63 ID:hnVgjqVb.net]: >>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。
718 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:25:51.88 ID:zZ32ojSE.net]: HTMLの文字参照で& muがμ
719 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:45:56.06 ID:ujBIW69o.net]: 例えば
pixel.alpha = in[0].alpha;
pixel.red = in[0].red / 2;
pixel.green = in[0].green / 2;
pixel.blue = in[0].blue / 2;
out[0] = pixel;
と
red = 0xFF & (in[0] >> 16);
green = 0xFF & (in[0] >> 8);
blue = 0xFF & in[0];
red /= 2;
green /= 2;
blue /= 2;
pixel = 0xFF000000 & in[0];
pixel |= red << 16;
pixel |= green << 8;
pixel |= blue;
out[0] = pixel;
ではだいぶ見やすさが違うような
720 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:47:41.04 ID:3JeGkSLy.net]: >>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする

今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね
721 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 21:50:14.96 ID:3JeGkSLy.net]: >>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは
722 名前：デフォルトの名無しさん mailto:sage [2022/09/11(日) 23:45:21.14 ID:ujBIW69o.net]: Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし

>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし

>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開＆最適化されますかね？一つでもコールやブランチが残ったら速度が結構落ちるだろうし
723 名前：デフォルトの名無しさん [2022/09/11(日) 23:59:30.49 ID:/O1tQPyF.net]: >>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい
724 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 00:37:31.19 ID:5hhAOS+Q.net]: &mut テスト
725 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 01:00:12.66 ID:JkhjRZ+U.net]: >>716
ほー、chmateはワザとunescapeしてるのか？
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな
726 名前：デフォルトの名無しさん [2022/09/12(月) 01:13:39.26 ID:D0TZxDhn.net]: HTML等の文字参照を処理する場合でも
μt (＝ & m u ; t )が μt となるのは正しいけど
&mut (＝ & m u t )が μt となるの間違いだからこれはバグと思われる
727 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 02:30:39.40 ID:JkhjRZ+U.net]: あ、たしかにバグっぽい・・・
728 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う
729 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 07:14:45.53 ID:tyJETXG8.net]: これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです
730 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 07:33:21.32 ID:o/NFQNbK.net]: &mut と書けば良いかな
テスト → &mut
731 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 07:34:32.06 ID:o/NFQNbK.net]: & amp ; amp; を空白なしで書き込んだら & に変換されてしまった
実体参照複数回展開しているのかな
&
732 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 08:15:16.27 ID:NGx/fsjU.net]: ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です
最適化レベルによる変化とか全然確認出来ないし
733 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 08:36:58.55 ID:tyJETXG8.net]: ちょっと意味がわからない
こうなるはずだから困ることはないと思うけど

・最適化によってRustが定めている意味が変わることはない
・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない
・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える
734 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 10:25:58.86 ID:o/NFQNbK.net]: genericな関数だと呼び出し元がないとコード生成されないとか？
735 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 12:04:36.56 ID:tyJETXG8.net]: その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ
736 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 12:46:09.29 ID:SjJDv8F6.net]: >>726
ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる
pub extern "C"でRust外の入出力にしてようやく消えなくなる
もうちょっと調べてみる
737 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 14:30:52.03 ID:o/NFQNbK.net]: >>729
ちなみにターゲットはbinと(r)libのどっち？
binならpubでも消えるかも
738 名前：デフォルトの名無しさん mailto:sage [2022/09/12(月) 19:11:31.91 ID:2zIjStdY.net]: >>730
変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ
とりあえずrlibにしておいてある程度形になってきたら変更すればいいか
コード自体はどっちでも大差ないだろうし
739 名前：デフォルトの名無しさん mailto:sage [2022/09/18(日) 01:08:32.32 ID:g4sMxKuf.net]: [u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど
740 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 02:33:25.46 ID:HMAR4dxa.net]: Tauriで動画プレーヤー的なのを作るサンプルってどっかにある？
ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい
あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい
741 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 07:48:35.44 ID:BbpMxDy4.net]: TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ？
そして既存のWeb技術を活かせるのがTauriの利点だろ？
そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか？
Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ？
742 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 12:27:41.81 ID:HMAR4dxa.net]: >>734
>HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中

ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか？なんか無駄に実装量が増えるけど
743 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 13:11:44.57 ID:PTk7Q+2G.net]: その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない？
744 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:38:49.00 ID:EybjBREq.net]: なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう
745 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:45:15.20 ID:npVSxydm.net]: 実装を追加させない方法ってありますか？
別個に渡されたふたつの型が同じであるという制約を付けたいという目的で
以下のようなトレイト Same を定義した場合、実装を追加できてしまうと破綻してしまうので、
なんらかの方法で制限できるだろうかという疑問です。

pub trait Same<T> {}
impl<T> Same<T> for T {}

// 使用例
pub fn foo<T, U>(x: T, y: U)
where
T: Same<U>,
{
}

ちなみに目的を上述しましたけども実際には目的というよりは題材です。
つまり具体的な用途は考えておらず、質問はあくまでも「実装させない方法があるかどうか」です。
746 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: trait Sealed {}
pub trait Same<T>: Sealed {}
747 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:19:03.69 ID:EybjBREq.net]: https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed
748 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:29:04.18 ID:Elo9mBmF.net]: ふたつの型が同じという制約を付けたいなら
TとUじゃなくTとTにすればいいじゃんか
749 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:34:13.52 ID:jWPeXdq1.net]: >>738
達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。

enum Same{SameA(型A),SameB(型B)}

みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。
750 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 22:48:26.11 ID:npVSxydm.net]: >>739-740
実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。
しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。
この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。

>>741
そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。
Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、
説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。

いわゆるXY問題というものの存在は承知しておりますので
解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。
わかりますが、大元の問題というものはありません。
この範囲で完結するパズルだと思ってください。
751 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:14:22.92 ID:nBuFqijL.net]: 2つの矛盾してる要求を同時に実現は無理だわな
752 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:42:08.53 ID:FykVNAq+.net]: impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ
753 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:43:28.04 ID:FykVNAq+.net]: fundamentalな型に一通り実装しておけば良さそう
754 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:48:25.82 ID:FykVNAq+.net]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=02e7851289dd00c9ffc8679ad68644d9
755 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 00:50:06.23 ID:FykVNAq+.net]: fundamental云々はcoherent ruleの話でconflictとは関係なかったわ
756 名前：738 mailto:sage [2022/09/20(火) 01:17:29.77 ID:w2qVrruo.net]: なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
&T とか &mut T とかも先に実装しておけば追加の余地をなくせると。
&T とか &mut T とか以外にどういうのがありえますかね？
757 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 01:40:45.09 ID:lHbnVGdk.net]: >>743
Sealedも<T>にすればいいんじゃないの
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dadd7e289ec4e5bb9746015ac093a9bc
758 名前：738 mailto:sa []: [ここ壊れてます]
759 名前：ge mailto:2022/09/20(火) 01:53:09.66 ID:w2qVrruo.net [ >>750 ありがとうございます。 言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。 ]: [ここ壊れてます]
760 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 18:26:27.74 ID:p9SiwD2d.net]: 「Linux」、バージョン6.1でRustを導入へ--トーバルス氏が明言
https://japan.zdnet.com/article/35193491/
761 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 20:25:26.21 ID:ckEqOjly.net]: >>752
いいね
ここ最近で一番いい知らせだわ
762 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 20:46:56.46 ID:Di+jgu/u.net]: 今のところデバドラだけという話だけど
基幹部分の新実装をRustで作りましたという
人が絶対現れるからそのときどうなるだろ
763 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 20:51:48.09 ID:rUHkgvjw.net]: 誰もvoldemort typeの名を呼ぼうとしない
764 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど
Visual StudioでもRustが最初からパッケージングされてるようになるのかな
765 名前：デフォルトの名無しさん mailto:sage [2022/09/22(木) 09:05:24.01 ID:e5bGjsaE.net]: https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に
766 名前：デフォルトの名無しさん mailto:sage [2022/09/22(木) 13:36:58.59 ID:V4zanZlp.net]: >>756
MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない?
いまさらVSに対応言語を追加する気はないでしょ
どう考えてもWindowsユーザーは少ないだろうし
767 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>756
マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。
インサイドWindowsにはお世話になったわ。
768 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 05:18:56.24 ID:I8UIrhRk.net]: Iteratorに対するIntoIteratorのように
Futureに対するIntoFutureということか
しかも.awaitに対して自動適用だからもっと効果が大きいか
非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる
769 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 08:24:08.00 ID:G8O+P73a.net]: Rust analyzerが優秀過ぎてMSが入る余地なさそう
PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう
VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな
770 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 08:29:43.60 ID:exFn1ITS.net]: Rustからから.Net?
意味ないやろ...
771 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 10:08:58.99 ID:QyFSmn0+.net]: 既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとな
772 名前：る可能性もあるので意味はある []: [ここ壊れてます]
773 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: Rust/Cliとか余計なもの作られそう
774 名前：デフォルトの名無しさん [2022/09/23(金) 12:31:56.94 ID:aakQSAhx.net]: >>758
VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな
775 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 17:48:32.43 ID:z6wpDrU6.net]: >>762
書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった

GoのCGoみたいな仕様だったら色んな意味で面白いと思う
776 名前：デフォルトの名無しさん [2022/09/23(金) 18:02:01.54 ID:bhLcJIv7.net]: rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか？
編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです
Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます
777 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 18:02:58.63 ID:exFn1ITS.net]: >>766
ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな
778 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 18:04:41.93 ID:nucVVsrt.net]: >>767
まあ普通はGitを使うからね
779 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 18:05:33.15 ID:5/jqA4bf.net]: C#も.Netも全く興味ないので知らないが
PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている
既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている
780 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:26:00.89 ID:Oi43IjEf.net]: repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ
781 名前：デフォルトの名無しさん [2022/09/23(金) 21:26:44.38 ID:bhLcJIv7.net]: >>769
でも、破棄ならコミット後の状態にも戻せるぜ？
782 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:42:44.57 ID:KYVSlV2v.net]: >>771
ABI安定化するまではFFIでextern "C"は避けられないよ
783 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 21:53:19.36 ID:wlVyCNVq.net]: >>773
そんなことすべきでない
自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト
外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい
784 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 23:40:33.31 ID:EyovOcQI.net]: 双方でマーシャル/アンマーシャルが必要になって無駄だよね
785 名前：デフォルトの名無しさん [2022/09/23(金) 23:55:09.24 ID:9eaiNZZz.net]: なるほど
786 名前：デフォルトの名無しさん mailto:sage [2022/09/23(金) 23:58:10.15 ID:SxK8BSHj.net]: 対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない
787 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:06:07.91 ID:j2XeJCoN.net]: やっぱエアプの複オジはわかってないなぁ
788 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:11:50.36 ID:DaB/WDgt.net]: >>774
pubなitemのABIに最適化関係ある？
なんかと混同してない？
789 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 00:14:18.76 ID:DaB/WDgt.net]: もしかして repr(Rust) のこと言ってる？
790 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 03:05:40.90 ID:ugWjDAH5.net]: Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう
結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう
791 名前：デフォルトの名無しさん [2022/09/24(土) 08:50:49.84 ID:pfcr5AFZ.net]: C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？
792 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 09:11:44.18 ID:DaB/WDgt.net]: >>781
dylibの場合pubは大いに関係あるよ
793 名前：デフォルトの名無しさん [2022/09/24(土) 09:15:16.80 ID:WR9fIR0K.net]: ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ
794 名前：デフォルトの名無しさん [2022/09/24(土) 09:26:53.29 ID:rPP8Qygy.net]: >>782
名前をプログラマが決められるからだよ
795 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 09:44:37.12 ID:BCuennz9.net]: >>782
むしろCは決まってるの？
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな
796 名前：はちみつ餃子 mailto:sage [2022/09/24(土) 10:38:04.73 ID:2HWwrIyG.net]: 近年になって作られた高速リンカ mold の作者の話でも、
文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。

C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし
どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、
結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が
解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。
797 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 11:00:33.46 ID:DaB/WDgt.net]: CはCPUベンダーが呼び出し規約を文書化してるよ
moldの話はELFやリンクに関連する話では
確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う
798 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 11:33:36.58 ID:FWSMvJVe.net]: AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？

>>786
呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ
799 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 13:14:15.81 ID:DaB/WDgt.net]: >>789
そこでいう実装依存ってプラットフォームごとの差違のこと？
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？
800 名前：デフォルトの名無しさん [2022/09/24(土) 14:25:21.27 ID:PoJJisuz.net]: cdeclとかstdcallみたいなやつ？
801 名前：はちみつ餃子 mailto:sage [2022/09/24(土) 16:06:51.67 ID:2HWwrIyG.net]: >>791
その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。
802 名前：デフォルトの名無しさん [2022/09/24(土) 16:24:43.84 ID:PoJJisuz.net]: >>792
コンパイラがリンカに渡す情報って統一規格があるの？
803 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 17:05:25.99 ID:7d8zqodE.net]: >>793
別に統一されちゃいないがELFとかPEとか
804 名前：デフォルトの名無しさん [2022/09/24(土) 17:10:20.79 ID:GMpouZpq.net]: じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？
805 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [[ここ壊れてます] .net]: >>795
ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。
806 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 19:08:36.35 ID:eDCmZTMq.net]: ARMの規約
https://github.com/ARM-software/abi-aa
807 名前：デフォルトの名無しさん mailto:sage [2022/09/24(土) 22:13:22.85 ID:DaB/WDgt.net]: 元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
LLVMがよしなにやってくれるのでは
808 名前：デフォルトの名無しさん [2022/09/24(土) 22:29:32.09 ID:GMpouZpq.net]: ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね？
809 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 08:24:33.85 ID:j3K9KjV7.net]: Option<NoneZeroUsize>などを使えば
IDやカウンタなどの用途でOption<usize>などを使っていたものを
半分のメモリサイズで済むようになるの？
810 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 11:42:14.43 ID:sQFmQmse.net]: >>799
任せてください。符号ビット省略しておきますね
811 名前：デフォルトの名無しさん [2022/09/25(日) 15:32:52.52 ID:F2Viqk5M.net]: Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない
812 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:24:00.83 ID:xalR35FT.net]: Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに
Microsoftはダメなの？
813 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:34:47.30 ID:4B3i10Bx.net]: try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ
814 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 17:57:47.12 ID:6lgwXJxi.net]: 言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは
815 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:09:02.84 ID:6wI0gbs/.net]: 正直LinuxにRustなんて辞めればいいのに・・・
816 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:14:08.03 ID:Td47G6We.net]: Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの
作り方の解説とかどっかにある？例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定
関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし
パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる
さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし
817 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 18:21:16.44 ID:xalR35FT.net]: テストがすごいのはSQLite
818 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>803
別に独自拡張とか入れてないだろ
コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし
Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない
819 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 19:57:21.62 ID:6lgwXJxi.net]: >>806
なんかまずいことでもあるの？
820 名前：デフォルトの名無しさん [2022/09/25(日) 19:59:47.96 ID:Rxhh3DJ9.net]: >>810
迷走と凋落、そして黒歴史化。
821 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:07:26.82 ID:58piYD8Z.net]: >>807
メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし
できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない
822 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:26:59.51 ID:Td47G6We.net]: >>812
条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした
関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい
で、テストを作ろうとしたけどどうしようか悩み中
823 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 20:37:27.14 ID:lhW/fB5K.net]: そういうのは呼び出し側の単体でええんちゃうの
824 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:09:49.29 ID:j1+dHWho.net]: >>807
歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。
対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。

歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。
825 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:31:04.61 ID:Td47G6We.net]: >>814
中間コンポーネントの単体テストって普通どうやるんだろ
後段のコンポーネントを切り離してテストするのか？繋げたままテストするのか？
切り離せるようにするとその部分にバグが入り込む余地が生まれるし

>>815
歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため
△△のような実装がベターだみたいなのが沢山あるからねぇ
そしてこの手の情報はググっても網羅するのが難しい
826 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:51:09.44 ID:6lgwXJxi.net]: >>811
Linux側にメリットがないと言ってる？
827 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:51:47.84 ID:PDKGWlWe.net]: >>816
> 中間コンポーネントの単体テストって普通どうやるんだろ
中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする
たいていのテストツールではモックの呼び出し回数のテストができる
828 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 21:53:52.45 ID:j1+dHWho.net]: >>816
JavaみたいにDIが発展しているタイプの言語だと中間コンポーネント�
829 名前：ｪ呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。 けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。 モジュール設計の考え方が変わるからかな？ []: [ここ壊れてます]
830 名前：デフォルトの名無しさん mailto:sage [2022/09/25(日) 22:41:02.05 ID:Td47G6We.net]: 今作っているのだとこんな感じかな？
関数C(データの前処理、処理単位への分割)
↓
関数B(処理全体の制御)→関数A'(処理1-2)
↓
関数A(処理1-1)

>>818,819
その場合モックへ切り替える機構はどうするんだろ
そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある

てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな
なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか
831 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 00:07:36.94 ID:h/WE7ZWH.net]: >>820
すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ
C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね
832 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 00:33:03.55 ID:TCGzsvbI.net]: mockall使うとか
833 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 06:28:19.26 ID:p/pWEmYs.net]: cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの？
834 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 06:47:39.41 ID:h/WE7ZWH.net]: >>823
>>820 > その場合モックへ切り替える機構はどうするんだろ
に答えてやってくれ
835 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:21:24.42 ID:kI3cAlPQ.net]: モックやスタブは別モジュール化しておいて
mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの？
836 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:31:47.69 ID:V9yeC/LF.net]: あと#[cfg(test)]でそれをuse
そして#[cfg(not(test))]で本物use
837 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:31:51.25 ID:i/jndsoD.net]: 他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな
説明が面倒だ
838 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 19:38:20.09 ID:V9yeC/LF.net]: >>827
テスト以外の開発の話でも
フレームワークに依存してやってる人は
単純なこと含めて本質的なことを理解してない人が多く
フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける
839 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 21:10:39.16 ID:qW/k82Qg.net]: cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ
何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか
Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ
という思想の言語だと思っているんだが違うのかな
840 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 21:41:35.64 ID:w5YNQb64.net]: >>829
#ifは使わないし
cfg(test)はテスト分離のため必須でしょ
どんな環境でも魔法は無いよ
841 名前：デフォルトの名無しさん mailto:sage [2022/09/26(月) 23:33:07.51 ID:h/WE7ZWH.net]: >>829
cfg使わないで済むいい方法があるなら書いてよ...
842 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 01:17:35.37 ID:OwORQ6vn.net]: mod tests に cfg(test) は必要だとして
依存性の注入にはtrait使えって事なのでは
843 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 07:51:04.95 ID:f9SEu4pT.net]: traitで置き換え可能にするのが面倒というのはありそうだな。
844 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 08:15:53.87 ID:SBVoZTui.net]: AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな
845 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 11:05:22.42 ID:OwORQ6vn.net]: size_tが64bitだからでは
846 名前：はちみつ餃子 mailto:sage [2022/09/27(火) 12:28:55.13 ID:ozjafOA0.net]: >>834
usize はポインタのサイズということになっている。
847 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>831
単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる
C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前
そうしないとそもそも単体テストにならないじゃん

わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ
そういうことができるようにあらかじめコード設計しておかないといけないがな
考えてなかったならリファクタが必要
848 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 19:48:22.41 ID:J8MleXan.net]: そんなフワフワした説明されても...
849 名前：デフォルトの名無しさん mailto:sage [2022/09/27(火) 19:51:56.44 ID:AWnlNGZp.net]: 本物と異なり決まった値を返す送信元スタブと
本物と異なりassertだけする送信先モックを
mod testsの中では本物の代わりにuseするだけだよね
入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね
850 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 00:44:24.76 ID:JQpGo85s.net]: >>839
useしたモックをどうやって注入すんの
関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、
genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは

それともmod testsの外もcfgで置き換えると言っている？
851 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 00:48:00.37 ID:JQpGo85s.net]: 要は
use imp::Foo;
fn target(foo: Foo) {}
がテスト対象だとして
mod tests {
use mock::Foo;
#[test]
fn test() {
target(Foo::new());
}
}
してもコンパイル通らないよね
targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では
852 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 07:20:15.72 ID:1i04Jlqk.net]: traitが無い言語では無理ってこと？？
853 名前：デフォルトの名無しさん mailto:sage [2022/09/28(水) 11:35:17.56 ID:RLf9Yg7w.net]: >>842
他の言語は他のやり方でやってるだけだろ
854 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 01:43:05.00 ID:xXycU9Ev.net]: u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で
せっかくだから u32 に変換可能な型は受け入れようと考えてこんなコードを書きました。
しかしエラーになります。

struct Code(u32);

impl<T: Into<u32>> From<T> for Code {
fn from(x: T) -> Self {
Code(x.into())
}
}

impl From<Code> for u32 {
fn from(Code(x): Code) -> Self {
x
}
}

結果的に自分自身への変換を許すことになってしまうのが既存 (標準ライブラリ)
の定義と衝突しているという理屈は理解しているのですが、
問題を解消するためにこの定義が受け入れる範囲から自分自身 (Code) は除外するように
うまく制約を付ける方法は思いつきません。

そもそもこんなところで勝手に変換するのがよくない作法だとかそういうのは脇に置いて
「自分自身だけ除外するような制約」を上手いこと表現できませんかね？
855 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:16:48.63 ID:zId7dOnm.net]: 無い
856 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:20:01.39 ID:7xp1eqla.net]: そっかー
857 名前：デフォルトの名無しさん mailto:sage [2022/09/29(木) 02:40:21.97 ID:U5dWXlr2.net]: そういうのはIntoCodeみたいな感じで別トレイトにすることが多い気がする
https://docs.rs/axum/latest/axum/response/trait.IntoResponse.html
858 名前：デフォルトの名無しさん [2022/09/30(金) 02:17:04.59 ID:Yj/X+hjS.net]: 初歩的なことですまんけどさ
メソッド内で↓みたいなのってよく見るけど、こう言うのってself.asdfのまま使用するのに比べてどういった利点があるの？
let asdf = self.asdf;
859 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 10:23:40.27 ID:1sTGpNyR.net]: 名前を短くする目的が99パー
860 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 11:00:13.39 ID:tNhbOFxw.net]: クロージャーで構造体のフィールドにアクセスすると構造体ごとムーブしちゃうんでそれ対策じゃないかな
2021で対策されたからどんどん減ってくだろうけど
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ebea0bd9611104e7a90eb8dfcb9899c9
861 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 12:43:57.87 ID:NYKsqXq4.net]: 書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある

let Foo { foo, bar. baz } = self;
としておくと後続の処理で使わないフィールドがあったときにコンパイラが警告してくれる
構造体に新たにフィールド追加した場合も分割代入の箇所でコンパイルエラーになるので修正必要箇所を洗い出すことができる
862 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 13:52:13.77 ID:yzoXDHK/.net]: >>851
なんかすごくモヤモヤする
863 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:15:24.65 ID:oHn8O8ll.net]: 本人は俺ってスゲー、天才やん！
って思ってるんだろうけど後でコード見たらなんでこんなイミフなことしてるんだ？バカじゃねーの
ってなるパターンかと
まあこういう工夫をすること自体は悪くない
864 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:42:00.50 ID:M1og6e+j.net]: フィールドそれぞれに処理をするシチュエーションがわからない
865 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:50:06.85 ID:temvUu5a.net]: >>851
俺もそのdestructuring assignment自体は使いまくる
しかし目的が漏れチェックとは違うのでこうだな
let Self { foo, bar, .. } = self;
866 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 14:55:47.39 ID:t/wNXSJY.net]: >>851
これいいな
867 名前：デフォルトの名無しさん [2022/09/30(金) 15:59:33.74 ID:XmkFmofe.net]: こうやって自己満足の意味不明なコードが量産されていく
868 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 16:19:08.34 ID:GH/ZHf2N.net]: 全フィールド舐めるのが重要な処理ってシリアライズとかだろうか
そんな小手先のテクニックとかじゃなくてproc_macro組んだ方がいいと思う

シリアライズしたいだけならserde使って#[derive(Serialize)]
これも結局proc_macroだわな
869 名前：デフォルトの名無しさん mailto:sage [2022/09/30(金) 17:36:27.38 ID:NYKsqXq4.net]: コマンドライン引数や設定ファイルの定義をclap::Argやserde::Deserializeで宣言的にやって、
それらを処理するところで分割代入してローカル変数にして処理してる
人間が意識的に気をつける必要がある箇所を極力減らしたい気持ちでやっている

好き嫌いあるかも知れないけど趣味プロダクトだしコーディングの意図をコメントに残してるから許せ
870 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 02:29:47.97 ID:hYwRxeDD.net]: >>844
impl<T: Into<u32>> From<T> for Code {}の定義はFromの反射性と衝突するから間違ってる。
Into<u32>を受け付けたいなら関数のパラメタの型をT: Into<u32> or impl Into<u32>にすればいい。
まあ、実装上の規約として必要なんで内部ではtrait IntoFooはパターンとして使われるけど外に漏らすようなものでもない。
871 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 02:38:45.63 ID:6voBA5Ft.net]: &(T, U)と(&T, &U)って等価ですか？
872 名前：デフォルトの名無しさん mailto:sage [2022/10/01(土) 05:47:36.69 ID:6w1pI6Co.net]: 等価ではありません
873 名前：デフォルトの名無しさん [[ここ壊れてます] .net]: アドレスを考えれば明白に別物
一方で
let t = (123, "abc");
let (x, y) = &t;
と自動マッチングしてくれて
&t の型は &(i32, &str)
x の型は &i32
y の型は &&str
となる
つまり&(T, U)が(&T, &U)に分割代入される
874 名前：デフォルトの名無しさん mailto:sage [2022/10/02(日) 10:11:02.15 ID:vdaryILR.net]: test
875 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 22:39:32.97 ID:zgM1XF6F.net]: amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど
r14、r15よりr13を空けておく理由がなにかあるのかな
876 名前：デフォルトの名無しさん mailto:sage [2022/10/03(月) 23:46:41.15 ID:cMmfYMlm.net]: >>865
そんな不吉なレジスタなんか使うな！
877 名前：デフォルトの名無しさん [2022/10/04(火) 00:38:55.95 ID:1GTeu6AF.net]: うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか
伝わりにくいかもしれませんけど
878 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 00:52:50.22 ID:4fgdKnMe.net]: そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは！
879 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと
880 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: Rustはデータ構造を最初に設計しないといけないというのはあるな
C++でもちゃんとそういうやり方が出来てるなら素直に移行できるだろうけど
雑にポインタ持ち回ったり実装の都合でアドホックに相互参照入れちゃったりする人には厳しいだろう
881 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 08:55:50.45 ID:fDq9dWrD.net]: C系は良くも悪くも動いてしまうんよな
そんで知らぬ間に副作用まみれになっている
882 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 09:10:45.14 ID:9SKodj4D.net]: >>867
慣れの問題も大きいのでは
883 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 09:22:15.67 ID:P4nmisNi.net]: 雑に始めてから整理していくスタイルなら C++ のほうがやりやすいというのは理解できる。
でも雑に始めたら整理する機会などないのが現実。
884 名前：デフォルトの名無しさん [2022/10/04(火) 09:24:31.25 ID:BONyu2jp.net]: >>867 ですが、
部分から始められるというのは、部分的な学習からということです
ここまで学習すればここまではできるとか
rustでは最初のプログラムを作るにもたくさんのことを知らなければならないというか
Haskellをかじったことがあり、とても興味深いのですが
わかりにくい独り言に、レスをくださってありがとうございました
885 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 09:48:05.73 ID:P4nmisNi.net]: >>874
> 部分的な学習から

できない。
部分的に学習して何かができたように見えても必ず間違ったものを書いているのが C++ というもの。
学習を進めていくにつれて間違っていたことに何度も気づくのでうんざりした経験があるだろ？
886 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 10:23:23.92 ID:5od2FDFX.net]: 部分的な学習ってのは
C with classes -> STL -> move
みたいな感じじゃない？
他人のコード読むなら全部必要だけど、独習してる分には最初テンプレートとかなくてもいけるでしょ
887 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 12:43:12.54 ID:7zYgBA5I.net]: >>875 >>876
横からだけど、「部分的な学習」はもっと手前のところ。初心者でも
空のコード->リテラル->関数呼出->ライブラリ使用->変数定義・使用
あたりで使い方が広がるんだけど、Rustは関数呼出-変数あたりに概念のデカイ塊がある。

このあたりをまとめて覚えないと機能するプログラムを組めないので、学習者には辛い状態が続く。
Rustはc++以上に挫折しやすいと思う。
888 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 12:54:59.39 ID:zVqHX6VA.net]: 借用と実体(所有権)を常に意識しなきなならんからね
Cだと全部ポインタ使うから意識しないんだけどね
889 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:01:26.34 ID:NJ6V6LdV.net]: どんなプログラミング言語でもいいから何か言語を学習済みの人にとって
他の言語を学習するのは部分的に段階的にすることが可能だよ
もちろんRustでも同じで初心者向けの学習本
The Rust Programming Language
https://doc.rust-jp.rs/book-ja/
を順番に少しずつ進めれば部分的に段階的に学習できるよ
890 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:14:23.44 ID:fXb8hG+g.net]: >>877
段階を経ず一気に進める無謀なことをする人だけが挫折するかもしれないが無謀なその人が悪い

>>878
いきなりそこまで進める人は単なる無謀者
まずは他の言語と同じ使い方
・実体のコピー
・参照（＝借用）
のみ使っている限り所有権なんて知らなくてよい
参照を戻り値としない限りライフタイムも知る必要ない
まずは部分的な学習をすればいい
その後で所有権とライフタイムを学べばよい
891 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 13:25:41.11 ID:P4nmisNi.net]: >>877
> 関数呼出-変数あたりに概念のデカイ塊がある

C++ にもある。
あるのに中途半端な状態で間違った使い方が出来てしまうのが問題の根源。
まともに機能していないことに気づかずに
機能するプログラムを作れていると誤解して後になって結局は行き詰る。

>> 878
意識する必要はある。
コンパイラが検証してくれないのだからむしろ C のほうが強く意識する。
892 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:37:36.16 ID:pLeAl7hn.net]: まずは(Copy実装型の)数値演算だけやって変数と関数の使い方を覚えればいいだけじゃん
所有権なんて出て来ないぜ
その後にようやく数値の配列をやってその参照渡しと可変参照渡しを学ぶ
といったように順番にちよっとずつ学習していけば全くの初心者でも躓くことはない
893 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:44:23.36 ID:0vVjyJiG.net]: 相変わらず複オジはクソだな
894 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 13:49:35.50 ID:ez1nu7fa.net]: 部分的な学習ができないと主張してるやつは、いきなり無茶なことをしてるバカだけだな。
895 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 14:54:07.07 ID:zVqHX6VA.net]: >>880
でも標準機能の中でその理解が必要なんだよ
into_iterとかiterとか
その辺は本当にちゃんと理解してないとまともなループする書けない
896 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:06:46.90 ID:ZhUau2yw.net]: 言語の学習ではあまりないと思うけど複数のコンポーネントを全て完動させないと到達出来ない領域があるのは確か
レイヤーが下がるとそう言うのも珍しくない
897 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:37:58.58 ID:attOzucb.net]: >>885
それは一気に全てを理解しないといけないと思い込んでるアホ人間だから
初心者のうちはfor文なんてざっくりした理解で十分に学習をどんどん進められる
後にIntoIteratorを理解する段階になってようやくfor文を完全に正解に理解すればよい
898 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 15:56:25.04 ID:NBwKbSDK.net]: 初心者がなんか言ってるwww
899 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:01:39.35 ID:zVqHX6VA.net]: >>887
いやそれは無理があるだろ
所有権と借用の理解は型変換の時にも必須
collectとか使うときにも必須
競プロみたいな数値だけ扱うようなプログラムならかけるけど
900 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:03:22.02 ID:LLFCSjL7.net]: >>886
それは言語の学習と関係ないよね
Rust固有の話でもないね
つまり今回の話と全く関係ないでしょう

ちなみにそういう時はサンプルコードなどをまずは魔法の呪文とブラックボックスとして受け入れましょう
そして一つずつ把握する範囲を広げていけばよいのです
失敗する人は最初から全てを把握しようとする人だけです
901 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 16:06:42.76 ID:P4nmisNi.net]: >>885
問題点が分かってきた。
「部分的な学習」というのは項目をひとつきちんと理解してから次の項目の学習に移るみたいなスタイルを前提としているんじゃないか？
俺が思ってた学習スタイルは「概念が存在していることは知っている」という程度の全体像から解像度を上げていくような方向性だった。
機能は互いに連携するので「この部分は完璧にわかっているけど他はまだ」なんて状況は有りえんし、そういう学習方法できちんと身につくとは思わない。
(もちろん人によってやりやすいスタイルはあるのだろうけども、個人的にはオススメ出来ない。)

流し読み程度でも入門書を一度読めば (細かい借用規則を覚えていなくても) iter を使うくらいは出来るよ。
そこから何度でも読んで細かい理解を深めていくんだよ。
902 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:09:22.52 ID:Yud6QviI.net]: >>889
キチガイは黙っていろ
どんな世界でもそんなに一気に大きく手を広げて学習しようとして上手くいくわけがない
単純に一つずつやっていくのが正しい
collectなんて後で困らん
そもそもイテレータ使わなきゃcollectは出て来ない
ぶっ飛んだことを書き込んでいることを自覚しろ
903 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:10:09.70 ID:froE0MIe.net]: これがいつもの複オジ演w
904 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:15:28.56 ID:Qrm8xufh.net]: >>889
collectを使わなくてもプログラムを書けるから少しずつ学習していく方法でも支障はないし
collectを一旦は魔術だとみなして仕組みの詳細まで把握せずに利用して進めていく学習方法でも支障はないし
FromIteratorなんてあとから学べば十分ですよ
905 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:17:47.88 ID:zVqHX6VA.net]: いやcollectをここまで安全かつ効率よく実装してる言語はないのにそれを使わないのは論外
906 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:19:54.90 ID:zVqHX6VA.net]: 戦国時代に例えるならここに名刀があります
ワタクシは未熟だからこの刀は使いませんと言って
戦に出て殺されるみたいな話
その名刀を最初から使えるように訓練すべき
907 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:20:34.14 ID:QGiHkjYG.net]: 馬鹿じゃねぇの
908 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:26:15.56 ID:Qrm8xufh.net]: >>895
使いたいならば使えばよいだけですよ
初心者がFromIteratorの仕組みまで理解しないとcollectを使っちゃいけないのですか？
この場合の『部分的に学習』とはcollectの機能の一部をまずは表層的にのみ理解して使ってみることです
そしてこの『部分的に学習』は可能です
909 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:29:20.57 ID:BXFwwNrI.net]: 隔離スレに帰れ
910 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:29:25.15 ID:zVqHX6VA.net]: いやだから「表層的な学習」だとコンパイルすら通せないんだって
911 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:31:30.86 ID:zVqHX6VA.net]: 何度も言ってるけどRustはコンパイルを通せば
意図してないエラーはまず起きないし
Nullで落ちるなんてこともない
912 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 16:35:17.34 ID:vFqvnIUB.net]: 頭がいいと思い込んでる馬鹿がいきなり複雑な難しいことに挑戦して失敗して
難しい！とわめく馬鹿パターンはどんな分野でもある
その馬鹿が>>896
913 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:00:26.62 ID:zVqHX6VA.net]: 「段階的学習」というのは数学や物理においては成立する言葉だがプログラミングにおいては成立しない
なぜなら「知識の差」が普遍的に影響を受けてしまうから
例えば数学では代数学の理論を知らなくても初等整数論は学べるがプログラミングではそのようなことはないとわかる
914 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:01:28.47 ID:zVqHX6VA.net]: 例えばアルゴリズムの問題もそう
「知らない」ことが致命的になり得る
915 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:06:11.40 ID:zVqHX6VA.net]: collectを知らないものが自前でfor文で同じことを実装していたらどうなるだろうか？
レビューで指摘され赤っ恥を書かされてプライドはズタズタ
それが原因で鬱になるかもしれん
さらにパフォーマンス悪くなる
精神的にも肉体的にもダメージを負うことになる
916 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:18:30.46 ID:vFqvnIUB.net]: >>905
真逆だ
初心者の学習過程ならばcollectを使わずに実装することは適切な練習問題だ
その段階を経てからcollectを学習した者こそ身に付く
917 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 17:46:08.51 ID:5flxOiHV.net]: 段階的学習って↓を読み進めればいいだけじゃないの？
https://doc.rust-jp.rs/book-ja/
918 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 18:05:45.53 ID:qunzxQTR.net]: >>907
その通りなんだけど
Rustは段階的な学習ができない！と主張している変な人がいるのよ
919 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 18:41:19.07 ID:NDareeYW.net]: この複オジ演パターンはもうみんな気づいてるよね
920 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 18:43:17.38 ID:ye813FXw.net]: 赤い人をNGしときゃいいやん
921 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 19:01:55.07 ID:7zYgBA5I.net]: >>907
初心者・初学者に「the bookを読め」はさすがにむちゃだろ。

やっぱり「初心者はRust使わず他の言語から勉強しろ」が正解なのかね。
922 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 19:07:38.54 ID:gMN5eNCr.net]: >>891
さすが餃子さん分かってらっしゃる
最初は大まかな理解→もう少し詳細な理解→最後に完璧な理解という解像度の段階的な学習を中心に
項目や範囲を広げていく網羅度の段階的な学習を組み合わせることでRustの学習を含めて一般的な事柄にも適用できる
923 名前：はちみつ餃子 mailto:sage [2022/10/04(火) 20:17:29.13 ID:P4nmisNi.net]: >>911
そこで言ってる「初心者」は「Rust の初心者」ではなく「プログラミングの初心者」の意味？
そうだとすると the book はちょっとハードルが高いということはあるかもしれんな。

でも C++ と比較すると C++ のほうがもっとハードルが高いと思う。
コンパイラが検出しないところで未定義に入り込むことがあまりに多い。
初心者が間違うのは当然のことだが、正しいのか間違っているのかわからないというのは間違っていることが明白であるよりもしんどい。
そこで間違ったまま邁進できるようなメンタルの持ち主はそれはそれで遠からず行き詰るし。
924 名前：デフォルトの名無しさん [2022/10/04(火) 20:27:55.40 ID:9Mq2x6bG.net]: >>867 ですが、
>>876 さんがおっしゃることが僕の意図を言い当てています
c++を使わなくなって 15年は経ちますが、その頃の c++にはテンプレートはありましたがスマートポインタやラムダ式、その他諸々のモダンな機能はまだありませんでした(と思います)
クラス付きのCの部分で仕事をしていました
モダンなc++へ再入門するか、rustを学ぶか迷って rustに触れて今に至りました
925 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 20:36:11.60 ID:pQmQIrKs.net]: >>914
C程度の予備知識があるならば
>>907のRust Bookだけで容易に段階的に学習できるから何ら問題は起きず大丈夫
926 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 21:10:32.92 ID:d7kGndGU.net]: 所有権も借用も生存期間も理解してなければ
メソッド呼び出し一つ満足にできないんだから
それら無しに動くものが作れるわけない

学習自体は言語に限らずどんな学習でも部分的段階的にやるもの
それ以外の方法なんてないんだから論点ずれてる
927 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>916
それはさすがに無知すぎやろ
Rustは数値など所有権とは無縁な型で構成されているから
所有権なんて理解しなくてもプログラムを組める
段階的に後から所有権を学ぶことができる
928 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 23:03:40.79 ID:HL14YOAo.net]: >>917
所有権も知らずにイキってた人はさすがに言う事が違うねぇww
929 名前：デフォルトの名無しさん mailto:sage [2022/10/04(火) 23:58:47.13 ID:vxOZn4OH.net]: 数値型って所有権がっつり関係してると思うけど
930 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 00:06:13.80 ID:SE95U4Vu.net]: >>919
数値型はCopyを実装しているので所有権は無くムーブも起きない
931 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 02:07:12.38 ID:1K+My+/e.net]: 数値型だけで>>867の言う「動くもの」を作ってみれば？
932 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 02:59:14.45 ID:P8+KCirf.net]: 所有権は実在しない幻影
lifetimeとvarianceだけを見つめなさい
933 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:09:52.75 ID:Ybu4BU3z.net]: どうも段階的にやれると思ってる人はデータタイプを数値に限定してる気がする
数値はコピー可能でありRustのサンプルとしてよく使われるが
コピー可能なオブジェクトというのは普通のアプリケーションでは効率が悪すぎて使わない
つまり所有権の理解は必須なのだよ
934 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:15:49.43 ID:UScD8/ ]: [ここ壊れてます]
935 名前：dK.net mailto: 初学者にマウント取りするだけで、ステップアップの具体的なノウハウを示したり
理解しやすいドキュメントを整備提供したりできない積極的に導けない人間ばかりの
コミュニティが形成されてる言語は決して流行らない

行き着く先は*BSDのような”魔法使い以外は帰れ帰れ”した結果の荒涼とした世界 []: [ここ壊れてます]
936 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:19:22.28 ID:Ybu4BU3z.net]: 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
コピーして効率よく処理できる仕組みがないからmoveが生まれた
937 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 03:20:04.62 ID:Ybu4BU3z.net]: 段階的なんてものは存在しない
理解してるかしてないか
938 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 05:31:48.70 ID:wne70pEz.net]: >>921
Hollow world から始めなさいよw https://doc.rust-lang.org/rust-by-example/hello.html

>>925
そもそも初学者って言ってるのに
> 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
とか頭おかしい
939 名前：デフォルトの名無しさん [2022/10/05(水) 07:53:16.44 ID:MzMPKgoE.net]: 初学者にマウント取りたいやつがイキってる
940 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 10:48:19.99 ID:gF0QOXVU.net]: 初学者にしてもスタイルは人それぞれだろうし皆がどうやってrust習得したか語ってくれた方が参考になりそう

自分はlifetimeが導入される前からrust触ってたからコンパイラに追加される機能を適宜試してみながら体で覚えた
941 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:23:13.56 ID:1F438Xk1.net]: 初級者はHello, world!からって、かつての初級者はBASICから並みに罠じゃね
ほとんどのHello, world!は現代のプログラミングで必須の要素が欠落しまくっているからな
942 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:28:02.85 ID:BbaUEliB.net]: 複オジも100点オジも
もう少しRust勉強してからレスするか
大人しくしとくかどっちかにしてくれ
943 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:28:25.81 ID:tZ9pwx2f.net]: コンパイル、ビルドができるまでの説明だし
944 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 11:34:33.18 ID:+5Cy2zf0.net]: ホロウワールドは何かのネタ？
945 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 12:32:57.65 ID:OxlYZjk9.net]: 今担当してる作業が、あるまとまった処理を上手く対応付けするとちょっと複雑な数値演算処理だけに置き換えられるので、
その数値演算ライブラリを作っているのだけど、確かに所有権は全く出て来ない。
入出力は配列(スライス)の参照渡しと可変参照渡しとなっていてライフタイム明記も無し。

所有権を学ぶ前に参照(借用)だけで十分に色んな実践ができると思う。
そして参照は他の言語でも配列などは参照渡しになるから、新たにスライスだけ覚えればRustを段階的に学ぶことができる。
946 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 12:36:28.49 ID:+KHGV4+/.net]: 俺はずっとJavaメインで、遊びでlispとかHaskellとか触る程度で低レイヤは触ってなかったんだけど、Rustでここまで現代的に書けるならアリだなって触り始めたクチだな。
947 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 12:59:55.95 ID:EKfM3pGK.net]: >>930
まずハロワやれと言われるレベルの初級者ってプログラミング自体初めてやるようなレベルの人でしょ
それならあれこれ教えたところでどうせ理解不能になるだけなのでとりあえず動くものを作らせることには意味がある
948 名前：デフォルトの名無しさん [2022/10/05(水) 13:37:41.28 ID:Pj9P59N0.net]: ただいまんこのあとは
シコシコちんちん　シコシコ　イソチンチン
949 名前：デフォルトの名無しさん [2022/10/05(水) 13:47:37.30 ID:X575+w0V.net]: かい
950 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 15:06:32.60 ID:wne70pEz.net]: >>930
何を勘違いしてるんだよw
ハロワはプログラミングの勉強じゃなくて>>932も書いてる通り環境の勉強だぞ
お前の言う必須の要素が何を指してるのか知らんけど例えばif文の勉強したい時に動かせるかどうかは重要だろ
951 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 16:08:34.41 ID:l3k0CCzl.net]: >>934
（安全な）参照は所有権の上に成り立っているよ
952 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 16:19:48.70 ID:7FrBhgJk.net]: >>940
それも真
しかし>>934のような使い方だと所有権を意識する必要すらないのも真
同様に>>934のような使い方だと参照のライフタイムを意識する必要がないのも真
これは類似なものとしてC言語を使っている時に常に所有権とライフタイムを意識する必要性があるわけではないことも同様に例示される
953 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 17:04:57.53 ID:NuKocPG+.net]: 噛み合ってない理由がわかった
競プロ勢が多いんだな
数値しか扱わないなら
ベターCとして書くことは容易だからね
954 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 17:33:30.37 ID:66O9N6nP.net]: 競プロじゃないけどトレイトとかよく判らないから安定しているCとしてしか使っていないわ
955 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 17:33:54.20 ID:mBRaD/Kx.net]: >>942
競プロ勢による書き込みが見当たらないこの状況で
妄想により幻覚が見えているのか？
956 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 競プロ勢の炙り出しには成功したみたいだな
957 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 23:31:57.40 ID:lcOrUuZN.net]: 色々書いたうちCLI程度の規模のプログラムだと大半は所有権の移動がなくて所有権の意識が薄いな
オブジェクトをnewするところは厳密には移動と言えるかも知れないが単なる値返しと捉えるだろう
あとはオブジェクトの参照を渡していくだけたから単なる参照渡し
958 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 23:44:31.07 ID:V7HNybPt.net]: 毎日毎日息を吐くように嘘を吐く複オジ
控え目に言っても頭おかしい
959 名前：デフォルトの名無しさん mailto:sage [2022/10/05(水) 23:56:41.83 ID:nYqhDlIA.net]: 数値型だけでは動くものが作れないことに気がついたみたいだな
Rustで所有権を理解せずに動くものを作るなんて柱を使わずに家を建てるようなもの
960 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 00:08:02.42 ID:aXzDwmUt.net]: >>946
関数が値返しと引数可変参照渡しへの書き込みだけならプログラムの規模や種類に関係なくそんなもんだろ
所有権が出てくる幕はない
もちろんライフタイムも出てこない
961 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 00:34:26.13 ID:XbdFr8Zd.net]: そういう点では所有権が出てこなくてもかなりの範囲のプログラムを書けるよ
962 名前：はちみつ餃子 mailto:sage [2022/10/06(木) 00:34:32.05 ID:rLXZsLBm.net]: >>949
いくつかの自明な場合にはライフタイムを省略しても暗黙のルールが適用されるから書かなくてもよいだけで、ライフタイムが存在しないわけではないよ。
その暗黙のルールが比較的自然に定義されてるってことなんだろうね。
963 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 00:37:42.29 ID:4kCBwc0q.net]: >>951
それは違うな
>>949のケースは参照返しをしていないのだからライフタイムは出て来ない
ライフタイムの存在を意識する必要もない
964 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 01:26:52.37 ID:v2j3J5Hy.net]: 動くものってなんだよ
965 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 01:33:20.48 ID:QZHh62Nh.net]: Rustを使ってると、参照を返すようなコードはだんだん避けるようになるかもしれないな
966 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 01:59:47.45 ID:iRnDWdOb.net]: 競プロみたいにmain関数のみ
データ型は数値のみ
データ構造は固定配列のみ
サイズも高々数百から数千程度なのでスタック確保でオッケー
配列への参照のみ必要
結果は固定配列を新しく作ってそこに詰めていく
これなら所有権など一切いらない
967 名前：デフォルトの名無しさん [2022/10/06(木) 02:04:59.09 ID:MtARpYSM.net]: この件は数値型や競プロは一切関係ない

ヒープを使うVecやStringやそれらを含む構造体を返しても『値返し』となる点がポイント
『参照返し』とならないため『ライフタイム』は登場せず『所有権』を意識する必要もない
そして『値返し』だけでも様々な実用的なプログラムをRustで作ることができる
968 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 02:07:29.97 ID:iRnDWdOb.net]: ついにlinux kernelにRustがマージされた模様
969 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 02:38:59.47 ID:v2j3J5Hy.net]: >>95
970 名前：4 個人的にはdangling pointetとか内部オブジェクトを書き換えられる心配しなくて良くなるから 他の言語より積極的に参照返すようになってる気がする []: [ここ壊れてます]
971 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 06:12:47.90 ID:QjC44cq3.net]: 参照返しの安全性を保証できるRustいいよな
参照返しを使わず値返しだけでもかなり広い範囲のことを処理できる点も同意
972 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 14:46:06.11 ID:wkSQkKsv.net]: 値返しとか参照返しなんて言葉をRustで使うなよw
973 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 参照を返す時のみ
ライフタイムの概念が登場
だから参照返しと値返しの区別は実質的に重要

もちろんRustでは常に(広義の)値返しとなる
そして参照返しとは参照を(広義の)値返しすること
参照返しの対義語として(狭義の)値返しを使ってもよい
974 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 構造体など参照以外の値がlifetime持つ場合もある
参照だけ区別するのはなぜ
975 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: ここでいうlifetimeはlifetimeパラメーターのこと
976 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>962
それはそのフィールドが参照を返しているね
構造体がライフタイムを持つのはそのような時
977 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: > 値返しとか参照返し

これはどこに定義された用語ですか？
それともオレオレ用語ですか？

https://en.wikipedia.org/wiki/Evaluation_strategy
> 3.1 Call by value
> 3.2 Call by reference

値渡し参照渡しは昔からよく聞くけど
978 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:37:35.04 ID:mTG1aBjr.net]: 最初に言い出したのは

>>952
> >>951
> それは違うな
> >>949のケースは参照返しをしていないのだからライフタイムは出て来ない

これか
979 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:37:37.36 ID:ry4GAtyf.net]: >>965
それは関数の引数としての渡し方だから返し方とは独立ではないか
980 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:38:40.62 ID:QZHh62Nh.net]: Return by Referenceも知らんのか・・・
981 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:40:52.32 ID:mTG1aBjr.net]: どこに定義されてる用語なのかを知りたいだけよｗ
982 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 15:45:23.29 ID:JBcgzpIo.net]: Rustでは参照返しが有る時だけライフタイムパラメータが付くんよ
例えば3つの参照返しが有る時に3つのライフタイムが異なれば3つのライフタイムパラメータが付くんよ
だから参照返しが有るか無いか区別されてしまうんよ
983 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:06:44.80 ID:sWKfpE/G.net]: 結局Rustにおける値と参照とは何かを知るためには所有権の理解が必須なワケよ
984 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:15:24.55 ID:B9K2Q0k5.net]: by valueの意味が他の言語とは違うからな
985 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:23:06.37 ID:bcHprxpF.net]: >>971
参照を返さない限り所有権の理解は不要
Rustでは配列も構造体も更にはヒープを用いるVecやString等も値として返される
つまり参照を返さなくてもある程度の広範囲のプログラムを書くことができる
986 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:33:59.37 ID:mb1xnKf4.net]: ムーブのことも忘れないでください
987 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:37:24.79 ID:JMKkrzgh.net]: >>974
ムーブする必要ないよな
参照渡しだけしていれば所有権は出て来ないな
988 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:42:22.59 ID:bM/kk4ia.net]: 所有権要らないならRust要らないじゃんって思いながらずっと読んでる

どういう結論に持っていきたいの
989 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:44:20.49 ID:QZHh62Nh.net]: 釣りが目的で書き込んでるひとと、それに付き合ってレスしてるひとがいるからわけわからん
990 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 16:49:39.04 ID:+ZB5z2+t.net]: 参照渡しだけして参照返しをしなければ
所有権もライフタイムも出てこないからそれらを意識することもない
結果として所有権とライフタイムを理解していなくてもそのスタイルでプログラムを組むことが出来てしまう
991 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 17:03:06.06 ID:HCQdlFdq.net]: >>976
rust 学習の話だろ？
未来永劫所有権の理解は不要なんて誰も言ってないと思うが
992 名前：デフォルトの名無しさん [2022/10/06(木) 18:43:34.42 ID:rjzElph2.net]: 逆にrustだとどういう時に参照返しが必要になるの？
993 名前：はちみつ餃子 mailto:sage [2022/10/06(木) 18:48:14.82 ID:rLXZsLBm.net]: >>980
Rust 特有の事情なんかないよ。
C/C++ でポインタや参照で返すときと同じだよ。
994 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 19:17:16.58 ID:mTG1aBjr.net]: 「参照で返す」「参照を返す」って表現する人　←わかる
「参照返し」と言い続ける人　←？？？
995 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 同じだろ
参照を渡すことを参照渡し
参照を返すことを参照返し
996 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 値渡し参照渡しで言うと依然として単なる値渡しなのに
ただポインタを渡してるだけでそれを
「ポインタ渡し」とか言い出したり
ひどいやつだと「参照渡し」だと言いはったり
そういうのを過去にC言語界隈で見てきたから気になったんよ
独自解釈による珍妙なワードはこの世に必要ないと思うでしょ

>>983
そうですかボクからはもう何も言うことはありません
997 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>984
それは君が区別すべきことを理解できていないから混乱している
会話や説明では何と何を区別するかが重要
もちろんRustでは常に指定した型そのものが渡され返される
だから区別するとしたら実体を渡したり返したりするのかその参照を渡したり返したりするのかが焦点となる
したがって参照渡しや参照返しという言葉がぴったり適して使われている
998 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: あとポインタへのポインタを「ダブルポインタ」って呼んじゃう人もいたな
このスレでは「所有権の複製」ってのもあったな
999 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: >>986
英語でもダブルポインタと言うし何を問題にしているのかわからん
自分勝手な線引きやルールがあってそこから外れると融通が効かなくなるダメな人かね？
1000 名前：デフォルトの名無しさん [[ここ壊れてます] .net]: ゲームの方のRustで、ホロライブのRustのSeason3が終わるから検索汚染も減るかもな
1001 名前：デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]: 参照で返すことを「参照返し」と言った途端ブチギレするのマジで意味不明なんだがその呼び方を否定するとどんなメリットがあるのだろうか
1002 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:19:33.91 ID:bM/kk4ia.net]: 意味不明なら言及しなくていいよ
1003 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:27:57.49 ID:RK7Fg483.net]: >>984を見るとCでポインタで渡すことをポインタ渡しと言われるだけで発狂するようだからその人はキチガイ
1004 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:52:03.93 ID:lx27AXhR.net]: 参照はピリリと辛い
1005 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:52:48.54 ID:mb1xnKf4.net]: 他への参照を持つ実体を返すのは値返しか参照返しかはたまた別の何かか
なんて考えたくない
1006 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 20:58:52.86 ID:EteQ2MpB.net]: 「ポインタ渡し」がNGなら「ポインタを渡すこと」も日本語でそう表現していいよと言語の開発者がわざわざお墨付き与えなければNGだと思う
1007 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:00:15.33 ID:99NRyDSB.net]: 今回はRustの段階的学習の話だから、これだけのことではないかい。
参照返しが含まれていなければ、ライフタイムを把握する必要がなく、所有権を学習していない段階でも、そのプログラムを書くことができる。
参照返しが含まれていれば、ライフタイムを把握する必要があり、所有権を学習した以降となる。
1008 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:05:33.19 ID:DNbAbwmR.net]: 複オジwを相手にしちゃうからww
1009 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:09:49.66 ID:Re0G7B20.net]: ぼくちゃんrust入門者
ライフタイム注釈だけはどうにかならなかったのとか思った
でもいろいろ満足
tauriやるぞう
1010 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:23:30.56 ID:xIsaLol7.net]: ホント毎日毎日アホなこと書いてるなぁ
釣られちゃうRust入門者は少し不憫
1011 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:26:14.68 ID:ccGjPy8L.net]: >>995
所有権を学ぶのを後ろへずらすことでRust学習の難易度を大きく下げられそうね
1012 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 21:35:40.63 ID:jyraEk4K.net]: などと言う嘘つき初心者w
1013 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 101日 13時間 18分 37秒
1014 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

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

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