Rust Part5

**デフォルトの名無しさん** · 2018/02/11(日) 20:07:24.54

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://mevius.5ch.net/test/read.cgi/tech/1507970294/

**デフォルトの名無しさん** · 2018/06/23(土) 17:56:54.88

みんな英語どうやって勉強したの

◆QZaw55cn4c · 2018/06/23(土) 18:09:48.96

>>653
受験勉強で

**デフォルトの名無しさん** · 2018/06/23(土) 18:09:55.67

>>653
俺は英語なら分かるんだけど、日本語はさっぱり分からん

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

>>654
すげーな
オライリーのやつKindleで読んでるけどまず訳すのが大変だわ

**デフォルトの名無しさん** · 2018/06/23(土) 18:27:07.96

>>655
英語圏に生まれたかったと切に思う

**デフォルトの名無しさん** · 2018/06/23(土) 19:52:59.41

訳さず英語で読んだ方が…
情報の早さ・量・正確さが段違いだし原著読むと意外と難しい単語使われてない。
bind(bound)を束縛とかアホかと。
せめて結びつけとかにしろよと。
翻訳のセンス無さすぎ。
もしくはわざと小難しくして地位を守ってるのか…

**デフォルトの名無しさん** · 2018/06/23(土) 19:59:41.54

結びつけだとassociateの訳ともとれそう
英語と一対一で対応できる和訳の方があとから英語情報に触れるときのハードルを下げると思う

◆QZaw55cn4c · 2018/06/23(土) 20:01:25.05

>>658
get / put / take なんかで言い換えしたからといって、わかりやすくなったとは思わない

**デフォルトの名無しさん** · 2018/06/23(土) 20:13:20.08

それにしても～を～に束縛しますとかセンス無さすぎる。
明治時代の翻訳見習ってほしい。
漢籍の素養が必要だが…

**デフォルトの名無しさん** · 2018/06/23(土) 20:59:38.24

逆に聞くが「変数にbindする」って日本語にどう訳したら自然なんだ？「結びつける」は別の意味になるぞ

明治期のアレは翻訳っていうよりは対応する訳語を創出するって感じだから、単純な翻訳じゃないぞ

「縛りつける」みたいな感じになるしかないと思うんだが
束縛は単純に漢語にしただけで大差なかろう

**デフォルトの名無しさん** · 2018/06/23(土) 21:03:29.72

>>652
ありがとう
一応そういうのあるんだ
そのページの下に書いてある、edition 指定出来るようになるのを期待、という感じかな

**デフォルトの名無しさん** · 2018/06/23(土) 21:53:58.53

> 翻訳のセンス無さすぎ。

お前にはあるかのような口ぶりで

> せめて結びつけとかにしろよと。

↑こんなこと言い放ちつつも

> もしくはわざと小難しくして地位を守ってるのか…

束縛っていうふつうの単語を小難しく感じると白状し
地位を守るだのなんだのという珍妙な価値観まで丸出しにするとは恐れ入る

**デフォルトの名無しさん** · 2018/06/23(土) 22:00:12.26

まあ、英語のbindからして数理論理の変数束縛と同じ単語を別の意味で使いまわしてる
近い分野なんだから専門用語もう少し考えてくれても良かったのに

**デフォルトの名無しさん** · 2018/06/23(土) 22:31:42.63

慣れちゃってるから気づきもしなかったけど代入からして大概だよな。
英語だと単にassignだぞ。

**デフォルトの名無しさん** · 2018/06/23(土) 22:44:14.17

その点、グーグルは気が利いてて、
「錆は、安全性、スピード、並行性に重点を置いたシステムプログラミング言語です。
以前のバージョンのRustが錆びてインストールされている場合、」
だからな

**デフォルトの名無しさん** · 2018/06/24(日) 00:43:46.88

「バインドする」で良いのでは
traitとかcrateとか訳すとよくわからなくなるもの多いし全部カタカナでよい

**デフォルトの名無しさん** · 2018/06/24(日) 00:53:31.43

a に 1 を綴じます。

**デフォルトの名無しさん** · 2018/06/24(日) 01:02:45.16

タイプアノテーションのないバリアブルのタイプはライトサイドをエバリューションしたときのタイプになります

**デフォルトの名無しさん** · 2018/06/24(日) 02:00:22.91

是々非々だな。
型アノテーションのない変数の型は右側を評価したときの型になります
束縛するはバインドするでよかった。SMの趣味ないし。

**デフォルトの名無しさん** · 2018/06/24(日) 07:41:58.64

束縛と代入ってなにか違うんけ？

**デフォルトの名無しさん** · 2018/06/24(日) 08:29:18.59

誰に確認したわけじゃないが、変数に何か値を設定するのが代入で、値に名前を付けるのが束縛だという認識
fn foo(...) {...} は、ある関数に対しfooという名前をつけるので「関数をfooに束縛する」とは言うかもしれないけど、
「fooに関数を代入している」とは言わない、みたいな

**デフォルトの名無しさん** · 2018/06/24(日) 09:14:33.52

緊縛と挿入!

**デフォルトの名無しさん** · 2018/06/24(日) 09:46:27.06

単にイミュータブルかミュータブルかの違いでないの？

**デフォルトの名無しさん** · 2018/06/24(日) 09:52:28.95

>>673
伝統的な表現だと宣言に近いニュアンスかな

**デフォルトの名無しさん** · 2018/06/24(日) 10:29:37.13

rustはバインドしていない状態の変数も合法だからややこしい

let hoge;
hoge = 100; // これをコメントアウトするとコンパイルできない
println!("{}", hoge);

**デフォルトの名無しさん** · 2018/06/24(日) 12:51:16.68

初心者なんですが、文字列を作成して返す関数を作るときって、
fn hoge() -> String { "hoge".to_string() }
と書くものですか？
それとも
fn hoge() -> &'static str { "hoge" }
と書くべきでしょうか？

**デフォルトの名無しさん** · 2018/06/24(日) 13:59:02.13

その例だと関数にする必要なくない

**デフォルトの名無しさん** · 2018/06/24(日) 15:24:02.20

>>678
テケトーにググっただけ

つ https://qiita.com/Mizunashi_Mana/items/db88cb0bff002abce1ae

**デフォルトの名無しさん** · 2018/06/24(日) 18:18:06.50

Stringもstrも返す可能性があるなら Cow<str> で
それ以外なら使えるときは &str を使うのが良いのでは

**デフォルトの名無しさん** · 2018/06/24(日) 19:01:12.28

Stringとstrを両方残しちゃうあたり
優柔不断でグダグダな言語に思えてしまう

**デフォルトの名無しさん** · 2018/06/24(日) 19:14:57.34

はあ…？

**デフォルトの名無しさん** · 2018/06/24(日) 19:22:46.99

C FFIに関する技術資料ってどこにあるんだろ？
ttps://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html
にチュートリアルはあるけどexternの記述方法とかがわからない
見よう見まねで書けなくはないけどそのまま行くのは事故の元だし
ついでにlibcが何をしているのかもわからない

**デフォルトの名無しさん** · 2018/06/24(日) 20:18:07.31

>>684
CのヘッダからRustのインターフェースを自動生成してくれる
bindgenを追っかけてみればよいかと
https://github.com/rust-lang-nursery/rust-bindgen

**デフォルトの名無しさん** · 2018/06/24(日) 22:15:14.01

>>683
せめて理論的に反論しろよグダグダ言語の信者

**デフォルトの名無しさん** · 2018/06/24(日) 22:29:21.43

>>686
ごめんなさい
論はどこですか？

**デフォルトの名無しさん** · 2018/06/24(日) 23:26:54.62

>>685
えぇ・・・ソース見るしかないのかよ・・・
リファレンスマニュアル見てもちゃんと書いてないんだよな
さらにググってもリファレンスマニュアルが引っかかってこない罠

**デフォルトの名無しさん** · 2018/06/24(日) 23:57:53.79

>>684,685
unsafeまわりの文書に入ってる（ただしdraft）
https://doc.rust-lang.org/nomicon/ffi.html
公式文書はgithubのorganization（rust-lang、rust-lang-nursery）から探している

**デフォルトの名無しさん** · 2018/06/25(月) 00:22:53.39

C言語ライブラリの関数を3回呼び出すコードと格闘すること数時間。ようやく動いた
まだ不明点は残っている
・#[link(～のkindが何を示しているのか判らない
　C FFIの使用例を見るとよく見るんだが・・・
・C言語配列の渡し方が不明
　元は
　>int p[]={16,9};
　>foo(p);
　とりあえず
　>foo("\x10\x09".as_ptr());
　などと書けばデータ上は整合するから動くけどどう見てもスマートな記述方法ではない
・文字リテラルの仕様が不明
　↑の表記を得るのに数回試行錯誤した

データの与え方もCStringを使った(＝\x00終端する)方法は出てくるけど、そうではない方法は
中々見つからなかった。結局↑の表記に落ち着いたが

>>689
ありがとう。kind値について書いてありますね。静的リンクだとkind = "static"らしいですが
付けても付けなくてもファイルサイズは大差ないようです。何が違うのだろう

**デフォルトの名無しさん** · 2018/06/25(月) 12:50:29.35

Cの配列は第一級の値じゃないからas_ptrが正攻法だと思う

**デフォルトの名無しさん** · 2018/06/25(月) 20:19:17.73

>>689によればFFIで使用できる物として
・#[repr(C付きのstruct
・#[repr(C付きのenum
・box？
・vec
・str
が挙がっているけどCと互換性があるのはこれらのみって事なのだろうか
vecを試してみたら動いたけどextern時に安全じゃないから#[repr(C)]付きのstruct使えなどと言いだした

>>691
マジかよ！確かに文字列は汎用性が高いけど可読性が良くない・・・必要に応じて抽象化しろという事か

**デフォルトの名無しさん** · 2018/06/25(月) 20:24:02.61

Rustの側では変更しないけどCの側で変更するような変数ってmutにしないと駄目よね？

**デフォルトの名無しさん** · 2018/06/25(月) 22:00:13.27

あっ、ヤベェ・・・いきなり重大なバグ出してら
×　foo("\x10\x09".as_ptr());
○　foo("\x10\x00\x00\x00\x09\x00\x00\x00".as_ptr());
こうだよな
標準で[16: i32, 9: i32]を"\x10\x00\x00\x00\x09\x00\x00\x00"に変換してくれるようなのが欲しい

**デフォルトの名無しさん** · 2018/06/25(月) 22:05:44.09

うわこれは読みたくないw
難しいもんだな

**デフォルトの名無しさん** · 2018/06/25(月) 22:59:19.25

ちなみに間違っている状態でも呼んだC関数は正常に終了します。まさにunsafeです。怖いです
何か対策を考えないと大事故を起こしそう
要素数2しかないのにstructを書くのはコード効率の点からも可読性の面からもあまり良いとは思えないし・・・
いろいろ試してみたら
>let p: [i32; 2] = [16, 9];
>foo(&p);
ならいけるようだ。コンパイラは何も言わないけどこの表記が適切かどうかは不明

Rubyだと
foo([16,9].pack("i2"))　#配列をint2個分の文字列(＝8byteのバイナリ列)に変換
とか書けるんだよなぁ。コストは安くないけど>>694みたいなポカミスは起こらない

**デフォルトの名無しさん** · 2018/06/25(月) 23:46:12.87

>>696
何がしたいかよく分からんが
何故にC側がintの配列なのにRust側では文字列を使おうとしてるんだ？
C側がintってことはRust側で対応する型はisizeだろ
(Cのintが事前に32bitと分かってる場合はi32でも可
同様に64bitだと分かっている場合は対応する型はi64)

つまり、Cで
int[] x = {16, 9};
なら、Rustで同じデータを表すものは
let x: [isize; 2] = [16, 9]; // let x = [16_isize, 9]; でもおk
って書けば良いはず

Rubyと同じように考えようとするから変なことになる
RustでFFIするならCと対応する型は何かを考えれば良い

**デフォルトの名無しさん** · 2018/06/26(火) 00:21:30.73

>>697
いや、isizeはまずいんじゃない？
例えばx86_64だとisize:64bit,int:32bitだし。
libcクレートのc_intならアーキテクチャ毎に適切なサイズになるから
こちらがいいかと。

**デフォルトの名無しさん** · 2018/06/26(火) 00:26:36.57

ついでに言うとFFIするときの型はプリミティブ型以外でも
とりあえずlibcクレートを探すといい。
まぁマイナーなアーキテクチャだと間違ってたりすることもあるから
確認は必要だけど。

**デフォルトの名無しさん** · 2018/06/26(火) 00:50:28.55

とりあえず仕返しにrubyスレ荒らそうぜ
http://mevius.5ch.net/test/read.cgi/tech/1523954817/

**デフォルトの名無しさん** · 2018/06/26(火) 00:50:41.38

>>698
あれ？そうだっけ？
うかっりしてたゴメン

そう言えばCのintはポインタのサイズに合わせるんじゃなくて
アーキテクチャ毎に変わるんだったっけか

**デフォルトの名無しさん** · 2018/06/26(火) 01:08:16.37

調べたらCのintにRustで対応する型はisizeじゃなくてstd::os::raw::c_intだったわ
libcのc_intとの違いがよく分からん
対応アーキテクチャの数か？

**デフォルトの名無しさん** · 2018/06/26(火) 02:21:07.36

>>702
一応libcはno_stdでも動くというメリットがあった気はする。
逆にプリミティブ型限定でも依存ライブラリ増やしたくないならstdなのかな？

**デフォルトの名無しさん** · 2018/06/26(火) 08:11:12.99

>>697
あなたの言うとおりですが、そのような情報はどこをから得られるのか・・・
>>689等のFFIに関する資料に書いてあるようには見えません
std::os::raw::c_intも>>702を見て探してみたら
ttps://doc.rust-lang.org/std/os/raw/index.html
ここにあるのか

配列等の長さが変わる型のC互換性に関する情報もどこにあるんだろ
アドレスの連続性とメモリの確保が保証されている必要があると思いますが

**デフォルトの名無しさん** · 2018/06/26(火) 08:35:08.35

>>704
資料が少ないのはまだ普及してない言語では仕方がない
FFIとか皆が頻繁に使う機能じゃないようなものはなおさら
Cの配列とRustの配列は互換があるはずだけど
悪いがその情報をどこから手に入れたかは覚えていないし
信用されても困る(ついさっきも間違えたしね)
場合によっては資料探すよりソースコード読んだほうが早いことも多いし
根気良く調べるしかないとしか言いようがない
あとはFFIみたいなunsafe部分は出来る限り念入りにテストを書くとか

**デフォルトの名無しさん** · 2018/06/26(火) 09:06:54.14

>>704
arrayとsliceの連続性保証はここですかね。
https://doc.rust-lang.org/reference/type-layout.html#array-layout

**デフォルトの名無しさん** · 2018/06/26(火) 10:23:55.54

今のnightlyだとclippyビルド出来ないよね？
ビルド出来る最後のバージョンと、それをインストールする方法教えてください

**デフォルトの名無しさん** · 2018/06/26(火) 12:18:25.05

RustのABIについてはドキュメント増やすことはできるだろうけど
それ以前の問題としてCのABI知らないとFFIつらいのでは

**デフォルトの名無しさん** · 2018/06/26(火) 18:47:03.15

付き合ってくれてありがとう

まとめるとFFIで使えるのは
・#[repr(C付きのstruct
・#[repr(C付きのunion
・#[repr(C付きのenum　←条件付き
・box？
・vec　←非推奨？
・str
・array
・slice
・std::os::rawの中にある物
このへんで良いのかな
std::os::rawの中とarray、struct、union、strがあれば一通り出来そうか

**デフォルトの名無しさん** · 2018/06/26(火) 20:49:29.40

vecもas_ptr用意されているし非推奨と言うことはないはず
sliceにderefできるし

**デフォルトの名無しさん** · 2018/06/26(火) 23:28:33.57

IDが変わっています

vecの件
>extern {fn foo(p: &std::vec::Vec<i32>);}
>foo(&vec![16, 9]);
これだと
>warning: `extern` block uses type `std::vec::Vec<i32>` which is not FFI-safe: this struct has unspecified layout
>・・・
> = help: consider adding a #[repr(C)] or #[repr(transparent)] attribute to this struct
と言われ正常に動作しない。クラッシュはしないが実行結果がおかしい
>extern {fn foo(p: *const i32);}
>foo(vec![16 as i32, 9 as i32].as_ptr());
これなら問題ないようだ。奥が深い

あとC関数から帰ってきたアドレスをu32へ入れていたのをc_voidへ入れるようにしたら所有権で怒られて動かなくなった
同じコードでも型によって所有権の移動のしかたが違うのか

**デフォルトの名無しさん** · 2018/06/27(水) 00:01:15.59

RustのVec自体には確かCとの互換性はないはずだよ
ただし、Vecはsliceにderefが可能でsliceはCの配列と互換がある

vec![16 as i32, 9 as i32].as_ptr()
はVecに対してas_ptr()メソッドを呼んでるように見えるけど
(ドキュメントを確認すれば分かるが)実際にはVecにas_ptr()メソッドなんて定義されていない
as_ptr()はsliceの方に定義されていて、暗黙的にderefされてからas_ptr()が呼ばれてる
つまり上のコードは丁寧に書き直すと↓と同じ意味(のはず)
let vec: Vec<i32> = vec![16, 9];
let slice: &[i32] = vec.deref();
let ptr: *const i32 = slice.as_ptr();

**デフォルトの名無しさん** · 2018/06/27(水) 00:13:14.65

あとC関数の引数＆戻り値はmove（ポインターか実値）しないとだめじゃない？
&付けて参照渡しにするのはよく分からない、たぶん未定義動作じゃないかなあ

**デフォルトの名無しさん** · 2018/06/27(水) 01:04:32.64

>>707
clippyは最新のnightlyは**追ってない**けど常に開発中だから
ビルドできるバージョンは常に変わる。
自分の環境のビルドできる最大のnightlyに合わせろしか言えん。
常にclippyを使い続けたいなら環境の方をclippyに合わせないとだめ。

>>709
- cの配列はraw pointer
- 配列以外ならrepr(C)してメモリレイアウト合わせるか
- C側でopaque pointer定義してas_ptr
- 汎用ポインタはrust側は

pub enum Void;
type VoidRef = *mut Void;

- cのvoid*がrust側にほしいならlibcクレート
- VLAや不完全配列はrustnomicon読む

まずC abi覚えろ。

std140レイアウトならクレートあるぞ。

**デフォルトの名無しさん** · 2018/06/27(水) 02:41:49.66

Rustだけ覚えればいい時代はまだ来ない
C/C++の知識皆無では

**デフォルトの名無しさん** · 2018/06/27(水) 09:44:32.66

オライリーの訳本が8月に出るのね

**デフォルトの名無しさん** · 2018/06/27(水) 10:05:32.17

本が出る頃には内容が古くなってるやつだろ

**デフォルトの名無しさん** · 2018/06/27(水) 14:44:22.85

>>716
英語で出る分には多目に見たが、日本語で出るんなら出版社の不買運動だな
どこが訳すか知らんけど

**デフォルトの名無しさん** · 2018/06/27(水) 17:59:19.20

不買運動何人参加するの？大規模にやろうぜ

**デフォルトの名無しさん** · 2018/06/27(水) 18:21:05.70

英語なら多目に見るｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/06/27(水) 18:35:05.31

>>712
ありがとう、そういうオチか。&で正常に動かないのも納得です
暗黙の変換って便利ですけど理解が浅いとハマる元だったりしますよね
不適切な入力を入れると自分が書いたつもりのコードとは無関係っぽいエラーを出して？？？になったり

>>713
#[link(name = "・・・")]
extern {
　fn func1(x: *const u8) -> u32;
　fn func2(y: u32);
　fn func3(z: &u32);
}
fn main() {
　unsafe {
　　let mut a = func1("foo.dat".as_ptr()); //C側でメモリが確保されアドレスが帰ってくる
　　func2(a); //アドレスを使って処理
　　func3(&a); //確保したメモリを解放
　}
}
これは動きます。u32をstd::os::raw::c_voidにするとfunc2のaで
>use of moved value: `a`
>= note: move occurs because `a` has type `std::os::raw::c_void`, which does not implement the `Copy` trait
そんな事を言われても困る・・・ついでにenumなので格納されているアドレス値の確認も面倒
usizeなら問題ない。ドキュメントが正しいならusizeはポインタのサイズらしいしこっちの方が楽かも

**デフォルトの名無しさん** · 2018/06/27(水) 19:40:13.19

訳本情報どこにある？

**デフォルトの名無しさん** · 2018/06/27(水) 19:41:49.80

てかrust覚えるなら普通にc++のスマポくらいは知っとかんとわけわからんだろ。

**デフォルトの名無しさん** · 2018/06/27(水) 19:45:28.45

今日発売の新しいrust本買った人いるのかな
評判良ければKindle出た頃に買おうかなと思うけど

**デフォルトの名無しさん** · 2018/06/27(水) 20:11:21.04

貧乏なのでPacktの糞本を$10セールの時しか買えない

**デフォルトの名無しさん** · 2018/06/27(水) 20:16:03.57

訳本amazonにあったわ
早速予約した

**デフォルトの名無しさん** · 2018/06/27(水) 20:16:12.37

オライリーの本って、オンラインに無料であるやつとおなじやなかったん？

**デフォルトの名無しさん** · 2018/06/27(水) 21:01:38.86

>>727
オライリーの原著は去年12月に発売、今年8月に訳本

今日発売された英語の本は公式ドキュメント(第2版)の印刷版
版元はno starch press

**デフォルトの名無しさん** · 2018/06/28(木) 01:06:21.38

>>721
他の人も似たようなこと書いてるけど、Cの配列は結局はポインタに過ぎないから
C側がポインタを求めれば、当然Rust側でもポインタを渡す

あと>>711の
>同じコードでも型によって所有権の移動のしかたが違うのか
は半分正解で半分不正解
正確には、型によって違うんじゃなくて、Copyトレイトをimplしてるか否かで違う
u32はCopyトレイトをimplしてるから所有権はmoveじゃなくてcopyされる
c_voidはCopyトレイトをimplしてないから所有権をmoveしようとする

The Bookちゃんと読んだ？読んでないなら一度きちんと通読することを勧める

**デフォルトの名無しさん** · 2018/06/28(木) 06:00:08.46

rustやるのにあったほうがいい前提知識ってどれくらい？
c++とhaskellがまともに出来ないときつい？

**デフォルトの名無しさん** · 2018/06/28(木) 06:30:25.53

そんなわけないだろw
どっちかてと根気が必要だ

**デフォルトの名無しさん** · 2018/06/28(木) 07:54:11.40

いや最低限c++のコンストラクタ、デストラクタの動くタイミングくらいは知っとかないと無理だろ。

**デフォルトの名無しさん** · 2018/06/28(木) 08:12:22.16

>>729
一応deriveでCopy(とClone)を実装すればいいらしいと言うところまでは確認しているのですが
１．std::os::raw::c_voidへ追加で実装できるのか未確認(できたとしてもモンキーパッチになってしまう)
２．別名の型を新規に作る(usizeもしくはusizeへのエイリアスに対するメリットが思いつかない)
なもんで問題なさそうならusizeで良いかなと・・・
というかCのライブラリを使うと>>721みたいなケースは良くあると思うけど他の人はどうしているんだろ
libcのc_voidもlib.rsを見るとstd::os::raw::c_voidと同じみたいだし同様の現象が起きそうです
ググると引数はc_voidを使って戻り値はusizeを使っているようなコードも出てくるしusizeが正攻法なのか？

ちなみにこのコードだとusizeを使ってもmutが不要の警告が出るんですよね。これもそんな事を言われても
困るのですが

**デフォルトの名無しさん** · 2018/06/28(木) 08:55:27.92

>>733
Cで確保したポインタ（特に○○ハンドルみたいなリソース）は普通はopaque structで受けると思う。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html#%E3%82%AA%E3%83%9A%E3%83%BC%E3%82%AF%E6%A7%8B%E9%80%A0%E4%BD%93%E3%81%AE%E8%A1%A8%E7%8F%BE

どちらかというと、func2の引数が参照渡しでなくて値渡しなのが問題では。
見た感じfunc2では借用して呼び出し後に返してもらえばいいっぽいけど。

**デフォルトの名無しさん** · 2018/06/28(木) 10:18:12.24

>>732
えーなんで？rust書いてる人の大半は知らないでしょ

**デフォルトの名無しさん** · 2018/06/28(木) 10:38:48.43

こりゃC++まだ覚えてない人はrustなんか勉強してる場合じゃないねｗ

**デフォルトの名無しさん** · 2018/06/28(木) 12:56:07.56

c++といってもRAIIとスマートポインタくらいで良いのでは
知らなくてもtrplなど読めばなんとかなるとは思うが
代数的データ型なども同様

あとは用途次第だけどFFIやるならCのメモリレイアウトくらいは押さえておいた方がよい

**デフォルトの名無しさん** · 2018/06/28(木) 13:32:58.62

そんないい加減なことでいいのだろうか？
ちゃんとC/C++一から十まできちんと理解した方がよいのでは？
それからじゃないとそこがいい加減でRustなんて本当に使えるようになったと言える？

**デフォルトの名無しさん** · 2018/06/28(木) 14:08:04.32

C++完全に理解した人間なんて世界中に何人いるやら

**デフォルトの名無しさん** · 2018/06/28(木) 14:14:44.86

Cはともかく、C++に時間を割く必要はないじゃろ

**デフォルトの名無しさん** · 2018/06/28(木) 14:20:27.58

むしろCすら知らないほうが変な先入観とか無くて所有権とかライフタイムとか素直に理解しやすそうな気もする

**デフォルトの名無しさん** · 2018/06/28(木) 14:28:13.71

必要という理由が分からない
言語なんて使いながら覚えていくもんでしょ

**デフォルトの名無しさん** · 2018/06/28(木) 15:28:41.63

>>738
RustはC/C++分かってないと書けない
→C/C++を分かるまでやる
→C/C++がわかってしまえばそもそもRustなんて不要だと気づく
→Rustを捨てる

**デフォルトの名無しさん** · 2018/06/28(木) 16:07:41.79

>>730
確かにC++とHaskellが出来きればRustの習得にはそれほど苦労しないだろうとは思う
ただ、理解できるまでにかかる時間量の問題であって、それがないとキツイってわけじゃない
むしろ、Rustの学習するためにC++とHaskellを先に学習するとか時間の無駄
The Bookが懇切丁寧に解説してくれるので前提知識はなくても全く問題ないと思う
ただし、Goみたいな言語と違ってサンプルコード読めばある程度理解できて
何となくで書けてしまうような言語ではないのでThe Bookの熟読は必須
それと、FFIする場合はある程度のCの知識は必要だよ

**デフォルトの名無しさん** · 2018/06/28(木) 16:49:45.85

FFIしたいけどCは知らん、とかレアケースだから
そんな心配はせんでいい

**デフォルトの名無しさん** · 2018/06/28(木) 16:53:35.27

別にRustは大して関数型言語じゃないし、Rustのために他の関数型言語から、っていうのは本末転倒すぎるな

**デフォルトの名無しさん** · 2018/06/28(木) 16:59:30.65

全然モナドってないし、関数型言語フレーバーぐらいでしょ

**デフォルトの名無しさん** · 2018/06/28(木) 17:13:53.31

C++は速いがコーディングストレスで禿げる
Rustで若干のパフォーマンスを犠牲にしてでも、いかに毛髪を守れるかがテーマ

**デフォルトの名無しさん** · 2018/06/28(木) 17:18:23.47

>>748
C++程度で禿げてたらRustのコンパイル通らん

Rustのコンパイル通せるならC++でやる方がよいコード書ける

つまりRustは実用にならん。C++er養成ギプスって話ならわかる

**デフォルトの名無しさん** · 2018/06/28(木) 17:41:56.51

結論：やっぱりC++からしっかりやったほうがよい

**デフォルトの名無しさん** · 2018/06/28(木) 17:46:58.11

>>750
違う違う、そもそもRustは不要って結論な

C++勉強してC++そのまま使い続ければいい

**デフォルトの名無しさん** · 2018/06/28(木) 17:47:09.81

C++98
C++03
C++TR1
C++11
C++14
C++17
C++20
C++23
C++26
C++29
C++32
C++35
C++38