TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
すべての言語を判定する計算機構
【Lua】組み込み系言語総合 その7【Squirrel】
monazilla Part 6
今までに見たソースコードで一番感動したのは deux
Io Language
VBで作られた有名なアプリって何？
次世代が造った言語 blawn
ネットワークプログラミング雑談
わんくま死亡か？
0から始める2chブラウザfor超漢字 "2ch de BTRON"

プログラミング言語 Rust 4【ﾜｯﾁｮｲ】


1 ：2017/12/24 〜 最終レス ：2018/08/05
Mozilla発のプログラミング言語「Rust」のスレです

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

■ワッチョイ
スレ建て時、一行目に
!extend:on:vvvvv:1000:512
を入れること

■派生元スレ
プログラミング言語 Rust 4
https://mevius.2ch.sc/test/read.cgi/tech/1507970294/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2 ：
>>1乙

3 ：
皆知ってるかもしれないけど、https://github.com/rust-unofficial/too-many-lists は良いね
公式のbookには無かった「自分で書いてみた時にハマる箇所と解決法」が丁寧に書いてあるんで、
特にプログラミング経験者でRust初学者には自信を持ってお勧めできる

4 ：
>>3
しらんかた
webのやつはみれなくなってるね

5 ：
製本？したものを上げてるサーバーが結構長いこと落ちてるね
1. cargo install mdbookでmdbookをインストール
2. git cloneで>>3のリポジトリを取ってくる
3. 取ってきたディレクトリでmdbookを実行
4. book/ にhtmlで製本されたものが出力される
ので、是非読んで欲しい。may not live longとかcannot moveとかで怒られまくってる人なら共感しながら読めるはず

6 ：
アンチスレのほうが伸びてるやん
枯れ木も山の賑わい

7 ：
>>3
http://cglab.ca/%7Eabeinges/blah/too-many-lists/book/
読めるようになってるな。

8 ：
教えてください

VecのDisplay::fmtをカスタマイズしたくて
type MyType<T> = (Vec<T>);

impl std::fmt::Display for MyType {

}

9 ：
申し訳ありません　途中送信してしまいました
コードをplaygroundに移しました

https://play.rust-lang.org/?gist=10bd65d0bfaf8b5117399b18bd8eb0d2

VecのDisplay::fmtをカスタマイズしたくて上の様にMyTypeを作成したのですが
Vecのメソッド委譲するためのコードを手書きする作業が煩雑になって困っています

何か上手い回避策は無いでしょうか?

10 ：
>>9
私も初心者で分からないですが最終的に何がしたいんでしょうか？

11 ：
>>10
レスどうもです
Vec（他標準 struct）のDisplay::fmt出力をカスタマイズしたいんです　例えば
・要素数が多い場合、最初の数個を出力して残りを省略するとか
・要素の出力が長くなる場合、適当なところで改行するとか
・インデントを受け付けてネストしてる場合は改行とインデントで整形するとか

その上でVecのインターフェースをそのまま使いたいんですが
>>9のように新規の構造体を作る場合　手書きで委譲せねばならず
どうにか上手く出来ないもんかな……と

12 ：
>>11
その用途ならVecに別な名前のメソッドを直接implしちゃってそっち呼び出せばいいような気がしたんですが

println!("{}", v.my_fmt());

みたいに

13 ：
>>9 https://play.rust-lang.org/?gist=eec6671ba201493eb61891447824b92f&version=stable

DerefとDerefMutを実装するといい。
↓にあるDeref Coarcionっていうコンパイラの機能で、x: MyType<T>に対し、&xが&MyType<T>とも&Vec<T>ともみなしてくれるようになる
https://doc.rust-lang.org/book/second-edition/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods

更に追加でIntoとFromも簡単に実装できるから不自由は無くなるはず

14 ：
>>12
ごもっともです
self.0に委譲するマクロが上手く書けなかった経験があり
それに引きずられて本質を見失ってました
コードを整理していったらいけそうな感じになりました
https://play.rust-lang.org/?gist=960819f1fb1b5f9988a1c58cab2b1b9e&version=stable
ありがとうございます

>>13
ああ、なるほど
Derefは思い至ってませんでした メソッド委譲の解決になりそうで助かります
こちらもありがとうございます

15 ：
なるほど

16 ：
https://stackoverflow.com/questions/45086595/is-it-considered-a-bad-practice-to-implement-deref-for-newtypes

ぐぐったらこんな議論も。

17 ：
>>16の論旨は「MyType<T>は常にVec<T>として扱われても問題ないか？あるならDerefはおすすめしない」だと思うけど、
今回の場合はむしろMyType<T>は特別なことが無い限りVec<T>として使いたいんじゃないの？

18 ：
>>16 読みました
見覚えのあるピンク玉はrust playgroundの中の人でした

「smart_ptrぐらいの同一性がある場合にはDerefが必要だけど
strにDeref<Taget = [u8]>が無いように
Derefだとやりすぎな場合もあるからdelegate構文欲しいよね」
ってなとこでしょうか
strの例は「替わりにas_bytesがあるよ」ということかなと

strとsliceとか他のライブラリを眺めた個人的な結論としては
has_aならAsRef、is_aならBorrowをimplして受ける関数で使い易くしておくのが
Rust的な落とし所なのかなーといった印象です
AsRef, Borrow, Derefの使い分けは宣言的にプログラマの裁量に任されてる感じ

よくよく考えれば自分のコードにもas_xxx, as_xxx_mutが散見されている現状なので
Mytypeにもas_vecを書けばそれでも良かったような気がします

>>17
自分のケースの場合はそもそもMyTypeがいらなくなってしまったもので
Derefはオーバーパワーかなと思ってます
とはいえ　smart_ptrのように扱うならDerefが有用ということが
知見として学べたので　大変ありがたかったです

19 ：
>>17
このスレを読んでる人に情報共有してるだけだよ

20 ：
元スレやばいね

21 ：
オライリー届いた。
分厚すぎてわろたわ。読むの大変そう。

22 ：
dyn Traitが入ってしばらくしたらBox<Trait>はdisconになるの？

23 ：
deprecated扱いになって警告を出し次のepochで削除とかだったと思う

24 ：
impl Trait入ったらそもそもほとんど使わなくなるから気にしなくていいのか。

25 ：
使うケース減るのもそうだけどepochで機能削除する場合はソースコードの変換ツールが提供されるらしい
あと古いepochのソースはそのままコンパイルできるらしいから特に対応不要らしい
だから新しいepochにしか入っていない機能を使いたいcrateとかでなければ何もしなくても困らないはずだし
その場合でも変換ツール通せば簡単に対応できるはず

26 ：
なるほど

27 ：
2018年のロードマップのRFC出てる
https://github.com/rust-lang/rfcs/pull/2314
impl Traitついに安定化されるのか

28 ：
epoch releaseってのはどういうことなんだってばよ？

29 ：
map: BTreeMap<K,V>で、keyが無かったら挿入、あったら格納されてる値vに応じて新しい値new_vに更新するか決めるってやりたいんだけど、
let v = map.entry(key).or_insert(new_v);
if ... {
*v = new_v;
}
よりもっと綺麗な書き方ある？

30 ：
and_modify() ?

31 ：
https://webassembly.studio/

CやRustでWebAssemblyできるOnlineIDEだそうな

32 ：
Rust Never Sleeps: Community Grows, Eclipse-Based IDE Planned
https://adtmag.com/articles/2018/02/01/rust-grows.aspx

33 ：
>>31
ええやん

34 ：
>>32
eclipseはいらんなあ

35 ：
オライリー本読んだ？

36 ：
wasmってまだプリミティブすぎて使い物にならないのかと思ってたけど wasm-bindgen すげえな
もうここまでできるのか

37 ：
Rustすごい！

takahito takabayashiさんのツイート: "ファミコンのエミュレータをRust / WebAssembly で書き直した
https://twitter.com/tatakaba/status/961532612723511296

38 ：
梅手伝い

39 ：
苦労して書き直しても全然パフォーマンス上がらないのな…
ぐうの音もでないほど効果があるユースケースってなんなんだ

40 ：
アルゴリズムが変わらないならそう変わらんのじゃないか
他人のひどいコードならともかく、同じ人が小規模なプログラムを書き直す程度だと特に

C/C++からRustへ書き直して速度が上がったって話はあんま聞いたことが無い
速いネイティブライブラリを言語に組み込んでるJuliaとかなら、書き直すだけで速度上がったって話はちらほら
pythonだったらnumpy使った方が楽でいいとかも

41 ：
いやだってjavascriptだぜ？アルゴリズムの問題か？

42 ：
リリースビルドしてないとか

43 ：
結局本スレどこ？

44 ：
ここ

45 ：
c++もそうだがコンパイラに機能を詰め込むってのがそもそも筋が悪い

46 ：
>>45
どういうこと？じゃあどうすればいいの？

47 ：
asm!だよ

48 ：
>>46
ライブラリ、もしくはツールに任せる。

49 ：
>>48
やっぱりちょっと分からないな。
RustやC++のどの辺がコンパイラに機能を詰め込んでると思うの？
ライブラリorツールに任せるってのもどの辺を任せたいのかな？
話がザックリし過ぎて言いたいことがよく分からないんだが。

50 ：
プリプロセッサマクロのことかな？あとは型システムとかGCのことかな？ライブラリに任せるの意味がよくわからんが…

51 ：
C++はコンパイラの方もだけど標準ライブラリでの機能実現も相応に多くて結果ソースの記述が煩雑になっているのは既知の事実でしょう
ライブラリや実装に任せた結果APIの統一が取れなくなって結局細かな仕様策定を余儀なくされたSchemeを見ても銀の弾丸でない事は明らかだよね
それに出来る事を増やすという点においてライブラリは有用だけど変数の不変性や型システムのような制限をする事に関してはコンパイラによしなにしてもらうより他ないよ

52 ：
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

53 ：
やっとstableでrustfmtできるようになったな

54 ：
どうせ明日にはまたnightly限定になってるよ

55 ：
最近のアップデートつまんねえなあ

56 ：
>>45は言語仕様の追加、更新が気に入らないんじゃないかな
try!の代わりに?なんて以ての外だ、みたいな？それ以外に思い付かなかったけど
1.0以前に@や~を削除してライブラリにぶん投げた辺りは希望通りな気がする

基本的に電池入りじゃないRustはライブラリやマクロの代わりの言語仕様の追加じゃなく
より効率的なバイナリを吐くための言語仕様の追加が多いイメージだけどなぁ、impl Traitとか

57 ：
>>56
あー、そういうこと。?記法は確かに若干違和感あったかもな。
でも実際、あれは便利なんだよなぁ。
File::open(path)?.read_to_string(&mut buf)?みたいに繋げられるから。
try!(try!(File::open(path)).read_to_string(&mut buf))は読みづらい。
かといって、
let mut file = try!(File::open(path));
try!(file.read_to_string(&mut buf))
みたいに2行に分けるのも面倒だし、無駄なローカル変数も出来れば避けたい。
結局、あれが妥当な判断だったと思うけど。
まぁ、stableにする必要あったのか？ってところで賛否両論あるかもね。

58 ：
box キーワードは何時 stable になるんだ？

59 ：
boxキーワードはどういう時にうれしいのかがわからん

60 ：
明らかに二行に分けた方が読みやすいわけだが。
新しい機能マンセー厨ってそういう感覚の狂いについて無自覚過ぎんだよね。

61 ：
俺も違和感はあるけど、多くの人が賛意を出して採用されたんだから
>>60や俺の感覚が狂ってるんじゃね？自身の感覚の狂いって当然ながら無自覚過ぎんよ

boxは在り様の総意を取るの面倒だし、目下はBoxで運用できてるしで、いつまでもstableに来なさそう
ヒープを多用したい人には文法にあればありがたいんだろうけど、そもそもヒープが好まれんしのう

62 ：
boxっていきなりヒープにメモリ確保されるのが保証されたりするんじゃないの？
今はコンパイラ次第じゃん

63 ：
ironって今メンテされてないのか
最近のweb FWはrocketの方が人気なんかな
nightly専用だからまだ手を付けてないんだけど

64 ：
>>59
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/box-syntax-and-patterns.html
> このように書くことでパフォーマンスを犠牲にすることなく、柔軟性を確保することができます。

知らないの？

65 ：
それはInPlaceとかPlacerがあればよくてbox inはただのsyntax sugarでは

66 ：
分解のほうは新しいの？

67 ：
分解の方がよほどsyntax sugarじゃないのかいな
NightlyのInPlace, Placer使わなくても、Stableの環境でmacro使って実現出来そう

68 ：
boxって名前はBox<T>以外に使う場面で綺麗に見えない
place <- exprは代入みたい

69 ：
tokio-coreなくなるんか
一通り組み上がった後の悲しいニュース

70 ：
まじか、ちょっと辛いな
依存してるライブラリも結構あるよね

71 ：
ワッチョイなしの方アンチが暴れてる

72 ：
tokio系列のやつってtokioとかtokio-coreとかtokio-ioとかtokio-protoとか複数あってよく分からんのよね
tokio-ioのリポジトリにはtokioに移動したからもう使うなって書いてあるし
tokio-coreは移動じゃなくて廃止予定って書いてある…
tokio-protoはそのまま？tokio-timerとかtokio-serviceとかよく知らんリポジトリもあるし…
誰か各クレートの特徴(役割)と関係性を教えてくれ

73 ：
>>71
あっちは、アンチが立てたキチガイ専用スレだからいいんだよ

74 ：
コミットを追うとtokio-coreはtokioに変わったように見える
tokio-core=tokioでtokioの本体

tokio-ioはtokio-coreを使って非同期ioを実装したものだったがしゃらくせえのでtokio-coreに取り込んだのかな

tokio-protoはtokio-coreを使ってネットワークプロトコルを実装したものだったがしゃらくせえからtokio-coreに取り込んだのかな

つまり tokio = tokio-core + tokio-io + tokio-proto

か？

75 ：
[] [[[ [[ [] ][ [] [ ] [] ][]] [[[ [] }

76 ：
tokio-protoとtokio-serviceってtrait宣言が主体のインターフェース定義クレートだったような？
前者はクライアント、後者はサーバに適したインターフェースが定義されてた覚えがある
io, timer, cpupoolなんかはユーティリティ機能が実装されてたよな

統合の基準はどこかで議論されたんだろうけど、どこでやってたのかな

77 ：
【お知らせ】Packt出版より Network Programming with Rust が発売されました。

78 ：
https://play.rust-lang.org/?gist=cb511b34bc3ffbb43b8589a24156337a&version=stable
let mut foo = Foo{ a:0, b:0, c:0 };
let aaa = ["5", "432", "3"].iter().flat_map(|i| i.parse::<u32>()).collect::<Vec<_>>();
foo.a = aaa[0];
foo.b = aaa[1];
foo.c = aaa[2];

Rustってこれ以外に書き方ありませんか？
tupleでやってみるとleft-hand of expression not validと出ました

79 ：
だめなコードはらないと何がしたいか分かりません

80 ：
だよなｗ　何をしたいのか分からんよなw

81 ：
>>79
大量のフィールドに値を入れるのって
一行一行書くしかありませんか？

82 ：
一行にしたいなら
foo = Foo { a: aaa[0], b: aaa[1], c: aaa[2] };
でも良いだろ。
部分書換なら
foo = Foo { a: aaa[0], .. foo };
とかもある。

83 ：
1.24.1は何のリリース？

84 ：
朗報: ついにウェブプラットフォームでRustが速度性能トップを取る
https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext

なお、JSON操作を伴うとJavaにも劣る模様
ツリー制御が不得意すぎて笑うわ

85 ：
JSON serializationはそんなに悪くないんじゃね？tokio-minihttpで96.2%出てる。
それよりSingle QueryとMultple Queryが遅いのが問題じゃね？

86 ：
serdeでシリアライズだけするぶんにはjavaの1.4倍くらい早かったんだけどなあ(俺調べ)

87 ：
Rust book first editionからの変更知りたいんだけどバージョン差分どこでまとめられてる？

88 ：
https://github.com/rust-lang/rust/blob/master/RELEASES.md
ここか

89 ：
1.24.1てなんなんだろ

90 ：
>>83>>89
なんで自分で調べようともしないの？

Rust Languageさんのツイート: "Announcing Rust 1.24.1: we had some regressions in 1.24.0, so we've released a patch release. Please check it out! https://t.co/zrItc0qiqD"
https://twitter.com/rustlang/status/969367994072739841 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)

91 ：
Iterator::mapに渡すクロージャ内で、クロージャ内の変数への参照を持つstructを返したい時ってどう対処するのが正解ですか？
https://play.rust-lang.org/?gist=a15e0dfa10339570fef5b9225761a9f0&version=stable

92 ：
does not live longエラー関係は自分が思ってるより広い視点で見た方が解決するんじゃないかなあ
Hito.konomi_no_mochiは参照なんだから、参照元としてVec<Mochi<'a>>を保持しないと駄目なんじゃね？
=>mochiがMapになってて分かりにくい
=>とりあえずcollectさせてVec<Mochi>持ったら動いた
みたいな。
https://play.rust-lang.org/?gist=6c9947e3584f1feb5bb14f07d27aa9c7&version=stable
多分、頭の良い人ならもっと綺麗な説明と解法があるんだろうけど

93 ：
>>92
ありがとうございます
仮引数mのライフタイムはmain関数が抜けるまでだから通るということで合っていますか
またVecではなくIterator::Mapだと駄目な理由は、Iterator::Mapはcollectされるまでクロージャが実行されないから…とかでしょうか

94 ：
>>93
仮引数mのライフタイムはクロージャ内なのは変わらないよ。>>92は仮引数を参照じゃなく消費してるから通る（>>92の&mじゃなくてmで良い）
クロージャが実行されないから、ではなく、mochiの値が消費されてるのにその参照を持たせようとしてるから駄目
試しに>>91のコードでmochi.map(|m| { 0 })とか書いて、mochiをprintln!に渡してみようとすると怒られるよ。もう使ってるって。

そこらへんの細かいルールを覚えるの大変だし、コンパイラもまだ分かりやすいエラーメッセージ吐いてくれないから、
・参照を使うときは、参照元をちゃんと生かしておくこと
・参照を使った構造体は、元の値を修飾（見方を変える、新しい機能を持たせる等）するようなパターンに限定すること
を守るようにした方がいいよ

95 ：
>>94
「消費したものの参照を持たせるのは駄目」と「消費しているから通る」はそれぞれはわかる気がするのですが、両方となると…
前者の「消費したもの」と後者(main関数中生き続けるMochiのベクトル)は別物だと思うのですが、
前者で駄目な理由は関数中生き続けるMochiがない(mapを呼び出しただけでは駄目)ということですか？

96 ：
「消費されるので通る」じゃ言葉足らずでした。「参照じゃなくmoveして延命している」の方が通じるかも

>>91のコードを整理すると
1. HitoはMochiの参照を持ってるから、Hitoが有効なスコープ中はMochiも有効じゃないといけない
2. mochiはinto_iterで作られてるからMochi型を吐き出す、けど所有はしない
3. なのにmochizukiはmochi.map()で各要素への参照しか持たない
4. mochiから吐き出されたMochiの受け皿が無いんでエラーになる

これを解決するには
1を変えてHitoがMochiを所有するようにデータ構造を変える
2で作られたMochi型の値をしっかり保持する変数を用意する
の2種類くらいしか思いつかん。
Does Not Live Longエラーはライフタイムがどうのこうのと小手先で弄るより、
値の所有者を明快にしたり、データ構造を見直してみると案外素直に直せるのが経験則。

97 ：
>>96
loop{
let (a, cond): (&str, bool) = get_too_many_str();
let m = Mochi{aji: a};
let h = Hito {m : &m};
if(cond){ break; }
}
// ここでhのvecが欲しい

この場合は、ムーブする(ループより長いライフライムの)変数がないので1の手法しかないということになりますか？
そこそこでかい文字列を扱っているので気を使っていたのですが、この場合Stringにすべきでしょうか

98 ：
大きい文字列を扱うから参照にしたいってのは普通にあるし分かるけど
Hitoが&MochiでなくMochiをメンバに持つようになっても文字列のコピーは行われないよ

自分なら>>97のget_too_many_str()が返す&strの元を誰が保持するのかをまず気にする
そこをしっかり把握してれば文字列のコピーは最低限になるはずだから

99 ：
>>97
んー、自分なら　そこだけに使うMochiCow型作ってでも
ajiの型をCowにして凌ぐかな

100 ：
&strの元もloop内の変数が持っています
hのvecを作るにはコピーは避けられないようですね…
&strからStringに変えたところhvec.push(h)してもエラーにはなりませんでしたが、
スコープを抜けたはずの変数が使える理由ってどこかに書いていますか？


100〜のスレッドの続きを読む
Excel VBA 質問スレ Part54
構造化ウェブプログラミング言語Dart2
シェルスクリプト総合 その33
師匠！1週間よろしくお願いするぞ！
Visual Studio Code / VSCode Part7
ふらっと C#,C♯,C＃（初心者用） Part137
Visual Studio 2017 Part6
２ちゃんねる互換P2P匿名掲示板の実装を考える １
メガデモを語る fr-08
Visual Studio 2012 Part8
--------------------
ルメール 112勝 デムーロ 102勝 戸崎圭 72勝 福永 66勝
有安杏果 サクライブ 2019? ?Another story?で起こりそうなこと
●　明治大学はMARCHを脱却し早慶に並んだ　●
ランニングと食事制限でかなり痩せたけど質問ある？
ヒロイン関連絡み同人スレ
憲法は同性婚を禁じているのか？
学者子どもの保育園2
ヒキなら新聞配達やろうぜ！Part-159
【すかいらーく】ガスト part86
【ダンメモ】ダンまち〜メモリア・フレーゼ〜 part246
かつや　田舎暮らしにあこがれて 40
YouTubeで見つけたセピアな動画
【解散】スス板で見たイタイ奴81【開山】
OneShot Part3
【長崎県対馬市】海ごみに国境はない　対馬の高校生派遣、韓国で学ぶ　啓発ポスターを現地の若者と制作 対馬市役所で展示予定[1/23]
ツイ企画ヲチスレ 9
☆ 新LED ZEPPELINのブートレグ総合スレッド15 ★
(･◎･)バブちゃんで馴れ合うパート56でち
復活！　今コピーしてあるものを貼り付けるスレ
【PS3/PS4/Switch】初音ミク -Project DIVA-28【F/X/FT/MEGA39's】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼