Rust part8
レス数が1000を超えています。これ以上書き込みはできません。
この世のC/C++プログラムにバグが一つでもあるぐらい% >>2
このスレの仕様が定義されてないから
バグがあるかどうかは不定です 質問です。
こんな構造体を作っていました。
struct Iter<T: Iterator> {
buffer : Option<char>,
iter : T
}
このとき T::Item が char であるような制限を表現する方法はありますか? struct Iter<T: Iterator<Item=char>> >>6
ありがとうございます。
上手くいきました。 ミスがある前提で作られたソフトウェアなんぞ使いたくないわ。 個人のミスが重大な問題にならないようシステムで防ぐんだぞ
1つのミスがそのままProductionのバグになるわけじゃないから
個々の部品が予期しない故障をする前提で設計したシステムと
個々の部品は想定外の故障はしない前提で設計したシステムと
どちらのほうが高い信頼性を実現できるのかは歴史を見れば明らか
だから優れたプログラマーは自分がミスを犯す前提で
そのミスが重大な問題につながらないよう個人単位でもシステムを構築してる >>10
おまえの関わった製品には署名しといて。
絶対使わないから。 >>11
5chに書き込んでる時点で
何か人生ミスってる気がする https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=511e2be2ae90342a9c36f759e73108b6
勉強がてらたらい回し関数をメモ化仕様で書いてみたんですけどあってますかね…自信がないです プルリクとかも出す前にさんざん確認してんのに出してからすぐ「あ、ここ間違ってた…」みたいになるよね(´・ω・`) Vec<String> を拡張すると定義外ってエラー出るんですけどなんでかわかる人います?
他のライブラリでVec拡張してるソース見ると特殊なことせずにimplできてるんですけどどうすればこのエラー取り除けますか?
impl From<Vec<&str>> for Vec<String> {
fn from(v: Vec<&str>) -> Self {
v.into_iter().map(String::from).collect()
}
}
error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
|
88 | impl From<Vec<&str>> for Vec<String> {
| ^^^^^---------------^^^^^-----------
| | | |
| | | `std::vec::Vec` is not defined in the current crate
| | `std::vec::Vec` is not defined in the current crate
| impl doesn't use only types from inside the current crate
| >>18
ざっくりいうと
外部crateで定義された型 + 外部crateで定義されたtrait
の組み合わせでインプリするのは無理
どっちか片方が自crateで定義されたものなら問題ない
coherence ruleとかorphan ruleとかいうやつ
https://doc.rust-lang.org/error-index.html#E0117 >>19
おお、ありがとう
impl Vec<&str> の単体でも駄目だったから自trait作って実装した!
結構制約厳しいな
外部トレイトに実装するならめんどくさいけどマーカーつけとけよって意味かな こんな関数は書けますか?
@ イテレータを受け取る
A 受け取る引数は @ のただひとつのみ
B 条件を満たす範囲を「スライスで」返す
スライスを作る記法は &s[1..10] みたいな感じなのでスライスの元になるオブジェクト s が必要なように見えますが、
スライスを返したいというのはいかにもありそうなことなので出来ないはずはないだろうという思いもあります。
イテレータは実際にはなんらかのシーケンスをたどるものではなく値の生成器である場合もありますが、
それらを区別するような制約を表現できますか? >>21
無理じゃね?
スライスじゃなくtakeやskip使ってイテレータを返すべきケースだと思うけど スライスは連続したメモリ領域である必要があって
任意のイテレータがその条件を満たすのは不可能。
たまたま連続した場合だけスライスを返すのはunsafe使えば書ける。
ただ普通はイテレータ返してランダムアクセス必要なタイミングでcollectすると思う。 あと標準のイテレータは特に値の生成方法に関する型制約はないので
区別したいなら独自のイテレータ型を作って
標準イテレータへの変換を実装する感じかな。 入力が連続したメモリ領域だってんなら引数をイテレータじゃなくてスライスにすればいい
当たり前だけどスライスを作れるもの以外からはスライスは作れないからな >>23
>たまたま連続した場合だけスライスを返すのはunsafe使えば書ける。
イテレータを受け取ってスライスを返すとした場合
スライスの元になってるシーケンスのlifetimeが関数内に閉じるから
unsafe使ったとしてもborrow checkerにひっかからない? >>27
from_raw_partsでスライスを作った場合は元のポインタ由来のライフタイムは関係なくなるので
ボローチェッカは通るんじゃないかな?
もちろんそのスライスの実体が生きているかどうかは
自己責任になるけど。 >>28
なるほど
イテレータからイテレータの元のシーケンスが取得できればそれでいけるってことか
ちょっと見てみたらslice::Iterのas_sliceとかも内部でfrom_raw_parts使ってた
自分では使わないと思うけど勉強になった >>22-29
ありがとうございます。
スライスの役目や Rust の習慣について誤解していたみたいです。
【誤解】
スライスは範囲を表現する高級なオブジェクト
Vec にも配列にも使えるのでコンテナ全般に使えると思った
【正解】
スライスは「メモリの」範囲を表現するオブジェクト
実体としてはいわゆる fat pointer
【背景】
Vec は内部的に連続したメモリ領域で管理しているので普通の配列のようにスライスを作れる
C++ でいえば vector の data や string の c_str みたいなもの
【見落とし】
配列でも Vec でもスライスの型表記は同じなのでどうしてだろうと気にかかってはいたが掘り下げて調べなかった
型が同じなのは実際に同じだからなわけですね 質問あると自分の理解が怪しいのが分かって助かるわ。 let template = if spaces { "{1}{0}{1}" } else { "{1}{0}" };
format!(template, 1, 2);
これだとリテラルかけってエラー出るだけど、解決方法ないかな? iter[1..4]とか書けた方がiter.skil(1).take(4).collect()よりシンプルでええやん!
とは思ったが、そういう使い方したらそもそも駄目よ、という意思が表れているのかもしれん >>33
標準のformatでは無理だね。templateのパースエラーを返す手段がないので。
dynfmtクレートとかならいけると思う。 >>34
range(&self, from: usize, to: usize) -> Option
があればいいのにね
>> 35
ありがとう、リテラルのみは統一感出るけどかなり不便だね。
デバッグ用じゃなくともDisplayとかもあるからResult返すマクロも入れといてくれたらいいのにね >>34
Rust的にはcollectによるメモリコピーみたいな
重い操作は見た目上も重くしたいんだと思ってる。 collectを二度書くと罪悪感で一度にならないか一生懸命考える >>33
単純な用途ならリテラル返すマクロを書くといいかも
複雑な用途ならテンプレートエンジンかな
macro_rules! my_format {
(true) => ("{1}{0}{1}");
(false) => ("{1}{0}");
}
println!(my_format!(true), 1, 2); >>41
CodeLLDB初めて使ってみたがオレ環では特に問題なく使える
ソースマップ定義してないから標準ライブラリとかにstep inすればバイナリで表示されるけど
自分のソースのブレークポイントでバイナリ表示はされない
単純にdebug symbolが有効になってないとか?
launch.jsonのcargoのコマンド確認してそれでbuildしたバイナリを
rust-lldbでデバッグできるかどうかで切り分けてみたら? 解決しました
上記はMac用のデバッグのやり方のようです vscodeでrust始めたんだけどオートコンプリートがまともに働いてくれてない気がする
メソッド内の変数だと候補を出したり出さなかったりする >>45
vscodeやめてインテリなんとか使えば? vscode での Rust の補完って LSP を使うんでないの?
処理系と連携するって最強じゃんと思ってたんだが。 コンパイラから出てくる補完情報が成熟してないんで、まだ完璧には遠い
独自の解析はracerとintellij rustがやってて、精度はintellijの方が高い
あんまIDE使いたくないからrlsには頑張って欲しい 本体のソース見たいけど/* compiler built-in */ってなってて読めない。
どうやったら見れる? Rust の char::is_ascii とかは pub const fn is_ascii(&self) -> bool なのに is_whitespace とかは pub fn is_whitespace(self) -> bool みたいになってるのなんでだろ?
&self でも self でもどっちかに統一してよさそうな気がするんだけど。 なんかツイッターで以下2つについてコンパイルできねーっていうつぶやきがあったんですが、
試してみたらコンパイルできちゃったんですがどういうことなのでしょう
Rust2015/2018どっちでもコンパイルできちゃいました
//その1
let y: &i32;
let x = 5;
y = &x;
println!("{}", y);
参照元yの変数宣言が参照先のxより先に変数宣言されたからエラー。
//その2
let mut x = 5;
let y = &mut x;
*y += 1;
println!("{}", x); //これがエラー >>50
is_asciiはstrやsliceにもあるからそれに揃えたんじゃないかな >>51
NLLで救えるようになったケースだね。
Rust1.30くらいまで戻せばエラーになるけど
今は2015でも2018でもNLLがデフォルトなのでエラーにはならない。 >>52
なるほど、全部を &self に揃えなかったのは、やっぱ self の方が効率的って判断なのかな?
ワイはまだ初心者で Rust 脳になりきれてないんだけど、参照渡しってのは実質的に (C/C++ で言うところの) ポインタをやりとりしてる感じでしょ?
(単純な場合は最適化で消えると思うけど。)
char 程度の大きさならポインタを渡すのでもコピーして渡すのでも差はないし、ポインタだと間接参照になる分だけ無駄っぽい。
という理解をしてて、 char のメソッドは全部 self でいいくらいじゃないかと思ってた。 >>55
ascii系は昔はAsciiExtってトレイトに別れてたから
その名残だと思う。 >>56
歴史的経緯ってやつか。
比較的新しい言語なのに、やっぱりそういうこともあるのね。 The Rust Programming Language 第2版で勉強中なんだけど
この内容に連動した練習問題か使用例みたいなのどこかにないだろうか?英語でいい https://www.rust-lang.org/learn
このページの上のほうにある3つのボタンがそれそれ
1. The Bookの最新版
2. Rustlings course(練習問題的なやつ)
3. Rust by Example(使用例)
英語で問題ないなら2018対応してる最新のThe Book読んだほうがいいかも 英語がしんどい人 (日本語しかわからん人) にオススメなのはありますか? >>59
ありがと
こんな感じの欲しかった
って言うかPDFだけ読んでたから思い付かなかったけど本家にあったのか 手を動かしたいなら自転車本もあり
オライリーはちょっと古くなってるからなー オライリー本の古くなってる箇所はEdition Guide読めば問題ないよ
多少古くてもOwnershipやLifetimeあたりの重要コンセプトをわかりやすく書いてるものがおすすめ >>58みたいに英語でいいならrustupでインストールしたら付いてくるdocとそのリンク先にあるやつ読んだほうが良いぞ。
// ランタイム持ってないからasync/awaitがゼロコスト理論斬新すぎる 自クレートの名前やバージョンを取得するマクロって無かったっけ? Rust のライブラリって検索できるようになってるじゃん?
あれって名前だけじゃなくて引数の型とかで検索できたりしないのかなぁ。
Haskell (GHC) の Hoogle みたいに >>67
あ、 Inparameters ってやつをクリックすれば出てくるのか。 >>69
へー。
そのための専用のマクロってわけじゃなくて cargo が環境変数を設定してくれるって話なのね。
Cargo.toml を見ないとわかるはずもないからなんらかの連携があるのは当たり前といえば当たり前だけど。 io::Errorとかってprintln!("{:?}", err )とかしても
Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
みたいに出るだけで「どのファイル」かが分からないんですが、外部のクレートの関数から上のようなエラーが帰ってきた場合それが「どのファイル」によって起きてるのかというのはどうやって知れば良いんでしょうか? >>72
自分が明示的にパスを渡してるケースじゃなければ
クレートの作者にファイルパスも入れてクレメンスするしかないかも バイナリサイズはまだCの方が全然小さいけどRustはC以上になにが含まれてるの?
もちろん標準ライブラリとかは使ってないやつはバイナリに含まれないよね? >>74
明らかに大きいのはbacktrace用のデバッグシンボル。
これはstripすれば縮む。
それ以外はC側が共有ライブラリとしてどれだけ外に出してるかによるかと。 メモリ管理がランタイムにあるしdrop checkerもあるからランタイムはデカイよ。 >>75
backtrace用のデバッグシンボルってreleaseでもついてくるの?
>>76
drop checkerってborrow checkerの書き間違え?borrow checkerってcompile-time以外でも走るのって一部の実装だけって認識だけど
ARCとか使うとランタイムとか増えるの分かるけど使ってないハロワだけのやつでもCより多いのが疑問 Windows10のキャラクターがゴミ過ぎて無駄に苦労する
やっぱLinux使うしか無いんか?
でもゲームしたいからWindows環境が良いんだよな… >>77
releaseでもデバッグシンボルはついてくる。
取って欲しいってIssueは立ってるけど
stripすればいいって感じなのか、あまり動きはない。
あとCのHelloWorldが小さいのはコードの大半が
libcにあるせいなのでは。 組み込みで使おうなんて本気で考えてる奴はこんなところで聞いたりせんだろ。 cargo install mdbook
としたとき、依存するライブラリクレートも一斉にインストール (というかキャッシュみたいな扱い?) されたようです。
ローカルに入ったライブラリクレートのドキュメントから一斉に、網羅的に検索する仕組みはありますか?
標準ライブラリのドキュメントは名前や引数で検索できますが、それを手元に入っているライブラリ全てに拡大したようなものが欲しいです。 >>84
ビルド用の一時ディレクトリ以下に展開されただけで他から使えるようにはなってないよ >>85
そうなんですか。 Windows でやってるんですけど、
C:\Users\<ユーザー名>\.cargo\registry\src
に入っているのはビルド時の一時ファイル扱いという理解でいいんですかね?
他のプログラムをビルドしたときに必要になるライブラリクレートに共通するものが (このフォルダに) あったときでも
使いまわしはされないんでしょうか?
見かけ上は独立してるけど cargo が裏でうまいことやってくれるって感じなんでしょうか?
本当は Cargo book を読めばいいんでしょうけど、英語がわからなすぎて基本的な理念がよくわかってないです。 $ cargo doc --open
doc生成すればプロジェクトの依存クレートすべてWeb形式で検索できるけど
そういうことではない? >>84
cargo installはバイナリクレートをインストールするためのワンライナーなんで
ライブラリクレートをどうこうする為のものではないよ。
バイナリのビルドに成功したら.cargo\binにコピーしてゴミは削除する。
バイナリクレートのドキュメントを読みたいならそれ自身を読みに行くんだよ。
rustdocは開発者向けでユーザー向けじゃない。
mdbookのrustdocが読みたいなら単にソースコードをクローンして自分でcargo doc叩けばビルドしてくれるけど。 構造体のメソッドでメンバ変数の値ひっぺがすのにstd::mem::take使うの面倒だな >>87
「そのプロジェクト (に依存する全ての)」ではなく「ローカルに残っている全ての」というつもりでした。
>>88
> cargo installはバイナリクレートをインストールするためのワンライナーなんで
> ライブラリクレートをどうこうする為のものではないよ。
「為のものではない」ということは察していたんですが、
ライブラリのソースコードは残っているので裏で Cargo が動くために情報を残してもいるのだろう
と考えて特定のプロジェクトに限定せず横断的な処理をする方法があるのかどうかということを考えていました。
バイナリクレートをアップデートするときのために残してあるだけなんですかね……?
とりあえず、プロジェクトごとに独立していると考えておきます。 >>90
.cargoは全プロジェクト共通のキャッシュなので
プロジェクトまたいでも再利用はされる。
ただcargoコマンド自体はプロジェクト毎の操作しか提供しない、という感じ。
そういうツールを作ること自体は可能と思うけど。 >>91
なるほど。
見かけ上はプロジェクトの独立性があるように抽象化されているという感じですね。
なるべくなら過去に使ったことのあるライブラリクレートから使えそうなものを
探した方がキャッシュ (?) の増大を抑えられるし、
よく使われるライブラリの方が信頼性が高いだろうというのが元々の動機でした。
ツールの使い方もおぼつかないので定番と言えるのがどのあたりなのかとかいった肌感覚もなくて、
実際のコードを色々と見て回るのにどういうやり方が良いのか模索しています。 https://ideone.com/6mGYO9
これの14行目15行目のところを10行目のところのように1つの文で書ける方法ってありますか? Haskell の default 宣言みたいなのは Rust にありますか?
たとえば関数 foo が返す値の型が a もしくは b の可能性があり、
関数 bar が受け取る値の型が a もしくは b のときに bar(foo()) という式で型が定まりません。
このときに a と b の間での優先度を決める方法があるかという質問です。
具体的な状況があるわけではなくて、言語機能を学ぶ中で生じた疑問です。 >>93
こんな感じかな。
buf = buf.replace(ch, &<String as std::iter::FromIterator<&char>>::from_iter(&[' ', ch, ' '])); 俺だったらformat!(" {} ", ch)にするかforを[" ( ", " ) ", ...]で回すかな >>94
>たとえば関数 foo が返す値の型が a もしくは b の可能性があり
Rustで戻り値の型が1つに決まらない関数書ける? 型が曖昧な時はだいたいターボフィッシュでなんとかなるやろ >>94
型が定まらない関数は定義不能。
aまたはbを返したいならenum c {a, b}にしてcで返すしかないかと。 >>94
rustはsum typeしかない。それだと実行時に型を評価する方法とunion typeがいる。 正直TypeScriptの1 | 2 の型記法欲しい >>94 って多分こういう事では?
trait X { ... }
impl a for X { ... }
impl b for X { ... }
fn foo<T: X>() -> T { ... }
fn bar<T: X>(_: T) { ... }
bar(foo())
Rust の文法詳しくないんで間違ってたらすまん >>103
もしそうならdyn Xで返せばいいね。
その場合は型がAかBかの評価は実行時になるけど
どちらにしてもAとBのどっちを優先する、みたいなのはないな。 >>103-104
近いですが a と b との関係がもっと無関係なもの (仮想関数を使えない) を考えていました。
コードにするならこんな感じです。
struct Foo {}
struct Bar {}
trait X<T> { fn foo(&self) -> T; }
trait Y<T> { fn bar(&self, T); }
impl X<Foo> for Foo { fn foo(&self) -> Foo {Foo{}} }
impl X<Bar> for Foo { fn foo(&self) -> Bar {Bar{}} }
impl Y<Foo> for Bar { fn bar(&self, _x: Foo){} }
impl Y<Bar> for Bar { fn bar(&self, _x: Bar){} }
fn main() { Bar{}.bar(Foo{}.foo()); }
いずれにせよ方法はなさそうですね。
型を明記すればよい話ではあるのですが、ふと疑問に思ってしまったもので。 型推論でどの型のメソッドを呼び出せばいいか決まらないときに
特定の型のメソッドを優先させるような記述方法があるかってことだったのか
>>99のエスパー力すごいな ターボフィッシュで指定するか型指定した変数で一旦受けるかだね
https://play.rust-lang.org/?gist=3d288900b3f655687d0ba22cc37cbb23
逆にこのケースでdefaultの型が決まっちゃうのってちょっと怖い Rust の型システム (Hindley-Milner) は ML 系言語で実績があるやつなので、
(型に関して) ML 系で出来ることはおおよそ出来るのではないかと思いつつ、
Rust 的には明記させたい場面かもな……みたいな気持ちでした。
やはり勝手に決まって欲しくないというのが Rust ユーザの感覚なんですね。
※ Haskell が ML 系と言えるかどうかは諸説あります これ出来たらかっこいい見たいな型推論の活用ってある? C++ をやってた感覚から言うと Rust の str::parse っていいよね。
C++ は返却値の側からの推論が無いから普通の関数 (メンバ関数) として parse みたいなものを書けない。
いや、書けるけど型が推論されないからいちいち型を明記しなけりゃならない。
昔は演算子でやる C++ のスタイルを上手い案だと思ってたけど、
普通に関数 (メソッド) でやれるもんならその方がいいわ。 異なる関連型を持つ複数のトレイトオブジェクトを1つのVecに入れるのはAnyとかを使わないと無理でしょうか? IntelliJのRustプラグイン、ここのところぶっ壊れてないですか? static TEST = &'static str = "test";
このTESTの文字列の最後の一文字だけを参照として&'static charで作ることってできる?
型レベルで一文字ってことを保証したいのとメモリ節約したい >>117
charは4byteで&strはutf-8でasciiの部分は1byteだから無理そう。 charは4バイトでポインタ(参照)は8バイトだから節約するどころかむしろメモリ食ってるなwww charにする場合は’staticは無理なんじゃないかな
&strをsliceして1文字分にしたほうが素直だと思う
let x: &'static str = "test";
let y: &'static str = &x[x.len()-1..];
let z: &char = &x.chars().next_back().unwrap(); asciiと分かってるなら u8 だよね
どっかで u8 ベースの文字列操作ライブラリ見かけた気がする >>120
それだと最後の1文字が2バイト以上の時に死ぬから
結局全体をcharsするしかないような。 おお、いっぱい回答くれた ありがとう
レス止まってたけど見てる人はいるんだね。
素直にsliceしようと思ったけど、
str.chars.last()
このlastって消費されないけどなんで?
型的には
fn last(self) -> Option<char>
だけどなんで消費されないか分かんない
&strみたいな元々消費不可能ならコンパイルエラーでると思ってたんだけど。
https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.last 消費されるのは&strじゃなくてそのイテレータだからね。
"abcd".chars()で得られるのは、{ String : source, index : 0 }みたいな形のChars型で、これがindexをインクリメントしながら文字を取得してくれる。 use std::fmt::{self, Display, Write};
このselfってどういう意味? >>130
回答に書いてあるじゃん・・・
dostuff()やfixme()が受け取るselfに’aでlifetimeアノテーションをつける理由ないよね >>131
ライブラリ側が同じデータ構造しててループで回したいけど同じエラーで出来ません
これって並列にループ回す可能性があるからシングルスレッドでも禁止されるんですか?
すみません、初心者で >>132
ある値に対するmutable referenceは同時には1つしか存在できない
ってのはRustの基本ルールの1つ
この場合は並列に回す可能性があるかどうかは関係ない
Test構造体自体のライフタイムが’aで
dostuff()が&’a mut selfを取るなら
1回目のdostuff()呼び出し時にselfをmutableに借りてくるけど
Test構造体のライフタイムと同じだけ借りることになるから
2回目のdostuff()呼び出し時には1個目を借りたまま2個目を借りようとしてることになる
だからエラー >>133
なるほど。
ライブラリ側なので修正できないんですが、AcとRefCell使って解決できる問題ですか? その構造体の意図が分からんので、あんまりアドバイスできない
単にライブラリ作者がrustに慣れていないだけなら、適切な形に直してもらうのがシンプルで合理的だし、
>>130のTest::fixme相当のメソッドは誰にも呼び出して欲しくないのかもしれないなら、使うべきじゃない
Test::dostuffを繰り返し呼び出したいだけならRefCellで何とかなる Rustで型パズルみたいな状況になるのは、見落としている前提があったり、設計レベルで何か考慮が足りないことが原因な事が多いと個人的には思ってる
姑息な解決をしてたら余計にドツボにはまる >>135
>>136
このライブラリです。
https://github.com/fulmicoton/kuromoji-rs
https://github.com/fulmicoton/kuromoji-rs/blob/master/src/lib.rs#L246-L256
こういう風に使おうとしていて、Testと同じ状況です。
let mut tokenizer = kuromoji::Tokenizer::normal();
for s in ["Example", "Example2"].iter() {
tokenizer.tokenize_str(s);
} >>138
Tokenizer自体は'aで定義されてないからTestとは状況違うんじゃない? コンパイラをだましても本質的な解決にはならん。
そろそろrustマンセーしてる輩も気づくころだろうね。 なんかトレイトの命名でなるべく名詞ではなく動詞を使う(WriterではなくWrite、ReaderではなくRead)みたいなのがオフィシャルの文書で有ったような気がするんだけど見つからない
そんな指針って無かったっけ? >>141
オフィシャルにはapi-guidelinesだと思うけど特になさそう。
このissueで議論されてるけど特に結論はでてないし。
https://github.com/rust-lang/api-guidelines/issues/28 >>144
昔は一度借用するとスコープアウトするまで借りっぱなしだったけど、今は使われなくなった時点で返すようになってる。
non lexical lifetimeというやつ。
英語版だとちゃんとエラーになるように修正されてるね。
https://doc.rust-lang.org/rust-by-example/scope/borrow/freeze.html >>138
試しに触ってみた感じだけど、戻り値をVecに格納しようとすると怒られるよね。
で、よく見ると引数のtextはtokenizer自身と全く関係の無い寿命であって良いのに、tokenizerとtextの寿命が同じであるってシグネチャで言ってるから何かマズそう
多分もっと理解できる人も居るだろうけど、selfとtextの寿命を無関係にしたら動くってなんとなく分かる
pub fn tokenize_str<'s, 'a>(&'s mut self, mut text: &'a str) -> Vec<&'a str> {
ってやったら動くよ。省略ルールで
pub fn tokenize_str<'a>(&mut self, mut text: &'a str) -> Vec<&'a str> {
と同義。
俺の頭の中の理解じゃプルリク送れるほど明快に説明できないが、適当にローカルに落とすかgithubでforkして使っても良い >>145
non lexical lifetimeっていうのね。Rust日本語情報が少ないので助かるわ。thx >>147
しかしそもそも借用によるフリーズって意味なくなってるから
そのページ全体書き直した方がいい感じ。
フリーズするならシャドーイングによるmut外しかな。 >>149
ありがとうございます、後継なんてあったんですね。
最近出来たみたいですがそれほどメンテされてないみたいですしこの先不安なので素直にPython使うことにします。
日本関係依存のライブラリはRustユーザー少ないので確立されたものがないのが辛いですね... rustも字句解析も相当知ってなきゃそれ使うの無理だろ。。 vecのinto_iter呼んだらconsumeするって
fn into_iter(self) -> イテレータ {self}
こういうふうになってるってこと?
よく分かってない質問ですみません。 あ、consumeじゃないわこの場合
moveって言いたかった 自己解決?
https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-IntoIterator
impl<T> IntoIterator for Vec<T>
こうなってるからそのまま self を返してるに違いない
よーわからんけどなんとなく納得 >>154
ソースで理解したいんならここ。
https://doc.rust-lang.org/src/alloc/vec.rs.html#1934-1952
Vecのポインタを使ってIntoIterを構築して、元のVecはforgetでメモリ管理対象から外してる。 >>155 おっしゃるとおり
>>156 おおおお!!!
想像とは違ってunsafeの中であれこれしてた!
impl<T> IntoIterator for Vec<T> {
type Item = T;
type IntoIter = IntoIter<T>;
fn into_iter(mut self) -> IntoIter<T> {
unsafe {
let begin = self.as_mut_ptr();
let end = if mem::size_of::<T>() == 0 {
arith_offset(begin as *const i8, self.len() as isize) as *const T
} else {
begin.add(self.len()) as *const T
};
let cap = self.buf.capacity();
mem::forget(self);
IntoIter {
buf: NonNull::new_unchecked(begin),
phantom: PhantomData,
cap,
ptr: begin,
end,
}
}
}
}
いやあ勉強になります fn into_iter(mut self) -> IntoIter<T>
このmut selfのmutの使い方について
意味は理解してるんだけど公式で解説してる箇所ある? なんでextern crate crate_name;ってuse crate_name;に統合されたの? serde, reqwestとかを使ってるだけの小さいツールなのに
targetディレクトリ以下がいつの間にか2GB以上喰ってて驚いた
無駄遣いしすぎだろ >>158
公式系のやつを一通り検索したけどなさそうだね。
確かに頻出パターンではないし、mut selfが必要になる頃には
それくらい分かるだろってことなんだろうか。 容量くうのってインクリメンタルコンパイルのせいかしら? cargo run --bin bin_a で bin_a から a にバイナリ名をrenameできる方法ない?
オプションとかで >>165
標準ではないと思うから以下の三択
1. コマンドを自作する
2. プラグインを探す
3. Cargo.tomlの編集で我慢する >>164
インクリメンタルコンパイルの内部構造知らないけど、仕組み的に一個前の状態しかもたないから関係なさそう お前らのtargetディレクトリは何GBあるんだ? duとかdustでどのcrateが容量食ってるのか
きちんと確認したほうがいい dustで一番ディスク喰ってるプロジェクトを調べてみたよ
target/debug/depsの下に
lib(serde|derive_more|syn|reqwest|chrono_tz)-xxxxxxx.(so|rlib)
が各ライブラリごとに3つずつぐらいあって、それぞれ21〜38MBぐらいあった
その他、依存ライブラリの依存ライブラリと思われる *.rlib ファイルが260個
これだけで 1.4GB
target/debug/build の下が400MBぐらい
target/debug/incremental の下は100MBもない
同様のファイルがtarget/releaseにもあって合わせると 2.3GB エコシステムが充実してるのはいいが、
ぞろぞろと依存を引き連れて落ちてくるのはしんどいな。 Rustに限らず誰が書いたかも知らないまま誰がチェックしたかも知らないまま何がダウンロードされるかも知らないままインストールするのが当たり前になっちゃってるよな
ソースが公開されてるとは言えこれじゃいかんよなぁとは思いつつ楽だからまぁいっかな…って感じだわ(´・ω・`) わからないまま終わる。そんなのは嫌だ(´・ω・`) 誰が書いたかも知らないまま誰がチェックしたかも知らないまま何がインストールされるかも知らないままOSをインストールするのが当たり前になっちゃってるよな 公式アプリストアしか使えないとか真逆の動きだろ
何指してるんだ? 実際のところ、そんなのいちいち精査してられんだろう。 arrayvecとsmallvecってどっち使えばいいの? arrayvecとsmallvecよく見てないけど同じぐらい人気だからどっちでもよさそう
それよりもロガー周りが何選んだらいいか分からん(env_logger抜きで)
ファイル保存したいからlog4rsかfernかslogで迷ってる
ライブラリ選びはホントにRustの欠点だよな まあねぇ。 部品は連携してこそのものだから、
どっちでもいいものでもどちらかには決まってた方がありがたいってのはあるわな。
自由の強さと統率の強さは両立できないのでしゃーない。 確かに選びにくいんだけど、型が強いのとコンパイルエラーが見やすいから、移行コストが結構低い気はしている。
なので最近はあまり気にせず適当に選ぶことにしてるな。 スタック上に確保するStringライブラリってあるの? rust-avって今どういう状況なん?
だいぶ前にlibavの人たちがMozillaから数万ドル支援を受けて始めたとかニュースになってたけどgithub見ても実質的にはほぼ何も進んでないようなコミットばっかだしlibavすらほぼ放置みたいな感じだし
非公開の場所で着々と進んでてそのうち公開されるんやろか C++の負の仕様引きずってるなってRustの特徴とかある? winapi 0.3.8 の環境にて、CoCreateInstanceを行いたいのですが、
REFIIDの指定部分をどのように書けばよいか教えてくださいませ なんでassert_neはあるけどassert_notはないの? notと!が続いて少し紛らわしい
なくてもそんな困らない
必要なら作ればいい
とかかな
macro_rules! assert_not {
($cond:expr) => { assert!(!$cond) };
($cond:expr,) => { assert!(!$cond) };
($cond:expr, $($arg:tt)+) => { assert!(!$cond, $($arg)*) };
} assert!(!false);
の方が紛らわしくないか?
assert_not!は関数名の方に!あるから見間違えないしスッキリするし直感的な気がする
それにneが内部的に反転してるだけならnotあったほうがいいな usize同士の差の絶対値を求めるのがすごくだるいんですけどなんかいい方法ないすか if x > y { x - y } else { y - x }
じゃ駄目かい let mut v = vec![1,2];
std::mem::swap(v[1], v[0]);
assert!(v == vec![2,1]);
こうしたいんですけど、どうすればいいですか? Vec::swap使え->
Vec::swapは中でunsafe使ってるじゃないですか結局unsafe使わなきゃろくなこと出来ないんですねRustってクソですね
ってやりたい荒らしだろ?
氏ねばいいと思うよ 標準ライブラリ内でunsafe使うのと
自前でunsafe使わされるのとは雲泥の差があると思うんだがw ほら、万が一の荒らしじゃないケース用に答えも同時に提示してあげたのにそっちには見向きもしないでしょ
そりゃそうだよね、実際はやりたいことの質問じゃなくてRustをディスるための質問なんだもんね
つかそもそも本当に質問のことがやりたいなら提示したコードをコンパイルしようとしてるはずだよね
そしたら親切なコンパイラが&mutで借用しろって教えてくれてるよね
そしたらそれに従ったら今度は親切なコンパイラが同時に2つmutな借用は作れないって教えてくれてるよね
じゃあどうしたら良いですか?ってなるのが普通だよね
それがないってことは質問を装っていながらコンパイルすらしてないってことだからね
荒らすんなら荒らすでもうちょっと頭使おうね☆ Rustにも、次のような「言語定義された smart pointer」があり、
~ : 一回だけ(unique) 参照する smart pointer。
@ : 複数回参照できる smart pointerで、GC を使っている。
drop なるものが、C/C++ の free()やdeleteの機能を持つ。
という認識で正しいのでしょうか。 >>202
参照カウンタを1引くようなDeref や、C/C++の単項演算子の方の「*」と
全く同様な「参照はずし演算子」の「*」もあるようですね。
また、~ や @ よりは少し高レベルになった smart pointer として、
Box<T> が、参照カウンタ方式の smart pointer として Rc<T> が、
さらに、動的(?)になった smart pointer としてRef<T>やRefMut<T>
があるようです。
凄く複雑です。 参照型の変数 r への代入は、普段は、
r = 1;
などでよいようですが、なぜか、*r と書かなければなら無い事があるようです。
また、&i32の変数rとi32の変数aを比較する場合比較する場合、
前者には *r を付けないといけないようです。
難しいです。 6年以上前に削除された仕様の良し悪しを語りたいのか? >>207 いやbook読んでよ。もし@とか~についての記述があったら逆に教えて欲しいくらいだ >>204
&と*は常に逆の関係にあるようです。
The opposite of referencing by using & is dereferencing, which is accomplished with the dereference operator, *.
vがvecへの参照型の場合でも
v.push(5);
と書けてしまうのは、実体vとポインタ pV に対して
v.push(5);
pV->push(5);
と区別していたC++と違っているために個人的に混乱していただけのようです。
もう一つは、参照ではなく、
let a = 5;
let a = a + 1;
のように shadowing を行う例が個人的に混乱の原因になっていたようです。
参照型 &T の場合には、
let r : &mut TYPE = &a;
のようにした後は、
*r = xxx;
のように、原則的に * を付けて参照を一段階戻す必要があるようです。
*をつけなくていいのは、メンバ関数呼び出しの、
r.func();
のような例の場合だけで、もしかすると、
(*r).func();
としてもコンパイルが通るかもしれません。 7年も前の情報を無条件に信じられるピュアさが俺にも欲しいよ >>210
Rustの1.0リリースは2015年なので
それより古い資料は「昔そういう検討がなされたことがある」程度の意味しかない。
この5年の間に変わった仕様も結構あるし。 初心者なんだけど
もし1つの変数(所有権)にマルチスレッドで書き込みをしようと思ったら、
Rustの借用のルールだと不可能ですか?
複数のイミュータブルな参照を作る事になりますが、できないんですよね? あまちがえました
訂正:
複数のミュータブルな参照を作る事になります >>213
同時じゃなければ可能なので
他のマルチスレッドプログラミングと同じく排他制御をすればいい 実行時にデータ競合系の問題が生じない代わりに
コーディング時に借用チェッカーとの戦いをするという感じになるんですかね >>210 そのbookだよ。オフィシャルのドキュメントを読まずにどうして深入りできようか
1点だけ。rustではobj.method()とするとメソッドの引数の型(&とか&mutとか)に合うようにobjに*とか&とか付ける仕様になってる
メソッド呼ぶ時のobjに対してこっちが*とか&とか付ける必要は特に無い >>217
bookの話、了解しました。
後半、「メソッドの引数の型」とは、た第一引数 thisのことでしょうか。 所有権、借用、ライフタイムについて勉強してみた。
でも他の言語でも排他制御とか非同期処理用クラスで非同期処理に対応できるわけで、
結局どれくらい御利益があるのか分からなかった。 Rustの変数束縛、所有権、借用などで自動化されるのは、
「スタック変数」のポインタが、ブロックの外や関数の外に不用意に出ない
事だけで、Heapから確保されたオブジェクトの自動解放は、
参照カウンタや Garbage Collection を用いずに静的解析のみで行うことは出来ない、
という認識で正しいのでしょうか?? >>220
例えば、Cだと、
int *func()
{
int a;
return &a;
}
としても警告は出る可能性はあってもコンパイルエラーにはなりませんが、
Rustでは同等のことはできないようになっていますね。
でも、Heapから確保したオブジェクトは、それを参照している変数の個数は
動的に変わります。というのは、Heapとは解放のタイミングを後に遅らせる
ための仕組みな分けですから。
オブジェクトを参照している変数の個数は静的に決まらないと言うことは、
参照カウンタやGarbageCollectionのような動的な検査の仕組みが全く無ければ
解放できないはずですね。
もし静的に解放タイミングを決められる可能性があるとすれば、参照の個数に上限を
設けることによってです。簡単な例ではそのオブジェクトを参照する変数が1つしか
ないなら、その変数にnullや別の値が代入されたり、その変数が削除されるタイミング
だけを静的に調べれば自動解放できるはずです。
しかし、2つ以上になった場合、参照カウンタ無しで静的に削除タイミングを決定するのは
かなり難しくなります。 私が読んだ説明記事では所有権やライフタイムはローカル変数かつシングルスレッドの例しかなかったんですが、
それだとRustがどう非同期処理に強いのかイメージできませんでした。
グローバル変数やマルチスレッドでライフタイム等の概念が活用されている例ないですか? Rust では所有権が移るから、資源を共有しないからだろ
資源を共有すると、アクセスするタイミングで、バグってしまう。
A を更新 → B を更新 → Aを読み取り
間に、Bが入ったことで、AはBの値を読み取ってしまったけど、
その場ではエラーにならず、かなり後になって、データが何かおかしいと誰かが気づくかも知れない。
気づかないかも知れない
だから、あちこちで排他制御をせざるを得ない。
そうすると、デッドロック・タイムアウトも考えないといけない 資源を共有しないんじゃなくて、共有していい資源かどうかを型(SendとSync)で区別している。
なので排他制御が必要な箇所に入ってなかったらコンパイルエラーにできる。
だからデッドロックなんかは起きるけど、レーシングは起きないって感じ。
ライフタイムはそれほど関係ない。 マルチスレッドの話は置いておいて、そもそも Rustでは、Heapから確保したオブジェクトの解放は自動化されてますか? >>223
修正
>A を更新 → B を更新 → Aを読み取り
スレッドA が共有資源を更新 → B が更新 → Aが読み取り 基本的なことが理解出来てない人はまずThe Bookを読もう
次からテンプレに書いといたほうが良さそう 読んでそこまでたどりつくのは大変過ぎますので、どなたか分かる方が >>225 に答えていただければ幸いです。 >>225
自動で解放される。なぜされるのかが気になるならいろいろ想像してないでthe bookを読んだ方がいいと思う。 Rc<T> は参照カウンタ方式で自動解放されますが、循環参照があった場合には自動解放されず、メモリーリークするそうです。
つまり、RustはHeapのメモリーを完全自動では解放できないのです。
C#やJavaは遅いですが、循環参照がある場合でも、GarbageCollectionにより完全自動で解放されます。 つまり、「Rustは、GarbageCollectionがなくてもメモリ解放が自動化されている」
というのは嘘です。 >>228
その部分だけの説明は出来ない。 そこにたどり着くまでの説明は関連してるから。
体系立てて説明している文書が公式にあるのにそれより上手い説明が出来るわけないだろ。 >>231
https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust
[Q] Is it possible to cause a memory leak in Rust?
Is there any way of causing a memory leak in Rust? I know that even in garbage-collected
languages like JavaScript there are edge-cases where memory will be leaked, are
there any such cases in Rust?
[A1]
Yes, leaking memory in Rust is as easy as calling the std::mem::forget function.
You can also leak memory if you create a cycle of shared references:
A cycle between Rc pointers will never be deallocated. For this reason, Weak is used to break cycles.
For example, a tree could have strong Rc pointers from parent nodes to children, and Weak pointers
from children back to their parents. >>233
結論的に言えば、Heapから確保されたオブジェクトのメモリの解放は自動化されてません。 なんだ。真面目に聞いてるのかと思ったのに。
まぁご自由にどうぞ。 真面目に回答した相手が荒らしだった時って「何だよ荒らしかよ」みたいな反応より「クッソ抜けるwww」からの「すいません誤爆しました」みたいなレスで「真面目に回答したわけじゃないぞ、シコりながら適当に回答したんだぞ」的な雰囲気を出してったほうが良さそうじゃない? Rc<T> だけを使って循環リストを作った場合、循環参照が生じます。
その場合、その循環リスト全体が誰からも参照されなくなって、つまり、不要に
なっても「循環参照問題」が起きるために自動解放できないのです。
C#やJavaでは、この循環参照問題を解決することを主目的として、
遅さを犠牲に Garbage Collection を使っています。
これは「動的解析」に分類されます。
一方、Rustの場合は静的解析だけで済まそうとしていますが、結局、循環参照問題のために
完全自動化は出来ず、解放べきメモリが解放されずに残ってしまうという現象がおきえます。
これを防ぐには、人間側が 循環リストの最後と最初を結ぶためには、weak pointer を使う
などの注意深いプログラミングをすることで防ぐしかありません。
つまり、人間の注意深さでメモリーリークを防いでいるだけです。 >>239
リークしない保証が欲しいならそういう言語 (処理系) を使えばいいじゃん。
Rust はリークを確実に排除することを保証しないし、
Rust の定義するメモリ安全にはリークの排除が含まれないことは明言されている。
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
GC を使えばメモリリークが起きないってわけでもないし、
「どのような保証を与えるか?」の線引きが違うだけで
きちんと学んできちんと使いこなさなきゃなんだって駄目だよ。 >>241
別に駄目とは言ってません。
「静的解析でメモリ管理を自動化した。」
というのは言いすぎだと言うことです。 そりゃ循環参照とかウンコード書けばの話だろ、何か問題有るのか? 荒らしにかまうやつも荒らし
暇なおじいさんが各言語に難癖つけて回ってる
Kotlinの次はRust >>242
結局のところライフタイムは人間が書くし、それを元にいくらかのチェックと推論をするだけ。
今まで自動化できてなかった分 (の一部) を新しいやり方で自動化したってだけのことで、
何もかも自動でやってくれるような最強解析能力を持ってるなんて誰も言ってないよ。
ストローマン論法はやめろよな。
もう一度書くけど、 Rust のシステムはメモリリークの排除を目的にしていない。 リソースの開放をプログラム内で完璧にやろうとせずに
プロセスの再起動とかの水準で考えてしまえばいいこともあるかもね メモリ以外のリソース回収に関してはGCよりRust(あるいはC++のスマポ)がはるかに優秀なんだよな。
Rustに慣れると他言語でusingとかするのが面倒になってくるし、ついつい付け忘れて困る。 Kotlinスレでnullポインタの方が良いと
荒らしてたのと同一人物だったのか 体制側と違う意見は大事。
自分の頭で考えない人は、効能書きや権威やネットで書かれたことを鵜呑みにしてしまう。 いやファイルポインタ、コネクション、スレッドなどいくらでもあるだろ。 >>250
こんな出てきたばかりの言語に慣れてる人なんているかい。 ファイルハンドルくらいならusingでもいいけど、デバイスコンテキストみたいな微妙に寿命が長いのが困る。
Disposeとか呼び忘れても大抵GCが回収してくれてぱっと見動くけど、
時々回収してくれなくて再現性の低いバグになるとか。 Box<T>のソースを見ていたら、Box::new が次のような1行だけのソースで、
box キーワードを調べてみたら、組み込みの Box::new の実装とだけしか
情報がない。つまり、ソースがあるようで実質的には無い:
impl<T> Box<T> {
pub fn new(x: T) -> Box<T> {
box x
}
}
同様に Vec<T> のソースを見ていたら、RawVec なるものが出ていて、
RawVecのソースもあったがそこで、core::ptr なるものが使ってあり、
そのソースはないようだ。
Cにとってかわるシステム言語と言いながら、本質的には組み込み関数ばかりで
ソースを追っていくことができない。
Cは最初から理解できて、このような闇が存在しないので、高級アセンブラであり、
システム言語であった。
Rustにはその代わりは務まらないのではないか。 巨大学術掲示板群 - アルファ・ラボ
ttp://x0000.net
物理学 化学 生物学 数学 天文学 地理地学
IT 電子 工学 言語学 方言 国語 など Rustは概念が整理されてない。
Cは、ポインタという概念さえ理解すれば(そしてそれは、プログラミングに適性が有る人にはそんなに難しいわけではない)、それだけを頼りにあらゆるものが構築できた。
ところが、Rustはいくら学んでも終わりが無いくらい基礎の部分が難しい。
Box<T>が何をやっているかは、自然言語で説明されるばかりで肝心の
コードも擬似コードもなかなか見つからない。 Box<T>のデストラクタである所の Drop trait の drop 関数を調べてみると、
次のようになっており、compilerの埋め込み処理というコメントになっている。
恐らく、Box<T>が削除される際にコンパイラが何らかの処理を入れているが、
ソース中には書いてない。
こんな状態で Cの後釜を名乗ってほしくない。
unsafe impl<#[may_dangle] T: ?Sized> Drop for Box<T> {
fn drop(&mut self) {
// FIXME: Do nothing, drop is currently performed by compiler.
}
} >>257
それは悔しいけどちょっと理解できる
コンパイラーのソースみるとcompiler builtinで見れないやつとかあるし
いや、どこにあんねんと Option<Box<T>> で、Some(Box::new<xxx>)
とした場合に、どういう状況の時に このメモリが解放されるのか、
その仕組みも分かりにくい。 >>264
誤: Some(Box::new<xxx>)
正: Some(Box<T>::new(値)) Rustでの代入記号は、i32/f32/bool/str などのprimitive型以外は原則的に copy動作
ではなく、move 動作のようなもので、所有権の移動が発生する。
例外は、Copy traitsが実装されている型の場合で、その場合も copy動作になる。
Option<XXX>は、Copy traitsが実装されているらしく、Optionが他動詞で代入記号
を使うと、copy動作になるらしい。
ただし、これは文書で明確には述べられてないのでよくわからない。
根拠は、Optionのソースは以下のようになっていて、#[derive(Copy, ...)]の部分が、
Copy traitsを自動実装する、という意味になるらしいからだ:
#[derive(Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[rustc_diagnostic_item = "option_type"]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Option<T> {
/// No value
#[stable(feature = "rust1", since = "1.0.0")]
None,
/// Some value `T`
#[stable(feature = "rust1", since = "1.0.0")]
Some(#[stable(feature = "rust1", since = "1.0.0")] T),
} >>267
誤:Optionが他動詞で
正:Option型同士で >>263
compiler builtinはコンパイラのソースの中にあるよ
コンパイラのソースでcompiler built-inは見たこと無いけど 汽車 汽車 チンポ チンポ
シコシコ チンポッポ
チンポを出して シコシコ チンポッポ Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。
なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。 >>274
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
正しいことを保障できなかったり、自動化できなかったりするため、
しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。 みんなドキュメントコメントで日本語も一緒に書くときってどうしてる?
こんな連ねた感じでいいのかな?
/// Returns a Person object
/// Personオブジェクトを返す 例が悪いわ。
そんな糞コメント書くな、になってしまう。 Cからprintln使ってるRustの関数呼ぶとメモリリークしよる(´・ω・`) >>277
Personオブジェクトを返すって
-> Person
-> Box<dyn Person>
どっちのこと? Box<T> は copy ではなく move なんだとさ。 >>267
Option<T> は、Copy。
Box<T> は、Move。
だから、
Option<Box<T>> は、外側が Copy で、中身が Move らしい。 中身がCopyのときだけOptionもCopyになるんじゃないの?? >>285
ソースを示しておくと、以下の公式(?)サイトに、
「because Box isn't Copy」という言葉が書かれている:
https://doc.rust-lang.org/nomicon/checked-uninit.html struct のメンバに local 変数を代入した場合、エラーになる? >>291
それは >>267 とちゃんと整合しているな。
Option<T>は、Copy と Cloneの両方が実装されていると言うことで、
ならば、原則論からすればOptionは代入演算子でMove動作「ではなく」Copy動作
だということになる。 >>292
>ならば、原則論からすればOptionは代入演算子でMove動作「ではなく」Copy動作
は?
where T: Copyって書いてるやん
オレオレ原則論書き散らかして荒らすのやめてくれ c++の代替というけど、rust理解するにはc++でメモリイメージ固めた方が学習速いんじゃねーの? >>292
Optionは型ではない
Option<T>は型
区別してくれ ML系列の記法に慣れるとrustがどうしてalgol系列の記法にしたのか納得できなくなる。どんだけカンマ打たせるねん。
少し頑張れば関数の型も推論できると思うんだけど人まかせにしてるのが好きじゃない。せめて、勝手に挿入できるような記法にしとくべきだったと思う インスタンスでフィールドアクセスにカンマ使わない場合どんなのがいいの?
推論は関数で境界作りたかったんでしょ >>282
日本語のコメントはどう書くだけなのか聞きたかったから特に意図はない例だよ
>>283
完全な例だからあれだけどBoxではない
struct Person {
name: String,
}
impl Person {
pub fn new(name: &str) -> Self {
Self {
name: name.to_string()
}
}
} 型推論の能力的には関数も全部できるけど、ドキュメント目的であえてしてないはず。 TypeScriptは戻り値の型を省略できるけど、書かないと訳が分からなくなるので言語的には省略出来てもコーディングルールで強制してるわ
Cみたいに変数宣言含めて型を全部書くのも面倒だけど、行き過ぎた省略もメンテナンス性を損なうと思う C/C++に疲れた人が使って幸せになれるのがRustだと思ってたけど
実態は全然違うってことか C++17に疲れた人なら結構幸せになれるんじゃない。
C89に疲れた人だと厳しそうだが…。 RustのコンパイラソースをCloneしてそれをベースに名前も違うプログラミング言語作るのってライセンス的にどうなの?
rustcの構文解析の部分を変えてからそのrustcも全部その言語に変換したいんだけど >>304
そういう考えだから、人を馬鹿にするんだな。
ちょこっといじっただけの癖に全体を自分が造ったみたいな態度をとる。 >>299 あえてやらないなら、せめてコンパイラが推論した結果を教えてくれよと思う
この処理のこの部分だけ一旦切り出して別の処理にしてみたい、とかやるときにすげー大変
Haskellでも型表記は省略できるけどしない方が良いねって作法がメジャーなのは知ってるけど、型推論でサポートしてくれるからrustよりストレス少ない
ちょいとクロージャを関数として外に出しとこう、とか、ここ切り分けて別パターン用意して比較してみよう、とかやるのが面倒くさい
あ、まずクロージャにして型エラーを起こして教えてもらう、とかやればできるんかな… >>306
型を自分で書くのが面倒なときは()とかi32とか適当な型で埋めておいて、エラーメッセージから正しい型を持ってくるというのはありだよ。
(逆に言えば正しいエラーメッセージを出せるということは、関数プロトタイプまでちゃんと型推論できているということでもある) 関数の型を推論するのを捨ててるから
Deref coercionだったりFrom/Intoだったり中身を書くときに型を省略できるんじゃないの?
owned/shared/mutの違いに加えてlifetimeもあるから
それらも含めて推論することになると現実に使えるレベルになるのかどうか怪しい
少なくとも現時点で注力するようなポイントじゃないと思う >>304
ライセンス的にも道義的にもなんの問題もないんで、ぜひ面白言語作ってくれ。
Rust/Cargoの名前やロゴ使うと商標権には引っかかるのでそこだけちゃんと変えてればOK。 >>309
コミットも常に最新を本家からチェリーピックして最新機能とか享受大丈夫?
道理的に叩かれそうじゃない? HACK言語の成り立ちを参考にしたら
答えが見えてくるかもしれないよ WebKitとBlinkみたいな感じでしょ?へーきへーき githubのissueのタグで頭についてるE-easyとかT-compilerみたいな大文字のアルファベットってどういう意味があるの? >>310
ライセンス的には問題ない
道義的にはライセンス踏襲してRustを元にしてるよって書いとけば問題無いと思う この引数に&つけるのって
iter.map(|&i| i * 2)
これと同等?
for i in iter {
let i = &i;
} 巨大な学術掲示板群 アルファ・ラボ
ttp://x0000.net
物理学 化学 生物学 数学 天文学 地理地学
IT 電子 工学 言語学 方言 国語 など >>318
let i = 1;
let &i = i;
これだとコンパイル通らないよ 記法の問題で、>>318は、C++ と勘違いしたんでは。
Rustだと
let i = 1;
let j = &i;
が正しいはず。 iter.map(|i| i * 2)
と書いた場合、|i| i * 2 の部分は、closure や Lambda expression, lambdas
と呼ばれるものなんだろうけど、|&i| と書く形式はなかなか検索では出てこない。 >>318が書いてるの合ってると思うけど?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6d886f2d3b944871c18856f0e19da71c
iterがshared referenceをイテレートするから
パターンマッチで`&`を1枚剥がした型にして使ってる
for &i in iterと同じ >>322
ところで、
let &x = y;
ってどういう意味ですか?
let y:i32 = 5;
let x:&i32 = y;
とは違うんでしょうか? 誤: let x:&i32 = y;
正: let x:&i32 = &y; >>323
左辺に代入する時にパターンマッチ使ってDestructuringしてる
例えばyが&i32ならxはi32になる
let i = 1;
let &i = i;
これがコンパイル取らないのは
右辺がintegerで左辺がreferenceを要求しててマッチしないから
let i:i32 = 1;
let i = &i;
let &i = i;
let i:() = i;
↑こうやって試せば3行目の&iへの代入でiが&i32じゃなくi32になってるのが分かる
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1d23370e99b388e2205c43e863885315 >>325
let i:() = i;
はどういう意味でしょう。 >>326
C で言う void みたいなもんだよ。
あり得ない型を指定してエラーメッセージを出させたら
メッセージに右辺の側の型も表示されるという
型確認のテクニック 1.38からはstd::any::type_nameがstabilizeされてるので
エラーメッセージやnightly使わずに変数の型をprintして確認できるみたい
(consumeしないようにreferenceで渡すから少し分かりにくいかもだけど)
fn type_of<T>(_: &T) -> &str {
std::any::type_name::<T>()
}
fn main() {
let i = 1;
let i = &i;
let &i = i;
println!("{}", type_of(&i));
}
type_name_of_valってのも追加されてるけど
こっちはまだstabilizeされてない >>327
なるほど。貴重なテクニック有難うございます。
>>328
それを使えば構造体(?)や参照型などの lifetime も表示できますでしょうか?
何か lifetimeを確認する方法をご存知の型がいらっしゃればご教授頂ければ幸いです。 /1SwYHDd氏やるなぁ
こういう細かいことまで知ってる人のRust歴気になる さっきオナラしようとしたらウンチが少し出てしまったんだけど
ばれてないからいいよね ごめんね やりたいこと
Optionからの安全な値の取り出しを構文レベルで保証、およびNone時に数行の処理と戻り値を伴う正常の早期returnをしたい
if Some(v) = foo.get() {
安全に取り出せるがネストが嫌すぎる
} else {
位置が遠すぎる
}
let v = if Some(v) = foo.get() {
v 安全取り出しだが冗長すぎて嫌
} else {
}
let v = match foo.get() {
Some(v) => v 安全取り出しだが冗長すぎて嫌
None => { }
}
if foo.is_none() {
構文で保証されずプログラマの注意力次第で嫌すぎる
}
let v = foo.get().unwrap();
let v = foo.get().ok_or_else(||{
は?正常終了つってんだろが?エラー値で返すんじゃねえよバカか?
})?; 構文を調整したいならマクロじゃない?
let v = safe_get!(v, {
失敗した
return Ok (());
});
みたいな。ベタ書き以外でearly returnしたいならマクロか?演算子みたいにコンパイラサポートがいると思う。 >>335
map_or_elseでSomeの時とNoneの時に適用するクロージャを渡せる
でもどうしても1行で書きたいとかchainしたい場合じゃなければ普通にmatchかif-else使うな
fn foo(){
get().map_or_else(|| bar(), |x| baz(x))
}
fn foo(){
match get() {
None => bar(),
Some(x) => baz(x)
}
}
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=dd9040426e54f1dfc6e39d07bbd219fb >>341
クロージャ渡しじゃearly returnできないって話では? >>342
んん?
map_or_elseの結果戻せばいいんでは? >>343
それはearly returnって言わなくない?
そりゃ結果は同じだけど、元の人は構文的なことを言ってるわけで。 ネストが嫌なんだから無理でしょ
ネストしないコードを書く人なんだろうけど >>344
なるほど理解した
どうしてもearly returnがしたくてunwrapも嫌なら
if letを2回やるか、is_none+if let Someでもいい気がする
マクロ書いてもidiomaticな形に比べて読みやすくなるかっていうと微妙なので
fn foo(x: &str) -> Result<()>{
let v = safe_get!(get(x), { …; return Ok(()) });
let v = baz(v)?;
qux(v)?
}
fn foo(x: &str) -> Result<()>{
if let Some(v) = get(x) {
let v = baz(v)?;
qux(v)?;
}
Ok(())
} "処理と戻り値"を伴う""正常""の早期returnをしたいといってるだろがErrでラップして返すとかバカか?
こういうSomeから取り出すだけの部分が冗長だから消えてなくなれつってんだよ
is_none()でやるのは構文保証ではなく"プログラマーの注意力"による保証だからクソだつってんだよ
let v = match foo.get() { Some(v) => v, None => {
bar.modify();
baz.modify();
return Ok(bar, baz);
}};
let v = if let Some(v) = foo.get() { v } else {
bar.modify();
baz.modify();
return Ok(bar, baz);
}}; >>347
だからその冗長な部分はマクロで潰せと言ってるんだが。
マクロが嫌なら無理としか言いようがないが。 宣言的な書き方の基本が分かってないんやろな
Rust以前のレベル >>347
>"処理と戻り値"を伴う""正常""の早期returnをしたいといってるだろがErrでラップして返すとかバカか?
えっ、 Errでラップして返してる?
まぁそれはいいとしてearly returnだけじゃなく
戻り値の型と取り出した値をどうするかをセットで考えてないから
そうなっちゃうんだと思うよ RFCざっと見てきたけど、あっちでも
「map_errでいいんじゃ?」「return;できねーよ」ってやってるな。
そんなに難解なリクエストでもないと思うんだが。 fn check<T>(mut f: impl FnMut(T) -> bool)
と
fn check<T, F>(mut f: F)
where F: FnMut(T) -> bool
って同意義ですか? >>354
恐らくだけど、前者は必ずその関数を定義する。
後者は、Fがその型の場合にのみその関数を定義する。 なお、このような場合の whereは、日本人感覚からすれば、ifと読み替えてもいい。 前者の場合 check::<T, F>() でコールできるが後者はできない これ
https://docs.rs/try_or/0.2.0/try_or/macro.try_opt_or_else.html
Unwraps an Option. If the result is None, calls the function $or_fn and returns its result. そもそもcheck::<T, F>()じゃ引数渡してないから呼び出せなくない? 試してないけど 構文で解決すべきところを皆が俺俺マクロで解決して統一感ない状態を生むのが良いと考えるやついるのか? if foo.is_none() {
シンプルにこれでいいと思うんだが...
これぐらいの細かい挙動で構文拡張しろとかマクロ書けとかなったらC++みたいになっていくのが目に見えるしから嫌だわ
しかもこんな嫌だ嫌だ言ってて質問する立場なのにこんな逆ギレもしてて救いようがない 現状は335が冗長と言う状態で統一されてるんだからいいんじゃないの。
その冗長さをどうしても許容できない人は(少数派である以上)マクロで解決するしかないし、もし大多数が賛同できる新構文を思い付いたならRFC出せばいい。 test bench_test ... bench: 111,111 ns/iter (+/- 11,111)
ベンチマークの +/- ってどういう意味? >>363
is_none()は==NULLや==nilと同じ書き忘れのリスクを伴う"プログラマの注意力"を消耗するだけのゴミだろ if letやmatchにしないとSomeだったときの処理書けないしょ rust実用化に成功したプロジェクトって何があるの?お前らの会社では成功してるの? rustで作ったメカの中でセックスしましたみたいな use chrono::{Utc, TimeZone};
assert_eq!(Utc.ymd(2015, 5, 15).to_string(), "2015-05-15UTC");
なんでこれって静的メソッドじゃないのにself省略で使えるんですか?
https://docs.rs/chrono/0.4.11/chrono/offset/trait.TimeZone.html#method.ymd Utcはフィールドを持たないstructだから
イメージ的にはUtc{}.ymdとしているかんじ 公開されていないLoopStateっていうenum使いたいんですけどコンパイラーオプションとか属性とかで使う方法ありませんか?
https://doc.rust-lang.org/src/core/iter/mod.rs.html#371-422 pub が付いてないものをそんなに簡単に使えたらモジュールの意味がないやろ……。 そのモジュールをコピペして新しいモジュールを作れば自由に出来るんとちゃう? Docs.rsのメソッドの引数の見方がわからん
具体的には
https://docs.rs/image/0.23.2/image/struct.Frames.htmlの
pub fn new(iterator: Box<dyn Iterator<Item = ImageResult<Frame>> + 'a>) -> Self iteratorを受け取ってSelfを返す。
iteratorは各要素がImageResult<Frame>のもの
Box<dyn …>してるのはコンパイル時にTrait ObjecのSizeが決まるようにするため
(Generics使えば不要)
‘aはiteratorのlifetimeをSelfのlifetimeにするため >>380
解説ありがとう
上二行は理解できたんだが他がイマイチ・・・ >>381
dyn は C++ で言う抽象クラスみたいなもんだよ。
トレイトオブジェクトというのは実際にはそのトレイトを実装している様々な型の可能性があって、
それら全てを格納可能な大きさはわからない。
Box は C/C++ でいうポインタみたいな用途で使われる。
大きさがわからなくてもオブジェクトの場所を指すことは出来る。
「そのトレイトを実装している型ならなんでも」と「そのトレイトを実装している型のいずれか」というのは違う意味で、
ジェネリクスは後者。
言い換えると、実行時にディスパッチされる多相とコンパイル時にディスパッチされる多相ってこと。
コンパイル時に型がわかるのなら大きさもコンパイル時にわかる。
大きさがわかるなら Box を経由しなくていい。
ライフタイムの 'a は Frames の型引数の 'a と同じだから、
new の返り値 (Self) の寿命は iterator の寿命と同じになる。 Boxと&dynの違いって参照元がヒープかスタックかの違い? >>381
大前提として変数や関数の引数や戻り値はコンパイル時にサイズが決まってないといけない
Iterator Traitを実装してる型を引数として受け取りたいからといって
`pub fn new(iterator: Iterator<…>) -> Self` と書くと
Iterator Traitのサイズがコンパイル時にはわからないのでコンパイルエラーになる
`let foo: str;`でエラーになるのと同じ
Box<dyn Trait>か&dyn Traitの形にすれば
Iterator Traitへの参照(=Trait Objectというfatポインタ)になって
受け渡しするサイズが固定されるのでエラーにならない
ジェネリクスを使って
`pub fn new<T: Iterator<…>>(iterator: T) -> Self` と書いた場合は
実際の呼び出しに使われているTの型ごとにコンパイラがバイナリを生成するので
コンパイル時にTのサイズが決まってる (impl Trait使った場合も同じ)
>>382も書いてるように前者は動的ディスパッチ、後者は静的ディスパッチなので
異なる型が混在するコレクションを使いたい時やバイナリサイズを小さくしたい時以外は
ジェネリクスを選ぶほうが一般的 あーなんとなくわかってっきた
ジェネリクスと同じことがトレイトオブジェクトでも実現できて、その書き方がBox<dyn...>ということか そもそもRustはかなり型のサイズに厳しいけどなんで?
コンパイラの最適化のため? >>388
他言語なら暗黙的に参照として扱われるようなものも
明示的に&を付けたりBox化することを求めるから厳しく感じるんだと思う
明示的に求めるのはowned/shared/mutableの3つを
一貫性を持って区別して書くようにっていう設計選択じゃないかな
>大前提として変数や関数の引数や戻り値はコンパイル時にサイズが決まってないといけない
↑これ他言語でも常識かもしれないけど自分はRustやるまで意識したことなかったよ > pub fn new(iterator: Box<dyn Iterator<Item = ImageResult<Frame>> + 'a>) -> Self
入力にimpl Traitってまだ無理なんだっけ?
>>386
同じではない。
ジェネリックスはパラメトリック多相の事だから静的ディスパッチになるけどtrait objectは動的ディスパッチそのもの。
>>388
そう。
リージョンでメモリ管理するときリージョンのサイズが事前に決まるなら
リージョンはヒープじゃなくてスタックに確保できるからrustは型システムが
サイズが事前に決まる事を強制してる。
rustでは 途中で送ってしもた。
rustでは当たり前に見えるけどこんな事してるのrustくらいでヒープが必要ならクロージャさえも自分でbox化する必要がある。 スタック上に長さ不定のデータが作れるとバグの温床になる。
他の言語だと大体の値がヒープに乗せること前提で動いているんで気にしたことが無いのだと思われる。
C/C++でも非推奨なんだけど、初心者向け釣りサイトでは平気でやってることがあるし、できちゃうから面倒 配列サイズが決められてないかつ、関数内で配列生成するけど返り値はサイズ固定のスライス記法の書き方するようにする方法ってない?
つまりはVecのアロケートが嫌な場合
fn name(v: Vec<A>) -> Vec<A> {
v.iter().map(***).collect
}
これだとスタック確保できるけど無駄なデータ入ってるし、動的なサイズの配列を返せない
fn name(v: Vec<A>) -> [i32; 10] {
let mut arr = [0; 10];
for (i, x) in v { arr[i] = x}
arr
}
こういうスライスのスタック版みたいな感じのことがしたい
fn name(v: Vec<A>) -> [A] {
let mut arr = [0; v.len()];
for (i, x) in v { arr[i] = x}
arr
} >>390
impl Traitは引数にも使えるよ
>>393
[A]だとサイズがコンパイル時に決まらないから&[A]か&mut [A]を返すのはできる
ただ入力がVecで長さが不定なので
出力の参照元にその長さの配列を使うのは無理じゃないかな あと関数内部で配列生成したら
そのlifetimeが関数内に閉じるので参照も返せないね やるとしたら
外側のスコープで固定サイズの配列をバッファとして作っておいて
関数ではバッファを満たして返すイメージ C言語でいうところの if ( (c=foo()) == bar) { ...(cを使う処理)
みたいなことやりたいんですがどうすればいいですか?
fooが結構重くて2回呼び出したくないのですが、
let c = foo();
if c == bar {...
とやるしかない? matchとifガード使えば似たようなことは出来る >>396
何かしらのライブラリでなんかないかな?
static使うぐらいなら素直にVec使うわ... >>397
@ bindingってのを使う
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b2a16356c2c790985ddd937ccc2ca826 >>398
match foo() {
c if c == bar => { .. },
_ => (),
}
こういう感じでしょうか。この場合だと記載量としてはかなり微妙ですが何かに使えそうなので覚えときます。
ありがとうございます。
>>399
今回の場合はfoo()がboolじゃないのと、barが変数なのでシャドーイングされてうまくいかないようです・・・。
if let foo @ bar = foo() { ...
みたいなことやろうとしましたがダメでした。
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d580f91c98f26cf52a23791489914ec3 >>390
うーん難しいな
プログラムの動作としては同じになるんじゃないのか Vecとかのコンテナ系の使い方は大分変わるよ
例えばイベント駆動の何かを作るときには考えた方が良いかと思う
struct XEventSource {
listeners : Vec<Box<dyn Handler>>,
...
}
trait Handler { fn handle(ev: &XEvent) -> () }
impl XEventSource {
fn addLisnter(&mut self, listener : Box<dyn Handler>) -> () {
self.listeners.push(listener);
}
fn emit(&self) -> () {
XEvent ev = ...;
for listener in listeners.iter() {
listener.handle(&ev);
}
}
}
みたいに作ると、利用者が好きに作った構造体でもHandlerをimplすればlistenersに足せる
ジェネリクスだとイベントリスナの実際の型1つしかaddできないので不便 >>402
実行時に型を振り分けるとなると仮想関数テーブルを辿る必要があるんで実行時コストが少し増えるよ。
(Rust では仮想関数って言わないのかな? 正確な用語がわからん。)
トレイトを実装している型を実際には一種類しか使わないのだったら、
実行時間を除けば見かけ上の動作で違いはないかもしれんな。
でも基本的にはやりたいことを出来る範囲で制約は厳しい方がいい。
間違いの検出される可能性が高まるから。
制約をどのように表現するかというのはプログラミング言語の設計においては重要なトピックで、
構造化プログラミングが提唱されたのも goto だと制御をどこへ移動するのか制約を付けられないってのがある。
さらにそれを発展させた形として型で制約を付けようってのが色々と考えられてきたし、
Rust では更にオブジェクトの寿命に制約を付けようという考えが実現された。
その関数では何ができるのか、そして「何をしてはいけないのか」ってのを考えると
Rust らしいプログラムが出来ると思う。 APIサーバーでJSON受け取るときに値の型が違ったりオーバーフローするときってどうしてる?
serde_json::from_str で構造体の属性でエラーメッセージとかつけれたらいいのにな from_strの結果そのまま使ってるけどダメなの
シンタックスエラーとか含めると大変じゃない 海外向けサーバーだったらいいけど日本向けサーバーの場合は?
serde_jsonのエラーメッセージcustomizableじゃないから辛い serde_json::Error を見ると行と列と大雑把な原因はとれるみたい
細かくやるなら置換するしかなさそうだね reached the configured maximum number of stack frames
でスタックフレームの制限にかかるんだけどオプションとかで変えれる? impl<'_, T> Drop for std::collections::vec_deque::Drain<'_, T>
こういう風にちゃんとパス書かれたのもあれば、デフォルトインポートされてないのに省略されてる型あるけどどうなってるの?
https://doc.rust-lang.org/std/ops/trait.Drop.html フルパス書かなくてもいいように
mod.rsに指定されてるものとされてないもの それが必要な理由は?ここはお前の便利帳じゃねーんだから
有益な使い方が有れば紹介してから聞け >>412
Yコンビネータ
Rust で適切に型がつけられるかどうか知らんけど >>413
データ入ったVecと各種定数とメモ化用のmutなHashMap使ったDFSするときとか、引数がむっちゃ長くなるんです
>>414
全然わからんのであきらめます・・・ Copyでの関数呼び出しとポインタ作成ってコスト的にはプリミティブのどの型からが処理重い?
ここらへんCSの知識ないからわかんない Rust仕事で使ってる人〜
ウチはコロナの影響でプロジェクト吹き飛んだよん( ;∀;) 組み込みで試験的に導入したけどムズイ
まあ慣れの問題もあるのだろうけど ATS2ってRust以上にドキュメントが少なくてHaskell以上に難解なアレじゃないですかやだー! Rust界隈で一番貢献度高いのってAlexとかになるかな? Microsoftに期待してるんだが今はそれどころじゃ無さそう 勉強がてらこちらの二分探索木を真似してみたのですが、コンパイルエラーが出てしまいます。
https://codereview.stackexchange.com/questions/133209/binary-tree-implementation-in-rust
playgroundで試してみた結果がこれです。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fc1fe0d2a4c39c6b28d017539419fa2a
どうやら古いRustならコンパイルが通るようなのですが、今のRustでコンパイルを通すにはどうすればよいのでしょうか? 非常に良いと思います。flagの意図を読み解くのが少し難しいくらいです。 確かにflagが読みづらいからコメントは欲しいかな
個人的にはuse Exp::*;とExp::V => Exp::Valueにするのとテストケース増やしてmod testsにするかな
let exp = Value("MITSU").add(Value("MITSU")).add(Value("MITSU")).eql(Value("CORONA"));
let solver = Solver::new(exp);
// prints solved exp
solver.solve();
最初のインスタンスは読みにくいからこうするかも、それかマクロかビルダー作るか トレイトって機能を追加するときどういう機能であるかの特徴を一見して分かりやすくするためだけのもの? >>433
とりあえずはJavaやC#のインターフェースっぽいものとして捉えておけばいいんじゃないのかな
やってるうちに違いも分かってくる思うので これライフタイム記述を省略できないのなんで? https://git.io/JfL6t 省略してコンパイラ通るけどstableは無理なん? 関数内で同じ一連の処理を複数回実行するときマクロにまとめるのが一般的?それともクロージャ?
他にやりかたある?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=30449f979231232b68016cab5cd1fb1e
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e5fc7f66785bb3794df19104d5c479ff >>438
関数
あとサンプルだからかもしれないけど
spilt_whitespace()とかでイテレータ使ったほうが読みやすい https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b03bef5cb6f98821032c5fb1cce618a1 そのコードは実際に使うコードじゃなくてさあ、変数が何個もあったりすると関数切り出しは引数が地獄になるじゃん その例でマクロかクロージャの二択ならクロージャだけど
>>438のは外側の変数をキャプチャすることで複雑化してるから&tangoを渡すようにする
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ec760be4190e2ad4ab21fbea3c84b0ed
そうすると結局クロージャも関数と同じように適切なシグニチャを考える必要があるから
関数化に比べて楽ってことはないんじゃないかと思う 公式のGithubにrustlingsっていう簡単な練習問題がある
The Bookを読んだ後に基本文法をおさらいしたい人向け
https://github.com/rust-lang/rustlings ↓Vecだと動くのに配列にするとコンパイルできないの何で?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6321129e5cc3853ef1421d706e19a136 配列にinto_iterしてもmoveされずに参照が返るから rustいつのまにか蟹のイメージになってるけど、オライリーの影響?それとももっと前から何かあるのかな? let mut heap = BinaryHeap::new();
heap.push(10);
heap.push(9);
heap.push(20);
for x in &heap {
println!("{:?}", x);
}
これでバイナリヒープすると
20
9
10
ってなるんだけどバグ? >>448
配列のIntoIteratorは
&[T; N]と&mut [T; N]に対して実装されてるが[T; N]に対しては実装されてないのでmove不可
対してVecのIntoIteratorは
&Vec<T>と&mut Vec<T>だけでなくVec<T>に対しても実装されてるので
moveが必要なコンテキストならIntoIterator for Vec<T>が選択されmove可能 >>448
配列でやりたい場合はFooにClone実装してfoo.clone()
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8fdb065f764ac7a0be3a3de161bfa984 学術の巨大掲示板群 - アルファ・ラボ
ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
PS 連続と離散を統一した!
ttp://x0000.net/topic.aspx?id=3709-0 配列のIntoIteratorにmoveが実装されてないの何で? >>458
詳しいことはよくわからないけど実装が難しかったみたいよ
興味あればこのissue読んでみて
https://github.com/rust-lang/rust/issues/25725
nightly使えばmoveできる機能はあるみたい
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6a22ab054f5ec52ea942a1186710a516 >>457
型制約見ればええんやで。
`pub fn iter(&self) -> Iter<T>`は`impl<T> BinaryHeap<T>`。
`impl<T> BinaryHeap<T> where T: Ord,` に`pub fn into_sorted_vec(self) -> Vec<T>`てあるやろ。
rustのOrdは全順序や! この場合はifを使うのとmatchを使うのとどっちがおすすめ?
if nanika_shori().filter(hoshiimonokana).is_some() {
hoge();
mitsukatta();
} else {
fuga();
mitsukaranakatta();
}
match nanika_shori() {
Some(butsu) if hoshiimonokana(butsu) => {
hoge();
mitsukatta();
}
_ => {
fuga();
mitsukaranakatta();
}
} >>461
後者は関数型言語風ってだけでしょ
関数型言語で is_some() にあたる関数は存在しなかったり、有るけど使うなって扱いだったりする テレワーク中なのか連休入ったせいなのか知らんけど猛者が全部回答してくれるから助かるわ >>461
match nanika_shori().filter(hoshiimonokana) {
Some(x) => {…},
None => {…}
}
か
if let Some(x) = nanika_shori().filter(hoshiimononanoka) {…} else {…}
か
boolを返す関数作ってif else
fn are_aruka(hoshiimono: Hoge) -> bool {
match nanika_shori() {
Some(x) if x == hoshiimono => true,
_ => false
}
} filter(...).is_some()
って形はかなり読みにくい
ようは設計が悪い ResultやOptionが複数ネストしたやつをイイカンジにmapとかやれるか Rustやる前に軽くScalaとかHaskellやっとけば
コレクションライブラリ見たときに「あっ、これ進研ゼミでやったところだ!」って
なるから理解が早いよ このコードがコンパイル通って実行できて期待した実行結果にならない
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4472067bedcd681b8154620b3023f278 HashMapでキーを参照にしたときキーがアドレス値にならないのなんで?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9f33505748c782a7b5a2cd22481e5b68 >>473
&strのEqはアドレス比較じゃないから >>471
酷いAPI
stdがどうなってるかぐらい見たほうがいい Rustは、Releaseモードでも、Runtimeをstatic linkする場合は、61MB、
dynamic linkする場合は、8.2MBになるらしい。
dynamic linkで、さらにサイズ重視最適化した場合、4.6MB、strip した場合、
3.1MBになる。
でも、C++に変わる言語を標榜するにしては大きすぎる。
https://www.quora.com/Why-are-the-Rust-and-Go-binaries-so-large-compared-to-C-or-Pascal >>476
>Rustは、Releaseモードでも、Runtimeをstatic linkする場合は、61MB、
>dynamic linkする場合は、8.2MBになるらしい。
Debugモードが61MB
Releaseモード(デフォルト設定)が8.2MB って書いてるよ
それにlinkするのはRuntimeではない
もう少しちゃんと読もう >>476
デフォルトでサイズが大きいという結論は間違ってないけど
もうちょっと英語ちゃんと読んだ方がいいと思う…。
あとその回答には書いてないけど、頑張ればCにサイズで勝つことは可能だったはず。 >>476
Cで書いたプログラムが小さいのは標準ライブラリを利用しているから、だったと思うんだけど違った?
rustはmallocも自身に含めてたはずだし、Cの標準ライブラリ使うならもっと小さくなるはず
って>>476のQuoraの回答にちゃんと書いてあるじゃん!Cで15kb、Rustで14kbって!
自分でリンク貼るならちゃんと読め!もう! release profileでもデバッグシンボル含めてるからprofileオプション安定化までお預けかな。 アイデアありませんか?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=88804aace268a5d6adbdf8a8e4423fe4 scanでどうでしょ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0092b046fa5b3fa9f1aba90d35a93f4a お前らおっぱいだって大きいほうが好きなくせに何バイナリのファイルサイズが大きめだからって文句言ってるんだよ バイナリサイズの話題ってずーっと昔に出てたよな
ここで出たのかどこで見たのか忘れたけど
Why are Rust executables so huge?
https://stackoverflow.com/questions/29008127
これかなぁ? Noob question: why are Rust binaries so big
https://www.reddit.com/r/rust/comments/9m2dwo/
こっちだったかも let hoge = match s {
"hage" => hage,
"moge"=> moge, // 何かの関数や構造体を返そうとしたがhogeは一意の型しか受け取らないから無理
_=> return
}
loop {
hoge()
}
的な事やろうと色々試したけど、超絶複雑な事になってヤバい匂いしかしない。
ループの外でループ内で呼ぶ関数の分岐を書くのは何かのアンチパターンなのか
そもそも、ループの中でMatch書いても外からイミュータブルな値を渡すの分かってるなら
コンパイラが最適化してループ毎に分岐なんてしないから普通に入れて書けば良い? >>482
inclusiveなtake_untilは標準では無いみたいだから自分で作るかcrate探すかになるっぽい
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b74ec6655adc38e1e790a35485eee01c
https://github.com/rust-lang/rust/issues/62208
既存Traitを拡張するのはめんどくさいから
自分ならイテレータを受け取ってイテレータを返す関数で我慢する >>488
hoge用にhageかmogeをとれるenumを定義すれば型は一意に定まる。
別にループ内でmatchしても分岐予測はほぼ当たるだろうし
性能的に問題はないと思うけど。 あるいはFnとかにして型を揃えれば
loop内の分岐はなくなるかな。
たださっきも書いた通り分岐をなくすことに
それほど意味があるとも思えない。 こういうパターンマッチの使い方ってマイナー?保守性が悪い?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=29945c6422cbc643197b73631691211b >>488
enumで紐つけても結局hogeでmatch使う事になる。
Fnで返すと所謂if文と関数ポインタどっちが早い?的な事になって
最適化するとif文のが早くなる。つまりループの中でMatchしとけば良い。 rustのenumはsum typeだからjitがあればmegamorphicでもtracingじゃなくてもjit効いて
インラインキャッシュも必要ないからそのままインライン展開出来るんだが、この辺がAOTの限界だな。
まあ、分岐予測外れるような呼び出しなら初めからvtable使うだろう。
Rust/WinRT見てc++と違っていきなりマクロ出てくるからMFCの悪夢が蘇った。 >>492
ローカルにあるcrateとrustのソースをgrepしてみたがほとんど使われてないね
シグニチャに書くことで可読性が高まるケースであれば使えばいいと思うけど
そうじゃなければ一旦受けてから関数内で分割したほうがよさそう レンジ自体にマッチしたいんだけど書きかたって今はない?
match 1..3 {
2..3 => println!("2..3"),
1...3 => println!("matched!"),
_ => println!("_"),
} >>496
use std::ops::Range;
match 1..3 {
Range{start: 2, end: 3} => println!("2..3"),
Range{start: 1, end: 3} => println!("matched!"),
_ => println!("_"),
} >>497
ありがとう。
でもなんで
match 1 {
1...2 => println!("matched!"),
_ => todo!(),
}
こっちのマッチは ... で一個点々多く使わないといけなくなったの?
Range{start: 2, end: 3}をつかうなら1...2じゃなくて1..2でもよかったんじゃ ...ってまだ使えるのか。..=に置き換えられたのかと >>498
matchのarmでrangeを使うケースはほぼ100%inclusive rangeなので
half openのexclusive rangeとは区別して利便性を上げつつ
不用意なバグをコンパイル時に弾けるようにしたのが理由だと思うよ
>Range{start: 2, end: 3}をつかうなら1...2じゃなくて1..2でもよかったんじゃ
んん?
そもそも「レンジ自体にマッチしたい」ってどういう用途? Rust の API についてはメソッドのシグネチャとコメントからドキュメントを生成できるけど、
バイナリクレートにユーザー向けのドキュメントを付けるときの作法とかってあるの? i32とかにあるdiv_euclidってどういうときに使うものなの? >>502
「負数の剰余」で調べると違いが分かるかと。 ドキュメントコメントでのassetでのテストとmod testsってどう使い分けたらいいの?
ドキュメントテストすればユニットテスト書かなくていい?
ドキュメントは使用例だけで、assertでのテストって意味なくね?って思ってしまう。無視もできるし >>504
ドキュメントテストはドキュメントであってテストではない。
説明上分かりやすいならassertしてもいいけど、別になくてもいい。
それでもドキュメントテストを通すのは、古いサンプルコードがいつの間にかコンパイル通らなくなっている、というのを防ぐため。
ユニットテストは普通にmod testsで書けばいいよ。 doit()はclone()が入るとエラーが出るんだけど何で?
TにCloneが必要って出て来るけどTの実体をCloneしないのに必要ないだろJKって感じのエラーなんだが?
これどうしたらいいの?
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=31635004c1ad9fd9e5ba0f859f28ceb0 >>506
derive使うのやめて自分でClone実装したわ
deriveのCloneがおバカということがわかっただけ収穫とするわ これdoit()のget()がTに'static必要ってコンパイル失敗すんだけど
Tを直接扱ってないんだからTに'static要らんだろって感じなんだが?
関数ポインタくらい静的に解決できんだろJK
どうしたらいいんだよ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b69fe063a3cc2fae6f1cc7536007fe8e >>505
てことはドキュメントで書いたコードは普通のコンパイルエラー検知しなくてassertのエラーだけ検知するの?
なんかそれはそれでやばくないか コンパイル通さずにどうやってassertだけ通すんじゃ >>508
doitのTにstaticを指定すればいい。fn <T:'static> doit .... >>509
いやいや、コンパイルエラーは検知したくてassertはどっちでもいいって話。
コンパイルできないサンプルコードを検出したいんだから。 なんで型って大文字始まりなのにi32とかは全部小文字始まりになってんの?
初期のデザインミス? primitiveは小文字で統一したんじゃないの? Rustみたいに標準ライブラリは最小に留めてるような言語って他にありますか?
それとコンパイラ内部のCargo.tomlにライブラリのバージョン書けば別に最小に留めなくてもと思うんですが、どうでしょうか? >>516
どこまでを最小というかによるがC++は似たようなもんじゃないかしら これってなんで&mut になんの?
n: mut &i32のほうが差分的にも視覚的にもいいと思うけど、どっかに理由とか書かれてないかな?
fn example(n: &mut i32) {
}
let mut r = &10;
example(mut r); >>519
変数がmutableなのか、immutableなのかと
変数の型がownedなのか、shared referenceなのか、mutable referenceなのかとは別
mutable referenceを表す記号として`&mut`で一塊なのでmut &i32は微妙
n: mut i32みたいに型として意味のないコードを書いて
何が悪いのかわからないってことになりにくい
コンパイラ的にも`&`が先にあったほうが処理が簡単そう >>521
微妙というかmut &i32だとimmutableなi32へのmutableな参照になるから意味が違うのでは?
もとのi32は変更不可だが別の参照を再bindは可能という。 >>523
変数のmutabilityと変数の型をごっちゃにしてない?
`let x: &mut i32`と書くところを
`let x: mut &i32`と書くような文法にしたほうがよかったのでは
ってのが>>519の意見 >>524
その場合、今の文法でmut &i32と書くケースはどうすべきなの?
そこだけ変えちゃうと、全体的に整合性が取れなくなるのではないかと思うけど。 >>525
今の文法でmut &i32と書くケースは無いよね?
`let x: &mut &i32`って書くべきケースのことなら
`let x: mut &&i32`になるんじゃない? >>526
確かに勘違いしてた。今の文法だとmut x: &i32だった。
なので今は
x: &mut i32
mut x: &i32
を
x: mut &i32
mut x: &i32
にしても別に問題はないのか。なんとなく両者の区別はしにくくなってる気はするけど。 >>521
パース負荷はおいておいて、mut i32ってかいてあったら普通にコンパイルエラーでよくないか?
エラーの親切さはRustの特徴だし。
mut 書いてる時点で参照なのは当然なんだから書き忘れってすぐわかるじゃん
それに語彙的にmutable referenceとも一致して自然だから前から疑問だった
>>526 のパターンとかも今までの書き方だとかなり読みにくいよね 本当の理由は知らないけど、その区別しにくくなるってところがポイントだったんじゃないのかな
mut i32はコンパイルエラーだろうけど、今はエラーメッセージ見ても
&mutがあれば型、mutがあれば変数のmutabilityって詳細読まなくてもすぐ分かる
慣れかもしれんが俺は今の文法のほうが読みやすいと感じる
let mut x: &mut &i32
let mut x: mut &&i32
let mut x: &mut &mut i32
let mut x: mut mut &&i32 >>530
使いたくなくてもネットワーク使うcrateがtokioにべったり依存してて
非同期にこだわる意味ないアプリでも使わざるを得なくなるのがRustのダメなとこ actix-webでも中で使ってるしtokio単体でも使ってる 非同期に拘らないならstd::net使えばよくない 今の主流は tokio か async-std だけど io-uring 対応でまた勢力図に変化が起きたりするのだろうか 乗り遅れた。
tokioは使ってないけどデスクトップでnon-blocking file ioが欲しい。ブロックしたら並列の意味がない。
>>531
ランタイムと付いてくるapiで肥大化するのが問題なんだよね。 cargo clippyが通ってcargo buildが失敗するケースってある? 望まぬ非同期は一応 tokio::runtime::current_thread::block_on_all() で回避できるか
それでもビルドが一気に遅くなる 日本のRust界隈で有用なRust関連のツイートしてる人教えて io-uringと今までの非同期処理の違いってなに?
パフォーマンスそれほど変わるもんなの 返り値に &'static str ってライフタイム指定ないといけないけど、推論だけで解決できない問題があるから書かないといけないの?
Stringからderefで生成した&strでも結局はIO以外で来たStringは'staticでしょ?推論できそうだけど IO以外で来たString、つまりコンパイル時に計算しろってことやな!
let mut string = String::from("abcde");
if long_long_time_consume() != 0 { string.insert(0, 'c') }
require_static_str(&string); // require_static_str : &'static str -> ()
というコードが正しいかどうか、実際に長い長ーい計算しないと分からないけどできるならやれってことやな!絶対使わんわ! 競技プログラミングだとアルゴリズムの理解はともかく言語機能の活用は必ずしも身につかないしなぁ……。
Rust のようなプログラミング言語はいかにして抽象化層を構築するか、
いかにしてミスを防ぐか、
そのために必要なのはどんな機能かに意識が割かれたデザインが多いので、
手早くやることが正義の競技プログラミングではマッチしない。
ステップアップには良いかもしれんが、初心者向けには各言語向けの課題が欲しいよね。 enum MyEnum {
Foo,
Bar,
Baz,
}
のようなデータを載せないシンプルなenumで
Clone/CopyやPartialEq/Eqなどを実装しない場合ってどんな意図があったりするの? 意図もクソも本来の普通のenumだろ
値そのものに特に意味がなくて、複数のオプションを区別するためだけに使う単なる定数 Rc<Hoge>のHogeの参照を取りたいとき &*rc_hoge とするのと rc_hoge.as_ref() とするのとどっちがおすすめ? >>551
順序に意味はなくていいが、
Copy は出来て欲しーーってワイは思うやで。 enumだけ勝手にCopyついてるとか嫌すぎて草
>>553
as_ref() non_exhaustive で pub な enum は勝手に Copy になると意図せぬ破壊的変更を起こしやすくなってしまう >>553
Hoge が AsRef 実装してるかもしれないから Rc::as_ref か &* C++がそうだからとかの理由はなしで
[[[i32; 3]; 3]; 3]
がなんで
[3; [3; [3; i32]]]
じゃないの?
行列の時かなり読みにくいしさ なしでと言うかC++erが記法にノイズを持ち込んでるのは明らかなんだが >>560
それって型としては [[[i32]]] なんでしょ?
大きさの情報は後付けというか、
補足的なニュアンスを感じるので後にくるのが自然だと受け入れてる。
実際のところはどういう議論があったのか知らんけど。 >>561
じゃあこの型をRustに持ち込んだのはC++erのMozilla社員ってこと?
>>562
その型はスライスだから全く別。しかも&もないからそんな型ない let x = Box::new(String::from("foo"));
let y = *x;
これyにmoveできるの入門ドキュメントで説明されてなかったから結構驚いた >>563
>その型はスライスだから全く別。しかも&もないからそんな型ない
rustのドキュメントも混同しまくってるけど[T]はDSTのarrayで&[T]がDSTのarrayの借用(スライス)だぞ。
>>564
Boxのrustdocに書いてある >>565
[[[i32; 3]; 3]] は存在できるが [[[I32]]] は存在できない
配列の要素毎にサイズが可変となってしまう >>566
スライスにとって要素の数の情報は動的なもの (実質的に fat pointer) で
配列にとっての要素の数は型の一部ってこと? >>567
そういうこと
もっと言うと [T] の要素数情報は配列自体ではなく配列への参照 (fat pointer) が保持してるから
[T] が単独で存在することはできなくて、
参照経由の &[T] やスマートポインタ経由の Box<[T]>, Rc<[T]> といった形でしか存在できない >>568
そういうことか。
fat pointer を基礎に据えることを除けば
C/C++ のルールとかなり似てるのでわかりやすいな。
(けどそれ故に C/C++ 的な考え方に引きずられてしまう部分もある……。) 言いたい事は理解できるが
存在できないって言い方は少し引っかかる traitのFizzbuzzに付属してるtrait群がいいね。From実装してなくて爪甘いけど >>566
>[[[i32; 3]; 3]] は存在できるが
unsizedだからできない。
というか存在はしてる。rustはリージョンでメモリ管理するからコンパイル時に
リージョンのサイズが分かる必要があるからDSTが第一級じゃないだけ。
スライスにすればそのスライスのサイズはusize*2だからzoneを確保できるだろ。
コンパイル時にポインタのサイズが分かれば良いだけだから
assert_eq!(::std::alloc::Layout::new::<*const [u64]>(), ::std::alloc::Layout::new::<&[u64]>());
は通る。the bookとnomiconよめ。 >>574
(要素数と要素サイズがコンパイル時で既知である必要があるarrayの形では)存在できない
と読んでくれ ::stdの指定の仕方ってなんで使うの?stdじゃなくて
自作のmod std作った時にしか被らないぐらいしか利点なさそう。しかもそんな紛らわしい名前で作らないし std以外のcrateにも使えるから、モジュールとの名前かぶりで使わざるを得ないときもある
testとか pub enum KansaiPref {
Osaka,
Hyogo,
Kyoto,
}
こういうenumを文字列から生成する時ってnewよりfrom_strで作った方がいいの?
impl KansaiPref {
fn new(s: &str) -> Self {
use Self::*;
match s {
"大阪" => Osaka,
"兵庫" => Hyogo,
"京都" => Kyoto,
_ => unimplemented!(),
}
}
newかfrom_str
impl FromStr for KansaiPref {
type Err = ...;
fn from_str(s: &str) -> Result<Self, Self::Err> {
use Self::*;
match s {
"大阪" => Osaka,
"兵庫" => Hyogo,
"京都" => Kyoto,
_ => unimplemented!(),
}
}
} >>582
どっちでもいいと思うけど自分ならfrom_str選ぶ
理由はenumをnewするのにResult(かOption)が返されるシグニチャよりも
input.parse::<KansaiPref>()してResultが返されるほうが意図が伝わりやすいから >>582
俺は初心者だから意見としてはそれほどあてにならないけど、
from_str を使った方がいいと思う。
new はただの習慣だが FromStr は制約として機能するので、
既存の枠組みの中で便利に機能する可能性がある。 多言語展開を考えるとどれも使いたくねえな…と思ってしまう FromStr実装するならちゃんと Err 返してくれ let a : Box<[T; 1000]> = Box::new([Default::default();1000]);
みたいなのってスタックに要素を作ってからヒープにコピーするようになるから効率が悪いし、
Copy を実装してない型だと使えないみたいなんだけど、これって今はどうするのが常套手段なの?
前提条件として変数の型は Box<[T; 1000]> というのは固定ということにして、
unsafe も避けられるものなら避けたい。 >>587
vec![Default::default();1000].into_boxed_slice(); >>586
標準でString or &str のパース失敗時に返すErrの型とかあんの? vec! と同じような使い勝手の box! があってもよさそうな気がするけど、
そういうクレートがあったりする? #![feature(box_syntax)]
let a: Box<[T; 1000]> = box [Default::default(); 1000];
https://github.com/rust-lang/rust/issues/53827 >>591
おおっ、これぞ私が必要としていたもの! >>594
#は直後の構文要素に対するアノテーションで
#!はそれを含むスコープ全体へのアノテーション。 loopとスレッドスリープでやるのもいいけど、いい感じにデーモン立てて一定時間経ったら関数実行してくれるような仕組みのクレートってない? 借用や所有の概念って、Rustがはじめてなのかと思ったら、D言語に既にあったんだね。 >>598
あー。D言語の方がRustを参考に取り入れたらしい。 Rustのヒープは必ず参照カウンタが入ってしまうので、C/C++言語に比べれば遅くなるね。 >>600
Rc以外は参照カウンタ入らないよ。
解放タイミングはコンパイル時に決定するんだからカウンタいらない。 >>601
Box<T>も参照カウンタ入ってないの? >>601
それより、参照カウンタが入っているかどうかはどこを読めば分かるの? C++ vs Rust
unique_ptr<T> ---> Box<T>
shared_ptr<T> ---> Rc<T>
weak_ptr<T> ---> Weak<T>
ということなの?
どこに書いてある?? >>603
RcやArcのドキュメントにはreference counting pointerと書いてある。
Boxとか入ってないやつにわざわざ入ってないとは書いてないけど。 let a = 7;
let a_box: Box<i32>
a_box = Box::new(a+2); //(3)
という例があったけど、どうして、(3)がエラーにならないの?
mut 属性にしておかなければ、let文でしか代入できないんじゃなかった? >>605
C++とは名前が変わっているだけで、>>604という理解でいいわけだね? >>607
>a_boxは2行目では値が入ってないので、3行目が最初の代入だから変更ではなくmutはいらない。
なるほど、最初かどうかをコンパイラが追跡していたんだね。
知らなかった。
immutableな変数は、必ず let 文でしか代入できないとばかり思っていた。
最初に読んだ documentでは、例としてそう書いてあったから。 >>608
厳密に同じかはわからないけど、対応としては合ってるかと。 「変数のアドレスを他の変数に代入することを借用(borrowing)という」
という理解で有ってる? ID: o7IiynR8
こいつやべーだろ。なんにも知らないくせにRustのヒープは必ず参照カウンタが入るとか嘘吹かしてんじゃねえか
蓋開けれみりゃ初心者のクレクレゴミだし、どういう自信で最初言ったんだよ >>611
実態はアドレスだが所有権管理の対象になるのはアドレスではなく参照。 コンパイル時に所有権のチェックをしてるってのがよくわかってなくて変なことを言ってるのかもね。
「所有権の移動」が「実行時にアドレスと一緒に所有権が渡される」みたいな認識だとしたら
参照カウンタによって実装されるという ID:o7IiynR8 みたいな言説になるのはわからんでもない。
が、 Rust は静的解析の賢さでメモリの安全性を高めるのがウリのひとつなんだからそんなわけねーだろというくらいには
想像できて欲しいよ。 C++の概念に言い換えて理解しようというのが
そもそも無理筋な気が 説明書読まずにとりあえず人に聞いて教えて貰おうとするやついるよね 所有権回りは Rust の重要な特徴だから
どんな入門書でも書いてないはずはないんだよな。 Rustの普及を阻む課題 年次調査から明らかに
https://www.atmarkit.co.jp/ait/articles/2006/01/news044.html
Rustの利用をやめた回答者にその理由を尋ねたところ「自社がRustを使っていない」という回答が最も多かった。
他の上位の理由は「習得が大変」「必要としているライブラリがない」「移行すると作業能率が落ちる」「IDE(統合開発環境)でのサポートが不十分」などだ。
Rustを利用したことがない回答者に理由を尋ねたところ、「Rustを学んだことがないから。ただし、学びたい」「自社がRustを使っていないから」という回答が、いずれも約4分の1の割合に達し、この2つで回答の過半数を占めた。
Rustの普及拡大への最大の課題として挙げた上位3つは、「トレーニング/ドキュメントの充実」「ライブラリの充実/改善」「IDEの統合」だ。 ちょっと変わった傾向だな:
55% of Rust users develop on Linux
24% develop on Windows
23% develop on macOS 間違った知識を他人に教えるのは説明書読む以前の問題 回答者がターゲットとしているプラットフォームも以下の様に書かれているが、回答者がWebBackendを職業にしている人が多いことに対応している可能性が高い :
Linux: 36.9%、
Windows: 16.3%、
maxOS: 14.7%
WebAssembly: 14.4%
Embedded: 7.6%
iOS: 2.9%
BSD: 2.7%
Android: 2.4%
When it comes to what platforms using are targeting for their applications Linux remains the first choice with 36.9%,with Windows as second at 16.3%.
Following close behind Windows are macOS and Web Assembly at 14% each Some a = xxx; // 何か初期済みであると仮定
let b1 = Box::new(a);
let b2 = b1;
とした場合、b1が持っていた所有権はb2に移ってしまい、
b1はこれ以後使えなくなるという理解で有ってますか? 初心者なもので、正しく(?)は、
let b1 = Box<Some>::new();
let b2 = b1;
なのかも知れません。 >>625
そこは一時間ほど前に読みましたが、>>623のことは分からないので質問しました。 >>623
お前が正しく理解してるかどうか知らんけど個別の事例として言えば Yes だ。
所有権は移動して、元の変数はもう使えない。
だけどそんなことはやってみたらわかりやすいエラーメッセージが出るじゃないの。
fn main() {
let a = 20;
let b1 = Box::new(a);
let b2 = b1;
println!("{}", b1);
}
みたいなことを書いたら
error[E0382]: use of moved value: `b1`
って出るし、どこでムーブ (所有権の移管) 済みかまでも表示してくれる。
Rust のエラーメッセージはめっちゃ親切なんだから、
「この場合はどうですか」なんて質問する間があったらやってみりゃいいんだよ。 Rustのエラーメッセージがすごく親切なのは分かるんだけど、小手先で直そうとするとどんどん修正範囲が広くなっていって最終的に「設計が悪い」みたいな結論になっちゃう
他言語よりコーディング時に考慮すべき点が多いというか違うというか…慣れればそういうことも無くなるのかね >>628
色々調べてる途中だけど、どうも、C言語で出来ていたことの何割かは
Rustでは禁止されていて出来ないと思う。
https://stackoverflow.com/questions/40875152/reference-to-element-in-vector
を見てもRustではarrayの1つの要素に対する参照は作れないようだし。
C/C++では当然、そのようなものへの参照やポインタが好きなように作れる。
これが出来ないことである種の組み合わせ爆発が起こりがちになり、
C/C++よりプログラムがしにくくなるだろう。 >>729
例えばの話、C言語だと1つのCPerson型のデータをファイルに出力する関数を
void write(FILE *fp, CPerson const *person);
のように作りさえすれば、
CPerson persons[100];
for (int idx=0; idx<100; idx++ ) {
write(fp, &persons[idx]);
}
でCPersonの配列にも対応できてしまう。
このようなことがRustではできなくなるはず。
無理やり観が有るが、CPersonのメンバ関数としてwrite()関数を作ってしまうことで対応できるかも知れない。 rustはまだ勉強中だけど、630がアホなこと言ってるのは俺でもわかる。 ID:T0vrM+QLやID:bf1cRh+Bと同一人物だね もうこのスレで公式すら読んでないような初心者質問するやつ無視でよくね。文章から見て同一人物っぽいし
それとそのテンプレ追加も次立てる人お願い >>999 diesel辛いっていう人多いけど、乗り換えるならどんなクレートになんだろうね 結局c++やらんとrustを理解するなんて無理なんだよ >>638
こないだ C++ スレで >>623 の ID は見たぞ。 https://users.rust-lang.org/t/isnt-rust-too-difficult-to-be-widely-adopted/6173/37
↑のサイトに寄れば、Blandy & Orendorff の Programming Rust の
評判が良いらしい:
I’m also new to Rust and have found the “Programming Rust” book by Blandy & Orendorff to be very helpful.
Especially the chapters on ownership and references.
It is an expensive book though.
また、Box<T>, Rc<T>, RefCell<T>は必要ないという見方があるらしい。
最初から用意されているコンテナを使えば十分という意味のようだ :
I also didn’t need Box, Rc, RefCell, or friends. >>638
(C++は、C++11から大幅に改定されたので)、海外のサイトに寄れば、
C++11より前のC++からRustを学ぼうとすると大変だが、C++11以後
からだと対応関係が分かり易くて楽なのだそうだ。
unique_ptrとBox<T>が対応しているような話か。
ただ、C++の特徴であるtemplateに相当するものがまだRustにはないことが
残念だと書かれていた。 そのサイトに寄れば、Rustで難しいのは、借用や所有の概念ではなく、
lifetimeなのだそうだ。
個人的にも、構造体のlifetimeについて説明不足を感じた。
構造体の変数のスコープと構造体のメタ部分で記述するライフタイムの
関係性がbookなどでは書かれて無いように思えた。
分からんけど。 2018/04 の時点でも、まだ、lifetimeに関する資料が足りてないと感じている人がいたそうだ。
Can we maybe have a book or booklet exclusively covering lifetimes?
I don’t think the first level of instruction material on lifetimes which is found
in the rust book and others which talks about the syntax and the aliasing rules and elision is enough.
It leads to an incomplete model which only frustrates when you discover its incompleteness.
Rust nominoc does go further. For example it shows with detailed examples how lifetimes start with
a let binding and how they interact with other lifetimes in the same scope.
This is fundamental stuff and absolutely essential to understanding.
But there are still aspects not covered there.
For instance I realized that lifetimes can be shrunk as needed by the compiler only from this
forum (thanks @vitalyd) which invalidated my previous model.
And I’m sure there are other aspects I don’t know about.
I think we just need one place where one can learn everything about lifetimes and be done with it. 難しいのはネストした場合のオブジェクトに対するイミュータブルかどうかとライフタイムだろう。 ライフタイムはコンパイラが親切丁寧に指摘してくれるから難しくは無いだろ
依存関係とか指摘出来ない系のエラーで詰まる事のが多い >>647
コンパイラに指摘されれば問題ないかというと総でも無い。
プログラミングはコンパイルする前に予想可能で無いと困る。 >>648
難しくないってのは「学習は」難しくないって話じゃね?
いずれは自分でわかるようになるというのは当然の前提で、
まあわかるようになっても間違えることはあるのでそれを指摘してくれるのもありがたい。 >>650
ところが、コンパイラを実際に動かさなくても、仕様書や例を見ただけで
理解できる言語も多いんだよ。
たとえば、CやBASIC,JS,Java,C#,Ruby,Python,Perlなどがそれに該当する。
C++は、03まではまあ分かったが、だんだん難しくなっていった。
もはやSTLのソースも仕様書ですらも理解できるのは一部の特殊な人に
限定されてきているかも知れない。STLの
forward()の意味を理解したりどう実装されているかをソースを見て理解できる
る人は本の一握りだろう。
move()とforward()の役割の違いも実装レベルでどれだけの人間が理解できることか。
でもRustも同じように難しくて同じようなことは起こると考えている。 そのレベルで理解できてない人がC++使うのはどういうメリットがあるのだろうか 実はC++は、forwardやmove, templateなどの詳細を理解できてなくても高級言語的な部分だけを使ってプログラムすることは出来る。
それはRustでも同じ。 C++は仕様が難しいというより
仕様ではないけど当然知ってるべきイディオムが
たくさんあってきつい、という感じがするな。 将棋しか知らない人が囲碁というゲームを見ると
何やってるかわからないしなんだかむずかしそうと言う
しかし実は囲碁はルールそのものはおそろしくシンプルなのだ
ところがルールだけ知っていても、囲碁は打てない
(打てるけど次に何していいかわからなくなる)
なぜなら囲碁はルールとは別に「こういう場面はこういう風に
打ち回す」というイデォムが大量にあってそれを知る必要があるからだ
C++はそれに似ている そもそもRustの仕様って難しいか?
いろんな言語から取り込んだ概念があって
C一筋とかRuby一筋みたいな人には学ぶべきことが多いとは思うけど、
特に複雑な仕様って思い当たらないんだけどな。
JSの型変換の仕様とかの方がよっぽど複雑だしワケわからんと思う。 >>651
C が仕様や例で理解できるってどんな超人だよ。
コンパイルエラーにも実行時エラーにもならない未定義だの処理系定義だのが山もりだろうが。
初心者の書くコードで完全に仕様に沿ったコードなんて見たことないぞ。 Haskell の入門書を一通りは読んでたから Rust の型システムは似たようなものとして理解できたなぁ。
ライフタイムもプログラムの字面に書きこそしないでも C/C++ では意識せざるを得ないし、
複雑になるとわけわからんってときは C/C++ で書いてもわけわからんようになるやつ。 きっとそういう感じでべた褒めする人が多いから、Rubyみたいに一回大人気言語になった後、急速に衰退する気がする。
Rubyも最初は良いと思われていた。 >>657
Cの仕様はシンプルで、
ポインタと明示的な型宣言と文字列比較をstrcmp()で行うという以外、
基本的な枠組みは既存の言語と変わりはなかったので理解は難しくなかった。 Ruby は今でも十分に使われているよ。 (俺は使ってないけど。)
適切ではないところまで広がった分がそぎ落とされてちょうどいい感じに落ち着いたってだけ。
プログラミング言語の良さはスカラ値で測定できるようなものではなくて、用途による。
利用事例が減ったからといってその勢いで衰退して消えるっていうような話ではない。
Rust はまだ実際のプロダクトでどう使うのが適切なのか見極め切れていないから過剰に広まっている
というのはあると思うが、少なくとも C/C++ で問題だった部分を解決したという側面はある。
そんでそのかわりに出てきた問題ももちろんあるので両方を天秤にかけて判断する材料を集めているとこって感じ。 >>660
うん。 C がシンプルで理解しやすいと思い込みやすい言語なのは俺も知ってる。 Google Trends によれば、検索数の増加曲線はほぼ kotlinと同じ位。
ただし、kotlinは、2017/05に急激に上がってRustと重なりあった曲線になったのに対し、Rustは、2014/01に急激に上がった後、徐々に増えている感じ。
Rustはこの1年くらいでわずかに増加速度がKotlinより上がったが、それでもKotlinの曲線とほぼ重なった状態からは脱してはいない。 >>662
匿名性掲示板では何でも言えてしまうが、実績を見れば俺がちゃんとCやC++を使いこなしていることは分かる。
ただし、C++は一度学んでも仕様が大幅に変更されるので、細かいところを理解するのは時間が掛かるようになってきている。
Cはそんなことはなかったが。 chronoつかってるんだけど、このyearってなんでi32なの?
https://docs.rs/chrono/0.4.11/chrono/offset/trait.TimeZone.html#method.ymd
fn ymd(&self, year: i32, month: u32, day: u32) -> Date<Self> >>664
仮に C や C++ を使いこなせているとして、
使いこなせている言語よりも使いこなせてない言語の方が難しいに決まってるじゃないの。
あなたはそうなんですねってだけ。 >>666
符号付きなのがなんでってこと?
month や day はマイナスになる意味はないけど、
年はマイナス (紀元前) を扱いたいこともあるんじゃね。
知らんけど。 C++の仕様が大幅に変更されたというのは
なんのことだ? >>670
有る意味では僅かな修正であっても、基礎的な部分における修正は多大な影響を及ぼすことがある。
moveを出来るようにするために追加されたもろもろの事や、=を書かないタイプの{}
による初期化はそれに該当する。
なんでも無いようでいて、可読性を下げたり危険をもたらすことがある。 >>662
Cほどシンプルな言語もないだろ。それと簡単に使いこなせるかは別問題。 >>666
そこに書いとるやん
This assumes the proleptic Gregorian calendar, with the year 0 being 1 BCE.
つまり-1は2 BC Cのプリプロセッサやパーサーを書くと全然シンプルじゃないことが分かる >>675
それは、使う側にはシンプルそうに見えるCも実は細かく見るとシンプルではないということであって、使う側目線で既に複雑なものはそれ以前の問題他。 依存先より寿命が長くなってはいけないなんていうのは C でも当たり前のことだろ。
Rust のライフタイムはライフタイムを簡単に「表現 (したものをチェック)」する言語機能であって、
C でプログラマがやってる (はずの) ライフタイムの管理より複雑ということはない。
Rust なら処理系がチェックしてくれることを
C ではプログラマがやってたんだぞ。
C で出来てたことが Rust ではやれないってのは言語のせいか?
Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
複雑だとか学習難易度が高いというのは納得しかねる。 >>677
>Rust のライフタイムの管理は制約が厳しいとか面倒くさいとかいうなら話はわかるが、
>複雑だとか学習難易度が高いというのは納得しかねる。
一つあるとすれば、難しさは、ちゃんと本も読んでいるか、ネットに書かれている情報だけに頼っているかの違いに起因している可能性。 これにて、このスレがRust関連の本の作者の巣窟であることが証明されました。 だいぶ前からじつは言語系のスレはほとんどソレなんだな
宣伝してるやつは気付かれれないと思ってるだろうけど >>618
2018/11/28の時点で、
https://www.infoworld.com/article/3324488/rust-language-is-too-hard-to-learn-and-use-says-user-survey.html
ユーザーの調査によると、Rust言語は習得も使用も難しい
Rustユーザーの調査では、メモリの安全性と正確性のためにこの言語の非常に宣伝されている機能に困難と不満を感じています
Rust言語チームが実施したRustユーザーコミュニティの新しい調査では、言語とその使用への関心が高まっていますが、プロジェクトが利点として宣伝しているいくつかのRust機能に対するユーザーの不満も示されています。
Rustの習得が難しいのはなぜですか?ユーザーは、Rustの最も特徴的な2つの機能(寿命と所有権/借用システム)は、「トリッキー」、「非常に難しい」、または「まだ得られない」ものであると報告しました。
その他の質問は、Rustを続行するための課題を中心に展開されました。Rustの使用をやめた人の約半分は、わずか1か月後にそうしました。Rustを使用していない最も一般的な理由は、「威圧的すぎる、習得が難しい、または複雑すぎる」(25%)、 Rust言語は、学んだり使ったりするのが難しすぎるということが、ユーザーに対する調査で分かった。
--Rustユーザーに対する調査では、安全性と正確性のために言語が非常にうるさく押し付けてくる特長により困難と欲求不満を感じていることが分かった。
Rust language is too hard to learn and use, says user survey
A survey of Rust users finds difficulty and frustration with the language’s highly touted features for memory safety and correctness.
tout = 押し売りする, うるさく勧誘する, 客引きする
(tout for custom うるさく注文を求める.)
・切符をプレミア付きで売る, ダフ屋をやる.
・うるさく勧める.
・ほめちぎる. 誤:安全性と正確性のために言語が非常にうるさく押し付けてくる特長
誤:安全性と正確性のために言語が非常にうるさく押し付けてくる機構(機能) >>674
へー。 西暦にゼロ年っていうのは無いのか。 この言語廃れてきそうな気がした。
だってみんなが触るって未来が想像できないもん Rustを使ったことはないけどC++は既存の資源で堅実に作るのに対して
Rustは一人のスーパープログラマが複雑高度なライブラリやモジュールを一点突破で書くのに使われそうなイメージ まあScalaと同じ道を辿るだろうね
あっちはビッグウェア系でそれなりに採用されてたから被害が甚大だったけど、
Rustに関してはそういうビジネス的な得意分野は今のところ無いのが救いか >>687
ところがスーパープログラマは、C++でもメモリー関連のバグで詰んで挫折したりすることはないんだな、これが。 >>687
Rust の偉大さのひとつには crates.io の存在がある。
資源の利用という意味じゃ Rust はかなり積極的だぞ。 C++は標準のライブラリリポジトリと標準のビルドツールがあればなぁ、と思う。
野良のは乱立してるけど、結局ほしいライブラリはなかったりするし…。 >>688
MicrosoftもAppleも使っていくのに爆死したら
IT業界壊滅じゃね >>691
各環境のパッケージマネージャに乗っかってることが多いからある意味では一等の地位ともいえる。
メジャーなものは apt-get とか pacman とかで一発で入るだろ。 >>690
crates.ioがダメダメだから代替のサイトあるのってご存知でない? >>691
漏れは、Windows 10, WSL, Ubuntu 18.04 で、
anyenv(rbenv)で、Ruby をコンパイルするのに、build-essential を使っているけど
build-essential には、
gcc(GNU C compiler), g++(GNU C++ compiler), libc6-dev(GNU C Library), make などが入っています
パッケージ: build-essential
https://packages.ubuntu.com/ja/bionic/build-essential >>693
結局それってディストリビューション依存だからなぁ。
バージョンだって固定できないし、OSS拾ってきてコンパイルが通るようにするだけで試行錯誤が必要。
>>696
いや、頑張って環境構築すればなんとかなるのはその通りだけど、
別のソフトだとまた別の環境構築が必要になって辛いのです。 Rustでプロキシーサーバー実装してみようと思ったんだけどTCPStreamとreqwest::headerの連携がうまくいかない 漏れは、日本人が作った、バージョンマネージャーのanyenv で、
rbenv, nodenv を使って、ruby 2.6.6, node 12.16.2 を入れた
環境構築が、各言語でバラバラになるのは面倒なので、
anyenv・asdf などを使えば? こんな書き込みを見つけた:
loop {
// 1. you finally understood lifetimes
// 2. you get compiler lifetime /borrow complaints
// 3. you feel stupid for taking hours to fix <5 LoC
} ループ {
// 1. あなたはついに lifetime を理解した。
// 2. あなたはコンパイラに lifetimeやborrow の苦情を複数個言われる。
// 3. 5行未満のコードを直すのに何時間もとられることにあなたは馬鹿馬鹿しさを感じる。
} コンパイラに緊縛されて未定義動作を踏まないという快感を得るプレイ Rsutって、早い話が、CやC++に、NULLバグ等々が発生しないようにするための補助機能がついた言語ってこと? そうだね〜、で、俺様はNullチェックは忘れないしダングリングポインタなんて組み込まないのでC/C++で良いや
という俺様スパハカがゴミグラムを生み出してきたのでRustは必須 >>704
書き方がC/C++の文化とはかけ離れているように感じるが。 >>706
いや、言語誕生の思想を考えただけです。
言語誕生の思想をきちんと抑えないと、メリットとデメリットを正答に評価出来ないから Hindley-Milner 型推論を元にしているから考え方は ML 系統からの影響は大きいと思う。 C++の地獄をML(とアフィン型)の知見で楽にしようとした言語
Cの遺産を引き摺ったが故に煩雑だった前者の記法を捨てて後者のいいとこを貰ってきたので、記法が後者に似てるように見えはするけど、やってる事はそう大きく変わってはいない 「C++ のメンバ関数の実態は this を暗黙に渡しているだけ」ってのを露骨にしたのも Rust の面白い部分だよね。
関数的な意味論を用いながらも構文糖としてのメソッド記法も用意することでオブジェクト指向的な表現が出来る。 RustはC++ではゼロコストで出来ていたものが、出来なくなってしまっていることが多い。 関数的な意味論ねぇ
表層的に一部それっぽいってだけでは? 言語として純粋関数型に分類される Haskell ですら
オブジェクト指向のスタイルで構築されたライブラリは有るから……。
(そのためのフレームワークである lens はまあまあ人気。)
言語仕様での理屈がどうあれ最終的には使い方次第。 memmove()すらunsafeなしではかけないし。 RustではpChildがHeapにとられている時、次のようなループすら書けない。
CPerson *pChild=pPerson->pChild;
while(pChild != NULL) {
(pChildに対する処理);
pChild=pChild->pNext;
} >>718
こういう感じのこと?
#[derive(Default)]
struct Person {
pub childs: Box<[Person]>
}
fn main() {
let person : Person = Default::default();
let childs = person.childs;
for ref child in childs.iter() {
// child に対する処理
}
} >>719
Heap領域にある構造体の中に、さらにHeap領域にあるデータへの
参照を持つためにBox型のメンバが有る場合、後者のBoxは、unique_ptrなので
ローカル変数にmoveすることができないためコンパイルエラーになる。
なので、参照カウント方式のRcを使う必要がある。 >>719 の場合だと personがスタック領域にあるが、もしそれがHeap領域に
あったとすると、
let childs = person.childs;
とするとエラーになるはずだ。 チュートリアルも読まない難癖おじいちゃんの相手すんなし そもそも、
struct Person {
pub child: Box<[Person]>
}
がおかしくて、正しくは、
struct Person {
pub child: Box<Person>
pub next: Box<Person>
}
だ。 >>722
全く同じではないが、こっちの環境ではなったがな。 後付けやめろよ。
C++ のどういうコードを Rust でどう書けて欲しい (そして実際にはどういうエラーになる) のかちゃんと書け。
いや、書くな。 (どうせ見当違いなので。) >>725
#[derive(Debug)]
struct TAaa {
x: Box<i32>,
y: i32
}
fn main() {
let mut vec:Vec<TAaa> = Vec::new();
vec.push( TAaa {
x : Box::new(333),
y : 444
} );
let x = vec[0].x; // error[E0507]: cannot move out of index of `std::vec::Vec<TAaa>`
println!("{:#?}", x);
}
↑のように vec をHeapに確保した場合、エラーになる。
ところが、stackに確保した場合はエラーにならない。
実験済み。 >>726
海外のサイトでも、RustはC/C++から単純移行ができ無い事が問題とされている。
FortranからCへは単純移行が出来たからCが普及したと書いてあった。 >>726
後付ではない。
C++で、pChild、pNextと言えば、当然そういう構造体になる。 >>727
型・寿命・所有権の条件が同じならヒープかスタックかというのは関係ない。
お前が結果的に違う条件で書いるだけ。
>>728
知らんがな。
同じように書けるんなら新しい言語を導入する意味ないだろ。
制約が厳しい替わりに問題点が検出されやすいのが Rust の利点なんだから、
その利点が要らんなら別に Rust を使わんでいいよ。 >>730
>型・寿命・所有権の条件が同じならヒープかスタックかというのは関係ない。
>お前が結果的に違う条件で書いるだけ。
1.実験してみたところ、>>727でBoxをRcに変えてもエラーのままだった。
2.単純にTAaaをスタックに確保した場合、正常にコンパイルされた。
3.TAaaを以下のようにHeapに確保した場合も、正常にコンパイルされた:
fn main() {
let bbb = Box::new( TAaa {
x : Box::new(333),
y : 444
} );
println!( "bbb = {:#?}", bbb );
println!( "bbb.x = {:#?}", bbb.x );
println!( "let x = bbb.x;" );
let x = bbb.x;
println!( "x = {:#?}", x );
}
つまり、Vec<TAaa>の場合にだけエラーになる。 >>731
ついでに言えば >>727 のエラーが出る行を
let ref x = vec[0].x;
とか
let x = vec.swap_remove(0);
とか
let x = vec[0].x.clone();
とかすることでもコンパイルは通る。 >>732
>let x = vec.swap_remove(0);
let x = vec.swap_remove(0).x
のことかな? rustじゃ書けないおじさんのコードを添削する流れ、何度目だ >>733
おっと、せやな。
.x が無くてもコンパイルは通ってしまうからミスったわ。 >>734
ワイも初心者ではあるんよ。
The book (第二版の日本語訳の無料で読めるやつ) を読み終わって、試しに 500 行くらいのコードを書いてみたって程度。
本を読んでいる間はコードを書いてない。
手を動かすと理解しやすいという人も多いけど、
感覚でやってしまいがちで書いてある理屈をしっかり把握するのが疎かになる気がするから。
で、 The book を読めばこの程度には理解できるので理解できてないやつは単にアホという証明でもあるし、
逆に返答に詰るようなら俺がまだ入門級のことが理解できてない (どこが理解できていないか) ことがわかるので
練習の題材としてちょうどいいわという気持ちで相手してた。 >>738
では、>>732 で
>let ref x = vec[0].x;
の borrow が合法かどうか、どうやってコンパイラが静的に解析しているか
アルゴリズムを説明してみてください。 >>739
let ref というのは直接的には The book に出てこないと思うけど、
let もパターンマッチだということはタプルの項目で示されている。
たとえば let a = &1; と書いたら a には 1 の参照が入るし、
let &a = &1; と書いたら a は (参照を経由する) 値になる。
参照にマッチするのではなく値にマッチさせた上で参照が欲しいときに使うのが
ref であるということは match の説明の中にある。
つまりこの場合に let ref x = vec[0].x; というのは
let x = &(vec[0].x); と書くのと理屈は同じ。 公式で丁寧にしかも無料で公開されてる本もろくに読めないガイジたちがわらわらするスレになっちまったな
ちょっと名が知れ渡っただけでこんなことになんだから、一般的になったらとんでもないな rust+wasmちょっとやってみたけど、単純な処理に記述だけが無駄に複雑になりすぎる
組み込みとかシステム系で使われそうだけど、一般的とか言う広く色々な使われ方はしないだろコレ JSみたいに直接DOM触れて、直接実行できるなら普及するけど、現状のめんどくささならなぁ・・・ >>740
それは分かっている。
iとjがループ内で変化したような場合、
vec[i].x
からmutableで借用した場合、
vec[j].x
からimmutableで借用できるかどうかの判定をコンパイラが一般的に行うのが難しいんだよ。
だからそのアルゴリズムを理解しているのかと聞いている。 >>744
似た例で言えば、
dst[i]をmutableで借用した場合、src[i]をimmutableで借用しようとしたときに、
srcとdstが同じアドレスに被って無いかの判定が静的には物凄く難しいと
されているので、エラーになってしまうかも知れないというようなことを心配
しているんだよ。 >>745
もっとちゃんと書くと、
src[0]〜src[99]までに対して処理するような場合だと、src[i]をaに借用してから
f(a)、g(a)、h(a)に順番に渡して何か処理するようなことは出来ると思われるが、
ここに、dst[0]〜dst[99]も加わって、dst[j]をbにmutableで借用
しようとすると、mutableで借用した場合にimmutableでは借用できないというルールを
この場合にはコンパイラが静的には判断できなくなってコンパイル・エラーになって
しまう可能性を心配している。
つまり、コンパイルの借用チェッカは、予めよくあるパターンに対して特別な
処理を実装している場合には通るが、一般的には判断できるわけ無いので通らない
のではないかと考えられるんだよ。 let x = 5;
println!("{}", if 0 < x < 10 { "in" } else { "out" });
この比較方法ができない理由ってなんかある?例えば最適化に響く?とか
可読性も労力もこれ出来たほうがいいと思うんだけど 最初の比較でBoolになってんのを整数と比較してるからじぇね?
特に可読性が上がるとも思わないし、むしろ老眼で見逃す勢が出るから&&挟んだ方が見やすいな その書き方ができる言語は割と少数派な気がする
pythonではできるが a < x > b
これを見て何がしたいのか直感的に理解できる人間は多数派ではないだろう
結局 lb < x < ub のパターンしか使わないんなら range で十分 >>744-746
こういう感じの話? (※ 構造体を介する意味がないのでこの例では省略)
fn bar(vec: &mut Vec<usize>, i: usize, j: usize) {
let ref x = vec[i];
let ref mut y = vec[j]; // エラー
println!("{:#?} {:#?}", x, y);
}
fn main() {
let mut vec: Vec<usize> = vec![1, 2, 3];
bar(&mut vec, 0, 1);
}
vec の所有権が貸し出されるので一律に出来ない。
可能性を心配する必要はないよ。
普通の借用ルールが適用されて確実に出来ない。 (unsafe を使わない限り。) しかもそいつら繋がってんのな、Rust大嫌いなのに隠してここでやりとりしてんのな
とりあえず二人とも気持ち悪いからミュート、ブロックした
https://qiita.com/Yutaka_Aoki
https://qiita.com/SFITB 少なくともMozillaのステマが〜とか言ってた頃よりだいぶましだと思うが。 dropが飴玉みたいって批判?がちょっと面白かった。
その発想はなかった的な。 drop out とか drop off とかのニュアンスでしょ?
スコープから消えろという意味での drop であって、結果的に解体もするというのは実装側の都合だよな。
その型を利用する側の都合からするとただ消えろって話なので、drop という語をあてるのは Rust 的にはそこそこ妥当な選択だと思える。
やることが同じだから同じというのは抽象化を軽視する暴論だ。 linuxカーネルでキャッシュをドロップする、みたいなのが用法としては近いのかな。 >>756
https://twitter.com/YutakaAoki3/status/1270069950581858309
同一人物説
dropって命名はかなり絶妙だと思う。
時点でscoped outから取ってoutとかがいいと思うけど、outだけだと抽象的すぎるからdropが一番いい
https://twitter.com/5chan_nel (5ch newer account) そもそもdropって表現使ってる言語なんかなかったっけ?? ネイティブが決めた名前をJapsが文句言うのは流石に草 実際にプログラミングするのは英語話者ばかりではないので
既に浸透した用語を使って欲しいというのはわからんでもないんだが、
似て非なるものに同じ名前を与えると調べにくかったりすることもあるしなぁ。
他の言語からの「移行」という視線でばかり見ていると良くなった部分も移行コストに見えてしまうんだなというのはわかった。 そもそもdropについて言えば既存の言語でも
free, delete, dispose, finalizeとバラバラなので
浸透もクソもない。 それぞれの用語の大まかな使い分けはあるけども、
じゃあ drop がそのどれかに当てはまるかといえば当てはまらないし。 qiitaの記事数は、Rustに対し、Goが8倍、Kotlinが1.5倍、C++が50倍、Javaが16倍。
唯一、Haskelに対しては、Rustは、100倍以上の記事数がある。 Haskelは触ったことのある人数で言えばRustよりずっと多いだろうけど、マサカリが怖くて記事書きづらいんだろう 宣言型マクロでRustの処理書けない理由ってある?
今のパターンマッチ風構文で作ったから処理文入れるところがない的な? ガチ関数型と違って難しいポイントはただ複雑なだけなので、頭悪くても慣れさえすればマウンティングしやすいのが人気の理由だと思ってる 「一番愛する言語」と聞かれたら、C++もC#もJSもPythonも全面的に好きで
使ってるわけではないから、消去法でRustを選ぶしかない。
そもそも愛すべき言語なんて一般人にはあるわけ無いし。
Rustだったら「愛すべき」と公表しても馬鹿にされないで済むみたいな。
他のどの言語を選んでも、白い目で見られそうだから。 ドキュメントを眺めてたら >>587 は Nightly ではこんな感じで書けるかなって思った。
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=75b0cca2f785445e707b113c1bce3b55 >>774
SOのサーベイのことをいってるなら、あれは別に「愛する言語は何ですか?」というアンケートではないので「愛する」と日本語で考えてもあまり意味ないぞ。
いまRustを使っていて今後も使い続けたいですか?という質問の集計結果をmost loved languageと表現してるだけ。
だから仕事で(嫌々でも)使わざるを得ない言語は低く出るし、Rustみたいに趣味で選んでる言語は高く出るのだろう。 >>776
Rustを愛すると答えた人でも、 使っている人は5%程度しかいないと書いてあったから、
「いまRustを使っていて今後も使い続けたいですか?という質問の集計結果」
とは違うはずだ。
使って無い人も「好き」と言えた訳だから。 >>777
ちょっと正確な質問は忘れたけど、
問1 最近よく使う言語はなんですか?
問2 その言語を今後も使い続けたいですか?
みたいな質問で、1でRustと答えた人の86%が2でyesと答えたって話。
(で、その86%ってのが全言語で1位だった)
なので5%の人しか使ってないというのとは別に矛盾しないし、
Rustを使ってない人の意見はそもそも反映されない。 このあたり元のアンケートに答えた人や
SOのレポートを隅々まで読んだ人なら分かるんだけど
ニュースサイトの伝言ゲームで「最も人気のある言語」とかになってしまうと
ものすごく語弊があるんだよな。 >>778
あれ?
それだと、全体の母集団の中でRustを使っている人が5%ということになってしまい、
「Rustが好きです」、と答えた人でも 95%が使ってないということとは違ってくるよ。 >>780
使ってる人が5%というのは合ってて、
その5%のうちの86%が今後も使いたいってこと。
だからRustを好きな人が多いんじゃなくて、好きな人の割合が高いというだけ。
実際に好きな人の絶対数でいけば、ユーザーの多いPythonとかが圧勝だと思う。 >>775
Default::default() が panic したときに drop で未初期化領域アクセスして UB になりそう >>783
unwind の段階でってことですか? >>784
そう
何らかの工夫を入れないといけない気がする 要素がMaybeUninitなので未初期化領域にアクセスすることはないだろうけど、逆に初期化済みの領域が解放されずに残るような? >>786
panic したときのことなので UB でさえなければメモリが解放されないのは問題にならないと思いますが。 copylessっつうcrateがあるからそれ使うか参考にするといいかもよ >>783
Default::default() が panic起こす実装してるからUB以前にそこを直すべきだと思うけど違う? playgroundで手続きマクロ書きたいんだけど
#![crate_type="proc-macro"]
で出来なくてCargo.tomlも触れないから変更出来ないんだけどどうやっても触れない?? 弱参照を多用する人っていないの?unsafeが基本? こういうコードを書いててどこを直せばいいかわかんないので教えてーー
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4ce583191e5b07279b8ec65ef5198456
AddAssign の型引数のところに与えてるライフタイムがおかしいとは思うんだけど、
どう直せばいいかわかんない。
この書き方だと += の左辺以上の寿命を右辺が持ってるという意味になるの? あんまり詳しくないけど、ライフタイムのその書き方でエラーなるってバグじゃない?(推論力の問題?)
個人的に気になるから詳しい人教えて欲しいな
一応これで治るけど
impl<T: AddAssign<T> + From<usize> + Clone> Iterator for Fibonacci<T> {
type Item = T;
fn next(&mut self) -> Option<T> {
swap(&mut self.f0, &mut self.f1);
self.f1 += self.f0.clone();
Some(self.f0.clone())
}
} デフォルトで usize を基礎に据えているんですが、 BigUint なども効率的に扱いたいので
clone はなるべく少なくしたいという意図で参照で受け取る AddAssign を前提にしたいんですよね……。 >>793
これでどう?
impl<T> Iterator for Fibonacci<T>
where
T: From<usize> + Clone,
T: for<'a> AddAssign<&'a T> >>796
期待通り動きました!
for の使い方について調べたところこのへんにあるのを見つけたのですが、
どうにもはっきりとは理解できてないです。
https://doc.rust-lang.org/nomicon/hrtb.html
AddAssign が必要とされる個別の場面まで寿命の推測を遅らせるみたいな感じですかね? むしろ >>793 がどう解釈されてしまっていたのかにも解説が欲しい…… なんか見覚えある気がすると思って考えてたんだけど、
Haskell の forall と似てるんだな。
>>793 だと Fibonacci<T> の T の制約として解釈されてしまうから、
'a は Fibonacci<T> と同じ寿命ってことになっちゃうわけか。 あるフォルダーに入っているファイルをWeb経由で見れるようにしたいのだがそういったことができるクレートあったりしますか?
現在Actix+teraで実装しようと考えていますがなかなかうまくいかないので・・・ python3 -m http.server 8000 actix-webとactix-filesではだめなの Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
http://localhost:8080 >>803
rustのスレまで出張ってくるなよジジイ なぜrustでactix+tera を使いたいのか
学習目的? そういや、actixの作者がやる気なくしてた問題は解決したの? あの「とほほのWWW入門」に「Rust」と「Go言語」の入門コンテンツ追加へ【やじうまWatch】 - INTERNET Watch
https://internet.watch.impress.co.jp/docs/yajiuma/1260986.html
このサイトまだあったんだな >>805
あのテンプレートの書き方がDjangoに似てたので・・・(じゃあPythonでやれっていうのはなしで)
別に使わなくてもできるのならそれでいいんですが この前作ったツールではrouilleを使った
CLIツールにおまけのWeb UIを付けるため
シンプルで良かった アプリケーションの設定を管理するようなライブラリで変更時に知らせてくれるような機能があるのってgioクレートのSettings以外になんかありませんか? const fn b(s: &'static str) -> usize {
s.len()
}
fn a(s: &'static str) -> usize {
b(s)
}
a("c");
const fn のこの例ってこの下に置き換えられる?
それともaがconstじゃないから置き換わらない?
fn a(s: &'static str) -> usize {
1
} >>812
定数伝搬の最適化はconstとは関係なくかかるので
その例なら1になるかと。
const fnはconst値にバインドできるかどうか、というだけのはず。 >>813
じゃあハッシュテーブルとかのキー定数とかもコンパイル時にハッシュになってるの? ハッシュ値の生成に乱数使ってるからコンパイル時には決定できないはず
const fn な hasher が仮に存在するならハッシュ値まで生成されるかもしれなち >>816
ハッシュに乱数を混ぜるのは普通にある。
もちろんそのハッシュテーブルの寿命の間は一貫した値を使うけど。 普通に、はなくね?
素数のマジックナンバーと比較してデメリットしかない
汎用性が下がる
コードが煩雑になる
テーブルサイズの整数倍になって効率低下する確率が上がる >>817
>ハッシュテーブルの寿命の間は一貫した値を使うけど。
キーの値から、ハッシュ値を計算する際、乱数を使っていて、
一貫した値をどうやって取得するの。
// pszKey = キーの0終端文字列
// 戻り値 = キーに対応した Hash値
DWORD CalcHash( const char *pszKey )
{
DWORD hash;
・・・
hash += 乱数; // こんな風にして、どうやって一貫性を確保する??
・・・
return hash;
} hasherの初期化に乱数使う
ハッシュ値の生成のされ方が決定的だと
ユーザーが悪意のある入力列を与えることでハッシュ値の衝突を起こしてシステム負荷を高めるような攻撃ができちゃうのよ
それを避けるために多くの処理系では hasher の初期化に乱数を使ってハッシュ値の生成のされ方を予測しにくいようにしている 乱数使うのは hasher の初期化だけで、
その後のハッシュ値計算は当然乱数は使わない システム負荷を高めるような攻撃を回避するのって初期化に乱数使うとかじゃなくて、ハッシュテーブルの実装次第じゃね?
システム再起動の時に乱数で変わってたら保存してるハッシュと違くなるって整合性ぐちゃぐちゃすぎる
ちなみにRustは初期化に乱数使ってないけどどの言語がそれに当たるの?
悪いけどホラ吹いてるようにしてみえない >>824
By default, HashMap uses a hashing algorithm selected to provide resistance against HashDoS attacks. The algorithm is randomly seeded and …
https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html ハッシュの生成はアルゴリズムに対して決定的なんだからハッシャーがどうのなんて馬鹿げてる Result<T,E> を要素とするイテレータを Result<Vec<T>,E> にしたくて、
よくありそうなパターンだと思うんだけどさらっと上手くやる方法ってないもんかな? >>828
collectがいい感じにやってくれるよ。 collect::<Result<Vec<_>, _>>() 毎回乱数使ってるなら画面更新するたびにハッシュ変わるはずだよね?
https://play.rust-lang.org/?code=%23!%5Ballow(unused)%5D%0Afn%20main()%20%7B%0Ause%20std%3A%3Acollections%3A%3Ahash_map%3A%3ADefaultHasher%3B%0Ause%20std%3A%3Ahash%3A%3AHasher%3B%0A%0Alet%20mut%20hasher%20%3D%20DefaultHasher%3A%3Anew()%3B%0Alet%20data%20%3D%20%5B0x01%2C%200x23%2C%200x45%2C%200x67%2C%200x89%2C%200xab%2C%200xcd%2C%200xef%5D%3B%0A%0Ahasher.write(%26data)%3B%0A%0Aprintln!(%22Hash%20is%20%7B%3Ax%7D!%22%2C%20hasher.finish())%3B%0A%7D&edition=2018
変わらないよ? >>831
HashMapと同じことをしたいなら、RandomStateからbuild_hasherでhasherを得ればよい。別に画面更新しなくてもRUN押す度に変わるよ。 ちなみにDefaultHasher::newで変わらないのは、単に内部的にSipHasher13::new_with_keys(0,0)を呼んでるから。
RandomStateがその0,0をランダムに変えている。 Hash値の計算そのものも、本当はかなり速度が求められるものなので、それを
自在に変えるというのはどうやっているのか興味が有る。
Hash値そのものの計算は、遅いわけではないが、それでも膨大なデータを処理する
場合には、その問題になることがある。 SipHasher13::new_with_keys(0,0)はソルト?シード? >>830
えっ、それでいけたんだ……。
知らんかった。 collectが中でやってる事って std::convert::from か? >>839
FromIterator::from_iter呼んでる
From呼ばれるかどうかはFromIteratorの実相次第だけど
普通はIterator::Itemがそのままコレクションのデータ型になるから呼ばれないと思う これがコンパイルエラーになる(sum::<i64>()としないといけない)のってなんでですか?
let s: i64 = (0i64..10).sum() + 10i64;
推論できる材料は十分に見えるんですけども
ちなみにこれなら通ります
let s: i64 = (0..10).sum(); >>841
ここに理由書いてるけど、詳しくはわからん
At the moment, we always refuse to guess the "self" type, so we just stop there.
For other type parameters, if Self is known, we will sometimes infer them based on Self
https://github.com/rust-lang/rust/issues/25094#issuecomment-304079316 >>843
下位互換失うからじゃね?
>because it leads to regressions when new impls are added. 今までターボフィッシュで型指定しなくても動いてたものが
新しいimpl追加によって型指定がないと動かなくなるケースがあるというのは理解できる
ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね
//iter::Iterator::sum
fn sum<S>(self) -> S where Self: Sized, S: Sum<Self::Item>
{
Sum::sum(self)
}
//iter::Sum
pub trait Sum<A = Self>: Sized {
fn sum<I: Iterator<Item = A>>(iter: I) -> Self;
} >>845
まず、
1) inference type(推論された型)と宣言時や実行時の型は別なんで、実行時の型はあくまで推論された型の外延でしかない。
すると、別の型互換のルール(たとえば、部分多相とか)がないと互換の型とみなせない。
2) 公開された部分を推論すると将来の変更で1)から互換性を失う場合がある。
最近型推論導入した言語が公開関数のシグネチャ等を推論しないのはこの問題が理由だと思う。
>ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
>各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね
これは単にメソッド呼び出しの生成規則: expr0 ". " expr2 [Turbofish] "()" のexpr0から推論しないルールが既にあるからできないだけじゃないの?
これを拡張すると2)から互換性を失う可能性がある。公開された型と関数のシグネチャに依存してるんで。 Rustの構文を自分でPython風にしてるんだけど、このwhereのとこの構文がどうも末尾:と相性悪くてどうしたら綺麗になるか教えて欲しい。
問題点
* Self: Sizedの型指定の:と被る(引数の型はかっこに埋まってるからいい)
* 一行目の関数宣言の:があるのに二行目でもwhere使うために:がある(二行続くのは英文法的にもおかしい)
* whereの構文ルールが曖昧(改行入れたりできる) -> だから統一したい
fn sum<S>(self) -> S:
where Self: Sized, S: Sum<Self::Item>:
Sum::sum(self) Rust にトランスパイルされる Python 風構文の言語を作っているということかな?
fn sum<S>(self) -> S
where Self(Sized), S(Sum<Self::Item>):
Sum::sum(self)
こんな感じで class の継承っぽく書くのはいかが そう、そういう言語作ってる最中。
たしかにその構文もいいね!でもstruct S(i32);に見た目上だけど被るのと、トレイトのfn name<T: Num>とかも構文変える必要でてくるなぁ
個人的にはトレイトベースの言語だからT: Numは変えたくないだよね
こういうのもいいかも
fn sum<S>(self) -> S,
(Self: Sized, S: Sum<Self::Item>):
whereと同じような機能でしっくりくる構文持ってる他言語とかないのかなぁ Winrtよく知らないんだけどWindows環境でGUI簡単にいじれるようになったの? let delta = input[0] - input[1];
println!("{}{}", if delta == 0 { "" } else if delta > 0 { "-" } else { "+" }, delta.abs());
このif delta == 0 { "" } else if delta > 0 { "-" } else { "+" }の綺麗な順番とかの定石の書き方ってある? match delta.cmp(&0) {
std::cmp::Ordering::Equal => "",
std::cmp::Ordering::Greater => "-",
std::cmp::Ordering::Less => "+",
} n == 0の時だけ記号なしにしてそれ以外は{:+}でフォーマット
(n > 0の時だけ{:+}にするのでも結果は同じ) 両方有るってことはどっちにでも出来るってこった。
どちらかが良いなんてことはない。 以下のコードでクロージャclの引数に型推論が効かないのってなんでですか?
fn main() {
let vv = vec![vec![1, 2, 3]; 4];
let cl = |a, b, c, d| vv[a][b] + vv[c][d];
//error[E0282]: type annotations needed
println!("{}", cl(3usize, 1usize, 2usize, 2usize))
}
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a49b194930fcdfd894c2be4fc078be80
クロージャclの引数のところを |a: usize, b, c: usize, d| とすればコンパイルは通るのですが、aとcだけ型注釈が必要になるのも意味がわからないです jsonをパースして、その中身に対して更に値を追加し
最後にはまたjsonでシリアライズということをやりたいのですが、
serdeだと事前に入力と出力の型を定義していないと難しいですか?
from_stringでValue型に入れて、mapのようにキー名で値を取れることは分かったのですが
そこに新たに値を追加する方法がわからないです >>863
ありがとう神様
C#ならすぐなのに、
これは理解するのに時間がかかりそうだ。 スライスから差集合を作るの際にスライスをそれぞれhashsetにしてdifference呼ぶ以外で良い書き方ありますか? >>869
シンメトリックじゃない単なる差集合なら
片方だけsetにしてもう片方の要素でループしながらチェックするのでもいい気がする
あと状況によってはBroom filterみたいなのを使うと高速化できるかも fn aaa(s: &str) {
if s == "aaa" {
compile_error!(r"If s is "aaa", compile error!");
}
}
fn main() {
// compile error!
aaa("aaa");
// can compile
aaa("aaaaaaaa");
}
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな
↓
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルエラーになるんだけど回避方法ってないかな ダブルクォートがaaaの部分で外れてるのが原因とかじゃなくて? >>875
ごめん。ここに貼る用のデバッグコメ。
そこ直したら本題の条件分岐のコンパイルエラーにならないのがでてくる
compile_error!(r#"If s is "aaa", compile error!"#); compile_error!は条件付きコンパイルかマクロでしか使えないんじゃ?
compile_error!と記述してる行がコンパイルするコードに含まれることになったらコンパイルエラー
マクロを展開する段階では変数の値を評価できないから
文字列を受け取る関数に対して特定の文字列を渡すコードがあったらコンパイルエラーってのは無理な気がする 最近RustのSlackでも出てきた福野泰介ってやつ声でかいよな
こいつどのコミュニティでも何かしら主張して目障りだわ Ubuntu Japanese Team に言いつけて潰してもらおうぜ 環境はMacOS Catalina, Rustは1.45.0です
今弄ってる物(https://github.com/Nercury/rust-and-opengl-lessons)で
/lib/gl/src/lib.rs内に
include!(concat!(env!("OUT_DIR"), "/binding.rs"));
というのがあるのですがですがcargo buildすると
this error originates in a macro
error: couldn't read /Users/Path/target/debug/build/gl-71effbf83f5b03a9/out/binding.rs: No such file or directory (os error 2)
と表示されます
https://github.com/rust-analyzer/rust-analyzer/issues/1964
https://github.com/rust-skia/rust-skia/issues/10
などを見たのですが具体的な修正がわかりませんでした。
Rustは最近始めたばかりでincludeマクロやcargoの仕組みなどまだあまり詳しくありません
このinclude!を成功させる方法を教えてください
迷惑をかけてしまうかもしれませんがご教授お願いします 福野泰介はたしかにどこでも目立つ。
自己顕示欲もあそこまでいったら面白い、反面教師として役立つ >>882
lib/gl/build.rsでOUT_DIRにbinding.rsを作成してる
ビルドスクリプトが意図した通りに動いているのか確認するために
build.rsを変更してbinding.rsのフルパスをprintlnでもするようにして
cargo build -vvしてみるといいと思う
ビルドスクリプトについて詳細知りたければこの辺読んで
https://doc.rust-lang.org/cargo/reference/build-script-examples.html >>884
ありがとうございます動きました!
非常に長文だった自覚はあるんですが分かりやすくすっきりした回答ありがとうございますm(_ _)m 同じサーバー内でポート別にクライアント用サーバー(Nuxt)とAPI用サーバー(Rust)立ち上げるのってどう思う?
クライアント用サーバーは初回しか性能響かないからあれだけど、Rustの方が断然速いし、SPAだからルートの設定も全然しなくていいし、Rustの方でフロントページも返した方がいいんじゃないかと思ってるんだけども
要はRustを実行すればポート別に2つサーバーが立ち上がるようにするってこと RocketってRust公式サイトにも使われてるのか
迷ったらRocketで良さそうだな rustcの-C llvm-args=が取り得るオプションの説明ってどこかに書いてある?
clangのttps://clang.llvm.org/docs/ClangCommandLineReference.html#x86
あたりがそれっぽいけど説明が全くないのでデフォルト値も効果もよく判らない あるモジュールクラスを別のモジュールで使いたい場合ってどう宣言するのが正しいの?
正直ドキュメント読んでも分からん >>890
サンキュ。そう使うのかよw うちの環境では
>rustc -C llvm-args=--help ←'を付けると怒られる
でそれっぽいのが得られました。amd64で使用命令を選択するようなオプションは無いのか・・・ --helpの最後に出てたけど
利用可能なオプションを全部表示するには
llvm-args=--help-hiddenってするみたい chronoのnext_monthないのってどう実現すればできる? >>894
そもそもnext_monthに何を期待するかによると思うが。30日後?31日後?翌月の同じ日?それが存在しない場合は?とか。その辺がはっきりすれば、その通りに実装すればいい。 >>896
ありがとう、結局next_month自分で実装したけど、かなり頻繁に使われる類のメソッドだから正直きついな
with_monthもoptionで返すから31 -> 30の次月遷移したとしても安全だから実装しない理由が分かんないな
chronoは変なとこには手回ってるしよくわからん >>897
issueはあるけど別に誰かが反対しているわけでもなく、
単に誰も実装してないだけじゃない?
PR出してみればいいと思うけど。
https://github.com/chronotope/chrono/issues/290 >>891
じけつ
main.rsでそれぞれのモジュールをmod宣言 ed25519の公開鍵のssh-ed25519 ******の部分が欲しくて、ed25519_dalekっていうクレートで鍵作ってるんだけどPublicKey構造体のas_bytesでとってくるバイト列をstr::from_utf8でしてもエラーが出て秘密鍵の***部分にならないんだけど、どうすればいいか分かる?
https://docs.rs/ed25519-dalek/1.0.0-pre.4/ed25519_dalek/struct.PublicKey.html 1byteずつ print!("{:02x}", b) するとかではなく? >>900
str::from_utf8でエラーになるのは
0~127までのUTF-8互換のASCII以外の文字が含まれてるからでは?
pemで見れる公開鍵のssh-ed25519 ******の部分は
keyの種別とDERエンコードしたkeyの値をBase64にしたものらしい >>901
やってみたらエラーはでないし、ハッシュっぽいものできたけど、大文字ないから >>902の方法っぽいかも
4ef6dcfda191770b64939c5657fc26e631c2caffa18e423c397d761d507ae82a%
>>902
ありがとう、やってみるわ bindgenにwindowsはllvmのプリビルドバイナリをインストールしなさいと書いてあるけど、
LIBCLANG_PATH設定し忘れるとwinのプリビルドバイナリには含まれてないllvm-configを使って<LLVM_ROOT>/binまでのパスを探すんで
llvm-configがないって怒られる罠がある。
LIBCLANG_PATHタイポして時間潰してしまった。 unsafeの個数が少ない方が勝ちって事でいいんじゃない? rocketってmultipartサポートしてないのか unsafe という機能があるのは unsafe が必要だからです。
設計方針に対して必要以上に unsafe があるのはダメですが、
少なければ少ないほど良いというわけでもありません。
たとえば C++ を使っているときだって、
グラフィックドライバを書くときとかは
どうしたって (C++ 的には) 行儀の悪い書き方になってしまうでしょう。
行儀の悪い部分はなるべく低レイヤに押し込めて、
ロジック層が綺麗になるようにするのが望ましいなどといった習慣はありますが、
どの程度にするかの程度問題は設計方針によります。
actix は rocket よりも unsafe を多用してはいますが、
意図のはっきりした unsafe です。
あまりにも unsafe が多すぎるならもう Rust 使うのやめろよと思うかもしれませんが、
行儀の悪い書き方 (unsafe) がより明示的であるというだけでも
C++ よりは少しマシでしょう。 出てますよ。
あなたがそれをキャッチする立場にないだけです。 stdの中でこれは外部ライブラリにした方がいいんじゃないかなって思うやつある?
逆に外部ライブラリからstdにした方がいいんじゃないかってやつとかもある? >>914
乱数ライブラリが標準ライブラリに入ってない言語とか他にあんの? 乱数は用途によって必要な性質が色々だからなぁ。
どの分野を優遇すべきかってのは自明ではないでしょ。
全部盛りにするのも Rust 的ではないし。
でも、どの乱数ライブラリを使うにしても同じようなインターフェイスだとありがたいので、
乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
そのサンプル的な位置づけでひとつくらいは乱数ライブラリが入っていてもいいかなとは思う。 >>917
メルセンヌツイスタは統計的な性質は良いけど暗号的には使い物にならんしデカい。
常にベストと言えるほど良い選択ではないよ。 >>918
確かに暗号にMTを使うのはダメですね、暗号用には crypt-MT がありますね 今はもうMTもそこまで・・・って話じゃないっけ
randクレート見るとそんなこと書いてあったような 他の言語だって完璧な乱数だと思ってなくても
利用者の利便性を考えて標準ライブラリに含めてるんだろ
それが無いRustは変 今どきMT法なんか使わん。
>乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
rand_coreがそれに当たるけどcoreだけだとバイト配列しか取得できんので分布器に生成器渡せん。
未知の生成器の実装すべて含めるのは無理、既知のものに絞っても要求する特性が人によって違うから標準にするのは無理。
結局はこうなるが、俺も標準ライブラリに乱数ほしい。 cargo使ってるから別ライブラリでもあまり困らない
こと乱数に関してはデファクトスタンダードのcraete決まってるし迷うことないしね
標準ライブラリに入ってて欲しいのは初学者がcrate知らないとか探すのが手間だとか、コンパイルタイムが延びるのが嫌だとか、そういう理由? stdに入れて欲しいのはrandよりregexだな
標準ライブラリとして責任もってメンテされていくものなのかどうかが重要 >>924
あちこちのcrateでregex使ってるから
コンパイル遅くする原因になってるわ Authors のところが The Rust Project Developers ってなってるやつは
事実上の標準みたいなもんと思ってええんけ?
将来の互換性が保証されるかどうかはともかくとして Rust と足並みがそろっているとは
思っていいよね? 外に出されたunicode系ライブラリが更新止まってていつかstdがサポートするunicodeのバージョンと互換性失うんじゃないかと思う。
>>926
事実上の標準っていうかc++のboostみたいなもんだけど足並み揃ってるかは別。 use std::ops::{Rem, AddAssign};
pub fn get_days_of_month<T: Rem>(year: T, month: u32) -> u32 {
match month {
2 => if is_leap_year(year) { 29 } else { 28 },
4 | 6 | 9 | 11 => 30,
_ => 31,
}
}
pub fn is_leap_year<T: Rem>(year: T) -> bool {
match ((year % 100 as T) as i32, (year % 400 as T) as i32) {
(_, 0) => true,
(0, _) => false,
_ => year % 4 == 0,
}
}
pub fn next_day<N, T: AddAssign + Rem>(mut year: T, mut month: u32, mut day: u32) -> (T, u32, u32) {
let days_of_month = get_days_of_month(year, month);
day += 1;
if day > days_of_month {
month += 1;
day = 1;
}
if month > 12 {
year += 1;
month = 1;
}
(year, month, day)
}
non-primitive castエラーが出るんだけどどうすれば解決できる?
1 as Tでもできないし、1.parse()はstrじゃないから出来ない >>929
num-traitsのOneで制約すればT::one()でT型の1が得られる。 >>930
i32 か u32を受け取るトレイト境界ってつくれない?
あとAdd<u32> for u64とかの実装していない理由とかって何? >>931
自分で作ればいい。
型変換は明示的にしろ、ってことだろう。 >>933
個人の開発に使ってるけどバインディングだらけになる。
ミドルウェア1から作る新規開発くらいじゃないとrustの恩恵がフルに受けられないと思う。
あと、コンパイル遅いのが辛い。 ラズパイとかでコンパイルすると糞遅いのなんとかならんかな 禁断のCPU換装とかないの?
DOS/Vパワーリポートとか買ってみたら。 rustじゃないけど適当な設定で大きいライブラリビルドしたら過熱でラズパイ落ちた事あるわ rustって日本で人気という勝手なイメージがあるけど世界的にはどうなんだろ ルスト?なにそれ?てかそんなの聞いた事ないんだけど >>941
Goの方がマスコットがかわいいからしゃーない。 >>944
いやいやいやいy・・かわいいかアレ??
どぉおおおおおみてもキモい >>941
調査によって、まちまちだな。
StackOverflowでは、Rustは好きな言語ランキングでは、五年連続Topらしいが、
「人気」は低い。
今のところ「好き」だが「人気」は無いのがRust。
恐らくこの場合、「人気」= 「Popular」のことで、英語の Poluarは、
「人気」と言う意味のほかに、「普及している」とか「一般的」、というような
意味もあるのでややこしい:
https://news.mynavi.jp/article/20190412-807191/ 「好き」ならば「学びたい」のだろう、と思いきや、そうでもないということか。
「最も好きな言語は何ですか?」
という問に対して、相手に馬鹿にされないためには、Rustが丁度よい言語
である気はする。
でも、結構、実際に使用したいと思っているどうかは別。
俺もそんな質問されたら、答えに窮して Rust と答えてしまうかも知れんが、
使う気はほぼ無い。 Rustはターゲットになる開発領域が狭くてどう足掻いても大人気誰も彼もRust!なんてことにはならないよ
C++が広範な領域で使われてたのは選択肢のなさとWinのAPI基準の1つなのとCとの運用のしやすさ
選択肢が増えてWinもよっぽどなことしなけりゃC#があるしCをコールする分にはどの言語も十分改善されてきた
0から作るある程度のパフォーマンスを求めるプロダクトならGoがあって、アセンブリと連携するけどcgoのオーバーヘッドやGCのオーバーヘッドが気になるみたいな際際じゃなけりゃRustにならない
計算高速化のcalleeとしては安全性があまり旨味のない要素だからC++の選択がまだ強い
以上に加えてエラー周りとかアセンブリ連携もnightlyがあってまだ熟してない部分があり厳しい立ち位置にいるという認識だ >>949
>計算高速化のcalleeとしては安全性があまり旨味のない要素だからC++の選択
C++ が呼ばれ側になるのですか? >>949
その中だとパフォーマンス的にはGoでいいけど言語仕様が簡素すぎて辛い、みたいな層の受け皿としてRustが使われてるケースはありそうかな。
ScalaがいいけどJVMは厳しい、みたいなのとかも。
まぁニッチなのは間違いない。 Microsoftが興味持ってるからC# + Rustが未来の姿だ
UIはC# >>950
TensorflowとかPytorchのバックはC++だよね
これらは当然CUDAとの兼ね合いであるのは間違いないけど、CUDA側がRustではなくC++を選択してる意図として安全性の旨味のなさは間違ってないと思う
C++の仕様が先立つ言語であることや人口の多さ、既存資産との兼ね合いの比重のが大きいだろうけどね >>953
そりゃCUDA1.0の頃(もう10年以上前だぞ)にRustなんて影も形もなかったんだから選択されないのは当然だろう。
その視点で見るならここ1-2年で開発開始されるプロジェクトでどの程度採用されるか、では?
今だとブロックチェーン界隈とかかね。 >>949
rustは元からサーバーは視野に入れてないだろ "abc".split("").collect::<Vec<_>>()は["", "a", "b", "c", ""]になるんだけど、うまく空白なしでスプリットでできない? .charsじゃなくてどうしても.split使ってvecにしたいってことなのか? "abc".split_terminator("").skip(1).collect::<Vec<_>>();でできるけど
普通はchars使うやろ >>957
charだとparse()がなくて変換めんどくさい
あと容量無駄 charと&strって&strのがでかくね???? >>960
Splitは
type Item = &'a str
だから無駄に生成しないって意味ね >>961
でも最後にVecに格納するポインタは一文字ごとに8バイト取られるんだから、charの方が小さくない? &strはfat pointerだから16byte じゃね 確かに16バイトだね。parseにしてもto_digitでいいし、Vec<&str>のメリットはなさそう。 Rustのコア開発者達がMozillaのリストラで大量解雇されたようだが大丈夫なのか? MozillaとRust Core Team、Rustの非営利団体を立ち上げへ
https://mag.osdn.jp/20/08/20/104100
Mozillaのプログラミング言語「Rust」を開発するRust Core TeamとMozillaは8月18日、独自の非営利団体を立ち上げることを発表した。Mozillaの大規模なリストラ計画を受け、Rustプロジェクトの安定を図る。
Mozillaは約250人規模の人員解雇計画を明らかにしているが、この中にはRustプロジェクトやコミュニティにアクティブに参加しているメンバーも含まれるという。
この再編計画がプロジェクトとしてのRustに対する不確実性を生んでいることから、非営利団体立ち上げを急ピッチで進めることにしたようだ。
なおRustにはMozilla外部からの貢献も多く、Mozilla内部の開発者の多くも余暇を使って参加しているため、Mozillaの再編計画によりプロジェクトが大きな影響を受けることはないとしている。 解雇された人のtwitterとか見てると
「弊社でRust書きませんか?」なオファーが殺到って感じだし
個人の生活としてはそんなに問題ないんじゃないかな。
Rustの開発に割ける時間が増えるのか減るのかは知らんが。 Rust財団作って開発と管理を移管するのかね
その後プラチナスポンサーにMicrosoftがいても驚きはないな >>966の記事でも触れてるけどrustはコントリビュータが多いからmozillaの再編は影響すくない。
mozillaの中のままでmozillaの計画の影響受けたら面倒くさいからこの際独立しようって考えだろうね。
といかMozillaのはアフターコロナを見据えた再計画なんでアメリカにしてはコロナに関してはまともな部類なんだけど国内でどう見られるかだね。 僕も解雇されてニートになったんで暇つぶしにRust始めようかと思うんですがRustって個人の趣味として使うならナンセンスなんですか?
WinのGUI開発しようと思ってるんですがあんまり情報ないですよね PythonとJSをちょっと書けるくらいなんですが
Rustを勉強する前にCをやったほうがいいですか? >>976
一度Cを書かないとRustのありがたみの半分が理解できないよ 世の中にはドキュメントを読んで納得できるタイプの人と
実際に自分で罠にはまってみないと納得できないタイプの人がいる。
自分が後者だと思うなら一度Cで苦しむのがいいんじゃないかな。そうじゃないなら不要。 RustってC/C++の代替って言うけどそもそも今時Cって使う?
趣味で使ってる言語の1位がRustだって記事もあったけどCで何作るの?
なんでRustがこんなに人気なのか理解できない Linuxの基本的なコマンド(ls,grep等)を高機能にした代替コマンドがよくRustで作られてる >>984
よく勘違いされることであるが、Cが昔から使いこなせている人は、Rustでなくても、
特に問題を感じていなかったりする。 よく勘違いされることであるが、Cが昔から使いこなせてると思ってる人は、
単にバグに気付いてないだけだったりする。
真面目な話、組み込み系のシニアエンジニアにありがち。
オフラインの家電やってる頃は良かったんだろうけど、
ネットに接続とかやるとたいていやらかす。 Cでマルチスレッド書けって言われてもバグる自信しか無いわ
C製ツールをRustで書き直したものはマルチスレッド化して高速化してるわけだしな LinuxカーネルハッカーというCの超ベテランからも
LinuxにRustも使いたいという話が出るくらい C使えるけど気苦労多いしRustの方が良い
Cを積極的に使う理由は少ない 単に文字列扱うだけでめんどくさくなって
「仕様削ってintにしていい?」と言いたくなるのがC >>984
rustを評価する際にC/C++の代替なんて誰も言ってないよな。mozillaも評価いいMSとかも。
C++より安全って言ってるのを外野がC/C++の代替と言い出したのが
ろくにrust書いてない連中が呪文のように唱えだしただけだと思う。
C++の代替になってもCの代替にはならないと思う。
>>991
早くuchar.hを自分で用意する作業に戻るんだ! 逆にCの代替になる必要はないと思う
CとのFFIは不自由なくできるわけで
むしろFFIが不自由なC++の代替にはなりづらいと思う Cの代替ってのは別にCの用途すべてを置き換えうるって意味じゃないでしょ
ripgrepとか見れば十分Cの代替と言える 例えばQEMUなんかは既存のCの書き直しは大変過ぎるからやらないけど、
新規開発のデバイスエミュレーションコードはRustでって言ってるね。
そういう代替の仕方もあると思う。 >>989
その人が、凄腕プログラマーとは限らないが。 Linuxのカーネルハッカーが、凄腕プログラマとは限らないと言っているんだ。
プログラマの世界は、レベルの差が大きいから、その程度では凄腕には
分類されない。
例えば、VzEditorのc.mosさんは、その程度ではなかった。 >>999
お前よりはカーネルハッカーの方が腕も頭も良さそうだな このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 210日 23時間 25分 20秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。