Rustとか言うダブスタ言語

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

いる

>>2
どうやって心の整理つけてる？
俺はこんなクソ設計の塊みたいなダブスタ言語使いたくないって思っちゃったわ

何がダブスタと思ってるのかわからない
何がわからないのかわからない
キミが使いこなせないのはわかった
がんばれー

一定の複雑さをオーバーすると発狂する低能

>>4
だから値型と参照型でlet a ＝ bの振る舞いが違ってくるでしょ
値型の場合bは再度使えるけど参照型の場合bはprintfでも使えない(コンパイルエラーになる)
同じコードで
let a ＝ str bと
let a ＝ String::bで比べてみたらわかるよ

ちなみにわかってると思うけどstr型は値型でString::型は参照型なタコ

所有権の考え方ってRustやるなら変数より前に習うぐらいじゃないの？

すまん文法間違えてた
正しくはstrは &str
String::bは std::string bだ

>>8
そのうえで値型と参照型で振る舞いを変えるダブスタ言語だなぁって思いました。

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

用途に応じて使う型を変えることの何がダブスタなんだろう・・・

単純作業で修行しなはれ
値を代入したり譲渡したり何なり

値型なんてあったかな
プリミティブ型とは違うのか

>>12
普通のプログラミング言語はちがうけど
値型だろうが参照型だろうが変数が使えなくなることなんて割と無い

>>14
それがいわゆる値型
メモリそのものに値が入ってるから値型

>>15
所有権を移してるんでないか？

参照型はアドレスが入ってる

>>17
だからその所有権移したりコピーした値を渡したりダブスタだろって言う話

所有権の管理を俺様ではなくたかがプログラム言語ごときが勝手にやるのが気に食わないっていうのなら言ってることはわかるけど
ダブスタと言われると意味が分からない

>>20
ダブスタだろ
値型と参照型で振る舞い変えるんだから

ここで言う値型が、所有権を失ったり失わなかったりコロコロ挙動が変わるならまあダブスタだけど
参照だって定義してるんならそりゃ動きも変わるだろう

そこまで理解していて「わからない」とか言ってるのがわからない

>>23
いやなんで2つの振る舞いにしたの？ってなるくね？
値型もメモリコピーしないで参照型のように値渡したら開放するでいいじゃん

Rustに値型と参照型という区別はないぞ
参照という概念はあるけど、これは &i32 なども作れるもので、「整数なら値型」といったものではない
どちらかというとC++に近い

let a = b でbが所有権を失うかどうかは、その型が「コピー可能かどうか」で決まる

Rustでグラフィックやると面白い
まぁCでもC++でもいいけど

>>25
メモリコピーできるかできないかだろ？
でそのメモリコピーできるかできないかで変数の振る舞いを変えるの？

>>26
でもあれって結局DirectXラップするだけなのでは？
それともDirectXすら使わずに1から作るってことかい？

例えばめちゃくちゃ誇張した表現にはなるが

fn main() {
let a＝3.402823e+38;←便宜上float16の最大値とする(4byte)
Hoge(a);←Rustわかってないやつはここでaが移譲されたと勘違いする
let b＝3.402823e+38;←もう一度使いたいがために宣言する
Hage(b);
.
.
.
}
↑
こんな感じのことやってたらチリ積でメモリリークしてないか？(↑の例をだと8byteのメモリリーク)
aやbが解放されないから

コピーするかしないかって相当重要なポイントだと思うんだけど
なんだろうWeb系ばっかやってるとそういうのどうでもいいと思うのかね？

>>30
いや重要なのはわかるけど変数に代入したあとは解放なりなんなりすればよくないか？
それか普通の言語のように記述を変えるか
let b ＝ mcopy(a);
とかならだれも文句言わないけど

a.mcopy;とかでもいいよaはメモリコピーインターフェースを実装しているならこれが一般的な書き方になるか？

だから型を変えることで記述変えてるじゃん？
他の言語の記法が絶対正義でRust固有のものは常に間違ってるっていうなら、それはもうどうしようもない

Rustの良いところってintやfloat,longなんかにbit数書いてるところだよね
あれたまにど忘れしちゃうときあるからみたらわかるの便利

>>33
記述は変えてなくね？

>>29
RAIIでググれ
変数はスコープを外れたら寿命が尽きるからリークにはならないし、そもそもスタックとヒープの違いを理解してないと思う

所有権はメモリだけでなくリソース管理の問題でもある
ファイルハンドルなんかが良い例で、実態はせいぜい数バイトしかないからコピー自体にコストがかかるわけではないんだけど、ファイルというリソースに絡むから所有権の管理の対象になる
あるファイルへのアクセスを行う変数が同時に複数ある状態を許容しない、ということ

共有するなら Rc や Arc などの『シェアされてる』ことを示す型でのラップが必要だし、実際にアクセスする際に Mutex などでのガードが必要になる
これらをコンパイル時に制限することでバグを生みにくい設計にしようというのがRust的な考え方

全く見たことがない言語なんだ、なんか発狂している海外のエンジニアを見るとこの言語は大丈夫なのかとは思う

名前通りだよまったく

rustではコピートレイトが実装されてる型というのがあって、基本的にはプリミティブな型がそれに相当するの。で、それらはスタックに確保されるから解放しなくていいの。コピートレイトを実装出来る条件というのがあって、デストラクタが不要な物に限るの。解放しなくていいものだけ。わかりやすいでしょ？

ヒープに確保したらどんな型だろうが開放しないといけないのでは？

i32型ならスタックに確保される。
ヒープに確保したかったらBox<i32>で、それはもう別の型。なのでコピー出来ない。

わあわかりやすい

デストラクト不要のプリミティブ型は小文字で書かれてて、それ以外の型は大文字で書かれてるでしょ。
一応その辺でCopyが出来るか区別つくようにはなってる。

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「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

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

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

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

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

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

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

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

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

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

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 って書いてもいいんですよ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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だと安心してコードを書ける感じがする

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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);
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そりゃ無職だからなあ

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

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

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

>>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などの型でムーブを使う理由が無い点も同じ

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

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

なので >>11 は自分の知ってる言語に無い概念を理解しようとすらしてないだけだと思う
Cしか知らない人がOOP言語の入門書を読んで「クラス」の章に文句言い続けてるようなのと変わらない

これはRustがどうとかじゃなくて、GCがある言語とそうでない言語の違い
GCのある言語の方が簡単なのはその通りなので、メモリ周りの詳細を気にしたくないなら素直に他の言語を使った方が良い
世の中の多くのプロジェクトはそれで十分なはず

CPUリソースもメモリリソースもGC言語はムダに消費してしまいます
GC言語を使うと速いマシンが必要になったり複数のマシンが必要になったりします
クラウド利用の場合も利用料金が高くなってしまいます
GC言語は電気代の面でもムダでありCo2排出量も増やすことになりふさわしくありません

C++でも「これは&を付けないと無駄なコピーが生じるな」「これはムーブ済みだから使ってはいけないな」とかを気を付けて書いてたんだよ
&を付け忘れて無駄なコピーが生じても、ムーブした後の変数に誤ってアクセスしても、C++コンパイラはそれを指摘してくれない
Rustのコンパイラはこれらをエラーにしてくれるし、エラー原因を示すメッセージも丁寧だから、この点はC++よりもずっと分かりやすい

>>137
事実はあるだろ
プリミティヴ型とプリミティヴ型ではない型でそれぞれ
let b＝a;
をやった時println(a);が出来るのと出来ないのがある
これを振る舞いが変わらないとはならない
>>142
上のレスに例のコード書いてるからよく読めアホ

let b ＝ a;
をすると一律でaが使えなくなるならそれでいいんだよ
だけどこのダブスタ言語はaが使えなくなるときとaが使える時両方あるってのが問題
いっそのこと値型であろうとメモリ解放してやればいいんだよ
なんのためにこのメモリをブロック終了まで保持してんだ？

移譲で使えなくなるのが問題無いなら値型も使えなくなって問題ないだろ

>>149
デタラメはよくないですよ
Rustは大きく分けると2種類の型があります
・Copyトレイト実装型　(Copy型)
・Copyトレイト非実装型　(!Copy型)

前者はプリミティブ型であるi32やf64やcharなどだけでなく
std::fs::FileTypeやstd::net::SocketAddrなどもCopy型です
後者はプリミティブ型であるarrayやsliceやstrなどが!Copy型です

ちなみに参照型＆TはCopy型です
可変参照型＆mut Tは!Copy型です

>>150
ブロック終了までメモリ確保してるってのが間違いって何度も言ってるのにまだわからないの？プリミティブ型で開放するメモリなど最初からないってのよ。
ましてや定数ならそもそも変数領域さえ作らない。

ムーブがデフォなんじゃなくて、コピーが基本でコピーが出来ない型だけムーブなの。c++みたいにムーブの時だけmoveって書く仕様なら納得するの？

そうなったらそうで絶対文句言うのよ。イコールって書いたらコンパイルエラーが出たとか、moveって書いてもムーブ出来ない時があるってね。c＋＋でムーブセマンティクスが流行らなかったのはそれだからね。

ダブスタっていうなら、それこそC++の
「ムーブするかコピーするかを決めるのはコンパイラ様だ！
人ごときがstd::moveとか書こうが無視してコピーしてやる！エラーも警告も出さねえぜ！」
ってやつのことだよな。あれがクソっていうなら同意。

>>150
Rustでは明示的に指定しない限りコストの高いヒープ領域メモリを使用しない
スタック領域メモリが使われるわけだが関数やブロック内で既に使い終わっている変数があればそれが使っていた領域を安全に再利用するので最小限のサイズしかスタックを消費しない
さらにレジスタがある環境ならばレジスタを使用すれば済む分はスタックを消費しない
そしてスタック領域メモリの解放とは関数の呼び出し元に戻る時にスタックポインタなどを元の位置に戻すことのみしかコストはかからない

>>153
だとしても再度使えるようにするのは意味わからんだろ
開放しろって話
>>155
だからコストかからないとかどうとかじゃなくてコードから把握できないから全て渡したら解放にしろよって話なんだわ
解放しない場合は.mcopyだの後ろにつけとけばいいだろ

なんでお前ら人の話聞かないの？

>>156
いやヒープも使ってない変数を解放出来るプログラム言語存在しないだろ？
解放しないんじゃなくて出来ないのよ？
何もしない空関数呼ぶの？
それこそ馬鹿でしょ。
何基準に合わせろと言うのよ？

ムーブの時だけmove付けろならまだ話になるが。
そうしない理由はc++からの教訓って話しもしてる。

// MCopyトレイトを定義
pub trait MCopy {
fn mcopy(&self) -> Self;
}

// プリミティブ型に対して一括実装
macro_rules! impl_mcopy {
($($t:ty),*) => {
$(
impl MCopy for $t {
fn mcopy(&self) -> Self {
*self
}
}
)*
}
}

// 全てのプリミティブ型に実装
impl_mcopy!(
u8, u16, u32, u64, u128, usize,
i8, i16, i32, i64, i128, isize,
f32, f64,
bool,
char
);

はい、もう何がしたいのか分からないけどプリミティブ型にmcopy実装したから好きにして。
これで読みやすくなる？

>ブロック終了までメモリ確保してる
スタックとヒープの違いが本当に分からないんだな
「構文上のルール統一のために変数を使えなくする」は可不可でいえばできるけど、それで何かしらリソースが解放されたりパフォーマンス上のメリットがあるわけでもない
パフォーマンスやリソース管理などの理由があるケースでのみムーブされるだけなんだし

型によって管理が変わるって他の言語でもあるだろ
C#で
{
　var a = new Foo();
}
という書き方が問題ないかは Foo の実装に依存する

なんでGCに任せられない型があるの？ダブスタを解消するために「全ての型で明示的なDisposeの呼び出しが必要」にしたりしないの？
とか言わないだろ

>>156
何を解放しろと主張しているの？
その整数値は例えばレジスタに即値ロードされるか
あるいは他の関数からレジスタに入って返り値として返ってくるんだよ
もし何の用途にも使われなければ最適化でそのレジスタの使用すらなくなるし
もし他の関数に渡すなら別のレジスタにコピーされて引数として渡される
そしてレジスタは次々と別の用途に使われていく
いったい何を解放しろと主張しているの？

ダブスタだ解放だとゴネてるから意味不明だけど
1が言いたいのって、Haskell見た初心者が「記号だらけで意味不明でクソ。英単語で構文を作れ」
って言うレベルの難癖なんじゃねえの？

>>6
参照型＆TはCopyトレイトを実装しているのでコピーされて何度でも使えるよ

>>7
＆strも＆Stringどちらも参照型だよ
strは可変長なのでそのまま扱わずに参照型＆strとして用いるよ
Stringもそのまま扱うのは生成する時だけで読み取りは＆strとして扱うよ
書き換えの時は可変参照型＆mut Stringとして扱うよ

>>157
メモリ解放すればいいだろ

>>162
pragmaまみれの構文書いてるやつは言うことが違うね

>>160
Dispose()を呼ばなければならないのは例外だから
プリミティヴ型は基本型のなの通り基本なんだよ？

>>164
このスレでメモリの仕組み理解してないのあなた1人だけよ。ありもしない幻想に囚われてる。

rustどころか他の言語も危ういから無理せずもっと簡単なのから試したほうがいいよ。

一応望みの物は >>158 に置いてあるのでちゃんと使ってよね。

>>49 >>122
プリミティブ型とは何かを勘違いしているのではないか
Rustではヒープメモリを前提とせずに使える基本パーツの型を指す

この公式ページに一覧が挙げられている
https://doc.rust-lang.org/std/#primitives
このようにarrayやsliceやstrなども当然プリミティブ型である

ムーブが基本でtrait Copyを実装しているCopy型だけ特別にコピーだね
プリミティブ型の中にもCopy型と!Copy型の両方あるね

結局1は俺が何言ってるか理解できない日本語すらわからんバカ共と話すことはないって
自分の中では大勝利して満足したんだろうか

>>158
Rustはトレイト境界の指定によりジェネリックで簡潔＆安全にこのように書けるよ

trait MCopy {
fn mcopy(&self) -> Self;
}

impl<T: Copy> MCopy for T {
fn mcopy(&self) -> Self {
*self
}
}

fn main() {
let x = 123.45;
let y = x.mcopy();
assert_eq!(x, y);

let x = "abc.de";
let y = x.mcopy();
assert_eq!(x, y);
}

strはCopy実装型ではないけど
&TがジェネリックにCopy実装型なので
&strの文字列も上記のように動作

multiple readers XOR single writerなので
可変がなければ参照はいくつでもコピーできるね
対照的に可変参照は独占的オンリーワンになる