Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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/

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

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

**デフォルトの名無しさん** · 2024/07/24(水) 03:30:03.16

>>946
それっぽいクレートがあるけどよう判らん
これはどんな感じ？
https://crates.io/crates/tuple-iter

**デフォルトの名無しさん** · 2024/07/24(水) 03:57:10.87

これは典型的なXY問題だから相手にするだけ無駄
質問者は本当に解決したい元の課題Xを素直に話すべき
自分の思い込みで勝手に判断して進めた二次的な課題Yについて質問しているからそれについては相手にしなくていい

**デフォルトの名無しさん** · 2024/07/24(水) 04:42:12.08

>>946
imple IntoIterator for (&str, u64, &str, &str, u64) {
...
}
で出来るかと思ったけど
this is not defined in the current crate because tuples are always foreign

**デフォルトの名無しさん** · 2024/07/24(水) 05:38:42.31

dynやenumにしろと本質的なアドバイスをもらえているのに対応しようとしない人

**デフォルトの名無しさん** · 2024/07/24(水) 07:25:15.81

たしかにXY問題だな
「異なる型が入り乱れてイテレートしたい」←何のために？
「異なる型が入り乱れてタプルがある」←どうやってそれが出来た？

**デフォルトの名無しさん** · 2024/07/24(水) 08:43:52.20

・タプルは型を混合できる
・タプルはイテレートできない
・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う
で良いんじゃない？

**デフォルトの名無しさん** · 2024/07/24(水) 08:43:57.79

とりあえず出来ました
struct Hoge<'a> { t: (&str, u64, &str, &str, u64) }

impl<'a> IntoIterator for Hoge<'a> {
type Item = Fuga<'a>;
type IntoIter = std::vec::IntoIter<Self::Item>;

fn into_iter(self) -> Self::IntoIter {
vec![
Fuga::from(self.t.0),
Fuga::from(self.t.1),
Fuga::from(self.t.2),
Fuga::from(self.t.3),
Fuga::from(self.t.4),
].into_iter()
}
}
みなさんありがとうございました

**デフォルトの名無しさん** · 2024/07/24(水) 08:50:34.05

XY問題だとか言うけど、上のFizzBuzイテレーターなんかはXとYのどちらとも関係ないでしょ
既にあるデータに対してイテレートする方法でなく、FizzBuzを0から生成するだけだから
それをしつこく何度も書くあたりが本物

**デフォルトの名無しさん** · 2024/07/24(水) 09:24:46.95

>>959
それな

**デフォルトの名無しさん** · 2024/07/24(水) 09:30:08.78

意味のないFizzBuzzを散々書いておいて答えられなくなったら急に質問者を攻撃する複オジくん草

**デフォルトの名無しさん** · 2024/07/24(水) 12:35:19.94

必要な個数のタプルを配列に変換するコードでいいんじゃないかな
これは長さ自由に機械的にマクロで生成できそう

struct Wrapper<A, B, C, D, E>((A, B, C, D, E));

impl<A, B, C, D, E> From<Wrapper<A, B, C, D, E>> for [Tx; 5]
where
　Tx: From<A> + From<B> + From<C> + From<D> + From<E>,
{
　fn from(x: Wrapper<A, B, C, D, E>) -> Self {
　　[Tx::from(x.0.0), Tx::from(x.0.1), Tx::from(x.0.2), Tx::from(x.0.3), Tx::from(x.0.4)]
　}
}

impl<A, B, C, D, E> IntoIterator for Wrapper<A, B, C, D, E>
where
　Tx: From<A> + From<B> + From<C> + From<D> + From<E>,
{
　type Item = Tx;
　type IntoIter = std::array::IntoIter<Self::Item, 5>;
　
　fn into_iter(self) -> Self::IntoIter {
　　let x: [Self::Item; 5] = self.into();
　　x.into_iter()
　}
}

**デフォルトの名無しさん** · 2024/07/24(水) 12:36:33.67

あとはタプルに登場する型を列挙して
例えばこんなコードを機械的に自動生成させてしまえばいいね

type T1 = &'static str;
type T2 = i64;
type T3 = f64;

enum Tx { T1(T1), T2(T2), T3(T3), }

impl From<T1> for Tx { fn from(x: T1) -> Self { Self::T1(x) } }
impl From<T2> for Tx { fn from(x: T2) -> Self { Self::T2(x) } }
impl From<T3> for Tx { fn from(x: T3) -> Self { Self::T3(x) } }

impl std::fmt::Display for Tx {
　fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
　　match self {
　　　Self::T1(x) => write!(f, "{x}"),
　　　Self::T2(x) => write!(f, "{x}"),
　　　Self::T3(x) => write!(f, "{x}"),
　　}
　}
}

**デフォルトの名無しさん** · 2024/07/24(水) 12:38:12.03

そうするとタプルの中の型の順番は任意でよくて
タプルをラッパーにかませるだけで利用できるよ

fn main() {
　let tuple = ("abcde", 123, "nop", 0.456, 789);
　for x in Wrapper(tuple) {
　　println!("{x}");
　}
　for (i, x) in Wrapper((-1, "pi", 3, 3.14159, "END")).into_iter().enumerate() {
　　println!("{i}: {x}");
　}
}

**デフォルトの名無しさん** · 2024/07/24(水) 12:43:52.56

効いてる効いてるw

**デフォルトの名無しさん** · 2024/07/24(水) 12:49:36.37

「XY問題だから相手にするだけ無駄」と言い放っておいてからの～～

**デフォルトの名無しさん** · 2024/07/24(水) 17:04:11.48

もっと建設的な話題はないの？

**デフォルトの名無しさん** · 2024/07/24(水) 19:14:00.84

5chより建設的なコミュニティを列挙し移住を検討するのが目下最も建設的な話題である

**デフォルトの名無しさん** · 2024/07/24(水) 21:00:33.77

最近出た便利クレートの話とかすれば良いんじゃね？

**デフォルトの名無しさん** · 2024/07/24(水) 22:25:44.31

ベストな日付処理クレートについて議論しよう

**デフォルトの名無しさん** · 2024/07/25(木) 08:45:26.25

おすすめクレートの話はしてほしいな～

**デフォルトの名無しさん** · 2024/07/25(木) 10:09:56.78

クレートの話をしてくれー、と

**デフォルトの名無しさん** · 2024/07/25(木) 22:41:22.06

クレートではないけれど今日リリースのRust 1.80でLazyCell, LazyLockが安定版に入ったよ
グローバルな変数を外部クレート無しで書きやすくなる

**デフォルトの名無しさん** · 2024/07/25(木) 22:49:30.69

>>973
それ、OnceCell使ってたコードは全部置き換えた方がいい奴？

**デフォルトの名無しさん** · 2024/07/25(木) 23:18:37.32

>>974
自分はそれを言えるほど詳しくないけど、必ずしも必要ではないと思う
依存クレートを減らせる点で嬉しいし、今から書くコードでは新しいものにして良いと思うけど、今使ってるものをすぐに置き換える必要があるとまでは思わない
特にライブラリを作ってる場合は、rustcを今日リリースされたばかりの最新バージョンに上げないとライブラリをビルドできなくなるということなので、もう少し待った方が良いかもしれない

**デフォルトの名無しさん** · 2024/07/26(金) 00:25:09.02

OnceLockからLazyLockへ移行すると
変数宣言と初期化関数が離れていた可読性の問題が解決するとともに
例えばget_or_initを一箇所にするために一つ関数を用意したりするなどしていた手間も省けるようになるね
そして何よりも最大のメリットはDerefによりアクセスできる利便性

**デフォルトの名無しさん** · 2024/07/26(金) 23:32:15.42

とりあえず定番のこのあたりを置き換えた
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new("...").unwrap());
static SE: LazyLock<Selector> = LazyLock::new(|| Selector::parse("...").unwrap());

**デフォルトの名無しさん** · 2024/07/27(土) 11:02:49.38

LazyLockよさそうね

**デフォルトの名無しさん** · 2024/07/27(土) 18:38:25.11

俺の今日のハマりポイントを紹介

bindgenにC++のコンストラクタを作らせると、データが壊れる
よく調べたら公式ドキュメントのConstructor semanticsに書いてあった
https://rust-lang.github.io/rust-bindgen/cpp.html

コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので
struct内部を参照したポインタが変なところを参照してバグる

**デフォルトの名無しさん** · 2024/07/27(土) 19:30:58.99

C++も部分的に使えるとはいえ、FFIするならCのAPIにしておく方が無難な気はする

**デフォルトの名無しさん** · 2024/07/27(土) 20:04:50.53

>>980
bindgenはFirefoxがプロダクトでたくさん使ってるって聞いて、いけると思ったんだ
Firefoxは大半がC++だから

**デフォルトの名無しさん** · 2024/07/28(日) 15:27:45.35

>>978
LazyLockさようなら
に観えた

**デフォルトの名無しさん** · 2024/07/28(日) 15:29:40.57

>>979
RustとC++は相性最悪
RustとCは相性良いバッチリ

**デフォルトの名無しさん** · 2024/07/30(火) 01:24:35.90

>>979
この件って、RustはC++と比べて無駄にムーブするから遅いってこと？

**デフォルトの名無しさん** · 2024/07/30(火) 06:04:09.29

無駄な移動は消える
cargo asmで生成コードを見ることでそれを確認できる
移動前と移動後のアドレスを表示させて最適化を阻害することで元は別々となる例も確認できる

**デフォルトの名無しさん** · 2024/07/30(火) 12:06:12.26

>>984

＞コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので
＞struct内部を参照したポインタが変なところを参照してバグる

って書いてるのに、読解力無い人？

**デフォルトの名無しさん** · 2024/07/30(火) 19:02:27.28

>>985
移動じゃなくてムーブね
ここまでのレスで使われてる述語を踏襲すればいいよ

**デフォルトの名無しさん** · 2024/07/30(火) 20:13:33.28

>>985
最適化のかかり具合でバグが消えたり現れたりする嫌なパターンだな

**デフォルトの名無しさん** · 2024/07/30(火) 20:41:43.84

>>986
Rustを使えばそんなバグは起きない
参照のライフタイムは参照先より長くなることがコンパイル時点で保証される

>>988
Rustならばそこでバグは起きようがない

**デフォルトの名無しさん** · 2024/07/30(火) 22:41:22.15

>>989
本人じゃないのに出しゃばらせて頂きますが…。

Rust単体じゃなくて、C++との相性問題ですよ。相性最悪って書いてるんだから。
起きようがないじゃなくて、実際に起きてるらしいじゃないですか。

最適化で治るのなら大したことじゃなくても、デバッグ時にハマるの確実な類のバグ。

将来的に全部Rustで書けば起きないような問題も、過渡期の今は良く起きます。

「Rustを使えば」「Rustなら」。
そうでしょうけど、実際問題ライブラリがなければ既存のC/C++ライブラリ使う場面は多々あるでしょう。
（枯れたライブラリならなおさら）

これはRustに限らず、後続の言語全てが抱えている問題です。

**デフォルトの名無しさん** · 2024/07/30(火) 22:49:06.91

最適化じゃなくて単に移動の問題
Box::newで要素を直接ヒープに作れない (いちどスタックに作られてからコピーされる) のと同じで、コンストラクタを抜ける前に構造体が maybeuninit::assume_init で移動する
その上で構造体のアドレスがC++のメソッドにthisポインタとして渡される際に問題を引き起こす、というように思える
だとすると最適化の有無は関係なく起こる気がする

ついでにいえば >>987 もあまり意味のない発言で、移動はムーブの訳語でもある (例えばC++の仕様の訳語に移動コンストラクタという表現がある) し、そもそもこの問題はムーブセマンティクスによるものでもない
これはStringやVecが持つリソースを所有権ごと移動することで効率的に別の変数に割り当てるもので、構造体のアドレスのようなローレベルなものとは違うかと

**デフォルトの名無しさん** · 2024/07/30(火) 22:59:00.85

移動とムーブが仕様として別物だというなら、移動は英語でどう表現されてるんだ？

**デフォルトの名無しさん** · 2024/07/30(火) 23:00:06.83

>>990
それはRust単体では全く発生しない問題だね
C++とRustを併用する時にRustの知識を持たない人がハマるという話
FFI部分は両者の概念と挙動の違いの知識を持った人が作るべきだね

**デフォルトの名無しさん** · 2024/07/30(火) 23:13:56.95

>>979
>>値をムーブしちゃうのでstruct内部を参照したポインタが変なところを参照してバグる

Rustでそのような自己参照はムーブでライフタイム切れとなるためバグは発生しなくて
自己参照を保ちたいならば値がムーブしなければよくて
値がムーブしないためにはスタック上でそのまま使うかヒープ上に確保して使えばよくて
それを保証するためにRustではPinという枠組みがあって安全に取り扱えるようになってるよ

**デフォルトの名無しさん** · 2024/07/30(火) 23:19:18.00

>>994
bindgenの作者に言ってあげればいいと思うよ
ついでに改善したコードをPRしてコントリビュートしてみてはどうだろう
使用者のミスを擦るよりもずっと有意義なはず

**デフォルトの名無しさん** · 2024/07/30(火) 23:48:00.88

同意

**デフォルトの名無しさん** · 2024/07/31(水) 11:32:49.64

結合が密過ぎないかこの言語

**デフォルトの名無しさん** · 2024/07/31(水) 11:35:31.65

>将来的に全部Rustで書けば起きないような問題

さっさと仕事しろおまいらってことですね判ります

**デフォルトの名無しさん** · 2024/07/31(水) 12:10:03.24

>>985
Pin

**デフォルトの名無しさん** · 2024/07/31(水) 12:10:59.00

Pin<Arc<T>>

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 65日 5時間 29分 33秒

**1002** · Over 1000

5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。

───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。

▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/

▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login