Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/

**デフォルトの名無しさん** · 2024/06/24(月) 10:35:24.72

統合失調症 100人い１人
本当に音波電磁波攻撃だった場合
統合失調症の寿命は短いからして殺害されている

トロッコ問題にあてはめると
Aの線路に電磁波攻撃をしている者が100人いる
Bの線路に被害者が１人いる
トロッコに乗っている者も第三者
切り替えポイントに第３者がいる
間違いなく選んだ方の線路の者は全員死亡する

あなたはどちらを助けますか?

**デフォルトの名無しさん** · 2024/06/24(月) 12:53:49.42

少なくとも >>330 さんを助ける人は一人もいない

>>329
なるほど

**デフォルトの名無しさん** · 2024/06/24(月) 16:09:25.85

>>320
結局c++やってないと無理な気はするけどね。
c++は確かに建て増しでグダグダではあるんだが、
書き方の変遷をそのまま引き継いでるから、学習過程でその書き方を変遷させる過程を色々ビルドしながら
できるのはまあわかりやすくはあるんだわ。

**デフォルトの名無しさん** · 2024/06/24(月) 16:17:05.11

>>328
長くなるので最初の3つの部分だけで規則性を書くと、
1→2
2→1
3→3

**デフォルトの名無しさん** · 2024/06/24(月) 16:21:31.19

>>333
//1→2
//2→1
//3→3
(1) 四則演算のみ:
y=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
規則は、y0*(x-x1)(x-x2)のようなパターンを
サイクリック(循環的)に繰り返す。

(2)三項演算子、その1
y=x==1?2:(x==2?1:(x==3?3:0));

(3)三項演算子、その2
y= (x==1?2:0) + (x==2?1:0) + (x==3?3:0);

**デフォルトの名無しさん** · 2024/06/24(月) 16:28:01.78

スレチなのでよそでやって下さい

**デフォルトの名無しさん** · 2024/06/24(月) 17:42:58.06

>>328
const INPUT: &str = "
1→2
2→1
3→3
4→10
6→4
8→8
10→6
";

fn parse(s: &str) -> Vec<(i32, i32)> {
　s.lines().filter_map(|line| {
　　line.split('→')
　　　.map(str::parse::<i32>)
　　　.collect::<Result<Vec<_>, _>>()
　　　.ok()
　　　.and_then(|v| (v.len() == 2).then(|| (v[0], v[1])))
　})
　.collect::<Vec<_>>()
}

fn make_f(v: &[(i32, i32)]) -> impl Fn(i32) -> i32 + '_ {
　move |x| {
　　v.iter().enumerate().map(|(i, (in1, out))| {
　　　v.iter().enumerate().filter_map(|(j, (in2, _))| (i != j).then(|| x - in2)).product::<i32>() /
　　　v.iter().enumerate().filter_map(|(j, (in2, _))| (i != j).then(|| in1 - in2)).product::<i32>() * out
　　})
　　.sum()
　}
}

**デフォルトの名無しさん** · 2024/06/24(月) 17:43:39.86

>>336

fn main() {
　let v = parse(INPUT);
　let f = make_f(&v);
　for (input, output) in &v {
　　let calc_output = f(*input);
　　println!("{input} -> {calc_output}");
　　assert_eq!(calc_output, *output);
　}
}

結果
1 -> 2
2 -> 1
3 -> 3
4 -> 10
6 -> 4
8 -> 8
10 -> 6

**デフォルトの名無しさん** · 2024/06/24(月) 18:41:27.02

>>334
>y=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
間違ったわ。
多分、
y=1*(x-2)(x-3)-1*(x-1)(x-3)+3/2*(x-1)(x-2);
だと思うわ。
理由は大体分かると思うけど。

**デフォルトの名無しさん** · 2024/06/24(月) 18:41:27.42

>>334
>y=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
間違ったわ。
多分、
y=1*(x-2)(x-3)-1*(x-1)(x-3)+3/2*(x-1)(x-2);
だと思うわ。
理由は大体分かると思うけど。

**デフォルトの名無しさん** · 2024/06/24(月) 18:44:46.10

一般的には、次のように書けると思うわ:
a=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
b=(x-2)(x-3)+(x-1)(x-3)+(x-1)(x-2);
y=a/b;

**デフォルトの名無しさん** · 2024/06/24(月) 19:35:34.10

>>340
合っているかどうか以前に
プログラムコードで回答しないとスレ違い
具体的な数値例が式やコードに含まれるのは望ましくない
出来上がった関数の動作検算の時に具体的な数値例を用いる

**デフォルトの名無しさん** · 2024/06/24(月) 23:33:41.46

>>328-329
なんかダサい
https://paiza.io/projects/uc8gH6yNWCWKdQSYtqNREg
pub fn f(x: i32) -> i32 {
(
-2413f64*(x.pow(6) as f64)/120960f64
+739f64*(x.pow(5) as f64)/1260f64
-157991f64*(x.pow(4) as f64)/24192f64
+69551f64*(x.pow(3) as f64)/2016f64
-2691673f64*(x.pow(2) as f64)/30240f64
+88679f64*(x as f64)/840f64
-905f64/21f64
+0.5)
as i32
}
pub fn g(y: i32) -> i32 {
(
13f64*(y.pow(6) as f64)/120960f64
-(y.pow(5) as f64)/315f64
+1415f64*(y.pow(4) as f64)/24192f64
-1511f64*(y.pow(3) as f64)/2016f64
+144793f64*(y.pow(2) as f64)/30240f64
-3053f64*(y as f64)/280f64
+185f64/21f64
+0.5)
as i32
}
pub fn main() {
let a = vec![(1, 2), (2, 1), (3, 3), (4, 10), (6, 4), (8, 8), (10, 6)];
for (x, _y) in &a { println!("{}, {}", x, f(*x)); }
for (_x, y) in &a { println!("{}, {}", y, g(*y)); }
}

**デフォルトの名無しさん** · 2024/06/24(月) 23:39:26.44

係数はこっちで求めたでござる
https://paiza.io/projects/YvPFB5g4cCOtCXz1wpA86g
import sys, os
from functools import reduce
import sympy as sy

def lc(a):
x, y = sy.symbols('x y')
p = 0
for i, (c, d) in enumerate(a):
g = reduce(lambda s, t: (t[0], (s[1][0] * (1 if t[0] == i else (x - t[1][0])), 0)), enumerate(a), (-1, (1, 0)))
f = g[1][0]
p += d * f / f.subs(x, c)
print(p)
print(p.expand())
for c, d in a:
print(p.subs(x, c), p.subs(x, c) == d)

if __name__ == '__main__':
lc([(1, 2), (2, 1), (3, 3), (4, 10), (6, 4), (8, 8), (10, 6)])
lc([(2, 1), (1, 2), (3, 3), (10, 4), (4, 6), (8, 8), (6, 10)])

**デフォルトの名無しさん** · 2024/06/25(火) 01:47:22.24

1～10は4bitに収まるから64bitのシフト演算と論理積（&）がOKなら簡単なんだけどな
やることはテーブル参照と変わらんけど

**デフォルトの名無しさん** · 2024/06/25(火) 02:44:46.88

>>332
Rustを習得する上でC++の知識は不要
Cでの基礎知識(ポインタ、スタック、ヒープ)しか必要としない

>>343
ここはRustのスレだ

**デフォルトの名無しさん** · 2024/06/25(火) 05:16:25.10

>>342
6次式を使う場合それを展開することに意味があると思えないから展開前の>>336でいいんじゃない？

**デフォルトの名無しさん** · 2024/06/25(火) 07:25:12.24

>>346
ほぼ定数になる部分まで
実行時に二重ループで毎回計算してるのは効率悪いと思う

**デフォルトの名無しさん** · 2024/06/25(火) 07:47:56.32

>>345
っ move semantics
っ RAII
っ SmartPointer(Rc)

**デフォルトの名無しさん** · 2024/06/25(火) 08:03:22.73

>>348
そりゃすでにC++を知っているならそのへんの知識が流用できて楽だけど
新たに学ぶならわざわざC++を経由する必要なくね？
特にmoveとか明らかにC++のほうが複雑だし

**デフォルトの名無しさん** · 2024/06/25(火) 08:54:41.29

お題スレが機能しなくなってゴミがあふれてきてんのかこれ？

**デフォルトの名無しさん** · 2024/06/25(火) 09:00:44.98

>>349
c++通らなきゃなんでこんなめんどいことするか理解できんだろ

**デフォルトの名無しさん** · 2024/06/25(火) 09:03:31.00

「アセンブラ知らずにCって理解できるものなのか？」
↓
「C++の方が普通。Cは専門家向け」
↓
「いきなりRust」

**デフォルトの名無しさん** · 2024/06/25(火) 09:25:46.54

オレはPHPからRustに移行したよ
actix web使ってる
速さには感激してる

戸惑うのは謎のワーニングが出る時かな
mut付けてないのにmut付けるなってワーニング出たりする
cargo cleanとかすれば消えるんだけど

**デフォルトの名無しさん** · 2024/06/25(火) 09:32:01.85

>>351
Cでmalloc/free手書きしたりSEGV起こすだけで十分理解できると思うけどなぁ
C++じゃないとダメなのってどのへん？

**デフォルトの名無しさん** · 2024/06/25(火) 10:36:22.38

>>348
その3つはどの言語から来ても簡単にすんなり理解できるでしょ

>>353
PHPから来た人はジェネリクスはすんなり理解できるものなの？

**デフォルトの名無しさん** · 2024/06/25(火) 11:03:26.31

>>355
ジェネリクスが特段わかりずらいとは思わなかった
それより型があいまいなPHPから移行すると型定義したくてうずうずする
ちゃんと型定義したかったんだわ

**デフォルトの名無しさん** · 2024/06/25(火) 11:48:25.07

C++ を知っていると Rust がわかりやすいというよりも有難みを感じやすいとは思う。
なんだかんだで Rust は面倒くさいしそれなりに学習曲線の急上昇もあるのは本当だけど、
それでもなお Rust が良いと思えるのは C++ の駄目な部分についての反省が入ってるから。

C++ 的なものが必要な場面で C++ より上手くやるものという感覚で捉えてる。

**デフォルトの名無しさん** · 2024/06/25(火) 12:43:05.46

「Rustを学ぶためにC++を学ぶ必要があるか(学ぶといいか)」も定期的に沸くな

何度も見てて思うのが
「あなたはRustを学ぶ前にC++を学んでいたか」とYes/Noが一致して、平行線にしかならない議論なのでは

**デフォルトの名無しさん** · 2024/06/25(火) 13:05:45.82

フランス語を学ぶときに英語を知ってる必要があるか(學ぶといいか)を考えれば良い
日本語←→フランス語だけ教わりたいのに英語學ぶ必要は無い

**デフォルトの名無しさん** · 2024/06/25(火) 15:05:50.09

Rustを学ぶ前に他言語を学ぶ必要は無い。

しかしプログラム自体の経験が浅いのなら、絶壁の学習曲線に挫折する可能性が高い。そういう初学者はRusuではなく、とりあえずは動くところまで持っていきやすい言語を使って勉強したほうがいい。

**デフォルトの名無しさん** · 2024/06/25(火) 15:23:35.53

C++を経由しないでRustを使えてる人たちがたくさんいることから
C++が不要言語であることは間違いない

**デフォルトの名無しさん** · 2024/06/25(火) 15:29:24.75

>とりあえずは動くところまで持っていきやすい言語

Rustも変な事しなければとりあえずは動く
C/C++みたいに一見動いてるフリしてメモリ壊してたりに気付かない方が有害

**デフォルトの名無しさん** · 2024/06/25(火) 16:22:38.23

それはプログラミングに慣れてるから言えることで、
エラーになってくれることが心底から有難いことだと思えるのは
エラーにならずにぶっ壊れる体験を通してじゃないと無理だよ。

結果的にわかりやすいかどうかの話じゃなくて
学習する当人がちゃんと納得して学習し続けられるかというモチベーションの話としてね。

**デフォルトの名無しさん** · 2024/06/25(火) 16:57:26.38

Cでmalloc/free面倒とか忘れたとか解放したのにポインタ残っていて使っちゃったとか体験しておいたほうがよいかもしれないが
C++は不要

**デフォルトの名無しさん** · 2024/06/25(火) 17:23:57.01

>>363
つまり最初はPerlが良いってことか

**デフォルトの名無しさん** · 2024/06/25(火) 17:55:00.58

初心者レベルだと C/C++ もRust も向いてないって話

**デフォルトの名無しさん** · 2024/06/25(火) 19:32:04.37

そう言えばHaskell難しい言うやつも似たようなこと言ってたな。
そんなに難しいと感じてなかったから不思議だったんだが、
自分でバグ作っておいて言語が難しいとか言うなよ…。

**デフォルトの名無しさん** · 2024/06/25(火) 20:03:41.12

ID:ZtCD4zFU
ID:bjcoCLHQ

**デフォルトの名無しさん** · 2024/06/25(火) 20:13:30.50

関数型言語を使ってるとRustの理解が少し早くなるよ
特にHaskellを知っていればtraitの理解も早いね
しかしRustを学ぶために関数型言語を知っている必要はないんだよな
同様にC++も知っている必要はない

**デフォルトの名無しさん** · 2024/06/25(火) 22:48:01.04

Erlang使ってて良かったと思った

**デフォルトの名無しさん** · 2024/06/25(火) 23:04:44.45

バレおじw

**デフォルトの名無しさん** · 2024/06/25(火) 23:30:51.26

>>347
展開しないほうがよい

展開する時も二重ループは発生するだけでなく単なる計算より重い
さらに本来は回避できる浮動小数点を使わざるを得なくなる
そして>>342のコードをその例のような静的ではなく問題入力値に応じて動的に作り出さなければならない

一方で展開しないならばRustコード数行だけで済み任意の問題に対応できる
割り算部分も0/N=0かN/N=1だけなので整数で済む

**デフォルトの名無しさん** · 2024/06/25(火) 23:49:25.06

>>369
>特にHaskellを知っていればtraitの理解も早いね
これには全く同意できない
type classというかHaskellとはやり方もできることも違いすぎるから
そもそも何の事前知識なくてもtraitは容易に理解できるでしょ

**デフォルトの名無しさん** · 2024/06/26(水) 08:25:01.52

神精霊絶大なエネルギーを使用可能
幽霊人間を疲れさせるや一時操作可能
①エネルギーの貯蔵の仕方は➁そのエネルギーの発生方法は③そのエネルギーを貯蔵する方法は④それだけのエネルギーの物体を科学で観測不能はなぜ

6G通信に使われるテラヘルツ帯の電波、脳細胞の成長を促進
2022/08/16
タンパク質の操作／マイクロ波等の照射が記憶に影響
2008/11/01
男性の精子の減少、携帯電話の使用と関係か最新研究
2023/11/02
統合失調症.発達障害.各身体症状など国力低下
人為的で身体攻撃
威力を測定すれば判明するのにテロリストを野放し

全ての精神病
①　英キングス・カレッジ・ロンドンをはじめとするグループは、人間の脳内で発現している古代ウイルス由来のDNA配列を調べ、それがうつ病・統合失調症・双極性障害といった主要な精神疾患のなりやすさと関係していることを明らかにした。
➁九大、後の出来事が直前の出来事に錯覚を起こさせる脳の仕組みの一端を解明
2024/06/05
④幼児期の脳活動から18歳時点でのIQを予測できるという研究結果
2023/09/09
⑤3歳までに脳は形成される
⑥統合失調症などの患者に幻覚や妄想を引き起こす脳のネットワークがAIを使った研究で明らか

1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功
2024年05月10日
※MRIで物理的に神経の接続問題観測可能

嘘つきの知的障碍者と精神障碍者や認知症の者発見

◇電磁波攻撃はあるとないどの思考【組織】の者が話しているのかな
マイクロ波聴覚効果やボイス・トォ・スカル発見可能
電磁波している者守りたいもの守りたくないものの判別方法は各対象者の将来で名よある地位やよい未来の映像と悪い未来の映像を見てもらえば副交感神経と交感神経の差と脳波パターンをみたら判明する

**デフォルトの名無しさん** · 2024/06/26(水) 12:30:12.07

>>372
>割り算部分も0/N=0かN/N=1だけなので整数で済む
そうだね
この問題の本質はそこだと思うけどそれ言い出すとif使わない理由が無いな

**デフォルトの名無しさん** · 2024/06/26(水) 12:31:27.14

>>373
事前にやるならNimの方が良いよ

**デフォルトの名無しさん** · 2024/06/26(水) 13:01:41.83

Rustを学ぶ前に他の言語を学ぶ必要はないけど
全くプログラミング言語を知らないならシンプルで学習例も多いC言語一択だね
ポインタとヒープの扱いまで学べたらたらC言語を忘れてRustへ

**デフォルトの名無しさん** · 2024/06/26(水) 14:31:44.00

デストラクタの動きを知らないで本当にrustできんの？って思うけど

**デフォルトの名無しさん** · 2024/06/26(水) 14:43:55.70

スコープを抜けた時にデストラクタが自動的に呼ばれる
それだけ
予備知識を必要としない

**デフォルトの名無しさん** · 2024/06/26(水) 14:54:42.66

Rustのデストラクタの描き方ってなんであんなんなん

**デフォルトの名無しさん** · 2024/06/26(水) 15:00:49.20

C書くしかない時代だったからC勉強できたけど
Rustがある時代に純粋な教養としてC勉強なんて苦行できないだろ
修行僧かよ

**デフォルトの名無しさん** · 2024/06/26(水) 15:13:01.92

最近気付いたんだけどもしかしてRustの所有権って2通りの意味がある？

**デフォルトの名無しさん** · 2024/06/26(水) 17:42:24.19

>>382
そのココロは？

**デフォルトの名無しさん** · 2024/06/26(水) 18:05:02.22

>>378
それってc＋＋学ぶときも一緒じゃない？

**デフォルトの名無しさん** · 2024/06/26(水) 20:50:33.32

>>382
Rustを学ぶ上で所有権は忘れた方がいい
実はRustは非常にシンプルで
値をmoveして用いるか参照して用いるかしかない
(ただしCopy実装型はmoveの代わりにcopy)
値はmoveされないままスコープが尽きると消える
消える直前にデストラクタが呼ばれる
以上たったこれだけだ

**デフォルトの名無しさん** · 2024/06/26(水) 23:00:32.38

>>381
苦行はごちゃごちゃして煩わしい記述を強要されるRustだろ。fnだのmutだの略語が多く
殺伐としているし、記号の使い方なども含めて如何にもギークが作ったというような
美的感覚が欠如した野暮ったいコードを書き連ねるのはおぞましい。

Cと違って新しいSwiftはRustに機能的に近いが、Rustよりずっと洗練されている。

**デフォルトの名無しさん** · 2024/06/26(水) 23:26:44.75

Rust言語を知らないから見た目のキーワード批判しかできないのだ

**デフォルトの名無しさん** · 2024/06/27(木) 04:20:04.01

スタックは早くてヒープは遅い、みたいな話よく聞くんだけど、
具体的に何が早い/遅いの？

**デフォルトの名無しさん** · 2024/06/27(木) 04:33:33.49

>>388
自分でヒープメモリ管理部分を書いてみるとよくわかる
ヒープでメモリ確保したり解放したりするのは色んな処理が入って非常に遅い
スタック上ならそのコストはない
関数に入る＆抜けるときにスタックフレームを指してるレジスタの値を変えるだけ

というのに加えて
CPUの多段メモリキャッシュ機構での速さが桁が変わってくる
スタックフレーム上なら常にアクセスしていてキャッシュに載るから超速い

**デフォルトの名無しさん** · 2024/06/27(木) 07:18:32.22

>>386
mutが煩わしい言うてる時点で関数型プログラミングをまともに出来てないな。
今までの副作用だらけの言語だとマルチスレッドプログラミングが上手く出来ないから関数型プログラミングを取り込んだというのに。

Rustでごちゃごちゃしてると感じるならHaskellにおいで。
forやifと書くことすら煩わしく感じるくらいシンプルだよ。

**デフォルトの名無しさん** · 2024/06/27(木) 08:56:33.16

Swift、よく知らないんだよなあ
Appleの囲い込み言語という時点でもう勉強する気になれない

**デフォルトの名無しさん** · 2024/06/27(木) 09:08:39.14

C++ でも変更なしのときに const を付けるんじゃなくて変更ありのときに指定するほうがよかったという声は結構あるよな。
まあいまさら変更できんが。

**デフォルトの名無しさん** · 2024/06/27(木) 09:50:18.20

>>372
PyO3おすすめ

**デフォルトの名無しさん** · 2024/06/27(木) 10:07:28.99

>美的感覚が欠如した野暮ったいコード

禿しく同意

**デフォルトの名無しさん** · 2024/06/27(木) 10:21:46.91

>>389
キャッシュに乗るという前提なら、
確保・解放が遅いだけでアクセス速度とかは変わらないってことでOK？

キャッシュに乗る確率とかもスタックとヒープでやっぱちがうんかな

**デフォルトの名無しさん** · 2024/06/27(木) 10:30:52.47

キャッシュに載ったらアクセス速度変わるやろ

**デフォルトの名無しさん** · 2024/06/27(木) 10:33:46.61

そりゃ、キャッシュ・イズ・キングと言うぐらいだからな

**デフォルトの名無しさん** · 2024/06/27(木) 11:05:58.76

>>395
キャッシュに乗りやすいというのはアクセスに局所性があるということ。
関数自体が小さくてすぐ終わるなら普通はスタックのほうが以前と近い場所にアクセスすることになる。

**デフォルトの名無しさん** · 2024/06/27(木) 11:20:07.91

よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
「そんなわけないだろ」って思うんだけど

**デフォルトの名無しさん** · 2024/06/27(木) 11:56:53.85

>>395
スタックフレーム同士も連続しているし
レジスタ退避でアクセスしているし
他のローカル変数もスタック上にありアクセスしているから
スタック上に確保すればキャッシュ上にある

**デフォルトの名無しさん** · 2024/06/27(木) 12:00:05.74

>>399
関数が値を返す場合にサイズが小さければレジスタで返す
サイズが大きい場合は呼び出し元のスタックフレームに領域を確保してそこへ直接書き込んでいる
つまり暗に可変参照を渡す最適化が行われている
それはサイズの大きい値を返す関数呼び出しが多段でも同じなので一番最初の関数のスタックフレームに直接書き込まれる

**デフォルトの名無しさん** · 2024/06/27(木) 12:27:57.71

>>399
>「そんなわけないだろ」
その感覚は正しい
Rustを広めたいために勢い余ってデマを流してる香具師が一定数いる

>>401 が正しい

**デフォルトの名無しさん** · 2024/06/27(木) 12:45:47.11

>>399
>よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
これ自体なにを言いたいのかよくわからんけど
その前にそんなこと言ってるやつおる？

>>400
>スタック上に確保すればキャッシュ上にある
キャッシュから追い出される状況もあるよね

**デフォルトの名無しさん** · 2024/06/27(木) 12:53:21.92

>>402
いや>>399の話も正しいんだよ
重要なのはRust上の概念とその実現方法(実装)とその最適化の3つは当然異なるということ

所有権を移すとはmoveという概念であって
moveの実装はコピー(してコピー元を使わない)
ただし無駄なコピーは最適化で消える
例えば大きなサイズの構造体を関数が返す場合は呼び出し元の関数のスタックフレーム上に直接書き込まれることで無駄なコピーが発生しない

**デフォルトの名無しさん** · 2024/06/27(木) 13:06:53.73

それをスタックが縮むと表現してるのか
意味は分かった

**デフォルトの名無しさん** · 2024/06/27(木) 13:24:58.99

スタックてのは関数が何段か終了して縮んだあと、また伸び直して前の伸びを上書きしちゃうでしょって話
とにかく「移動」というのが新しくて、代入の移動はわかったけど
関数呼び出しの引数も移動です、返り値も移動ですってのがどういう実装に落とされるのかまだわかってない

**デフォルトの名無しさん** · 2024/06/27(木) 13:49:01.55

低レイヤで起こってることは C と変わらん。
寿命の矛盾がないか静的な検査がクソ強いってだけだ。

**デフォルトの名無しさん** · 2024/06/27(木) 15:56:45.17

スタックを伸ばすだの縮めるだのいうのはメモリのとある番地に実際のメモリを割り当てたり切り離したりすること。
スタックが足りなくなってきたら連続するアドレスのところに実メモリを割り当てるのがスタックを伸ばすってこと。
普通の使い方をしていたらスタック領域を縮めることはあんまりない。
スタックがあるところまで伸びたということはもう一度そこまで伸びる可能性が高いので回収してまた割り当ててをするよりは割り当てっぱなしにしたほうが良いという設計思想になってるので全体のメモリが足りている限りスタックが浅いところまで戻ってきても実メモリを回収しないというのが現代的な OS。
逆に言えば全体のメモリが足りなくなってきたら回収することもあるんだけど。

素人感覚だとメモリをなるべく空くようにするのが「メモリの無駄を防ぐ」という意識の人がいるんだけど、存在するメモリが使われないままになってるほうがもったいないんだ。

それとたとえば Linux だとスタックの大きさは 8MB が上限というのがデフォ。
これは OS 側の設定なのでアプリケーション側では (OS の設定をいじる権限がない限りは) どうにもできない。
8MB ってめちゃくちゃ少ないように感じるかもしれないけどだいたいこんなもんで足りちゃうんだよ。

**デフォルトの名無しさん** · 2024/06/27(木) 16:39:29.50

>>406の書いてる「縮む」はVecで言うところのcapacityじゃなくてlenっぽくない？
ムーブとの関連がよくわからんけど

**デフォルトの名無しさん** · 2024/06/27(木) 17:46:10.67

>>407
ですな

**デフォルトの名無しさん** · 2024/06/27(木) 17:59:42.80

低レイヤのメモリの取り扱いモデルが確立している高級言語が C/C++ くらいしかなくて、 LLVM も汎用的なフレームワークのふりして思ったほど自由ではないので Rust の言語仕様が LLVM の都合に、 C/C++ の都合に引っ張られているところはまあまあある。

**デフォルトの名無しさん** · 2024/06/27(木) 18:20:02.76

つまりC++同様、ポインタの糖衣構文としての参照？

**デフォルトの名無しさん** · 2024/06/27(木) 18:50:13.20

あ、なるほど
&mutみたいに*mutって書けば実体を扱えるわけか

**デフォルトの名無しさん** · 2024/06/27(木) 18:56:27.59

いつものことながら妙なこと書く人はだいたいThe Book(本物)を読んでないよな

**デフォルトの名無しさん** · 2024/06/27(木) 19:07:01.79

そんなの読むような真面目な人間は5chに来ない

**デフォルトの名無しさん** · 2024/06/27(木) 20:08:52.27

>>412
まあ機械語レベルの低レイヤまでいけば参照もポインタも同じっちゃおなじだけど、構文糖だという認識は明確に誤りだ。
参照がポインタの構文糖なんて書いてあるデタラメ本で C++ を学んだのなら C++ の理解も全然できてないと思う。
または書いてないことを脳内で作り出すタイプのやつは誤った方向に邁進してどうにもならなくなったところで質問したりするから言ってることが意味不明になりやすい。
仮に(あくまでも仮にだが！)言ってる理屈自体が正しかったとしてもちゃんとした用語でいってくれないと伝わらないし、ちゃんとした用語は(一次資料に基づいた)ちゃんとした資料で学ばないと身に付かん。

**デフォルトの名無しさん** · 2024/06/27(木) 22:40:30.91

>>406
そのmoveについてもmoveというRust上の概念の理解のみがRustを学習＆利用していく上で必要となるよ
moveによる生成コードがどのようになるかは最適化の方法の変更や進化で変わり得る話だから確定することはできず、学ぶこともできない
こんな場合に現在はたまたまこんな生成コードになっていることだけは実験などでわかるけど今後の保証はない、としか言えない
だからmoveはmoveとして理解することが唯一の正解でしょう

**デフォルトの名無しさん** · 2024/06/27(木) 22:43:00.49

どうせChatGPTの回答を使い回してるだけだろ

**デフォルトの名無しさん** · 2024/06/27(木) 22:45:03.57

>>416
C/C++でポインタのポインタと言わずに
ダブルポインタって言ってる香具師のことか

**デフォルトの名無しさん** · 2024/06/27(木) 23:03:07.98

Rustの各概念を無理矢理なC/C++と結びつけようとしたり生成コードと対応させようとしてる人々がRustを難しいと言ってるようにみえる
そんなことをせずに各概念の理解だけに集中すればRustはシンプルに出来ていてわかりやすい言語だと理解できるよ

**デフォルトの名無しさん** · 2024/06/27(木) 23:34:16.52

C/C++ だと抽象機械という概念を挟む形で仕様化されてる。
言語の挙動を抽象的な (架空の) 機械の動作として記述していて、それを実際の機械とどう対応させるかは知らんけど見かけ上の動作が仕様通りなら良しとする規定。
だから最適化を豪快にやっても結果が同じなら言語仕様に反しない。

で、抽象機械っていうのはある程度は現実のコンピュータを想定はしているけど細かいところは意図的にうやむやにして選択の余地を残してる。
C/C++ には言語仕様としてはスタックもヒープも存在せず書いてあるのは寿命についてのルールだけで、それをどういう形で実現するかは自由……
なんだけど現実にはスタックとヒープを使い分けるとちょうどいいような仕組みになってる。

C/C++ の言語仕様に低レイヤのメモリアクセスのことも確かに書いてあるんだ。
でもそれは抽象的な機械のことであって本物の機械のことじゃない。
でもある程度は対応しているという絶妙なバランスで成り立ってる。

Rust では言語の高レイヤの話と低レイヤの話の間を取り持つ理屈がまだ十分に整理されてないと思う。
言語の性質上、やっぱり低レイヤを全く意識しないで上手く使えるようなものでもないし、低レイヤのことを考えるのもそれなりには必要だと思う。
必要なんだけど意識的にレイヤを分けて考えられないなら混乱するのも確かなので、 (少なくとも最初は) 低レイヤのことは忘れろというのは理に適った助言だと思う。

**デフォルトの名無しさん** · 2024/06/27(木) 23:40:56.83

C/C++の方こそ誤魔化しているぜ
そのため未定義動作だらけだ

Rustはわかりやすく抽象的に明確だ
そして未定義動作もない

**デフォルトの名無しさん** · 2024/06/27(木) 23:46:01.41

未定義動作の話をしてはいないよ。
低レイヤとの間をどう取り持つかの話をしてる。

**デフォルトの名無しさん** · 2024/06/27(木) 23:53:14.85

Rustは低レイヤにも対応している
高い抽象度によるプログラミングもできる
高い抽象度のプログラミングにおいて低レイヤとの対応付けは不要であってやるべきではない

**デフォルトの名無しさん** · 2024/06/27(木) 23:56:31.92

オジーw

**デフォルトの名無しさん** · 2024/06/28(金) 00:09:40.45

>>424
その論を許すなら Rust は OS やデバイスドライバを書くのには使えない言語であってよいという立場になるが、そうじゃないよね？

**デフォルトの名無しさん** · 2024/06/28(金) 00:16:19.92

>>426
なぜなの？
Rustが抽象的にプログラミングできるのも事実であるし
OSやデバイスドライバを記述できるのも事実だよ

**デフォルトの名無しさん** · 2024/06/28(金) 00:20:27.61

>>427
低レイヤを書くための仕様が確立していなくて今はなんとなく書けているという状態を「できる」と称していいならそうだね。

**デフォルトの名無しさん** · 2024/06/28(金) 00:28:00.38

>>428
うーん
Rustに何か欠けているわけではなく
実用的に問題なく機能している状況で
言い掛かりをつけてるだけにみえるけどどうよ