X
Rust part8
■ このスレッドは過去ログ倉庫に格納されています
0628デフォルトの名無しさん
垢版 |
2020/06/01(月) 19:13:13.12ID:is4FQXAW
Rustのエラーメッセージがすごく親切なのは分かるんだけど、小手先で直そうとするとどんどん修正範囲が広くなっていって最終的に「設計が悪い」みたいな結論になっちゃう
他言語よりコーディング時に考慮すべき点が多いというか違うというか…慣れればそういうことも無くなるのかね
0629デフォルトの名無しさん
垢版 |
2020/06/01(月) 22:13:40.55ID:o7IiynR8
>>628
色々調べてる途中だけど、どうも、C言語で出来ていたことの何割かは
Rustでは禁止されていて出来ないと思う。
https://stackoverflow.com/questions/40875152/reference-to-element-in-vector
を見てもRustではarrayの1つの要素に対する参照は作れないようだし。
C/C++では当然、そのようなものへの参照やポインタが好きなように作れる。
これが出来ないことである種の組み合わせ爆発が起こりがちになり、
C/C++よりプログラムがしにくくなるだろう。
0630デフォルトの名無しさん
垢版 |
2020/06/01(月) 22:19:12.08ID:o7IiynR8
>>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()関数を作ってしまうことで対応できるかも知れない。
0634デフォルトの名無しさん
垢版 |
2020/06/01(月) 23:37:56.02ID:QCREwpDy
もうこのスレで公式すら読んでないような初心者質問するやつ無視でよくね。文章から見て同一人物っぽいし
それとそのテンプレ追加も次立てる人お願い >>999
0636デフォルトの名無しさん
垢版 |
2020/06/02(火) 10:57:29.35ID:UmuMxSnR
diesel辛いっていう人多いけど、乗り換えるならどんなクレートになんだろうね
0640デフォルトの名無しさん
垢版 |
2020/06/03(水) 02:21:24.02ID:TdRUmxlv
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.
0641デフォルトの名無しさん
垢版 |
2020/06/03(水) 02:34:58.13ID:TdRUmxlv
>>638
(C++は、C++11から大幅に改定されたので)、海外のサイトに寄れば、
C++11より前のC++からRustを学ぼうとすると大変だが、C++11以後
からだと対応関係が分かり易くて楽なのだそうだ。
unique_ptrとBox<T>が対応しているような話か。
ただ、C++の特徴であるtemplateに相当するものがまだRustにはないことが
残念だと書かれていた。
0642デフォルトの名無しさん
垢版 |
2020/06/03(水) 02:45:19.00ID:TdRUmxlv
そのサイトに寄れば、Rustで難しいのは、借用や所有の概念ではなく、
lifetimeなのだそうだ。
個人的にも、構造体のlifetimeについて説明不足を感じた。
構造体の変数のスコープと構造体のメタ部分で記述するライフタイムの
関係性がbookなどでは書かれて無いように思えた。
分からんけど。
0643デフォルトの名無しさん
垢版 |
2020/06/03(水) 02:59:40.24ID:TdRUmxlv
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.
0645デフォルトの名無しさん
垢版 |
2020/06/04(木) 12:10:41.88ID:4kMLpsX6
>>636
sqlxじゃないか
0646デフォルトの名無しさん
垢版 |
2020/06/04(木) 13:20:58.04ID:YCN7KCgu
難しいのはネストした場合のオブジェクトに対するイミュータブルかどうかとライフタイムだろう。
0647デフォルトの名無しさん
垢版 |
2020/06/04(木) 14:06:07.27ID:hCECm/yf
ライフタイムはコンパイラが親切丁寧に指摘してくれるから難しくは無いだろ
依存関係とか指摘出来ない系のエラーで詰まる事のが多い
0648デフォルトの名無しさん
垢版 |
2020/06/04(木) 19:40:21.91ID:pT22FhoL
>>647
コンパイラに指摘されれば問題ないかというと総でも無い。
プログラミングはコンパイルする前に予想可能で無いと困る。
0650デフォルトの名無しさん
垢版 |
2020/06/04(木) 20:37:04.46ID:ZbgQHKA+
>>648
難しくないってのは「学習は」難しくないって話じゃね？
いずれは自分でわかるようになるというのは当然の前提で、
まあわかるようになっても間違えることはあるのでそれを指摘してくれるのもありがたい。
0651デフォルトの名無しさん
垢版 |
2020/06/04(木) 22:06:35.88ID:x+eVDE0s
>>650
ところが、コンパイラを実際に動かさなくても、仕様書や例を見ただけで
理解できる言語も多いんだよ。
たとえば、CやBASIC,JS,Java,C#,Ruby,Python,Perlなどがそれに該当する。
C++は、03まではまあ分かったが、だんだん難しくなっていった。
もはやSTLのソースも仕様書ですらも理解できるのは一部の特殊な人に
限定されてきているかも知れない。STLの
forward()の意味を理解したりどう実装されているかをソースを見て理解できる
る人は本の一握りだろう。
move()とforward()の役割の違いも実装レベルでどれだけの人間が理解できることか。
でもRustも同じように難しくて同じようなことは起こると考えている。
0652デフォルトの名無しさん
垢版 |
2020/06/04(木) 22:49:18.31ID:VyuaeUph
そのレベルで理解できてない人がC++使うのはどういうメリットがあるのだろうか
0653デフォルトの名無しさん
垢版 |
2020/06/04(木) 22:52:33.61ID:x+eVDE0s
実はC++は、forwardやmove, templateなどの詳細を理解できてなくても高級言語的な部分だけを使ってプログラムすることは出来る。
それはRustでも同じ。
0654デフォルトの名無しさん
垢版 |
2020/06/04(木) 23:01:33.43ID:iTcUmNL8
C++は仕様が難しいというより
仕様ではないけど当然知ってるべきイディオムが
たくさんあってきつい、という感じがするな。
0655デフォルトの名無しさん
垢版 |
2020/06/05(金) 01:02:20.04ID:D80WdA6t
将棋しか知らない人が囲碁というゲームを見ると
何やってるかわからないしなんだかむずかしそうと言う
しかし実は囲碁はルールそのものはおそろしくシンプルなのだ
ところがルールだけ知っていても、囲碁は打てない
(打てるけど次に何していいかわからなくなる)
なぜなら囲碁はルールとは別に「こういう場面はこういう風に
打ち回す」というイデォムが大量にあってそれを知る必要があるからだ
C++はそれに似ている
0656デフォルトの名無しさん
垢版 |
2020/06/05(金) 01:41:15.67ID:27EcDywu
そもそもRustの仕様って難しいか？
いろんな言語から取り込んだ概念があって
C一筋とかRuby一筋みたいな人には学ぶべきことが多いとは思うけど、
特に複雑な仕様って思い当たらないんだけどな。
JSの型変換の仕様とかの方がよっぽど複雑だしワケわからんと思う。
0657デフォルトの名無しさん
垢版 |
2020/06/05(金) 09:30:38.65ID:9qGH+5zI
>>651
C が仕様や例で理解できるってどんな超人だよ。
コンパイルエラーにも実行時エラーにもならない未定義だの処理系定義だのが山もりだろうが。
初心者の書くコードで完全に仕様に沿ったコードなんて見たことないぞ。
0658デフォルトの名無しさん
垢版 |
2020/06/05(金) 09:38:30.26ID:9qGH+5zI
Haskell の入門書を一通りは読んでたから Rust の型システムは似たようなものとして理解できたなぁ。
ライフタイムもプログラムの字面に書きこそしないでも C/C++ では意識せざるを得ないし、
複雑になるとわけわからんってときは C/C++ で書いてもわけわからんようになるやつ。
0659デフォルトの名無しさん
垢版 |
2020/06/05(金) 12:01:32.43ID:lHXK6is7
きっとそういう感じでべた褒めする人が多いから、Rubyみたいに一回大人気言語になった後、急速に衰退する気がする。
Rubyも最初は良いと思われていた。
0660デフォルトの名無しさん
垢版 |
2020/06/05(金) 12:13:12.11ID:lHXK6is7
>>657
Cの仕様はシンプルで、
ポインタと明示的な型宣言と文字列比較をstrcmp()で行うという以外、
基本的な枠組みは既存の言語と変わりはなかったので理解は難しくなかった。
0661デフォルトの名無しさん
垢版 |
2020/06/05(金) 12:14:22.73ID:9qGH+5zI
Ruby は今でも十分に使われているよ。 (俺は使ってないけど。)
適切ではないところまで広がった分がそぎ落とされてちょうどいい感じに落ち着いたってだけ。
プログラミング言語の良さはスカラ値で測定できるようなものではなくて、用途による。
利用事例が減ったからといってその勢いで衰退して消えるっていうような話ではない。

Rust はまだ実際のプロダクトでどう使うのが適切なのか見極め切れていないから過剰に広まっている
というのはあると思うが、少なくとも C/C++ で問題だった部分を解決したという側面はある。
そんでそのかわりに出てきた問題ももちろんあるので両方を天秤にかけて判断する材料を集めているとこって感じ。
0663デフォルトの名無しさん
垢版 |
2020/06/05(金) 12:32:15.42ID:lHXK6is7
Google Trends によれば、検索数の増加曲線はほぼ kotlinと同じ位。
ただし、kotlinは、2017/05に急激に上がってRustと重なりあった曲線になったのに対し、Rustは、2014/01に急激に上がった後、徐々に増えている感じ。
Rustはこの1年くらいでわずかに増加速度がKotlinより上がったが、それでもKotlinの曲線とほぼ重なった状態からは脱してはいない。
0664デフォルトの名無しさん
垢版 |
2020/06/05(金) 12:34:07.49ID:lHXK6is7
>>662
匿名性掲示板では何でも言えてしまうが、実績を見れば俺がちゃんとCやC++を使いこなしていることは分かる。
ただし、C++は一度学んでも仕様が大幅に変更されるので、細かいところを理解するのは時間が掛かるようになってきている。
Cはそんなことはなかったが。
0667デフォルトの名無しさん
垢版 |
2020/06/05(金) 13:32:05.31ID:9qGH+5zI
>>664
仮に C や C++ を使いこなせているとして、
使いこなせている言語よりも使いこなせてない言語の方が難しいに決まってるじゃないの。
あなたはそうなんですねってだけ。
0668デフォルトの名無しさん
垢版 |
2020/06/05(金) 13:35:12.28ID:9qGH+5zI
>>666
符号付きなのがなんでってこと？
month や day はマイナスになる意味はないけど、
年はマイナス (紀元前) を扱いたいこともあるんじゃね。
知らんけど。
0671デフォルトの名無しさん
垢版 |
2020/06/05(金) 14:17:19.64ID:lHXK6is7
>>670
有る意味では僅かな修正であっても、基礎的な部分における修正は多大な影響を及ぼすことがある。
moveを出来るようにするために追加されたもろもろの事や、=を書かないタイプの{}
による初期化はそれに該当する。
なんでも無いようでいて、可読性を下げたり危険をもたらすことがある。
0674デフォルトの名無しさん
垢版 |
2020/06/05(金) 14:55:26.22ID:vEUs2R05
>>666
そこに書いとるやん
This assumes the proleptic Gregorian calendar, with the year 0 being 1 BCE.

つまり-1は2 BC
0676デフォルトの名無しさん
垢版 |
2020/06/05(金) 15:11:02.16ID:lHXK6is7
>>675
それは、使う側にはシンプルそうに見えるCも実は細かく見るとシンプルではないということであって、使う側目線で既に複雑なものはそれ以前の問題他。
0677デフォルトの名無しさん
垢版 |
2020/06/05(金) 15:43:45.14ID:9qGH+5zI
依存先より寿命が長くなってはいけないなんていうのは C でも当たり前のことだろ。
Rust のライフタイムはライフタイムを簡単に「表現 (したものをチェック)」する言語機能であって、
C でプログラマがやってる (はずの) ライフタイムの管理より複雑ということはない。

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

Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
複雑だとか学習難易度が高いというのは納得しかねる。
0678デフォルトの名無しさん
垢版 |
2020/06/05(金) 15:54:02.73ID:lHXK6is7
>>677
>Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
>複雑だとか学習難易度が高いというのは納得しかねる。
一つあるとすれば、難しさは、ちゃんと本も読んでいるか、ネットに書かれている情報だけに頼っているかの違いに起因している可能性。
0679デフォルトの名無しさん
垢版 |
2020/06/05(金) 21:26:05.32ID:Py5zog1r
これにて、このスレがRust関連の本の作者の巣窟であることが証明されました。
0680デフォルトの名無しさん
垢版 |
2020/06/05(金) 21:32:24.36ID:cXh0Dvtv
だいぶ前からじつは言語系のスレはほとんどソレなんだな
宣伝してるやつは気付かれれないと思ってるだろうけど
0681デフォルトの名無しさん
垢版 |
2020/06/05(金) 21:49:15.38ID:Py5zog1r
>>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％）、
0682デフォルトの名無しさん
垢版 |
2020/06/05(金) 22:00:56.76ID:Py5zog1r
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 うるさく注文を求める.)
・切符をプレミア付きで売る, ダフ屋をやる.
・うるさく勧める.
・ほめちぎる.
0683デフォルトの名無しさん
垢版 |
2020/06/05(金) 22:04:18.63ID:Py5zog1r
誤:安全性と正確性のために言語が非常にうるさく押し付けてくる特長
誤:安全性と正確性のために言語が非常にうるさく押し付けてくる機構(機能)
0685デフォルトの名無しさん
垢版 |
2020/06/06(土) 04:00:23.67ID:Vvt5YBJp
この言語廃れてきそうな気がした。
だってみんなが触るって未来が想像できないもん
0687デフォルトの名無しさん
垢版 |
2020/06/06(土) 05:29:47.06ID:i8tpraSw
Rustを使ったことはないけどC++は既存の資源で堅実に作るのに対して
Rustは一人のスーパープログラマが複雑高度なライブラリやモジュールを一点突破で書くのに使われそうなイメージ
0688デフォルトの名無しさん
垢版 |
2020/06/06(土) 09:51:25.89ID:9F/1KVDa
まあScalaと同じ道を辿るだろうね
あっちはビッグウェア系でそれなりに採用されてたから被害が甚大だったけど、
Rustに関してはそういうビジネス的な得意分野は今のところ無いのが救いか
0689デフォルトの名無しさん
垢版 |
2020/06/06(土) 15:58:34.19ID:HBMrgMqa
>>687
ところがスーパープログラマは、C++でもメモリー関連のバグで詰んで挫折したりすることはないんだな、これが。
0690デフォルトの名無しさん
垢版 |
2020/06/06(土) 17:06:05.01ID:58RXXUUu
>>687
Rust の偉大さのひとつには crates.io の存在がある。
資源の利用という意味じゃ Rust はかなり積極的だぞ。
0691デフォルトの名無しさん
垢版 |
2020/06/06(土) 17:17:15.77ID:P/b6XOwm
C++は標準のライブラリリポジトリと標準のビルドツールがあればなぁ、と思う。
野良のは乱立してるけど、結局ほしいライブラリはなかったりするし…。
0693デフォルトの名無しさん
垢版 |
2020/06/06(土) 18:11:03.05ID:58RXXUUu
>>691
各環境のパッケージマネージャに乗っかってることが多いからある意味では一等の地位ともいえる。
メジャーなものは apt-get とか pacman とかで一発で入るだろ。
0694デフォルトの名無しさん
垢版 |
2020/06/06(土) 18:38:18.22ID:Vvt5YBJp
>>690
crates.ioがダメダメだから代替のサイトあるのってご存知でない？
0697デフォルトの名無しさん
垢版 |
2020/06/06(土) 19:37:13.44ID:P/b6XOwm
>>693
結局それってディストリビューション依存だからなぁ。
バージョンだって固定できないし、OSS拾ってきてコンパイルが通るようにするだけで試行錯誤が必要。

>>696
いや、頑張って環境構築すればなんとかなるのはその通りだけど、
別のソフトだとまた別の環境構築が必要になって辛いのです。
0698デフォルトの名無しさん
垢版 |
2020/06/06(土) 21:37:30.50ID:nFHIDUIo
Rustでプロキシーサーバー実装してみようと思ったんだけどTCPStreamとreqwest::headerの連携がうまくいかない
0699696
垢版 |
2020/06/06(土) 22:21:08.03ID:7YMZq5d4
漏れは、日本人が作った、バージョンマネージャーのanyenv で、
rbenv, nodenv を使って、ruby 2.6.6, node 12.16.2 を入れた

環境構築が、各言語でバラバラになるのは面倒なので、
anyenv・asdf などを使えば？
0701デフォルトの名無しさん
垢版 |
2020/06/07(日) 00:03:49.64ID:uvQLWD0s
こんな書き込みを見つけた：
loop {
// 1. you finally understood lifetimes
// 2. you get compiler lifetime /borrow complaints
// 3. you feel stupid for taking hours to fix <5 LoC
}
0702デフォルトの名無しさん
垢版 |
2020/06/07(日) 00:19:04.85ID:uvQLWD0s
ループ {
// 1. あなたはついに lifetime を理解した。
// 2. あなたはコンパイラに lifetimeやborrow の苦情を複数個言われる。
// 3. 5行未満のコードを直すのに何時間もとられることにあなたは馬鹿馬鹿しさを感じる。
}
0704デフォルトの名無しさん
垢版 |
2020/06/07(日) 17:57:12.72ID:WIpxuhAg
Rsutって、早い話が、CやC++に、NULLバグ等々が発生しないようにするための補助機能がついた言語ってこと？
0705デフォルトの名無しさん
垢版 |
2020/06/07(日) 18:44:36.11ID:r/6oC92T
そうだね〜、で、俺様はNullチェックは忘れないしダングリングポインタなんて組み込まないのでC/C++で良いや
という俺様スパハカがゴミグラムを生み出してきたのでRustは必須
0707デフォルトの名無しさん
垢版 |
2020/06/07(日) 19:46:37.12ID:WIpxuhAg
>>706
いや、言語誕生の思想を考えただけです。
言語誕生の思想をきちんと抑えないと、メリットとデメリットを正答に評価出来ないから
0709デフォルトの名無しさん
垢版 |
2020/06/07(日) 22:51:27.97ID:fhJ4vSsJ
Hindley-Milner 型推論を元にしているから考え方は ML 系統からの影響は大きいと思う。
0710デフォルトの名無しさん
垢版 |
2020/06/08(月) 02:06:14.90ID:jeqh3aBJ
C++の地獄をML（とアフィン型）の知見で楽にしようとした言語

Cの遺産を引き摺ったが故に煩雑だった前者の記法を捨てて後者のいいとこを貰ってきたので、記法が後者に似てるように見えはするけど、やってる事はそう大きく変わってはいない
0711デフォルトの名無しさん
垢版 |
2020/06/08(月) 10:53:34.76ID:KAmnJXdU
「C++ のメンバ関数の実態は this を暗黙に渡しているだけ」ってのを露骨にしたのも Rust の面白い部分だよね。
関数的な意味論を用いながらも構文糖としてのメソッド記法も用意することでオブジェクト指向的な表現が出来る。
0712デフォルトの名無しさん
垢版 |
2020/06/08(月) 13:11:59.47ID:LDYBA2kC
RustはC++ではゼロコストで出来ていたものが、出来なくなってしまっていることが多い。
0715デフォルトの名無しさん
垢版 |
2020/06/08(月) 13:28:01.70ID:KAmnJXdU
言語として純粋関数型に分類される Haskell ですら
オブジェクト指向のスタイルで構築されたライブラリは有るから……。
(そのためのフレームワークである lens はまあまあ人気。)

言語仕様での理屈がどうあれ最終的には使い方次第。
0718デフォルトの名無しさん
垢版 |
2020/06/08(月) 13:53:57.25ID:LDYBA2kC
RustではpChildがHeapにとられている時、次のようなループすら書けない。
CPerson *pChild=pPerson->pChild;
while(pChild != NULL) {
(pChildに対する処理);
pChild=pChild->pNext;
}
0719デフォルトの名無しさん
垢版 |
2020/06/08(月) 14:30:52.23ID:KAmnJXdU
>>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 に対する処理
}
}
0720デフォルトの名無しさん
垢版 |
2020/06/08(月) 14:39:32.30ID:LDYBA2kC
>>719
Heap領域にある構造体の中に、さらにHeap領域にあるデータへの
参照を持つためにBox型のメンバが有る場合、後者のBoxは、unique_ptrなので
ローカル変数にmoveすることができないためコンパイルエラーになる。
なので、参照カウント方式のRcを使う必要がある。
0721デフォルトの名無しさん
垢版 |
2020/06/08(月) 14:44:31.30ID:LDYBA2kC
>>719 の場合だと personがスタック領域にあるが、もしそれがHeap領域に
あったとすると、
let childs = person.childs;
とするとエラーになるはずだ。
0724デフォルトの名無しさん
垢版 |
2020/06/08(月) 14:56:15.14ID:LDYBA2kC
そもそも、
struct Person {
　pub child: Box<[Person]>
}
がおかしくて、正しくは、
struct Person {
　pub child: Box<Person>
　pub next: Box<Person>
}
だ。
0726デフォルトの名無しさん
垢版 |
2020/06/08(月) 14:58:43.87ID:KAmnJXdU
後付けやめろよ。
C++ のどういうコードを Rust でどう書けて欲しい (そして実際にはどういうエラーになる) のかちゃんと書け。



いや、書くな。 (どうせ見当違いなので。)
0727デフォルトの名無しさん
垢版 |
2020/06/08(月) 15:03:12.27ID:LDYBA2kC
>>725
#[derive(Debug)]
struct TAaa {
　　x: Box<i32>,
　　y: i32
}
fn main() {
　　let mut vec:Vec<TAaa> = Vec::new();
　　vec.push( TAaa {
　　　　x : Box::new(333),
　　　　y : 444
　　} );
　　let　　 x　 = vec[0].x;　// error[E0507]: cannot move out of index of `std::vec::Vec<TAaa>`
　　println!("{:#?}", x);
}
↑のように vec をHeapに確保した場合、エラーになる。
ところが、stackに確保した場合はエラーにならない。
実験済み。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況