21/04/18 12:57:11.20 UN4umXE6.net
vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？
151:デフォルトの名無しさん
21/04/18 13:12:40.26 /yrt+WGh.net
お前らの用途だったらgoで十分だろと思うことが多いわ。
ファッションでやるってのも悪くはないが。
152:デフォルトの名無しさん
21/04/18 13:30:23.57 8MLIImZW.net
rustではunsafeを多用するのは良いことですか？
153:デフォルトの名無しさん
21/04/18 13:39:58.68 a3mPgn8/.net
必要なら使えばいい
154:デフォルトの名無しさん
21/04/18 16:52:32.86 dOXZMSKq.net
>>148
そういうメソッドはなさそう
特に理由がなければ分けて書いた方がいいけど、ブロック式を使って
let y = { v.push(x); v.last_mut().unwrap() }; // 変数に入れる場合
f({ v.push(x); v.last_mut().unwrap() }); // 関数に渡す場合
みたいな詰め方はできるかな
いっぱい使うならローカルなマクロ作ってもいい
macro_rules! push_and_mut_ref {
($v:expr, $x:expr) => {{ $v.push($x); $v.last_mut().unwrap() }};
}
let y = push_and_mut_ref!(v, x);
蛇足だけどyが生きてる間はvに触れないからご注意を
155:デフォルトの名無しさん
21/04/18 17:30:23.89 qHYw4Dd3.net
>>152
>蛇足だけどyが生きてる間はvに触れないからご注意を
蛇足ではない気がする
push時にその要素のmut refを必要とするような書き方は避けたほうがいい
156:デフォルトの名無しさん
21/04/18 17:38:05.52 /DBGFH0C.net
entry APIみたいなことしたいのかな
157:デフォルトの名無しさん
21/04/19 03:50:11.66 cH3u5yp0.net
Rustに比べたC++の良さは雑に書けるところだって気付いた
やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ
158:デフォルトの名無しさん
21/04/19 08:44:54.89 4a/aZ6Q1.net
>>155
いいところに気付いたな
Rustは一般プログラマーには無用の長物だ
159:デフォルトの名無しさん
21/04/19 10:48:10.96 7a+3hK+O.net
段階的に直していく方法と最初から設計で硬くしておく方法があると思うが
rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。
160:デフォルトの名無しさん
21/04/19 11:19:16.28 QqvLWpkW.net
型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが
161:デフォルトの名無しさん
21/04/19 11:21:50.23 7a+3hK+O.net
>>158
型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。
ちょっとしたリファクタリングするにもかなり大域的変更になる。
162:デフォルトの名無しさん
21/04/19 11:34:35.17 VqBzpR75.net
>>155
雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね
163:デフォルトの名無しさん
21/04/19 13:02:55.04 sZaag2LS.net
>>160
何言ってんだこの馬鹿
Rust謹製なら脆弱性が無いとでも思ってんのか？
164:デフォルトの名無しさん
21/04/19 13:06:52.92 hAOdtYDs.net
つーかRust以前はどうしてたんだよって話ｗ
流行りのもんに飛びついてそれ以外見えなくなってる典型
165:デフォルトの名無しさん
21/04/19 13:26:32.62 I7sE/fYQ.net
どうしてたって脆弱性を秘めたまま出回ってただろ
166:デフォルトの名無しさん
21/04/19 13:27:33.53 k4Vsf7V5.net
いつものレイヤーとかスコープを
ごちゃまぜにする思考が乱雑な人でしょ
167:デフォルトの名無しさん
21/04/19 14:27:55.78 7a+3hK+O.net
それお前だろ
168:デフォルトの名無しさん
21/04/19 16:41:05.18 OqiIdPZa.net
まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな
どうみても簡単で早いし・・・・
169:デフォルトの名無しさん
21/04/19 16:57:54.64 QZprAv/b.net
>>155
C/C++は雑に書けるというより、Rustが想定してないでけで
本当は安全なプログラムも思った通りに書くことが出来る。
RustはRustが想定している範囲内でしか書けないので面倒なことになる。
170:デフォルトの名無しさん
21/04/19 17:00:14.68 QZprAv/b.net
>>167
職人さんはさまざまな危険な道具を、十分安全に使う。
Rustは、「危険だ危険だ」と言って、危ない道具を使わせず
予め「刃(やいば)を抜かれた」道具の使用を強制する。
171:デフォルトの名無しさん
21/04/19 17:08:36.65 QZprAv/b.net
AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。
なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。
同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ
を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ
であることの証明にはならない。
172:デフォルトの名無しさん
21/04/19 17:33:10.17 QqvLWpkW.net
>>169
具体的に何のベンチマークのことを言っているの？
173:デフォルトの名無しさん
21/04/19 17:37:07.25 QqvLWpkW.net
unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは？
174:デフォルトの名無しさん
21/04/19 17:58:35.97 eG8AP0Ht.net
今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ
RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど
Rustでよく使うパターンが
175:デフォルトの名無しさん
21/04/19 17:59:44.87 cPEAzkUm.net
「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか
176:デフォルトの名無しさん
21/04/19 18:02:01.96 Nl1mmVW4.net
だって入れ食いなんだもん…
177:デフォルトの名無しさん
21/04/19 18:15:13.40 zaOVVmA+.net
>>173
リトマス試験紙なんよ
C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。
C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。
178:デフォルトの名無しさん
21/04/19 18:56:00.14 7a+3hK+O.net
>>171
言ってる意味がまるでわからんのだが。
179:デフォルトの名無しさん
21/04/19 19:29:57.41 OqiIdPZa.net
大半の人は、C/C++で苦労も何もしてないだろう
何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ
180:デフォルトの名無しさん
21/04/19 19:51:48.28 iY2hw6vD.net
C/C++でメモリをぶっ壊して数日絶望するところまでがチュートリアル
181:デフォルトの名無しさん
21/04/19 19:59:51.22 sjEpEGTN.net
メモリぶっ壊すのは絶望ではない、C++の日常だ
182:デフォルトの名無しさん
21/04/19 20:10:50.91 hAOdtYDs.net
>>178-179
この人たち未だにC++でnewとかdelete多用してるかそれを通過儀礼のように捉えてる人たちだよね
こえ～
よくある職
183:場の老害像そのものじゃん
184:デフォルトの名無しさん
21/04/19 20:11:49.67 sjEpEGTN.net
アマチュア君にはそう見えるんだね
185:デフォルトの名無しさん
21/04/19 20:13:49.42 cPEAzkUm.net
さすがに日常ではないかな……
構造体の初期化にmemset使うようなC言語上がりのやつはどうだか知らんけど
186:デフォルトの名無しさん
21/04/19 20:16:58.02 swd16GZO.net
毎日のようにRustスレで繰り返し同じ事をグチグチ言ってる自称C++使い達はよっぽど暇なんだなぁって思う
187:デフォルトの名無しさん
21/04/19 20:21:28.79 7a+3hK+O.net
c/c++でそんだけ壊れるならrustでもunsafe使ってぶっ壊れまくるだろ。。
エアプ丸出しすぎるわ
188:デフォルトの名無しさん
21/04/19 20:21:54.23 iY2hw6vD.net
引数チェックのないライブラリ等で引数を誤ったりすると
パッと見正しく見えるのでかなり面倒なことになる
189:デフォルトの名無しさん
21/04/19 21:31:37.98 LNECVJtJ.net
AddressSanitizerを使ったことのないものだけが石を投げよ
190:デフォルトの名無しさん
21/04/19 22:14:40.51 w0HdGBDs.net
伸びてると思ったら。次からﾜｯﾁｮｲ付けろよ。
191:デフォルトの名無しさん
21/04/20 00:56:58.25 h4Yrn7zO.net
URLﾘﾝｸ(trends.google.com)
Google Trends での Rustと他の言語とのトレンド比較。
これを見る限り、Rust言語は全く流行ってないようだ。
192:デフォルトの名無しさん
21/04/20 00:59:14.52 h4Yrn7zO.net
Python>Java>=JS>C++>>>>Rust
193:デフォルトの名無しさん
21/04/20 01:00:58.56 P7hWVPU6.net
そんな超メジャー言語と比較されるようになったのか
194:デフォルトの名無しさん
21/04/20 01:04:41.62 h4Yrn7zO.net
>>190
逆にそんなマイナーな言語なのに書籍が出たりtwitterでRustとWasmが
対になって出たりしてたのか。
Rustを試してる人は書籍や雑誌記事を書いて食っていくかか、難しくて新しい言語
を知ることで自分の社会的評価(?)を上げようとしているのか。
195:デフォルトの名無しさん
21/04/20 01:11:58.24 P7hWVPU6.net
>>191
なんかかっこいい嫌味を言いたいみたいだけど
意味不明ですべってるぞ
196:デフォルトの名無しさん
21/04/20 02:00:40.62 1YS4Hj5E.net
>>161
雑に書いたコードだって自分で言ってんだろボケが
197:デフォルトの名無しさん
21/04/20 08:34:25.33 A+mNu4wy.net
URLﾘﾝｸ(m.slashdot.org)
198:デフォルトの名無しさん
21/04/20 10:41:16.90 MbK31k7w.net
なんか無駄なところに手を出しちゃったみたいになってる若い人が発狂してんのかね。
別にrustで学んだことは無駄にはならんよ。
現場でrust強要するのはクソだが。
199:デフォルトの名無しさん
21/04/20 11:46:33.55 UmXg6L/G.net
5chに若い人なんかいないよ
200:デフォルトの名無しさん
21/04/20 19:43:34.07 jXnHABO7.net
なるほどそれで皆C++の話ばかりするのか
201:デフォルトの名無しさん
21/04/20 21:08:17.70 i+94ZV2W.net
C++もそれだけ枯れたか
202:デフォルトの名無しさん
21/04/21 11:52:12.19 /JxRHm/B.net
C++ニワカのLinusはpanicは認めないと言う話をしてるのにアロケーターだけの問題だ
「それだけでしょ、分かってるやつ居なすぎ」とまとめる
範囲外のインデックスアクセスでもpanicするし、Debugなら整数のオーバーフローでも
panicする（なぜかReleaseだとpanicしない）とんでもないアホの勘違いはJavaを持って
きて検査例外と非検査例外の話をし出す。せっかくResult/OptionがあるのにRustの文化と
なっているpanicを通常は捕捉しないと言うものをKernelに持ち込むなと言う話。
範囲外アクセスで即座に既存のC/Kernelならレジスタを保存してダンプするような
Segment fault例外トラップなどが働くのに、panicでスタック巻き戻し実行が起こるのは
絶対的に受け入れられない言うとる
Cの悪名高きsetjmpや、C++のRTL/動的例外テーブルの議論を見てるようだ
検査例外と非検査例外の話をし出すアホはもう来るな
203:デフォルトの名無しさん
21/04/21 12:24:14.02 dj6DJThv.net
++うんこ華麗にスルーして、やっぱリーナス見る目有るわ神だろ
204:デフォルトの名無しさん
21/04/21 12:54:12.00 KSNXGwT5.net
別にそこまで褒めることでもないんだけどね。。
URLﾘﾝｸ(lkml.org)
の他の議論に比べて明らかに議論のレベルが低いわけで。。
205:デフォルトの名無しさん
21/04/21 13:38:37.86 T0Zi2n6U.net
>>199
なんか何言ってるのか分からない部分が有るな。
206:デフォルトの名無しさん
21/04/21 17:38:16.65 l2lL4TPp.net
js-sys見てたらJavaScript側の型の継承関係をDerefで表現しててびびった
こういうの普通なん？
207:デフォルトの名無しさん
21/04/21 17:58:04.79 tLndpRqR.net
>>201
歴史があってどう実装すべきかという指針ができあがっているCと
手探りで指針を作りつつあるRustで議論のレベルが同じにならないのは自然なのでは
208:デフォルトの名無しさん
21/04/21 18:42:16.83 KSNXGwT5.net
>>204
問題はそういう言語の問題まで行かず、カーネルが備えるべきところってな議論で止まってるって部分だけどね。
歴史という意味ではそもそもカーネルに対する歴史観が不足してる連中しかrustにはいないということになる。
209:デフォルトの名無しさん
21/04/21 22:06:45.67 2oKQsBoE.net
プロセスがスローし、誰も補足しなかった例外を
最終的に捕捉してそのプロセスを終了させるのはOS（ことによったらカーネル）の仕事である
一方、カーネルが仮に例外をスローしてしまったら誰が最終的な捕捉の任を負うのか
について今今のOS論には目下定説が無い
Linux（リーナス）は「カーネルは何があっても例外をスローすんなﾊｹﾞ、」という
古典的な立場
のやつ、
210:デフォルトの名無しさん
21/04/21 23:10:54.58 /dktUqXg.net
機械語に例外なんてねーよ
いい加減なこと言ってんじゃねーや
211:デフォルトの名無しさん
21/04/21 23:43:21.15 NQ0xHQya.net
>>206 CPUの例外と言語上の例外との区別が付いてないみたいね。
212:デフォルトの名無しさん
21/04/22 00:18:18.68 41g4gqqa.net
>>203
javascriptでメソッドとか探すときにプロトタイプを遡っていく動きがあるけど
それをRustのドット演算子（.）がメソッド使える型になるまで自動で参照解決する仕様で
模倣したんだと思う
演算子の特殊な拡張は正規表現とか構文解析のライブラリでたまに見かけるけど
どちらかと言えばトリッキーな手法
213:デフォルトの名無しさん
21/04/22 02:40:36.34 hZdbeIl+.net
panic上等のredox！
セキュリティホール開けるよりマシという理由だった。
>>203
アンチパターンだから通常のコードでは使うな。
トレイトメソッド呼べないからクソって所まではすでに
githubのissuesやrust internalsで合意が有る。
js-sysはffi（バインダ）だから仕方ない。
214:はちみつ餃子
21/04/22 02:53:02.19 3zTCC3Br.net
>>203
ガイドライン的には Deref はスマートポインタだけにしとけってことになってる。
URLﾘﾝｸ(rust-lang.github.io)
215:デフォルトの名無しさん
21/04/22 05:58:54.39 WQGVMWvQ.net
例外の最終的な捕捉をOSの仕事、と書いたのは語弊があったｽﾏﾝｶｯﾀ、
正確に言えば言語のランタイムが最終的に捕捉してプロセスを自発的に終了する
（スタックのアンワインドは言語依存性が強いのでそうなっている
しかしプロセスが自発的にexit()したら誰がそれを処理するのかというとOSやんけ；；；
カーネルの中で例外を生じられたら誰が終了を担保するのかについて
OS論的に定説が無いのは真
>>208
いじょ
216:デフォルトの名無しさん
21/04/22 06:34:32.34 WQGVMWvQ.net
で、別の観点の話をする、
OSがpanic上等というのはそれはそれでも良いが、
とにかくスタックのアンワインド処理は言語依存性が強いので
例外が通過する関数（ゼロコストの奴も含む）の巻き戻しのためには
関数のアドレスとスタックのアンワインド方法の対応表をランタイムが把握せねばならない
というわけでカーネル内の例外を認めると、その例外を最終的に捕捉する奴より
上の関数を全部同一言語・同一コンパイラで書かねばならないという縛りが生じる
現実にはそれで問題など生じないかしらんが、とにかくレイヤー分けに縛りが生じる
Redoxの一部をC++（等）で書くことは事実上不可能に、
217:デフォルトの名無しさん
21/04/22 13:01:11.46 hZdbeIl+.net
>>212,213
なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
>>213
Linusがカーネル書くのに信用してないだけで
C++でもフリースタンディング書けるだろ。
C++のフリースタンディングは最低限の標準ライブラリは持つからrustのcoreクレートと同じ。
C++ならexception、abort,exitがある。
>>213がホストとベアメタルの区別がついてないだけじゃないか？
あと、redoxのpanicはスタックトレース吐いてx86のhltループするだけだから。
そもそもカーネルで標準のexitなんか呼ぶか。
218:デフォルトの名無しさん
21/04/22 13:21:02.53 EDkBlaoV.net
Linux界隈といえばちょうど｢マージしたパッチが研究目的にわざと脆弱性を含んだものだったことが発覚して激おこで送ってきた奴らの大学出禁にする｣みたいな面白いことが起こってる模様
219:デフォルトの名無しさん
21/04/22 13:49:41.54 I9diyMZ1.net
どうせお前らはOS書かないんだからどっちでもいいじゃん
220:デフォルトの名無しさん
21/04/22 15:39:04.46 VwSZJGdV.net
linuxの騒動の話はさすがにスレチ
221:デフォルトの名無しさん
21/04/22 21:04:10.86 ndVhN6HU.net
Cコンパイラゼミ消失問題を思い出した
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
222:デフォルトの名無しさん
21/04/22 23:08:37.40 y/lG5X/l.net
研究目的だろうがそうでなかろうがわざと脆弱性を含むパッチを簡単にマージできている、という状況が問題なんであって
腹たつから大学出禁にしたった、とやったところで根本的な問題は何も解決しないんだけどlinuxのメンテナンスしてる連中とか
linusを筆頭にとか老害頭ばっかりだから自分がスッとすれはそれでいいんだろうな
223:デフォルトの名無しさん
21/04/22 23:21:38.67 5b2Tg2Qr.net
1) 善意でやってくれてる連中にケチつけんな
2) じゃあお前が根本的な解決とやらをやれ
3) もしくはその根本的な解決方法を彼らに教えてやれ
224:デフォルトの名無しさん
21/04/22 23:33:32.83 Bg0clzlT.net
しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
らすとすぱぁとをきめるスレ
225:デフォルトの名無しさん
21/04/22 23:52:38.76 KHhdvM96.net
rust厨八つ当たりw
226:デフォルトの名無しさん
21/04/23 08:31:32.27 yuX3+THA.net
その脆弱性もUAFとかぬるぽデリファレンスとか未初期化領域の使用とか2重開放とか最近の言語じゃ明らかに
227:意図してやらなきゃ起きないようなもんばっかだもんなぁ そりゃC/C++にしがみついてる大先輩方にとっちゃ逆鱗だわな
228:デフォルトの名無しさん
21/04/23 08:34:12.76 Lj3XxxY0.net
そんなもんunsafeしまくれば同じだろ。。
そういう問題じゃないことくらいわかるだろうに、本当の馬鹿だな。
229:デフォルトの名無しさん
21/04/23 08:36:52.46 +YpcBxgU.net
C++とlinuxの話禁止な
230:デフォルトの名無しさん
21/04/23 08:52:11.81 Lj3XxxY0.net
rustでOSかける->linus、panicある限り載せねーよ->rust信者発狂
231:デフォルトの名無しさん
21/04/23 09:00:00.40 5QBVXmI/.net
発狂？むしろ歓迎
個人で使うようなアプリは好きなだけパニくれ
使われるアプリはパニくんなカス、これ常識だろ
232:デフォルトの名無しさん
21/04/23 10:42:10.47 Lj3XxxY0.net
言語実装的にもそうなってないよねって話なんだけど、なんだか通じてなさげ。
233:デフォルトの名無しさん
21/04/23 11:59:33.30 bX8BaI1F.net
rustにもgoのマスコットキャラみたいなのいないんですか？
234:あめ
21/04/23 12:13:46.74 hS4CVJbd.net
かにさん
235:デフォルトの名無しさん
21/04/23 12:17:43.73 E6ocica9.net
>>214
>なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
カーネル内での例外を許すみたいな立場で話す人が居るから
例外メカニズムが言語ランタイムと不可分な理由は
>スタックのアンワインドは言語依存性が強いのでそうなっている (>>212
C言語みたいにそもそも例外メカニズムを持たない言語を使った場合のみ
言語ランタイムと切り離したカーネル設計ができてｽｷｰﾘ
236:デフォルトの名無しさん
21/04/23 12:23:39.46 Xbep6LJc.net
>>219
だから、脆弱性を簡単に盛り込めないように危険な団体を排除しただけだろ。
普通の対応だと思うけど？
237:デフォルトの名無しさん
21/04/23 12:31:21.77 +YpcBxgU.net
>>231
> >なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
> カーネル内での例外を許すみたいな立場で話す人が居るから
いません
この話はおわり
238:デフォルトの名無しさん
21/04/23 12:56:09.67 1/JMNo8Q.net
「注意すればC/C++でも問題ない」って意見は日本的だよな
人間はミスしないことが前提になっている
Rust Foundationのメンバーに言わせればそういう問題ではない
人間はミスするものだってなるんだろうけど
239:デフォルトの名無しさん
21/04/23 13:00:34.48 Lj3XxxY0.net
そのミスの取り除き方のアプローチの違いだっていうことにさえ気づかない馬鹿。
240:デフォルトの名無しさん
21/04/23 13:33:15.21 AZKiGQoD.net
c++でミスするような無能はrustでも使ってろと怒鳴り散らす
これが正しいアプローチ
241:デフォルトの名無しさん
21/04/23 13:43:27.45 M88Kc634.net
>>229-230
なんで蟹なんだろうな。
PythonユーザーのことPythonistaって言うみたいに
RustユーザーのことRustaceanって言うけど、
これCrustacean（甲殻類）からCを取り除いたものなんだな。
242:デフォルトの名無しさん
21/04/23 14:28:40.04 9+zMAQDa.net
エビにしろよな
カニだとRealtekと被るじゃん
243:デフォルトの名無しさん
21/04/23 14:58:40.99 ntrIv3TW.net
大半の人は、C/C++の文法がわかる程度でプログラムを書いているのが現状だろう
何がミスなのかそもそもわかっておらず、Rustを勉強している人と話も噛み合わない
244:デフォルトの名無しさん
21/04/23 15:01:12.26 Lj3XxxY0.net
c++とrustの部分入れ替えてもなんの違和感もない文章だね
245:デフォルトの名無しさん
21/04/23 15:03:21.83 ntrIv3TW.net
君にはそう見えるだろうね
246:デフォルトの名無しさん
21/04/23 15:05:01.62 Lj3XxxY0.net
君にはそう見えないんだろうね
247:デフォルトの名無しさん
21/04/23 15:05:59.83 ntrIv3TW.net
とりあえず、話が噛み合わないのはわかったでしょ
248:デフォルトの名無しさん
21/04/23 15:07:53.22 9+zMAQDa.net
C++ドロップアウターが希望を求めてやって来るスレ
249:デフォルトの名無しさん
21/04/23 15:13:29.93 ECpnCXVF.net
スレでグチグチ言うよりプログラム書いた方がよっぽど理解できるよ
250:デフォルトの名無しさん
21/04/23 15:20:14.54 ntrIv3TW.net
C/C++で穴のあるコードを書いてもしょうがないし、それも難しいんじゃないのかな
逆にC/C++の人らがRustコンパイラをすり抜けるヤバいコードを提示してくれたら、一発で口だけじゃなく出来る人だったと示せるだろうが
251:デフォルトの名無しさん
21/04/23 15:28:23.22 mq69qBnk.net
>>155
> Rustに比べたC++の良さは雑に書けるところだって気付いた
> やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ
これが何気に的を得てるでしょ
コンパイラが安全な方に導いてくれるのはもちろん良いとして、それよりも雑に (あるいは短く親しんだ方法で) 書きたい思惑が優先されるときは C/C++ でやれば良い話で
252:デフォルトの名無しさん
21/04/23 15:38:53.83 CjhKTAAP.net
いや、Rustでラクに書けない時点で勉強が不足してる
そのことに自分で気付けるような人だけRust使えばいい
「当を得る」か「的を射る」ことが出来るような人になってほしい
253:デフォルトの名無しさん
21/04/23 15:56:22.07 mq69qBnk.net
いや、単にコード長が C/C++ の方が短く書ける可能性高いでしょ
どんなイディオムを駆使しても
254:デフォルトの名無しさん
21/04/23 15:59:55.49 mq69qBnk.net
あと近年では「的を得る」は必ずしも誤用じゃないという見方が主流でしょ
255:デフォルトの名無しさん
21/04/23 19:45:46.49 ECpnCXVF.net
Rustの方が雑に書ける局面多いと思うけどなぁ
256:デフォルトの名無しさん
21/04/23 20:51:53.23 +YpcBxgU.net
C++ vs Rustスレでも作ってそっちでやってくれマジで
不毛すぎる
257:デフォルトの名無しさん
21/04/23 21:04:58.31 g6tU54WL.net
>>249
そうだね、記述量の多い言語だと思う
258:デフォルトの名無しさん
21/04/23 22:37:03.61 E6ocica9.net
Rustのコンパイラと戦って勝ったコードは
シンプルでエレガントで簡潔なことが多い
らしい
mjk、
259:デフォルトの名無しさん
21/04/23 23:34:43.49 KS/Kkucz.net
linusはやっぱすげーな
洞察力が違うわ
もちろんその道の神的な存在とはいえ
たいして知らない言語の弱点を一瞬にして暴いて
論破できるのは凄い
260:デフォルトの名無しさん
21/04/24 01:08:35.83 h5KFlu4v.net
>>251
例えばどんなとき？
261:デフォルトの名無しさん
21/04/24 01:20:53.45 vtdgUVMq.net
どんなときもどんなときもRustがRustらしくある～ために～
262:デフォルトの名無しさん
21/04/24 08:06:24.96 nPKzA798.net
C++ vs Rust
ｽﾚﾘﾝｸ(tech板)
立てましたので以降そういうのはこっちでお願いします
263:デフォルトの名無しさん
21/04/24 08:33:43.03 AUtfiExa.net
>>258
お前ずっと一人で「他所でやれ」連呼してる奴だろ
C++との対立構造はRustにとって無視できないテーマでしょ
正直C++とどう住み分けたら良いのかわかってない奴がほとんどなんだから
264:デフォルトの名無しさん
21/04/24 08:39:09.80 /opj2hnT.net
C++とRustは対立なんてしてない
Rustが怖いC++お爺ちゃんがRustに噛みつているだけでしょ
265:デフォルトの名無しさん
21/04/24 08:48:20.99 MAG7Rri7.net
カーネルの件で完全に拗らせとるな
266:デフォルトの名無しさん
21/04/24 08:54:35.43 8O98k7om.net
> C++との対立構造はRustにとって無視できないテーマでしょ
お前のテーマなんてどうでもいいんだよ
よそでやってくれ
267:デフォルトの名無しさん
21/04/24 08:59:24.96 MAG7Rri7.net
一般的なテーマだってこともわからんのか。馬鹿だな。
268:デフォルトの名無しさん
21/04/24 09:02:59.11 CqGuC/ho.net
リナス「やっぱCが至高、C++もRustもクソ！」
269:デフォルトの名無しさん
21/04/24 09:13:04.98 IM8zU0Pj.net
rustもpanicをコアから外せればいけると思うのだが
もろ言語のコアなんだよな
痛いところ突かれた
270:デフォルトの名無しさん
21/04/24 10:06:12.73 yJd/gJxx.net
言語の問題じゃなくてライブラリの問題では
271:デフォルトの名無しさん
21/04/24 10:11:32.69 vtdgUVMq.net
へーpanicってライブラリなんだ
272:デフォルトの名無しさん
21/04/24 10:29:13.61 nPKzA798.net
>>259
仮にその対立構造を認めるにしても
「雑に書くならC++のほうが楽」なんて、曖昧で基準も何も示されない話に真面目に付き合う奴はいないよ
そういう奴らのための隔離スレとして用意したから好き放題書き散らせばいい
273:デフォルトの名無しさん
21/04/24 10:42:59.04 2MdujosH.net
コード長の話でしょ？
どー考えてもC++の方が短いよ
んなとこで張り合ってもしゃーない
274:デフォルトの名無しさん
21/04/24 11:44:33.91 8fCyRscb.net
3割ぐらいは長いな
URLﾘﾝｸ(benchmarksgame-team.pages.debian.net)
median source code gzip (July 2018)
Ruby 568
Python 672
C++ 1044
C 1115
Rust 1319
275:デフォルトの名無しさん
21/04/24 12:07:10.57 RPGHdVOi.net
>>258
乙。次からテンプレ入りで
>>980
スレ立てよろ
==========
公式
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(blog.rust-lang.org)
URLﾘﾝｸ(github.com)
Web上の実行環境
URLﾘﾝｸ(play.rust-lang.org)<)
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
URLﾘﾝｸ(doc.rust-lang.org)
※C++との比較は専用スレへ
C++ vs Rust
ｽﾚﾘﾝｸ(tech板)
前スレ
Rust part10
ｽﾚﾘﾝｸ(tech板)
==========
276:デフォルトの名無しさん
21/04/24 12:17:31.75 HBFF7y2e.net
Rustしかまじめに勉強したことないけどいい言語だと思うよ
277:デフォルトの名無しさん
21/04/24 12:21:15.48 8fCyRscb.net
>>272
C/C++で一度ひどい目にあわないとRustの良さは分からんよ
今はまだ分かった気になってるだけ
278:デフォルトの名無しさん
21/04/24 12:39:27.31 aNHhbYgZ.net
Rustはコンパイルでひどい目にあうから問題無い
同じことだ
279:デフォルトの名無しさん
21/04/24 12:56:02.52 1Wwd5OE1.net
Rustのコンパイラに怒られまくる奴は三流プログラマ
280:デフォルトの名無しさん
21/04/24 12:59:06.14 hc4SaSPr.net
Rustの文字列変数って、
str1 = str2;
のように書いた時、copyではなくmoveでしたっけ？
281:デフォルトの名無しさん
21/04/24 13:03:33.00 kYV5ExS+.net
String型ならmove、&str型ならcopy
文字列リテラルなら後者
282:デフォルトの名無しさん
21/04/24 13:09:43.73 hc4SaSPr.net
>>276
調べてみたら、やっぱり、
let s1 = String::from("hello");
let s2 = s1;
とすると、以後、s1は使用できなくなり、使用しようとするとコンパイルエラー
になるんだね。こうなるのは珍しいと言えば珍しい言語。
1. Javaだと、参照を入れるだけで同じ実体を指しているため、s2経由で変更してもs1が
指しているものも変更される。
2. JS の 文字列は primitive 型なので「コピー動作」となり、s2とs1は別の実体を
指すことになり、一方を変更しても他方には変更の影響は及ばない。
3. MFCのCStringも意味的にはコピー動作なのでJSと似ているが、高速化のため、
代入後に一度も書き換えなければ、文字列を入れているメモリブロックは複製
されないし、コピーもされない。
4. STL(C++) の std::striingもMFCと意味的には似た動作。
5. BASIC言語でも、文字列はコピー動作。
6. Rubyの場合、Javaと同じで同じ実体を参照しているだけなので、一方を書き換えると
他方も全く同じように書き換わる。コピーするためには、s2 = s1.dup; と書く。
つまり、
a. BASIC、JS、MFC、STL(C++)は似た動作。
b. JavaとRubyも似た動作。
c. Rustは、b の系統に似ているが、s1 が使えなくなるのでちょっと違う。
283:デフォルトの名無しさん
21/04/24 13:13:27.35 vtdgUVMq.net
>>278
無駄なことに時間使ってないでthe bookくらい読みなよ
284:デフォルトの名無しさん
21/04/24 13:20:12.76 hc4SaSPr.net
>>
C# は、「b.」の系統で、JavaとRubyと似た動作だね。
285:デフォルトの名無しさん
21/04/24 13:23:38.54 hc4SaSPr.net
>>279
いろんな言語をかじってしまうと、どれがどれだか分からなくなってしまうんだよ。
文字列の s2 = s1 の動作は：
a. BASIC、JS、MFC、STL(C++)は似た動作。中身をコピーする。
b. Java、Ruby、C# が似た動作。参照を代入するだけ。コピーしたければ明示する。
c. Rustは、b の系統に似ているが、s1 が使えなくなる。
286:デフォルトの名無しさん
21/04/24 13:27:17.48 hc4SaSPr.net
>>281
Javaの場合、Stringは参照しか出来ないが、Rustの場合は、「String型」だけでなく、
「Stringへの参照型」も使えるんだっけ (let s3:&String ??) ？
287:デフォルトの名無しさん
21/04/24 13:36:44.63 hc4SaSPr.net
>>281
C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、
moveで、それ以外の時は copy。
一方、Rustだと、「デフォルト move」なので、基本的には move 動作。
cooy したければ、x = y.clone; と書くのかな。
色々ややこしい。
288:デフォルトの名無しさん
21/04/24 13:39:26.22 glcm53ed.net
>>283
> C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、moveで、それ以外の時は copy。
そんな親切け？？？
左辺値同士だと明示しないとmoveしてくれないだろ
最適化次第ではしてくれるの？
289:デフォルトの名無しさん
21/04/24 13:43:36.80 hc4SaSPr.net
>>284
えっと、関数の戻り値が構造体型(or クラス型)の場合、右辺値と解釈されるので、
s2 = func(xxx);
見たいにした場合は自動的に move代入されたと思う。
それ以外だと、たいていは、s2 = std::move(s1); のように書かなければ
copy代入になるんじゃないかな。
s2 = func(xxx).s;
のようにした場合も move代入になるはず。
自信は無い。
290:デフォルトの名無しさん
21/04/24 13:47:10.36 Kvw1J2lw.net
>>285
RVOは全然違うぞ
s2の構築にコピーコンストラクタを使わなくなって早くなるというだけ
ムーヴコンストラクタはそもそも出てこない
291:デフォルトの名無しさん
21/04/24 13:47:25.73 hc4SaSPr.net
>>285
自分の記憶だと、一時オブジェクトも右辺値だから、
s2 = std::string("xxx");
ともし書いたとしたら、右辺は右辺値になるのでmove代入になるはず。
s2 = s3 + s4;
みたいにしても、右辺は関数の戻り地と解釈されるので右辺値になるので
move代入になるはず。
292:デフォルトの名無しさん
21/04/24 15:48:01.23 QvmQEBVA.net
Rustってコードをフォーマットしてくれる機能があるからいいね
これこそモダンな言語だと思う
293:デフォルトの名無しさん
21/04/24 16:01:24.29 93XQhLV9.net
C++と比べりゃ大抵の言語はモダンだろうよ
294:デフォルトの名無しさん
21/04/24 16:18:04.79 rGfKetgv.net
しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
rustすぱぁとをきめるスレ
295:デフォルトの名無しさん
21/04/24 16:38:27.41 MAG7Rri7.net
lintツールも満足に使えない人が喜んでるのかね
296:デフォルトの名無しさん
21/04/24 17:14:02.73 yJd/gJxx.net
非Syncなデータに複数スレッドからアクセスするコードに警告だしてくれるlintある？
297:デフォルトの名無しさん
21/04/24 18:12:05.46 6780eEd1.net
へーそれコードをフォーマットしてくれる機能なんだ
298:デフォルトの名無しさん
21/04/24 22:25:57.79 EY30SvcB.net
>>293
君は、松永の論文を読んだのかい？
299:デフォルトの名無しさん
21/04/25 11:06:21.68 M4WxeD2J.net
質問です
let a = 10;
let b = &a;
let &c = b;
としたときに変数cは数値の10になるのですが
cの前にある&は参照外しの効果があるということなのでしょうか？
300:デフォルトの名無しさん
21/04/25 12:30:46.33 yYRREqIx.net
>>295
pattern matchとdestructuringでそうなる
3行目でbの型が&Tの場合に`&c`にマッチさせたらcの型はTになる
dereferenceの意味で「参照外し」と言ってるなら意味は違うかも
301:デフォルトの名無しさん
21/04/25 13:38:30.57 rtrHqrCb.net
>>296
横から失礼するけど、なるほど。
let &c = b;
は、C++の
int &c = b;
とはかなり違った解釈をされてしまうんだね。後者の場合、&は参照型の
記号で、cの型は、intへの参照型になる。Rustで似たことをしたいなら、
let c:&i32 = &b;
だったっけ？
302:デフォルトの名無しさん
21/04/25 13:41:33.98 C031ZmfT.net
String::fromとString::newの使い分けを教えてください
303:デフォルトの名無しさん
21/04/25 15:13:55.60 3Jdhcm8q.net
>>297
cも参照にしたいなら単純に
let c = b;
でいいはず
let &c = b;
は
let (x, y) = (1, 2);
と似たような代入式だからbが参照型（かつ被参照型がCopy可能）じゃないと
コンパイルできない
>>298
String::newは引数取らないで空文字列を作る
String::fromは引数に文字とか文字列を取って同じ内容の文字列を作る
リファレンス（↓）読みなさいと言いたいけどRustのリファレンスって
traitとか理解しないとなかなか読みこなせないよね
_URLﾘﾝｸ(doc.rust-lang.org)
304:デフォルトの名無しさん
21/04/25 15:19:02.60 yYRREqIx.net
>>297
>let c:&i32 = &b;
>>295の続きならbがすでに&i32なので
let c = b; か
let c: &i32 = b;
C++でもStroustrupに従ってint& c = b;と書いとけば同じ意味にとれなくもない
305:デフォルトの名無しさん
21/04/25 15:31:18.79 2bakgkUg.net
意図もわからずなんとなく動くからそのメソッドを使い、借用をつければなんとなく動くから
借用し、変更する予定はないけどmutし、ここはエラーだからとpanic!し、補足するなと言われているのに
catch_unwind/recoverして、血の涙で泣きながら渡されたソースをシコシコ直すおまいら・・・
306:デフォルトの名無しさん
21/04/25 16:19:28.48 S2tV53BX.net
>>299 >>300
なるほど、Rustでの b は、C++で言えば「参照」ではなく「ポインタ」の「ようなもの」に
なっているので、
let a = 10;
let b = &a;
の状態だと、
let c = b; か
let c: &i32 = b; か
let c: &i32 = &a;
で c を b と同じような「Rustでの参照型」の変数に出来るわけね？
307:デフォルトの名無しさん
21/04/25 16:55:56.06 S2tV53BX.net
>>302
C++で書き直すと、
int a = 10;
int *b = &a;
の状態だと、
int *c = b; か
int *c = &a;
で c を b と同じような「C++のポインタ型」の変数になる。
ということだね。
308:デフォルトの名無しさん
21/04/25 17:24:01.78 Ef2Yns/P.net
>>301
割とこの未来はもう始まってるんだよな。。rust書き逃げは結構ある。。
309:デフォルトの名無しさん
21/04/25 17:25:49.32 vrxr0D/D.net
悪用できない道具など無い
310:デフォルトの名無しさん
21/04/25 17:30:22.71 VydP0zWV.net
構造体があるじゃん
a.b.cの更新参照もってて
同時に
a.b.dの更新参照とって
両方更新しようしたら
aの更新参照が２箇所にあることになるからできないの？
使い物にならんくない？
311:デフォルトの名無しさん
21/04/25 17:40:32.44 M4WxeD2J.net
>>296
なるほど
match式と同じ様に振る舞うのね
312:デフォルトの名無しさん
21/04/25 17:58:15.33 In1fvQYU.net
>>306
更新参照ってのが&mutのことならできる時とできない時がある
同じ関数内で &mut a.b.c と&mut a.b.d を取ることはできるけど
&mut a.b をとって &mut a.b.d を返す関数を呼び出した後は a.b.d にアクセスできない
これは関数呼び出し時点で a.b が borrow されると判断されるため
このあたりを何とかしようとする 議論は昔からあるけど特に進展なし
URLﾘﾝｸ(github.com)
実用的にはデータ構造の設計を見直すか、RefCell でくるむのが良いと思う
後者は &a.b をとって RefMut を返す関数にするってことね
313:デフォルトの名無しさん
21/04/25 18:57:01.34 1PPsE
314:J27.net
315:デフォルトの名無しさん
21/04/25 18:59:07.81 2bakgkUg.net
悪用できない道具など無いキリッwwwwwwww
316:デフォルトの名無しさん
21/04/25 19:04:09.95 3Jdhcm8q.net
>>308
細かいけど関数の例はRefMut返すより&RefCellで返す方が安全な気がする
RefCell本体の参照をシェアするだけなら二重で呼んでも大丈夫だし
RefMut作るのは変更が必要な瞬間だけに限定したい
317:デフォルトの名無しさん
21/04/25 19:28:29.93 gk8/Gpze.net
>>309
&strはlenも持ってる
fat pointerでぐぐれ
318:デフォルトの名無しさん
21/04/25 19:34:37.74 bkWFj8iO.net
RefCellについての良いドキュメントや、本などがあれば教えて。
319:デフォルトの名無しさん
21/04/26 10:05:04.39 HMswZhLH.net
f3がコンパイルエラーになる理由がわかる方います？
fn f2<'a, 'b, T>(x: &'a &'b mut T) -> &'a T { x }
fn f3<'a, 'b, T>(x: &'a &'b mut T) -> &'b T { x }
&'b mut TがTに変換可能で
&'a Tから&'b Tが変換不可だから？
320:デフォルトの名無しさん
21/04/26 12:08:58.70 DOIDJi7O.net
>>314
‘aが’bをoutliveするかどうかわからないからじゃない？
fn f3<'a: 'b, 'b, T>(x: &'a &'b mut T) -> &'b T { x }
321:デフォルトの名無しさん
21/04/26 12:53:56.61 SHVW/hag.net
リーナスのRustのパニックがどうのはCを前提としたプロジェクトとRustの流儀がマッチしないって話に見える
逆にRustの流儀に沿ってデザインされたシステムなら問題は起きない可能性もある
てかそういう研究はされていないのかな？
322:デフォルトの名無しさん
21/04/26 12:57:40.62 cN+lbm0F.net
全部rustで書けばいいってか。馬鹿すぎる発想だな。
323:デフォルトの名無しさん
21/04/26 13:02:47.63 +85I2LX6.net
パニックってFFI Boundaryさえ越えなければベアメタルだろうが使っても問題ない認識なんだけど間違ってる？
324:デフォルトの名無しさん
21/04/26 14:09:26.26 u7NjNSbC.net
>>316
そのシステムの基礎を作るのがOSで、Rustの流儀に従うようにする
基礎の部分を作るために Rust の流儀を前提とした言語で書くのは出来ない。
C言語は素朴なマシン語に直るために基礎を作ることが出来る。
325:デフォルトの名無しさん
21/04/26 14:16:19.84 ie84aLaE.net
>>318
別に使って問題ないし、ベアメタル用のパニックハンドラなんかもいろいろあるよ。
326:デフォルトの名無しさん
21/04/26 14:33:09.14 DOIDJi7O.net
>>313
URLﾘﾝｸ(doc.rust-lang.org)
URLﾘﾝｸ(ricardomartins.cc)
URLﾘﾝｸ(stackoverflow.com)
327:デフォルトの名無しさん
21/04/26 15:35:40.97 EKg1PdAE.net
>>317
いきなりLinuxやWindows級のOSを作るのは現実的ではないが
組み込み用のOS程度なら馬鹿げてはないだろう
328:デフォルトの名無しさん
21/04/26 18:30:20.34 ONuspOvn.net
>>315
回答ありがとうございます
確かに'a: 'bを付けるとコンパイル通りますね
xの変換については
&'a (&'b mut T)
→ &'a T
→ &'b T ('a: 'b指定により可能)
という考え方で良いのでしょうか
329:デフォルトの名無しさん
21/04/26 18:39:37.14 ONuspOvn.net
>>323
いや自分で書いてて全然理解できてないです
下記変換は無しですかね。。
&'a (&'b mut T)
→ &'a T
330:デフォルトの名無しさん
21/04/26 20:00:38.89 +85I2LX6.net
>>324
&'a &'b T の lifetime は 'a と 'b の短い方になるから
むりやり書こうとすると min('a, 'b) みたいになる
'a: 'b というのは 'a が 'b より長生きするという意味で
この場合 min('a, 'b) = 'b になるので f3 が valid になる
なお、&'a &'b T については暗黙的に 'b: 'a とみなされてるからコンパイルが通る
('b: 'a の時しか &'a &'b T 型の値が作れないため)
331:デフォルトの名無しさん
21/04/26 20:05:03.48 cN+lbm0F.net
>>322
じゃあ自分で作ってみりゃいいじゃん。
linuxなんかにいちゃもんつけてないでさ。
332:デフォルトの名無しさん
21/04/26 23:42:53.23 y3Z2xzaE.net
>>301
自分で書いてて全然理解できてない奴らが量産されて、キーボードを叩く拳に血が混じりながら
意味不明なコードを誰かが直す。なんというおそろしい未来かw
333:デフォルトの名無しさん
21/04/26 23:56:56.13 MHmHz52r.net
linuxにいちゃもんつけてる人はいないが
rustユーザーがlinuxにいちゃもんつけてると主張する人はいる不思議
334:デフォルトの名無しさん
21/04/27 01:41:47.11 Wan/QADt.net
来年は組み込みRust元年になるやで
335:デフォルトの名無しさん
21/04/27 02:20:03.39 +/hUQLiN.net
あわしろ氏もそう言ってますね。
336:デフォルトの名無しさん
21/04/27 02:20:38.76 GJuK6dTy.net
何で今年じゃないの？
337:デフォルトの名無しさん
21/04/27 02:36:39.16 lIgwswD1.net
panicのせいで実質組み込みでも死んじゃったな
linusやりすぎだぞ
338:デフォルトの名無しさん
21/04/27 02:51:16.77 53lThlBD.net
>>332
Linux カーネルで受け入れられないからと言って組み込みで panic が使えないわけじゃないでしょ。
339:デフォルトの名無しさん
21/04/27 08:06:21.79 C32SFGMy.net
>>325
URLﾘﾝｸ(play.rust-lang.org)
元ネタこれなんですが
min('a,'b)的な考え方だと確かにf3について納得できる気がしますが、今度はf1が通るのがわからなくなります
f1を&'a &'b Tの参照がひとつ外せて&'b Tと考え
f0は'b:'aなので&'b Tから&'a Tに変換可能と考えると
f2が通ってf3が通らないことが理解できない
rust難しい。。
340:デフォルトの名無しさん
21/04/27 08:11:26.79 Xxuu6Rq/.net
>>326
だから作るにあたって参考になる資料とか実装例はあるのかって話なんだが
OSを作るみたいな資料はあってもその多くはCとアセンブラを前提としているし
それを参考にしたらC流になってしまうだろ
341:デフォルトの名無しさん
21/04/27 08:43:32.76 W9X9APV9.net
実用的なOSとしてはこの辺かな。
URLﾘﾝｸ(github.com)
あとは研究論文レベルでは、Rustの所有権システムをOSの権限管理周りに使って堅牢なシステムを作ろう、みたいなのもある。
342:デフォルトの名無しさん
21/04/27 12:44:22.23 /+bIFNU8.net
こんなんCで書いてるのと変わらんだろ。。
URLﾘﾝｸ(github.com)
343:デフォルトの名無しさん
21/04/27 13:52:57.49 B18ZzSzj.net
>>337
インラインアセンブリでもRustを使うとコンパイル時に強力なチェックが！
あるわけないよな…Cでいいと思います
344:はちみつ餃子
21/04/27 14:21:05.00 gsHoUi4w.net
OS 全体の中でも低レイヤ寄りの部分はしょうがないでしょ。
どうせほとんどインラインアセンブリなら C でもいいが Rust で駄目という理由にもならんし。
345:デフォルトの名無しさん
21/04/27 15:07:33.38 V9b4VlmB.net
>>339
Rustは書き辛いし、生成されるコードや意味解釈に闇がある。
346:デフォルトの名無しさん
21/04/27 15:26:51.13 +CyfYLC3.net
言語の設計思想をOS全体に広げて実用的に成功した例ってあるの？
LispOSみたいなのは全部失敗してるじゃん
Cはもともとアセンブラで書かれてたOSを高級言語で書き直せるように
言語自体を後から設計したものだからね
Rustがシステム記述言語として使われたいなら、Linusに意向に100%従って
言語仕様をどんどん書き換えていかないとダメ絶対
347:デフォルトの名無しさん
21/04/27 16:09:23.12 sPb/VVK7.net
ここまでRedoxの話を避けているのはなぜ
348:デフォルトの名無しさん
21/04/27 17:15:40.85 MBTyAJrN.net
Redoxとか使ったことないし……
349:デフォルトの名無しさん
21/04/27 19:00:31.49 UNWScvKY.net
>>341
forth?
350:デフォルトの名無しさん
21/04/27 19:17:36.18 SeQzLHjb.net
forthとかなつかしいなオイ
351:デフォルトの名無しさん
21/04/27 20:00:34.98 B18ZzSzj.net
FORTH作者「FORTHには申し訳ないことをした…」
ホントだよ！
FORTHがきちんとケアされ続けた世界線を見てみたい
352:デフォルトの名無しさん
21/04/28 00:25:46.13 zZPOP3tR.net
forthって今も使われとるのだろか。。
353:デフォルトの名無しさん
21/04/28 01:56:40.25 RzWjm9zz.net
昔はＢＩＯＳ とか forth で書かれてたけど今はどうかなー
354:デフォルトの名無しさん
21/04/28 03:06:12.66 k8H8q1SE.net
Rustは配列に添え字アクセスする時、必ず境界チェックされるよね？
355:デフォルトの名無しさん
21/04/28 06:10:01.83 Er4sy6AA.net
言語設計とOSが一体ていうのがどのくらいまでを指すかにもよるけど
Smalltalk は元々は言語=OSみたいなシステムだったな
356:デフォルトの名無しさん
21/04/28 10:12:57.76 HN4XQcog.net
>>349
言語仕様的にチェックされるかという意味ならYes
357:デフォルトの名無しさん
21/04/28 10:51:18.82 EDIdYwla.net
>>351
ライブラリの実装ではチェックされるようなコードになっているが
最適化で消えるかも知れないので実行時に必ずしもチェックされるとは限らないという意味？
358:デフォルトの名無しさん
21/04/28 11:29:39.09 1OyY1L+6.net
コンパイル時に境界チェックを外せると確定してない限り最適化しようが境界チェックはやる
359:デフォルトの名無しさん
21/04/28 13:16:17.19 BfdKSrwu.net
例のLKML見直してて思ったけど
unsafeなコードetcが不変条件を破壊した場合に対する安全な対処法って今なんかあるのかな
360:デフォルトの名無しさん
21/04/28 13:47:19.78 3EuQZ3Ew.net
こんなとこじゃね
URLﾘﾝｸ(doc.rust-lang.org)
361:デフォルトの名無しさん
21/04/28 15:27:12.87 jQpDsyge.net
二重投稿になるかも知れませんが、[0; n] で、n要素のi32 型の配列という
意味になるようですが、n が実行時にしか決まらない変数でも大丈夫ですか？
その場合、データ領域はスタック領域から確保するのでしょうか。
362:デフォルトの名無しさん
21/04/28 18:08:50.70 HN4XQcog.net
>>356
まずはリファレンスを
URLﾘﾝｸ(doc.rust-lang.org)
363:デフォルトの名無しさん
21/04/28 18:22:21.07 t+PzYqgO.net
>>354
不変条件の種類によるけど最悪 undefined behavior になるから対処は無理じゃないかな
コンパイラの最適化レベル落とすとかで振る舞いを予測可能にすることは出来るのかも
364:デフォルトの名無しさん
21/04/28 19:36:40.90 jQpDsyge.net
>>357
でも、Box::new([0; n])と書いた場合には、nはコンパイル時に決まらない値
でもいいの？
365:デフォルトの名無しさん
21/04/28 20:41:55.42 m2UbhZH5.net
いいに決まってんだろハゲ！
366:デフォルトの名無しさん
21/04/28 20:43:40.06 XWuZH88T.net
Vec::with_capacity使えよ
367:デフォルトの名無しさん
21/04/28 21:18:06.47 EDIdYwla.net
試せば2秒で分かるんだから試しなよ
368:デフォルトの名無しさん
21/04/28 21:32:36.01 lX6x7Umv.net
２秒で試してみろや
369:デフォルトの名無しさん
21/04/28 21:34:25.75 lX6x7Umv.net
うまくいかなかったとしてほかに問題がないか状況を切り分け周辺を調査
誤りのない環境を整備
学習内容を保存し整理
単純な文法ひとつでも最低３０分
370:デフォルトの名無しさん
21/04/28 22:27:00.95 GVcFAhra.net
Rustの場合
｢2秒で試せる｣ || ｢試すしたら2秒でわかる｣
error: 意図が曖昧です
Cの場合
｢2秒で試せる｣
｢2秒で試してみろやカス｣
371:デフォルトの名無しさん
21/04/29 00:40:38.91 xah6OenV.net
Golangが難しかったのでRustにきました
よろしくおねがいします
372:デフォルトの名無しさん
21/04/29 00:53:02.27 90w9Shfm.net
ゴールデンウィークに釣りですか
373:デフォルトの名無しさん
21/04/29 12:40:02.43 K/HFYMcp.net
Animal から、C++ の継承のようなことをした構造体(?)を Dog とした時、
Box<T> a; で T を Animalのようなものにして、a には、実際には Dog
への参照を入れるようなことは出来ますか？
374:はちみつ餃子
21/04/29 13:12:17.47 x0Vd7BP9.net
>>368
dyn かな？
完全に一致する機能というわけではないけど、
Rust ではトレイトに dyn キーワードを付けると (C++ で言うところの) 抽象クラスのように機能する。
375:デフォルトの名無しさん
21/04/29 13:33:28.09 K/HFYMcp.net
>>369
URLﾘﾝｸ(stackoverflow.com)
↑には、Questionの人の書いたのももしかしたら動作するかも知れないけど
Answerの人に従えば、以下のようにするのが正しいのかな？
trait Function {
fn value(&self, arg: &[f64]) -> f64;
}
struct Add {}
struct Multiply {}
impl Function for Add {
fn value(&self, arg: &[f64]) -> f64 { arg[0] + arg[1] }
}
impl Function for Multiply {
fn value(&self, arg: &[f64]) -> f64 { arg[0] * arg[1] }
}
impl Add {
fn new() -> Add { Add {} }
fn new_boxed() -> Box<Add> { Box::new(Add::new()) }
}
impl Multiply {
fn new() -> Multiply { Multiply {} }
fn new_boxed() -> Box<Multiply> { Box::new(Multiply::new()) }
}
fn main() {
let x = vec![1.0, 2.0];
let funcs: Vec<Box<dyn Function>> = vec![Add::new_boxed(), Multiply::new_boxed())];
for f in funcs {
println!("{}", f.value(&x));
}
}
376:デフォルトの名無しさん
21/04/29 17:34:51.47 HuHtKfqb.net
C++でis-a関係の継承使うデータはRustだとenum使う方が単純になるケースもある
struct AnimalData { ... }
struct DogData { ... }
struct CatData { ... }
#[non_exhaustive]
enum Animal {
Dog (AnimalData, DogData),
Cat (AnimalData, CatData),
}
この方法にも色々欠点はあるけど（クレートの外で新しいAnimalを追加できないとか）
trait使う抽象化が大袈裟だと思ったら考えてみて
377:デフォルトの名無しさん
21/04/29 17:51:11.31 GXfM8nV1.net
>>370
継承とは違うけど
そのユースケースはfnかFn使えば十分じゃないの？
let functions: Vec<fn(f64, f64) -> f64> = vec![|x, y| x + y, |x, y| x * y];
for f in &functions {
println!("{}", f(1.0, 2.0));
}
378:デフォルトの名無しさん
21/04/30 01:35:27.25 7VhEvZ/Q.net
>>372
簡単な例として書いただけで、同じ表示結果を得ることが目的ではないので
そういうこととは趣旨が違う。
さまざまな種類の多態なオブジェクトを1つのリストの中に入れるということは
オブジェクト指向に置いて基本的な概念の一つで、Polymorphismの基本なので、
継承的なものを使わずに同じ結果を書けたとしてもそれは違う。
379:デフォルトの名無しさん
21/04/30 15:35:29.77 dTeJW22U.net
ポリモーフィズムを理解してないようなやつでもRustをはじめるようになったんだな
380:デフォルトの名無しさん
21/04/30 17:06:26.25 8uDUVNfy.net
c++と同じで難しくてランタイム速度最強てなところが厨を呼び寄せてる
381:デフォルトの名無しさん
21/04/30 18:24:08.88 K785SuXO.net
C++やってたら配列のインデックスアクセスが安全かどうかや
ディスパッチがスタティックかどうかを普通気にするよね
382:デフォルトの名無しさん
21/04/30 20:47:52.42 eR/nI2gV.net
グーグルやMSが「Rust」言語でOS開発、背景に国家による諜報活動の影＝日経 xTECH中田敦
背景に国家による諜報活動の影っていう根拠が１つも示されてないんだけど、こいつの言ってることマジなん？
それとも日経新聞のおなじみの「飛ばし」によるクリック集め？
383:デフォルトの名無しさん
21/04/30 21:05:00.75 MgEdsK0p.net
GAFAMって言いたいだけ
384:デフォルトの名無しさん
21/04/30 21:27:01.84 8uDUVNfy.net
マイクロソフトがwindows書くのにc++使って後悔した話も知らん層が今も同じようなことやろうとしてんだろ。。
バカは歴史に学ばない。
385:デフォルトの名無しさん
21/05/01 00:25:31.33 6VZJr73m.net
これ見てたら、いきなり日本語で「ネコ」って出てきてびっくりした
URLﾘﾝｸ(www.programming-idioms.org)
実は、お前らの中の誰かが書いてんのか？
386:デフォルトの名無しさん
21/05/01 05:47:22.98 5xLRGYfU.net
>>380
URLﾘﾝｸ(www.publickey1.jp)
今、プログラムやる若い層じゃアニメとアニメに出てくる簡単な日本語は基礎教養だぞ
github見たらアニメキャラアイコンだらけだ
387:デフォルトの名無しさん
21/05/01 08:00:51.92 GEnkdmRT.net
NANI
388:デフォルトの名無しさん
21/05/01 17:02:13.98 1WejqaZh.net
>>379
>マイクロソフトがwindows書くのにc++使って後悔した話
興味有るので詳しく :
389:
21/05/01 17:21:37.61 m+tkSw04.net
>>379
流出したソースを見る限り、MS は C で Windows を書いていたようですよ‥‥
390:デフォルトの名無しさん
21/05/01 17:53:57.44 /Wzn7OVr.net
そういえば初期WindowsのWindow管理のサンプルコード見た記憶がある
ツリーリンクリストが構造体に埋め込む形で自作されてた
391:デフォルトの名無しさん
21/05/01 17:54:25.77 /Wzn7OVr.net
コードの８割方コメントだった
392:デフォルトの名無しさん
21/05/02 09:31:00.53 /RYlgP4n.net
The Windows Research Kernel AKA WRK
URLﾘﾝｸ(github.com)
393:デフォルトの名無しさん
21/05/02 09:42:02.70 3kB7D+rP.net
9割がCか
394:デフォルトの名無しさん
21/05/02 09:51:42.31 3kB7D+rP.net
まあLinuxもCと一部アセンブラだから似たようなものか
395:デフォルトの名無しさん
21/05/02 12:27:53.91 Jc9e5ibu.net
当時の言語状況からして他に選択肢なんかなかったと思うがねぇ。
他の言語選択してたら駆逐されてた可能性すらある。
396:デフォルトの名無しさん
21/05/02 12:37:35.62 anCj3LhS.net
NT kernelが開発されたのが1990年代か
C++も既にあったがまだ浸透してなかったかな
397:デフォルトの名無しさん
21/05/02 13:45:15.23 c1rmI49h.net
チュートリアルやってたらトレートオブジェクトってのの説明が意味不明級だったぜ
URLﾘﾝｸ(tourofrust.com)
なんじゃこりゃ
398:デフォルトの名無しさん
21/05/02 14:35:17.11 n4dQrb8u.net
>>392
Javaの知識があれば
trait object： interfaceとして渡されたオブジェクト
という感じで説明できるけど何か使い慣れた言語はあるかね
399:デフォルトの名無しさん
21/05/02 15:05:16.82 c1rmI49h.net
>>393
もしかしてExistential Container(和訳不明)が独立のオブジェクトとして括り出さている感じですか？
なおC#が一番使い慣れているのですが、この範囲ではJavaと大きく違わなさそうでしょうか・・・・
400:デフォルトの名無しさん
21/05/02 15:36:14.52 hSgvj4Ff.net
>>392
The Bookの該当箇所を読むのを勧める
Java/C#のインターフェースと基本的には同じだけど違う部分もある
URLﾘﾝｸ(doc.rust-lang.org)
その少し後に出てくるBoxのコードに出てくる
`animals: Vec<Box<dyn NoiseMaker>>`の
Box<dyn NoiseMaker>がTrait Object
Trait Objectは動的サイズの型なので&NoiseMakerやBox<dyn NoiseMaker>のようにポインタの形になる
そのチュートリアルは前後のページとどう関係があるのかについて説明がほぼないのでわかりにくいかもね
401:はちみつ餃子
21/05/02 15:50:22.98 VAfyzxcR.net
他の言語の概念と対応付けるよりはそれ自体として理解したほうがいいのは確かだと思う。
(理解できずに行き詰まるくらいなら雑な理解でも一旦前に進んだほうがいいかもしれんけど。)
言語機能ってひとつだけを取り出して使えるものじゃなくて、他の言語機能との連携の中で活きてくるものだから
個別の言語機能を他言語の言語機能と対応付けて理解しても綺麗に繋がらない感じがする。
402:デフォルトの名無しさん
21/05/02 15:58:09.22 TmCNx2ML.net
URLﾘﾝｸ(doc.rust-lang.org)
こっちじゃ`dyn Trait`のことをtrait objectと呼んでいるようだけど
というか俺はこれだと思ってた
Traitを実装する具体型の値のアドレスと、その型に対するTrait実装のvtableの組
403:デフォルトの名無しさん
21/05/02 16:04:49.31 n4dQrb8u.net
>>394
C#はあまり詳しくないけど、例えばListのAddRange関数の引数の(IEnumerable collection)が近いかな
AddRangeにはIEnumerableを実装してればどんな型でも渡せるはず（ArrayList、HashSet, etc）
これをAddRangeの視点で見ると、渡されたcollectionが実際に何の型かは分からないけど
IEnumerable（interface≒trait）を実装してることは分かってるから
そのGetEnumeratorを呼んでIEnumeratorを受け取ってそこから取り出せる要素を全部追加すれば
目的の動作は果たせることになる
このAddRangeの引数のcollectionがIEnumerableトレイトを実装したtrait objectって感じ
404:デフォルトの名無しさん
21/05/02 17:25:27.83 hSgvj4Ff.net
>>397
正確に言うとリファレンスに書いてる通りdyn Trait型のオブジェクトがTrait Object
&dyn TraitやBox<dyn Trait>はTrait Objectを指してるfat pointer
でも実用上は&dyn TraitやBox<dyn Trait>のfat pointerのこと自体を
Trait Objectというものとして理解したほうがわかりやすいので
The Bookや他の解説書でも区別してないのが多い
405:デフォルトの名無しさん
21/05/03 09:09:00.34 AyvebyYK.net
>>76
Visual Rust#やろ
406:デフォルトの名無しさん
21/05/03 11:04:52.91 L2uysNOu.net
URLﾘﾝｸ(marketplace.visualstudio.com)
407:デフォルトの名無しさん
21/05/03 15:28:19.67 lWPqbdGD.net
囲い込んでブラックボックス強要するあたりはMSと相性いいかもな
408:デフォルトの名無しさん
21/05/04 15:41:01.40 6lvPuDrb.net
facebookも財団に参加したのか
appleも時間の問題かな
intelとかのCPUメーカーにも参加して欲しい所だが
409:デフォルトの名無しさん
21/05/04 17:15:37.01 lMvsmKDJ.net
CPUメーカーが参加するとどういうことが嬉しいの？
LLVMなら分かるんだけど
410:デフォルトの名無しさん
21/05/04 20:03:06.80 6lvPuDrb.net
まあ元intelのエンジニアも開発に参加しとるけどね
411:デフォルトの名無しさん
21/05/04 20:33:44
412:.63 ID:PCq3WtR4.net
413:デフォルトの名無しさん
21/05/04 21:04:23.81 mgj/rIpW.net
rustが低レイヤーの開発言語としては覇権取りそうね
今から勉強しとくのが良さそう
414:デフォルトの名無しさん
21/05/04 22:09:05.61 mvlmOZ0b.net
低レイヤーの仕事をしたことないってのがよくわかるわ。
415:デフォルトの名無しさん
21/05/05 00:03:56.29 UOumGkwv.net
>>405
エンジニア個々人が参加するのは普通にあると思うんだけど
企業として支援することにどんなうまみがあるのかなと思って
ただ改めて思うとintelもソフトウェアたくさん出しててrust使う旨みはあるから支援する意味はありそうだね
416:デフォルトの名無しさん
21/05/05 01:46:02.42 E1emjEBd.net
SHやArmのRustコンパイラをメーカーが出たらｶﾞﾁ
417:はちみつ餃子
21/05/05 03:09:13.31 o0iQ7lyN.net
うまみっていうか、それが上手くいくかどうかなんて事前にはわからん。
ほどほどに有用そうなものに支援してたらどれかひとつくらいはいい感じって程度の話だろ。
418:デフォルトの名無しさん
21/05/05 05:31:11.89 rumk0idO.net
協力し合うと同時にあまり勝手しないように牽制するのも目的なので
419:デフォルトの名無しさん
21/05/05 12:35:13.44 UNdhfIGe.net
どうも頭の悪い輩が多いなと思ってたけど、
この言語、ある程度まではスクリプト的に書けるからなんだな。。
なんとなくおかしなこと言ってる奴の感覚がわかってきたわ。
420:デフォルトの名無しさん
21/05/05 13:37:38.31 ZpSbA1Y5.net
>>413
> この言語、ある程度まではスクリプト的に書けるからなんだな。。
短く簡単に書けるようにするのはRustの課題の一つだと思ってるので、どういう観点から「スクリプト的に書ける」とおっしゃるのか伺いたいです
よく比較に上がるC++よりはよっぽど記述量多くなるよね？
421:デフォルトの名無しさん
21/05/05 14:30:15.37 UNdhfIGe.net
そりゃautoなんかを使いまくった最近のスクリプト厨のc++ならそうだろうけれど、
普通に仕事で読むc++コードはそういう感じではないからね。
てかc++と一口に言っても年代で全く別言語だわ。
そういうスクリプト的な書き方をした場合、rustのがc++より快適に感じるのはまあわかるよ。
問題もrustのが少なく感じる。そういう書き方だけしてる場合はね。
422:デフォルトの名無しさん
21/05/05 14:59:14.54 ZpSbA1Y5.net
炎上学習法かってくらい何も理解してない感じでワロス
423:デフォルトの名無しさん
21/05/05 15:13:12.13 UOumGkwv.net
autoと動的型付けの区別が付いていない...?
424:デフォルトの名無しさん
21/05/05 15:19:43.76 nBZStdai.net
型再構築なんてむしろ厳格に型付けされた言語から生まれたんだが
425:デフォルトの名無しさん
21/05/05 15:21:51.15 2WIXJ/st.net
C#でvarキーワードが導入された時も
基本型の変数にvar使うのやめましょうみたいな規約を
意味不明な根拠で良い規約と信じて導入しようとする
おかしな人達がそこら中に居た
後にEffective C#かそこらの書籍で
ローカル変数はvar使えと明確に書かれるようになって
老害ザマァと思ったものだ
426:デフォルトの名無しさん
21/05/05 15:46:10.02 sMGymnD4.net
正義が世俗の愚劣さに屈した
427:はちみつ餃子
21/05/05 15:47:19.58 o0iQ7lyN.net
ローカル変数の場合は型がすぐ隣に書いてあるような状況だろうからな。
428:デフォルトの名無しさん
21/05/05 16:17:27.41 UNdhfIGe.net
ほらね。
好き勝手な自分流でコード書いてるだけで人のコードを読んでないのが丸わかりなコメントしてても
全く気づかないバカしかいない。
429:デフォルトの名無しさん
21/05/05 16:25:26.72 GNJam4rN.net
>>421
ようするに型情報を二重に書いてるようなものだよな
情報の多重化であり
小さなDRY�
430:ｴ則違反 こんな簡単な理屈を理解出来ない奴が不思議
431:デフォルトの名無しさん
21/05/05 16:30:24.49 sMGymnD4.net
書かれておらずメソッドで戻り値を取得するような場合
C#もJavaも型で呼び出し先が変わる仕組みなので
意図せずに処理の流れまで変わってしまう
432:デフォルトの名無しさん
21/05/05 16:44:03.35 GNJam4rN.net
>>424
お前は日本語勉強しろよ
普通に読解不能なんだよ
必要な所には型を書く
当たり前
不要な所に書いてると
「何故書いてるのだろうか？
何か理由を見落としてるだろうか？」
と注意深いプログラマを考えさせるのでエネルギーの無駄
433:
21/05/05 16:50:12.99 tRoHSHAj.net
>>416
＞炎上学習法
懐かしい言葉ですね‥‥
434:デフォルトの名無しさん
21/05/05 16:59:13.24 sMGymnD4.net
>>425
varにするようになったら全部varにするだろ？
435:デフォルトの名無しさん
21/05/05 17:40:56.63 iUhohRzs.net
>>416
相手してるお前も同罪やぞ
すぐ見分けつくだろ
436:デフォルトの名無しさん
21/05/05 18:09:53.05 UOumGkwv.net
VSCode + rust-analyzer だとletやメソッドチェーンのところに型が表示されるし
今時の開発環境使っていればローカル変数の型がぱっと見で分からなくて苦労することは少ないのでは
437:デフォルトの名無しさん
21/05/05 18:14:24.50 GNJam4rN.net
>>427
何を言っとるんだお前は？
右辺値と同じ型で「困る」時は型を書くに決まってるだろ
下手するとvarの仕様も理解せずに混乱した事を書いてんじゃないだろうな
438:デフォルトの名無しさん
21/05/05 18:51:20.46 cJbqSzge.net
ゲェーQZ居着いてんのかよこのスレ
バカなくせに出しゃばりでウザいからC++スレから出てくんなよ
439:デフォルトの名無しさん
21/05/05 19:01:51.22 sMGymnD4.net
>>430
後から右辺値の型が変わったら気が付かないうちに影響が波及するじゃん
440:デフォルトの名無しさん
21/05/05 19:41:05.57 E1emjEBd.net
var xの型が何であるかはxの初期化のときただ一度きりの右辺の型で決まるんｼﾞｬﾈｰﾉ
だとしたら後から右辺値の型が変わることに関して
varの導入で傷口が広がったことにはならない
441:デフォルトの名無しさん
21/05/05 19:44:32.97 E1emjEBd.net
二回目以降の右辺値はxに対する代入でしかありえない
それらはxに対して（暗黙の型変換等を経て）代入可能ならコンパイルが通るし、
代入不可能ならエラーになる。
xの初期化時にvarを使おうが使うまいが（明示的に型を書こうが）変わらない話
442:デフォルトの名無しさん
21/05/05 20:38:12.35 UOumGkwv.net
せめてletの話をしろよ
443:デフォルトの名無しさん
21/05/05 20:48:36.67 vgXZGrp9.net
RustのletはJS由来？ それともHaskell？
444:デフォルトの名無しさん
21/05/05 21:09:59.09 1EwqoC8k.net
JavaScriptにもletあるけど語源調べたら普通に英単語のletで短縮形ってわけじゃないらしい
445:デフォルトの名無しさん
21/05/05 21:24:20.68 ra+BilqN.net
BASICの時代からletはあったけどな
446:デフォルトの名無しさん
21/05/05 21:31:43.51 ZsCzZm1J.net
letはlisp系から始まったイメージ。
447:デフォルトの名無しさん
21/05/05 22:26:24.94 vWJ975z5.net
RustのletはML系由来だろ
448:デフォルトの名無しさん
21/05/05 22:44:48.04 UOumGkwv.net
最初のrustcはocamlで書かれてたくらいだしML系の影響は色濃そう
449:
21/05/05 22:49:49.94 tRoHSHAj.net
>>431
ｽﾚﾘﾝｸ(tech板:839番)
450:デフォルトの名無しさん
21/05/06 01:02:12.67 SpjdL+PT.net
let mut にするか var にするかの決定で、
目立たないけどRustに貢献した人という記事が最近書かれたので貼っとく
URLﾘﾝｸ(brson.github.io)
451:デフォルトの名無しさん
21/05/06 01:05:25.16 ut0g6JOd.net
>>443
3行でまとめて
452:デフォルトの名無しさん
21/05/06 01:35:02.38 SpjdL+PT.net
デイブ・ハーマン（Dave Herman）というECMAScript委員会のMozillaの代表者の人がいました。
リポジトリ上のコミットログでは目立ちませんが、彼の好みがRustチームの好みを作り、チームの組織と維持に重要な役割を果たしていました。
彼はチームの決定をほとんど穏やかに受け入れていましたが、let mut と var のどちらにするかについては var を使うというチームの決定に同意しませんでした。
453:デフォルトの名無しさん
21/05/06 01:36:11.91 V2I8vwdu.net
>>421
でも、
BYTE c = 'a';
と
let c = 'a';
では間違い易さが違う。後者は、int か BYTE か SBYTE か分からない。
454:デフォルトの名無しさん
21/05/06 01:37:37.69 V2I8vwdu.net
Rustだと、明示するには、
let c:i8 = 'a';
とキータイプが多くなってしまうな。
455:デフォルトの名無しさん
21/05/06 01:40:47.77 V2I8vwdu.net
例えばの話、演算子も優先順位が決まっているので、
if ( (a >= 5 && a <= 10) || (b>=10 && b <=20) ) {・・・}
見たいな条件も、優先順位の括弧を省略できるかも知れないが、勘違いや
記憶違いを防ぐために書いた方がいいと言われている。
int c = 'a';
char c ='a';
auto c = 'a';
ではやはり、autoはバグの原因になりそう。
456:デフォルトの名無しさん
21/05/06 01:47:50.96 V2I8vwdu.net
それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
float a = 1.0f;
float b = a + 5.0f;
みたいなものも、もし、
auto a = 1.0f;
auto b = a + 5.0f;
と書くと b は、double 型になってしまうかもしれないが、テストしても
間違いに気づかず、僅かに速度低下やメモリーを多く食ってしまう
かもしれない。また、思想にもよるが、1.0f などと書かずに
float a = 1;
float b = 5;
と書きたい人も居ると思う。これの方が、後から double 型に変えたときに
右辺を訂正する必要がないメリットもある。
457:デフォルトの名無しさん
21/05/06 03:19:29.71 EVf7RH7G.net
>>446
rustの文字リテラルはu8でもi8でもなくてcharな
それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと
タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない
458:デフォルトの名無しさん
21/05/06 03:21:51.36 EVf7RH7G.net
誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な
459:デフォルトの名無しさん
21/05/06 06:46:11.97 AMAuzv83.net
>>443
こういうのいいな
460:デフォルトの名無しさん
21/05/06 10:08:34.61 VcsxCBNr.net
>>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに
461:デフォルトの名無しさん
21/05/06 10:15:22.90 lmEaR3VD.net
>>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は（珍しく）反対したけど最終的には受け入れた
462:デフォルトの名無しさん
21/05/06 11:35:13.23 hCHdFqbq.net
つまり暗黙の型変換は癌
463:デフォルトの名無しさん
21/05/06 11:48:56.26 f
464:owE0ZYM.net
465:デフォルトの名無しさん
21/05/06 11:52:26.38 a37uwZNi.net
いないいない
466:デフォルトの名無しさん
21/05/06 14:35:25.59 SpjdL+PT.net
>>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな
467:デフォルトの名無しさん
21/05/06 16:00:35.75 acc3YL8w.net
タイプ数で優劣を決めようとするアホとは次元が違うな
468:デフォルトの名無しさん
21/05/06 16:31:20.99 q/dBsf9f.net
タイプ数は少ない方が問答無用で良い
469:デフォルトの名無しさん
21/05/06 17:13:47.97 EVf7RH7G.net
fn, ret, cont, break の時代に回帰するか
470:デフォルトの名無しさん
21/05/06 17:27:07.40 ut0g6JOd.net
タイプ数は少ない
って基本型が少ない言語が好みなのかと思った
471:デフォルトの名無しさん
21/05/06 19:28:16.24 fowE0ZYM.net
<?rust
println!("hello rust!!");
?>
472:デフォルトの名無しさん
21/05/06 21:17:13.93 O03dxxkK.net
>>448
型を明示したってバグるくせによく言うのぜ
473:デフォルトの名無しさん
21/05/06 22:42:35.79 pupGSg3O.net
タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え
474:デフォルトの名無しさん
21/05/06 23:22:18.38 fowE0ZYM.net
Rust ～地図にない場所～
475:デフォルトの名無しさん
21/05/07 03:50:05.38 vAByX/Kb.net
>>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。
476:デフォルトの名無しさん
21/05/07 07:04:16.43 aU3MjDw9.net
>>467
intが32bitだといつから錯覚していた？
477:デフォルトの名無しさん
21/05/07 08:21:08.42 Dsa6ajo4.net
Announcing Rust for Windows v0.9
URLﾘﾝｸ(blogs.windows.com)
478:デフォルトの名無しさん
21/05/07 09:19:02.07 iG4irUX1.net
言ってる側から落とし穴に嵌っててワロタ
479:デフォルトの名無しさん
21/05/07 10:35:21.40 8IfDDxiK.net
let a = 5_i32;
型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ
・・なに？
aがi32だと明示してバグを軽減したいじゃと？
それなら行を分けるのじゃ
１行にまとめるとせっかくの明示が埋もれてしまうからの
let a: i32; // この行の存在は大きいぞい
a = 5_i32;
480:デフォルトの名無しさん
21/05/07 12:08:53.04 B2UdQUpV.net
>>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。
481:デフォルトの名無しさん
21/05/07 12:20:12.52 B2UdQUpV.net
>>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。
482:デフォルトの名無しさん
21/05/07 12:24:00.34 w+YL5YRG.net
>>472
int32_tな
483:デフォルトの名無しさん
21/05/07 12:51:05.27 B2UdQUpV.net
>>474
typedef int int32;
typedef int i32;
とすればよいだけ。
484:デフォルトの名無しさん
21/05/07 12:57:04.52 w+YL5YRG.net
>>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど？
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして？
485:デフォルトの名無しさん
21/05/07 13:31:50.44 B2UdQUpV.net
>>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。
486:デフォルトの名無しさん
21/05/07 13:40:18.27 8gopO5Ce.net
どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感
487:デフォルトの名無しさん
21/05/07 13:42:32.36 B2UdQUpV.net
というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。
488:デフォルトの名無しさん
21/05/07 13:45:35.27 eN8Lkrsa.net
何を議論してるのか全然分からん
489:デフォルトの名無しさん
21/05/07 14:02:25.02 SIz+0gIF.net
1レス目で即NG
相手してるやつも同じカテゴリなので即NG
490:はちみつ餃子
21/05/07 14:03:01.68 xLSEaA6V.net
議論なんかするつもりがないんだろう。
491:デフォルトの名無しさん
21/05/07 14:40:46.39 r6L15P9a.net
>>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。
誰がどこでそんな話をしたのか
ログ辿っても全然分からない件
ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな
これ突っ込んだら
どんなガイジレスを返すのか興味津々
>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ
492:デフォルトの名無しさん
21/05/07 14:57:30.94 DUMB7Vls.net
メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか？
GUI使いたいんですが長いものにまかれたいので
493:はちみつ餃子
21/05/07 15:02:55.52 xLSEaA6V.net
>>484
プラットフォーム (OS) によって違うんじゃない？
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。
494:デフォルトの名無しさん
21/05/07 15:53:14.60 B2UdQUpV.net
>>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。
495:デフォルトの名無しさん
21/05/07 16:08:00.06 r6L15P9a.net
>>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ
496:デフォルトの名無しさん
21/05/07 17:04:02.49 +x2jPaur.net
メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う
497:デフォルトの名無しさん
21/05/07 17:16:13.01 8gopO5Ce.net
>>488
rustでLinuxのドライバー書く話？
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで
498:デフォルトの名無しさん
21/05/07 17:22:12.18 r6L15P9a.net
>>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど
499:はちみつ餃子
21/05/07 18:25:34.58 xLSEaA6V.net
>>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。
カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。
500:デフォルトの名無しさん
21/05/07 18:53:57.67 XbWp/RIC.net
割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ
501:デフォルトの名無しさん
21/05/07 19:12:04.63 RYgnWswQ.net
>>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。
502:デフォルトの名無しさん
21/05/07 19:35:24.51 FlZ9PpDj.net
差し当たりRustの言語を広く浅く学習したいのですが、「実践Rustプログラミング入門」の言語部分(100ページ程度)が分量が少なめで気になっています
この本で大きく抜けている文法や機能ってありますか？
503:デフォルトの名無しさん
21/05/07 20:06:32.24 xz5IWUMT.net
>>494
The Bookと比べれば一目瞭然
504:デフォルトの名無しさん
21/05/07 20:11:06.98 8H8V34/d.net
>>493
サーバーOSのほうがクライアントOSよりクラッシュには寛容だぞ
サーバー側の開発したことないのかな？
505:デフォルトの名無しさん
21/05/07 20:22:58.56 fmyiQrUP.net
>>496
最近は仮想化＆分散で寛容になっているの？
506:デフォルトの名無しさん
21/05/07 21:23:40.41 EDSX1EuR.net
>>494
最近の本だからasyncまであるし、そんなに大きな抜けはないかな
広く浅くならまぁいいんじゃないかと
もし細かい部分が気になったらthe bookで補完すればいい
507:デフォルトの名無しさん
21/05/07 21:36:25.19 7aFGtcIv.net
>>497
むしろchaos engineeringで積極的に落とす