Rustとか言うダブスタ言語

**仕様書無しさん** · 2024/10/17(木) 08:07:52.57

値型と参照型で振る舞い変えるダブスタ言語だけど使ってるやついる？

**仕様書無しさん** · 2024/10/19(土) 09:39:04.12

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などのプログラミング言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

警備員[Lv.11][芽] · 2024/10/19(土) 11:35:17.55

>>36
だからmain関数で宣言してたらソフト終了するまでメモリ解放されないだろアホ
>>44
でもメモリコピーするクラスというか型は各々作れるよね？そのときどうすんの？
俺は素直に変数.mcopyで良いと思うが

**仕様書無しさん** · 2024/10/19(土) 12:02:44.51

struct Point {
x: i32,
y: i32.
}

例えばこのようなPoint構造体を作ったら。それは新しい型であってデフォルトではCopy出来ない。

もしこの構造体の所に
#[derive(Copy,Clone)]
という指定を付けるとCopyトレイトが実装されるのでコピー出来るようになる。ただ慣習的には構造体は暗黙的にコビーされるのは良くないので、Cloneだけ実装して明示的にCloneしてねというのが推奨。

警備員[Lv.11][芽] · 2024/10/19(土) 12:05:15.32

>>47
だったらはなから変数.mcopyでいいだろ

警備員[Lv.11][芽] · 2024/10/19(土) 12:06:10.07

それつけなかったらプリミティヴも移譲にするでいいじゃん
そっちのほうがはるかに神言語のそれだろ

**仕様書無しさん** · 2024/10/19(土) 12:10:59.43

let p1 = Point { x:100, y:200 };
let p2 = p1; // copy が実装されてる場合
let p3 = p1.clone(); // 明示的な clone

**仕様書無しさん** · 2024/10/19(土) 12:20:52.07

C言語から来た人は型をメモリのサイズで捉えてる人が多いよ。関数型言語で言うところの型というのは機能や文脈や制限や寿命やら色々な情報を含むもので全部区別すべきもの。これが凄い便利機能なわけ。
暗黙的な型変換をする言語は型の力を利用出来ないのでバグる。

**仕様書無しさん** · 2024/10/19(土) 12:33:15.92

あと勘違いしてるかもしれないけど、プログラム上の変数のスコープの範囲と、実際の寿命の範囲は別物だよ。
Rustコンパイラは変数が使われている所を全て把握しているので用が済んだ変数はスコープ抜けなくても最適化で消されてる。
定数になるものなら変数の領域すら確保されない。

**仕様書無しさん** · 2024/10/19(土) 12:46:30.82

fn main() {
// 整数型
let a: i32 = 42;
let b = a.clone();

// 浮動小数点型
let c: f64 = 3.14;
let d = c.clone();

// ブール型
let e: bool = true;
let f = e.clone();

// 文字型
let g: char = 'A';
let h = g.clone();
}

明示的に書いたほうが分かり易いという人は全部 clone って書いてもいいんですよ。

警備員[Lv.11][芽] · 2024/10/19(土) 12:46:36.00

>>52
それ君らが嫌いなガベコレとなにが違うの？

**仕様書無しさん** · 2024/10/19(土) 12:51:14.23

ガベコレは用が済んだタイミングで即解放されるんじゃなくて、GCを走らせたタイミングで解放です。
なのでメモリを倍ぐらい余分に確保しとかないと足らなくなることがある。

**仕様書無しさん** · 2024/10/19(土) 15:46:59.73

無職ってすぐ人に聞こうとするよな
だから無職なんだろうけど

**仕様書無しさん** · 2024/10/19(土) 16:17:01.01

>>54
ガベージコレクション(GC)は
・「ガベージ＝ゴミ＝使われなくなったメモリ」がどんどん溜まっていく
・そのため実行中のあるタイミングで溜まってきたゴミをまとめて収集(コレクション)する
・ゴミかどうかは実行中に使われなくなったかどうかを何らかの方法で追跡して判断する
・このGCを判断実行できるように冗長なメモリ管理をすることとゴミが溜まるためメモリ消費量が多い
・これらの処理を行なえるようGCランタイムと呼ばれるプログラムが必ず内蔵される

このGCにメモリ管理を依存する言語がGC言語と呼ばれている
C/C++/Rustは依存しないため非GC言語

**仕様書無しさん** · 2024/10/19(土) 16:48:14.21

【GC言語】常に安全にメモリ自動解放されるがGCのため遅くてメモリ利用量も多い
【Rust】常に安全にメモリ自動解放されて速くて省メモリ
【C/C++】安全ではなく解放済み領域をメモリ参照してしまうことも発生

警備員[Lv.12][芽] · 2024/10/19(土) 19:17:09.27

まぁどんだけ安全でもダブスタ言語なんて使いたく無いけどね

**仕様書無しさん** · 2024/10/19(土) 19:23:41.39

それは単に使わなければ良いだけじゃないの？

**仕様書無しさん** · 2024/10/19(土) 19:23:41.76

それは単に使わなければ良いだけじゃないの？

**仕様書無しさん** · 2024/10/19(土) 19:39:45.66

>>45
アメリカでは政府も国防総省もRust言語なんだね

**仕様書無しさん** · 2024/10/19(土) 21:27:12.32

メモリの仕組み理解してからRustやろうね
できればCかC++やってから

警備員[Lv.13][芽] · 2024/10/19(土) 21:29:03.92

>>63
いや理解してんだわ
だからこそ同じ書き方で2つの振る舞いをするRustが嫌いなの

**仕様書無しさん** · 2024/10/19(土) 21:35:54.87

JavaやC#もそういうことはある

**仕様書無しさん** · 2024/10/19(土) 21:37:56.86

「本当に理解した？」
「はいっ！」←こういう新人いるよね

**仕様書無しさん** · 2024/10/19(土) 21:44:28.27

こいつは何をダブスタって言ってるんだ？

**仕様書無しさん** · 2024/10/19(土) 21:50:24.57

>>64
誤解してるんじゃないの？
Rustにはコピー可能型とコピー不可能型の2種類しかない
それを理解すれば振る舞いは常に一意に定まることがわかる

**仕様書無しさん** · 2024/10/19(土) 22:03:38.72

無職はほっとけよ
仕事してないんだから

警備員[Lv.4][新芽] · 2024/10/19(土) 22:59:12.10

このスレには、僕のスッキリしない部分を言語化して説明してくれる人が多くて助かります

警備員[Lv.14] · 2024/10/19(土) 23:29:07.21

>>67
移譲とメモリコピーで振る舞い変える

警備員[Lv.14] · 2024/10/19(土) 23:30:10.12

>>68
だから.cloneを明記しないと移譲になるでいいじゃん

**仕様書無しさん** · 2024/10/19(土) 23:46:47.34

>>72
コピーとcloneは明確に異なると定められている
コピーはプログラマーが実装することはなくビットパターンごとサイズ分のメモリがコピーされる
cloneはプログラマーが自由に実装することができて例えばヒープ領域を持つデータならその部分も含めてコピーすることもできるしコピーせずに共有することもできてcloneは型毎に自由度がある
このようにコピーとcloneは明確に異なっている

**仕様書無しさん** · 2024/10/19(土) 23:49:27.57

コピーと同じ動作になるのはムーブ
どちらもプログラマーは実装することができない
ただしムーブはムーブ元の値が無効になるという点のみコピーと異なる

**仕様書無しさん** · 2024/10/20(日) 02:08:40.13

ムーブとコピーで同じイコールを書くのが気に入らないって事かな？

所有権の移譲とか言うから分かりにくいんだと思う。「メモリ管理責任」が無いからコピー、有れば「メモリ管理責任」ごとムーブするだけ。

で、プリミティブ型はそもそも移動する意味がないしコピーの方が速い。

優先順位の考え方が逆で、イコールはコピー出来る型ならコピー、出来ない型ならムーブする。ムーブも出来ない型ならコンパイルエラー。で、エラーが出る場合は明示的にcloneを書いたりする。でcloneも出来ない型なら更に他の方法で対策する。
そうやって型で制約をはめる事で誰が書いても同じ挙動になるようにしている。

警備員[Lv.14] · 2024/10/20(日) 03:27:08.69

>>73
じゃあなおさら変数.mcopyが必要だね

警備員[Lv.14] · 2024/10/20(日) 03:30:07.84

>>75
そうやって色々試して型探ってくよりはるかにプリミティヴ系も＝のみの場合はメモリ解放して使えなくなるくらいのほうが楽だろ
コピーは上で言ってるように.mcopyを明示的に示せばいいだけ

**仕様書無しさん** · 2024/10/20(日) 04:25:09.91

>>77
なんか物事の捉え方がインタプリタと勘違いしてない？

コンパイラなんだからコンパイル時に全部処理されるのよ？

**仕様書無しさん** · 2024/10/20(日) 04:29:33.89

プログラム的な意味論とそれが最適化されて出力された後のコードの挙動まで解説しないと駄目なのかな？

**仕様書無しさん** · 2024/10/20(日) 06:39:19.66

>>77
ムーブとコピーはプリミティブな相補的な動作なので
.move()や.copy()といったメソッド呼び出しは不可能
トレイトCopy実装型は常にコピーされ
Copy非実装型は常にムーブされる
Rustは非常にシンプルでわかりやすくなっている

警備員[Lv.15] · 2024/10/20(日) 09:19:34.07

>>80
だからそれを同じ
let b ＝ a;
let d ＝ c;
で表現させちゃダメだろ
↑見てどっちがプリミティヴかわかるか？

警備員[Lv.15] · 2024/10/20(日) 09:20:49.24

低レベル言語やってるやつって保守のこと全く考えないのかな？

**仕様書無しさん** · 2024/10/20(日) 09:30:55.71

C#でいうと
var a = new Foo();
var b = a;

で a と b が同じオブジェクトを指す状態になるけど、これを許容しないのがRust
この場合は b だけが Foo に責任を持つべきで、そのためにaは所有権を無くす (「解放する」ではなく「所有権を移す」だけ)
これはメモリ使用量というよりも管理の問題で、「a の操作がbに影響を与える」ことによる複雑性を取り除くために厳しくしてる

var a = 1;
var b = a;

C#でもそうだけど、これはスタックメモリに積まれるもので、単に値コピーされる
これは関数を抜ければ解放される (GCのような機構を必要としない) し、C#でもaの書き換えがbに作用しないはず
Rustでもこれでaを使えなくする理由はないので単にコピーされる

Rustでもオブジェクトを共有する仕組みはあるけど、その場合は共有のための型 (Rc<T> のような型) を使うことになる
これは特にマルチスレッドの場合に有用で、スレッドを跨いで共有されるオブジェクトは「ロックをかけないと内部の値にアクセスできない」型で包まないとコンパイルエラーになる仕組みがある
これは個人的にすごく便利だと思う部分で、Rustだと安心してコードを書ける感じがする

**仕様書無しさん** · 2024/10/20(日) 09:41:57.61

C#でも
var b = a;
でbがaと同じオブジェクトを参照するかコピーされるかは型に依存するでしょ

**仕様書無しさん** · 2024/10/20(日) 09:46:56.69

【結婚難】金稼ぎ共働き妨害するな【孤独死】

☆犠牲になるのは犯罪幇助SEの結婚相手☆

実態派遣で非婚や離婚や中絶や少子化や親不孝を促進

・キモい
・モラルない
・ファッションセンスない
・コミュニケーション苦手
・時間外労働違反で共働き妨害
・泥棒客先に開発報酬を奪わせる
・泥棒客先に知的財産を奪わせる
・裁判官が技術判断不正をする

SEは多重派遣の料金詐欺は非婚
https://codelearn.jp/articles/about-engineer-marriage

**仕様書無しさん** · 2024/10/20(日) 09:55:32.58

>>82
保守性は言語でなく開発者や組織のレベルの問題
あえて言語の特徴を書くなら、OOP言語だとクラスのフィールドに参照型の値がある場合に、それが他のクラスと共有されるものであるかを知る方法がないけど、Rustはそれが明確という利点がある

struct Foo { a: T } のTがStringならこれはFooの中に閉じ込められてるし、Rc<String> なら他と共有される (ただしスレッドは跨がない) し、Rc<Mutex<String>> なら複数スレッドから共有されるかつ書き換わる可能性があることを意味する

そのために面倒な部分があるのは確かで、C#やJavaは逆にそれらを簡略化してるともいえる

**仕様書無しさん** · 2024/10/20(日) 10:41:24.68

>>82
Rustの保守性がこれまでの言語と比べて格段に保守性が高く優れているのは様々な仕組みで実現されている
例えばRustのデータ参照競合の防止機構やデータ競合の防止機構は保守においてそれらによるバグ混入を確実にコンパイルエラーとして検出する

**仕様書無しさん** · 2024/10/20(日) 11:20:15.04

初学者がコードを見た時のとっつきにくさはあると思う
けどこれは simple vs easy みたいもので、Rustは難しいけど仕組みを理解すればシンプルではある

警備員[Lv.16] · 2024/10/20(日) 12:59:21.64

>>87
だからわざわざそれをコンパイルエラーで確認するのかって話になるだろ
>>84
でもaは使えなくならないよね

**仕様書無しさん** · 2024/10/20(日) 13:05:09.09

>>1
値型と参照型って何のこと？
Rustは全ての型に対して値と参照の両方があるよ
もしプログラマーがそれらを取り違えばコンパイルエラーとなるから問題は起きないよ
まずは正しい現状認識をしてから批判しようね

警備員[Lv.16] · 2024/10/20(日) 13:19:31.73

>>90
だからわざわざコンパイルエラー確認しましょうってことだろ？
どっち使ってんのかわかんないから
どっち使ってるかわかんねぇからコンパイルエラーで確認しましょうってそんなスマートか？
俺なら無理

警備員[Lv.16] · 2024/10/20(日) 13:20:41.41

普通の人間ならコンパイルエラーで確認するより書かれたプログラムの中身見て判断できるようになったほうがいいよねってなると思うよ
それがいわゆる可読性というやつや

**仕様書無しさん** · 2024/10/20(日) 13:33:04.04

>>91 >>92
型の違いなどはどの言語もコンパイル時にエラーか実行時にエラーとなる
もちろんRustのようにコンパイル時にエラーとなる言語の方が優れている

**仕様書無しさん** · 2024/10/20(日) 14:06:18.94

Rust書いた事ない人が言いそうな事だな。
vs-codeなりなんなりでコード書いてればコンパイルするまでもなく書いてるそばから rust analyzer が間違いを指摘してくれるのに。どう直せばいいかも細かく出てくるよ。

**仕様書無しさん** · 2024/10/20(日) 14:26:59.39

>>93
実行時エラーが出るまでわからないプログラミング言語はその仕様が静的にエラーを指摘できない言語仕様になってるからな
例えばC/C++のサニタイザーも実行させて問題が発生した時に初めてコードに問題があることがわかる
実行前に静的に様々な問題が判明できる最先端の言語はRustで間違いない

**仕様書無しさん** · 2024/10/20(日) 16:04:59.07

プログラム板のRustスレにいる人が出張してきてるね

警備員[Lv.16] · 2024/10/20(日) 16:28:14.26

>>94
それIDEが無いと無理でしょ

警備員[Lv.16] · 2024/10/20(日) 16:30:01.63

ふつうにコピーして渡してるのか参照で渡してるのかくらいプログラムのコード見て分かるようになったほうが遥かにいいだろ
Rust信者は盲信してるだけで普通の感性が全くない頭悪い人間ども

**仕様書無しさん** · 2024/10/20(日) 16:45:11.52

>>98
実際にプログラミングをすればわかる
ほとんどのムーブは関数呼び出しの引数や返り値に表れる
そしてほとんどの関数の引数はムーブではなく参照を受け取る
つまりムーブで渡してしまう関数は限られた特殊なものだけなのだ
レアケースなのですぐに意識できるため困る人が出現していない

**仕様書無しさん** · 2024/10/20(日) 16:48:55.21

>>97
普段コード書くのに何のエディタ使ってるんだよ。今時、emacsでもvimでもrust analyzer使えるぞ？
もし Langurge Server Protocol に対応してないエディタ使ってたらそれがこそプログラム書いてない証拠。

**仕様書無しさん** · 2024/10/20(日) 16:57:37.13

rustfmtとclippyとrustcだけがあれば十分
LSPは補助輪として優秀だが必須ではない
むしろLSPに依存しないとコーディングできなき人は下に見られる

**仕様書無しさん** · 2024/10/20(日) 17:00:06.92

>>98
Rustでは必ず区別がつきますよ
参照で渡すときは「＆変数名」となります
まずは基本知識を身に着けましょうね

**仕様書無しさん** · 2024/10/20(日) 17:42:31.87

C#でもIDEが無ければ
var b = a;
のコードが参照なのかコピーなのか分からないんだが
int b = a; のように型を付ければ分かるのはRustも同じで、 let b: i32 = a; と書くこともできる

警備員[Lv.17] · 2024/10/20(日) 19:34:34.90

>>102
いやポインタ渡してんだから移譲が参照渡しだろうが！

警備員[Lv.17] · 2024/10/20(日) 19:35:31.52

>>103
参照かコピーかわからなくてもaはその後も使えるけどな

警備員[Lv.17] · 2024/10/20(日) 19:37:46.89

俺が言ってるのはコピーか参照かわからんじゃなくてどっちがその後でその変数が使えるかわからんだ
どっちも使えなくすればそれでいいんよ
で.mcopyがあればそれはそのあとでもつかえるよって簡単にわかっていいよねって話なんだが
でなんでそれをやってないかというとそういうの考えずに作った欠陥言語だからってわけ

警備員[Lv.17] · 2024/10/20(日) 19:38:14.40

おれがダブスタって言ってるのは常にこのことについて言ってんだわ

警備員[Lv.17] · 2024/10/20(日) 19:39:50.59

IDEでデバッガー使って>>11これをやってんのがお前ら
わかる？

**仕様書無しさん** · 2024/10/20(日) 19:42:48.88

>>104
ムーブは参照渡しではありません
ムーブは値渡しです
コピーも値渡しです
ムーブとコピーは元が残るかどうかの違いだけで同じカテゴリに属します

警備員[Lv.17] · 2024/10/20(日) 19:46:02.90

>>109
ムーブが値渡しぃ？
大量のデータわざわざコピーしてんの？

**仕様書無しさん** · 2024/10/20(日) 19:52:41.19

>>104
移譲はポインタ渡しをしない

以下は生成コードレベルの話になるが
関数へ引数を渡す時に
移譲でもコピーでも小さい値(例えば64bitのLinux環境なら48バイト以下)ならばレジスタ(最大6個使用)で関数に渡される
移譲でもコピーでも巨大な値ならば最適化によりポインタ渡しになる
つまり移譲とコピーは全く同じ

**仕様書無しさん** · 2024/10/20(日) 20:04:03.69

>>108
C#から来るととっつきにくいかもしれないけの、C++をやってた人は割と入りやすいし、学んだ言語による慣れの問題だと思う
&記号の意味もC++に近いし、ムーブもC++にある概念だし

**仕様書無しさん** · 2024/10/20(日) 20:23:37.92

>>110
ムーブもコピーも値渡しなので関数へは基本的にレジスタ群に値を入れて渡されるよ
例えば以下の例

// ムーブされる構造体例
struct MovablePoint { x: i64, y: i64, }

// コピーされる構造体例
#[derive(Copy, Clone)]
struct CopyablePoint { x: i64, y: i64, }

ムーブとコピーの渡し方に違いはなく両者とも同じで
関数へ渡す場合はどちらも2つの64bitレジスタを使って値渡しされるよ

だから>>1さんが無知で『ムーブは参照渡しされる』と誤解をしているだけですね

**仕様書無しさん** · 2024/10/20(日) 20:27:59.07

>>110
雑にいえばポインタだけコピーする感じ
10万文字の文字列を扱う場合でも、大抵は文字列はヒープに確保されて、スタックにはそのアドレスや文字列長などの管理用のデータだけ置かれる
ムーブする際はその管理用のデータだけコピーするので、巨大な文字列のコピーは起こらない

ムーブした後はヒープのデータの所有権 (解放の責務も含む) がムーブ先の変数に移すので、ムーブ前の変数はそれを使えなくなる
ファイルハンドルなんかも同じで、解放などの責務を持つリソースについて気軽なコピーをさせないよう制限してる感じ

**仕様書無しさん** · 2024/10/20(日) 20:38:40.43

1みたいなこの手の無能はほぼレジスタの知識がない
バイナリレベルを学んでないから話が噛み合わない

**仕様書無しさん** · 2024/10/20(日) 20:48:47.82

Rustはメモリ周りを意識させられる言語なのはその通りなので、そこは受け切れざるを得ない
そこまでの効率性を求めない分野だったらRustである必要もないので、素直に他の言語を使うのも選択肢だと思う
(個人的にはリソース管理だけでなく、型表現の豊かさなどRustの利点は他にもあると思ってるけど)

C++やってた身からすると、C++で踏みがちな罠に繋がる道がほとんど塞がれてる感じで、それがかなり有用なのよ

**仕様書無しさん** · 2024/10/20(日) 22:04:12.19

Rustは非常にシンプルでこの3つしかない
・ムーブ値渡し
・コピー値渡し
・参照渡し　(値への参照が渡される)

Rustはレジスタのない環境(例: Wasm)にも対応しているのでレジスタを意識する必要はない
(むしろ環境指定してる場合を除いてレジスタを仮定してはいけない)

参照とアドレスはイコールではない
スライスなど可変長の値への参照は値を指すアドレスと長さのペアになる
トレイトオブジェクトへの参照は値を指すアドレスとvtableを指すアドレスのペアになる

**仕様書無しさん** · 2024/10/20(日) 23:54:03.34

結局>>1が自己中に勝手な妄想で勘違いしてイチャモンつけていただけだったな

**仕様書無しさん** · 2024/10/21(月) 00:19:35.69

なんだかプログラム学習で変数という概念に引っかかっている人を相手しているみたいな気分だな
Rust書いてる人的にはひっかかる要素がなさすぎて、たぶん1が一体何にひっかかってるのかすら誰もわかってない

**仕様書無しさん** · 2024/10/21(月) 00:31:38.32

あいつは世間知らずのC#教で何かにケチつけたいだけの人間ですから

警備員[Lv.18] · 2024/10/21(月) 02:03:49.74

Rust信者ってメモリのアドレスを渡す事を参照渡しって言わないんだね
メモリのアドレス渡すから参照渡しなんだろ

警備員[Lv.18] · 2024/10/21(月) 02:05:34.21

>>118
いや妄想では無いよね
プリミティヴ型と普通の型で振る舞い変えるのは事実だろ
俺はそれについてダブスタと言ってんの
事実を捻じ曲げて自分が勝ってるように見せるのやめてくれな？

警備員[Lv.18] · 2024/10/21(月) 02:06:28.82

>>119
とかいうおまえも>>11こういうことやってんだろうなぁw
デバッガーに頼らないといけない言語だもんなぁ

警備員[Lv.18] · 2024/10/21(月) 02:12:00.28

引っかかる要素無いのはお前が何も考えずにRust使ってるからなんじゃないの？
普通の感性してるなら同じ宣言してるのに振る舞い変えるなよって思うが

**仕様書無しさん** · 2024/10/21(月) 02:36:07.41

>>121
値自体のデータを渡すことが値渡し
値への参照データを渡すことが参照渡し

値が固定長ならば参照データはアドレスのみ
値が可変長ならば参照データはアドレスと長さ
値が動的型(dyn Trait)ならば参照データはアドレスとその実型用vtable(を指すアドレス)
それぞれの状況に応じてそれら参照データが渡される

**仕様書無しさん** · 2024/10/21(月) 02:50:30.84

fn main() {
// copyの例
let x = 5;
print_value(x);
println!("After value passing: x = {}", x); // xは依然として使用可能

// 参照渡しの例
let mut y = String::from("hello");
print_reference(&y);
println!("After reference passing: y = {}", y); // yは依然として使用可能

// moveの例
let z = String::from("world");
take_ownership(z);
// println!("After moving: z = {}", z); // これはコンパイルエラーになる

// 可変参照の例
let mut w = String::from("rust");
modify_string(&mut w);
println!("After mutable reference: w = {}", w);
}

参照渡しとムーブを混同してる。参照渡しの場合は関数呼んだ後でもアクセス出来る。可変参照でもね。

**仕様書無しさん** · 2024/10/21(月) 03:04:10.81

普通は関数呼んだあとも変数使える方が便利だしそのようにするのよ。参照で渡せる場合はそうする。
逆にムーブが発生する場合は意図的に所有権を渡している。その違いは関数見りゃ解るし、引数の型見ればわかる。

**仕様書無しさん** · 2024/10/21(月) 03:25:36.78

>>121
例えば文字列(str)への参照を受け渡す場合
アドレスだけ渡されても長さがわからなければ意味ないでしょ
可変長サイズのデータの参照はアドレス＋長さになります
常識的に考えればわかるよね

**仕様書無しさん** · 2024/10/21(月) 03:31:14.58

>>123
その>>11を見たらめちゃくちゃデタラメで意味不明な書き込みだぞ

＞これは値型だからこいつに代入しても使える～
＞こいつは参照型だからもうこの変数使わないどこ～
＞とかやってんだろうなw

**仕様書無しさん** · 2024/10/21(月) 03:56:20.16

>>1さんは参照がムーブすると思い込んでる病気なのよ

**仕様書無しさん** · 2024/10/21(月) 05:13:21.64

LSPとデバッガの区別も付いてないし。プログラミングしてないのは明らか。

**仕様書無しさん** · 2024/10/21(月) 05:22:40.44

>>29
例えばこの例で書かれたような拙いプログラムでも別にいいのよ。どうせコンパイラが最適化して重複削除するから変数領域すら確保されない、実際copyされるわけないし、スタックでリークする要素全くないし。
何を心配してるのか分からん。

**仕様書無しさん** · 2024/10/21(月) 05:53:54.01

あー変数への代入と束縛の違いもわかってなさそう。
rustのletは代入じゃなくて束縛ですよ。
ムーブしたなら同じアドレスに対する名前がつけ変わるだけですよ。

警備員[Lv.18] · 2024/10/21(月) 07:14:25.95

>>129
すまんどこがでたらめなんだ？
お前らがデバッガー見てやってることだけど

警備員[Lv.18] · 2024/10/21(月) 07:24:38.81

>>132
だからさぁ
メモリリークしちゃうのが問題なんじゃなくてこんな拙いクソコードを書く可能性があるって話してんの
わかる？

警備員[Lv.18] · 2024/10/21(月) 07:27:42.57

でそれを回避しようとするにはデバッガー見て
>>11をしないといけない
なんならlet a ＝ 3.402823eの場合はプリミティヴ型だからコンパイルエラーは出ない
だからいちいち割り当てていかないと上のような訳のわからないコードを描いてしまうことになる

**仕様書無しさん** · 2024/10/21(月) 08:38:19.25

>>122
>>プリミティヴ型と普通の型で振る舞い変えるのは事実だろ

そんな事実はない
そもそも普通の型なんていう分類はない
何を言いたいのか？

**仕様書無しさん** · 2024/10/21(月) 08:43:11.94

他の言語とは違って
Rustではデータ競合も参照競合も発生しないため
意図せずデータが書き換わってしまうことが発生しないので
デバッガーのお世話になったことが一度もない

>>136
デバッガーなんてRustで使わないので
あなたの文章の意味がわからないです

**仕様書無しさん** · 2024/10/21(月) 09:00:26.63

>>135
メモリリークしない事は理解できたのね。
心配はなくなったね。

仮に拙い書き方でもコンパイル出来たら出てくるコードは最適化されてて正しく動くんだから問題ないよね。むしろ優秀だよね。

**仕様書無しさん** · 2024/10/21(月) 09:03:58.31

Rustの前に、自分が本当に伝えたいことを整理する日本語コミュニケーション能力を学んだほうがいい
主張の正当性の前に、何言ってるかすら誰にも伝わってないのはわかるだろう

**仕様書無しさん** · 2024/10/21(月) 12:44:30.03

そりゃ無職だからなあ

**仕様書無しさん** · 2024/10/21(月) 15:59:11.07

>>1
>>値型と参照型で振る舞い変えるダブスタ言語だけど使ってるやついる？

参照ではない値の型をTとして
その値の参照の型を&Tとすると
値Tと参照&Tで振る舞いが異なるのは当たり前じゃないかな？
値そのものとそこを指す参照(アドレスなど)に違いは必ず出るよ
何を言いたいのか主張がよくわからないね

むしろRustは値Tでも参照&Tでも区別なく
同じ記法「.フィールド名」「.メソッド名()」で記述できるから
C/C++よりもシンプルだね

**仕様書無しさん** · 2024/10/21(月) 21:34:03.60

>>11についていえば、参照に&付けるのはC++もそうだよ

// aに巨大なデータが格納されてるとする
auto a = vector<uint8_t>();

auto b = a; // コピー
auto& c = a; // 参照
auto d = move(a); // ムーブ, これ以降aやcは使用不可

&を付けないと巨大なコピーが行われるので、C++開発者は気を付けて書く必要がある
(画像処理とかだとありがちだけど、aが数十MBのメモリを確保してるオブジェクトだとしたら？)

Rustはコピーとムーブのどちらに明示が必要かが逆なだけで、参照などの概念は同じ (C++はムーブにmoveが必要、Rustはコピーにcloneが必要)
GCを使う言語とは違うけど、参照かどうかの区別はC++開発者にとっては当たり前で、Rust特有ってわけでもない
intなどの型でムーブを使う理由が無い点も同じ

**仕様書無しさん** · 2024/10/21(月) 21:34:37.10

更に言えば、C++だとムーブ後の変数を使ってもコンパイルエラーにならず実行時に問題を引き起こすので、使うのに注意が要る
デフォルトがコピーなのは安全だけど、意図せぬパフォーマンス低下を引き起こしやすい
(「ムーブは可能だけどコピーは不可能なクラス」を作る方法もある)

Rustはムーブ後の変数の使用をコンパイルエラーにした上でデフォルトをこちらにして、コストのかかるコピーを明示が必要にするという考え