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で書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない
787:デフォルトの名無しさん
22/09/24 00:06:07.91 j2XeJCoN.net
やっぱエアプの複オジはわかってないなぁ
788:デフォルトの名無しさん
22/09/24 00:11:50.36 DaB/WDgt.net
>>774
pubなitemのABIに最適化関係ある？
なんかと混同してない？
789:デフォルトの名無しさん
22/09/24 00:14:18.76 DaB/WDgt.net
もしかして repr(Rust) のこと言ってる？
790:デフォルトの名無しさん
22/09/24 03:05:40.90 ugWjDAH5.net
Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう
結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう
791:デフォルトの名無しさん
22/09/24 08:50:49.84 pfcr5AFZ.net
C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？
792:デフォルトの名無しさん
22/09/24 09:11:44.18 DaB/WDgt.net
>>781
dylibの場合pubは大いに関係あるよ
793:デフォルトの名無しさん
22/09/24 09:15:16.80 WR9fIR0K.net
ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ
794:デフォルトの名無しさん
22/09/24 09:26:53.29 rPP8Qygy.net
>>782
名前をプログラマが決められるからだよ
795:デフォルトの名無しさん
22/09/24 09:44:37.12 BCuennz9.net
>>782
むしろCは決まってるの？
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな
796:はちみつ餃子
22/09/24 10:38:04.73 2HWwrIyG.net
近年になって作られた高速リンカ mold の作者の話でも、
文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。
C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし
どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、
結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が
解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。
797:デフォルトの名無しさん
22/09/24 11:00:33.46 DaB/WDgt.net
CはCPUベンダーが呼び出し規約を文書化してるよ
moldの話はELFやリンクに関連する話では
確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う
798:デフォルトの名無しさん
22/09/24 11:33:36.58 FWSMvJVe.net
AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？
>>786
呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ
799:デフォルトの名無しさん
22/09/24 13:14:15.81 DaB/WDgt.net
>>789
そこでいう実装依存ってプラットフォームごとの差違のこと？
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？
800:デフォルトの名無しさん
22/09/24 14:25:21.27 PoJJisuz.net
cdeclとかstdcallみたいなやつ？
801:はちみつ餃子
22/09/24 16:06:51.67 2HWwrIyG.net
>>791
その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。
802:デフォルトの名無しさん
22/09/24 16:24:43.84 PoJJisuz.net
>>792
コンパイラがリンカに渡す情報って統一規格があるの？
803:デフォルトの名無しさん
22/09/24 17:05:25.99 7d8zqodE.net
>>793
別に統一されちゃいないがELFとかPEとか
804:デフォルトの名無しさん
22/09/24 17:10:20.79 GMpouZpq.net
じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？
805:はちみつ餃子 ◆8X2XSCHEME
[ここ壊れてます] .net
>>795
ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。
806:デフォルトの名無しさん
22/09/24 19:08:36.35 eDCmZTMq.net
ARMの規約
URLﾘﾝｸ(github.com)
807:デフォルトの名無しさん
22/09/24 22:13:22.85 DaB/WDgt.net
元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
LLVMがよしなにやってくれるのでは
808:デフォルトの名無しさん
22/09/24 22:29:32.09 GMpouZpq.net
ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね？
809:デフォルトの名無しさん
22/09/25 08:24:33.85 j3K9KjV7.net
Option<NoneZeroUsize>などを使えば
IDやカウンタなどの用途でOption<usize>などを使っていたものを
半分のメモリサイズで済むようになるの？
810:デフォルトの名無しさん
22/09/25 11:42:14.43 sQFmQmse.net
>>799
任せてください。符号ビット省略しておきますね
811:デフォルトの名無しさん
22/09/25 15:32:52.52 F2Viqk5M.net
Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない
812:デフォルトの名無しさん
22/09/25 17:24:00.83 xalR35FT.net
Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに
Microsoftはダメなの？
813:デフォルトの名無しさん
22/09/25 17:34:47.30 4B3i10Bx.net
try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ
814:デフォルトの名無しさん
22/09/25 17:57:47.12 6lgwXJxi.net
言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは
815:デフォルトの名無しさん
22/09/25 18:09:02.84 6wI0gbs/.net
正直LinuxにRustなんて辞めればいいのに・・・
816:デフォルトの名無しさん
22/09/25 18:14:08.03 Td47G6We.net
Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの
作り方の解説とかどっかにある？例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定
関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし
パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる
さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし
817:デフォルトの名無しさん
22/09/25 18:21:16.44 xalR35FT.net
テストがすごいのはSQLite
818:デフォルトの名無しさん
[ここ壊れてます] .net
>>803
別に独自拡張とか入れてないだろ
コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし
Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない
819:デフォルトの名無しさん
22/09/25 19:57:21.62 6lgwXJxi.net
>>806
なんかまずいことでもあるの？
820:デフォルトの名無しさん
22/09/25 19:59:47.96 Rxhh3DJ9.net
>>810
迷走と凋落、そして黒歴史化。
821:デフォルトの名無しさん
22/09/25 20:07:26.82 58piYD8Z.net
>>807
メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし
できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない
822:デフォルトの名無しさん
22/09/25 20:26:59.51 Td47G6We.net
>>812
条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした
関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい
で、テストを作ろうとしたけどどうしようか悩み中
823:デフォルトの名無しさん
22/09/25 20:37:27.14 lhW/fB5K.net
そういうのは呼び出し側の単体でええんちゃうの
824:デフォルトの名無しさん
22/09/25 21:09:49.29 j1+dHWho.net
>>807
歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。
対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。
歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。
825:デフォルトの名無しさん
22/09/25 21:31:04.61 Td47G6We.net
>>814
中間コンポーネントの単体テストって普通どうやるんだろ
後段のコンポーネントを切り離してテストするのか？繋げたままテストするのか？
切り離せるようにするとその部分にバグが入り込む余地が生まれるし
>>815
歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため
△△のような実装がベターだみたいなのが沢山あるからねぇ
そしてこの手の情報はググっても網羅するのが難しい
826:デフォルトの名無しさん
22/09/25 21:51:09.44 6lgwXJxi.net
>>811
Linux側にメリットがないと言ってる？
827:デフォルトの名無しさん
22/09/25 21:51:47.84 PDKGWlWe.net
>>816
> 中間コンポーネントの単体テストって普通どうやるんだろ
中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする
たいていのテストツールではモックの呼び出し回数のテストができる
828:デフォルトの名無しさん
22/09/25 21:53:52.45 j1+dHWho.net
>>816
JavaみたいにDIが発展しているタイプの言語だと中間コンポーネント�
829:ｪ呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。 けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。 モジュール設計の考え方が変わるからかな？
830:デフォルトの名無しさん
22/09/25 22:41:02.05 Td47G6We.net
今作っているのだとこんな感じかな？
関数C(データの前処理、処理単位への分割)
↓
関数B(処理全体の制御)→関数A'(処理1-2)
↓
関数A(処理1-1)
>>818,819
その場合モックへ切り替える機構はどうするんだろ
そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある
てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな
なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか
831:デフォルトの名無しさん
22/09/26 00:07:36.94 h/WE7ZWH.net
>>820
すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ
C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね
832:デフォルトの名無しさん
22/09/26 00:33:03.55 TCGzsvbI.net
mockall使うとか
833:デフォルトの名無しさん
22/09/26 06:28:19.26 p/pWEmYs.net
cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの？
834:デフォルトの名無しさん
22/09/26 06:47:39.41 h/WE7ZWH.net
>>823
>>820 > その場合モックへ切り替える機構はどうするんだろ
に答えてやってくれ
835:デフォルトの名無しさん
22/09/26 19:21:24.42 kI3cAlPQ.net
モックやスタブは別モジュール化しておいて
mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの？
836:デフォルトの名無しさん
22/09/26 19:31:47.69 V9yeC/LF.net
あと#[cfg(test)]でそれをuse
そして#[cfg(not(test))]で本物use
837:デフォルトの名無しさん
22/09/26 19:31:51.25 i/jndsoD.net
他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな
説明が面倒だ
838:デフォルトの名無しさん
22/09/26 19:38:20.09 V9yeC/LF.net
>>827
テスト以外の開発の話でも
フレームワークに依存してやってる人は
単純なこと含めて本質的なことを理解してない人が多く
フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける
839:デフォルトの名無しさん
22/09/26 21:10:39.16 qW/k82Qg.net
cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ
何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか
Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ
という思想の言語だと思っているんだが違うのかな
840:デフォルトの名無しさん
22/09/26 21:41:35.64 w5YNQb64.net
>>829
#ifは使わないし
cfg(test)はテスト分離のため必須でしょ
どんな環境でも魔法は無いよ
841:デフォルトの名無しさん
22/09/26 23:33:07.51 h/WE7ZWH.net
>>829
cfg使わないで済むいい方法があるなら書いてよ...
842:デフォルトの名無しさん
22/09/27 01:17:35.37 OwORQ6vn.net
mod tests に cfg(test) は必要だとして
依存性の注入にはtrait使えって事なのでは
843:デフォルトの名無しさん
22/09/27 07:51:04.95 f9SEu4pT.net
traitで置き換え可能にするのが面倒というのはありそうだな。
844:デフォルトの名無しさん
22/09/27 08:15:53.87 SBVoZTui.net
AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな
845:デフォルトの名無しさん
22/09/27 11:05:22.42 OwORQ6vn.net
size_tが64bitだからでは
846:はちみつ餃子
22/09/27 12:28:55.13 ozjafOA0.net
>>834
usize はポインタのサイズということになっている。
847:デフォルトの名無しさん
[ここ壊れてます] .net
>>831
単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる
C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前
そうしないとそもそも単体テストにならないじゃん
わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ
そういうことができるようにあらかじめコード設計しておかないといけないがな
考えてなかったならリファクタが必要
848:デフォルトの名無しさん
22/09/27 19:48:22.41 J8MleXan.net
そんなフワフワした説明されても...
849:デフォルトの名無しさん
22/09/27 19:51:56.44 AWnlNGZp.net
本物と異なり決まった値を返す送信元スタブと
本物と異なりassertだけする送信先モックを
mod testsの中では本物の代わりにuseするだけだよね
入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね
850:デフォルトの名無しさん
22/09/28 00:44:24.76 JQpGo85s.net
>>839
useしたモックをどうやって注入すんの
関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、
genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは
それともmod testsの外もcfgで置き換えると言っている？
851:デフォルトの名無しさん
22/09/28 00:48:00.37 JQpGo85s.net
要は
use imp::Foo;
fn target(foo: Foo) {}
がテスト対象だとして
mod tests {
use mock::Foo;
#[test]
fn test() {
target(Foo::new());
}
}
してもコンパイル通らないよね
targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では
852:デフォルトの名無しさん
22/09/28 07:20:15.72 1i04Jlqk.net
traitが無い言語では無理ってこと？？
853:デフォルトの名無しさん
22/09/28 11:35:17.56 RLf9Yg7w.net
>>842
他の言語は他のやり方でやってるだけだろ
854:デフォルトの名無しさん
22/09/29 01:43:05.00 xXycU9Ev.net
u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で
せっかくだから u32 に変換可能な型は受け入れようと考えてこんなコードを書きました。
しかしエラーになります。
struct Code(u32);
impl<T: Into<u32>> From<T> for Code {
fn from(x: T) -> Self {
Code(x.into())
}
}
impl From<Code> for u32 {
fn from(Code(x): Code) -> Self {
x
}
}
結果的に自分自身への変換を許すことになってしまうのが既存 (標準ライブラリ)
の定義と衝突しているという理屈は理解しているのですが、
問題を解消するためにこの定義が受け入れる範囲から自分自身 (Code) は除外するように
うまく制約を付ける方法は思いつきません。
そもそもこんなところで勝手に変換するのがよくない作法だとかそういうのは脇に置いて
「自分自身だけ除外するような制約」を上手いこと表現できませんかね？
855:デフォルトの名無しさん
22/09/29 02:16:48.63 zId7dOnm.net
無い
856:デフォルトの名無しさん
22/09/29 02:20:01.39 7xp1eqla.net
そっかー
857:デフォルトの名無しさん
22/09/29 02:40:21.97 U5dWXlr2.net
そういうのはIntoCodeみたいな感じで別トレイトにすることが多い気がする
URLﾘﾝｸ(docs.rs)
858:デフォルトの名無しさん
22/09/30 02:17:04.59 Yj/X+hjS.net
初歩的なことですまんけどさ
メソッド内で↓みたいなのってよく見るけど、こう言うのってself.asdfのまま使用するのに比べてどういった利点があるの？
let asdf = self.asdf;
859:デフォルトの名無しさん
22/09/30 10:23:40.27 1sTGpNyR.net
名前を短くする目的が99パー
860:デフォルトの名無しさん
22/09/30 11:00:13.39 tNhbOFxw.net
クロージャーで構造体のフィールドにアクセスすると構造体ごとムーブしちゃうんでそれ対策じゃないかな
2021で対策されたからどんどん減ってくだろうけど
URLﾘﾝｸ(play.rust-lang.org)
861:デフォルトの名無しさん
22/09/30 12:43:57.87 NYKsqXq4.net
書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある
let Foo { foo, bar. baz } = self;
としておくと後続の処理で使わないフィールドがあったときにコンパイラが警告してくれる
構造体に新たにフィールド追加した場合も分割代入の箇所でコンパイルエラーになるので修正必要箇所を洗い出すことができる
862:デフォルトの名無しさん
22/09/30 13:52:13.77 yzoXDHK/.net
>>851
なんかすごくモヤモヤする
863:デフォルトの名無しさん
22/09/30 14:15:24.65 oHn8O8ll.net
本人は俺ってスゲー、天才やん！
って思ってるんだろうけど後でコード見たらなんでこんなイミフなことしてるんだ？バカじゃねーの
ってなるパターンかと
まあこういう工夫をすること自体は悪くない
864:デフォルトの名無しさん
22/09/30 14:42:00.50 M1og6e+j.net
フィールドそれぞれに処理をするシチュエーションがわからない
865:デフォルトの名無しさん
22/09/30 14:50:06.85 temvUu5a.net
>>851
俺もそのdestructuring assignment自体は使いまくる
しかし目的が漏れチェックとは違うのでこうだな
let Self { foo, bar, .. } = self;
866:デフォルトの名無しさん
22/09/30 14:55:47.39 t/wNXSJY.net
>>851
これいいな
867:デフォルトの名無しさん
22/09/30 15:59:33.74 XmkFmofe.net
こうやって自己満足の意味不明なコードが量産されていく
868:デフォルトの名無しさん
22/09/30 16:19:08.34 GH/ZHf2N.net
全フィールド舐めるのが重要な処理ってシリアライズとかだろうか
そんな小手先のテクニックとかじゃなくてproc_macro組んだ方がいいと思う
シリアライズしたいだけならserde使って#[derive(Serialize)]
これも結局proc_macroだわな
869:デフォルトの名無しさん
22/09/30 17:36:27.38 NYKsqXq4.net
コマンドライン引数や設定ファイルの定義をclap::Argやserde::Deserializeで宣言的にやって、
それらを処理するところで分割代入してローカル変数にして処理してる
人間が意識的に気をつける必要がある箇所を極力減らしたい気持ちでやっている
好き嫌いあるかも知れないけど趣味プロダクトだしコーディングの意図をコメントに残してるから許せ
870:デフォルトの名無しさん
22/10/01 02:29:47.97 hYwRxeDD.net
>>844
impl<T: Into<u32>> From<T> for Code {}の定義はFromの反射性と衝突するから間違ってる。
Into<u32>を受け付けたいなら関数のパラメタの型をT: Into<u32> or impl Into<u32>にすればいい。
まあ、実装上の規約として必要なんで内部ではtrait IntoFooはパターンとして使われるけど外に漏らすようなものでもない。
871:デフォルトの名無しさん
22/10/01 02:38:45.63 6voBA5Ft.net
&(T, U)と(&T, &U)って等価ですか？
872:デフォルトの名無しさん
22/10/01 05:47:36.69 6w1pI6Co.net
等価ではありません
873:デフォルトの名無しさん
[ここ壊れてます] .net
アドレスを考えれば明白に別物
一方で
let t = (123, "abc");
let (x, y) = &t;
と自動マッチングしてくれて
&t の型は &(i32, &str)
x の型は &i32
y の型は &&str
となる
つまり&(T, U)が(&T, &U)に分割代入される
874:デフォルトの名無しさん
22/10/02 10:11:02.15 vdaryILR.net
test
875:デフォルトの名無しさん
22/10/03 22:39:32.97 zgM1XF6F.net
amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど
r14、r15よりr13を空けておく理由がなにかあるのかな
876:デフォルトの名無しさん
22/10/03 23:46:41.15 cMmfYMlm.net
>>865
そんな不吉なレジスタなんか使うな！
877:デフォルトの名無しさん
22/10/04 00:38:55.95 1GTeu6AF.net
うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか
伝わりにくいかもしれませんけど
878:デフォルトの名無しさん
22/10/04 00:52:50.22 4fgdKnMe.net
そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは！
879:デフォルトの名無しさん
[ここ壊れてます] .net
作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと
880:デフォルトの名無しさん
[ここ壊れてます] .net
Rustはデータ構造を最初に設計しないといけないというのはあるな
C++でもちゃんとそういうやり方が出来てるなら素直に移行できるだろうけど
雑にポインタ持ち回ったり実装の都合でアドホックに相互参照入れちゃったりする人には厳しいだろう
881:デフォルトの名無しさん
22/10/04 08:55:50.45 fDq9dWrD.net
C系は良くも悪くも動いてしまうんよな
そんで知らぬ間に副作用まみれになっている
882:デフォルトの名無しさん
22/10/04 09:10:45.14 9SKodj4D.net
>>867
慣れの問題も大きいのでは
883:はちみつ餃子
22/10/04 09:22:15.67 P4nmisNi.net
雑に始めてから整理していくスタイルなら C++ のほうがやりやすいというのは理解できる。
でも雑に始めたら整理する機会などないのが現実。
884:デフォルトの名無しさん
22/10/04 09:24:31.25 BONyu2jp.net
>>867 ですが、
部分から始められるというのは、部分的な学習からということです
ここまで学習すればここまではできるとか
rustでは最初のプログラムを作るにもたくさんのことを知らなければならないというか
Haskellをかじったことがあり、とても興味深いのですが
わかりにくい独り言に、レスをくださってありがとうございました
885:はちみつ餃子
22/10/04 09:48:05.73 P4nmisNi.net
>>874
> 部分的な学習から
できない。
部分的に学習して何かができたように見えても必ず間違ったものを書いているのが C++ というもの。
学習を進めていくにつれて間違っていたことに何度も気づくのでうんざりした経験があるだろ？
886:デフォルトの名無しさん
22/10/04 10:23:23.92 5od2FDFX.net
部分的な学習ってのは
C with classes -> STL -> move
みたいな感じじゃない？
他人のコード読むなら全部必要だけど、独習してる分には最初テンプレートとかなくてもいけるでしょ
887:デフォルトの名無しさん
22/10/04 12:43:12.54 7zYgBA5I.net
>>875 >>876
横からだけど、「部分的な学習」はもっと手前のところ。初心者でも
空のコード->リテラル->関数呼出->ライブラリ使用->変数定義・使用
あたりで使い方が広がるんだけど、Rustは関数呼出-変数あたりに概念のデカイ塊がある。
このあたりをまとめて覚えないと機能するプログラムを組めないので、学習者には辛い状態が続く。
Rustはc++以上に挫折しやすいと思う。