[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
953: デフォルトの名無しさん [sage] 2024/07/24(水) 03:57:10.87 ID:yTLgnmif(1) AAS
これは典型的なXY問題だから相手にするだけ無駄
質問者は本当に解決したい元の課題Xを素直に話すべき
自分の思い込みで勝手に判断して進めた二次的な課題Yについて質問しているからそれについては相手にしなくていい
954: デフォルトの名無しさん [sage] 2024/07/24(水) 04:42:12.08 ID:sCVmnNU/(3/4) AAS
>>946946(2): デフォルトの名無しさん [sage] 2024/07/24(水) 00:02:23.05 ID:QMkBbV1F(1) AAS
できる/できないで言えばできるよ
タプルの要素がすべて同じ型で要素数が12個以内ならFrom/Intoで配列に変換してイテレートする
それ以外ならextension traitで自前のイテレータを返すメソッドをタプルに実装する
他にも方法あるけどこの2つが主
タプルの型・要素数、イテレート時の型を汎用化したい場合はマクロが必須でそこそこめんどくさい
特にヘテロなタプルを汎用的にイテレート用の型に揃えるのはめんどくさい
本当にタプルで管理するのが望ましいのか
タプルで管理しつつイテレータで回すのがベストなのか
まずはよく考えたほうがいいと思う
imple IntoIterator for (&str, u64, &str, &str, u64) {
...
}
で出来るかと思ったけど
this is not defined in the current crate because tuples are always foreign
955: デフォルトの名無しさん [sage] 2024/07/24(水) 05:38:42.31 ID:U0F2g2Py(1) AAS
dynやenumにしろと本質的なアドバイスをもらえているのに対応しようとしない人
956: デフォルトの名無しさん [sage] 2024/07/24(水) 07:25:15.81 ID:Py4dd1Kh(1) AAS
たしかにXY問題だな
「異なる型が入り乱れてイテレートしたい」←何のために？
「異なる型が入り乱れてタプルがある」←どうやってそれが出来た？
957: デフォルトの名無しさん [] 2024/07/24(水) 08:43:52.20 ID:NUYI7xpt(1/2) AAS
・タプルは型を混合できる
・タプルはイテレートできない
・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う
で良いんじゃない？
958: デフォルトの名無しさん [sage] 2024/07/24(水) 08:43:57.79 ID:sCVmnNU/(4/4) AAS
とりあえず出来ました
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()
}
}
みなさんありがとうございました
959(1): デフォルトの名無しさん [] 2024/07/24(水) 08:50:34.05 ID:NUYI7xpt(2/2) AAS
XY問題だとか言うけど、上のFizzBuzイテレーターなんかはXとYのどちらとも関係ないでしょ
既にあるデータに対してイテレートする方法でなく、FizzBuzを0から生成するだけだから
それをしつこく何度も書くあたりが本物
960: デフォルトの名無しさん [sage] 2024/07/24(水) 09:24:46.95 ID:eaHzhPzb(1) AAS
>>959
それな
961: デフォルトの名無しさん [sage] 2024/07/24(水) 09:30:08.78 ID:+W2StRcH(1) AAS
意味のないFizzBuzzを散々書いておいて答えられなくなったら急に質問者を攻撃する複オジくん草
962: デフォルトの名無しさん [sage] 2024/07/24(水) 12:35:19.94 ID:qFVR7Ywl(1/3) AAS
必要な個数のタプルを配列に変換するコードでいいんじゃないかな
これは長さ自由に機械的にマクロで生成できそう
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()
}
}
963: デフォルトの名無しさん [sage] 2024/07/24(水) 12:36:33.67 ID:qFVR7Ywl(2/3) AAS
あとはタプルに登場する型を列挙して
例えばこんなコードを機械的に自動生成させてしまえばいいね
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}"),
}
}
}
964: デフォルトの名無しさん [sage] 2024/07/24(水) 12:38:12.03 ID:qFVR7Ywl(3/3) AAS
そうするとタプルの中の型の順番は任意でよくて
タプルをラッパーにかませるだけで利用できるよ
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}");
}
}
965: デフォルトの名無しさん [sage] 2024/07/24(水) 12:43:52.56 ID:mjGiit/q(1) AAS
効いてる効いてるw
966: デフォルトの名無しさん [sage] 2024/07/24(水) 12:49:36.37 ID:TJmYfYAi(1) AAS
「XY問題だから相手にするだけ無駄」と言い放っておいてからの〜〜
967: デフォルトの名無しさん [sage] 2024/07/24(水) 17:04:11.48 ID:1Kw3Uuff(1) AAS
もっと建設的な話題はないの？
968: デフォルトの名無しさん [sage] 2024/07/24(水) 19:14:00.84 ID:UKniupNy(2/2) AAS
5chより建設的なコミュニティを列挙し移住を検討するのが目下最も建設的な話題である
969: デフォルトの名無しさん [] 2024/07/24(水) 21:00:33.77 ID:bzm5y73f(1) AAS
最近出た便利クレートの話とかすれば良いんじゃね？
970: デフォルトの名無しさん [sage] 2024/07/24(水) 22:25:44.31 ID:mF9Tvkg9(1) AAS
ベストな日付処理クレートについて議論しよう
971: デフォルトの名無しさん [sage] 2024/07/25(木) 08:45:26.25 ID:q/t9CUhu(1) AAS
おすすめクレートの話はしてほしいな～
972: デフォルトの名無しさん [sage] 2024/07/25(木) 10:09:56.78 ID:P+cFrEvf(1) AAS
クレートの話をしてくれー、と
973(1): デフォルトの名無しさん [] 2024/07/25(木) 22:41:22.06 ID:zdgCFOr2(1/2) AAS
クレートではないけれど今日リリースのRust 1.80でLazyCell, LazyLockが安定版に入ったよ
グローバルな変数を外部クレート無しで書きやすくなる
974(1): デフォルトの名無しさん [sage] 2024/07/25(木) 22:49:30.69 ID:9YYk7vP+(1) AAS
>>973
それ、OnceCell使ってたコードは全部置き換えた方がいい奴？
975: デフォルトの名無しさん [] 2024/07/25(木) 23:18:37.32 ID:zdgCFOr2(2/2) AAS
>>974
自分はそれを言えるほど詳しくないけど、必ずしも必要ではないと思う
依存クレートを減らせる点で嬉しいし、今から書くコードでは新しいものにして良いと思うけど、今使ってるものをすぐに置き換える必要があるとまでは思わない
特にライブラリを作ってる場合は、rustcを今日リリースされたばかりの最新バージョンに上げないとライブラリをビルドできなくなるということなので、もう少し待った方が良いかもしれない
976: デフォルトの名無しさん [sage] 2024/07/26(金) 00:25:09.02 ID:/65SSmn2(1/2) AAS
OnceLockからLazyLockへ移行すると
変数宣言と初期化関数が離れていた可読性の問題が解決するとともに
例えばget_or_initを一箇所にするために一つ関数を用意したりするなどしていた手間も省けるようになるね
そして何よりも最大のメリットはDerefによりアクセスできる利便性
977: デフォルトの名無しさん [sage] 2024/07/26(金) 23:32:15.42 ID:/65SSmn2(2/2) AAS
とりあえず定番のこのあたりを置き換えた
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new("...").unwrap());
static SE: LazyLock<Selector> = LazyLock::new(|| Selector::parse("...").unwrap());
上下前次1-新書関写板覧索設栞歴
あと 25 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s