23/05/07 15:29:50.80 ms6+oRxa.net
自分は触れたくないがpythonって存在は面白い
c++やrustには移れないのにpythonならできるって人が多い
今後c++やrustの研究が進んで実行速度が1%上がるとかそんなレベル
乾いたぞうきんを絞ってる
それだったらpythonをjava並みに引き上げるほうが社会的意義があると思う
pythonの有名ライブラリはc++で書かれてチューンされて実行速度は速い
個人が各部分のコードが遅くてもライブラリが速いならこれで十分
でもそれがc++ユーザーに反映されて利用が進んでいるとは言えない
一般の研究で利用はpythonに軸足が移ってる
今後も進むだろうし
201:デフォルトの名無しさん
23/05/07 15:33:01.77 zx4D7i6q.net
いや、どうみてもPython（PyPy3）書いてるやつらはヘタだな
C++のやつらと同じ程度の頭脳なら言語そのものの早さはともかく分布の形状が同じにならないとおかしい
Pythonだとベストのアルゴリズムを選べないんだろうか？
2500msまで行ってるのはC++しか無いがおそらくはタイムオーバーで失敗したやつもいる
この課題をクリアできたやつの統計だな
クリアできなかった人数もやっぱりC++とPythonが多いと思われる
単に利用者が多いからな
202:デフォルトの名無しさん
23/05/07 15:36:56.31 zx4D7i6q.net
頭脳程度が同じだとすればPythonだと10000ms程度で解けるような尾の方が足きりされてるから分布がそう見えるだけなのか？
すると分布の形状はC++とは相似で、pythonではそれが拡大されただけになる
203:デフォルトの名無しさん
23/05/07 15:39:50.70 ms6+oRxa.net
だから知能レベルが低くてコーディングが下手な人間が書いても成果が残せるんならそっちの言語に注視したほうがいい
ある意味優秀だからさ
たまにライブラリレベルで回答できる問題もあるし正規表現で解決できる問題もある
優劣と言うより実現できるかどうかの世界
204:デフォルトの名無しさん
23/05/07 15:41:53.17 zx4D7i6q.net
とするとC++とPythonの下位は全く同じアルゴリズムを使っているが、
C++の言語性能のおかげで2500msに収まっている
考えてることが同じ人間でそう変わるわけもない
205:デフォルトの名無しさん
23/05/07 15:43:48.79 /r7DBuOd.net
まともにプログラミングができる人ならばC++かRustもやるだろうしな
高速さと省メモリで他の言語とはまるで違う
このスレになぜかJavaのほうが速いと主張してる一匹いるが
206:デフォルトの名無しさん
23/05/07 15:46:07.10 /r7DBuOd.net
効率の良いプログラムを書けない人はAI代替でいいから不要となるんじゃないか
C++とRustだけが残りそうだ
207:デフォルトの名無しさん
23/05/07 15:47:17.20 ms6+oRxa.net
e問題を見れば分かるけどおそらく出題内容をベタにそのままプログラムすると遅くなる
c++の人たちはそんなことはしてないと思う
208:デフォルトの名無しさん
23/05/07 15:48:14.10 ms6+oRxa.net
いいすぎかな
実際自分は解いてないで雰囲気で言ってるだけだから的外れかもしれない
209:デフォルトの名無しさん
23/05/07 15:57:11.39 zx4D7i6q.net
後は手元でのコンパイル時間だろうか
gccとrustcでせいぜい100行200行のコード、コンパイル時間に差が出るとも思えないが
100倍も違ったらさすがに競技プログラミングでは忌避されるがそうじゃあないでしょう
そして書いてすぐ試せるとなるとpythonとかになる
にも関わらずRuby利用者がいないのは悲惨としか言いようがない
210:デフォルトの名無しさん
23/05/07 16:01:14.86 0+o01IGu.net
競プロに限らず無駄な効率悪いプログラムを書くプログラマーが溢れてる
そいつらで十分な分野はAIで置き換わるのたろう
ちゃんと考えて効率良いプログラムを書けるプログラマーならC++でもRustでも会得すぐだしな
211:デフォルトの名無しさん
23/05/07 16:03:17.49 ms6+oRxa.net
pythonは有名ライブラリ内でavx512使ってたりする
コードが寄贈されたりしてる
212:デフォルトの名無しさん
23/05/07 16:20:26.96 zx4D7i6q.net
あとはCargoと競技プログラミングの相性だろうか
213:デフォルトの名無しさん
23/05/07 17:00:28.41 ZuSoPChd.net
連休最終日だというのにお前らは
214:デフォルトの名無しさん
23/05/07 17:27:29.15 IEgposGn.net
>>206
効率の良いプログラムもAIが書いてくれるようになる
215:デフォルトの名無しさん
23/05/07 17:44:09.69 eOzMHQ5G.net
>>214
現在のAIの方式だとそれは無理だな
論理の理解がなく例えば素数すら列挙する以外に理解できない
足し算ですら桁が大きくなると間違える
抜本的な大発明が将来起きない限り見込みがないだろう
216:デフォルトの名無しさん
23/05/07 18:06:36.61 +pQ1lZnP.net
>>131 みれば、平均したらRustのほうがC++より速いだろ
それどころか、平均したらC++はPythonにも負けてそうだぞ
217:デフォルトの名無しさん
23/05/07 18:07:20.74 +pQ1lZnP.net
Pythonクソ速いな
C++より速いな
218:デフォルトの名無しさん
23/05/07 18:10:02.13 TRA1GHWk.net
boxプロットも読めない奴がいるなw
219:デフォルトの名無しさん
23/05/07 18:11:19.92 +pQ1lZnP.net
んなもん読まんでええのや
220:デフォルトの名無しさん
23/05/07 18:31:40.13 N703An5k.net
>>215
AtCoderの問題を解くような処理がプログラミングにおいて最もAIを活用できる分野だよ
広く知られたアルゴリズムの最適化なんてお手のもの
221:デフォルトの名無しさん
23/05/07 18:36:12.26 eOzMHQ5G.net
>>220
競プロに興味はない
そんな話はしていない
222:デフォルトの名無しさん
23/05/07 18:42:35.09 +pQ1lZnP.net
C++がウェブ界に進軍したら、お前らみんな無職だぞ
C++のパワーをまざまざと見せつけられ、しょんベンチビルと思うわ
223:デフォルトの名無しさん
23/05/07 18:43:59.40 +pQ1lZnP.net
それにしてもPython速いな
中にRust入ってるのと違うやろな
224:デフォルトの名無しさん
23/05/07 20:06:09.85 IEgposGn.net
>>215
AIが理解できなくてもパターンみたいに学習するからできちゃうんじゃん
突飛な想像力が必要なのは無理だろうけど
225:デフォルトの名無しさん
23/05/07 20:18:49.70 mxXhCe04.net
工夫すれば１行分（＋電球とブロックの位置）の記憶だけで解けるのか
H,Wが1500以下でメモリ制限1024MBだとH×Wの確保も許容範囲だからそこで差がつきそう
解答者全体のレベルがよく分からないけどPythonにもガチ勢がいただけでしょ
226:デフォルトの名無しさん
23/05/07 20:20:12.61 eOzMHQ5G.net
>>224
パターンはその通りで得意
しかしそこからの帰納法が無理
例えば素数を多数知っているがそこから素数の性質特徴を理解するのは無理
ただし学習として素数の性質特徴はわかるしプログラムも多数転がってるのでわかるだろう
でもそれじゃダメだ
未知のもの(初めてのもの)に対して出来ないといけない
227:デフォルトの名無しさん
23/05/07 20:42:06.12 IEgposGn.net
>>226
そういうことができるプログラマ以外いらなくなりそうだよね
228:◆QZaw55cn4c
23/05/07 21:21:38.60 MxFKzH70.net
>>226
素数に関して突っ込んでいえば、素数の定義と素数の性質＝すべての自然数は素数の積で一意に表現できる、との間には大きなギャップがあるのに、それがあまり意識されていないのが問題
229:デフォルトの名無しさん
23/05/07 21:25:03.91 /qC6ccnK.net
>>227
全く逆だよ
そういうことを差別化要素と捉えてるようなプログラマがいらなくなる
コモディティ化しやすい知識とそうでない知識の違い
230:デフォルトの名無しさん
23/05/07 21:34:18.83 IEgposGn.net
>>229
難しくてわかんない
もう少し優しく
231:デフォルトの名無しさん
23/05/07 22:10:30.80 HMVW7dad.net
バイアスがあった可能性を否定できない っていうんなら逆方向も否定できないだろうに、なんでこのおじいちゃんは片方にだけ肩入れするん？
不自然ですよ
232:デフォルトの名無しさん
23/05/08 00:59:11.95 abS4z/F4.net
最大の問題は rustの利用者が何でこんなに少ないかだな
ただ これには複案があって おそらくは C ++から 移ってきたやつらがrustをやってると思われる
すると rustの標榜する モットーにも合致すると思われる
233:デフォルトの名無しさん
23/05/08 01:13:16.38 abS4z/F4.net
もう出ている通りに この問題を最速で解く 機械語 は存在するので
あと疑うべきは 入出力のオーバーヘッドだけになる
メインのアルゴリズム やら ロジック やらが同じなら
遅くしている要因は 入出力だ
234:デフォルトの名無しさん
23/05/08 01:15:13.32 ddy6A8qL.net
>>232
しかし、SNSを見てると、好きな言語にRustを書いている人は、他の好きな言語と
して、JSやGo、Kotlinなどを挙げる傾向が強く、C++は全く書かれてない
ことが多い。
235:デフォルトの名無しさん
23/05/08 02:06:52.10 A57Tkf07.net
C++のほうが機能が多いので、使える人はC++を使うからだろ
236:デフォルトの名無しさん
23/05/08 02:33:43.51 ocGLFPvg.net
機能の差の比較は難しいが
言語自体で様々な安全保証をするRustの機能が本質的に大きいかな
237:デフォルトの名無しさん
23/05/08 02:37:25.24 A57Tkf07.net
C/C++の90%のコードが危険というような話は
9割が20年以上前に書かれているだけで
最近のマナーで書けば済む話では
238:デフォルトの名無しさん
23/05/08 03:00:18.94 ocGLFPvg.net
IT大手各社が揃って同じ判断をした
C++では無理なので新たなシステムからRustを採用
そしてRust Foundationを共同で立ち上げた
さらに既存のWindows、Linux、AndroidなどもRustの採用を開始
239:デフォルトの名無しさん
23/05/08 03:33:40.76 A57Tkf07.net
そんなこと言ったらJavaの採用も開始してるしC/C++なんか大昔から採用を開始してるだろ
240:デフォルトの名無しさん
23/05/08 03:48:41.01 42N5+bFw.net
非GC言語として絶対的な王道を確立したC++が存在するにも関わらず、
新たな部分からC++ではなくRustを採用し始めたことに重い意味があるのでしょう。
しかも競合ライバル同士が同じ判断をした点も非常に重い意味があるのでしょう。
そのため正しい判断をした可能性が極めて高いでしょう。
241:デフォルトの名無しさん
23/05/08 04:02:39.80 yn6KTAlC.net
C++は死ぬべきだけど、後釜がRustでいいかはわからんわ
コストかけて置き換えるなら最高の言語がいいしな
242:デフォルトの名無しさん
23/05/08 04:21:48.93 c35xMa4f.net
Rustの書きやすさは気に入ったね
次の言語はコンパイラが様々な保証をする点を押さえた上で、Rustが取り込めないような別の新たな画期的な機能を持たないといけない
他に芽が現状ないからこのままRustで進みそう
243:デフォルトの名無しさん
23/05/08 04:29:17.13 PP0yxCHU.net
この流れなら言える
cpp2を知らなかったなんて言えない
244:デフォルトの名無しさん
23/05/08 08:23:06.69 eWwLSdkD.net
実際のところ、将来的に最適化はAIがやるようになって、要件定義と検証だけ人間がやるようになるんだろ。
設計自動化の流れだわな。
そうなってくると実装を人間がやる状況は限定されて、言語もIDLみたいになってくるかと。土方コーダーは全滅だな。
まぁ、c++はCOBOLみたいに過去資産メンテに、Rustはpostscriptみたいにバックエンドで生き残る可能性はあるけど。
245:デフォルトの名無しさん
23/05/08 09:34:04.39 mYRj0CUt.net
>>244
AIにとっても機械語を直接吐くのは保守性が悪すぎる
一方で少なくとも当面は人間が検証できる既存のプログラミング言語になりそう
万が一の時の対応や問題把握のためにも既存の言語が良さそう
インフラは人間がある程度把握し続けないとAIに主導権を奪われかねない点でも同じ
使われる言語は自動的に色々と保証されるRustになるのかな
246:デフォルトの名無しさん
23/05/08 10:33:58.34 faKRd8TS.net
人命や経済損失に大きく関わるシステムは責任や論理的な信頼性の観点からAIに頼るのは無理そうだね。
247:デフォルトの名無しさん
23/05/08 10:45:11.11 iczXOFhv.net
AIはTDD（人間がテストコード書いてAIが実装コード書く）と相性いいかなって思ったけど
絶妙にテストケースだけパスするようなコード吐いてきそうで怖い
人間的な一般化パターンを学習すれば使えそうだけど現状だとコピペミキサーでしょ
248:デフォルトの名無しさん
23/05/08 11:29:16.24 Kh0HUP9F.net
AIがどうとか関係無いはずなんだが
Rustのここがダメ！みたいなことを書くと必死でレスしてくれる人がいるから無限に話を脱線させることができるんだね
249:デフォルトの名無しさん
23/05/08 11:46:17.60 PotcPEgC.net
.gitignore に Cargo.lock を入れてるのに
cargo publish すると Cargo.lock もうｐされる
github の方にはもちろんうｐされていない
cargo publish --allow-dirty は本気で要らないものまでうｐされるからこれはやってないのだが
250:デフォルトの名無しさん
23/05/08 12:11:03.58 Re0hEQKj.net
AIに書いてもらうプログラミング言語はC++かRustになるんだろうが、
C++でプログラムの本質でない部分の隙を残すよりも、
コンパイルが通れば静的にその部分が自動検証されるRustになるんだろうな
251:デフォルトの名無しさん
23/05/08 12:16:11.80 PotcPEgC.net
>>174
すばらC洞察
252:デフォルトの名無しさん
23/05/08 12:31:11.67 B7yn02Wa.net
>>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ
253:デフォルトの名無しさん
23/05/08 12:43:44.96 PotcPEgC.net
>>201
これは良いサンプル
URLﾘﾝｸ(www.youtube.com)
254:デフォルトの名無しさん
23/05/08 12:43:46.40 iczXOFhv.net
>>249
内部で呼ばれるcargo packageの仕様っぽいね
URLﾘﾝｸ(doc.rust-lang.org)
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな
255:デフォルトの名無しさん
23/05/08 12:48:52.30 PotcPEgC.net
>>228
全ての素数の積でπを造る公式あるな
256:デフォルトの名無しさん
23/05/08 12:50:45.02 PotcPEgC.net
>>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き
257:デフォルトの名無しさん
23/05/08 12:56:17.27 yn6KTAlC.net
Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？
258:デフォルトの名無しさん
23/05/08 12:57:11.50 PotcPEgC.net
thx!
259:デフォルトの名無しさん
23/05/08 13:48:29.03 imilCHLn.net
今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。
260:デフォルトの名無しさん
23/05/08 14:22:47.81 yn6KTAlC.net
>>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね
261:デフォルトの名無しさん
23/05/08 15:04:56.15 eTYn8zaL.net
>>245
AIにRustのコード吐かせる理由なんて無いよね
262:デフォルトの名無しさん
23/05/08 15:39:48.45 pZhRtbOb.net
Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので
263:デフォルトの名無しさん
23/05/08 15:42:47.04 QcAzVd3l.net
速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。
264:デフォルトの名無しさん
23/05/08 16:19:16.98 SySGd/wN.net
>>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな
265:デフォルトの名無しさん
23/05/08 16:35:56.27 x8c+D5IZ.net
>>263
llvmの方がgccより性能良くなった?
266:デフォルトの名無しさん
23/05/08 16:41:27.47 NDGne9Ur.net
>>265
12年前から既にclangの方が速いです:
URLﾘﾝｸ(stackoverflow.com)
267:デフォルトの名無しさん
23/05/08 17:24:13.85 dxF1xGv4.net
>>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し
機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい
268:デフォルトの名無しさん
23/05/08 18:43:10.50 A57Tkf07.net
>>266
その手の話は信用ならねえな
269:デフォルトの名無しさん
23/05/08 20:09:42.31 tptm3XCm.net
>>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？
270:デフォルトの名無しさん
23/05/08 22:23:28.00 Sk4xBlmq.net
>>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない
ちなウォーターフォールね
271:デフォルトの名無しさん
23/05/08 22:48:34.95 23L22zMg.net
そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない
272:デフォルトの名無しさん
23/05/09 02:35:37.18 roDNqhiB.net
公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ
273:デフォルトの名無しさん
23/05/09 02:55:17.89 oJhOeTc4.net
yank
274:デフォルトの名無しさん
23/05/09 03:40:24.06 LWOtm1Dy.net
>>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と 比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。
275:デフォルトの名無しさん
23/05/09 06:12:08.21 CM93Ewnl.net
そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな
276:デフォルトの名無しさん
23/05/09 07:51:20.97 roDNqhiB.net
yankしても消えないやん？
277:デフォルトの名無しさん
23/05/09 08:28:08.83 cNhnBb7C.net
いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ
278:デフォルトの名無しさん
23/05/09 09:22:12.89 E9TE6Urv.net
プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ
279:デフォルトの名無しさん
23/05/09 10:03:50.18 MyUREp4F.net
vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち
280:デフォルトの名無しさん
23/05/09 10:17:59.79 DWbeMcsH.net
とフィボナッチイテレータより高度なプログラムが書けない人が申しております
281:デフォルトの名無しさん
23/05/09 10:29:01.80 VcsuRebp.net
>>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ
282:デフォルトの名無しさん
23/05/09 11:12:55.99 MyUREp4F.net
>vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt
>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt
>まあClone回避パターンもありRustは完璧だ
doubt
よくこんな短文で嘘ばかりかけるな
283:デフォルトの名無しさん
23/05/09 11:27:29.07 5GLz9i7j.net
複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい
284:デフォルトの名無しさん
23/05/09 11:41:48.76 aPAF6NA5.net
オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん
285:デフォルトの名無しさん
23/05/09 12:08:20.62 By46q85D.net
オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ
286:デフォルトの名無しさん
23/05/09 12:19:41.76 DWbeMcsH.net
な、単発だろ
287:デフォルトの名無しさん
23/05/09 12:27:45.30 DWbeMcsH.net
プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい
288:デフォルトの名無しさん
23/05/09 13:50:33.38 TWnpopnf.net
>>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。
289:デフォルトの名無しさん
23/05/09 14:18:30.40 qRADqwfY.net
>>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利
290:デフォルトの名無しさん
23/05/09 14:27:49.18 TWnpopnf.net
>>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。
291:デフォルトの名無しさん
23/05/09 14:49:54.81 qRADqwfY.net
>>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る
292:デフォルトの名無しさん
23/05/09 15:08:56.17 oJhOeTc4.net
URLﾘﾝｸ(stackoverflow.com)
だいたいそんな感じなんだけど実際にはバグったせいで付けたり外したりしてしてます
293:デフォルトの名無しさん
23/05/09 15:10:24.05 TWnpopnf.net
>>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。
294:デフォルトの名無しさん
23/05/09 15:21:42.16 GHMOM/oZ.net
>>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね
295:デフォルトの名無しさん
23/05/09 16:23:47.59 oJhOeTc4.net
重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです
296:デフォルトの名無しさん
23/05/09 16:57:31.86 qRADqwfY.net
>>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる
Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い
297:デフォルトの名無しさん
23/05/09 17:04:50.38 9RO9lVT1.net
コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな
298:デフォルトの名無しさん
23/05/09 17:08:17.41 qRADqwfY.net
>>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする
299:デフォルトの名無しさん
23/05/09 17:09:31.38 oJhOeTc4.net
そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です
300:デフォルトの名無しさん
23/05/09 17:30:52.58 JrSVS9vw.net
Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど
301:デフォルトの名無しさん
23/05/09 17:33:18.67 d0WXtuj5.net
おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな
302:デフォルトの名無しさん
23/05/09 17:35:11.58 d0WXtuj5.net
普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ
303:デフォルトの名無しさん
23/05/09 17:49:39.63 d0WXtuj5.net
速度じゃないわな
実行時間だ
速度だと
c > c++ > rust
304:デフォルトの名無しさん
23/05/09 21:13:21.70 jpsGavbj.net
>>300
Rustは適当に書いたらコンパイル通らない。
305:デフォルトの名無しさん
23/05/09 21:36:53.43 Pc0KyjBY.net
いうて、C++でinline、constexprやらテンプレートメタとかで実行時の処理効率を上げまくったらRustじゃ敵わないと思うんだけど、、
Rustでも似たようなこと出来るんだっけ？
306:デフォルトの名無しさん
23/05/09 21:55:51.60 m/PdBmgz.net
>>305
できるよw
307:デフォルトの名無しさん
23/05/09 22:07:22.50 GHMOM/oZ.net
>>305
Rustもできるよ
そもそもRustのconstはコンパイル時定数でC++のconstexprのこと
Rustの手続きマクロはRustコードの構文解析を入出力としてコンパイル時に実行生成するためC++より強力だね
308:デフォルトの名無しさん
23/05/09 22:10:15.60 Pc0KyjBY.net
なるほどね
俺の全力のC++コードじゃRustには敵わないようだ
309:デフォルトの名無しさん
23/05/09 23:53:36.96 qRADqwfY.net
>>299
>>301
noalias指定で劇的に速くなる例はC言語でrestrict修飾の有無の解説ページが多数あって詳しい
restrict指定がないとnoalias最適化ができずにベクタ化されずに遅くなる例なども出ている
310:デフォルトの名無しさん
23/05/10 07:24:49.96 gVulLBUf.net
テキトーに書いてもコンパイルが通る言語に憧れるなあ
311:デフォルトの名無しさん
23/05/10 08:38:28.50 uLiToFDO.net
体感ではこうかな
c > rust > c++
312:デフォルトの名無しさん
23/05/10 08:59:49.54 yd4Msfz1.net
複雑なことを好き勝手に書けるのがC++だったけど、簡潔に書くことも求められるようになりそうだねえ
当初は複雑だったけど、やることが大体固まったものをrewriteするなら、
いまなら確かにrustがアツい 成果も目に見えると思う たぶんCでは力不足だしね
313:デフォルトの名無しさん
23/05/10 10:30:02.81 gGgNP0IP.net
>>308
全力のrustコードを書けばいい
314:デフォルトの名無しさん
23/05/10 12:47:47.75 of34847N.net
C++相談室part161、ﾜｯﾁｮｲ導入直前のスレ
ｽﾚﾘﾝｸ(tech板:343番)-381
ｽﾚﾘﾝｸ(tech板:481番)-650
C++相談室part162、ﾜｯﾁｮｲ導入直後
ｽﾚﾘﾝｸ(tech板)
"Rust" の検索結果: 1件
は～
315:デフォルトの名無しさん
23/05/10 12:48:26.46 usV3D88W.net
lintだけでもいいから、smart c++とか名前を付けてRustもどきの強制フォーマットを作って欲しいわ。
Rustそのものは要らん。
316:デフォルトの名無しさん
23/05/10 12:49:05.61 of34847N.net
Rust本スレもﾜｯﾁｮｲ無しのほうやめちまえばいいのにな
C++相談室はすんなり移行できてて羨ましい
317:デフォルトの名無しさん
23/05/10 13:11:50.30 dsu8fQGS.net
>>310
それならば静的型付けではない言語を選ぼう
ここは静的型付けのC++とRustのスレだからコンパイル時に可能な限りエラーを出す言語
>>315
その方向を求めるならばRustの方が優れているからC++にこだわる必要ないんじゃないかな
生産性の高いRustを使った方がメリット享受もたくさん
318:デフォルトの名無しさん
23/05/10 13:15:44.86 uLiToFDO.net
crates.io にうｐして docs.rs の comment cover が
中々 100% に到達しないんだが
どこの comment が足りないって簡単に教えてくれるツールは？
local で docker 使えば判るもんなの？
あと「未 comment」数を減らした(=100%に近付けた)はずなのに
逆に%下がるケースもあるみたいで良く判らん
319:デフォルトの名無しさん
23/05/10 14:03:23.86 jzBK8DOC.net
lintにmissing_docs
URLﾘﾝｸ(doc.rust-lang.org)
があるけどデフォルトでallowになってるらしい
lib.rs（main.rs）に
#![warn(missing_docs)]
を足すかコマンドで↓を実行
cargo rustc -- -W missing-docs
320:デフォルトの名無しさん
23/05/10 14:21:07.26 HatbRJDw.net
>>316
注意喚起テンプレとこの隔離スレが効いてるから本スレも平和
321:デフォルトの名無しさん
23/05/10 16:48:54.33 uLiToFDO.net
>>319
?クス
しかし足りない数(あと5ヶ所のはず)よりはるかに多い warning が出て来たでござる
322:デフォルトの名無しさん
23/05/10 17:11:01.06 uLiToFDO.net
>>319
5ヶ所治して残りの warning 放置で 100% 達成出来ました！
ほんとうにありがとうございました！！！
323:デフォルトの名無しさん
23/05/10 17:13:13.74 dsu8fQGS.net
コメントカバー率の計算対象は限定されてるよ
URLﾘﾝｸ(doc.rust-lang.org)
324:デフォルトの名無しさん
23/05/11 03:47:03.48 1mbxr1bo.net
C++だとdoxygenなど使うところが
Rustだと公式サポートされて色々と進んでいるのね
325:デフォルトの名無しさん
23/05/11 08:01:31.45 UvaUTinw.net
URLﾘﾝｸ(twitter.com)
If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel!
URLﾘﾝｸ(pbs.twimg.com)
(deleted an unsolicited ad)
326:デフォルトの名無しさん
23/05/11 11:43:59.84 Ue/TF0sJ.net
win32kbase_rs.sys
win32kfull_rs.sys
って何?
ついでに名前が似た以下のファイルも
win32kbase.sys
win32kfull.sys
327:デフォルトの名無しさん
23/05/11 12:35:35.38 hMF5bhvG.net
URLﾘﾝｸ(japan.zdnet.com)
328:デフォルトの名無しさん
23/05/11 12:57:22.38 h0Ssdxno.net
>>327
C++は何故か年々人気が上がってるね
329:デフォルトの名無しさん
23/05/11 13:16:26.32 a3sWIGIB.net
C++0xの暗黒時代を知らない世代が増えたんだろう
330:デフォルトの名無しさん
23/05/11 14:21:03.16 kyUN9mFL.net
>>317
上澄みだけ使うならライブラリも豊富だし悪くない。
本来なら、c++標準化団体がAccelerated C++みたいなのを用意してメンテナンスすべきだと思うけどなぁ。
331:デフォルトの名無しさん
23/05/11 14:44:20.03 Ue/TF0sJ.net
いらね
332:デフォルトの名無しさん
23/05/11 15:04:29.85 OsVl9AaP.net
デザパタ流行した時ほにゃららパターンのほとんどが理解できなかったけどそのうち理解しなくても何の問題もない事が判った
うんこうんこうんこー
333:デフォルトの名無しさん
23/05/11 15:26:04.23 IKYAIOBH.net
>>332
実務で今使ってるのは、state, proxy, singleton, factoryくらいかな。
あとは使ってないね。
334:デフォルトの名無しさん
23/05/11 16:10:38.63 o+lB6Dgi.net
近年の C + 人気は上の画像でも見ただろ
競技プログラミングだよ
335:デフォルトの名無しさん
23/05/11 16:14:51.13 a3sWIGIB.net
GoFのパターンはiteratorとかadapterも含めてるから多分無意識で使ってるよ
昔のforループはi++で回すのが普通だったし
JavaにIterator（foreach構文）が追加されたのが1.5くらいのはず
336:デフォルトの名無しさん
23/05/11 18:30:22.74 mNkrg+hY.net
懐かしの 何とかの呼吸 ○の型 ほにゃらら！が沢山あるけど
使わないときは使わないと言うだけです
337:デフォルトの名無しさん
23/05/11 18:41:36.44 mNkrg+hY.net
Rustの呼吸 一の型 mut代入！
Rustの呼吸 二の型 シャドーイング！
338:デフォルトの名無しさん
23/05/11 18:56:15.63 gsH464oC.net
それ現行コンテンツちゃうの? (初クール初回から録画だけして観てない
339:デフォルトの名無しさん
23/05/11 19:34:36.36 KOkRWEaK.net
C++コアガイドラインに従い、IDE組み込みのチェッカーを使う
これが一般的なスタイル
これだけであなたの悩みはすべて解決する
340:デフォルトの名無しさん
23/05/11 19:37:24.28 KOkRWEaK.net
CCG！CCG！
341:デフォルトの名無しさん
23/05/12 14:15:57.41 qPE7RwmZ.net
終戦のお知らせ
Rust言語で開発されたカーネルがプレビュー版「Windows 11」に - やじうまの杜 - 窓の杜
URLﾘﾝｸ(forest.watch.impress.co.jp)
342:デフォルトの名無しさん
23/05/12 14:19:03.50 jNwvrlvi.net
解散
343:デフォルトの名無しさん
23/05/12 14:25:26.74 uf2dKGIg.net
カーネルのどのへんで使われてるんだろう
Linuxみたいに周辺部分からかな
344:デフォルトの名無しさん
23/05/12 14:32:56.45 yiIZVwAo.net
>>341
Rustの成果をC/C++に還流させるフェーズ どんどんやってくれ
345:デフォルトの名無しさん
23/05/12 14:44:13.86 GoY4o9UG.net
Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
URLﾘﾝｸ(azure.microsoft.com)
Rust as the path forward over C/C++
Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we’re betting on Rust as the alternative to C/C++. Rust is a modern language designed to compete with the performance C/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure. We expect our adoption of Rust to expand substantially over time.
346:デフォルトの名無しさん
23/05/12 14:45:57.07 QUxSeMfx.net
マイクロソフト、Rust言語による開発を含む初めてのWindowsカーネルをInsiderプログラム参加者向けに提供開始
URLﾘﾝｸ(www.publickey1.jp)
デバドラからか
347:デフォルトの名無しさん
23/05/12 15:41:33.52 66ak38wv.net
これを見ると、言語の移り変わり時期が来ると
一気に使われなくなって廃れていくんやな、、
URLﾘﾝｸ(m.youtube.com)
348:デフォルトの名無しさん
23/05/12 16:02:52.10 TaYVXf5t.net
むかしもこんな感じでJ++に騙されたんだよ
349:デフォルトの名無しさん
23/05/12 16:05:02.84 vtQb4m8q.net
コンパイラは何使っているんだろうね?
MSがllvmなんかつかうのかな?
350:デフォルトの名無しさん
23/05/12 16:11:29.41 GsK+e8JY.net
Visual Rust++登場も近いな
351:デフォルトの名無しさん
23/05/12 16:19:18.80 MfrxynDP.net
新しいGC言語がどれだけ出て来ても
C++の天下は揺らがない
もしC++が転落するときが来るとすれば
C++の欠点を解決しつつ同等の性能を出せる新たな非GC言語が登場した時だけだ
352:デフォルトの名無しさん
23/05/12 17:14:53.42 0Z+hsanL.net
trait 内の fn は pub 付けていなくても
trait 自体が pub で定義されていたら
他の trait (というか上の trait を引き継いでいる) からでも参照出来るんだね
353:デフォルトの名無しさん
23/05/12 17:16:09.03 0Z+hsanL.net
Visual R++
Visual R#
しっくりこない
354:デフォルトの名無しさん
23/05/12 17:47:30.22 UYEx77Kz.net
R言語はもう別であるからRustがR++になる心配はない
355:デフォルトの名無しさん
23/05/12 17:50:51.87 BjQIXqEx.net
Visual &mut Rust
356:デフォルトの名無しさん
23/05/12 17:54:33.84 qfqUshnI.net
トリビア: トレイトメソッドに付くVisibilityは構文定義上だけは許されている
357:デフォルトの名無しさん
23/05/12 18:18:31.38 0Z+hsanL.net
トレイト完全に理解した！
ヒャッハーっ！！！
358:デフォルトの名無しさん
23/05/12 18:29:46.57 LzgSZzp6.net
URLﾘﾝｸ(doc.rust-lang.org)
Trait items syntactically allow a Visibility annotation,
but this is rejected when the trait is validated.
359:デフォルトの名無しさん
23/05/12 20:36:17.87 qfqUshnI.net
またひどい知ったかぶりしてる……
ｽﾚﾘﾝｸ(prog板:575番)
575 仕様書無しさん 2023/05/12(金) 15:53:45.02
C++のスマートポインタはRustで吸収され
・RustのCopy実装型 (使われる時は自動コピー)
・RustのCopy非実装型 (使われる時はムーブ) ← C++のunique_ptr
・RustのArc型 (atomic増減でスレッド間も利用可) ← C++のshared_ptr
・RustのRc型 (高速にスレッド内で利用可)
つまりunique_ptrの機能がRustでは標準で備わっている
さらにshared_ptrはArcでその軽量版Rcが追加
C++と異なり使い間違えるとコンパイルエラーで知らせてくれる
さらにRustは参照と可変参照の規則によりデータ競合をコンパイル時に防ぐ
360:デフォルトの名無しさん
23/05/12 22:56:44.22 LzgSZzp6.net
問題なし
361:デフォルトの名無しさん
23/05/12 23:46:30.09 qfqUshnI.net
unique_ptrに対応するのはBoxやろがい
362:デフォルトの名無しさん
23/05/13 02:08:25.96 IwTcnmrR.net
>>361
C++のunique_ptrとRustのBoxは対応しない
Boxはヒープ確保であり例えば以下でのnew int(123)部分にあたる
std::unique_ptr<int> foo(new int(123));
そしてunique_ptr自体にヒープ確保の機能はない
363:デフォルトの名無しさん
23/05/13 04:06:17.18 rghdYpRz.net
>>351
それがrustだろ
364:デフォルトの名無しさん
23/05/13 07:59:34.64 Mq7eAK7K.net
天下ねえ
天下って思われてると、むだに煽られるよねえ
C++サイコーｗｗｗ(大好き)とは思ってるけど
365:デフォルトの名無しさん
23/05/13 10:20:28.21 rDLT/gzF.net
何故プログラミング言語が変わるのか
まずハードが変わる、当然命令セットも変わる、さりとてハードが変わるたんびに新しい言語を覚える、既存のソフト移植する、など不可能なのでここで一個
ソフトサイドで新しい考え方が出てくる、既存の考え方ではバグ出やすい、効率悪い、こう考える方がいいという新しいプログラミングに関する知見が出れば言語そのものの刷新に向かう圧力が出る
ここで一個
大別すればこの2段やろな
①高級言語
━━━
②繋ぎレイヤ
━━━
③アセンブラ
①、③は必然的な刷新圧力に応じてどんどん変わっていく、③は必然的に新しいハードが出るたびに、①は絶対ではないけどBasic, Perl, Java, Ruby, Python などなど概ね5～10年周期で変わってきた
しかし②のレイヤはほぼ半世紀近くC,C++の独壇場, MachとかObjectice Cとかあったけど結局消えていった
さてさてどうなるのか？
Windows, Linuxでは一部Rubyに置き換える試みがなされてるけどコレは本流の大きなにがれになるのか、あるいはやはりごく一時的なものでやはりC,C++の牙城は崩れないのか
366:デフォルトの名無しさん
23/05/13 10:27:54.96 R1hDb7+8.net
>>365
Rustは③だよね？
367:デフォルトの名無しさん
23/05/13 11:14:30.77 qbLWQV0Y.net
たった今あるソリューションがRustだから、切迫した更新需要にはRustが入ると思う
もうちょっとゆとりのあるものは、improved C/C++ でいいかなって感じじゃないかな
自分もその位置
368:デフォルトの名無しさん
23/05/13 12:46:24.99 TFo/sDKR.net
C++は倒れたままなのか？
死亡フラグ
369:デフォルトの名無しさん
23/05/13 12:48:52.48 OKlDpUB8.net
倒れたと言いますと?
370:デフォルトの名無しさん
23/05/13 13:37:03.03 0/cn7SoC.net
>>365
頭悪過ぎ
371:デフォルトの名無しさん
23/05/13 13:52:20.03 IGToM9iL.net
>>362
make_unique知らないの？ 知ってて黙ってる？
それとも知ってたけどunique_ptrに属さないから駄目だって言いたいの？
というかその差異を認めたとしても、スコープを抜けるとき/ムーブされるときに内容の後始末とヒープの解放を行うという重要な共通点が依然としてあるし、
その点を無視してunique_ptr<T>を任意の非Copy型と対応付けようとするほうがよっぽど無理があると思うけどね
372:371
23/05/13 13:54:01.76 IGToM9iL.net
あ、ムーブされるときは違うなすまん
373:デフォルトの名無しさん
23/05/13 18:07:44.55 1P8OgH65.net
lifetime の &'static と
global の static で
同じ名前になってるのはセンス無いな
Rust 界にも static おじさんは息衝いている
374:デフォルトの名無しさん
23/05/13 18:08:15.66 Zeyov0xO.net
なんかメチャクチャ書いたな
NeXT Stepとかはあくまで周辺プログラミング環境がobjective CだっただけでOS本体はMach kernelでそれはCとかでかかれてるから②のレイヤでC,C++に変わるものは四半世紀でてきていない
果たして本当にここにRustが食い込めるのかね、あるいは置き換わるなどということが本当に起こりうるものなのか
375:デフォルトの名無しさん
23/05/13 19:38:25.85 rkpDrS5+.net
>>373
そこはむしろRustの美学というか方針
Rustは予約キーワード類を最小とするために巧妙な使い回しと組み合わせを意図的にしている
376:デフォルトの名無しさん
23/05/13 21:15:21.97 C/HTc2pJ.net
>>371
make_uniqueは複合の合わせ技だから、
unique_ptrのコンストラクタを見た方がよいね
引き数はnewで確保したポインタなどだから、
unique_ptrの構築前に別途ヒープ領域を確保済
一方でBoxの構築時はまだヒープ領域を確保しておらず、Boxがヒープ領域を確保
だから両者は決定的に違うんじゃないかな
さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
スコープを抜けたときの処理や内部で持っているヒープ領域の解放については、
unique_ptrやBox以外でも行われる話だから、両者の共通点というよりもっと大きな範囲の共通点だね
377:デフォルトの名無しさん
23/05/13 21:18:10.27 qbLWQV0Y.net
>>375
騙されないぞ
それじゃC++とおんなじじゃないかｗ
378:デフォルトの名無しさん
23/05/13 21:55:24.10 ps1U4+yC.net
>>373,375
staticはglobalスコープとは関係ない
lifetimeがstaticなだけなのでどっちも同じ意味
美学てｗ
379:デフォルトの名無しさん
23/05/13 22:14:54.43 ps1U4+yC.net
Copy非実装型とBoxとどちらがunique_ptrに近いかと言えば大多数の人はBoxだと言うだろうな
まあ言語が変われば1対1で対応しない機能があるのが普通なので
無理に対応づけようとするよりもそれぞれの違いを学んだほうがいいよ
380:デフォルトの名無しさん
23/05/13 22:22:25.59 IGToM9iL.net
>>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ
381:デフォルトの名無しさん
23/05/13 22:50:11.88 awcNL8zc.net
Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew
382:デフォルトの名無しさん
23/05/13 22:51:59.52 ps1U4+yC.net
BoxもZero Sized Type(ZST)だとheapを伴わないよね
383:デフォルトの名無しさん
23/05/14 02:32:01.76 WzlwealS.net
>>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな
384:デフォルトの名無しさん
23/05/14 09:24:48.35 20ql+77K.net
Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される
PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される
何か出るたびそれを信仰し同じコトを繰り返すんだな
385:デフォルトの名無しさん
23/05/14 09:25:10.34 hi4Bq2pn.net
>>383
使いどころがないからなｗ
386:デフォルトの名無しさん
23/05/14 09:27:43.22 20ql+77K.net
自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし
387:デフォルトの名無しさん
23/05/14 09:34:52.10 1jFVCpuN.net
>>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)
今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない
Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ
388:デフォルトの名無しさん
23/05/14 10:27:30.61 pb1Dbmn7.net
javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript
地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから…
389:デフォルトの名無しさん
23/05/14 14:29:21.51 ePHWuoFt.net
WindowsのカーネルもRustに移行するのか
390:デフォルトの名無しさん
23/05/14 15:10:39.12 +xFqdUJk.net
これでWindows、Linux、AndroidがRust採用かー
391:デフォルトの名無しさん
23/05/14 19:44:19.16 JeiAQ+ra.net
rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい
392:デフォルトの名無しさん
23/05/14 19:45:39.76 JeiAQ+ra.net
>>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね
393:デフォルトの名無しさん
23/05/14 20:14:19.79 pJuPP/LG.net
色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう
394:デフォルトの名無しさん
23/05/14 20:36:25.87 QmAlZPFj.net
🐟::🐟::🐟::
395:デフォルトの名無しさん
23/05/14 20:47:29.76 aUfiFIOV.net
::も<type>もC++と同じだから連続してもそれほど違和感ない
396:デフォルトの名無しさん
23/05/14 20:57:09.57 pb1Dbmn7.net
goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった
397:デフォルトの名無しさん
23/05/14 20:59:37.48 oUsSKvxr.net
C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ
398:デフォルトの名無しさん
23/05/14 21:00:38.00 QE+keqW6.net
>>392
関数型はマイナーだからな
399:デフォルトの名無しさん
23/05/14 21:02:12.13 QE+keqW6.net
>>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな?
400:デフォルトの名無しさん
23/05/14 21:06:28.92 pb1Dbmn7.net
< >は解釈の時若干邪魔なのかとは思うけど
ヒマだからANTLRで構文解析器でも作ってみようか
401:デフォルトの名無しさん
23/05/14 21:08:03.75 pb1Dbmn7.net
ｃはtypedefとかの仕組みがクソ
402:デフォルトの名無しさん
23/05/14 21:30:13.88 QE+keqW6.net
>>401
typedefかっけーやん
#include <iostream>
using namespace std;
struct Hoge {
void hage () const {cout << "hage" << '\n';}
};
int main () {
typedef void (Hoge::*Mage) () const;
Hoge hoge;
Mage mage {&Hoge::hage};
(hoge.*mage) ();
return 0;
}
403:デフォルトの名無しさん
23/05/14 22:05:58.43 RldwXebz.net
何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ
404:デフォルトの名無しさん
23/05/14 22:07:54.16 QE+keqW6.net
>>403
昔のC++はそうだったよ
405:デフォルトの名無しさん
23/05/14 22:57:53.83 bfYFgiq9.net
次スレのスレタイはC++ Considered Harmfulにしよう
406:デフォルトの名無しさん
23/05/14 23:23:04.77 pb1Dbmn7.net
>>402
頭が痛くなるからやめて
407:デフォルトの名無しさん
23/05/14 23:23:32.31 QE+keqW6.net
>>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ?
408:デフォルトの名無しさん
23/05/14 23:26:10.97 pb1Dbmn7.net
作った人たちも失敗したと言ってるからな
409:デフォルトの名無しさん
23/05/14 23:29:27.12 bfYFgiq9.net
変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです
410:デフォルトの名無しさん
23/05/14 23:34:59.36 QE+keqW6.net
俺は使える程には理解してるが人にはちょっと説明できん
411:デフォルトの名無しさん
23/05/14 23:35:38.40 QE+keqW6.net
>>408
誰?
412:デフォルトの名無しさん
23/05/15 00:00:45.30 wsaXJZjZ.net
>>411
しばらく検索してみたけどソースが見当たらないので取り消します
413:デフォルトの名無しさん
23/05/15 00:06:48.33 I+wFjT19.net
>>412
お時間使わせてスミマセン
414:デフォルトの名無しさん
23/05/15 09:27:18.72 wFuQ/qib.net
C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに
415:デフォルトの名無しさん
23/05/15 09:33:17.96 wFuQ/qib.net
>>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った
416:デフォルトの名無しさん
23/05/15 09:37:02.63 wFuQ/qib.net
>>411
ハゲ麦紐じゃなかった？
417:デフォルトの名無しさん
23/05/15 09:38:10.71 DhZrO8d7.net
>>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな
418:デフォルトの名無しさん
23/05/15 11:36:55.02 ujHFmMNa.net
>>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
URLﾘﾝｸ(doc.rust-lang.org)
419:デフォルトの名無しさん
23/05/15 12:27:59.24 GXc9JAaS.net
>>415
いつの話だよ。
C++11以降を知らんのか。
420:デフォルトの名無しさん
23/05/15 12:36:46.16 HovYgrQ4.net
じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ
421:デフォルトの名無しさん
23/05/15 12:58:13.92 s5edYhaR.net
Box[T]
Box t
't box
(box t)
422:デフォルトの名無しさん
23/05/15 13:30:47.16 s5edYhaR.net
今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね
423:デフォルトの名無しさん
23/05/15 13:45:50.28 I+wFjT19.net
Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ
424:デフォルトの名無しさん
23/05/15 13:49:25.75 s5edYhaR.net
URLﾘﾝｸ(www.kmonos.net)
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～
425:デフォルトの名無しさん
23/05/15 14:23:03.39 1m/NLizK.net
> C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた
完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず
仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？
426:デフォルトの名無しさん
23/05/15 14:37:29.92 8jCFowEK.net
C++11までそんなので頑張ってたんだねw
427:デフォルトの名無しさん
23/05/15 14:44:13.08 HovYgrQ4.net
「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？
Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ
428:デフォルトの名無しさん
23/05/15 15:00:31.60 5sS8eRrw.net
()が増えるのは良くない
429:デフォルトの名無しさん
23/05/15 15:09:20.65 s5edYhaR.net
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
0.1すら出る前の超初期は角括弧だったんすねえ
430:デフォルトの名無しさん
23/05/15 15:11:35.81 ujHFmMNa.net
URLﾘﾝｸ(soc.me)
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど
431:デフォルトの名無しさん
23/05/15 15:21:53.58 gbsleJgn.net
>>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね
あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢
432:デフォルトの名無しさん
23/05/15 15:44:34.72 YPCsGXtE.net
言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ
433:デフォルトの名無しさん
23/05/15 18:44:18.46 FgOHTeF5.net
プログラミング言語をただの道具と言うやつは大抵無能
434:デフォルトの名無しさん
23/05/15 18:58:00.82 VaeCf5Jf.net
>>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて
435:デフォルトの名無しさん
23/05/15 19:22:58.71 W6wSx7Ot.net
何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ
436:デフォルトの名無しさん
23/05/15 19:25:10.97 FgOHTeF5.net
道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ
437:デフォルトの名無しさん
23/05/15 19:32:41.90 wsaXJZjZ.net
ここからは理論無用でレスできるのでスレが進むのか？
438:デフォルトの名無しさん
23/05/15 19:32:43.22 Zmr9JaW+.net
作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。
439:デフォルトの名無しさん
23/05/15 19:34:27.68 fkhy8mxo.net
問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。
440:デフォルトの名無しさん
23/05/15 19:38:48.81 s5edYhaR.net
If all you have is a hammer, everything looks like a nail.
>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから
441:デフォルトの名無しさん
23/05/15 19:42:25.96 LmW7vJqn.net
ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。
442:デフォルトの名無しさん
23/05/15 19:47:06.01 wsaXJZjZ.net
目玉焼きに醤油を掛けるのかソースを掛けるのかマヨネーズ掛けるのか塩を掛けるのか
ぐらいのレベルがこの後30レスぐらい続くのかなあ？
443:デフォルトの名無しさん
23/05/15 20:18:45.40 Kl4uDN3z.net
塩だろ。俺は邪道のアジシオだな
どんなターゲットにも合う。最悪、スイカにすら合う。
Cもそんな感じ。
444:デフォルトの名無しさん
23/05/15 20:36:08.15 sS887eTb.net
>>433
道具を「ただの道具」にするかどうかは使い手の問題なんだよ
それがわかってない君は無能
そもそも>>432が「ただの道具」と言ってるように見えるようじゃ終わってるよ
445:デフォルトの名無しさん
23/05/15 21:11:38.66 FgOHTeF5.net
マンパワー依存の無能はさすがに苦笑
エンジニア向いてないよ笑
446:デフォルトの名無しさん
23/05/15 22:00:39.87 Kl4uDN3z.net
まあC++にもunsafe{ } は来てほしいけどね
統一的な方法がなかったので、今後Rustのやりかたが他言語にも波及するっしょ
447:デフォルトの名無しさん
23/05/16 03:39:12.30 mxMgusoo.net
>>446
global deleteを無くすのと、参照渡しのライフタイム保証があればいいよ。
448:デフォルトの名無しさん
23/05/16 04:35:10.15 4S8kS8o+.net
何か未知で不確実だとしてもただの道具ならその目的は既知だったりするでしょ
デストラクタの後で参照しないとか
デストラクタの後でデストラクタを呼ばないとか
だがメモリリークをあまり問題視しない件などは目的自体が変化してしまうから
ただの道具ではない
449:デフォルトの名無しさん
23/05/16 05:49:36.67 LhFniP55.net
>>447
Rust勢が言っているのは、Rustで書いたものは安全といって納品できる、ということなので、
ガイドライン チェッカとかじゃなく、言語にちゃんとunsafe{ } があるというのはモダン
何をもってsafeとするかには議論があったが、Rustがデファクトスタンダードになるなら、それを取り込めばいい
ひとつの夜明けは近い
450:デフォルトの名無しさん
23/05/16 10:02:16.98 dncY24o+.net
>成長が止まりやすく老害化しやすい
道具云々は↑これが図星で悔しかったんだろ
その後のレス見れば成長止まって老害化してる人だとよくわかる
451:デフォルトの名無しさん
23/05/16 10:57:49.38 4S8kS8o+.net
当たり前だけど、攻撃力がレーゾンデートルになるよりは回避力か防御力のほうが
ダメージやストレスが少ない
452:デフォルトの名無しさん
23/05/16 11:13:49.28 afLAkRaY.net
レーゾンデートルｗｗｗ
453:デフォルトの名無しさん
23/05/16 12:35:37.97 ALDBkD8o.net
>>449
shared XOR mutableはちょっと面倒くさい。
せっかくスタックフレームベースなんだから、それ前提にもっと手軽にできないかなぁ。
454:デフォルトの名無しさん
23/05/16 13:33:35.88 d+qszQ7T.net
インテリだなぁwおい
455:デフォルトの名無しさん
23/05/16 13:41:37.03 spgQVWRA.net
>>453
値を変更する時にそれが他から参照されてるかはRust以外でも多少は意識してるはずだし
変更可能な状態で共有することに意味があるならRefCellとかCellに入れて共有すればいい
面倒といっても安全のための規約レベルでしょ
（違反するとコンパイラに殴られるからある意味手間が省ける）
456:デフォルトの名無しさん
23/05/16 15:40:22.92 HCiu7CXC.net
>>453
正確にはshared NAND mutable
457:デフォルトの名無しさん
23/05/16 18:00:25.19 4S8kS8o+.net
所有と参照を区別しない場合は
参照が一つもない値の存在は許されない (循環参照が許されないとは言ってない) ので
むしろxorが正確である場合もあるかも
458:デフォルトの名無しさん
23/05/16 22:00:57.33 LSAD/UZx.net
>>457
それじゃ値について述べてるのか参照について述べてるのかそれとも型について述べてるのか曖昧すぎてルールとしては使い物にならない
主語と目的語を明確に意識してないと所有権複製の二の舞だよ
459:デフォルトの名無しさん
23/05/16 23:06:18.96 4S8kS8o+.net
ああ、C++では値と参照を区別するとかしないとか言うね
でも動詞を使いたくなったら「参照する」は正しいが「値する」はおかしい
だから値を所有する、値を参照するというのが良い
460:デフォルトの名無しさん
23/05/17 06:30:13.75 u+07gdJ+.net
C/C++の値に所有なんてあるのか
参照なら実体側の所有が誰か問題になるかも知れんが
461:デフォルトの名無しさん
23/05/17 11:15:53.89 qIPYqCzM.net
>>460
無い。
特に「所有」の一般的な概念に含まれる(他から制限を受けないという意味での)排他性・専有性は無い。
462:デフォルトの名無しさん
23/05/17 12:05:12.66 jyReDlhf.net
C++の参照がダングリングを引き起こす根本的原因は、
値の所有とその生存期間を参照に対してはっきりさせていないため？
463:デフォルトの名無しさん
23/05/17 12:13:29.10 BpkuThno.net
use Hoge; と
extern crate Hoge; の違いが判ったわ
新しいとか古いとか言ってる人が以前居たけど嘘だったω
464:デフォルトの名無しさん
23/05/17 12:13:39.98 F24a8wLt.net
待て待て
そもそもC++でダングリングを起こしたことがない
Rustは言語仕様上関数でヒープまで消しちゃうから
仕組みがないとダングリングを起こしやすい
ダングリングはRust固有の持病
465:デフォルトの名無しさん
23/05/17 12:57:26.72 gejLyGRv.net
>>464
逆だよな
ダングリングポインタが生じるのはC++
466:デフォルトの名無しさん
23/05/17 13:13:25.46 BC7Hht5L.net
>>464
関数でヒープを自動解放する仕組みすなわち自動的にデストラクタが呼ばれる仕組みはC++とRustで同じ
467:デフォルトの名無しさん
23/05/17 13:36:00.32 bmOF/eVQ.net
デバッグビルドでよければ、結構重厚にチェックしてくれるんだけどね
リリースビルドでも一定程度チェックが残ってくれるようになれば、まだましになるか
468:デフォルトの名無しさん
23/05/17 13:56:37.30 ICP0Cmin.net
>>462
C++でも値に対する所有とライフタイムを明確にして参照のライフタイムがそれ以内に収まる枠組みにすればダングリングを防げるようになる