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++以上に挫折しやすいと思う。
888:デフォルトの名無しさん
22/10/04 12:54:59.39 zVqHX6VA.net
借用と実体(所有権)を常に意識しなきなならんからね
Cだと全部ポインタ使うから意識しないんだけどね
889:デフォルトの名無しさん
22/10/04 13:01:26.34 NJ6V6LdV.net
どんなプログラミング言語でもいいから何か言語を学習済みの人にとって
他の言語を学習するのは部分的に段階的にすることが可能だよ
もちろんRustでも同じで初心者向けの学習本
The Rust Programming Language
URLﾘﾝｸ(doc.rust-jp.rs)
を順番に少しずつ進めれば部分的に段階的に学習できるよ
890:デフォルトの名無しさん
22/10/04 13:14:23.44 fXb8hG+g.net
>>877
段階を経ず一気に進める無謀なことをする人だけが挫折するかもしれないが無謀なその人が悪い
>>878
いきなりそこまで進める人は単なる無謀者
まずは他の言語と同じ使い方
・実体のコピー
・参照（＝借用）
のみ使っている限り所有権なんて知らなくてよい
参照を戻り値としない限りライフタイムも知る必要ない
まずは部分的な学習をすればいい
その後で所有権とライフタイムを学べばよい
891:はちみつ餃子
22/10/04 13:25:41.11 P4nmisNi.net
>>877
> 関数呼出-変数あたりに概念のデカイ塊がある
C++ にもある。
あるのに中途半端な状態で間違った使い方が出来てしまうのが問題の根源。
まともに機能していないことに気づかずに
機能するプログラムを作れていると誤解して後になって結局は行き詰る。
>> 878
意識する必要はある。
コンパイラが検証してくれないのだからむしろ C のほうが強く意識する。
892:デフォルトの名無しさん
22/10/04 13:37:36.16 pLeAl7hn.net
まずは(Copy実装型の)数値演算だけやって変数と関数の使い方を覚えればいいだけじゃん
所有権なんて出て来ないぜ
その後にようやく数値の配列をやってその参照渡しと可変参照渡しを学ぶ
といったように順番にちよっとずつ学習していけば全くの初心者でも躓くことはない
893:デフォルトの名無しさん
22/10/04 13:44:23.36 0vVjyJiG.net
相変わらず複オジはクソだな
894:デフォルトの名無しさん
22/10/04 13:49:35.50 ez1nu7fa.net
部分的な学習ができないと主張してるやつは、いきなり無茶なことをしてるバカだけだな。
895:デフォルトの名無しさん
22/10/04 14:54:07.07 zVqHX6VA.net
>>880
でも標準機能の中でその理解が必要なんだよ
into_iterとかiterとか
その辺は本当にちゃんと理解してないとまともなループする書けない
896:デフォルトの名無しさん
22/10/04 15:06:46.90 ZhUau2yw.net
言語の学習ではあまりないと思うけど複数のコンポーネントを全て完動させないと到達出来ない領域があるのは確か
レイヤーが下がるとそう言うのも珍しくない
897:デフォルトの名無しさん
22/10/04 15:37:58.58 attOzucb.net
>>885
それは一気に全てを理解しないといけないと思い込んでるアホ人間だから
初心者のうちはfor文なんてざっくりした理解で十分に学習をどんどん進められる
後にIntoIteratorを理解する段階になってようやくfor文を完全に正解に理解すればよい
898:デフォルトの名無しさん
22/10/04 15:56:25.04 NBwKbSDK.net
初心者がなんか言ってるwww
899:デフォルトの名無しさん
22/10/04 16:01:39.35 zVqHX6VA.net
>>887
いやそれは無理があるだろ
所有権と借用の理解は型変換の時にも必須
collectとか使うときにも必須
競プロみたいな数値だけ扱うようなプログラムならかけるけど
900:デフォルトの名無しさん
22/10/04 16:03:22.02 LLFCSjL7.net
>>886
それは言語の学習と関係ないよね
Rust固有の話でもないね
つまり今回の話と全く関係ないでしょう
ちなみにそういう時はサンプルコードなどをまずは魔法の呪文とブラックボックスとして受け入れましょう
そして一つずつ把握する範囲を広げていけばよいのです
失敗する人は最初から全てを把握しようとする人だけです
901:はちみつ餃子
22/10/04 16:06:42.76 P4nmisNi.net
>>885
問題点が分かってきた。
「部分的な学習」というのは項目をひとつきちんと理解してから次の項目の学習に移るみたいなスタイルを前提としているんじゃないか？
俺が思ってた学習スタイルは「概念が存在していることは知っている」という程度の全体像から解像度を上げていくような方向性だった。
機能は互いに連携するので「この部分は完璧にわかっているけど他はまだ」なんて状況は有りえんし、そういう学習方法できちんと身につくとは思わない。
(もちろん人によってやりやすいスタイルはあるのだろうけども、個人的にはオススメ出来ない。)
流し読み程度でも入門書を一度読めば (細かい借用規則を覚えていなくても) iter を使うくらいは出来るよ。
そこから何度でも読んで細かい理解を深めていくんだよ。
902:デフォルトの名無しさん
22/10/04 16:09:22.52 Yud6QviI.net
>>889
キチガイは黙っていろ
どんな世界でもそんなに一気に大きく手を広げて学習しようとして上手くいくわけがない
単純に一つずつやっていくのが正しい
collectなんて後で困らん
そもそもイテレータ使わなきゃcollectは出て来ない
ぶっ飛んだことを書き込んでいることを自覚しろ
903:デフォルトの名無しさん
22/10/04 16:10:09.70 froE0MIe.net
これがいつもの複オジ演w
904:デフォルトの名無しさん
22/10/04 16:15:28.56 Qrm8xufh.net
>>889
collectを使わなくてもプログラムを書けるから少しずつ学習していく方法でも支障はないし
collectを一旦は魔術だとみなして仕組みの詳細まで把握せずに利用して進めていく学習方法でも支障はないし
FromIteratorなんてあとから学べば十分ですよ
905:デフォルトの名無しさん
22/10/04 16:17:47.88 zVqHX6VA.net
いやcollectをここまで安全かつ効率よく実装してる言語はないのにそれを使わないのは論外
906:デフォルトの名無しさん
22/10/04 16:19:54.90 zVqHX6VA.net
戦国時代に例えるならここに名刀があります
ワタクシは未熟だからこの刀は使いませんと言って
戦に出て殺されるみたいな話
その名刀を最初から使えるように訓練すべき
907:デフォルトの名無しさん
22/10/04 16:20:34.14 QGiHkjYG.net
馬鹿じゃねぇの
908:デフォルトの名無しさん
22/10/04 16:26:15.56 Qrm8xufh.net
>>895
使いたいならば使えばよいだけですよ
初心者がFromIteratorの仕組みまで理解しないとcollectを使っちゃいけないのですか？
この場合の『部分的に学習』とはcollectの機能の一部をまずは表層的にのみ理解して使ってみることです
そしてこの『部分的に学習』は可能です
909:デフォルトの名無しさん
22/10/04 16:29:20.57 BXFwwNrI.net
隔離スレに帰れ
910:デフォルトの名無しさん
22/10/04 16:29:25.15 zVqHX6VA.net
いやだから「表層的な学習」だとコンパイルすら通せないんだって
911:デフォルトの名無しさん
22/10/04 16:31:30.86 zVqHX6VA.net
何度も言ってるけどRustはコンパイルを通せば
意図してないエラーはまず起きないし
Nullで落ちるなんてこともない
912:デフォルトの名無しさん
22/10/04 16:35:17.34 vFqvnIUB.net
頭がいいと思い込んでる馬鹿がいきなり複雑な難しいことに挑戦して失敗して
難しい！とわめく馬鹿パターンはどんな分野でもある
その馬鹿が>>896
913:デフォルトの名無しさん
22/10/04 17:00:26.62 zVqHX6VA.net
「段階的学習」というのは数学や物理においては成立する言葉だがプログラミングにおいては成立しない
なぜなら「知識の差」が普遍的に影響を受けてしまうから
例えば数学では代数学の理論を知らなくても初等整数論は学べるがプログラミングではそのようなことはないとわかる
914:デフォルトの名無しさん
22/10/04 17:01:28.47 zVqHX6VA.net
例えばアルゴリズムの問題もそう
「知らない」ことが致命的になり得る
915:デフォルトの名無しさん
22/10/04 17:06:11.40 zVqHX6VA.net
collectを知らないものが自前でfor文で同じことを実装していたらどうなるだろうか？
レビューで指摘され赤っ恥を書かされてプライドはズタズタ
それが原因で鬱になるかもしれん
さらにパフォーマンス悪くなる
精神的にも肉体的にもダメージを負うことになる
916:デフォルトの名無しさん
22/10/04 17:18:30.46 vFqvnIUB.net
>>905
真逆だ
初心者の学習過程ならばcollectを使わずに実装することは適切な練習問題だ
その段階を経てからcollectを学習した者こそ身に付く
917:デフォルトの名無しさん
22/10/04 17:46:08.51 5flxOiHV.net
段階的学習って↓を読み進めればいいだけじゃないの？
URLﾘﾝｸ(doc.rust-jp.rs)
918:デフォルトの名無しさん
22/10/04 18:05:45.53 qunzxQTR.net
>>907
その通りなんだけど
Rustは段階的な学習ができない！と主張している変な人がいるのよ
919:デフォルトの名無しさん
22/10/04 18:41:19.07 NDareeYW.net
この複オジ演パターンはもうみんな気づいてるよね
920:デフォルトの名無しさん
22/10/04 18:43:17.38 ye813FXw.net
赤い人をNGしときゃいいやん
921:デフォルトの名無しさん
22/10/04 19:01:55.07 7zYgBA5I.net
>>907
初心者・初学者に「the bookを読め」はさすがにむちゃだろ。
やっぱり「初心者はRust使わず他の言語から勉強しろ」が正解なのかね。
922:デフォルトの名無しさん
22/10/04 19:07:38.54 gMN5eNCr.net
>>891
さすが餃子さん分かってらっしゃる
最初は大まかな理解→もう少し詳細な理解→最後に完璧な理解という解像度の段階的な学習を中心に
項目や範囲を広げていく網羅度の段階的な学習を組み合わせることでRustの学習を含めて一般的な事柄にも適用できる
923:はちみつ餃子
22/10/04 20:17:29.13 P4nmisNi.net
>>911
そこで言ってる「初心者」は「Rust の初心者」ではなく「プログラミングの初心者」の意味？
そうだとすると the book はちょっとハードルが高いということはあるかもしれんな。
でも C++ と比較すると C++ のほうがもっとハードルが高いと思う。
コンパイラが検出しないところで未定義に入り込むことがあまりに多い。
初心者が間違うのは当然のことだが、正しいのか間違っているのかわからないというのは間違っていることが明白であるよりもしんどい。
そこで間違ったまま邁進できるようなメンタルの持ち主はそれはそれで遠からず行き詰るし。
924:デフォルトの名無しさん
22/10/04 20:27:55.40 9Mq2x6bG.net
>>867 ですが、
>>876 さんがおっしゃることが僕の意図を言い当てています
c++を使わなくなって 15年は経ちますが、その頃の c++にはテンプレートはありましたがスマートポインタやラムダ式、その他諸々のモダンな機能はまだありませんでした(と思います)
クラス付きのCの部分で仕事をしていました
モダンなc++へ再入門するか、rustを学ぶか迷って rustに触れて今に至りました
925:デフォルトの名無しさん
22/10/04 20:36:11.60 pQmQIrKs.net
>>914
C程度の予備知識があるならば
>>907のRust Bookだけで容易に段階的に学習できるから何ら問題は起きず大丈夫
926:デフォルトの名無しさん
22/10/04 21:10:32.92 d7kGndGU.net
所有権も借用も生存期間も理解してなければ
メソッド呼び出し一つ満足にできないんだから
それら無しに動くものが作れるわけない
学習自体は言語に限らずどんな学習でも部分的段階的にやるもの
それ以外の方法なんてないんだから論点ずれてる
927:デフォルトの名無しさん
[ここ壊れてます] .net
>>916
それはさすがに無知すぎやろ
Rustは数値など所有権とは無縁な型で構成されているから
所有権なんて理解しなくてもプログラムを組める
段階的に後から所有権を学ぶことができる
928:デフォルトの名無しさん
22/10/04 23:03:40.79 HL14YOAo.net
>>917
所有権も知らずにイキってた人はさすがに言う事が違うねぇww
929:デフォルトの名無しさん
22/10/04 23:58:47.13 vxOZn4OH.net
数値型って所有権がっつり関係してると思うけど
930:デフォルトの名無しさん
22/10/05 00:06:13.80 SE95U4Vu.net
>>919
数値型はCopyを実装しているので所有権は無くムーブも起きない
931:デフォルトの名無しさん
22/10/05 02:07:12.38 1K+My+/e.net
数値型だけで>>867の言う「動くもの」を作ってみれば？
932:デフォルトの名無しさん
22/10/05 02:59:14.45 P8+KCirf.net
所有権は実在しない幻影
lifetimeとvarianceだけを見つめなさい
933:デフォルトの名無しさん
22/10/05 03:09:52.75 Ybu4BU3z.net
どうも段階的にやれると思ってる人はデータタイプを数値に限定してる気がする
数値はコピー可能でありRustのサンプルとしてよく使われるが
コピー可能なオブジェクトというのは普通のアプリケーションでは効率が悪すぎて使わない
つまり所有権の理解は必須なのだよ
934:デフォルトの名無しさん
22/10/05 03:15:49.43 UScD8/
935:dK.net
936:デフォルトの名無しさん
22/10/05 03:19:22.28 Ybu4BU3z.net
数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
コピーして効率よく処理できる仕組みがないからmoveが生まれた
937:デフォルトの名無しさん
22/10/05 03:20:04.62 Ybu4BU3z.net
段階的なんてものは存在しない
理解してるかしてないか
938:デフォルトの名無しさん
22/10/05 05:31:48.70 wne70pEz.net
>>921
Hollow world から始めなさいよw URLﾘﾝｸ(doc.rust-lang.org)
>>925
そもそも初学者って言ってるのに
> 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
とか頭おかしい
939:デフォルトの名無しさん
22/10/05 07:53:16.44 MzMPKgoE.net
初学者にマウント取りたいやつがイキってる
940:デフォルトの名無しさん
22/10/05 10:48:19.99 gF0QOXVU.net
初学者にしてもスタイルは人それぞれだろうし皆がどうやってrust習得したか語ってくれた方が参考になりそう
自分はlifetimeが導入される前からrust触ってたからコンパイラに追加される機能を適宜試してみながら体で覚えた
941:デフォルトの名無しさん
22/10/05 11:23:13.56 1F438Xk1.net
初級者はHello, world!からって、かつての初級者はBASICから並みに罠じゃね
ほとんどのHello, world!は現代のプログラミングで必須の要素が欠落しまくっているからな
942:デフォルトの名無しさん
22/10/05 11:28:02.85 BbaUEliB.net
複オジも100点オジも
もう少しRust勉強してからレスするか
大人しくしとくかどっちかにしてくれ
943:デフォルトの名無しさん
22/10/05 11:28:25.81 tZ9pwx2f.net
コンパイル、ビルドができるまでの説明だし
944:デフォルトの名無しさん
22/10/05 11:34:33.18 +5Cy2zf0.net
ホロウワールドは何かのネタ？
945:デフォルトの名無しさん
22/10/05 12:32:57.65 OxlYZjk9.net
今担当してる作業が、あるまとまった処理を上手く対応付けするとちょっと複雑な数値演算処理だけに置き換えられるので、
その数値演算ライブラリを作っているのだけど、確かに所有権は全く出て来ない。
入出力は配列(スライス)の参照渡しと可変参照渡しとなっていてライフタイム明記も無し。
所有権を学ぶ前に参照(借用)だけで十分に色んな実践ができると思う。
そして参照は他の言語でも配列などは参照渡しになるから、新たにスライスだけ覚えればRustを段階的に学ぶことができる。
946:デフォルトの名無しさん
22/10/05 12:36:28.49 +KHGV4+/.net
俺はずっとJavaメインで、遊びでlispとかHaskellとか触る程度で低レイヤは触ってなかったんだけど、Rustでここまで現代的に書けるならアリだなって触り始めたクチだな。
947:デフォルトの名無しさん
22/10/05 12:59:55.95 EKfM3pGK.net
>>930
まずハロワやれと言われるレベルの初級者ってプログラミング自体初めてやるようなレベルの人でしょ
それならあれこれ教えたところでどうせ理解不能になるだけなのでとりあえず動くものを作らせることには意味がある
948:デフォルトの名無しさん
22/10/05 13:37:41.28 Pj9P59N0.net
ただいまんこのあとは
シコシコちんちん シコシコ イソチンチン
949:デフォルトの名無しさん
22/10/05 13:47:37.30 X575+w0V.net
かい
950:デフォルトの名無しさん
22/10/05 15:06:32.60 wne70pEz.net
>>930
何を勘違いしてるんだよw
ハロワはプログラミングの勉強じゃなくて>>932も書いてる通り環境の勉強だぞ
お前の言う必須の要素が何を指してるのか知らんけど例えばif文の勉強したい時に動かせるかどうかは重要だろ
951:デフォルトの名無しさん
22/10/05 16:08:34.41 l3k0CCzl.net
>>934
（安全な）参照は所有権の上に成り立っているよ
952:デフォルトの名無しさん
22/10/05 16:19:48.70 7FrBhgJk.net
>>940
それも真
しかし>>934のような使い方だと所有権を意識する必要すらないのも真
同様に>>934のような使い方だと参照のライフタイムを意識する必要がないのも真
これは類似なものとしてC言語を使っている時に常に所有権とライフタイムを意識する必要性があるわけではないことも同様に例示される
953:デフォルトの名無しさん
22/10/05 17:04:57.53 NuKocPG+.net
噛み合ってない理由がわかった
競プロ勢が多いんだな
数値しか扱わないなら
ベターCとして書くことは容易だからね
954:デフォルトの名無しさん
22/10/05 17:33:30.37 66O9N6nP.net
競プロじゃないけどトレイトとかよく判らないから安定しているCとしてしか使っていないわ
955:デフォルトの名無しさん
22/10/05 17:33:54.20 mBRaD/Kx.net
>>942
競プロ勢による書き込みが見当たらないこの状況で
妄想により幻覚が見えているのか？
956:デフォルトの名無しさん
[ここ壊れてます] .net
競プロ勢の炙り出しには成功したみたいだな
957:デフォルトの名無しさん
22/10/05 23:31:57.40 lcOrUuZN.net
色々書いたうちCLI程度の規模のプログラムだと大半は所有権の移動がなくて所有権の意識が薄いな
オブジェクトをnewするところは厳密には移動と言えるかも知れないが単なる値返しと捉えるだろう
あとはオブジェクトの参照を渡していくだけたから単なる参照渡し
958:デフォルトの名無しさん
22/10/05 23:44:31.07 V7HNybPt.net
毎日毎日息を吐くように嘘を吐く複オジ
控え目に言っても頭おかしい
959:デフォルトの名無しさん
22/10/05 23:56:41.83 nYqhDlIA.net
数値型だけでは動くものが作れないことに気がついたみたいだな
Rustで所有権を理解せずに動くものを作るなんて柱を使わずに家を建てるようなもの
960:デフォルトの名無しさん
22/10/06 00:08:02.42 aXzDwmUt.net
>>946
関数が値返しと引数可変参照渡しへの書き込みだけならプログラムの規模や種類に関係なくそんなもんだろ
所有権が出てくる幕はない
もちろんライフタイムも出てこない
961:デフォルトの名無しさん
22/10/06 00:34:26.13 XbdFr8Zd.net
そういう点では所有権が出てこなくてもかなりの範囲のプログラムを書けるよ
962:はちみつ餃子
22/10/06 00:34:32.05 rLXZsLBm.net
>>949
いくつかの自明な場合にはライフタイムを省略しても暗黙のルールが適用されるから書かなくてもよいだけで、ライフタイムが存在しないわけではないよ。
その暗黙のルールが比較的自然に定義されてるってことなんだろうね。
963:デフォルトの名無しさん
22/10/06 00:37:42.29 4kCBwc0q.net
>>951
それは違うな
>>949のケースは参照返しをしていないのだからライフタイムは出て来ない
ライフタイムの存在を意識する必要もない
964:デフォルトの名無しさん
22/10/06 01:26:52.37 v2j3J5Hy.net
動くものってなんだよ
965:デフォルトの名無しさん
22/10/06 01:33:20.48 QZHh62Nh.net
Rustを使ってると、参照を返すようなコードはだんだん避けるようになるかもしれないな
966:デフォルトの名無しさん
22/10/06 01:59:47.45 iRnDWdOb.net
競プロみたいにmain関数のみ
データ型は数値のみ
データ構造は固定配列のみ
サイズも高々数百から数千程度なのでスタック確保でオッケー
配列への参照のみ必要
結果は固定配列を新しく作ってそこに詰めていく
これなら所有権など一切いらない
967:デフォルトの名無しさん
22/10/06 02:04:59.09 MtARpYSM.net
この件は数値型や競プロは一切関係ない
ヒープを使うVecやStringやそれらを含む構造体を返しても『値返し』となる点がポイント
『参照返し』とならないため『ライフタイム』は登場せず『所有権』を意識する必要もない
そして『値返し』だけでも様々な実用的なプログラムをRustで作ることができる
968:デフォルトの名無しさん
22/10/06 02:07:29.97 iRnDWdOb.net
ついにlinux kernelにRustがマージされた模様
969:デフォルトの名無しさん
22/10/06 02:38:59.47 v2j3J5Hy.net
>>95
970:4 個人的にはdangling pointetとか内部オブジェクトを書き換えられる心配しなくて良くなるから 他の言語より積極的に参照返すようになってる気がする
971:デフォルトの名無しさん
22/10/06 06:12:47.90 QjC44cq3.net
参照返しの安全性を保証できるRustいいよな
参照返しを使わず値返しだけでもかなり広い範囲のことを処理できる点も同意
972:デフォルトの名無しさん
22/10/06 14:46:06.11 wkSQkKsv.net
値返しとか参照返しなんて言葉をRustで使うなよw
973:デフォルトの名無しさん
[ここ壊れてます] .net
参照を返す時のみ
ライフタイムの概念が登場
だから参照返しと値返しの区別は実質的に重要
もちろんRustでは常に(広義の)値返しとなる
そして参照返しとは参照を(広義の)値返しすること
参照返しの対義語として(狭義の)値返しを使ってもよい
974:デフォルトの名無しさん
[ここ壊れてます] .net
構造体など参照以外の値がlifetime持つ場合もある
参照だけ区別するのはなぜ
975:デフォルトの名無しさん
[ここ壊れてます] .net
ここでいうlifetimeはlifetimeパラメーターのこと
976:デフォルトの名無しさん
[ここ壊れてます] .net
>>962
それはそのフィールドが参照を返しているね
構造体がライフタイムを持つのはそのような時
977:デフォルトの名無しさん
[ここ壊れてます] .net
> 値返しとか参照返し
これはどこに定義された用語ですか？
それともオレオレ用語ですか？
URLﾘﾝｸ(en.wikipedia.org)
> 3.1 Call by value
> 3.2 Call by reference
値渡し参照渡しは昔からよく聞くけど
978:デフォルトの名無しさん
22/10/06 15:37:35.04 mTG1aBjr.net
最初に言い出したのは
>>952
> >>951
> それは違うな
> >>949のケースは参照返しをしていないのだからライフタイムは出て来ない
これか
979:デフォルトの名無しさん
22/10/06 15:37:37.36 ry4GAtyf.net
>>965
それは関数の引数としての渡し方だから返し方とは独立ではないか
980:デフォルトの名無しさん
22/10/06 15:38:40.62 QZHh62Nh.net
Return by Referenceも知らんのか・・・
981:デフォルトの名無しさん
22/10/06 15:40:52.32 mTG1aBjr.net
どこに定義されてる用語なのかを知りたいだけよｗ
982:デフォルトの名無しさん
22/10/06 15:45:23.29 JBcgzpIo.net
Rustでは参照返しが有る時だけライフタイムパラメータが付くんよ
例えば3つの参照返しが有る時に3つのライフタイムが異なれば3つのライフタイムパラメータが付くんよ
だから参照返しが有るか無いか区別されてしまうんよ
983:デフォルトの名無しさん
22/10/06 16:06:44.80 sWKfpE/G.net
結局Rustにおける値と参照とは何かを知るためには所有権の理解が必須なワケよ
984:デフォルトの名無しさん
22/10/06 16:15:24.55 B9K2Q0k5.net
by valueの意味が他の言語とは違うからな
985:デフォルトの名無しさん
22/10/06 16:23:06.37 bcHprxpF.net
>>971
参照を返さない限り所有権の理解は不要
Rustでは配列も構造体も更にはヒープを用いるVecやString等も値として返される
つまり参照を返さなくてもある程度の広範囲のプログラムを書くことができる
986:デフォルトの名無しさん
22/10/06 16:33:59.37 mb1xnKf4.net
ムーブのことも忘れないでください
987:デフォルトの名無しさん
22/10/06 16:37:24.79 JMKkrzgh.net
>>974
ムーブする必要ないよな
参照渡しだけしていれば所有権は出て来ないな
988:デフォルトの名無しさん
22/10/06 16:42:22.59 bM/kk4ia.net
所有権要らないならRust要らないじゃんって思いながらずっと読んでる
どういう結論に持っていきたいの
989:デフォルトの名無しさん
22/10/06 16:44:20.49 QZHh62Nh.net
釣りが目的で書き込んでるひとと、それに付き合ってレスしてるひとがいるからわけわからん
990:デフォルトの名無しさん
22/10/06 16:49:39.04 +ZB5z2+t.net
参照渡しだけして参照返しをしなければ
所有権もライフタイムも出てこないからそれらを意識することもない
結果として所有権とライフタイムを理解していなくてもそのスタイルでプログラムを組むことが出来てしまう
991:デフォルトの名無しさん
22/10/06 17:03:06.06 HCQdlFdq.net
>>976
rust 学習の話だろ？
未来永劫所有権の理解は不要なんて誰も言ってないと思うが
992:デフォルトの名無しさん
22/10/06 18:43:34.42 rjzElph2.net
逆にrustだとどういう時に参照返しが必要になるの？
993:はちみつ餃子
22/10/06 18:48:14.82 rLXZsLBm.net
>>980
Rust 特有の事情なんかないよ。
C/C++ でポインタや参照で返すときと同じだよ。
994:デフォルトの名無しさん
22/10/06 19:17:16.58 mTG1aBjr.net
「参照で返す」「参照を返す」って表現する人 ←わかる
「参照返し」と言い続ける人 ←？？？
995:デフォルトの名無しさん
[ここ壊れてます] .net
同じだろ
参照を渡すことを参照渡し
参照を返すことを参照返し
996:デフォルトの名無しさん
[ここ壊れてます] .net
値渡し参照渡しで言うと依然として単なる値渡しなのに
ただポインタを渡してるだけでそれを
「ポインタ渡し」とか言い出したり
ひどいやつだと「参照渡し」だと言いはったり
そういうのを過去にC言語界隈で見てきたから気になったんよ
独自解釈による珍妙なワードはこの世に必要ないと思うでしょ
>>983
そうですかボクからはもう何も言うことはありません
997:デフォルトの名無しさん
[ここ壊れてます] .net
>>984
それは君が区別すべきことを理解できていないから混乱している
会話や説明では何と何を区別するかが重要
もちろんRustでは常に指定した型そのものが渡され返される
だから区別するとしたら実体を渡したり返したりするのかその参照を渡したり返したりするのかが焦点となる
したがって参照渡しや参照返しという言葉がぴったり適して使われている
998:デフォルトの名無しさん
[ここ壊れてます] .net
あとポインタへのポインタを「ダブルポインタ」って呼んじゃう人もいたな
このスレでは「所有権の複製」ってのもあったな
999:デフォルトの名無しさん
[ここ壊れてます] .net
>>986
英語でもダブルポインタと言うし何を問題にしているのかわからん
自分勝手な線引きやルールがあってそこから外れると融通が効かなくなるダメな人かね？
1000:デフォルトの名無しさん
[ここ壊れてます] .net
ゲームの方のRustで、ホロライブのRustのSeason3が終わるから検索汚染も減るかもな
1001:デフォルトの名無しさん
[ここ壊れてます] .net
参照で返すことを「参照返し」と言った途端ブチギレするのマジで意味不明なんだがその呼び方を否定するとどんなメリットがあるのだろうか
1002:デフォルトの名無しさん
22/10/06 20:19:33.91 bM/kk4ia.net
意味不明なら言及しなくていいよ
1003:デフォルトの名無しさん
22/10/06 20:27:57.49 RK7Fg483.net
>>984を見るとCでポインタで渡すことをポインタ渡しと言われるだけで発狂するようだからその人はキチガイ
1004:デフォルトの名無しさん
22/10/06 20:52:03.93 lx27AXhR.net
参照はピリリと辛い
1005:デフォルトの名無しさん
22/10/06 20:52:48.54 mb1xnKf4.net
他への参照を持つ実体を返すのは値返しか参照返しかはたまた別の何かか
なんて考えたくない
1006:デフォルトの名無しさん
22/10/06 20:58:52.86 EteQ2MpB.net
「ポインタ渡し」がNGなら「ポインタを渡すこと」も日本語でそう表現していいよと言語の開発者がわざわざお墨付き与えなければNGだと思う
1007:デフォルトの名無しさん
22/10/06 21:00:15.33 99NRyDSB.net
今回はRustの段階的学習の話だから、これだけのことではないかい。
参照返しが含まれていなければ、ライフタイムを把握する必要がなく、所有権を学習していない段階でも、そのプログラムを書くことができる。
参照返しが含まれていれば、ライフタイムを把握する必要があり、所有権を学習した以降となる。
1008:デフォルトの名無しさん
22/10/06 21:05:33.19 DNbAbwmR.net
複オジwを相手にしちゃうからww
1009:デフォルトの名無しさん
22/10/06 21:09:49.66 Re0G7B20.net
ぼくちゃんrust入門者
ライフタイム注釈だけはどうにかならなかったのとか思った
でもいろいろ満足
tauriやるぞう
1010:デフォルトの名無しさん
22/10/06 21:23:30.56 xIsaLol7.net
ホント毎日毎日アホなこと書いてるなぁ
釣られちゃうRust入門者は少し不憫
1011:デフォルトの名無しさん
22/10/06 21:26:14.68 ccGjPy8L.net
>>995
所有権を学ぶのを後ろへずらすことでRust学習の難易度を大きく下げられそうね
1012:デフォルトの名無しさん
22/10/06 21:35:40.63 jyraEk4K.net
などと言う嘘つき初心者w
1013:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 101日 13時間 18分 37秒
1014:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています