Rustとか言うダブスタ言語

**仕様書無しさん** · 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はムーブ後の変数の使用をコンパイルエラーにした上でデフォルトをこちらにして、コストのかかるコピーを明示が必要にするという考え

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

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

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

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

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

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

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

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

警備員[Lv.7][新芽] · 2024/10/22(火) 12:28:01.05

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

警備員[Lv.7][新芽] · 2024/10/22(火) 12:29:53.80

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

警備員[Lv.7][新芽] · 2024/10/22(火) 12:30:33.15

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

**仕様書無しさん** · 2024/10/22(火) 13:12:30.07

>>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型です

**仕様書無しさん** · 2024/10/22(火) 13:27:58.50

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

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

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

**仕様書無しさん** · 2024/10/22(火) 14:08:17.06

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

**仕様書無しさん** · 2024/10/22(火) 17:54:16.14

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

警備員[Lv.4][新芽] · 2024/10/22(火) 19:31:32.76

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

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

**仕様書無しさん** · 2024/10/22(火) 19:48:23.93

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

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

**仕様書無しさん** · 2024/10/22(火) 20:10:09.50

// 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実装したから好きにして。
これで読みやすくなる？

**仕様書無しさん** · 2024/10/22(火) 21:17:13.30

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

**仕様書無しさん** · 2024/10/22(火) 21:29:02.86

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

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

**仕様書無しさん** · 2024/10/22(火) 21:37:15.18

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

**仕様書無しさん** · 2024/10/23(水) 00:10:06.06

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

**仕様書無しさん** · 2024/10/23(水) 06:33:50.46

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

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

警備員[Lv.6][新芽] · 2024/10/23(水) 07:22:58.28

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

警備員[Lv.6][新芽] · 2024/10/23(水) 07:24:25.49

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

警備員[Lv.6][新芽] · 2024/10/23(水) 07:26:57.62

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

**仕様書無しさん** · 2024/10/23(水) 07:40:07.56

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

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

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

**仕様書無しさん** · 2024/10/23(水) 17:11:17.22

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

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

**仕様書無しさん** · 2024/10/24(木) 16:02:01.63

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

**仕様書無しさん** · 2024/10/25(金) 12:56:54.88

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

**仕様書無しさん** · 2024/10/25(金) 19:17:54.04

>>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の文字列も上記のように動作

**仕様書無しさん** · 2024/10/27(日) 14:31:17.99

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

**仕様書無しさん** · 2025/01/31(金) 08:58:53.87

【結婚難】違反SEの代償【孤独死】

☆大損害だから稼働減らして収入増やせ☆

金稼ぎ妨害！
共働き妨害！

時間外労働違反
　 ↓
偽装委託多重派遣
　 ↓
低技術
　　 ↓
低収入
　　 ↓
結婚難
　　 ↓
孤独死

反社会な孤独死の現場
https://i.imgur.com/pALCFXJ.jpg