Rust part14

**デフォルトの名無しさん** · 2022/02/12(土) 01:24:16.59

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

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part13
https://mevius.5ch.net/test/read.cgi/tech/1636247099/

**デフォルトの名無しさん** · 2022/02/12(土) 01:27:40.45

Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/

**デフォルトの名無しさん** · 2022/02/12(土) 01:28:24.19

Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust async-std Book
https://book.async.rs/
Rust The Unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
The Rust Reference
https://doc.rust-lang.org/reference/
The Rust Standard Library
https://doc.rust-lang.org/std/

**デフォルトの名無しさん** · 2022/02/12(土) 13:48:10.54

新スレ乙です

前スレ994流れてたので
（以下引用）
struct S;
impl Drop for S {
fn drop(&mut self) {
println!("drop");
}
}
fn main() {
S;
}
↑じゃあこれは何が所有権をもってて何がdropさせてんの？
インスタンス説のほうがまだシックリくる？
変数も所有権を持てるしスコープ終了で手放せる？
（以上引用）

この場合はmain内の
S;
のところに隠れた一時変数がいて
{ let _s = S; }
みたいに変換されると考えれば自然だと思う

**デフォルトの名無しさん** · 2022/02/12(土) 13:53:07.63

前スレ>>994
匿名の一時変数(temporary)が所有者になってenclosing scopeを抜ける時にdropが呼ばれる

公式の見解とは違うけど変数じゃなくスコープが所有者になるという捉え方のほうが分かりやすければ別にそれでもいいと思う
実装的にはその方が近い

**デフォルトの名無しさん** · 2022/02/12(土) 13:54:01.32

すまん、モロ被りした

**デフォルトの名無しさん** · 2022/02/12(土) 16:30:44.26

>>4 >>5
それで正解。

所有権については公式がこう↓うたってんだから、値だとかインスタンスだとかいってる奴は公式に文句言えと。

4.1. What is ownership?
（ttps://doc.rust-lang.org/book/ch04-01-what-is-ownership.html）

Ownership Rules

First, let’s take a look at the ownership rules.
Keep these rules in mind as we work through the examples that illustrate them:

* Each value in Rust has a variable that’s called its owner.
* There can only be one owner at a time.
* When the owner goes out of scope, the value will be dropped.

**デフォルトの名無しさん** · 2022/02/12(土) 16:59:30.70

非同期のデファクトライブラリはtokioかと思うがasync-std使ってる人おる？

**デフォルトの名無しさん** · 2022/02/12(土) 17:24:19.71

sqlxがasync-stdのサポート切るって聞いたけどほんと？

**デフォルトの名無しさん** · 2022/02/12(土) 23:26:08.10

>>5
同感
変数に入れないまま関数の戻り値となったり
その関数の戻り値が変数に入れないまま式の中で消費もしくは移動することが多い
そしてdropタイミングはスコープを抜ける時
だから変数よりもスコープが所有権を持っていると考えた方がより近いとの考えに同意する
ただし同じスコープ内で別変数へ移動させた場合もスコープ視点では移動なしとなる
それはdropに関して全く問題ないが変数間の移動を表現しきれていない

一方で属する変数もスコープも移動により次々と移り変わって行く
だから所有権と1対1でリンクしていて不変なものはインスタンスだというのも納得できるしそれ自体は正しく確定
ただし所有権と1対1でリンクしているインスタンス自体も移動していくからその移動を表現しきれていない

したがって
『所有権と1対1でリンクしているのは当然インスタンスとしつつも
そのインスタンスが代入や式や戻り値で使われるたびに変数もしくは見えない一時変数に必ず入っていると考え
さらにその変数が属するスコープの中にインスタンスが毎回イドウすると考え
他へ移動されぬまま属するスコープが消滅するとインスタンス及びその1対1となる所有権も消滅する』
というのが正確なところなのであろう

ただしそれでは学習するには長すぎるから大幅に端折って>>7の定義で良いと思う
そして学習した後で端折ってある部分が上述の長い説明だと後で理解できれば十分なのではないだろうか

**デフォルトの名無しさん** · 2022/02/12(土) 23:33:37.93

>>8
使っている

>>9
その議論を少し読んでみたけど
サポート続けるべきの声もある程度あるし
何らか用途ごとにもう少し抽象化したインタフェースを確立して両立利用できるようにすべき声もあるようだ
明るい未来になるとうれしい

**デフォルトの名無しさん** · 2022/02/13(日) 09:35:24.39

見えない一時変数とか想像しなくても
オーナー変数がある場合は
* There can only be one owner at a time.
* When the owner goes out of scope, the value will be dropped.
で、無い場合は
* When the value ほにゃららタイミング, the value will be dropped.
と公式で書いてくれてたらスッキリなのにな

**デフォルトの名無しさん** · 2022/02/13(日) 11:34:54.98

>>12
一時変数は想像上の産物ではないよ
リファレンスに変数の一つとして定義されてるし
どういう時に一時変数が作られるのかも定義されてる
The Bookに詳しく書いてないだけ

**デフォルトの名無しさん** · 2022/02/13(日) 11:56:22.68

>>13
勉強になりました

https://doc.rust-lang.org/reference/variables.html
> A variable is a component of a stack frame, either a named function parameter,
> an anonymous temporary, or a named local variable.

https://doc.rust-lang.org/reference/expressions.html#temporaries
> When using a value expression in most place expression contexts,
> a temporary unnamed memory location is created and initialized to that value.
> The expression evaluates to that location instead, except if promoted to a static.
> The drop scope of the temporary is usually the end of the enclosing statement.

匿名一時変数は式の終わりでdropされそうやね

**デフォルトの名無しさん** · 2022/02/13(日) 12:07:59.97

おっと式じゃなくて文の間違い

**デフォルトの名無しさん** · 2022/02/14(月) 21:08:19.96

外部ライブラリを使わずに
コマンドライン引数の処理を昔ながらのシェルスクリプト風に処理したい場合
こんな感じでいいのでしょうか？
let mut args = std::env::args().peekable();
let cmd_name = args.next().unwrap();
let usage = || {
eprintln!("Usage: {cmd_name} [-d] [-q] [--] <target>");
std::process::exit(1);
};
let mut is_debug = false;
let mut is_quiet = false;
while let Some(b'-') = args.peek().and_then(|arg| arg.as_bytes().first()) {
let option = args.next().unwrap();
match option.as_str() {
"-d" => is_debug = true,
"-q" => is_quiet = true,
"--" => break,
_ => usage(),
}
}
if args.len() != 1 {
usage();
}
let target = args.next().unwrap();
もっと楽に記述できるよ、とか、もっと無駄を省けるよ、とか
何でもいいのでアドバイスお願いします

**デフォルトの名無しさん** · 2022/02/15(火) 00:56:03.94

peekableにする意味ある？
手間かかってるだけに見えるし-o output.txtみたいなオプション引数も扱えなくならない？

**デフォルトの名無しさん** · 2022/02/15(火) 16:20:56.03

look aheadのパターンにしたかったのかな
Peekableならnext_ifがいい感じにはまりそう

...
let mut is_debug = false;
let mut is_quiet = false;
while let Some(option) = args.next_if(|s| s.starts_with("-")) {
match option.as_str() {
"-d" => is_debug = true,
"-q" => is_quiet = true,
"--" => break,
_ => usage(),
}
}
if args.len() != 1 {
usage();
}
...

**デフォルトの名無しさん** · 2022/02/15(火) 22:18:31.12

>>17
そういうのは >>16にこれ追加で行けそう
"-o" => output = args.next().or_else(|| { usage(); None }),

**デフォルトの名無しさん** · 2022/02/15(火) 22:42:34.06

ところで
>>16の as_bytes().first() と
>>18の s.starts_with("-") はどっちが速いのかな？
今回は誤差として例えば数万行のテキストで＃から始まるコメント行を除外したい場合
最善手は何？

**デフォルトの名無しさん** · 2022/02/15(火) 23:44:22.03

どちらも文字列の先頭数byte参照するだけだから大差ないよ
as_* じゃなくて to_* を使うとかだと差が出るかもね

**デフォルトの名無しさん** · 2022/02/16(水) 01:25:58.91

短くてもいつもの汚コード氏だと分かるコードなのがすごい

**デフォルトの名無しさん** · 2022/02/16(水) 18:46:05.60

>>20
他にも色々方法がある
例えば落とし穴だが一番表記が短いスライス &(&s)[..1]
ただし空行をs.len()で回避した場合でも
if "#" == &(&s)[..1] { これは先頭が非ASCIIだとpanicなので注意
utf8境界を見極めて最初の1文字を取り出すには面倒で
if "#" == &(&s)[..s.char_indices().nth(1).unwrap().0] { となり本末転倒
なので最初の1文字を取り出すには普通はイテレータchars()を使って
if Some('#') == s.chars().next() { となるが
今回は正しく先頭1文字ではなく先頭1バイトを取り出せれば判断できるので
if Some(b'#') == s.bytes().next() { の方が速い
しかしイテレータを使うまでもないから
if Some(&b'#') == s.as_bytes().get(0) { と配列アクセスでも十分だろう
先頭は需要が大きいためなのか
if Some(&b'#') == s.as_bytes().first() { と専用メソッドが用意されてるようだ
ただしここでもサボって
if b'#' == s.as_bytes()[0] { とすると空行でpanicするので注意
以上ここまでは先頭取り出し系だがシンプルに
if s.starts_with("#") { が一番わかりやすい
ただしこれは実装でinline指定がないから不利で遅いかもしれない
inlineで&[u8]に読み替えるだけの as_bytes() は確実に速い
あとは get(0) と first() がどちらもinlineでコードが
前者が if self < slice.len() { unsafe { Some(&*self.get_unchecked(slice)) } } else { None }
後者が if let [first, ..] = self { Some(first) } else { None }
たぶん展開して最適化した最終コードは同じになるのではないか
そしてSomeやNoneは最適化で if Some(&b'#') == 部分と反応しておそらく消えると予想しているが
if let [b'#', ..] = s.as_bytes() { と最初からOption使わなければその点も確実という結論か
あとはみんなでツッコミしてくれ

**デフォルトの名無しさん** · 2022/02/17(木) 10:37:24.58

premature optimizationの典型例
このレベルの最適化が本当に必要ならまずは計測しろ

**デフォルトの名無しさん** · 2022/02/17(木) 10:41:11.69

百理ある

**デフォルトの名無しさん** · 2022/02/17(木) 11:01:53.16

結論の if let [b'#', ..] = s.as_bytes() { なら可読性も落ちず意味もわかりやすいからいいんじゃね？
それを満たした上で長さが0でないことと先頭バイトの定数比較コードになると誰もが予測可能

**デフォルトの名無しさん** · 2022/02/17(木) 11:06:38.82

うーんRustのデフォルトがムーブになっているのはおもしろいな
かなり思い切った設計をしている

**デフォルトの名無しさん** · 2022/02/17(木) 11:42:39.48

千里ある

**デフォルトの名無しさん** · 2022/02/17(木) 12:41:58.72

>>20
リテラルなら差はないみたいね
https://godbolt.org/z/hGrPEa5rc

**デフォルトの名無しさん** · 2022/02/17(木) 23:06:37.97

あらためてRustは凄いな
enum Optionで意味わかりやすく安全にプログラミングしつつ
生成コードからはSomeやNoneが綺麗に跡形もなく消え去ってC言語で書いたときと同じになるんだな

**デフォルトの名無しさん** · 2022/02/17(木) 23:36:39.74

ML系言語の概念とC的な低レイヤの概念を融合した上で
オブジェクトの依存性の概念も付け加えるというのは実に素晴らしい考えだと私も思う。
個人的には Haskell が好きなんだけどランタイムサポートが重すぎると思ってたので Rust は大歓迎だ。

**デフォルトの名無しさん** · 2022/02/17(木) 23:47:52.93

ヒープを使うか使わないかと
dynを使うか使わないかの2点だけは
コンパイラも最適化できないのでそれだけ気をつけていれば大丈夫

**デフォルトの名無しさん** · 2022/02/18(金) 08:09:00.13

>>32
boxを使わない時は常にスタックじゃないの？

**デフォルトの名無しさん** · 2022/02/18(金) 08:29:45.01

>>33
BoxだけでなくVecやStringなどもヒープを使う
配列[T;N]や配列を使ったArrayVecやArrayStringなどはスタック上のみ使う
dynはBox<dyn ...>の形ならヒープ上だけど&dynの形ならスタック上のみで使うことができる

**デフォルトの名無しさん** · 2022/02/18(金) 09:51:02.85

>&dynの形ならスタック上のみで使うことができる
ん？

**デフォルトの名無しさん** · 2022/02/18(金) 10:17:03.62

>>35
例えば標準入力stdin()とファイルFile::open()は型がStdinとFileで異なるが
どちらもtrait Readを実装しているから&mut dyn Readに入れることで同じコードでreadできるようになる
このdyn Traitをtrait objectと言って動的ディスパッチとなるが生成コードは一つになる
ちなみにimpl Traitだとコンパイル時に静的に解決されて生成コードは型毎に多数のコードが生成される

trait objectは?Sizedだから直接は扱わずに&dynの形かBox<dyn>の形で使うことになる
&dynの形ならスタック上のみで使うことができるが元の型よりは長く生きられない制限がある
そこで例えば関数の返り値にしたい時などはヒープを使ってBox<dyn>の形にして返す

**デフォルトの名無しさん** · 2022/02/18(金) 18:16:26.39

Box<T>の形ならヒープ上だけど
&Tの形ならスタック上のみで使うことができる

と言われたら、ん？ってならない？

**デフォルトの名無しさん** · 2022/02/18(金) 18:18:33.56

ヒープ使わないんだったら、そりゃスタックになるが、
そもそもなにか勘違いしてない？

**デフォルトの名無しさん** · 2022/02/18(金) 19:03:20.48

&dyn の形ならスタックで "も" 使うことができる
ってこと？

**デフォルトの名無しさん** · 2022/02/19(土) 02:35:40.94

dynはヒープを使わない
しかしサイズが不定
つまりdyn型の変数はない
スタック上で使う時は&dyn型の変数に入れて用いる
戻り値にしたいならBox<dyn Trait>
これはヒープ使うことになる

**デフォルトの名無しさん** · 2022/02/19(土) 03:42:10.99

(stable rustでは) dyn 型の変数はない
が正しい

**デフォルトの名無しさん** · 2022/02/19(土) 13:30:36.11

>>40
strはヒープを使わない
しかしサイズが不定
つまりstr型の変数はない
スタック上で使う時は&str型の変数に入れて用いる
戻り値にしたいならBox<str>
これはヒープ使うことになる

これでも
んー・・・ってならないならもういいや

**デフォルトの名無しさん** · 2022/02/19(土) 15:49:52.73

その置き換えは無理があるんじゃないか
&strは単なる参照で&strの一部でもStringの一部でも代入できる
&dyn Traitはそれを実装する具体型を代入することで生成される

**デフォルトの名無しさん** · 2022/02/19(土) 18:01:00.26

&dynの参照先はヒープ（例えばBoxの中身）の可能性もあるからヒープを使わないって表現は誤解を招きそう

**デフォルトの名無しさん** · 2022/02/19(土) 18:59:15.30

>>41
stable前提話でごめん
unsized localがstableとなるには
一旦可変長配列を切り離さないと厳しい？

>>44
そんなことを書いてる人はいない
俺が書いた分も、dyn自体は(arrayなどと同様に)ヒープを使わない、だけだぞ
しかもその後にBoxでヒープを使う話もしている

**デフォルトの名無しさん** · 2022/02/19(土) 22:32:05.29

>>43
&strがstrへの参照であるように
&dyn Traitもdyn Traitへ単なる参照
&strにStringを代入すればDerefがstrを生成してるように
&dyn ReadにFileを代入すればコンパイラがdyn Readを生成してる

BoxだけでなくRc<dyn Trait>とかも使えるからね

**デフォルトの名無しさん** · 2022/02/19(土) 23:18:16.06

>>46
自己矛盾を起こしているぞ2点も
まず1点目
前者はターゲットstrでimpl Deref for String実装というコードが実際にありその枠組みに従った規定通りの操作
後者はそのような枠組みも実装コードも公開されていない操作
次に2点目
前者はStringの一部を指しているだけであり何か新たな実体を生成してそこを指しているわけではない
後者はFileとは別にvtableなどの実体を生成している
このように明白に異なる

**デフォルトの名無しさん** · 2022/02/20(日) 01:59:50.05

>>47
strとtrait objectという別のものなんだから違いがあるのは当たり前
>>40と>>42の対比が成立しないと言えるような違いを指摘しないと意味ないよ

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

>>47
>前者はStringの一部を指しているだけであり何か新たな実体を生成してそこを指しているわけではない
>後者はFileとは別にvtableなどの実体を生成している

ああ、なるほど
trait objectが生成されるときにvtableも生成されると思ってるのか

**デフォルトの名無しさん** · 2022/02/20(日) 02:49:14.40

dynにキャストするときにコンパイラがfat pointerから参照させる用のvtableを生成することを指しているのでは？

**デフォルトの名無しさん** · 2022/02/20(日) 03:20:02.69

>>48
そのように大きく違いのある全く別のものを対比させるのは無意味なので、置き換えは無理があるんじゃないか、と書いた

>>49
そこは実行時にvtableを生成とも誤解しかねない書き方をしてすまん
vtable自体は型とtraitのペアで静的に確定するものでありコンパイル時に生成している

**デフォルトの名無しさん** · 2022/02/20(日) 10:31:39.82

>>50,51
vtableはtrait objectの有無に限らずtrait実装につき1つコンパイル時に作成されそれが共有して使われる

vtableを指すtrait objectも実行時じゃなくコンパイル時に作成される
実行時にはvtable経由のダイナミックディスパッチが発生するだけ

**デフォルトの名無しさん** · 2022/02/20(日) 11:23:51.17

>>52
そうか、crate内で静的ディスパッチしかしてなくても他crateからtrait objectとして使われる場合もあるから常にvtableは生成されるのね

ちなみに、object safeでないtraitについては生成されない (できない) よね？

**デフォルトの名無しさん** · 2022/02/20(日) 13:54:46.64

Rustって関数のデフォルト引数ないの？

**デフォルトの名無しさん** · 2022/02/20(日) 14:48:11.68

>>53
trait objectとして使われなくても常にvtableが作成されるかどうかはコンパイラの最適化の話だからここでは関係ないよね
実際のところはdylibじゃなければコンパイル時に使われないことがはっきりしてるはずだから作られないと思うけど

**デフォルトの名無しさん** · 2022/02/20(日) 17:48:45.70

>>55
コンパイル時じゃなくてリンク時の最適化の話じゃないの
オブジェクトファイルには常にvtable埋め込まれてるのかと
それとも dyn Trait を使った側のcrateのオブジェクトファイルにvtableは埋め込まれる？

**デフォルトの名無しさん** · 2022/02/20(日) 22:19:41.32

>>51
>> vtable自体は型とtraitのペアで静的に確定するものでありコンパイル時に生成

>>52
>> vtableはtrait objectの有無に限らずtrait実装につき1つコンパイル時に作成

この件だがコンパイラのソースを見ると
必要となる型の分だけコンパイル時にvtableを作成してるよな
https://github.com/rust-lang/rust/blob/stable/compiler/rustc_codegen_ssa/src/meth.rs#L53

**デフォルトの名無しさん** · 2022/02/21(月) 00:37:14.94

crateあたり同一traitのvtableは最大一つ生成されるということかな

**デフォルトの名無しさん** · 2022/02/21(月) 00:58:29.74

同一traitが複数の型で実装されてたらその型ごとに作られるはず

**デフォルトの名無しさん** · 2022/02/21(月) 17:43:56.41

各型毎にtrait objectやvtableはこういう構造になっている
let mut stdin: std::io::Stdin = std::io::stdin();
let addr_stdin = addr!(stdin); // &mut借用する前にアドレスを得ておく
let dyn_stdin: &mut dyn std::io::Read = &mut stdin; // ここで dyn Readのtrait object作成
assert_eq!(val!(addr!(dyn_stdin), 0), addr_stdin); // 前半は元のstdinを指している
// assert_eq!(val!(addr!(dyn_stdin), 1), 【Stdin用のvtable】); // 後半はStdin用vtableをを指している
assert_eq!(val!(val!(addr!(dyn_stdin), 1), 3), <std::io::Stdin as std::io::Read>::read as usize);
assert_eq!(val!(val!(addr!(dyn_stdin), 1), 4), <std::io::Stdin as std::io::Read>::read_vectored as usize);

別の型でも同じようにdyn Read作成
let mut file: std::fs::File = std::fs::File::open("/dev/null").unwrap();
let addr_file = addr!(file);
let dyn_file: &mut dyn std::io::Read = &mut file; // trait object作成
assert_eq!(val!(addr!(dyn_file), 0), addr_file); // 前半は元のfileを指している
// assert_eq!(val!(addr!(dyn_stdin), 1), 【File用のvtable】); // 後半はFile用vtableをを指している
assert_eq!(val!(val!(addr!(dyn_file), 1), 3), <std::fs::File as std::io::Read>::read as usize);
assert_eq!(val!(val!(addr!(dyn_file), 1), 4), <std::fs::File as std::io::Read>::read_vectored as usize);
上述Stdinの時と同じ位置にFile用のread()やread_vectored()がvtableに入っていることがわかる

したがって>>59や>>51が正しいと思う
各trait毎にvtableのメソッドの位置が決まり
そのtraitを実装する各型毎にvtableが作成される

**デフォルトの名無しさん** · 2022/02/21(月) 18:18:27.01

traitをimplした型が違ったら対応するfnの中身も違うので
同じtraitでも実装された型ごとに違うvtable作らなきゃいけないのは確かに当然か

>>60
異なるcrateからtrait object生成した場合にvtableは同じアドレスのものになるの？
それとも、異なるものになるの？

**デフォルトの名無しさん** · 2022/02/21(月) 23:56:22.93

>>57
「trait objectを使うようなコードが一切存在しなくても」vtableが作られると言いたかったわけではないんだが書き方が悪かったね

**デフォルトの名無しさん** · 2022/02/22(火) 00:04:11.51

vtable自体はデバッグビルドのasmやllvm-irで確認できるよ
例えばxという名前のメソッド1つだけ持つFooトレイトのi32実装ならこんな形でvtableが出力される

.quad core::ptr::drop_in_place<i32>
.asciz "¥004¥000¥000¥000¥000¥000¥000¥000¥004¥000¥000¥000¥000¥000¥000"
.quad <i32 as playground::Foo>::x

**デフォルトの名無しさん** · 2022/02/22(火) 11:55:50.79

>>61
crateごとじゃなくcodegen unitごとにvtableが作成される可能性が一応ある
crateが違っても必ずしも複数のvtableができるわけではない

**デフォルトの名無しさん** · 2022/02/22(火) 12:24:58.23

違う型のvtableがmergeされることもあるみたい
https://rust-lang.github.io/rust-clippy/master/#vtable_address_comparisons

**デフォルトの名無しさん** · 2022/02/22(火) 12:36:19.01

>>64
前者は分かるんだけど後者はどういう時にそうなるの？
依存crateにvtableが含まれてる場合？

**デフォルトの名無しさん** · 2022/02/22(火) 14:56:23.72

>>60
もう少しvtableの情報を詳細にした
let mut file: std::fs::File = std::fs::File::open("/dev/null").unwrap();
let addr_file = addr!(file);
let dyn_file: &mut dyn std::io::Read = &mut file;
という状況で以下が成立

assert_eq!(val!(addr!(dyn_file), 0), addr_file);
let vtable_file = val!(addr!(dyn_file), 1);
assert_eq!(val!(vtable_file, 0), std::ptr::drop_in_place::<std::fs::File> as usize);
assert_eq!(val!(vtable_file, 1), std::mem::size_of::<std::fs::File>());
assert_eq!(val!(vtable_file, 2), std::mem::align_of::<std::fs::File>());
assert_eq!(val!(vtable_file, 3), <std::fs::File as std::io::Read>::read as usize);
assert_eq!(val!(vtable_file, 4), <std::fs::File as std::io::Read>::read_vectored as usize);
つまり型情報が消失したdynにおいてもこのvtableさえ保持していれば正しくトレイトメソッドやデストラクタを呼び出せる

>>65
そのコードだと比較しようとしているのはvtableやそのアドレスではなく
上述コードでのdyn_fileのアドレスを比較しているだけなのでそもそも前提が謎だな
さらにvtableの内容は各型に完全に依存しているからmergeの意味もよくわからない

**デフォルトの名無しさん** · 2022/02/22(火) 15:27:07.33

空traitなんかは異なる型同士でvtable使い回しできるのでは
あとは全associated fnにデフォルト実装が与えられていて中身が全く同じものとか
いずれにせよLLVMがよしなに最適化してくれるとかなのでは？

**デフォルトの名無しさん** · 2022/02/22(火) 17:06:00.72

vtableにはデストラクタも乗ってるようだけどそれも必要ない場合あるもんな
>>67の状況も今後実装が変わったり最適化で消えたり色々ありうるわけだ
いずれにせよ我々は興味本位で語り合ってるだけであり
このあたりの非公開の仕様に依存したコードを書いてはいけないしな

**デフォルトの名無しさん** · 2022/02/22(火) 23:08:55.74

>>67
>上述コードでのdyn_fileのアドレスを比較しているだけなのでそもそも前提が謎だな
Rc::ptr_eqで単純に比較するとfat pointer内のdataへのpointerとvtableへのpointerの両方が一致してるかのテストになる

>さらにvtableの内容は各型に完全に依存しているからmergeの意味もよくわからない
わかりやすいのは&Tと&mut Tのように可視性のみ違う場合

**デフォルトの名無しさん** · 2022/02/22(火) 23:17:56.21

>>70
dataへのpointerの一致を見てるなら
型を含めた一致が保証される？

**デフォルトの名無しさん** · 2022/02/22(火) 23:33:33.79

>>66
>依存crateにvtableが含まれてる場合？
そうだね
依存crateに含まれてても同じ内容のvtableができる場合もあるみたいだからいくつか条件があるみたいだけど

**デフォルトの名無しさん** · 2022/02/22(火) 23:44:43.85

>>71
std::ptr::eqでdataへのpointerを比較すれば保証されると思うよ

**デフォルトの名無しさん** · 2022/02/23(水) 08:40:05.57

プロジェクトのディレクトリの外から
$ cargo run
するときってどうやってプロジェクト (ディレクトリ) を指定するの？

**デフォルトの名無しさん** · 2022/02/23(水) 10:36:44.63

https://github.com/rust-lang/cargo/issues/1485

**デフォルトの名無しさん** · 2022/02/23(水) 15:08:57.81

>>74
用途が違うかもしれんがworkspace配下からなら-p <package-name>で指定できる

**デフォルトの名無しさん** · 2022/02/23(水) 23:58:29.92

>>70
vtableがmergeされるのかどうか
trait定義methodの定数返しと最適化されやすいようにして
さらに &T と &mut T でやってみたがtableは別々になった

まず最初の原因はvtable最初の要素である以下が成立していないためとわかった
assert_eq!(std::ptr::drop_in_place::<&i32> as usize, std::ptr::drop_in_place::<&mut i32> as usize);
ところが--releaseにすると上記は成立するようになった
同様にtrait定義methodも--releaseにすると同じアドレスとなった
つまりこういう実験において--releaseオプションは必須
そしてvtableの内容は全て完全に一致
しかしvtableのアドレス(格納場所)は異なり別々のvtableのままであった

**デフォルトの名無しさん** · 2022/02/24(木) 00:46:54.35

LLVMの最適化で何が行われるかrust側では保証できないから >>65 みたいに同一性について保証しないって仕様になっているんだろうね

**デフォルトの名無しさん** · 2022/02/24(木) 00:52:17.43

そういえばRustってC++とかFortranみたいに最適化で結果変わる可能性ってあるの？

**デフォルトの名無しさん** · 2022/02/24(木) 00:56:53.49

>>77 がその結果の変わる一例では、ってことではない？

**デフォルトの名無しさん** · 2022/02/24(木) 00:59:33.72

>>77は内部構造が変わるという話で出力が変わるという話ではないと思っていた

**デフォルトの名無しさん** · 2022/02/24(木) 01:53:13.93

>>79
Rustは他の言語と違い、UB (undefined behavior)すなわち未定義動作を基本的に起こさないように安全に設計されている
最適化オプションの有無でもその点は大丈夫

もちろん念のためだが、入力が異なれば結果は変わるし、非同期の実行タイミングは当然保証されないから実行順序に依存するコードは結果が変わり得る
そういうことでないならば結果は同じになる

ちなみにvtableの件は仕様が公開すらされていない内部情報の話
しかもそこに収容される関数のアドレスの値やvtableのアドレスの値というプログラマーが全く気にする必要ない話
だからこれらは変化してももちろん良くてそれを承知の上で盛り上がってるだけ

**デフォルトの名無しさん** · 2022/02/24(木) 01:56:10.31

>>82
よかった。安心したわ。ありがとう

**デフォルトの名無しさん** · 2022/02/24(木) 14:04:31.52

vtableの話は元々のスタックやヒープの話と関係あったの？

**デフォルトの名無しさん** · 2022/02/24(木) 14:36:03.44

関係ないけどスタックやヒープの話よりも面白かった

**デフォルトの名無しさん** · 2022/02/25(金) 09:31:23.23

ついに期待のRust 1.59がリリース！

**デフォルトの名無しさん** · 2022/02/25(金) 09:56:57.35

>>86
なにか目玉機能あるの？

**デフォルトの名無しさん** · 2022/02/25(金) 11:13:21.04

asm!とdestructuring assignmentかな

**デフォルトの名無しさん** · 2022/02/25(金) 12:42:45.63

来たね

**デフォルトの名無しさん** · 2022/02/25(金) 15:06:17.84

inline asm安定化は嬉しい、stableでベアメタルやりやすくなるかも

**デフォルトの名無しさん** · 2022/02/25(金) 16:04:22.84

この馬鹿はアホすぎて日本語分からないようなのでこちらに転送。
https://mevius.5ch.net/test/read.cgi/tech/1605467680/919
以降はこちらで。

**デフォルトの名無しさん** · 2022/02/25(金) 17:28:20.31

同じやつかもしれんが、スレ違いの指摘を聞かない馬鹿3名引き取ってくれ
ID:u7rOKKj6
ID:iu2arc+w
ID:aDhOSI3t

**デフォルトの名無しさん** · 2022/02/25(金) 17:31:49.95

お膣毛

**デフォルトの名無しさん** · 2022/02/25(金) 17:39:52.83

rustのバージョンごとのリリース予定機能ってどこかにまとまってるの？
betaに入ったものはだいたいそのままstableになるから事前にどの機能が来るのか分かると思うんだが
いつもstableリリースのブログ投稿で知るので、もっと早めに知れると嬉しい

**デフォルトの名無しさん** · 2022/02/25(金) 18:25:23.29

Rust コンパイラのリリースサイクルは六週間という時間で区切ってるから
その時点で確定してるものが入るって感じじゃないの。
次のリリースまでにこれとこれを……というようなマイルストーン方式ではない。

**デフォルトの名無しさん** · 2022/02/25(金) 18:45:09.48

最近12週間でnightly(master)でstabilizeされた機能一覧とか
最近6週間でbetaに入った機能一覧を知る方法ない？って意図だった

**デフォルトの名無しさん** · 2022/02/25(金) 18:59:15.48

Githubのマイルストーン見ればいいんじゃない？
例えば1.60.0だとこれが入る予定なはず
https://github.com/rust-lang/rust/milestone/90?closed=1

**デフォルトの名無しさん** · 2022/02/25(金) 19:27:57.07

なるほどmilestoneがあったか
relnotesラベルで絞り込むといい感じだ
ありがとう
https://github.com/rust-lang/rust/issues?q=milestone%3A1.60.0+label%3Arelnotes

**デフォルトの名無しさん** · 2022/02/25(金) 21:16:51.47

https://mevius.5ch.net/test/read.cgi/tech/1605467680/927
まだやってるんだがｗ
ID:aDhOSI3t

**デフォルトの名無しさん** · 2022/03/02(水) 12:22:44.66

Electronの代替を目指す軽量なRust製フレームワーク「Tauri」、リリース候補版に到達
https://www.publickey1.jp/blog/22/electronrusttauri.html

Electronの優れた特徴を備えつつ、よりメモリ消費量が小さくファイルサイズもコンパクトで、高いセキュリティを備え、柔軟なライセンスを実現しようと開発されたのが「Tauri」です。

GitHubにはElectronとの比較表が示されています。それによるとLinux版のインストールサイズがElectronで52.1MBのところ、Tauriは10分の1以下のわずか3.1MB。同じくLinux版でのメモリ消費量はElectronが462MBのところ、Tauriは半分以下の180MBとなっています。

起動時間もElectronの0.80秒に対してTauriは0.39秒です。

**デフォルトの名無しさん** · 2022/03/02(水) 13:09:17.24

モバイル版も予定されてるとなるとFlutterにも似てるかな
あっちはモバイルベースのフレームワークだけど

**デフォルトの名無しさん** · 2022/03/02(水) 16:28:42.01

rustで複数のプロセスで「共有メモリ」したい場合ってどうすればいいの？

**デフォルトの名無しさん** · 2022/03/02(水) 16:53:15.47

プロセス間だとCと大して変わらないと思う
libcのmmapとかでアドレスに共有ファイルを割り当ててそのポインタをBoxもどきで包む
Drop時にfreeじゃなくmunmapするBoxっぽい別の型が必要でプロセス間のロックとか考えるともっと面倒くさい
mmapでcrate検索すれば使えるのがあるかもしれない

**デフォルトの名無しさん** · 2022/03/02(水) 17:43:29.63

基本的には >>103 の言うとおり C と変わらないと思う
shared_memoryというLinuxとWindowsで使えるクロスプラットフォームなcrateもあるみたいだね

ただプロセス間でメモリを共有する場合に複数プロセスから同一領域に対して &mut 参照を作っちゃうと UB にならないかは気になる

**デフォルトの名無しさん** · 2022/03/03(木) 05:15:49.21

>>100
WebViewなら大して変わらんじゃないか
がっかり

**デフォルトの名無しさん** · 2022/03/03(木) 05:38:31.20

>>105
かなり違うよ？

**デフォルトの名無しさん** · 2022/03/03(木) 07:53:58.47

むしろ、rustでプロセス間通信をする場合に相性が良いのは何か、というのが本質では無いだろうか？
プロセス間共有メモリをrust的に安全になるように包むことは可能なのか？
パイプやソケットの再実装にならないか？

**デフォルトの名無しさん** · 2022/03/03(木) 08:16:43.34

本当に共有メモリが必要なのか？って所だよな
ベアメタル開発時のハードウェアみたいに必須のケースもあるけど

**デフォルトの名無しさん** · 2022/03/03(木) 08:44:34.78

メッセージキューのほうが安全かね。
速度と手間は犠牲になりそうだけど。

**デフォルトの名無しさん** · 2022/03/03(木) 09:15:37.98

どういう問題を解決したいかという文脈抜きに
どういう手段がいいかを論じても意味ないよ
いわゆるXY problem

**デフォルトの名無しさん** · 2022/03/03(木) 09:18:31.12

>>107
共有メモリをミューテクスで排他制御するならロックの取得/解放をメモリの取得/解放と同等に扱えるような気はするが

**デフォルトの名無しさん** · 2022/03/03(木) 10:18:45.28

volatileアクセスするのが自然なんじゃねーの。

**デフォルトの名無しさん** · 2022/03/03(木) 16:55:17.18

>>112
volataileはプロセス間のリソース共有とは概念的には別の話。

**デフォルトの名無しさん** · 2022/03/03(木) 17:16:17.86

少なくともCでは
CON02-C. volatile を同期用プリミティブとして使用しない
ttps://www.jpcert.or.jp/sc-rules/c-con02-c.html
だけど、Rustは同期が保証されるんだっけ？

**デフォルトの名無しさん** · 2022/03/03(木) 19:04:46.11

それはマルチスレッドの話でしょ？

**デフォルトの名無しさん** · 2022/03/03(木) 19:15:45.62

全ての共有メモリのページアクセスに対して割込みをかけてるならそういう実装も可能だろうけど、現実的には考えにくいだろうｗ
アホなこと考える前に自分でコード読めよｗ

**デフォルトの名無しさん** · 2022/03/03(木) 19:22:14.52

>>100
そのTauriに興味を持ったのですが
それはJSの使用を限りなく小さくできますか？

**デフォルトの名無しさん** · 2022/03/04(金) 11:29:49.34

>>117
根拠はないけどできると思うよ

**デフォルトの名無しさん** · 2022/03/04(金) 18:24:33.40

で、Tauri使ってみた人いるの？

**デフォルトの名無しさん** · 2022/03/04(金) 18:45:00.29

>>119
その質問の意図は？

**デフォルトの名無しさん** · 2022/03/04(金) 20:47:25.90

Rustみたいな標準ライブラリが未熟で安全性のかけらもなく、野良のゴミコードばかりの言語ありがたがって使うアホいないよなｗ

**デフォルトの名無しさん** · 2022/03/04(金) 20:50:32.75

>>121
Javaもそう言われてたけどなw20年くらい前

**デフォルトの名無しさん** · 2022/03/04(金) 20:57:54.90

20年くらい前のJavaはSunの強力な後押しでつよつよだったからなｗ
ソフト資産も順当に増えたｗ安全性はRustの比じゃないし、らいとわんすらんえびうぇあと嘯いてたｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:04:31.08

>>123
たしかにヌルポなどJavaの安全性は低いけど
RustはJavaとは異なりその点も安全性が保証される言語だから
実際にJavaからRustへの移行も進んでいる

**デフォルトの名無しさん** · 2022/03/04(金) 21:06:23.95

ぬるぽなどの安全性！？ぬるぽなんて安全そのもので代名詞みたいなもんだろうｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:10:22.89

Rustなんて誰も知りませんよ？
https://trends.google.co.jp/trends/explore?date=today%205-y&;q=%2Fm%2F0dsbpg6,%2Fm%2F07sbkfb,%2Fm%2F05z1_

**デフォルトの名無しさん** · 2022/03/04(金) 21:11:31.69

;消してなｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:15:18.91

>>124
それ以外にもJavaは実行時エラー(例外)が多すぎですね
Rustはコンパイル時にエラー検出してくれるものが多いだけでなく
実行時エラーとなるものでもResultやOptionで返すからエラー処理忘れが起きないけど
Javaは忘れていても通ってしまい実行時にレア発生するものだと本運用で例外発生で落ちたり

**デフォルトの名無しさん** · 2022/03/04(金) 21:19:19.87

Rustでも雑にunwrap使ったらpanicで死ぬ可能性あるよね

**デフォルトの名無しさん** · 2022/03/04(金) 21:20:22.36

そんなこと起きないし
Rustみたいに
誰もコーディングできません
聞ける人いません
ライブラリありません
エラーわかりません
とか言われないｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:24:24.27

おじさん芸風変えたのか？

**デフォルトの名無しさん** · 2022/03/04(金) 21:27:15.64

リリース前にunwrap全部消しとかないと叩かれるの？

**デフォルトの名無しさん** · 2022/03/04(金) 21:33:51.78

どんな言語でもロジックミスでプログラムが終了することはいくらでもあるｗ
安全というのはそういう事態が起きてもプログラムがsegmentation faultなどで落ちないことｗ
よりよい実装方法はあるけど、それはそれｗ
まあリリース後にpanicで終了するのは製品ならやばいｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:47:04.33

>>132
可能な限りunwrap()は避けたほうがよいでしょう
もちろん続行不可能なために意図的にpanic終了させたい場合は別です
ロジック的にここでは絶対にNoneやErrが来ないはず！(と思い込んでいる)ケースもありますが
それならばせめてその理由を記述したexpect()を呼ぶように変えることで
発生時対処やコードをレビューする人にも役立つと思います

**デフォルトの名無しさん** · 2022/03/04(金) 21:49:55.68

unwrapなんていくらでもそこら中で使ってるだろｗ
流石Rust ｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:57:04.53

もちろん誰が見ても起きないとわかる自明な場合はunwrap()でいいと思いますよ
自明でない場合はせめてコメントに理由を残すとよいでしょう
自分で書いたコードでも1年後に「ここでunwrap()大丈夫だっけ？」と忘れてることもありうるためw

**デフォルトの名無しさん** · 2022/03/04(金) 22:05:29.47

そんなのは誰がどんな理由でどう書いたってその人の自由ｗ
他の人がどう思うかを気にするなら、べき論くらいは知っててもいい程度の話ｗ

**デフォルトの名無しさん** · 2022/03/04(金) 22:05:29.91

unwrapはunwrapで死ぬけどヌルポはしばらく動いてから死ぬという地味な怖さがある

**デフォルトの名無しさん** · 2022/03/04(金) 22:07:00.39

RustがJavaやC#より安全なわけないだろｗ頭悪すぎｗ

**デフォルトの名無しさん** · 2022/03/04(金) 22:14:27.75

>>139
Rustの方が安全
Rustはデータ競合安全性もコンパイラが保証

**デフォルトの名無しさん** · 2022/03/04(金) 22:51:40.80

unsafeこんもりのRustが安全なわけないだろｗ

**デフォルトの名無しさん** · 2022/03/04(金) 23:07:12.52

理由を書かずに同じ言葉繰り返すだけのおじさん

**デフォルトの名無しさん** · 2022/03/04(金) 23:14:03.66

もしかして手元のCコードをRustにベタ移植してる？

コンパイル通すためにunsafeこんもりなら納得できるが

**デフォルトの名無しさん** · 2022/03/04(金) 23:23:45.83

熱烈なJava信者なのかもな

**デフォルトの名無しさん** · 2022/03/05(土) 00:20:00.76

まあいうほど安全だったらもっと早く全てrustに置き換わってるわな。

**デフォルトの名無しさん** · 2022/03/05(土) 00:22:29.41

すまん。セグフォする言語使ってる雑魚おる？

**デフォルトの名無しさん** · 2022/03/05(土) 00:23:59.45

ああ、Rustっていう言語ねｗ
https://mevius.5ch.net/test/read.cgi/tech/1638086359/480

**デフォルトの名無しさん** · 2022/03/05(土) 02:38:11.66

何ヶ月か前にもいたな。Rustのいう安全とは何かを知る気が一切無いまま、安全じゃないって煽ってたやつが

**デフォルトの名無しさん** · 2022/03/05(土) 02:50:45.20

Rustはunsafeを隠蔽し、しかも内包する動機を安全の核とする部分に持つ劇的矛盾言語ｗ
それを安全安全高速と謳って騙ってベアメタル領域に行ってみたり、他スレまでしゃしゃり出るうざさｗ
マジで迷惑ｗ
firefoxだけで使って大人しくしとけｗ

**デフォルトの名無しさん** · 2022/03/05(土) 03:34:00.88

ネガキャンしようが
ttps://foundation.rust-lang.org/members/
これが現実ｗ

**デフォルトの名無しさん** · 2022/03/05(土) 03:55:08.77

俺が出したやつじゃんｗ
あのときも言ったけど、その辺の巨人は必要のあるニッチな領域を持ってるからバックにいるだけｗ
あのときからマジでRust推しがウザすぎてRust推すのやめたんだよなｗ

**デフォルトの名無しさん** · 2022/03/05(土) 10:45:20.33

>>126
Rustは何でもは知りません
知ってることだけ知ってます

**デフォルトの名無しさん** · 2022/03/05(土) 10:45:48.31

>>119
今日使うわ

**デフォルトの名無しさん** · 2022/03/06(日) 00:17:17.68

tauri触ってみたけどRust⇔JSの値のやりとりはJSON限定なのかな
Responseのbodyにバイナリデータ入れて返す方法を探してるけど
iframe内で送受信するオプションがあるからできないかもしれない

**デフォルトの名無しさん** · 2022/03/06(日) 02:29:18.30

base64

**デフォルトの名無しさん** · 2022/03/06(日) 12:07:19.24

154だけどBuilderのregister_uri_scheme_protocolでいけそう
WebViewのIPCをちょっと勘違いしてた

**デフォルトの名無しさん** · 2022/03/06(日) 12:57:45.63

全く使ってないけど結局js使うんならややこしくなるだけだろｗ
electronでwasm使ってウンウン唸ってる層にしか刺さらないように見えるのに宣伝うるさすぎｗ
しかもRust推しの数字操作は常にえげつないｗ
実効果と桁が違う宣伝効果をタイトルに持ってきちゃうｗ詐欺かよｗ

**デフォルトの名無しさん** · 2022/03/06(日) 13:11:37.97

js周りで言えばdenoとか最近どうなん？
わざわざ作り直した挙げ句、「全然速くなってませんでした！！！！少し設定とか出来るから許して…てへｗ」では困るだろｗ
いろいろ足りない処理もあるし、ベンチ向けに偏りすぎてると思うけど、後発ならjust-jsとか特定用途で高速化・コンパクト化できている
この差は何なんだろう？

**デフォルトの名無しさん** · 2022/03/06(日) 14:19:43.76

denoってセキュリティ周りをどうにかするのがモチベーションで高速であることは謳ってないのでは

**デフォルトの名無しさん** · 2022/03/06(日) 14:25:13.83

>>157
内部処理もUI周りも全部同じ言語で書いた方が楽って層には敬遠されそうだけど
内部処理はRust、UI周りはHTML+JSの方が書きやすいって層には需要があると思う

electronはよく知らないけどWebViewはバイナリにブラウザ埋め込む感じだから
ブラウザ内でバイナリ実行するwasmとはあまり関係ないかも

**デフォルトの名無しさん** · 2022/03/06(日) 15:17:04.79

>>159
作者のモチベーションがどうというより、ユーザー視点だとわざわざ書き直したにしてはパッとしないってこと
しかも書きっぷりまで変わるんではちょっとね
V8の上側にRust入ってるのになぁ～ｗ

>>160
> 内部処理はRust、UI周りはHTML+JSの方が書きやすいって層
wasm使う層だよねｗ

> electronはよく知らないけどWebViewはバイナリにブラウザ埋め込む感じだから
> ブラウザ内でバイナリ実行するwasmとはあまり関係ないかも
埋め込むというかバイナリをくっつけるだけでしょｗ
包含関係が逆なだけで酷似してるし、問題も似たような問題ばかりｗ
wasmならwebでそのまま動くが、tauriだとplatform限定されてnativeな分Rust側の速度が速いってだけｗ

**デフォルトの名無しさん** · 2022/03/06(日) 15:42:49.31

Rustでそんな便利な状況になっているのか
tauriというのをちょっと試してみるかな

**デフォルトの名無しさん** · 2022/03/06(日) 16:43:21.41

tauri自体うんぬんじゃなくて、electronクラスのメジャーミドルにまでＲｕｓｔでの書き換えが浸透してきてるってこと
すなわちRustがシステムプログラミングのデファクトスタンダードになったってことを表すエビデンスが１つ増えた

**デフォルトの名無しさん** · 2022/03/06(日) 16:58:21.68

逆だよｗ
electronはそもそもjsでアプリを書こうというものであって、ごく一部のクソメジャーアプリを除けばjsの範疇を出ないし、クソメジャーアプリはもうそれ自体がプラットフォームと化してるからカウントできないｗ
C#で書けば楽に何でも書けるのになんでわざわざHTML+JS+Rustを不自由なフレームまで使って書きたがるのか・・・ユーザーは不便、開発者も面倒とメリットなんて全くないのにｗ
結局ただの自己満足なんだよね

**デフォルトの名無しさん** · 2022/03/06(日) 17:00:13.90

C#ってMacとLinuxでまともに動かなくね

**デフォルトの名無しさん** · 2022/03/06(日) 17:03:12.31

Macは知らんが、Linuxのどこにそんな事実があるの？

**デフォルトの名無しさん** · 2022/03/06(日) 17:50:44.16

ID:oRBcPyqIはあちこちのスレで
的外れなRust叩きをやってるけど
なんなんやろ

**デフォルトの名無しさん** · 2022/03/06(日) 17:54:28.15

誰も言及してないC#とか唐突に言い出すあたりでお里が知れる

**デフォルトの名無しさん** · 2022/03/06(日) 17:56:46.74

あちこちのスレで長期間スレ違い指摘を無視して嘘八百並べるRust推しがいたからでは？ｗ

**デフォルトの名無しさん** · 2022/03/06(日) 17:57:08.30

>>167
やっかみだろ
書けない人には絶対書けない言語だしな
C/C++もそうだがJSちょっとかじった程度のスクリプトキディが書ける言語ではないと言う認識を持ってほしいね

**デフォルトの名無しさん** · 2022/03/06(日) 17:57:28.93

RustのスレでRustの話して文句言われる筋合いはないｗ

**デフォルトの名無しさん** · 2022/03/06(日) 17:58:38.02

その辺の言語は普通にかけるけどなｗ
Rustが安全とか嘯くアホよりはマシだと思うぞｗ

**デフォルトの名無しさん** · 2022/03/06(日) 18:02:20.15

Rust書けるようになるためにはまずGC言語への依存を捨てろ
自力でメモリ管理できる能力が絶対に必要
スタック、ヒープ、Dropトレイト、所有権、借用ルール、(可変参照と不変参照)、Box、arena、Rc、Cell、RefCell
この辺り曖昧さなく完全に理解してないと書けない言語なの
無能にはかけない言語

**デフォルトの名無しさん** · 2022/03/06(日) 18:04:33.12

GC書いたことあるけどｗ
Rustなんて誰も書ける必要のない言語なだけｗ

**デフォルトの名無しさん** · 2022/03/06(日) 18:06:38.47

Rustは悲惨な言語だよ
JS書いてブイブイ言わせてるようなやつが全く赤子みたいになるんだからw

**デフォルトの名無しさん** · 2022/03/06(日) 18:09:37.09

変な選民思想が今一番強い言語かもな。

**デフォルトの名無しさん** · 2022/03/06(日) 18:13:42.56

Rustは本当に悲惨な言語だよなｗ
https://github.com/rust-unofficial/too-many-lists

**デフォルトの名無しさん** · 2022/03/06(日) 18:21:17.44

このおっさんJSもろくに書けないC#屋だから

**デフォルトの名無しさん** · 2022/03/06(日) 18:29:58.17

別にC#もJavaも・・・ってか大抵のメジャー言語は書けるけどｗ

**デフォルトの名無しさん** · 2022/03/06(日) 19:16:52.49

>>173
追加
Derefトレイト、Copyトレイト、Cloneトレイト
こいつらは必ずしも必要ではないがメモリの使い方の訓練にはなるので触っておくべき
逆にこれらを理解できればRustは書ける
C#おじさんｶﾞﾝｶﾞﾚ

**デフォルトの名無しさん** · 2022/03/06(日) 19:19:37.62

アホだなｗ俺はRustを書けないなどと一言も言ってないｗ
そしてC#おじさんとか意味不明な名前を付けられてる人でもないｗ

**デフォルトの名無しさん** · 2022/03/06(日) 19:21:03.95

誰も書けるようになる必要のない言語なのは間違いないｗ
理由は>>177のリンクのとおりｗ

**デフォルトの名無しさん** · 2022/03/06(日) 19:24:14.36

>>181
お願いだからコテハンつけて！

**デフォルトの名無しさん** · 2022/03/06(日) 19:25:09.10

>>183
お断りする

**デフォルトの名無しさん** · 2022/03/06(日) 19:25:33.99

>>181
効いてるねえw

**デフォルトの名無しさん** · 2022/03/06(日) 19:27:04.59

>>182
rustの代わりになに使えばいいの？

**デフォルトの名無しさん** · 2022/03/06(日) 19:29:22.49

>>185
お前に効いてるだけだろ

>>186
Rust以外の言語なら何でも

**デフォルトの名無しさん** · 2022/03/06(日) 19:40:49.28

お、CommonLispとか書けるんか？

**デフォルトの名無しさん** · 2022/03/06(日) 19:41:34.72

Rustもコンプレックスの対象になるんか…
ただのプログラム言語なのに

**デフォルトの名無しさん** · 2022/03/06(日) 19:49:25.58

>>188
最近はもうご無沙汰してるけどemacs使ってたよ

>>189
コンプレックスではなく、広めるメリットのないゴ○言語だよねって言ってる

**デフォルトの名無しさん** · 2022/03/06(日) 20:00:46.25

>>190
EmacsLispとCommonLispじゃ全然違うぞ

**デフォルトの名無しさん** · 2022/03/06(日) 20:04:53.65

TauriをJavaScriptを一切書かずRustだけで使うのに挑戦し始めました
とりあえず公式に従いcargo利用パターンでやってみる
$ cargo install tauri-cli --locked --version ^1.0.0-rc
これで bin/cargo-tauri がインストールされて cargo tauri XXX が使えるようになった
$ cargo tauri init
これで src-tauri というディレクトリができて tauri.conf.json に指定すればよいのか

どうやらwasmを入れてやればTauri利用でもブラウザ利用でもRustコードだけで済むっぽい
$ rustup target add wasm32-unknown-unknown
$ cargo install trunk
$ cargo install wasm-bindgen-cli
これで bin/trunk などRustでのWASM使用環境が入ったようだ

次にフロントエンド用のディレクトリを作る
$ cargo new --bin frontend
$ cd frontend
ここで index.html を以下のdata-trunkを含む行でcssなど指定して適当に作成
<link data-trunk rel="css" href="/public/main.css"/>
$ trunk build
$ trunk serve
これでサーバーが起動された
まずはブラウザから http://localhost:8080/ により無コードwasm環境動作確認OK

これでようやくTauriに戻って先ほどの tauri.conf.json に今の分を記述
"devPath": "http://localhost:8080";,
"beforeDevCommand": "cd frontend && trunk serve",
"beforeBuildCommand": "cd frontend && trunk build",
$ cargo tauri dev
これで無事にTauriのウインドウがついに出てきた！ので無事に初期環境が成功
さてここからRustコードはどのフレームワークで書くのがおすすめ？

**デフォルトの名無しさん** · 2022/03/06(日) 20:19:38.65

>>191
どれもLispでそんな違いがあるとは思ってなかったし、そんな思い入れねーよ

>>192
wasm入れてpure rustは面白い試み
terminal作ってくれ

**デフォルトの名無しさん** · 2022/03/06(日) 20:29:23.18

>>193
どれもLispでそんな違いがあるとは思ってなかったし、

なんだ素人だったwwwww
馬脚を表したなwww

**デフォルトの名無しさん** · 2022/03/06(日) 20:32:44.98

この人ぼくはプログラミングにはくわしいんだと
わめくほどボロが色々出て面白いな

**デフォルトの名無しさん** · 2022/03/06(日) 20:39:24.52

>>187
あなただったら何を使うの？

**デフォルトの名無しさん** · 2022/03/06(日) 20:46:19.62

>>193
EmacsLispはゴミだぞw

**デフォルトの名無しさん** · 2022/03/06(日) 20:53:26.84

>>192の続き
とりあえずRust製フロントエンドフレームワークYewを使用
先程のfrontendディレクトリで
[dependencies]
yew = "0.19.3"
を Cargo.toml に追加して src/main.rs に以下のハローワールド記述
use yew::prelude::*;
fn main() {
yew::start_app::<App>();
}
#[function_component(App)]
pub fn app() -> Html {
html! {
<div>
<h2 class={"heading"}>{"ハローワールド！"}</h2>
</div>
}
}
そしてTauri側で再び
$ cargo tauri dev
無事にTauriでハローワールド！が出ました
同様にブラウザから http://localhost:8080/ でも同内容が表示された
つまりRustコードを書くだけで『デスクトップアプリ』と『ウェブアプリ』が同時に出来上がる？
もうじきTauriがモバイル対応するそうなので『モバイルアプリ』にもなるということ？

**デフォルトの名無しさん** · 2022/03/06(日) 21:14:59.14

PWAで作った方がいいんじゃないの？

**デフォルトの名無しさん** · 2022/03/06(日) 21:28:17.34

yewってマクロの使いこなしが変態的だな・・・