Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/06/01(月) 18:07:45.72

>>623
とりあえずThe Bookの所有権のところを一通り読んでから質問してください
その質問の答えも試し方も全部書いてますので
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

**デフォルトの名無しさん** · 2020/06/01(月) 18:23:13.55

>>625
そこは一時間ほど前に読みましたが、>>623のことは分からないので質問しました。

**デフォルトの名無しさん** · 2020/06/01(月) 18:36:04.96

>>623
お前が正しく理解してるかどうか知らんけど個別の事例として言えば Yes だ。
所有権は移動して、元の変数はもう使えない。

だけどそんなことはやってみたらわかりやすいエラーメッセージが出るじゃないの。

fn main() {
let a = 20;
let b1 = Box::new(a);
let b2 = b1;
println!("{}", b1);
}

みたいなことを書いたら

error[E0382]: use of moved value: `b1`

って出るし、どこでムーブ (所有権の移管) 済みかまでも表示してくれる。
Rust のエラーメッセージはめっちゃ親切なんだから、
「この場合はどうですか」なんて質問する間があったらやってみりゃいいんだよ。

**デフォルトの名無しさん** · 2020/06/01(月) 19:13:13.12

Rustのエラーメッセージがすごく親切なのは分かるんだけど、小手先で直そうとするとどんどん修正範囲が広くなっていって最終的に「設計が悪い」みたいな結論になっちゃう
他言語よりコーディング時に考慮すべき点が多いというか違うというか…慣れればそういうことも無くなるのかね

**デフォルトの名無しさん** · 2020/06/01(月) 22:13:40.55

>>628
色々調べてる途中だけど、どうも、C言語で出来ていたことの何割かは
Rustでは禁止されていて出来ないと思う。
https://stackoverflow.com/questions/40875152/reference-to-element-in-vector
を見てもRustではarrayの1つの要素に対する参照は作れないようだし。
C/C++では当然、そのようなものへの参照やポインタが好きなように作れる。
これが出来ないことである種の組み合わせ爆発が起こりがちになり、
C/C++よりプログラムがしにくくなるだろう。

**デフォルトの名無しさん** · 2020/06/01(月) 22:19:12.08

>>729
例えばの話、C言語だと1つのCPerson型のデータをファイルに出力する関数を
void write(FILE *fp, CPerson const *person);
のように作りさえすれば、
CPerson persons[100];
for (int idx=0; idx<100; idx++ ) {
write(fp, &persons[idx]);
}
でCPersonの配列にも対応できてしまう。
このようなことがRustではできなくなるはず。
無理やり観が有るが、CPersonのメンバ関数としてwrite()関数を作ってしまうことで対応できるかも知れない。

**デフォルトの名無しさん** · 2020/06/01(月) 22:50:56.49

rustはまだ勉強中だけど、630がアホなこと言ってるのは俺でもわかる。

**デフォルトの名無しさん** · 2020/06/01(月) 22:53:23.54

ID:T0vrM+QLやID:bf1cRh+Bと同一人物だね

**デフォルトの名無しさん** · 2020/06/01(月) 22:54:16.92

荒らしの相手するやつも荒らし

**デフォルトの名無しさん** · 2020/06/01(月) 23:37:56.02

もうこのスレで公式すら読んでないような初心者質問するやつ無視でよくね。文章から見て同一人物っぽいし
それとそのテンプレ追加も次立てる人お願い >>999

**デフォルトの名無しさん** · 2020/06/02(火) 10:45:35.24

>>629
https://doc.rust-lang.org/1.9.0/book/structs.html
によれば、構造体メンバのアドレスを参照型変数に代入することができるらしい。

**デフォルトの名無しさん** · 2020/06/02(火) 10:57:29.35

diesel辛いっていう人多いけど、乗り換えるならどんなクレートになんだろうね

**デフォルトの名無しさん** · 2020/06/02(火) 11:19:09.02

>>627 >>634
読んでも書いてない。

**デフォルトの名無しさん** · 2020/06/02(火) 19:18:24.00

結局c++やらんとrustを理解するなんて無理なんだよ

**デフォルトの名無しさん** · 2020/06/02(火) 20:16:57.29

>>638
こないだ C++ スレで >>623 の ID は見たぞ。

**デフォルトの名無しさん** · 2020/06/03(水) 02:21:24.02

https://users.rust-lang.org/t/isnt-rust-too-difficult-to-be-widely-adopted/6173/37
↑のサイトに寄れば、Blandy & Orendorff の Programming Rust の
評判が良いらしい：
I’m also new to Rust and have found the “Programming Rust” book by Blandy & Orendorff to be very helpful.
Especially the chapters on ownership and references.
It is an expensive book though.

また、Box<T>, Rc<T>, RefCell<T>は必要ないという見方があるらしい。
最初から用意されているコンテナを使えば十分という意味のようだ :

I also didn’t need Box, Rc, RefCell, or friends.

**デフォルトの名無しさん** · 2020/06/03(水) 02:34:58.13

>>638
(C++は、C++11から大幅に改定されたので)、海外のサイトに寄れば、
C++11より前のC++からRustを学ぼうとすると大変だが、C++11以後
からだと対応関係が分かり易くて楽なのだそうだ。
unique_ptrとBox<T>が対応しているような話か。
ただ、C++の特徴であるtemplateに相当するものがまだRustにはないことが
残念だと書かれていた。

**デフォルトの名無しさん** · 2020/06/03(水) 02:45:19.00

そのサイトに寄れば、Rustで難しいのは、借用や所有の概念ではなく、
lifetimeなのだそうだ。
個人的にも、構造体のlifetimeについて説明不足を感じた。
構造体の変数のスコープと構造体のメタ部分で記述するライフタイムの
関係性がbookなどでは書かれて無いように思えた。
分からんけど。

**デフォルトの名無しさん** · 2020/06/03(水) 02:59:40.24

2018/04 の時点でも、まだ、lifetimeに関する資料が足りてないと感じている人がいたそうだ。
Can we maybe have a book or booklet exclusively covering lifetimes?
I don’t think the first level of instruction material on lifetimes which is found
in the rust book and others which talks about the syntax and the aliasing rules and elision is enough.
It leads to an incomplete model which only frustrates when you discover its incompleteness.
Rust nominoc does go further. For example it shows with detailed examples how lifetimes start with
a let binding and how they interact with other lifetimes in the same scope.
This is fundamental stuff and absolutely essential to understanding.
But there are still aspects not covered there.
For instance I realized that lifetimes can be shrunk as needed by the compiler only from this
forum (thanks @vitalyd) which invalidated my previous model.
And I’m sure there are other aspects I don’t know about.
I think we just need one place where one can learn everything about lifetimes and be done with it.

**デフォルトの名無しさん** · 2020/06/04(木) 10:31:48.72

>>641
グロ

**デフォルトの名無しさん** · 2020/06/04(木) 12:10:41.88

>>636
sqlxじゃないか

**デフォルトの名無しさん** · 2020/06/04(木) 13:20:58.04

難しいのはネストした場合のオブジェクトに対するイミュータブルかどうかとライフタイムだろう。

**デフォルトの名無しさん** · 2020/06/04(木) 14:06:07.27

ライフタイムはコンパイラが親切丁寧に指摘してくれるから難しくは無いだろ
依存関係とか指摘出来ない系のエラーで詰まる事のが多い

**デフォルトの名無しさん** · 2020/06/04(木) 19:40:21.91

>>647
コンパイラに指摘されれば問題ないかというと総でも無い。
プログラミングはコンパイルする前に予想可能で無いと困る。

**デフォルトの名無しさん** · 2020/06/04(木) 20:10:09.15

競馬かな？

**デフォルトの名無しさん** · 2020/06/04(木) 20:37:04.46

>>648
難しくないってのは「学習は」難しくないって話じゃね？
いずれは自分でわかるようになるというのは当然の前提で、
まあわかるようになっても間違えることはあるのでそれを指摘してくれるのもありがたい。

**デフォルトの名無しさん** · 2020/06/04(木) 22:06:35.88

>>650
ところが、コンパイラを実際に動かさなくても、仕様書や例を見ただけで
理解できる言語も多いんだよ。
たとえば、CやBASIC,JS,Java,C#,Ruby,Python,Perlなどがそれに該当する。
C++は、03まではまあ分かったが、だんだん難しくなっていった。
もはやSTLのソースも仕様書ですらも理解できるのは一部の特殊な人に
限定されてきているかも知れない。STLの
forward()の意味を理解したりどう実装されているかをソースを見て理解できる
る人は本の一握りだろう。
move()とforward()の役割の違いも実装レベルでどれだけの人間が理解できることか。
でもRustも同じように難しくて同じようなことは起こると考えている。

**デフォルトの名無しさん** · 2020/06/04(木) 22:49:18.31

そのレベルで理解できてない人がC++使うのはどういうメリットがあるのだろうか

**デフォルトの名無しさん** · 2020/06/04(木) 22:52:33.61

実はC++は、forwardやmove, templateなどの詳細を理解できてなくても高級言語的な部分だけを使ってプログラムすることは出来る。
それはRustでも同じ。

**デフォルトの名無しさん** · 2020/06/04(木) 23:01:33.43

C++は仕様が難しいというより
仕様ではないけど当然知ってるべきイディオムが
たくさんあってきつい、という感じがするな。

**デフォルトの名無しさん** · 2020/06/05(金) 01:02:20.04

将棋しか知らない人が囲碁というゲームを見ると
何やってるかわからないしなんだかむずかしそうと言う
しかし実は囲碁はルールそのものはおそろしくシンプルなのだ
ところがルールだけ知っていても、囲碁は打てない
(打てるけど次に何していいかわからなくなる)
なぜなら囲碁はルールとは別に「こういう場面はこういう風に
打ち回す」というイデォムが大量にあってそれを知る必要があるからだ
C++はそれに似ている

**デフォルトの名無しさん** · 2020/06/05(金) 01:41:15.67

そもそもRustの仕様って難しいか？
いろんな言語から取り込んだ概念があって
C一筋とかRuby一筋みたいな人には学ぶべきことが多いとは思うけど、
特に複雑な仕様って思い当たらないんだけどな。
JSの型変換の仕様とかの方がよっぽど複雑だしワケわからんと思う。

**デフォルトの名無しさん** · 2020/06/05(金) 09:30:38.65

>>651
C が仕様や例で理解できるってどんな超人だよ。
コンパイルエラーにも実行時エラーにもならない未定義だの処理系定義だのが山もりだろうが。
初心者の書くコードで完全に仕様に沿ったコードなんて見たことないぞ。

**デフォルトの名無しさん** · 2020/06/05(金) 09:38:30.26

Haskell の入門書を一通りは読んでたから Rust の型システムは似たようなものとして理解できたなぁ。
ライフタイムもプログラムの字面に書きこそしないでも C/C++ では意識せざるを得ないし、
複雑になるとわけわからんってときは C/C++ で書いてもわけわからんようになるやつ。

**デフォルトの名無しさん** · 2020/06/05(金) 12:01:32.43

きっとそういう感じでべた褒めする人が多いから、Rubyみたいに一回大人気言語になった後、急速に衰退する気がする。
Rubyも最初は良いと思われていた。

**デフォルトの名無しさん** · 2020/06/05(金) 12:13:12.11

>>657
Cの仕様はシンプルで、
ポインタと明示的な型宣言と文字列比較をstrcmp()で行うという以外、
基本的な枠組みは既存の言語と変わりはなかったので理解は難しくなかった。

**デフォルトの名無しさん** · 2020/06/05(金) 12:14:22.73

Ruby は今でも十分に使われているよ。 (俺は使ってないけど。)
適切ではないところまで広がった分がそぎ落とされてちょうどいい感じに落ち着いたってだけ。
プログラミング言語の良さはスカラ値で測定できるようなものではなくて、用途による。
利用事例が減ったからといってその勢いで衰退して消えるっていうような話ではない。

Rust はまだ実際のプロダクトでどう使うのが適切なのか見極め切れていないから過剰に広まっている
というのはあると思うが、少なくとも C/C++ で問題だった部分を解決したという側面はある。
そんでそのかわりに出てきた問題ももちろんあるので両方を天秤にかけて判断する材料を集めているとこって感じ。

**デフォルトの名無しさん** · 2020/06/05(金) 12:15:46.52

>>660
うん。 C がシンプルで理解しやすいと思い込みやすい言語なのは俺も知ってる。

**デフォルトの名無しさん** · 2020/06/05(金) 12:32:15.42

Google Trends によれば、検索数の増加曲線はほぼ kotlinと同じ位。
ただし、kotlinは、2017/05に急激に上がってRustと重なりあった曲線になったのに対し、Rustは、2014/01に急激に上がった後、徐々に増えている感じ。
Rustはこの1年くらいでわずかに増加速度がKotlinより上がったが、それでもKotlinの曲線とほぼ重なった状態からは脱してはいない。

**デフォルトの名無しさん** · 2020/06/05(金) 12:34:07.49

>>662
匿名性掲示板では何でも言えてしまうが、実績を見れば俺がちゃんとCやC++を使いこなしていることは分かる。
ただし、C++は一度学んでも仕様が大幅に変更されるので、細かいところを理解するのは時間が掛かるようになってきている。
Cはそんなことはなかったが。

**デフォルトの名無しさん** · 2020/06/05(金) 12:58:47.64

もしかして伝説のスーパーハカーさんですか！？

**デフォルトの名無しさん** · 2020/06/05(金) 13:22:50.72

chronoつかってるんだけど、このyearってなんでi32なの？

https://docs.rs/chrono/0.4.11/chrono/offset/trait.TimeZone.html#method.ymd
fn ymd(&self, year: i32, month: u32, day: u32) -> Date<Self>

**デフォルトの名無しさん** · 2020/06/05(金) 13:32:05.31

>>664
仮に C や C++ を使いこなせているとして、
使いこなせている言語よりも使いこなせてない言語の方が難しいに決まってるじゃないの。
あなたはそうなんですねってだけ。

**デフォルトの名無しさん** · 2020/06/05(金) 13:35:12.28

>>666
符号付きなのがなんでってこと？
month や day はマイナスになる意味はないけど、
年はマイナス (紀元前) を扱いたいこともあるんじゃね。
知らんけど。

**デフォルトの名無しさん** · 2020/06/05(金) 13:44:02.67

合ってんじゃね？
知らんけど。

**デフォルトの名無しさん** · 2020/06/05(金) 14:06:52.05

C++の仕様が大幅に変更されたというのは
なんのことだ？

**デフォルトの名無しさん** · 2020/06/05(金) 14:17:19.64

>>670
有る意味では僅かな修正であっても、基礎的な部分における修正は多大な影響を及ぼすことがある。
moveを出来るようにするために追加されたもろもろの事や、=を書かないタイプの{}
による初期化はそれに該当する。
なんでも無いようでいて、可読性を下げたり危険をもたらすことがある。

**デフォルトの名無しさん** · 2020/06/05(金) 14:41:22.49

>>662
Cほどシンプルな言語もないだろ。それと簡単に使いこなせるかは別問題。

**デフォルトの名無しさん** · 2020/06/05(金) 14:48:48.89

>>671
それ仕様の変更なの？

**デフォルトの名無しさん** · 2020/06/05(金) 14:55:26.22

>>666
そこに書いとるやん
This assumes the proleptic Gregorian calendar, with the year 0 being 1 BCE.

つまり-1は2 BC

**デフォルトの名無しさん** · 2020/06/05(金) 15:08:35.22

Cのプリプロセッサやパーサーを書くと全然シンプルじゃないことが分かる

**デフォルトの名無しさん** · 2020/06/05(金) 15:11:02.16

>>675
それは、使う側にはシンプルそうに見えるCも実は細かく見るとシンプルではないということであって、使う側目線で既に複雑なものはそれ以前の問題他。

**デフォルトの名無しさん** · 2020/06/05(金) 15:43:45.14

依存先より寿命が長くなってはいけないなんていうのは C でも当たり前のことだろ。
Rust のライフタイムはライフタイムを簡単に「表現 (したものをチェック)」する言語機能であって、
C でプログラマがやってる (はずの) ライフタイムの管理より複雑ということはない。

Rust なら処理系がチェックしてくれることを
C ではプログラマがやってたんだぞ。
C で出来てたことが Rust ではやれないってのは言語のせいか？

Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
複雑だとか学習難易度が高いというのは納得しかねる。

**デフォルトの名無しさん** · 2020/06/05(金) 15:54:02.73

>>677
>Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
>複雑だとか学習難易度が高いというのは納得しかねる。
一つあるとすれば、難しさは、ちゃんと本も読んでいるか、ネットに書かれている情報だけに頼っているかの違いに起因している可能性。

**デフォルトの名無しさん** · 2020/06/05(金) 21:26:05.32

これにて、このスレがRust関連の本の作者の巣窟であることが証明されました。

**デフォルトの名無しさん** · 2020/06/05(金) 21:32:24.36

だいぶ前からじつは言語系のスレはほとんどソレなんだな
宣伝してるやつは気付かれれないと思ってるだろうけど

**デフォルトの名無しさん** · 2020/06/05(金) 21:49:15.38

>>618
2018/11/28の時点で、

https://www.infoworld.com/article/3324488/rust-language-is-too-hard-to-learn-and-use-says-user-survey.html
ユーザーの調査によると、Rust言語は習得も使用も難しい
Rustユーザーの調査では、メモリの安全性と正確性のためにこの言語の非常に宣伝されている機能に困難と不満を感じています
Rust言語チームが実施したRustユーザーコミュニティの新しい調査では、言語とその使用への関心が高まっていますが、プロジェクトが利点として宣伝しているいくつかのRust機能に対するユーザーの不満も示されています。
Rustの習得が難しいのはなぜですか？ユーザーは、Rustの最も特徴的な2つの機能（寿命と所有権/借用システム）は、「トリッキー」、「非常に難しい」、または「まだ得られない」ものであると報告しました。
その他の質問は、Rustを続行するための課題を中心に展開されました。Rustの使用をやめた人の約半分は、わずか1か月後にそうしました。Rustを使用していない最も一般的な理由は、「威圧的すぎる、習得が難しい、または複雑すぎる」（25％）、

**デフォルトの名無しさん** · 2020/06/05(金) 22:00:56.76

Rust言語は、学んだり使ったりするのが難しすぎるということが、ユーザーに対する調査で分かった。
--Rustユーザーに対する調査では、安全性と正確性のために言語が非常にうるさく押し付けてくる特長により困難と欲求不満を感じていることが分かった。

Rust language is too hard to learn and use, says user survey
A survey of Rust users finds difficulty and frustration with the language’s highly touted features for memory safety and correctness.

tout = 押し売りする, うるさく勧誘する, 客引きする
(tout for custom うるさく注文を求める.)
・切符をプレミア付きで売る, ダフ屋をやる.
・うるさく勧める.
・ほめちぎる.

**デフォルトの名無しさん** · 2020/06/05(金) 22:04:18.63

誤:安全性と正確性のために言語が非常にうるさく押し付けてくる特長
誤:安全性と正確性のために言語が非常にうるさく押し付けてくる機構(機能)

**デフォルトの名無しさん** · 2020/06/05(金) 23:15:24.59

>>674
へー。西暦にゼロ年っていうのは無いのか。

**デフォルトの名無しさん** · 2020/06/06(土) 04:00:23.67

この言語廃れてきそうな気がした。
だってみんなが触るって未来が想像できないもん

**デフォルトの名無しさん** · 2020/06/06(土) 04:10:18.67

みんなが触る言語なんて世の中に存在するか？

**デフォルトの名無しさん** · 2020/06/06(土) 05:29:47.06

Rustを使ったことはないけどC++は既存の資源で堅実に作るのに対して
Rustは一人のスーパープログラマが複雑高度なライブラリやモジュールを一点突破で書くのに使われそうなイメージ

**デフォルトの名無しさん** · 2020/06/06(土) 09:51:25.89

まあScalaと同じ道を辿るだろうね
あっちはビッグウェア系でそれなりに採用されてたから被害が甚大だったけど、
Rustに関してはそういうビジネス的な得意分野は今のところ無いのが救いか

**デフォルトの名無しさん** · 2020/06/06(土) 15:58:34.19

>>687
ところがスーパープログラマは、C++でもメモリー関連のバグで詰んで挫折したりすることはないんだな、これが。

**デフォルトの名無しさん** · 2020/06/06(土) 17:06:05.01

>>687
Rust の偉大さのひとつには crates.io の存在がある。
資源の利用という意味じゃ Rust はかなり積極的だぞ。

**デフォルトの名無しさん** · 2020/06/06(土) 17:17:15.77

C++は標準のライブラリリポジトリと標準のビルドツールがあればなぁ、と思う。
野良のは乱立してるけど、結局ほしいライブラリはなかったりするし…。

**デフォルトの名無しさん** · 2020/06/06(土) 17:37:45.92

>>688
MicrosoftもAppleも使っていくのに爆死したら
IT業界壊滅じゃね

**デフォルトの名無しさん** · 2020/06/06(土) 18:11:03.05

>>691
各環境のパッケージマネージャに乗っかってることが多いからある意味では一等の地位ともいえる。
メジャーなものは apt-get とか pacman とかで一発で入るだろ。

**デフォルトの名無しさん** · 2020/06/06(土) 18:38:18.22

>>690
crates.ioがダメダメだから代替のサイトあるのってご存知でない？

**デフォルトの名無しさん** · 2020/06/06(土) 18:42:21.81

Webサイトの話をしてるわけじゃないだろ

**デフォルトの名無しさん** · 2020/06/06(土) 18:56:38.50

>>691
漏れは、Windows 10, WSL, Ubuntu 18.04 で、
anyenv(rbenv)で、Ruby をコンパイルするのに、build-essential を使っているけど

build-essential には、
gcc(GNU C compiler), g++(GNU C++ compiler), libc6-dev(GNU C Library), make などが入っています

パッケージ: build-essential
https://packages.ubuntu.com/ja/bionic/build-essential

**デフォルトの名無しさん** · 2020/06/06(土) 19:37:13.44

>>693
結局それってディストリビューション依存だからなぁ。
バージョンだって固定できないし、OSS拾ってきてコンパイルが通るようにするだけで試行錯誤が必要。

>>696
いや、頑張って環境構築すればなんとかなるのはその通りだけど、
別のソフトだとまた別の環境構築が必要になって辛いのです。

**デフォルトの名無しさん** · 2020/06/06(土) 21:37:30.50

Rustでプロキシーサーバー実装してみようと思ったんだけどTCPStreamとreqwest::headerの連携がうまくいかない

**696** · 2020/06/06(土) 22:21:08.03

漏れは、日本人が作った、バージョンマネージャーのanyenv で、
rbenv, nodenv を使って、ruby 2.6.6, node 12.16.2 を入れた

環境構築が、各言語でバラバラになるのは面倒なので、
anyenv・asdf などを使えば？

**デフォルトの名無しさん** · 2020/06/06(土) 23:04:13.04

hyperのサンプルに答えがありました

**デフォルトの名無しさん** · 2020/06/07(日) 00:03:49.64

こんな書き込みを見つけた：
loop {
// 1. you finally understood lifetimes
// 2. you get compiler lifetime /borrow complaints
// 3. you feel stupid for taking hours to fix <5 LoC
}

**デフォルトの名無しさん** · 2020/06/07(日) 00:19:04.85

ループ {
// 1. あなたはついに lifetime を理解した。
// 2. あなたはコンパイラに lifetimeやborrow の苦情を複数個言われる。
// 3. 5行未満のコードを直すのに何時間もとられることにあなたは馬鹿馬鹿しさを感じる。
}

**デフォルトの名無しさん** · 2020/06/07(日) 11:58:43.41

コンパイラに緊縛されて未定義動作を踏まないという快感を得るプレイ

**デフォルトの名無しさん** · 2020/06/07(日) 17:57:12.72

Rsutって、早い話が、CやC++に、NULLバグ等々が発生しないようにするための補助機能がついた言語ってこと？

**デフォルトの名無しさん** · 2020/06/07(日) 18:44:36.11

そうだね～、で、俺様はNullチェックは忘れないしダングリングポインタなんて組み込まないのでC/C++で良いや
という俺様スパハカがゴミグラムを生み出してきたのでRustは必須

**デフォルトの名無しさん** · 2020/06/07(日) 18:48:57.09

>>704
書き方がC/C++の文化とはかけ離れているように感じるが。

**デフォルトの名無しさん** · 2020/06/07(日) 19:46:37.12

>>706
いや、言語誕生の思想を考えただけです。
言語誕生の思想をきちんと抑えないと、メリットとデメリットを正答に評価出来ないから

**デフォルトの名無しさん** · 2020/06/07(日) 19:59:02.69

どっちかというと「関数型C++」な印象

**デフォルトの名無しさん** · 2020/06/07(日) 22:51:27.97

Hindley-Milner 型推論を元にしているから考え方は ML 系統からの影響は大きいと思う。

**デフォルトの名無しさん** · 2020/06/08(月) 02:06:14.90

C++の地獄をML（とアフィン型）の知見で楽にしようとした言語

Cの遺産を引き摺ったが故に煩雑だった前者の記法を捨てて後者のいいとこを貰ってきたので、記法が後者に似てるように見えはするけど、やってる事はそう大きく変わってはいない

**デフォルトの名無しさん** · 2020/06/08(月) 10:53:34.76

「C++ のメンバ関数の実態は this を暗黙に渡しているだけ」ってのを露骨にしたのも Rust の面白い部分だよね。
関数的な意味論を用いながらも構文糖としてのメソッド記法も用意することでオブジェクト指向的な表現が出来る。

**デフォルトの名無しさん** · 2020/06/08(月) 13:11:59.47

RustはC++ではゼロコストで出来ていたものが、出来なくなってしまっていることが多い。

**デフォルトの名無しさん** · 2020/06/08(月) 13:14:25.82

>>712
具体的には？

**デフォルトの名無しさん** · 2020/06/08(月) 13:19:16.88

関数的な意味論ねぇ
表層的に一部それっぽいってだけでは？

**デフォルトの名無しさん** · 2020/06/08(月) 13:28:01.70

言語として純粋関数型に分類される Haskell ですら
オブジェクト指向のスタイルで構築されたライブラリは有るから……。
(そのためのフレームワークである lens はまあまあ人気。)

言語仕様での理屈がどうあれ最終的には使い方次第。

**デフォルトの名無しさん** · 2020/06/08(月) 13:36:41.82

>>713
言うと改善されるので言わない。

**デフォルトの名無しさん** · 2020/06/08(月) 13:46:18.64

memmove()すらunsafeなしではかけないし。

**デフォルトの名無しさん** · 2020/06/08(月) 13:53:57.25

RustではpChildがHeapにとられている時、次のようなループすら書けない。
CPerson *pChild=pPerson->pChild;
while(pChild != NULL) {
(pChildに対する処理);
pChild=pChild->pNext;
}

**デフォルトの名無しさん** · 2020/06/08(月) 14:30:52.23

>>718
こういう感じのこと？

#[derive(Default)]
struct Person {
pub childs: Box<[Person]>
}

fn main() {
let person : Person = Default::default();
let childs = person.childs;
for ref child in childs.iter() {
// child に対する処理
}
}

**デフォルトの名無しさん** · 2020/06/08(月) 14:39:32.30

>>719
Heap領域にある構造体の中に、さらにHeap領域にあるデータへの
参照を持つためにBox型のメンバが有る場合、後者のBoxは、unique_ptrなので
ローカル変数にmoveすることができないためコンパイルエラーになる。
なので、参照カウント方式のRcを使う必要がある。

**デフォルトの名無しさん** · 2020/06/08(月) 14:44:31.30

>>719 の場合だと personがスタック領域にあるが、もしそれがHeap領域に
あったとすると、
let childs = person.childs;
とするとエラーになるはずだ。

**デフォルトの名無しさん** · 2020/06/08(月) 14:48:41.29

>>721
ならない。

　　　　　　(完)

**デフォルトの名無しさん** · 2020/06/08(月) 14:53:38.92

チュートリアルも読まない難癖おじいちゃんの相手すんなし

**デフォルトの名無しさん** · 2020/06/08(月) 14:56:15.14

そもそも、
struct Person {
　pub child: Box<[Person]>
}
がおかしくて、正しくは、
struct Person {
　pub child: Box<Person>
　pub next: Box<Person>
}
だ。

**デフォルトの名無しさん** · 2020/06/08(月) 14:56:44.39

>>722
全く同じではないが、こっちの環境ではなったがな。