22/07/22 11:30:46.07 emgmw9dd.net
Java厨は出て来ないで下さいうざいだけです
437:デフォルトの名無しさん
22/07/22 11:34:22.85 LVIZaCij.net
>>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。
438:デフォルトの名無しさん
22/07/22 13:14:37.08 GQh1j6M0.net
>>432
rustの画期的な部分なんだろ？言い返せないのかよダサいなお前
本当に革新的なのは>>423あたりなんじゃないの
439:デフォルトの名無しさん
22/07/22 14:36:57 ZDp8+ZKO.net
kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。
440:デフォルトの名無しさん
22/07/22 14:59:23.46 hnGDX2CP.net
>>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている
441:デフォルトの名無しさん
22/07/22 15:43:33.15 yLavWCdC.net
>>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。
コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。
442:デフォルトの名無しさん
22/07/22 17:12:05.71 efNbKFVE.net
安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない
443:デフォルトの名無しさん
22/07/22 17:40:06.82 whw2xWQR.net
Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね
444:デフォルトの名無しさん
22/07/22 17:44:11.14 t0V8WW9J.net
>>436
インターフェースの問題とJavaの問題を混同するのが論外
445:デフォルトの名無しさん
22/07/22 18:05:15.33 K++ItniC.net
Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな
446:デフォルトの名無しさん
22/07/22 19:11:51.06 yoEBUVfk.net
>>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。
447:デフォルトの名無しさん
22/07/22 21:06:16.19 UonvlDt9.net
キモいな
Javaは遺伝子引き継いでないから代理出産に違いない
448:デフォルトの名無しさん
22/07/22 21:16:25.55 i57cd+Nw.net
>>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。
449:デフォルトの名無しさん
22/07/22 21:29:36.07 zWgtMzpY.net
>>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。
450:デフォルトの名無しさん
22/07/23 04:53:27 Yc68YnRu.net
>>444
意味不明なこと言わないで
451:デフォルトの名無しさん
22/07/23 05:40:41.12 xoLMiefm.net
>>435
C++だけでなくRustも理解できてない？
＠
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる！」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。
452:デフォルトの名無しさん
22/07/23 08:37:27.70 0xKT+wLu.net
>>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない？
453:デフォルトの名無しさん
22/07/23 09:37:03.85 bR39w9BX.net
Googleは金の亡者
454:デフォルトの名無しさん
22/07/23 11:55:37.32 8Uydd8B4.net
>>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw
455:デフォルトの名無しさん
22/07/23 13:10:56 RBxCW/xN.net
OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当
Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある
後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い
456:デフォルトの名無しさん
22/07/23 16:15:20.09 tefRxlpq.net
>>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける
457:デフォルトの名無しさん
22/07/23 18:34:20.81 u2Y0Vizw.net
>>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。
458:デフォルトの名無しさん
22/07/23 19:04:05.94 ehQy/P8s.net
ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
459:デフォルトの名無しさん
22/07/23 19:21:14 NE7ljYY1.net
C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる
460:デフォルトの名無しさん
22/07/23 19:57:02.71 uphZtYPd.net
正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。
461:デフォルトの名無しさん
22/07/23 20:43:26.21 PgM2fTTz.net
>>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは
462:デフォルトの名無しさん
22/07/23 21:05:19 IDFlcwhf.net
>>454
Hoareはホーアかホアだと思うんだが
ホアレはどこの国の読み方？
463:デフォルトの名無しさん
22/07/23 21:18:57.29 91gi6HhK.net
日本じゃね？
464:デフォルトの名無しさん
22/07/23 21:28:49.17 zqWGCIwO.net
>>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇 言語や〇 langでいける
465:デフォルトの名無しさん
22/07/23 22:37:12.56 SkYdpzS6.net
>>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない？
ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ
466:デフォルトの名無しさん
22/07/24 09:21:08.56 lG8qI40d.net
>>461
じゃあいつできたの？
467:デフォルトの名無しさん
22/07/24 09:29:10.51 TkuAh24s.net
RustじゃなくてHoareの方が検索性は高かったと思う
言語に自分の名前つけたっていいじゃん、最初だけイタい人扱い受けるだけだし
468:デフォルトの名無しさん
22/07/24 12:23:10 A2ivE9+A.net
でも本当にHoareなんて名前付けたら絶対Tony Hoareのほうだと思われるやろな
469:デフォルトの名無しさん
22/07/24 12:53:11.52 lG8qI40d.net
>>464
ほんこれ
あんな有名人とfamily nameが一緒とかすごい偶然だよな
470:デフォルトの名無しさん
22/07/24 13:06:01.37 hnBeY/7d.net
木村拓哉と苗字が同じ木村君みたいな。
471:デフォルトの名無しさん
22/07/24 13:06:50.57 iVL8opWs.net
すごい偶然ですねえ・・・ えっ
472:デフォルトの名無しさん
22/07/24 13:35:38.58 q7gbemmZ.net
Rust-Oneとか見たいな感じの名前が良かったんじゃないかとｗ
473:デフォルトの名無しさん
22/07/24 13:48:30.68 q7gbemmZ.net
新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…
C java go Perl Ruby Rust ...
474:デフォルトの名無しさん
22/07/24 13:53:14.16 iVL8opWs.net
せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
Javalang、Clang、Golang、Rustlang...
clangは名前衝突するから今更ムリだけど
475:デフォルトの名無しさん
22/07/24 14:08:13.51 6QULAMze.net
RustとかGoはもう今じゃメジャーだから大分マシだけど
上の方に出てるCarbon？だのみたいな新しい知名度低いようなのにとっちゃ検索されづらいのって結構大きいデメリットじゃないのかね
476:デフォルトの名無しさん
22/07/24 14:11:15.69 q7gbemmZ.net
Car-bonおすすめ
477:デフォルトの名無しさん
22/07/24 17:26:22 AIK5SBoS.net
Rustでは検索にこまったことないけどなぁ
CやGoではそれなりに困ったことある
特にC
478:デフォルトの名無しさん
22/07/24 17:35:43.91 nz/s3YoW.net
>>469
perlは違うくね
入れるならpython
479:デフォルトの名無しさん
22/07/24 18:34:31.10 kd/zxSl1.net
Pythonはまさかちょっとしたイタズラ心で命名した言語が
30年経ってこれほどまでに普及するとは思ってないだろうなぁ。
480:デフォルトの名無しさん
22/07/24 20:35:51.30 T5Io3liY.net
ゲームのRustが人気になっていても問題なく検索できてるなぁ
481:はちみつ餃子 ◆8X2XSCHEME
22/07/25 09:42:55 OE8E5RfU.net
パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
個人情報保護の法律との兼ね合いが難しいみたいだが。
482:デフォルトの名無しさん
22/07/25 11:46:03.92 fotNOYOj.net
RustはCやC++の後継にはならないな。
483:デフォルトの名無しさん
22/07/25 12:46:43.99 /yXgS7y/.net
CはC言語で検索してもC++が出てきやがるからな
迷惑な言語だわC++
484:デフォルトの名無しさん
22/07/25 14:10:01.30 fotNOYOj.net
全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。
485:デフォルトの名無しさん
22/07/25 19:30:13.93 qs4kuyp6.net
>>456
その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる
486:デフォルトの名無しさん
22/07/25 20:08:08.67 uz33IoOs.net
goはgolangって呼び方が一般化してるから問題なくね？
親会社もalphabetだし、仮に一般名詞でも検索してやんよっていう自信の現れなのかも。
あとlisp monsterのほうが可愛いよね
487:デフォルトの名無しさん
22/07/25 21:31:20 o3/zkeTE.net
langってなに？
488:デフォルトの名無しさん
22/07/25 21:42:28 GF1rw+EH.net
ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府
489:はシリア高原と呼称するそうだぞ。
490:デフォルトの名無しさん
22/07/26 07:10:48 4TZ4RWr2.net
今ちいかわってキモいキャラが流行ってるように
Gopherくんもいずれ世界的なマスコットキャラクターになるよ
491:デフォルトの名無しさん
22/07/26 08:04:10.89 B/e7/0Va.net
>>484
それはGolan
492:デフォルトの名無しさん
22/07/26 08:15:07.77 RlhOzjvN.net
今マイコン用クレートでメジャーなのってどのあたり？
自分で作るにあたり参考にしたいのだが
493:デフォルトの名無しさん
22/07/26 08:36:59.30 +EhcIf+H.net
>>487
おれたちが知るわけないだろバカか？
494:デフォルトの名無しさん
22/07/26 08:37:23.50 jFWmtimM.net
言語の名前がGopherだったらよかったのに
495:デフォルトの名無しさん
22/07/26 09:10:32.87 gGUkeHRo.net
プロトコルの方のgopherについて調べる人が困るでしょ
496:デフォルトの名無しさん
22/07/26 09:38:10.98 hAg2HYen.net
プロトコルはイーサリアムとビットコインで実現出来ます
この2種類以外は今後不要になります
497:デフォルトの名無しさん
22/07/26 09:42:41.59 xvJteLGG.net
😲
498:デフォルトの名無しさん
22/07/26 09:57:43.88 khPn0eWd.net
>>491
草
499:デフォルトの名無しさん
22/07/26 11:19:17.05 wEdk200U.net
Web3なんて流行るわけねーだろ
スマートコントラクトの開発コスト高すぎ＆不便すぎ
500:デフォルトの名無しさん
22/07/26 11:50:54.04 m36KkBXx.net
それに引き換えBorrow Checkerは開発コスト低くて便利だね
501:デフォルトの名無しさん
22/07/26 11:55:05.12 xpFZew7X.net
Rust=Web3 だからWeb3業界の勢いが無くなったら影響受けるよ
502:デフォルトの名無しさん
22/07/26 11:59:58.82 EbLORSqB.net
>>496
意味不明
503:デフォルトの名無しさん
22/07/26 12:14:19.05 /Gebh7sM.net
Etherはイーサーだけど
Ethereumはァセーリアム
日本語読みだと外人に通じないから注意な
504:デフォルトの名無しさん
22/07/26 12:46:34 NppJ7uYb.net
>>487
AVR-HALとかいうやつ使ってる
505:デフォルトの名無しさん
22/07/26 14:54:22.29 6ZBHWj0q.net
３年以内にMoveが天下取るとか言われてるけど本当かね
506:デフォルトの名無しさん
22/07/26 14:58:00.69 m36KkBXx.net
本当だから高くなる前にいっぱい買っておけ
507:デフォルトの名無しさん
22/07/26 21:01:19.60 WAPUil1D.net
ʕ◔ϖ◔ʔ
508:デフォルトの名無しさん
22/07/27 00:16:39.59 Zq3V4Tcb.net
>>500
Moveってなに？
509:デフォルトの名無しさん
22/07/27 01:54:06.44 qGGsA3uX.net
>>503
最新のブロックチェーン言語も知らない奴はここから消えて
510:デフォルトの名無しさん
22/07/27 05:50:23.11 Zq3V4Tcb.net
>>504
あれLibraってまだ生きてんの？
ぜんぜん音沙汰聞かないけど
511:487
22/07/27 07:28:03.29 6+JEeGDS.net
>>499
ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・
512:デフォルトの名無しさん
22/07/27 07:32:05.65 6nSf0k+r.net
>>503
ダイハツの軽自動車
513:デフォルトの名無しさん
22/07/27 10:27:27.45 IW7fj0uw.net
>>505
名前変えた後継含めて公式に死んでる
514:デフォルトの名無しさん
22/07/27 19:19:33.01 U29fl458.net
>>505
世界に殺された
もし生まれたら恐ろしいことになってただろうしな
515:デフォルトの名無しさん
22/07/28 00:38:58 z/Vvst4i.net
アレはAptosとして生き残った
大型の資金調達を連発して次の投機の標的になってる
516:デフォルトの名無しさん
22/07/30 22:19:27.63 wZaxY20D.net
std::io::Result<()>
↑の()ってなんすか？
Ok(());
↑の()も。
「空」を意味してるってことでいいんですか？
517:デフォルトの名無しさん
22/07/30 22:34:27.43 PnFWbFUc.net
5つの何かを返す関数なら
return (a, b, c, d, e);
0つの何かを返す関数なら
return ();
と考えてもよく何も返さないこと
518:デフォルトの名無しさん
22/07/30 22:39:27.64 xUdiS2xM.net
URLﾘﾝｸ(doc.rust-lang.org)
519:デフォルトの名無しさん
22/07/30 22:41:59.23 wZaxY20D.net
>>512
>>513
どうもありがとう
520:デフォルトの名無しさん
22/08/01 16:04:37.53 ElZDPbmW.net
Meta社のバックエンドにRust推奨だってよ。
URLﾘﾝｸ(www.publickey1.jp)
521:デフォルトの名無しさん
22/08/02 02:20:06.29 M8Mca9lV.net
bevy 0.8
URLﾘﾝｸ(bevyengine.org)
522:デフォルトの名無しさん
22/08/02 23:33:57 FkNkpg49.net
bevyとFyrox Engineはどちらの方が良いのかな
人気度はbevyな気がするが
523:デフォルトの名無しさん
22/08/04 02:28:39.18 xaY+36ag.net
Rustでプラグインシステム組むならwasiが安牌かな
524:デフォルトの名無しさん
22/08/04 09:59:47.35 CkQzFtco.net
プラグインシステムとは
525:デフォルトの名無しさん
22/08/04 12:38:32.91 pLEfRi/j.net
エディタとかツールの機能拡張だよ。
RubyとかJVMとかある程度の動的さを持つランタイムがあると開発楽だけど、GoやRustみたいにスタティックリンク、シングルバイナリが基本になると
たしかにwasmベースで作るのが筋が良いのかねぇ。
526:デフォルトの名無しさん
22/08/04 12:57:45 qyv7p4eK.net
おいおいww
527:デフォルトの名無しさん
22/08/04 13:50:49.10 ck4xiQdl.net
クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
という条件だとLuaかwasm
528:デフォルトの名無しさん
22/08/04 13:51:05.48 ck4xiQdl.net
JSでも良いが
529:デフォルトの名無しさん
22/08/04 15:10:31.96 b+TNnTjV.net
プラグインというよりマクロの実行環境の話だな
Luaやwasmはホストアプリにランタイムを同梱する必要がある
530:デフォルトの名無しさん
22/08/04 15:23:41.09 1k9fnhsy.net
Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
よほどホスト側にプラットフォームとしての魅力がない限りは成立しないよ
ホストがスクリプトに対して提供している機能以上のことはできないわけだからな
そうじゃなくて、やりたいのはホストにない機能を追加できるプラグイン機構じゃないの？
531:デフォルトの名無しさん
22/08/04 15:39:46.71 9TNfUmNd.net
>>520
Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ
532:はちみつ餃子
22/08/04 15:55:10.42 hPtMGH66.net
そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ？
最終的にどういう結論になったのか追ってないんやが……。
必要な機能は Rust コンパイラの中に全部あってシステムの外とやり取りする必要もないから良い案に思える。
533:デフォルトの名無しさん
22/08/04 17:17:23 KbhCPu0a.net
>>525
Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど
534:デフォルトの名無しさん
22/08/04 17:19:43 ck4xiQdl.net
動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
それなりの量のグルーコードが必要になるかと
その辺良い感じにどうにかしてくれるcrateがあるかもしれないけど
535:デフォルトの名無しさん
22/08/04 17:29:05.26 1k9fnhsy.net
>>528
そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ？
536:デフォルトの名無しさん
22/08/04 17:46:52.95 CkQzFtco.net
URLﾘﾝｸ(qiita.com)
コメント欄も含めるとなかなか情報がまとまっています
537:デフォルトの名無しさん
22/08/04 17:49:06.27 8PPO9uzK.net
良さげ記事
538:はちみつ餃子
22/08/04 17:58:11.58 hPtMGH66.net
>>530
ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ？
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)
制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか……
539:デフォルトの名無しさん
22/08/04 18:01:34.69 9TNfUmNd.net
>>529
> 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった
540:デフォルトの名無しさん
22/08/04 18:42:08.03 pLEfRi/j.net
野良プラグイン入れて環境壊して上等！って時代でもないからねえ。
ある程度、できること制限できるようにしたプラグイン機構も大事な時代よ。
そういう点でwasmがセキュリティとパフォーマンスのバランスが取れていて魅力という層もあるでしょ。
541:デフォルトの名無しさん
22/08/04 18:42:45.33 KbhCPu0a.net
>>530
そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない
「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの？
542:デフォルトの名無しさん
22/08/06 12:18:12.84 z/fLyAW1.net
今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
同様にTauriで作成されたアプリが10年後でも問題なく使用できるのだろうか
543:デフォルトの名無しさん
22/08/06 20:40:11.73 6gQA87rg.net
Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Macとかだと突然仕様変えてきそうで怖いな
544:デフォルトの名無しさん
22/08/07 00:00:20.59 pGypWfdH.net
Rustでライブラリをどうやって選定してんの？
crate.io見て人気のを選んでんの？
GETだけのためにhttpclient使おうとしたらtokio入れて使えとか全然意味わからんしコンパイルしたら
これを使うには2018使えと2022使えが出てくる…
他のに変えても変わらず
GETなんてコピペ産業で実現させてくれよ
use
初期化
GET
これで終わらせてくれ
545:デフォルトの名無しさん
22/08/07 00:05:00.47 pGypWfdH.net
別に
use
GET
の2行でもいい
546:デフォルトの名無しさん
22/08/07 00:19:22.87 thO2Aez3.net
>>539
まあ今はそういう人向けの言語じゃないからね
とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん
547:デフォルトの名無しさん
22/08/07 00:27:13.75 pGypWfdH.net
crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと
どれもtokio使ってるしCurlコマンドみたいに一発でGETやPOSTって感じでもない
tokio必須と言うことは標準でasyncライブラリの完成度が低いんだろうけど
憶測が当たってるかどうかもよくわからない
548:はちみつ餃子
22/08/07 00:48:31.33 yGip1YMx.net
>>542
Rust は標準ライブラリの中に非同期ランタイムを持ってない。
言語として非同期を扱えるようにしつつ具体的な部分は外部のクレートに任せられるように
分離に成功しているという意味では十分に完成度は高いとも言える。
549:デフォルトの名無しさん
22/08/07 01:05:02.63 nCVSRdWl.net
>>539
簡単これだけ
#[async_std::main]
async fn main() {
let uri = "URLﾘﾝｸ(httpbin.org)
let s = surf::get(uri).recv_string().await.unwrap();
assert_eq!(s, "Hello, World!");
}
Cargo.tomlの[dependencies]に適当に
async-std = { version = "*", features = ["attributes", ] }
surf = "*"
550:デフォルトの名無しさん
22/08/07 05:20:01.36 FgVTxKNL.net
簡単に使いたいなら、非同期じゃなくて同期版のhttpクライアントライブラリ使いなよ
551:デフォルトの名無しさん
22/08/07 08:15:04.13 PrNdTuny.net
Goを素直に使っとけ
標準ライブラリでそのままできる上に非同期もGoroutineを使うだけ
テスト用のライブラリも用意されてるからクライアントサーバーもそのままテストできる
552:デフォルトの名無しさん
22/08/07 08:22:19.17 nCVSRdWl.net
>>546
Goなんていうものは不要
Rustで簡単に使える
553:デフォルトの名無しさん
22/08/07 08:29:14.86 PrNdTuny.net
標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ
>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする
554:デフォルトの名無しさん
22/08/07 08:59:18 9InYic2G.net
>>548
あまりにも狭い視野と酷い誤解をなさっているようだが
ウェブ関係はRustのメリットが十分にある分野で実際にRustで利用が多い分野
555:デフォルトの名無しさん
22/08/07 09:24:53.04 OveVhBWN.net
複オジ相手にするのは隔離スレか実質隔離スレの次世代スレだけにしろ
556:デフォルトの名無しさん
22/08/07 09:37:06.87 VV/7IoC0.net
>>548はいつものRustアンチのキチガイかな
RustはOSやドライバ用と嘘をついてそれ以外なら他の言語を使うべきと誘導する書き込みがそっくり
557:デフォルトの名無しさん
22/08/07 10:46:09.01 W6kFcilw.net
キチガイ同士ここ以外で仲良くやっとけよ
邪魔なんだよ
558:デフォルトの名無しさん
22/08/07 12:14:32.05 46MSroSz.net
キチガイ隔離スレのココが機能していてなにより
559:デフォルトの名無しさん
22/08/07 12:50:43.08 45kFT7pS.net
次世代スレの方もﾜｯﾁｮｲ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
あとは過疎を恐れず移行すれば万事解決です
560:デフォルトの名無しさん
22/08/07 13:58:05.65 ZjeWku4d.net
まだ実証されてないってことね
じゃあバスで
561:デフォルトの名無しさん
22/08/07 14:08:40.83 XsO6imG4.net
過疎やん
【ﾜｯﾁｮｲあり】プログラミング言語 Rust
ｽﾚﾘﾝｸ(tech板)
562:デフォルトの名無しさん
22/08/11 07:14:02.75 wbWFySKV.net
structに不変なフィールドを持たせるにはどうしたらいいのですか？
const定数ではなく、インスタンスごとに初期化時に値を設定したら、その後は変更不可能。
他のフィールドは変更可能でも。
563:はちみつ餃子
22/08/11 10:33:56.78 5k4DsUHs.net
>>557
直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。
564:デフォルトの名無しさん
22/08/11 11:32:02.59 wbWFySKV.net
>>558
ありがとうございます。
565:デフォルトの名無しさん
22/08/13 13:13:02.04 hNN+KHup.net
>>45-47
URLﾘﾝｸ(www.youtube.com)
566:デフォルトの名無しさん
[ここ壊れてます] .net
>>560
言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー
567:デフォルトの名無しさん
22/08/16 13:03:21.19 RcKGtcJQ.net
VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
Borrowed pointer typeの参照先の値ってデバッガ上でどうやったら見れるんですか？
568:デフォルトの名無しさん
22/08/18 15:17:30.09 nMYke7rH.net
参考までに、mutはドイツ語で勇気の意味です。
569:デフォルトの名無しさん
22/08/19 15:36:33.17 MNFQes9z.net
スレチ
570:デフォルトの名無しさん
22/08/19 15:56:19.49 WZnrgrRN.net
今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
Java Script全盛のこの時代にいちいちコンパイルするなんて面倒で仕方ない
571:デフォルトの名無しさん
22/08/19 17:51:45.38 jOBplE6P.net
釣りは隔離スレでどうぞ
572:デフォルトの名無しさん
22/08/21 14:52:30.50 j3ukytx2.net
RUST大流行だな
ほんと紛らわしい
573:デフォルトの名無しさん
[ここ壊れてます] .net
この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの？
574:デフォルトの名無しさん
22/08/21 21:36:56.87 RCuqOQsW.net
確か燃え尽き症候群で自分から離れたんじゃなかったかな
575:デフォルトの名無しさん
[ここ壊れてます] .net
嘘のようにボロ負けしたんだろうな
576:デフォルトの名無しさん
22/08/22 12:22:08.49 +Lu+Ewk5.net
ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
不要だろ。
jsでカーネルのラードンをつくる猛者まで出てきた
577:デフォルトの名無しさん
22/08/25 01:05:28.98 YZq8nn1p.net
Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか？
578:デフォルトの名無しさん
22/08/25 02:02:11.07 sE5vq5kZ.net
範囲はHashMap全体たが
Arc単体で提供するスレッドセーフはimmutableな共有所有のみ
その例だとHashMapは読み取り専用になる
他を要求するなら他と組み合わせる
まずArcは置いといて単独所有の時
整数やブールならAtomicXxxでスレッドセーフ
一般的な型ならMutex<T>
読み取り同時複数ならRwLock<T>
それぞれコストが異なるので使い分ける
その上で共有所有ならArc<.....>をそれらの上に被せる
579:デフォルトの名無しさん
22/08/25 02:06:21.10 mMVVZ1qM.net
T1, T2がSend/Syncな前提だよね？
580:デフォルトの名無しさん
22/08/25 21:50:49.35 sE5vq5kZ.net
もちろんTがSync+Sendの時のみ
Arc<T>はSync+Sendとなる
581:デフォルトの名無しさん
22/08/25 23:42:19.60 3Alfspxr.net
条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
間違えていても安全でなくてもコンパイルが通ってしまい実行時に酷い目に合う従来の言語
582:デフォルトの名無しさん
22/08/26 03:34:10.56 7ybirmBf.net
Test
583:デフォルトの名無しさん
22/08/26 10:06:51.61 i2SIEm4o.net
>>576
コンパイル通ったら安心と思い込む馬鹿
584:デフォルトの名無しさん
22/08/26 10:39:24.20 z3bi9+6P.net
そいつには触れるな
585:デフォルトの名無しさん
[ここ壊れてます] .net
>>578
思い込みで誤読しているあんたが馬鹿っぽい
>>576にはそんなこと書かれていない
586:デフォルトの名無しさん
22/08/27 02:23:31.10 4TEBlXJK.net
>>578
日本語読めないバカ
587:デフォルトの名無しさん
[ここ壊れてます] .net
>>578
うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。
588:デフォルトの名無しさん
22/08/27 13:37:40.60 VvCUXBS7.net
デバッグスキル0の奴がビルドだけでOKとか思いたがるんだわ。
589:デフォルトの名無しさん
22/08/27 14:27:59.40 fe4GQDaF.net
>>582
その会社ヤバくない？
大丈夫？
590:デフォルトの名無しさん
[ここ壊れてます] .net
確証バイアスかな？
591:デフォルトの名無しさん
22/08/27 20:57:03.41 0qPHVCED.net
>>585
お前ヤバくない？
大丈夫？
592:デフォルトの名無しさん
22/08/31 02:03:15.88 Lk5NPDCj.net
最強無敵言語age
593:デフォルトの名無しさん
22/08/31 08:04:44.83 +Igep1U8.net
>>587
入門者相手には最強だよな。
594:デフォルトの名無しさん
[ここ壊れてます] .net
急に書き込み減ったけどもう飽きられたの？
Scalaのときもそうだったけどエンジニアがこういう読みにくい言語で現場を遊び散らかして負債だけ残すの何とかして欲しいわ
595:デフォルトの名無しさん
[ここ壊れてます] .net
?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
せめて検索性に配慮して記号を決めればな。?::くらいにしても問題ないだろうに。
596:デフォルトの名無しさん
[ここ壊れてます] .net
ピークを過ぎた感はある
Scalaで遊んでたのはDDDとか高レイヤの好きな意識高い系が中心だったからまあそこまで酷い負債にはなってないけど、
その点Rustの負債はタチが悪そうだな
597:デフォルトの名無しさん
[ここ壊れてます] .net
Amazonがプログラミング言語「Rust」を使っている理由
URLﾘﾝｸ(japan.zdnet.com)
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:デフォルトの名無しさん
22/08/31 10:44:22.32 nTGfEW2M.net
>>590
そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ？
599:デフォルトの名無しさん
22/08/31 12:13:30.34 Fgf/9Zy6.net
>>590
文法は場当たり的に学ばないで初学者向けドキュメント読んだ方が良いと思うけどそれは置いておいて、
rust operatorでググって出てくるこれ参照して演算子の意味調べてもう一度ググれば良いのでは
それすらめんどくさい？
URLﾘﾝｸ(doc.rust-lang.org)
600:デフォルトの名無しさん
22/08/31 12:30:09.46 836P0mbg.net
question markとかsemicolonで調べればいいんだよ
601:デフォルトの名無しさん
22/08/31 12:34:08.26 J/OAC0EF.net
例えば
question mark site:doc.rust-lang.org
で検索すれば必要な解説がすぐ見つかる
602:デフォルトの名無しさん
[ここ壊れてます] .net
>>593
公式に「チュートリアル」てあったっけ？
THE Book読めということかしらん？
>>594
Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……
>>595
公式の解説出てこないんだけど、公式には説明無いんかね？
603:デフォルトの名無しさん
[ここ壊れてます] .net
>>596
おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。
604:デフォルトの名無しさん
[ここ壊れてます] .net
>>597
エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい
605:デフォルトの名無しさん
22/08/31 13:39:17.87 lcZ+Kyy5.net
所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。
606:はちみつ餃子
22/08/31 13:42:22.79 nTGfEW2M.net
>>597
> THE Book読めということかしら
せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。
なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。
607:デフォルトの名無しさん
22/08/31 15:08:14.60 Fgf/9Zy6.net
>>600
所有権チェックをなくすってどういうこと？
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと？
608:デフォルトの名無しさん
22/08/31 16:15:20.37 bi3oBo/Y.net
コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理
609:デフォルトの名無しさん
22/08/31 16:22:04.68 UXqUoG+N.net
ビルドしなくてももっと気軽にわかるようにしろってことか？
linterの領域外れてる気もするが
610:はちみつ餃子
22/08/31 16:50:31.19 nTGfEW2M.net
細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。
611:デフォルトの名無しさん
22/08/31 16:56:11.73 LCT5ihCl.net
所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
後から直そうとか思うと結局全部作り直すはめになるから
一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね
612:デフォルトの名無しさん
22/08/31 17:04:46.18 BdHQqSBt.net
マンホールって卑猥な単語じゃね？
613:デフォルトの名無しさん
22/08/31 19:07:16.13 th8cAM8K.net
>>592
そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。
614:デフォルトの名無しさん
22/08/31 20:09:18.42 iogMBVhq.net
>>601
the book読めというのはさすがに初心者殺しだと思うけどなぁ。
公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん？
615:デフォルトの名無しさん
22/08/31 20:22:19.87 3b0JioqE.net
学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう
616:はちみつ餃子
22/08/31 20:35:16.89 nTGfEW2M.net
>>609
えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ？
(俺自身は英語あんまりわからんので日本語訳を読んだ。)
617:デフォルトの名無しさん
22/08/31 20:38:24.92 SRFkQuBk.net
>>609
the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている
？は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる
？をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く
618:デフォルトの名無しさん
22/08/31 20:53:00.34 bW00GV9W.net
>>605
>>606
同意。
619:デフォルトの名無しさん
22/08/31 21:03:24.41 p14sgl1j.net
すべてがunsafeな世界になる
620:デフォルトの名無しさん
22/08/31 21:22:41.70 rT6IO02J.net
生きている限り安全なんてない
621:デフォルトの名無しさん
22/08/31 23:52:36.28 X48LRlQ+.net
ポエムはいいです
622:デフォルトの名無しさん
22/09/01 00:17:11.56 gQhEx8vQ.net
そうそうポエムいいよなぁ
みつヲ
623:デフォルトの名無しさん
22/09/01 01:28:45.35 v92yFclD.net
今時、ネイティブ吐く必要なんて全くない
tsでもvscのようなソフトが作れるんだし。
624: ユーザーランドではネイティブはもはや不要だろ
625:デフォルトの名無しさん
22/09/01 02:19:44.48 UU16wx/t.net
もしかしてelectron知らないのかしら
626:デフォルトの名無しさん
22/09/01 08:30:45.73 +imQtRK+.net
スクリプトって知らないのかしらん？
627:デフォルトの名無しさん
22/09/01 09:29:49.86 WQm7Gv/J.net
vscはコア部は全部C++だけど。
そのうえに薄くjs乗ってるだけやがな。
628:デフォルトの名無しさん
22/09/01 09:46:54.90 NH2cx+n6.net
Tauri (Rust) vs. Electron (C++)の戦いの結果…
＞ Electronの代替を目指す軽量なRust製フレームワーク「Tauri」
＞ URLﾘﾝｸ(www.publickey1.jp)
＞
＞ Electronはフロントエンドの基盤としてChromiumを組み込んでいますが、
＞ Tauriでは代わりに各OSが備えているWebViewの機能を、抽象化レイヤのwry経由で呼び出すことで、
＞ クロスプラットフォームを実現しつつChromiumを不要にしています。
＞ フレームワーク内にChromiumを組み込まないことでセキュリティも向上すると、Tauri開発チームは説明しています。
↓ 「マジ？！」と思っていたらマジだった！！
＞開発フレームワーク「Electron」に複数の脆弱性
＞URLﾘﾝｸ(news.mynavi.jp)
＞
＞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:デフォルトの名無しさん
22/09/01 12:18:02.95 Wlby5VAy.net
>>621
そうなん？わりとネイティブが薄くてTSが主体だと思ってた。
630:デフォルトの名無しさん
22/09/02 12:29:12.76 EMfEx7SW.net
GUIがtsの時点でお察し
やたらとモッサリしてんじゃん
631:デフォルトの名無しさん
22/09/02 22:13:08.24 06QeBluE.net
--emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある？
gas系っぽく見えるけどちょいちょい判らないのが・・・
632:デフォルトの名無しさん
22/09/02 22:55:35.95 TRifMPKk.net
--emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ
633:デフォルトの名無しさん
22/09/04 14:45:48.94 c9grlmUi.net
VScodeがもっさりは感じたことないな
ネイティブのVSのほうが重すぎ
634:デフォルトの名無しさん
[ここ壊れてます] .net
関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの？
635:デフォルトの名無しさん
22/09/05 15:19:35.29 TAlRHagA.net
そんなユースケースあるの？
636:デフォルトの名無しさん
22/09/05 15:31:51.51 TaR2CBOa.net
>>629
隔離スレでドヤりたいというユースケース
637:デフォルトの名無しさん
22/09/05 15:54:23.38 vyOP5LW0.net
いつも隔離スレのここが機能してくれて助かってます
638:はちみつ餃子
22/09/05 16:16:12.15 QNR7HRCU.net
>>628
一旦変換すりゃいいだけなんじゃないの。 知らんけど。
639:628
22/09/05 17:50:42.31 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:デフォルトの名無しさん
22/09/05 17:54:10.85 vXwuqGKm.net
>>633
シャドーイングできるからテンポラリの変数名は不要だよ
let x = x as u32;
でいい
641:デフォルトの名無しさん
22/09/05 19:20:47.36 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:デフォルトの名無しさん
22/09/05 19:21:35.07 g3RfqaIY.net
>>635
2行目間違えた
as i32 に読み替えて
643:デフォルトの名無しさん
[ここ壊れてます] .net
>>633
その例は手動で最適化すると
fn func(_x: u8, y: u8) -> u8 {
y
}
それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ
644:デフォルトの名無しさん
[ここ壊れてます] .net
x < y の場合考慮してなさそう
645:デフォルトの名無しさん
22/09/05 21:53:26.61 wI2HBmBd.net
ホントだごめん訂正
fn func(x: u8, y: u8) -> u8 {
y - (x < y) as u8
}
646:デフォルトの名無しさん
22/09/06 00:31:42.49 EiVnVIDc.net
結局u8で返すなら
途中でi32使わずとも
工夫するとu8のままだけで算出できちゃったりするわけか
647:デフォルトの名無しさん
22/09/06 00:52:56.28 uJFa29+7.net
逆方向にシフトした場合は？
そんな用途があるのか知らんけど
648:デフォルトの名無しさん
22/09/06 01:12:27.41 EiVnVIDc.net
>>641
それはu8部分の下位8bitが常にゼロとなって
足しても引いても影響ないかな
649:628
22/09/06 11:02:40.94 xGSGq1SQ.net
スタンダードな書き方みたいなのはないのかな
なら>>634で行こうと思います
あと>>633は右シフトを間違えていました
16ではなく8です
650:デフォルトの名無しさん
22/09/07 08:11:56.26 8saglJYc.net
Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの？
651:デフォルトの名無しさん
22/09/07 08:24:04.31 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:デフォルトの名無しさん
22/09/07 23:31:51.68 qqHULq33.net
native endianというのは初めて聞いたのですが、これはどういうものなのですか？
653:デフォルトの名無しさん
22/09/07 23:54:21.35 En8I5Kb5.net
この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと
特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが
そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います
一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います
654:デフォルトの名無しさん
22/09/08 00:04:41.95 nmwPOGZ0.net
>>645
サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう
デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する
みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった
655:デフォルトの名無しさん
22/09/08 00:19:17.65 8UoQH6yi.net
>>648
操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン
だから原則としてネイティブエンディアンのみでプログラミングする
例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換
656:はちみつ餃子
22/09/08 00:23:28.76 MG9wnc1h.net
>>648
内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。
でも普通はそんな煩雑なことをしたくないから
内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、
言語やライブラリも基本的には一般的な構成に倣っている。
657:デフォルトの名無しさん
22/09/08 01:11:28.44 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:デフォルトの名無しさん
22/09/08 01:21:33.97 5HeI/FQK.net
mansplainers
660:デフォルトの名無しさん
22/09/08 15:55:57.30 Vswe11EN.net
RustをOpenMPIに対応させるようなプロジェクトってありますか？
661:デフォルトの名無しさん
22/09/08 16:49:24.48 mLv3aAxt.net
「Rust OpenMPI」でGoogle検索
662:デフォルトの名無しさん
22/09/08 18:02:42.70 U6/gufpm.net
OpenMP なのか Open MPI なのかどっち
663:デフォルトの名無しさん
22/09/08 20:45:38.87 Vswe11EN.net
知りたいのはOpenMPIの方です
ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・
664:デフォルトの名無しさん
22/09/08 20:53:50.25 RwfCQI7B.net
一番上のrsmpiは違うの
665:デフォルトの名無しさん
22/09/08 21:56:17.41 fa0yFdt8.net
MPIはHPC以外では使う必要ないです
機械学習でも有用だとは思いますが
そもそもフレームワークが対応していないから
全部自前で作ってるような人以外は必要ないです
666:デフォルトの名無しさん
22/09/09 01:14:31.51 4b4Wyf25.net
Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは
667:デフォルトの名無しさん
22/09/09 08:12:49.36 auDHI5c1.net
良くありがちな奴だと思うけど
struct ARGB32 {A: u8, R: u8, G: u8, B: u8,}
みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの？
これ小文字にしちゃったら少なからず可読性が落ちるよね
668:デフォルトの名無しさん
22/09/09 08:31:41.27 WeF8ASv0.net
#[allow(non_snake_case)]
しかしフィールド名だけ小文字にすれば不要
struct ARGB32 {a: u8, r: u8, g: u8, b: u8,}
そして可読性が落ちると思わない
669:デフォルトの名無しさん
22/09/09 09:24:21.25 4b4Wyf25.net
構造体名もCamelCaseでArgb32とすべきかな
670:デフォルトの名無しさん
22/09/09 12:29:38.55 6YdHvwwi.net
識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
略語を使わずに書くとこうかね？
Color<T>{alpha: T, red: T, green: T, blue: T}
CMYはどうなるとか言い出すやつがいると面倒そうだけど。
671:デフォルトの名無しさん
22/09/09 12:42:45.67 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:デフォルトの名無しさん
22/09/09 13:41:22.02 4b4Wyf25.net
最低限ガイドには従った方が良いと思う
URLﾘﾝｸ(rust-lang.github.io)
acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき
あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは
規約に従ってないライブラリも多いけど
そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない
673:はちみつ餃子
22/09/09 14:02:11.22 gp9Eay33.net
API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。
674:デフォルトの名無しさん
22/09/09 14:15:33.61 +r9uXbjm.net
>>661
個人的にはこっちの方が好きだけど
規約的にダメなら仕方ない
675:デフォルトの名無しさん
22/09/09 14:42:45.26 4b4Wyf25.net
>>666
非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、
最初から内部も規約に従ったものにしておいた方が良いと思う
そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では
676:デフォルトの名無しさん
22/09/09 15:18:27.40 QLGZdL8Z.net
mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。
677:デフォルトの名無しさん
22/09/09 15:35:09.62 7NqN1r1N.net
gameraとか？
678:デフォルトの名無しさん
[ここ壊れてます] .net
>>669
94年初リリースで98年ソース公開で
数年遅れるとは？
679:デフォルトの名無しさん
22/09/09 17:53:00.11 rfSAUeXI.net
CreateFileW in windows::Win32::Storage::FileSystem - Rust
URLﾘﾝｸ(microsoft.github.io)
とかAPIガイドラインもクソもないけど名前だけRustに寄せたところでリファレンスドキュメント(MSDN)との差異が
拡大するだけでメリットはほとんど無いような
680:デフォルトの名無しさん
22/09/09 21:16:36.10 pyHRaXAz.net
JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる
681:デフォルトの名無しさん
22/09/09 22:46:34.35 B0h43lqZ.net
>>673
同意
682:デフォルトの名無しさん
22/09/10 00:32:32.71 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:デフォルトの名無しさん
22/09/10 01:19:16.36 BhJh8aSd.net
acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな
一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが
684:デフォルトの名無しさん
22/09/10 03:00:06.93 Rsh0NV07.net
Ipv4なんて一瞬なんのことか分からんかったな
結局慣れで、一貫性以上に価値のある好みなんてのはない
685:デフォルトの名無しさん
22/09/10 07:09:44.43 2MfL7Eat.net
>>676
その一貫性が崩れるのがいやなんだろ。
ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。
慣れの問題だが、今まで/一般的 に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。
686:デフォルトの名無しさん
22/09/10 07:12:21.94 2MfL7Eat.net
>>676
問題の大小なんて誰も言ってない。
今までの慣れ/一般的な表記 を置き換えるのは抵抗感あるって話。
687:デフォルトの名無しさん
22/09/10 12:37:11.73 GXRB1/O5.net
命名規則を利用する目的は可読性や開発効率の向上などのはず
一般的な表記から外れるのであればそれなりの理由が必要であろう
「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと
突っ込まれてもしょうがない
688:デフォルトの名無しさん
22/09/10 13:03:13.98 jQKLnU5m.net
JavaScriptのアイツは
XmlHttpRequestと命名されるべきだったのか？
XMLHTTPRequestと命名されるべきだったのか？
689:デフォルトの名無しさん
[ここ壊れてます] .net
eXtend Markup Language Hyper Text Transfer Protocol Request
690:デフォルトの名無しさん
[ここ壊れてます] .net
完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、
LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから
表記の慣例とか無視して全部キャメルケースにしちゃうな
691:デフォルトの名無しさん
22/09/10 13:50:29.86 TnGNUz3W.net
ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった
692:デフォルトの名無しさん
22/09/10 14:31:16.93 /uHulLcW.net
Rustすれのレベルの低さにガッカリ
Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ
693:デフォルトの名無しさん
22/09/10 14:56:40.59 qBfKxAEz.net
>>675みたいに書いた場合
>let mut bitmap:[u32; LEN] = [0; LEN];
のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし
mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている
参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど
なんか上手い書き方はないのだろうか
この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし
どこを見たらいいのか判らない
694:デフォルトの名無しさん
22/09/10 15:47:06.47 BhJh8aSd.net
>>675
ARGB32にDefault実装して
let mut bitmap : [ARGB32; LEN] = Default::default();
とするのが良いかと
repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う
695:デフォルトの名無しさん
22/09/10 15:48:16.32 vDnMZIxl.net
>>675
初期化難しいかな。こうとか
URLﾘﾝｸ(play.rust-lang.org)
696:デフォルトの名無しさん
22/09/10 15:54:53.07 BhJh8aSd.net
>>687
[T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった
こっちならOK
let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default());
697:デフォルトの名無しさん
[ここ壊れてます] .net
最後の手段のtransmuteは安易に使うものじゃないと思う
698:デフォルトの名無しさん
22/09/10 16:39:14.44 qBfKxAEz.net
>>687
すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず
repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが
>>688
CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです
原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ
コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの
切り替え方法が判らない)
699:デフォルトの名無しさん
22/09/10 18:12:40.24 n3Y/KVD/.net
>>686
最初に定義した変数bitmapはmoveしてるだけだからmutは余計でいいと思うけど？
700:デフォルトの名無しさん
22/09/10 19:24:52.82 qBfKxAEz.net
>>692
自分の理解があっているか不安なんですが、mutを付けずにletで宣言すると書き換わらない値として
書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です
言語仕様上mutを付けない宣言でも必ず読み書き可能な領域に配置されるというのであればそれでかまわないと思いますが
とりあえず手元のx64向けのコンパイラではmutを付けずともスタックフレームに配置されるようですが
組み込み向けなど他のコンパイラでも同様の動作を前提として問題ないのか判りません
古いバージョンのBookにはスタックやヒープの解説があったようですが
URLﾘﾝｸ(web.mit.edu)
最新版にこのページはないような・・・しかも
>Rust ‘stack allocates’ by default, which means that basic values ‘go on the stack’.
だとRAMを節約したいからROMに配置する実装もあり得ると読めなくもない
701:デフォルトの名無しさん
[ここ壊れてます] .net
let bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};
これでいいってことじゃない？
一個目のbitmapは実際書き込んでないからmut不要
二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要
702:デフォルトの名無しさん
[ここ壊れてます] .net
あぁ言いたいことは分かった
確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね
ただそれは別にmutをつけても保証はされない気がする
703:デフォルトの名無しさん
22/09/10 20:24:18.78 BhJh8aSd.net
>>691
repr(packed)を指定した構造体のフィールドへのアクセスは未定義動作を引き起こす可能性があるからrepr(packed)は基本的には使わない方が良いよ
URLﾘﾝｸ(doc.rust-lang.org)
確かにrepr(C)やrepr(Rust)はパディングされる可能性があるけど、フィールドのアラインメントを適切にするために必要なものなので
パディングが問題になるならフィールドのメンバーの順序やサイズを見直すか、フィールドの値を読むのに std::ptr::read_unaligned を使う必要があるよ
URLﾘﾝｸ(doc.rust-lang.org)
read_unalignedのドキュメントにも書いてあるけど、アライメントが不適切なフィールドへの参照を作るのすら未定義動作になるという落とし穴もあったり、
repr(packed)な構造体の取り扱いにはいろいろと注意が必要になるので、本当に必要なとき以外は使わない方が良いよ
あと、repr(packed)はrepr(packed, Rust)と同じ意味になるので、構造体のフィールドがメモリ上でどのような配置になるかの保証はないよ
フィールドの定義順とメモリ上での順序を同じにしたいのであれば repr(C) または repr(C, packed) と指定する必要があるよ
いずれにせよ今回は全てのフィールドがu8だからrepr(C)でパディングが挿入されることはなく
無駄にメモリを消費することもないよ
どうしてもパディング挿入が心配なら mem::size_ofやmem::align_ofを使って構造体のサイズとアライメントに関するアサーションを加えるのが良いと思う
704:デフォルトの名無しさん
22/09/10 20:36:28.31 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に変換するみたいなことをすると未定義動作になるから注意は必要
URLﾘﾝｸ(doc.rust-lang.org)
> 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:デフォルトの名無しさん
22/09/11 12:51:18.94 6axTKkj4.net
>>693
＞mutを付けずにletで宣言すると書き換わらない値として
＞書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です
しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。
706:デフォルトの名無しさん
22/09/11 13:08:43.20 3JeGkSLy.net
今はしないけどそうなるような最適化は禁止されてないのでは
707:デフォルトの名無しさん
22/09/11 13:49:03.04 7UmicIsS.net
コンパイル時に値が確定してないとtextセクションに書けないでしょ
708:デフォルトの名無しさん
22/09/11 13:55:35.90 VMVpvyTB.net
そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない
709:デフォルトの名無しさん
22/09/11 13:57:25.52 kEOVMHNm.net
コンパイル時に確定するような式なら最適化でありえるんじゃないの？
710:デフォルトの名無しさん
22/09/11 14:07:54.90 VMVpvyTB.net
どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される
そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう
711:デフォルトの名無しさん
22/09/11 14:40:44.81 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:デフォルトの名無しさん
22/09/11 14:49:25.24 FOB38Q8d.net
そのような実装はしたくないわけですか
713:デフォルトの名無しさん
22/09/11 15:13:19.03 /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:デフォルトの名無しさん
22/09/11 18:54:24.82 gEyGQ7vE.net
このスレでよく出てくる μt ってなんなん？
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの？
715:デフォルトの名無しさん
22/09/11 20:25:15.55 FOB38Q8d.net
自分も思ったけどブラウザによっては & mut がそうなるみたい
716:デフォルトの名無しさん
22/09/11 20:27:57.44 QYXgEc7E.net
>>708
そうなんだ。
717:デフォルトの名無しさん
22/09/11 20:45:42.63 hnVgjqVb.net
>>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。
718:デフォルトの名無しさん
22/09/11 21:25:51.88 zZ32ojSE.net
HTMLの文字参照で& muがμ
719:デフォルトの名無しさん
22/09/11 21:45:56.06 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:デフォルトの名無しさん
22/09/11 21:47:41.04 3JeGkSLy.net
>>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする
今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね
721:デフォルトの名無しさん
22/09/11 21:50:14.96 3JeGkSLy.net
>>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは
722:デフォルトの名無しさん
22/09/11 23:45:21.14 ujBIW69o.net
Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし
>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし
>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開＆最適化されますかね？一つでもコールやブランチが残ったら速度が結構落ちるだろうし
723:デフォルトの名無しさん
22/09/11 23:59:30.49 /O1tQPyF.net
>>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい
724:デフォルトの名無しさん
22/09/12 00:37:31.19 5hhAOS+Q.net
&mut テスト
725:デフォルトの名無しさん
22/09/12 01:00:12.66 JkhjRZ+U.net
>>716
ほー、chmateはワザとunescapeしてるのか？
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな
726:デフォルトの名無しさん
22/09/12 01:13:39.26 D0TZxDhn.net
HTML等の文字参照を処理する場合でも
μt (＝ & m u ; t )が μt となるのは正しいけど
&mut (＝ & m u t )が μt となるの間違いだからこれはバグと思われる
727:デフォルトの名無しさん
22/09/12 02:30:39.40 JkhjRZ+U.net
あ、たしかにバグっぽい・・・
728:デフォルトの名無しさん
[ここ壊れてます] .net
文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う
729:デフォルトの名無しさん
22/09/12 07:14:45.53 tyJETXG8.net
これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです
730:デフォルトの名無しさん
22/09/12 07:33:21.32 o/NFQNbK.net
&mut と書けば良いかな
テスト → &mut
731:デフォルトの名無しさん
22/09/12 07:34:32.06 o/NFQNbK.net
& amp ; amp; を空白なしで書き込んだら & に変換されてしまった
実体参照複数回展開しているのかな
&
732:デフォルトの名無しさん
22/09/12 08:15:16.27 NGx/fsjU.net
ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です
最適化レベルによる変化とか全然確認出来ないし
733:デフォルトの名無しさん
22/09/12 08:36:58.55 tyJETXG8.net
ちょっと意味がわからない
こうなるはずだから困ることはないと思うけど
・最適化によってRustが定めている意味が変わることはない
・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない
・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える
734:デフォルトの名無しさん
22/09/12 10:25:58.86 o/NFQNbK.net
genericな関数だと呼び出し元がないとコード生成されないとか？
735:デフォルトの名無しさん
22/09/12 12:04:36.56 tyJETXG8.net
その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ
736:デフォルトの名無しさん
22/09/12 12:46:09.29 SjJDv8F6.net
>>726
ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる
pub extern "C"でRust外の入出力にしてようやく消えなくなる
もうちょっと調べてみる
737:デフォルトの名無しさん
22/09/12 14:30:52.03 o/NFQNbK.net
>>729
ちなみにターゲットはbinと(r)libのどっち？
binならpubでも消えるかも
738:デフォルトの名無しさん
22/09/12 19:11:31.91 2zIjStdY.net
>>730
変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ
とりあえずrlibにしておいてある程度形になってきたら変更すればいいか
コード自体はどっちでも大差ないだろうし
739:デフォルトの名無しさん
22/09/18 01:08:32.32 g4sMxKuf.net
[u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど
740:デフォルトの名無しさん
22/09/19 02:33:25.46 HMAR4dxa.net
Tauriで動画プレーヤー的なのを作るサンプルってどっかにある？
ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい
あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい
741:デフォルトの名無しさん
22/09/19 07:48:35.44 BbpMxDy4.net
TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ？
そして既存のWeb技術を活かせるのがTauriの利点だろ？
そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか？
Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ？
742:デフォルトの名無しさん
22/09/19 12:27:41.81 HMAR4dxa.net
>>734
>HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中
ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか？なんか無駄に実装量が増えるけど
743:デフォルトの名無しさん
22/09/19 13:11:44.57 PTk7Q+2G.net
その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない？
744:デフォルトの名無しさん
22/09/19 18:38:49.00 EybjBREq.net
なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう
745:デフォルトの名無しさん
22/09/19 18:45:15.20 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:デフォルトの名無しさん
[ここ壊れてます] .net
trait Sealed {}
pub trait Same<T>: Sealed {}
747:デフォルトの名無しさん
22/09/19 21:19:03.69 EybjBREq.net
URLﾘﾝｸ(rust-lang.github.io)
748:デフォルトの名無しさん
22/09/19 21:29:04.18 Elo9mBmF.net
ふたつの型が同じという制約を付けたいなら
TとUじゃなくTとTにすればいいじゃんか
749:デフォルトの名無しさん
22/09/19 21:34:13.52 jWPeXdq1.net
>>738
達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。
enum Same{SameA(型A),SameB(型B)}
みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。
750:デフォルトの名無しさん
22/09/19 22:48:26.11 npVSxydm.net
>>739-740
実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。
しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。
この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。
>>741
そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。
Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、
説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。
いわゆるXY問題というものの存在は承知しておりますので
解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。
わかりますが、大元の問題というものはありません。
この範囲で完結するパズルだと思ってください。
751:デフォルトの名無しさん
22/09/20 00:14:22.92 nBuFqijL.net
2つの矛盾してる要求を同時に実現は無理だわな
752:デフォルトの名無しさん
22/09/20 00:42:08.53 FykVNAq+.net
impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ
753:デフォルトの名無しさん
22/09/20 00:43:28.04 FykVNAq+.net
fundamentalな型に一通り実装しておけば良さそう
754:デフォルトの名無しさん
22/09/20 00:48:25.82 FykVNAq+.net
URLﾘﾝｸ(play.rust-lang.org)
755:デフォルトの名無しさん
22/09/20 00:50:06.23 FykVNAq+.net
fundamental云々はcoherent ruleの話でconflictとは関係なかったわ
756:738
22/09/20 01:17:29.77 w2qVrruo.net
なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
&T とか &mut T とかも先に実装しておけば追加の余地をなくせると。
&T とか &mut T とか以外にどういうのがありえますかね？
757:デフォルトの名無しさん
22/09/20 01:40:45.09 lHbnVGdk.net
>>743
Sealedも<T>にすればいいんじゃないの
URLﾘﾝｸ(play.rust-lang.org)
758:738
759:ge
>>750 ありがとうございます。 言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。
760:デフォルトの名無しさん
22/09/20 18:26:27.74 p9SiwD2d.net
「Linux」、バージョン6.1でRustを導入へ--トーバルス氏が明言
URLﾘﾝｸ(japan.zdnet.com)
761:デフォルトの名無しさん
22/09/20 20:25:26.21 ckEqOjly.net
>>752
いいね
ここ最近で一番いい知らせだわ
762:デフォルトの名無しさん
22/09/20 20:46:56.46 Di+jgu/u.net
今のところデバドラだけという話だけど
基幹部分の新実装をRustで作りましたという
人が絶対現れるからそのときどうなるだろ
763:デフォルトの名無しさん
22/09/20 20:51:48.09 rUHkgvjw.net
誰もvoldemort typeの名を呼ぼうとしない
764:デフォルトの名無しさん
[ここ壊れてます] .net
MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど
Visual StudioでもRustが最初からパッケージングされてるようになるのかな
765:デフォルトの名無しさん
22/09/22 09:05:24.01 e5bGjsaE.net
URLﾘﾝｸ(www.publickey1.jp)
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に
766:デフォルトの名無しさん
22/09/22 13:36:58.59 V4zanZlp.net
>>756
MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない?
いまさらVSに対応言語を追加する気はないでしょ
どう考えてもWindowsユーザーは少ないだろうし
767:デフォルトの名無しさん
[ここ壊れてます] .net
>>756
マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。
インサイドWindowsにはお世話になったわ。
768:デフォルトの名無しさん
22/09/23 05:18:56.24 I8UIrhRk.net
Iteratorに対するIntoIteratorのように
Futureに対するIntoFutureということか
しかも.awaitに対して自動適用だからもっと効果が大きいか
非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる
769:デフォルトの名無しさん
22/09/23 08:24:08.00 G8O+P73a.net
Rust analyzerが優秀過ぎてMSが入る余地なさそう
PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう
VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな
770:デフォルトの名無しさん
22/09/23 08:29:43.60 exFn1ITS.net
Rustからから.Net?
意味ないやろ...
771:デフォルトの名無しさん
22/09/23 10:08:58.99 QyFSmn0+.net
既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとな
772:る可能性もあるので意味はある
773:デフォルトの名無しさん
[ここ壊れてます] .net
Rust/Cliとか余計なもの作られそう
774:デフォルトの名無しさん
22/09/23 12:31:56.94 aakQSAhx.net
>>758
VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな
775:デフォルトの名無しさん
22/09/23 17:48:32.43 z6wpDrU6.net
>>762
書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった
GoのCGoみたいな仕様だったら色んな意味で面白いと思う
776:デフォルトの名無しさん
22/09/23 18:02:01.54 bhLcJIv7.net
rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか？
編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです
Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます
777:デフォルトの名無しさん
22/09/23 18:02:58.63 exFn1ITS.net
>>766
ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな
778:デフォルトの名無しさん
22/09/23 18:04:41.93 nucVVsrt.net
>>767
まあ普通はGitを使うからね
779:デフォルトの名無しさん
22/09/23 18:05:33.15 5/jqA4bf.net
C#も.Netも全く興味ないので知らないが
PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている
既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている
780:デフォルトの名無しさん
22/09/23 21:26:00.89 Oi43IjEf.net
repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ
781:デフォルトの名無しさん
22/09/23 21:26:44.38 bhLcJIv7.net
>>769
でも、破棄ならコミット後の状態にも戻せるぜ？
782:デフォルトの名無しさん
22/09/23 21:42:44.57 KYVSlV2v.net
>>771
ABI安定化するまではFFIでextern "C"は避けられないよ
783:デフォルトの名無しさん
22/09/23 21:53:19.36 wlVyCNVq.net
>>773
そんなことすべきでない
自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト
外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい
784:デフォルトの名無しさん
22/09/23 23:40:33.31 EyovOcQI.net
双方でマーシャル/アンマーシャルが必要になって無駄だよね
785:デフォルトの名無しさん
22/09/23 23:55:09.24 9eaiNZZz.net
なるほど
786:デフォルトの名無しさん
22/09/23 23:58:10.15 SxK8BSHj.net
対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない