>>3
しらんかた
webのやつはみれなくなってるね 製本？したものを上げてるサーバーが結構長いこと落ちてるね
1. cargo install mdbookでmdbookをインストール
2. git cloneで>>3のリポジトリを取ってくる
3. 取ってきたディレクトリでmdbookを実行
4. book/ にhtmlで製本されたものが出力される
ので、是非読んで欲しい。may not live longとかcannot moveとかで怒られまくってる人なら共感しながら読めるはず アンチスレのほうが伸びてるやん
枯れ木も山の賑わい
教えてください
VecのDisplay::fmtをカスタマイズしたくて
type MyType<T> = (Vec<T>);
impl std::fmt::Display for MyType {
}
>>9
私も初心者で分からないですが最終的に何がしたいんでしょうか？ >>10
レスどうもです
Vec（他標準 struct）のDisplay::fmt出力をカスタマイズしたいんです 例えば
・要素数が多い場合、最初の数個を出力して残りを省略するとか
・要素の出力が長くなる場合、適当なところで改行するとか
・インデントを受け付けてネストしてる場合は改行とインデントで整形するとか
その上でVecのインターフェースをそのまま使いたいんですが
>>9のように新規の構造体を作る場合 手書きで委譲せねばならず
どうにか上手く出来ないもんかな……と >>11
その用途ならVecに別な名前のメソッドを直接implしちゃってそっち呼び出せばいいような気がしたんですが
println!("{}", v.my_fmt());
みたいに >>16の論旨は「MyType<T>は常にVec<T>として扱われても問題ないか？あるならDerefはおすすめしない」だと思うけど、
今回の場合はむしろMyType<T>は特別なことが無い限りVec<T>として使いたいんじゃないの？ >>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が有用ということが
知見として学べたので 大変ありがたかったです >>17
このスレを読んでる人に情報共有してるだけだよ オライリー届いた。
分厚すぎてわろたわ。読むの大変そう。
dyn Traitが入ってしばらくしたらBox<Trait>はdisconになるの？
deprecated扱いになって警告を出し次のepochで削除とかだったと思う
impl Trait入ったらそもそもほとんど使わなくなるから気にしなくていいのか。
使うケース減るのもそうだけどepochで機能削除する場合はソースコードの変換ツールが提供されるらしい
あと古いepochのソースはそのままコンパイルできるらしいから特に対応不要らしい
だから新しいepochにしか入っていない機能を使いたいcrateとかでなければ何もしなくても困らないはずだし
その場合でも変換ツール通せば簡単に対応できるはず
epoch releaseってのはどういうことなんだってばよ？
map: BTreeMap<K,V>で、keyが無かったら挿入、あったら格納されてる値vに応じて新しい値new_vに更新するか決めるってやりたいんだけど、
let v = map.entry(key).or_insert(new_v);
if ... {
*v = new_v;
}
よりもっと綺麗な書き方ある？
wasmってまだプリミティブすぎて使い物にならないのかと思ってたけど wasm-bindgen すげえな
もうここまでできるのか
苦労して書き直しても全然パフォーマンス上がらないのな…
ぐうの音もでないほど効果があるユースケースってなんなんだ
アルゴリズムが変わらないならそう変わらんのじゃないか
他人のひどいコードならともかく、同じ人が小規模なプログラムを書き直す程度だと特に
C/C++からRustへ書き直して速度が上がったって話はあんま聞いたことが無い
速いネイティブライブラリを言語に組み込んでるJuliaとかなら、書き直すだけで速度上がったって話はちらほら
pythonだったらnumpy使った方が楽でいいとかも
いやだってjavascriptだぜ？アルゴリズムの問題か？
c++もそうだがコンパイラに機能を詰め込むってのがそもそも筋が悪い
>>48
やっぱりちょっと分からないな。
RustやC++のどの辺がコンパイラに機能を詰め込んでると思うの？
ライブラリorツールに任せるってのもどの辺を任せたいのかな？
話がザックリし過ぎて言いたいことがよく分からないんだが。 プリプロセッサマクロのことかな？あとは型システムとかGCのことかな？ライブラリに任せるの意味がよくわからんが…
C++はコンパイラの方もだけど標準ライブラリでの機能実現も相応に多くて結果ソースの記述が煩雑になっているのは既知の事実でしょう
ライブラリや実装に任せた結果APIの統一が取れなくなって結局細かな仕様策定を余儀なくされたSchemeを見ても銀の弾丸でない事は明らかだよね
それに出来る事を増やすという点においてライブラリは有用だけど変数の不変性や型システムのような制限をする事に関してはコンパイラによしなにしてもらうより他ないよ
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
やっとstableでrustfmtできるようになったな
>>45は言語仕様の追加、更新が気に入らないんじゃないかな
try!の代わりに?なんて以ての外だ、みたいな？それ以外に思い付かなかったけど
1.0以前に@や~を削除してライブラリにぶん投げた辺りは希望通りな気がする
基本的に電池入りじゃないRustはライブラリやマクロの代わりの言語仕様の追加じゃなく
より効率的なバイナリを吐くための言語仕様の追加が多いイメージだけどなぁ、impl Traitとか >>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にする必要あったのか？ってところで賛否両論あるかもね。 box キーワードは何時 stable になるんだ？
boxキーワードはどういう時にうれしいのかがわからん
明らかに二行に分けた方が読みやすいわけだが。
新しい機能マンセー厨ってそういう感覚の狂いについて無自覚過ぎんだよね。
俺も違和感はあるけど、多くの人が賛意を出して採用されたんだから
>>60や俺の感覚が狂ってるんじゃね？自身の感覚の狂いって当然ながら無自覚過ぎんよ
boxは在り様の総意を取るの面倒だし、目下はBoxで運用できてるしで、いつまでもstableに来なさそう
ヒープを多用したい人には文法にあればありがたいんだろうけど、そもそもヒープが好まれんしのう boxっていきなりヒープにメモリ確保されるのが保証されたりするんじゃないの？
今はコンパイラ次第じゃん
ironって今メンテされてないのか
最近のweb FWはrocketの方が人気なんかな
nightly専用だからまだ手を付けてないんだけど
それはInPlaceとかPlacerがあればよくてbox inはただのsyntax sugarでは
分解の方がよほどsyntax sugarじゃないのかいな
NightlyのInPlace, Placer使わなくても、Stableの環境でmacro使って実現出来そう
boxって名前はBox<T>以外に使う場面で綺麗に見えない
place <- exprは代入みたい
tokio-coreなくなるんか
一通り組み上がった後の悲しいニュース
まじか、ちょっと辛いな
依存してるライブラリも結構あるよね
tokio系列のやつってtokioとかtokio-coreとかtokio-ioとかtokio-protoとか複数あってよく分からんのよね
tokio-ioのリポジトリにはtokioに移動したからもう使うなって書いてあるし
tokio-coreは移動じゃなくて廃止予定って書いてある…
tokio-protoはそのまま？tokio-timerとかtokio-serviceとかよく知らんリポジトリもあるし…
誰か各クレートの特徴(役割)と関係性を教えてくれ
>>71
あっちは、アンチが立てたキチガイ専用スレだからいいんだよ コミットを追うと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
か？
[] [[[ [[ [] ][ [] [ ] [] ][]] [[[ [] }
tokio-protoとtokio-serviceってtrait宣言が主体のインターフェース定義クレートだったような？
前者はクライアント、後者はサーバに適したインターフェースが定義されてた覚えがある
io, timer, cpupoolなんかはユーティリティ機能が実装されてたよな
統合の基準はどこかで議論されたんだろうけど、どこでやってたのかな
77デフォルトの名無しさん2018/02/28(水) 17:58:52.09
【お知らせ】Packt出版より Network Programming with Rust が発売されました。
>>79
大量のフィールドに値を入れるのって
一行一行書くしかありませんか？ 一行にしたいなら
foo = Foo { a: aaa[0], b: aaa[1], c: aaa[2] };
でも良いだろ。
部分書換なら
foo = Foo { a: aaa[0], .. foo };
とかもある。
JSON serializationはそんなに悪くないんじゃね？tokio-minihttpで96.2%出てる。
それよりSingle QueryとMultple Queryが遅いのが問題じゃね？
serdeでシリアライズだけするぶんにはjavaの1.4倍くらい早かったんだけどなあ(俺調べ)
Rust book first editionからの変更知りたいんだけどバージョン差分どこでまとめられてる？
>>92
ありがとうございます
仮引数mのライフタイムはmain関数が抜けるまでだから通るということで合っていますか
またVecではなくIterator::Mapだと駄目な理由は、Iterator::Mapはcollectされるまでクロージャが実行されないから…とかでしょうか >>93
仮引数mのライフタイムはクロージャ内なのは変わらないよ。>>92は仮引数を参照じゃなく消費してるから通る（>>92の&mじゃなくてmで良い）
クロージャが実行されないから、ではなく、mochiの値が消費されてるのにその参照を持たせようとしてるから駄目
試しに>>91のコードでmochi.map(|m| { 0 })とか書いて、mochiをprintln!に渡してみようとすると怒られるよ。もう使ってるって。
そこらへんの細かいルールを覚えるの大変だし、コンパイラもまだ分かりやすいエラーメッセージ吐いてくれないから、
・参照を使うときは、参照元をちゃんと生かしておくこと
・参照を使った構造体は、元の値を修飾（見方を変える、新しい機能を持たせる等）するようなパターンに限定すること
を守るようにした方がいいよ >>94
「消費したものの参照を持たせるのは駄目」と「消費しているから通る」はそれぞれはわかる気がするのですが、両方となると…
前者の「消費したもの」と後者(main関数中生き続けるMochiのベクトル)は別物だと思うのですが、
前者で駄目な理由は関数中生き続けるMochiがない(mapを呼び出しただけでは駄目)ということですか？ 「消費されるので通る」じゃ言葉足らずでした。「参照じゃなく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エラーはライフタイムがどうのこうのと小手先で弄るより、
値の所有者を明快にしたり、データ構造を見直してみると案外素直に直せるのが経験則。 >>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にすべきでしょうか 大きい文字列を扱うから参照にしたいってのは普通にあるし分かるけど
Hitoが&MochiでなくMochiをメンバに持つようになっても文字列のコピーは行われないよ
自分なら>>97のget_too_many_str()が返す&strの元を誰が保持するのかをまず気にする
そこをしっかり把握してれば文字列のコピーは最低限になるはずだから >>97
んー、自分なら そこだけに使うMochiCow型作ってでも
ajiの型をCowにして凌ぐかな &strの元もloop内の変数が持っています
hのvecを作るにはコピーは避けられないようですね…
&strからStringに変えたところhvec.push(h)してもエラーにはなりませんでしたが、
スコープを抜けたはずの変数が使える理由ってどこかに書いていますか？
そりゃloop内の変数hから、loop外のhvecに所有権が移動したから
頭の中に入れておける物なんて極わずかだし、場当たり的にdoes not live longエラーに対処するのは大変なので、
・値の所有者はどの変数であるべきか
・データ構造はどうあるべきか
という観点だけ念頭にいれて、「性能を稼ぐために参照を使おう」って考えを一旦外すとスッキリするよ
まともな話題はslackいっちゃうのかな。
匿名で喋りたいのはアンチ向きか
別にアンチって訳じゃないけど、コンパイルが遅すぎる（特に最適化掛けた場合に）のはどうかと思う。
実行が速くてもその生成に時間が掛かれば無意味でしょう……。
>>108
Rustで組んだ新Firefoxの動作が２倍ほど速くなったのは無意味？ まあコンパイルは遅いわな。
ていうかcargoの仕組みが問題なだけか？
rustcで単一ファイルだけコンパイルすると結構速いなと思った
cargoって警告無視のオプション(-Awarning)の有無でも一からビルドしようとしたりちょくちょくお粗末
なんかRustってテスト用と製品用で別々の最適化を施せるんじゃなかったっけ。
俺は自分の為だけにRustを使ってるのであまり気にしたことがないが。
確実にどんな人でも可能なネットで稼げる情報とか
念のためにのせておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
C717P
rustを始めたんだけど
分かりそうで分からなくて
イライラする
なんだこの言語
他の言語の経験にもよるけど 3000行ほど書けば慣れるよ（適当
actix_webでちょちょいとwebサービス作ろうと思っただけなんだが
externとuseみたいに、なんで同じようなものが２つ有るのとか
trait？、インプリすればいいだけならなんでこんな名前なんだとか
察するにJava経験者かね
externは外部ライブラリのモジュールを参照する宣言
modは自身のフォルダ以下のモジュールを参照する宣言
useはモジュールの要素（Struct or Trait）を取り込む宣言
pub use self::MyStruct; // 要素をexportしたり
use std::io::Error as IOError; // as で別名つけたり
use super::Result; // 上位の型を取り込んだり(mod.rs以外からだと同一フォルダのmod.rsを見にいくので注意)
肝はselfとsuperを使いこなすことかと
このあたりリファレンスに書いてあるんで落ち着いて読んでもらえばいいけど
インプリについては、Trait = Interface(Java)の理解でそれほど差し支えない気もするけど
（定数は同じ階層のmoduleに移す）
AssosiatedTypeがあるように"Traitはコンパイル時に解決できる"ものってのを
意識してればその内に腑に落ちるんじゃないかな
ただこんなこと言うと
「RustのTraitは厳密なtraitじゃない論争」（Wikipedia参照）が始まっちゃうかもしれないので
ゆるく受け流してほしいところ
extern/use周りをrefineする話ってどうなった？
チュートリアルの和訳のところを読んでいるけど
誰が訳したんだろう。。。
extern crateは、includeとかload libraryぐらいの意味だと思えばいいと思うが、
「え、それ、Cargo.tomlにもう書いたやん」って思うのは当然の感覚だな
しばらくしたら言語仕様変わりそうだなあこれ
勉強していくべきなのかどうか迷う
仕様の改定はc++のようにコンパイラのリリースとは別に２〜３年毎に定めることになってる
将来のコンパイラでも古い仕様を選択して使えるはず
どんな言語でも利用者多ければライブラリーのトレンド変わっていって学び直しはあるし
言語仕様の変更だけ特別視する理由が分からん
ver1.0になったし、firefoxに200kstepのソースがあるから始めるなら今でしょ
ruby1.8から1.9とか
python2から3の変更とか
嫌じゃん
言語もライブラリも混在してぐちゃぐちゃ
>>124
和訳は最新に追いついていないと思います、公式英文を確認したほうがいい Rustの場合仕様変更の影響を受ける記述はコンパイラがwarning（とsuggestion）出してくれるみたいだし
むしろライブラリのアップデートより楽なんじゃないかな
やりたいことをするのに1日使って50%しかできなかった
自分には無理だこの言語
ここにまともなRustユーザいないのは年寄りしかいないからなのかなぁ
slackかtwitterでコミュニケーションとれるので5chへ書き込みたい事情があまりない
>>138
おすすめのハッシュタグはなんでしょうか？ もっとメジャーになってslackが荒れて来たらここもワンちゃん
slackで発言できないアンチにしか存在価値がないのかぁ
つまり変な人でもスレに繰るなら、山の賑わい人気の証ってことね
Vec内のアイテムを複数条件やand or等をユーザに指定させてフィルタリングをしたいのですが
無理にでもSQL使うべきでしょうか
ユーザってのはどういうレイヤの話をしてるの？もう少し具体的に書かないと意味不明
values.iter().filter(hoge).filter(fuga).filter(piyo)
フィルターを何度がけすると型がやばそう
調べてみるとfiltersというクレートがありました
いやじゃ、いやじゃ、Eclipseなんぞ使いとうない
みんなどんな環境で書いてるの？今はvscode使ってるんだけどrlsがあまりに不安定すぎてストレスが…
emacs + flycheck
racerは重すぎるんでOFFにしてる
