Rust Part6

**デフォルトの名無しさん** · 2018/07/28(土) 03:04:38.63

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

**デフォルトの名無しさん** · 2018/08/23(木) 23:27:32.87

交換を一回しかしない配列の回転の応用だからJon BentleyのProgramming Pearlsだな。

**デフォルトの名無しさん** · 2018/08/24(金) 00:58:26.59

>>168
へー、ピアソンから出てた『珠玉のプログラミング』か
読んでみたい

**デフォルトの名無しさん** · 2018/08/24(金) 12:20:35.42

>>169
つまらんよ

**デフォルトの名無しさん** · 2018/08/25(土) 11:49:09.72

古典ですな。
今読んでもそんな悪くない本だと思う。

**デフォルトの名無しさん** · 2018/08/26(日) 17:59:52.65

rustfmt-nightlyがビルドできないお(´・ω・`)

**デフォルトの名無しさん** · 2018/08/26(日) 23:46:50.01

古めのnightlyじゃないと無理

**デフォルトの名無しさん** · 2018/08/27(月) 17:35:35.62

PR出ててもうマージされてた(｀・ω・´)

**デフォルトの名無しさん** · 2018/09/01(土) 01:39:37.63

VSCodeでRust Tool Missingと出てたからクリックしたらエラーたくさん出た。
ググったらNightlyのコンパイラじゃないとRacer(レイサーってのがRust Toolのこと？)は入れられないと
あったから。とりあえずRust Nightlyを入れた。
その後、また同じように入れようとしてみる。
cargo install racer && cargo install rustfmt && cargo install rustsym Updating registry `https://github.com/rust-lang/crates.io-index`

ダメだった！エラーが5個くらい出る。
どうすれば良いの？

**デフォルトの名無しさん** · 2018/09/01(土) 11:07:28.41

>>175
IntelliJを入れる

**デフォルトの名無しさん** · 2018/09/01(土) 22:51:12.01

>>175
rust関係ないからcodeスレへ。アドオン何使ってるかもちゃんと書けよ。

**デフォルトの名無しさん** · 2018/09/02(日) 05:13:21.00

VSCodeって言っちゃったのがまずかった
VSCodeのターミナル（WSLのzsh）で出たエラーだから、MacでもLinuxでも、このエラー起こると思う！
最近Rustインストールした人で、同じエラー出ている人いないかな？
GithubのRacerに書かれてある方法で試してみる・・

**デフォルトの名無しさん** · 2018/09/02(日) 08:10:44.09

エラーを書かずに同じエラーとわ

**デフォルトの名無しさん** · 2018/09/03(月) 05:33:11.38

これはすごい

https://github.com/EbTech/rust-algorithms

**デフォルトの名無しさん** · 2018/09/03(月) 23:57:51.98

Rustで使いやすいGUIツールキットってどんなのがあるんだろうな
マルチプラットフォームかつネイティブでそこそこのパフォーマンスを得られるのが良い
wxWidgetsは有名だけどwxRustは3年放置されている。使えるのかな

**デフォルトの名無しさん** · 2018/09/04(火) 00:37:25.68

良い塩梅に発酵したときが食べ頃

**デフォルトの名無しさん** · 2018/09/04(火) 02:01:24.43

>>181
gtk-rsは?
前にちょっと触ってみただけだから実用レベルかは知らんが
今でも積極的にコミットされてるから期待はできそう

純Rust製ならPistonが作ってるconrodかな？winitとgliumをベースにしてるっぽい？
こっちは使ったことすら無いんで全く分からん
純Rust製に惹かれたが、なかなか時間が作れなくて放置中…
因みにwinitはイベント管理用でgliumはOpenGLのクレートね

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

>>183
ggr-ksに見えた

**デフォルトの名無しさん** · 2018/09/04(火) 09:10:47.26

>>178
GithubのRacerに書いてあるとおりにやったらいけた
Rust Nightlyを入れただけではダメで
rustup toolchain add nightly
cargo +nightly install racer
でいけた。Multirustという機能があるからNightlyを使いたければ毎回指定するということを初めて知った

**デフォルトの名無しさん** · 2018/09/04(火) 10:31:00.23

>>184
+1

**デフォルトの名無しさん** · 2018/09/04(火) 21:01:57.03

>>184
ワロタ

**デフォルトの名無しさん** · 2018/09/05(水) 00:23:07.06

rlsじゃなくてracer使うのか

**デフォルトの名無しさん** · 2018/09/05(水) 03:15:12.05

RLSだけでいいの？それならRLSでいきたい
でもNightlyをデフォルトに設定したらRLSがスタートできなかった

**デフォルトの名無しさん** · 2018/09/05(水) 03:15:35.14

Rusty Codeっていうのにした

**181** · 2018/09/05(水) 07:39:35.54

>>183
ありがとう。GTK+が無難ですかね。gtk-rsを試してみます

純Rustは確かに惹かれますがこれってネイティブなのだろうか・・・

**デフォルトの名無しさん** · 2018/09/05(水) 07:46:50.58

Intellij Rustの作者が作ってるlibsyntax2がLSPを提供するようになってる
https://github.com/matklad/libsyntax2/tree/master/crates/server

racerの代わりになる日が来るだろうか？
IDE機能の提供はコンパイラでやるのが一番いいんだろうけど

**デフォルトの名無しさん** · 2018/09/05(水) 07:48:44.63

>>183
>>191
gtkってマルチプラットフォームと言えるの？
Linuxでしかまともに動かないイメージ
まあWindowsでは最低限は動くのかもしれんけどmacOSではダメダメでしょう

**181** · 2018/09/05(水) 08:06:31.33

>>193
そうなの？
まぁ今回の用途はWindowsとLinux/*BSDで動けばよし
たしかGIMPはGTKだったはず

**デフォルトの名無しさん** · 2018/09/05(水) 08:14:42.53

え、エレクトロン

**デフォルトの名無しさん** · 2018/09/05(水) 09:01:55.04

そもそもgimpを作るためにgtk作ったわけで…

**デフォルトの名無しさん** · 2018/09/05(水) 11:38:43.13

GTKは糞

**デフォルトの名無しさん** · 2018/09/05(水) 16:19:07.91

マイナー言語のGUIにはGtkバインディングぐらいしかないのが現実

**181** · 2018/09/05(水) 18:50:23.45

GTKのバインディングがあるならTkのバインディングも・・・と思ったら見あたらない？
Tkも一応ネイティブだったはず。機能面はぱっとしないが今回の用途には足りるかも

>>195
その手のWeb技術ベースのってアプリケーション側からウィジェットを更新する術に乏しい
印象があるけどそうでもないのかな

**デフォルトの名無しさん** · 2018/09/05(水) 20:07:45.33

ウィジェットってこの文脈だとどいう意味？

**デフォルトの名無しさん** · 2018/09/05(水) 21:04:58.50

OS(フレームワーク)ネイティブのGUIコンポーネントって意味だと思う。
というか、こっちの意味での利用のほうがコンピュータ的には一般的だったかと。

**デフォルトの名無しさん** · 2018/09/05(水) 22:08:13.79

Windows向けRustのリンカがlldになるのはいつかな

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

GIMPはMotif・・・。うん。わかってるよ。

>>191
msvcツールチェーンでビルド面倒くさいから頑張れ。

**デフォルトの名無しさん** · 2018/09/08(土) 20:22:07.67

何かやるのに言語からつくっちゃえって、どうなんだろ。

**デフォルトの名無しさん** · 2018/09/08(土) 21:39:35.66

なにかやるわけでもないのに言語だけ作るほうが珍しい気もするぞ。
で、どの言語のこと言ってるの？

**デフォルトの名無しさん** · 2018/09/08(土) 21:50:01.66

>>205
Rust

**デフォルトの名無しさん** · 2018/09/08(土) 22:35:38.88

Cの事じゃないのか。

**デフォルトの名無しさん** · 2018/09/09(日) 17:19:35.86

GUIといえばlibuiはどうだろう？

というかRustでGUIって面倒くさそう

**デフォルトの名無しさん** · 2018/09/09(日) 18:05:38.77

面倒臭いと思うよ

GUIだと大抵はイベントハンドラ多用する場合が多いから
Rustだと多分クロージャを渡すことになって
キャプチャする変数の所有権が絡んできて面倒なことになる

可能な限りデータを全て不変にして参照カウンタ使うのが一番楽そう
誰かもっと良い方法知ってたら教えて

**デフォルトの名無しさん** · 2018/09/09(日) 18:56:16.25

キャプチャ必要かな。しなけりゃいいんじゃね？
RxやReduxみたいなのならRustでもできるような気がするが。

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

wasm来たらhtmlでいいじゃん

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

>>209
相互/循環参照があり得るから参照カウンタじゃ無理だよ。
メモリ管理面の煩わしさを考慮するならjavaみたい
にイベントハンドラをtraitにしてユーザーデータ自身に
実装させればいいけど、今ではこのアプローチ自体が煩わしいと思う。

あと参照カウンタの場合一度に多すぎる解放処理が発生して
UIがもたつく可能性があるね。
トレーシングGCなら必要ないなら遅らせるからこういう事は起きない。

rustでトレーシングGC使う場合rootingはプログラマが行う必要があるから
自前でメモリ管理するのと同じだし、それ以外にGUIのシーングラフ自体にトレーシングGCがいるね。
ffiで既存のgui利用してrustからはデータ渡すだけにするのが簡単だと思う。

**デフォルトの名無しさん** · 2018/09/10(月) 14:20:14.67

yewとrelmが気になる

**デフォルトの名無しさん** · 2018/09/10(月) 19:39:57.20

ちなみにWEB開発のサーバーサイドでRustって現実味あるの？
Goがたまに使われてるから、Rustにもチャンスあるのかなと思ったけど

**デフォルトの名無しさん** · 2018/09/10(月) 20:02:06.79

君が作ればチャンスは無限大

**デフォルトの名無しさん** · 2018/09/10(月) 20:44:31.47

Goは手軽さと性能のバランスが丁度いいから

**デフォルトの名無しさん** · 2018/09/10(月) 21:33:40.66

現実味の程度による

**デフォルトの名無しさん** · 2018/09/10(月) 21:58:39.88

予算と工数的に競技志向のFPSのバトルサーバならRustも現実的だけどマッチングサーバなら現実的じゃないとかありそうよね

**デフォルトの名無しさん** · 2018/09/10(月) 22:17:46.90

現実になるかどうかは言語じゃなくでプログラマ次第でしょ
俺は現実に使ってるけど

**デフォルトの名無しさん** · 2018/09/10(月) 23:11:54.52

それ言い出したらアセンブラでもcでもプログラマ次第だわな。

**デフォルトの名無しさん** · 2018/09/10(月) 23:16:12.14

言語の決定権が

**デフォルトの名無しさん** · 2018/09/11(火) 00:22:51.64

適材適所で言語を選べるか？って事でしょ

**デフォルトの名無しさん** · 2018/09/11(火) 00:59:46.27

Rubyでいう

v = [1, 2, 3].map(){|e| e.to_f }

をrustで書きたくて、以下のように書いたんだけど、

let v = [1, 2, 3].iter().map(|x| *x as f32).collect();

vの型が推論できなくてコンパイルが通らない。助けて！

**デフォルトの名無しさん** · 2018/09/11(火) 08:51:05.30

let v = [1, 2, 3].iter().map(|x| *x as f32).collect::<Vec<_>>();
とか
let v:Vec<_> = [1, 2, 3].iter().map(|x| *x as f32).collect();

collectをジェネリックにする代わりに型推論できなくするのは良いアイデアだったのか

**デフォルトの名無しさん** · 2018/09/11(火) 22:15:57.71

rust的にはturbofish使うもんだけど型注釈をよく見かけるね。

**デフォルトの名無しさん** · 2018/09/11(火) 22:25:10.48

>>224
参考になりました！
これどちらも vec<f32> になるんですよね？
ヒープ確保じゃなくてスタックの配列への変換は無理ですかね？

**デフォルトの名無しさん** · 2018/09/11(火) 23:40:31.29

>>226
ttps://stackoverflow.com/questions/26441916/dynamic-array-allocation-on-stack-in-c
Cでも駄目で、C++ならオッケーだったけな。Rustはできなかった。

もしできるようになっても、その関数の下にどれくらいコールスタックが積まれているのか、
この関数の上にどれくらい呼び出しが控えているかを熟慮しないとすぐstack overflow起こすんで、よっぽどクリティカルでなければやらんほうがええんじゃないか

**デフォルトの名無しさん** · 2018/09/12(水) 00:27:32.15

>>227
逆やー。
Cではオプション扱い、C++では不可

**デフォルトの名無しさん** · 2018/09/12(水) 01:54:03.48

>>228
追いかけきれてるわけではないけど、
allocaについても言及されているrfc#1909の第一段階が、8/19にマージされてるっぽい。

近い将来にallocaが完全サポートされる感じなんですかねぇ？

**226** · 2018/09/12(水) 03:38:36.44

んーん、なるほど。
Rustには現状、スタックを伸長するalloca相当がないから件の場合、固定配列を求める事は出来ないってことですかね。

**デフォルトの名無しさん** · 2018/09/12(水) 19:11:41.82

cloneていつ付けてる？
不用意にcloneするのを避けたくて最小限にしていたんだけどテスト書くとき辛い
derefでcloneされるのはcopyついているやつだけ？

**デフォルトの名無しさん** · 2018/09/12(水) 20:48:13.21

テストの時辛いってのは
↓のアトリビュートじゃ解決できないの？

#[cfg_attr(test, derive(Clone))]

**デフォルトの名無しさん** · 2018/09/12(水) 20:56:43.30

omg
それでいきますわ！ありがとう！

**デフォルトの名無しさん** · 2018/09/12(水) 22:49:53.02

>>224
> 型推論できなくする
できるよ。
rust by exampleを例にすると
ttps://play.rust-lang.org/?gist=3cbef33631cbed2a2f0dce6439da4942&version=stable&mode=debug&edition=2015

上記の`i32::from_str`や`<i32 as std::str::FromStr>::from_str`のi32を見て推論してる。
ただのstd::str::FromStrでは推論できないってエラーになる。

**デフォルトの名無しさん** · 2018/09/13(木) 18:02:19.58

低コストで探索できるらしいB+木ってなんぞや。ググるといっぱい出てくるがどいつもこいつも抽象的
「で、それがどう活用できるのか？」と言う疑問が解決しない
もちろんRustでコーディングする予定

**デフォルトの名無しさん** · 2018/09/13(木) 20:57:57.27

>>235
てけとーにググってきたやつ
https://christina04.hatenablog.com/entry/2017/05/17/190000

で、B+ツリーはリーフノード間にリンクがある構造。

リンクがあると何が嬉しいかというと、
データベースで値の範囲で検索する際、先頭が見つかればリンクをたどってレコードが抽出できる。一例として。

**デフォルトの名無しさん** · 2018/09/13(木) 21:29:20.76

B木とそのバリエーションは、ディスクのように一定の大きさを持ったブロック単位で読み書きする
記憶装置上に置くのに適した木構造。
そういう使い方をしないんだったら効率が悪い木構造でしかない。

**235** · 2018/09/13(木) 22:11:03.43

ありがとう

>>236
そのような説明はいっぱい出てくるんですがそれを実用へ落とし込むのに必要なピースがわかりません
データベースやファイルシステムを作れる人ならその説明で十分なのだろうと思いますが
自分はそのような経験がないので「ファイルシステム」や「B+木」等のキーワードからその不足分にたどり
着けないでいます

>>237
まさしくその用途を考えています
・大容量のボリュームを扱う (数百GB～TB)
・ファイルをたくさん入れる (万～)
・ファイルの中身へのアクセスコストが低い
・充填率に優れる
・フラッシュメモリベースのメディアで使用する
みたいなファイルシステムを作れないかなーと。個人が扱うファイルシステムだとFAT32あたりがよく使われると思いますが
そろそろ最大ボリュームの上限を突破しそうだし、ディレクトリの探索が容易じゃないし(特にLFN使用時)
充填率も良いとは言えないしと、いろいろ課題が多いのでいっそ俺ファイルシステムを作ろうかと

**デフォルトの名無しさん** · 2018/09/13(木) 22:24:39.91

B木の実装は、共立出版の「ファイル構造」という本が詳細に分かりやすく説明されていてよかった。
残念ながらもう絶版らしいが。

**デフォルトの名無しさん** · 2018/09/13(木) 23:23:13.30

bit別冊は大部処分したけど似た本はもう無いと判断して捨てなかった一冊

今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう

**デフォルトの名無しさん** · 2018/09/14(金) 00:34:41.33

>>239
英語版ならまだあるようだし、pdfでも見れるな。

**デフォルトの名無しさん** · 2018/09/14(金) 11:13:17.17

1.29.0来たね

**デフォルトの名無しさん** · 2018/09/14(金) 17:04:14.02

来たー

**235** · 2018/09/14(金) 22:55:36.33

ありがとう

>>239-241
尼のマケプレの値段ヤバイですね。原書？のPDFは入手できたので見てみます

>今ファイルシステムの勉強しようと思ったらLinuxや*BSDのソースコードよむぐらいしか無さそう
うへぇ。ファイルシステムドライバの仕様がどうなっているのかを理解した上で、ジャーナリングや
スナップショットなどの付加機能を分離しつつ読む必要がありそう
オープンソースといえどもこの辺の情報はお世辞にも豊富ではないのもつらいところです

**デフォルトの名無しさん** · 2018/09/14(金) 23:38:15.74

まあ読むならext3ぐらいからじゃないかな？
losetupやbrdで小規模なデバイス上にmkfsしてhexdump使って媒体構造見るとか
system tapやblktraceで処理やアクセス箇所見るとか
crashでカレントプロセス覗くとか
printk仕込んで処理フロー確認するとか

昔勉強したけど他に何やったかもう覚えてないや

**デフォルトの名無しさん** · 2018/09/14(金) 23:52:28.71

まさかこんなところで共立出版というガチな名前を聞くとは思わなかった。
ねねっちがいるのかこのスレには。最近Rと統計ばっかだよねあそこ。

ところでファイル構造の古書店の通販見つけたけど長すぎてurl貼れない。

**デフォルトの名無しさん** · 2018/09/15(土) 00:11:05.25

共立出版って大学数学やら物理やらの教科書としてはまあまあ使われてるんじゃない？

**デフォルトの名無しさん** · 2018/09/15(土) 00:35:58.43

テキストとワインバーグ本とすべての人のためのJavaプログラミングのところだね。

**デフォルトの名無しさん** · 2018/09/15(土) 03:08:49.57

>>247
共立出版で情報系の教科書としては次の２つのシリーズは好著が多い良いシリーズだ
・情報数学講座
・アルゴリズムサイエンスシリーズ

あと、共立出版でプログラミングの本と言えばとっくに時代遅れになっているが
カーニハン＆リッチーの『プログラミング言語Ｃ』は外せない
恐らくこの訳書は初版と第２版とを合わせると、共立出版の情報系の書籍の中で圧倒的な部数を稼いだはず

それ以外にもカーニハン本の翻訳を日本で最初に出したのは共立出版だ
『プログラム書法』、『ソフトウェア作法』、『プログラミング作法』とね

今の若い人たちは存在していたことすら知らないだろうけど、共立出版は bit という月刊誌を出していた
これはB5版のころはソフトウェア技術者にとっての教養雑誌で、理論的な話題の記事も載せていたし
チューリング賞の受賞記念講演の翻訳も毎年載せていた

上に名前が出てた『ファイル構造』は元は bit誌の別冊か臨時増刊として出版されたものが
需要が多かったので増刷を機に単行本化されたものだ

だが部数が徐々に減ってきたのをテコ入れとばかりに編集長が変わって、版型をB5版からA4版に変え
記事も教養的なのから実用的なもの中心に変えてしまったら、昔からの読者の多くが離れて
急激に廃刊（建前上は休刊）に追い込まれた

bit誌の廃刊以降、共立出版の情報科学系の書籍の出版点数はかなり減少したような印象がある
現在の共立出版は数学書の出版に特に力を入れているみたいだね

**デフォルトの名無しさん** · 2018/09/15(土) 08:36:15.98

bit本誌、いまだに捨てられなくて本棚1段占領している。
ユニマガは引っ越しの時に全部捨てちゃったが。

**デフォルトの名無しさん** · 2018/09/16(日) 01:33:00.78

rustの複数行文字列って空白消されちゃうの？

https://stackoverflow.com/questions/29483365/what-is-the-syntax-for-a-multiline-string-literal

**デフォルトの名無しさん** · 2018/09/17(月) 00:20:05.94

>>251
そんな話してない

**デフォルトの名無しさん** · 2018/09/17(月) 20:15:25.23

ここで質問しても許されるのでしょうか？ダメそうなら、申し訳ないです。
S式を使って遊ぼうとしてRustで見様見真似で書こうとしたんですが、コンパイルすらできません…。
ヘッタクソなコードで恐縮ですが、以下の52行目で「`s` does not live long enough」と怒られます。
https://pastebin.com/94ZPh2dL

まず、's'がスタックに確保されていて、parseから返った先で（つまり、スタックが解放されたあとで）
sを使う可能性があるから駄目だと言っているという認識ですが、正しいのでしょうか。
また、どのように対処すればよろしいでしょうか。

たぶん、根本的なところから理解できていないのだと思いますが、ご教授お願いいたします。

**デフォルトの名無しさん** · 2018/09/17(月) 22:18:18.83

Nodeがsへの参照を持っているのにsが解放されちゃうからじゃないかなあ

**デフォルトの名無しさん** · 2018/09/17(月) 22:22:00.90

みたかんじsymbolを&strじゃなくてStringにしてsをmoveさせればよいと思うけど

**デフォルトの名無しさん** · 2018/09/17(月) 23:12:20.37

>>253
>sを使う可能性があるから駄目だと言っているという認識ですが、正しいのでしょうか。
合ってる。
sはparse関数の中で確保されてる。
そのsの借用(as_strしてるから借用することになる)をparse関数の外に出そうとしてるから
sの借用がsより長命になるのでrustではエラーになる。
sはparse関数の呼び出しが終わると解放されるからこれはダングリングポインタだよね。

>また、どのように対処すればよろしいでしょうか。
この場合、Node<'a>は文字列のsymbolフィールドを所有する側だから&strじゃなくてStringにすればいい。
apiの設計の時点でownd valueとborrowed valueを意識すればいい。
あとleftとrightが借用になってて、これはこれで設計的に間違いじゃないんだけど問題出るかも。

**デフォルトの名無しさん** · 2018/09/18(火) 22:40:54.20

コピーのコストが嫌だからとりあえず参照にしとこう、の精神は早々に破綻するよね
似たようなパーサ書いてて同じようにコンパイラにボロクソに言われたことがある

それ以来、このデータは誰が持っているべきなのか？を意識して書くようにして、
コンパイラに怒られたら「何か抜け道がきっとある」って思うようになれたし、リファレンス探すと大体解決するようになったよ

**デフォルトの名無しさん** · 2018/09/19(水) 11:41:33.60

The Creator

**デフォルトの名無しさん** · 2018/09/20(木) 01:17:05.56

皆さん、お返事ありがとうございます。
とても参考になります。
もう少し、頑張ってみます。

# ピンポイントで質問できるのは、本当にありがたいです。

**235** · 2018/09/21(金) 16:03:14.74

ありがとう。File Structuresを眺めていますが英語なのであまりはかどらないです
二分木およびその発展系の説明は十中八九キーとして数字が使われているけど
ファイルシステムの入力はファイルパスであり可変長の文字列。この部分はどう埋めればいいのだろうか
ハッシュテーブルでも使えという話なのか？しかしそれならハッシュテーブルを使ってファイルのメタデータを
探索してしまった方が早そうだけどそういう問題ではないんだろうな

**デフォルトの名無しさん** · 2018/09/21(金) 21:05:15.62

最近でたオライリーの本って
Rust公式ドキュメントの2018でもSecond Editionでもなく
明らかに初版が元になってるよね時期的に

**デフォルトの名無しさん** · 2018/09/21(金) 21:54:00.31

>>260
ブロック管理に使うからキーは数字で問題ない

**デフォルトの名無しさん** · 2018/09/22(土) 11:42:21.78

>>261
つまりオライリーの本は地雷？

**デフォルトの名無しさん** · 2018/09/22(土) 12:08:43.13

Second Edition出てるんだっけ？
ググってみても First Edition, Third Release が 2018-6-22 としか見つからないんだけど。

**デフォルトの名無しさん** · 2018/09/22(土) 12:28:30.62

目次の構成はSecondに近いか？

サンプルプログラムの発行時期は10ヶ月前だからそんなに古くはないのかもな

オライリー原書
http://shop.oreilly.com/product/0636920040385.do
公式ドキュメント日本語訳
https://doc.rust-jp.rs/

ちな最新の2018版ってGithubみた感じリアルタイムに更新されてるっぽいな
https://doc.rust-lang.org/book/index.html

**235** · 2018/09/22(土) 12:29:23.44

>>262
ありがとう。あれ？自分が勘違いしているのかな
B+木やB*木をファイルのメタデータの探索に使っていると思っていたけどそうではなくデータを格納しているブロックの探索に使っているということ？

**デフォルトの名無しさん** · 2018/09/22(土) 13:25:51.18

翻訳元のISBNと原書3rd releaseのISBNが違うことは確認したけど、たぶんこのerrataに載ってる修正くらいだろう。
https://www.oreilly.com/catalog/errata.csp?isbn=9781491927212

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

>>261,265
オライリーのカニ本の初版一版は1.17.0。TRPLの日本語訳は相当古い。
2018はverでいうと1.31.0に相当する。いまのstabuleは1.29.0。
それにTRPLでもまだ文書化されてない機能あるしな。
非初学者向けならStep Ahead with Rustもある。