Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

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

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

日本語の情報
https://rust-jp.rs/

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

**デフォルトの名無しさん** · 2021/04/21(水) 17:58:04.79

>>201
歴史があってどう実装すべきかという指針ができあがっているCと
手探りで指針を作りつつあるRustで議論のレベルが同じにならないのは自然なのでは

**デフォルトの名無しさん** · 2021/04/21(水) 18:42:16.83

>>204
問題はそういう言語の問題まで行かず、カーネルが備えるべきところってな議論で止まってるって部分だけどね。
歴史という意味ではそもそもカーネルに対する歴史観が不足してる連中しかrustにはいないということになる。

**デフォルトの名無しさん** · 2021/04/21(水) 22:06:45.67

プロセスがスローし、誰も補足しなかった例外を
最終的に捕捉してそのプロセスを終了させるのはOS（ことによったらカーネル）の仕事である

一方、カーネルが仮に例外をスローしてしまったら誰が最終的な捕捉の任を負うのか
について今今のOS論には目下定説が無い

Linux（リーナス）は「カーネルは何があっても例外をスローすんなﾊｹﾞ、」という
古典的な立場
のやつ、

**デフォルトの名無しさん** · 2021/04/21(水) 23:10:54.58

機械語に例外なんてねーよ
いい加減なこと言ってんじゃねーや

**デフォルトの名無しさん** · 2021/04/21(水) 23:43:21.15

>>206 CPUの例外と言語上の例外との区別が付いてないみたいね。

**デフォルトの名無しさん** · 2021/04/22(木) 00:18:18.68

>>203
javascriptでメソッドとか探すときにプロトタイプを遡っていく動きがあるけど
それをRustのドット演算子（.）がメソッド使える型になるまで自動で参照解決する仕様で
模倣したんだと思う

演算子の特殊な拡張は正規表現とか構文解析のライブラリでたまに見かけるけど
どちらかと言えばトリッキーな手法

**デフォルトの名無しさん** · 2021/04/22(木) 02:40:36.34

panic上等のredox！
セキュリティホール開けるよりマシという理由だった。

>>203
アンチパターンだから通常のコードでは使うな。
トレイトメソッド呼べないからクソって所まではすでに
githubのissuesやrust internalsで合意が有る。
js-sysはffi（バインダ）だから仕方ない。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/22(木) 02:53:02.19

>>203
ガイドライン的には Deref はスマートポインタだけにしとけってことになってる。
https://rust-lang.github.io/api-guidelines/predictability.html#only-smart-pointers-implement-deref-and-derefmut-c-deref

**デフォルトの名無しさん** · 2021/04/22(木) 05:58:54.39

例外の最終的な捕捉をOSの仕事、と書いたのは語弊があったｽﾏﾝｶｯﾀ、
正確に言えば言語のランタイムが最終的に捕捉してプロセスを自発的に終了する
（スタックのアンワインドは言語依存性が強いのでそうなっている

しかしプロセスが自発的にexit()したら誰がそれを処理するのかというとOSやんけ；；；
カーネルの中で例外を生じられたら誰が終了を担保するのかについて
OS論的に定説が無いのは真

>>208
いじょ

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

で、別の観点の話をする、

OSがpanic上等というのはそれはそれでも良いが、
とにかくスタックのアンワインド処理は言語依存性が強いので
例外が通過する関数（ゼロコストの奴も含む）の巻き戻しのためには
関数のアドレスとスタックのアンワインド方法の対応表をランタイムが把握せねばならない
というわけでカーネル内の例外を認めると、その例外を最終的に捕捉する奴より
上の関数を全部同一言語・同一コンパイラで書かねばならないという縛りが生じる
現実にはそれで問題など生じないかしらんが、とにかくレイヤー分けに縛りが生じる
Redoxの一部をC++（等）で書くことは事実上不可能に、

**デフォルトの名無しさん** · 2021/04/22(木) 13:01:11.46

>>212,213
なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？

>>213
Linusがカーネル書くのに信用してないだけで
C++でもフリースタンディング書けるだろ。
C++のフリースタンディングは最低限の標準ライブラリは持つからrustのcoreクレートと同じ。
C++ならexception、abort,exitがある。
>>213がホストとベアメタルの区別がついてないだけじゃないか？
あと、redoxのpanicはスタックトレース吐いてx86のhltループするだけだから。

そもそもカーネルで標準のexitなんか呼ぶか。

**デフォルトの名無しさん** · 2021/04/22(木) 13:21:02.53

Linux界隈といえばちょうど｢マージしたパッチが研究目的にわざと脆弱性を含んだものだったことが発覚して激おこで送ってきた奴らの大学出禁にする｣みたいな面白いことが起こってる模様

**デフォルトの名無しさん** · 2021/04/22(木) 13:49:41.54

どうせお前らはOS書かないんだからどっちでもいいじゃん

**デフォルトの名無しさん** · 2021/04/22(木) 15:39:04.46

linuxの騒動の話はさすがにスレチ

**デフォルトの名無しさん** · 2021/04/22(木) 21:04:10.86

Cコンパイラゼミ消失問題を思い出した
https://twitter.com/rui314/status/1384422532363657221
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2021/04/22(木) 23:08:37.40

研究目的だろうがそうでなかろうがわざと脆弱性を含むパッチを簡単にマージできている、という状況が問題なんであって
腹たつから大学出禁にしたった、とやったところで根本的な問題は何も解決しないんだけどlinuxのメンテナンスしてる連中とか
linusを筆頭にとか老害頭ばっかりだから自分がスッとすれはそれでいいんだろうな

**デフォルトの名無しさん** · 2021/04/22(木) 23:21:38.67

1) 善意でやってくれてる連中にケチつけんな
2) じゃあお前が根本的な解決とやらをやれ
3) もしくはその根本的な解決方法を彼らに教えてやれ

**デフォルトの名無しさん** · 2021/04/22(木) 23:33:32.83

しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
らすとすぱぁとをきめるスレ

**デフォルトの名無しさん** · 2021/04/22(木) 23:52:38.76

rust厨八つ当たりw

**デフォルトの名無しさん** · 2021/04/23(金) 08:31:32.27

その脆弱性もUAFとかぬるぽデリファレンスとか未初期化領域の使用とか2重開放とか最近の言語じゃ明らかに意図してやらなきゃ起きないようなもんばっかだもんなぁ
そりゃC/C++にしがみついてる大先輩方にとっちゃ逆鱗だわな

**デフォルトの名無しさん** · 2021/04/23(金) 08:34:12.76

そんなもんunsafeしまくれば同じだろ。。
そういう問題じゃないことくらいわかるだろうに、本当の馬鹿だな。

**デフォルトの名無しさん** · 2021/04/23(金) 08:36:52.46

C++とlinuxの話禁止な

**デフォルトの名無しさん** · 2021/04/23(金) 08:52:11.81

rustでOSかける->linus、panicある限り載せねーよ->rust信者発狂

**デフォルトの名無しさん** · 2021/04/23(金) 09:00:00.40

発狂？むしろ歓迎
個人で使うようなアプリは好きなだけパニくれ
使われるアプリはパニくんなカス、これ常識だろ

**デフォルトの名無しさん** · 2021/04/23(金) 10:42:10.47

言語実装的にもそうなってないよねって話なんだけど、なんだか通じてなさげ。

**デフォルトの名無しさん** · 2021/04/23(金) 11:59:33.30

rustにもgoのマスコットキャラみたいなのいないんですか？

あめ ◆P0jSlC5fJs · 2021/04/23(金) 12:13:46.74

かにさん

**デフォルトの名無しさん** · 2021/04/23(金) 12:17:43.73

>>214
>なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
カーネル内での例外を許すみたいな立場で話す人が居るから

例外メカニズムが言語ランタイムと不可分な理由は
>スタックのアンワインドは言語依存性が強いのでそうなっている (>>212

C言語みたいにそもそも例外メカニズムを持たない言語を使った場合のみ
言語ランタイムと切り離したカーネル設計ができてｽｷｰﾘ

**デフォルトの名無しさん** · 2021/04/23(金) 12:23:39.46

>>219
だから、脆弱性を簡単に盛り込めないように危険な団体を排除しただけだろ。
普通の対応だと思うけど？

**デフォルトの名無しさん** · 2021/04/23(金) 12:31:21.77

>>231
> >なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
> カーネル内での例外を許すみたいな立場で話す人が居るから

いません
この話はおわり

**デフォルトの名無しさん** · 2021/04/23(金) 12:56:09.67

「注意すればC/C++でも問題ない」って意見は日本的だよな
人間はミスしないことが前提になっている
Rust Foundationのメンバーに言わせればそういう問題ではない
人間はミスするものだってなるんだろうけど

**デフォルトの名無しさん** · 2021/04/23(金) 13:00:34.48

そのミスの取り除き方のアプローチの違いだっていうことにさえ気づかない馬鹿。

**デフォルトの名無しさん** · 2021/04/23(金) 13:33:15.21

c++でミスするような無能はrustでも使ってろと怒鳴り散らす
これが正しいアプローチ

**デフォルトの名無しさん** · 2021/04/23(金) 13:43:27.45

>>229-230
なんで蟹なんだろうな。
PythonユーザーのことPythonistaって言うみたいに
RustユーザーのことRustaceanって言うけど、
これCrustacean（甲殻類）からCを取り除いたものなんだな。

**デフォルトの名無しさん** · 2021/04/23(金) 14:28:40.04

エビにしろよな
カニだとRealtekと被るじゃん

**デフォルトの名無しさん** · 2021/04/23(金) 14:58:40.99

大半の人は、C/C++の文法がわかる程度でプログラムを書いているのが現状だろう
何がミスなのかそもそもわかっておらず、Rustを勉強している人と話も噛み合わない

**デフォルトの名無しさん** · 2021/04/23(金) 15:01:12.26

c++とrustの部分入れ替えてもなんの違和感もない文章だね

**デフォルトの名無しさん** · 2021/04/23(金) 15:03:21.83

君にはそう見えるだろうね

**デフォルトの名無しさん** · 2021/04/23(金) 15:05:01.62

君にはそう見えないんだろうね

**デフォルトの名無しさん** · 2021/04/23(金) 15:05:59.83

とりあえず、話が噛み合わないのはわかったでしょ

**デフォルトの名無しさん** · 2021/04/23(金) 15:07:53.22

C++ドロップアウターが希望を求めてやって来るスレ

**デフォルトの名無しさん** · 2021/04/23(金) 15:13:29.93

スレでグチグチ言うよりプログラム書いた方がよっぽど理解できるよ

**デフォルトの名無しさん** · 2021/04/23(金) 15:20:14.54

C/C++で穴のあるコードを書いてもしょうがないし、それも難しいんじゃないのかな
逆にC/C++の人らがRustコンパイラをすり抜けるヤバいコードを提示してくれたら、一発で口だけじゃなく出来る人だったと示せるだろうが

**デフォルトの名無しさん** · 2021/04/23(金) 15:28:23.22

>>155
> Rustに比べたC++の良さは雑に書けるところだって気付いた
> やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ

これが何気に的を得てるでしょ
コンパイラが安全な方に導いてくれるのはもちろん良いとして、それよりも雑に (あるいは短く親しんだ方法で) 書きたい思惑が優先されるときは C/C++ でやれば良い話で

**デフォルトの名無しさん** · 2021/04/23(金) 15:38:53.83

いや、Rustでラクに書けない時点で勉強が不足してる
そのことに自分で気付けるような人だけRust使えばいい

「当を得る」か「的を射る」ことが出来るような人になってほしい

**デフォルトの名無しさん** · 2021/04/23(金) 15:56:22.07

いや、単にコード長が C/C++ の方が短く書ける可能性高いでしょ
どんなイディオムを駆使しても

**デフォルトの名無しさん** · 2021/04/23(金) 15:59:55.49

あと近年では「的を得る」は必ずしも誤用じゃないという見方が主流でしょ

**デフォルトの名無しさん** · 2021/04/23(金) 19:45:46.49

Rustの方が雑に書ける局面多いと思うけどなぁ

**デフォルトの名無しさん** · 2021/04/23(金) 20:51:53.23

C++ vs Rustスレでも作ってそっちでやってくれマジで
不毛すぎる

**デフォルトの名無しさん** · 2021/04/23(金) 21:04:58.31

>>249
そうだね、記述量の多い言語だと思う

**デフォルトの名無しさん** · 2021/04/23(金) 22:37:03.61

Rustのコンパイラと戦って勝ったコードは
シンプルでエレガントで簡潔なことが多い
らしい
mjk、

**デフォルトの名無しさん** · 2021/04/23(金) 23:34:43.49

linusはやっぱすげーな
洞察力が違うわ
もちろんその道の神的な存在とはいえ
たいして知らない言語の弱点を一瞬にして暴いて
論破できるのは凄い

**デフォルトの名無しさん** · 2021/04/24(土) 01:08:35.83

>>251
例えばどんなとき？

**デフォルトの名無しさん** · 2021/04/24(土) 01:20:53.45

どんなときもどんなときもRustがRustらしくある～ために～

**デフォルトの名無しさん** · 2021/04/24(土) 08:06:24.96

C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

立てましたので以降そういうのはこっちでお願いします

**デフォルトの名無しさん** · 2021/04/24(土) 08:33:43.03

>>258
お前ずっと一人で「他所でやれ」連呼してる奴だろ
C++との対立構造はRustにとって無視できないテーマでしょ
正直C++とどう住み分けたら良いのかわかってない奴がほとんどなんだから

**デフォルトの名無しさん** · 2021/04/24(土) 08:39:09.80

C++とRustは対立なんてしてない
Rustが怖いC++お爺ちゃんがRustに噛みつているだけでしょ

**デフォルトの名無しさん** · 2021/04/24(土) 08:48:20.99

カーネルの件で完全に拗らせとるな

**デフォルトの名無しさん** · 2021/04/24(土) 08:54:35.43

> C++との対立構造はRustにとって無視できないテーマでしょ

お前のテーマなんてどうでもいいんだよ
よそでやってくれ

**デフォルトの名無しさん** · 2021/04/24(土) 08:59:24.96

一般的なテーマだってこともわからんのか。馬鹿だな。

**デフォルトの名無しさん** · 2021/04/24(土) 09:02:59.11

リナス「やっぱCが至高、C++もRustもクソ！」

**デフォルトの名無しさん** · 2021/04/24(土) 09:13:04.98

rustもpanicをコアから外せればいけると思うのだが
もろ言語のコアなんだよな
痛いところ突かれた

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

言語の問題じゃなくてライブラリの問題では

**デフォルトの名無しさん** · 2021/04/24(土) 10:11:32.69

へーpanicってライブラリなんだ

**デフォルトの名無しさん** · 2021/04/24(土) 10:29:13.61

>>259
仮にその対立構造を認めるにしても
「雑に書くならC++のほうが楽」なんて、曖昧で基準も何も示されない話に真面目に付き合う奴はいないよ
そういう奴らのための隔離スレとして用意したから好き放題書き散らせばいい

**デフォルトの名無しさん** · 2021/04/24(土) 10:42:59.04

コード長の話でしょ？
どー考えてもC++の方が短いよ
んなとこで張り合ってもしゃーない

**デフォルトの名無しさん** · 2021/04/24(土) 11:44:33.91

3割ぐらいは長いな
https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html

median source code gzip (July 2018)
Ruby 568
Python 672
C++ 1044
C 1115
Rust 1319

**デフォルトの名無しさん** · 2021/04/24(土) 12:07:10.57

>>258
乙。次からテンプレ入りで

>>980
スレ立てよろ

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

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

日本語の情報
https://rust-jp.rs/

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

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part10
https://mevius.5ch.net/test/read.cgi/tech/1617367084/
==========

**デフォルトの名無しさん** · 2021/04/24(土) 12:17:31.75

Rustしかまじめに勉強したことないけどいい言語だと思うよ

**デフォルトの名無しさん** · 2021/04/24(土) 12:21:15.48

>>272
C/C++で一度ひどい目にあわないとRustの良さは分からんよ
今はまだ分かった気になってるだけ

**デフォルトの名無しさん** · 2021/04/24(土) 12:39:27.31

Rustはコンパイルでひどい目にあうから問題無い
同じことだ

**デフォルトの名無しさん** · 2021/04/24(土) 12:56:02.52

Rustのコンパイラに怒られまくる奴は三流プログラマ

**デフォルトの名無しさん** · 2021/04/24(土) 12:59:06.14

Rustの文字列変数って、
str1 = str2;
のように書いた時、copyではなくmoveでしたっけ？

**デフォルトの名無しさん** · 2021/04/24(土) 13:03:33.00

String型ならmove、&str型ならcopy
文字列リテラルなら後者

**デフォルトの名無しさん** · 2021/04/24(土) 13:09:43.73

>>276
調べてみたら、やっぱり、
let s1 = String::from("hello");
let s2 = s1;
とすると、以後、s1は使用できなくなり、使用しようとするとコンパイルエラー
になるんだね。こうなるのは珍しいと言えば珍しい言語。
1. Javaだと、参照を入れるだけで同じ実体を指しているため、s2経由で変更してもs1が
　指しているものも変更される。
2. JS の文字列は primitive 型なので「コピー動作」となり、s2とs1は別の実体を
　指すことになり、一方を変更しても他方には変更の影響は及ばない。
3. MFCのCStringも意味的にはコピー動作なのでJSと似ているが、高速化のため、
　代入後に一度も書き換えなければ、文字列を入れているメモリブロックは複製
　されないし、コピーもされない。
4. STL(C++) の std::striingもMFCと意味的には似た動作。
5. BASIC言語でも、文字列はコピー動作。
6. Rubyの場合、Javaと同じで同じ実体を参照しているだけなので、一方を書き換えると
　他方も全く同じように書き換わる。コピーするためには、s2 = s1.dup; と書く。

つまり、
a. BASIC、JS、MFC、STL(C++)は似た動作。
b. JavaとRubyも似た動作。
c. Rustは、b の系統に似ているが、s1 が使えなくなるのでちょっと違う。

**デフォルトの名無しさん** · 2021/04/24(土) 13:13:27.35

>>278
無駄なことに時間使ってないでthe bookくらい読みなよ

**デフォルトの名無しさん** · 2021/04/24(土) 13:20:12.76

>>
C# は、「b.」の系統で、JavaとRubyと似た動作だね。

**デフォルトの名無しさん** · 2021/04/24(土) 13:23:38.54

>>279
いろんな言語をかじってしまうと、どれがどれだか分からなくなってしまうんだよ。
文字列の s2 = s1 の動作は：
a. BASIC、JS、MFC、STL(C++)は似た動作。中身をコピーする。
b. Java、Ruby、C# が似た動作。参照を代入するだけ。コピーしたければ明示する。
c. Rustは、b の系統に似ているが、s1 が使えなくなる。

**デフォルトの名無しさん** · 2021/04/24(土) 13:27:17.48

>>281
Javaの場合、Stringは参照しか出来ないが、Rustの場合は、「String型」だけでなく、
「Stringへの参照型」も使えるんだっけ (let s3:&String ??) ？

**デフォルトの名無しさん** · 2021/04/24(土) 13:36:44.63

>>281
C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、
moveで、それ以外の時は copy。
一方、Rustだと、「デフォルト move」なので、基本的には move 動作。
cooy したければ、x = y.clone; と書くのかな。
色々ややこしい。

**デフォルトの名無しさん** · 2021/04/24(土) 13:39:26.22

>>283
> C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、moveで、それ以外の時は copy。

そんな親切け？？？
左辺値同士だと明示しないとmoveしてくれないだろ
最適化次第ではしてくれるの？

**デフォルトの名無しさん** · 2021/04/24(土) 13:43:36.80

>>284
えっと、関数の戻り値が構造体型(or クラス型)の場合、右辺値と解釈されるので、
s2 = func(xxx);
見たいにした場合は自動的に move代入されたと思う。
それ以外だと、たいていは、s2 = std::move(s1); のように書かなければ
copy代入になるんじゃないかな。
s2 = func(xxx).s;
のようにした場合も move代入になるはず。
自信は無い。

**デフォルトの名無しさん** · 2021/04/24(土) 13:47:10.36

>>285
RVOは全然違うぞ
s2の構築にコピーコンストラクタを使わなくなって早くなるというだけ
ムーヴコンストラクタはそもそも出てこない

**デフォルトの名無しさん** · 2021/04/24(土) 13:47:25.73

>>285
自分の記憶だと、一時オブジェクトも右辺値だから、
s2 = std::string("xxx");
ともし書いたとしたら、右辺は右辺値になるのでmove代入になるはず。
s2 = s3 + s4;
みたいにしても、右辺は関数の戻り地と解釈されるので右辺値になるので
move代入になるはず。

**デフォルトの名無しさん** · 2021/04/24(土) 15:48:01.23

Rustってコードをフォーマットしてくれる機能があるからいいね
これこそモダンな言語だと思う

**デフォルトの名無しさん** · 2021/04/24(土) 16:01:24.29

C++と比べりゃ大抵の言語はモダンだろうよ

**デフォルトの名無しさん** · 2021/04/24(土) 16:18:04.79

しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
rustすぱぁとをきめるスレ

**デフォルトの名無しさん** · 2021/04/24(土) 16:38:27.41

lintツールも満足に使えない人が喜んでるのかね

**デフォルトの名無しさん** · 2021/04/24(土) 17:14:02.73

非Syncなデータに複数スレッドからアクセスするコードに警告だしてくれるlintある？

**デフォルトの名無しさん** · 2021/04/24(土) 18:12:05.46

へーそれコードをフォーマットしてくれる機能なんだ

**デフォルトの名無しさん** · 2021/04/24(土) 22:25:57.79

>>293
君は、松永の論文を読んだのかい？

**デフォルトの名無しさん** · 2021/04/25(日) 11:06:21.68

質問です

let a = 10;
let b = &a;
let &c = b;

としたときに変数cは数値の10になるのですが
cの前にある&は参照外しの効果があるということなのでしょうか？

**デフォルトの名無しさん** · 2021/04/25(日) 12:30:46.33

>>295
pattern matchとdestructuringでそうなる
3行目でbの型が&Tの場合に`&c`にマッチさせたらcの型はTになる
dereferenceの意味で「参照外し」と言ってるなら意味は違うかも

**デフォルトの名無しさん** · 2021/04/25(日) 13:38:30.57

>>296
横から失礼するけど、なるほど。
let &c = b;
は、C++の
int &c = b;
とはかなり違った解釈をされてしまうんだね。後者の場合、&は参照型の
記号で、cの型は、intへの参照型になる。Rustで似たことをしたいなら、
let c:&i32 = &b;
だったっけ？

**デフォルトの名無しさん** · 2021/04/25(日) 13:41:33.98

String::fromとString::newの使い分けを教えてください

**デフォルトの名無しさん** · 2021/04/25(日) 15:13:55.60

>>297
cも参照にしたいなら単純に
let c = b;
でいいはず

let &c = b;
は
let (x, y) = (1, 2);
と似たような代入式だからbが参照型（かつ被参照型がCopy可能）じゃないと
コンパイルできない

>>298
String::newは引数取らないで空文字列を作る
String::fromは引数に文字とか文字列を取って同じ内容の文字列を作る

リファレンス（↓）読みなさいと言いたいけどRustのリファレンスって
traitとか理解しないとなかなか読みこなせないよね
_ttps://doc.rust-lang.org/std/string/struct.String.html

**デフォルトの名無しさん** · 2021/04/25(日) 15:19:02.60

>>297
>let c:&i32 = &b;

>>295の続きならbがすでに&i32なので
let c = b; か
let c: &i32 = b;

C++でもStroustrupに従ってint& c = b;と書いとけば同じ意味にとれなくもない

**デフォルトの名無しさん** · 2021/04/25(日) 15:31:18.79

意図もわからずなんとなく動くからそのメソッドを使い、借用をつければなんとなく動くから
借用し、変更する予定はないけどmutし、ここはエラーだからとpanic!し、補足するなと言われているのに
catch_unwind/recoverして、血の涙で泣きながら渡されたソースをシコシコ直すおまいら・・・

**デフォルトの名無しさん** · 2021/04/25(日) 16:19:28.48

>>299 >>300
なるほど、Rustでの b は、C++で言えば「参照」ではなく「ポインタ」の「ようなもの」に
なっているので、
let a = 10;
let b = &a;
の状態だと、
let c = b; か
let c: &i32 = b; か
let c: &i32 = &a;
で c を b と同じような「Rustでの参照型」の変数に出来るわけね？

**デフォルトの名無しさん** · 2021/04/25(日) 16:55:56.06

>>302
C++で書き直すと、
int a = 10;
int *b = &a;
の状態だと、
int *c = b; か
int *c = &a;
で c を b と同じような「C++のポインタ型」の変数になる。
ということだね。