公式
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/
探検
Rust part24
レス数が1000を超えています。これ以上書き込みはできません。
2024/05/27(月) 06:41:26.82ID:T4AFD1f4
937デフォルトの名無しさん
2024/07/23(火) 11:25:10.18ID:ijWLrFq+ dynにすれば色んな型を混ぜられる
関数から返すときはBox<dyn ...>にする
例えば数値と文字列が混じる有名な例をRustでdynを使って書くと
type FizzBuzz = Box<dyn std::fmt::Display>;
fn fizz_buzz_iter() -> impl Iterator<Item=FizzBuzz> {
(1..).map(|int| match (int % 3, int % 5) {
(0, 0) => Box::new("FizzBuzz") as FizzBuzz,
(0, _) => Box::new("Fizz"),
(_, 0) => Box::new("Buzz"),
(_, _) => Box::new(int),
})
}
fn main() {
for x in fizz_buzz_iter().take(30) {
println!("{x}");
}
}
関数から返すときはBox<dyn ...>にする
例えば数値と文字列が混じる有名な例をRustでdynを使って書くと
type FizzBuzz = Box<dyn std::fmt::Display>;
fn fizz_buzz_iter() -> impl Iterator<Item=FizzBuzz> {
(1..).map(|int| match (int % 3, int % 5) {
(0, 0) => Box::new("FizzBuzz") as FizzBuzz,
(0, _) => Box::new("Fizz"),
(_, 0) => Box::new("Buzz"),
(_, _) => Box::new(int),
})
}
fn main() {
for x in fizz_buzz_iter().take(30) {
println!("{x}");
}
}
938デフォルトの名無しさん
2024/07/23(火) 17:24:06.93ID:hqmWVJB3 またFizzBuzzイテレータ書いてる……
939デフォルトの名無しさん
2024/07/23(火) 21:36:57.26ID:1jhTJKzb940デフォルトの名無しさん
2024/07/23(火) 21:58:12.50ID:joaeWjir941デフォルトの名無しさん
2024/07/23(火) 23:07:54.81ID:tKFzmUCx ほとんどの言語でオブジェクトを返す時にヒープを使うから
RustでもBox<dyn>を使っても構わないけど
ライフタイムさえ満たしてやればヒープを使わずに&dynにできるよ
use std::fmt::Display;
type FizzBuzz<'a> = &'a dyn Display;
fn fizz_buzz_iter<'a, T: Display>(i: &'a[T], s: &'a[&str; 3]) -> impl Iterator<Item = FizzBuzz<'a>> {
(1..).map_while(|int| match (int % 3, int % 5) {
(0, 0) => Some(&s[0] as FizzBuzz),
(0, _) => Some(&s[1]),
(_, 0) => Some(&s[2]),
(_, _) => i.get(int).map(|int| int as FizzBuzz),
})
}
fn main() {
let i: [_; 256] = std::array::from_fn(|i| i as u8);
let s: [_; 3] = ["FizzBuzz", "Fizz", "Buzz"];
for x in fizz_buzz_iter(&i, &s).take(30) {
println!("{x}");
}
}
RustでもBox<dyn>を使っても構わないけど
ライフタイムさえ満たしてやればヒープを使わずに&dynにできるよ
use std::fmt::Display;
type FizzBuzz<'a> = &'a dyn Display;
fn fizz_buzz_iter<'a, T: Display>(i: &'a[T], s: &'a[&str; 3]) -> impl Iterator<Item = FizzBuzz<'a>> {
(1..).map_while(|int| match (int % 3, int % 5) {
(0, 0) => Some(&s[0] as FizzBuzz),
(0, _) => Some(&s[1]),
(_, 0) => Some(&s[2]),
(_, _) => i.get(int).map(|int| int as FizzBuzz),
})
}
fn main() {
let i: [_; 256] = std::array::from_fn(|i| i as u8);
let s: [_; 3] = ["FizzBuzz", "Fizz", "Buzz"];
for x in fizz_buzz_iter(&i, &s).take(30) {
println!("{x}");
}
}
942デフォルトの名無しさん
2024/07/23(火) 23:38:39.26ID:QoNSkCmh 「tupleでイテレートできないの？」という質問に「こういうイテレータなら異なる型を混ぜられるよ」と回答するあたりがいかにもな感じ
率直に「できる/できない」で回答した上で補足として書けばいいのに
率直に「できる/できない」で回答した上で補足として書けばいいのに
943デフォルトの名無しさん
2024/07/23(火) 23:40:03.74ID:38zrS1+w トレイトオブジェクトをdynと呼ぶのは複オジだけ
944デフォルトの名無しさん
2024/07/23(火) 23:40:30.32ID:38zrS1+w >>942
それな
それな
945デフォルトの名無しさん
2024/07/23(火) 23:49:18.56ID:lLea54if Rust 2018 editionからdyn必須に変わった
946デフォルトの名無しさん
2024/07/24(水) 00:02:23.05ID:QMkBbV1F できる/できないで言えばできるよ
タプルの要素がすべて同じ型で要素数が12個以内ならFrom/Intoで配列に変換してイテレートする
それ以外ならextension traitで自前のイテレータを返すメソッドをタプルに実装する
他にも方法あるけどこの2つが主
タプルの型・要素数、イテレート時の型を汎用化したい場合はマクロが必須でそこそこめんどくさい
特にヘテロなタプルを汎用的にイテレート用の型に揃えるのはめんどくさい
本当にタプルで管理するのが望ましいのか
タプルで管理しつつイテレータで回すのがベストなのか
まずはよく考えたほうがいいと思う
タプルの要素がすべて同じ型で要素数が12個以内ならFrom/Intoで配列に変換してイテレートする
それ以外ならextension traitで自前のイテレータを返すメソッドをタプルに実装する
他にも方法あるけどこの2つが主
タプルの型・要素数、イテレート時の型を汎用化したい場合はマクロが必須でそこそこめんどくさい
特にヘテロなタプルを汎用的にイテレート用の型に揃えるのはめんどくさい
本当にタプルで管理するのが望ましいのか
タプルで管理しつつイテレータで回すのがベストなのか
まずはよく考えたほうがいいと思う
947デフォルトの名無しさん
2024/07/24(水) 00:15:33.28ID:sAqPevwn dynを使えば型が何種類でもいけてトレイト境界も使えて楽だろうけどdynは重い
Fizz Buzzのように2種類の型で済むならEitherを使う
色んなトレイトを透過的に対応してくれている
use either::Either::{self, Left, Right};
type FizzBuzz = Either<usize, &'static str>;
fn fizz_buzz_iter() -> impl Iterator<Item = FizzBuzz> {
(1..).map(|int| match (int % 3, int % 5) {
(0, 0) => Right("FizzBuzz"),
(0, _) => Right("Fizz"),
(_, 0) => Right("Buzz"),
(_, _) => Left(int),
})
}
Fizz Buzzのように2種類の型で済むならEitherを使う
色んなトレイトを透過的に対応してくれている
use either::Either::{self, Left, Right};
type FizzBuzz = Either<usize, &'static str>;
fn fizz_buzz_iter() -> impl Iterator<Item = FizzBuzz> {
(1..).map(|int| match (int % 3, int % 5) {
(0, 0) => Right("FizzBuzz"),
(0, _) => Right("Fizz"),
(_, 0) => Right("Buzz"),
(_, _) => Left(int),
})
}
948デフォルトの名無しさん
2024/07/24(水) 00:35:21.34ID:UKniupNy リフレクションのサポートとかにもっと力入れてれば普通にできるんだろうけど、しゃあなし
Rustはそういうの好かない言語だから
Rustはそういうの好かない言語だから
950デフォルトの名無しさん
2024/07/24(水) 03:12:39.74ID:s3z853Sv >>940
タプルをイテレーションしたい…。
リストとか、配列みたいに使いってことですよね？
Haskellでは無理ですが、Rustでは可能なのでしょうか？
（構造体代わりと言った通り、構造体をイテレーションしようと思わないですよね？）
Python,RubyのリストとHaskellのそれみたいに、そもそもの意味が違う可能性もありますし…。
タプルをイテレーションしたい…。
リストとか、配列みたいに使いってことですよね？
Haskellでは無理ですが、Rustでは可能なのでしょうか？
（構造体代わりと言った通り、構造体をイテレーションしようと思わないですよね？）
Python,RubyのリストとHaskellのそれみたいに、そもそもの意味が違う可能性もありますし…。
951デフォルトの名無しさん
2024/07/24(水) 03:25:04.27ID:sCVmnNU/ >>935
let t = ("abcde", 123, "mno", "pqrstuvw", 456);
for e Into::<[_; 5]>::into(t).into_iter() {
println!("{:?}", e)
}
無理ポorz
let t = ("abcde", 123, "mno", "pqrstuvw", 456);
for e Into::<[_; 5]>::into(t).into_iter() {
println!("{:?}", e)
}
無理ポorz
952デフォルトの名無しさん
2024/07/24(水) 03:30:03.16ID:sCVmnNU/953デフォルトの名無しさん
2024/07/24(水) 03:57:10.87ID:yTLgnmif これは典型的なXY問題だから相手にするだけ無駄
質問者は本当に解決したい元の課題Xを素直に話すべき
自分の思い込みで勝手に判断して進めた二次的な課題Yについて質問しているからそれについては相手にしなくていい
質問者は本当に解決したい元の課題Xを素直に話すべき
自分の思い込みで勝手に判断して進めた二次的な課題Yについて質問しているからそれについては相手にしなくていい
954デフォルトの名無しさん
2024/07/24(水) 04:42:12.08ID:sCVmnNU/ >>946
imple IntoIterator for (&str, u64, &str, &str, u64) {
...
}
で出来るかと思ったけど
this is not defined in the current crate because tuples are always foreign
imple IntoIterator for (&str, u64, &str, &str, u64) {
...
}
で出来るかと思ったけど
this is not defined in the current crate because tuples are always foreign
955デフォルトの名無しさん
2024/07/24(水) 05:38:42.31ID:U0F2g2Py dynやenumにしろと本質的なアドバイスをもらえているのに対応しようとしない人
956デフォルトの名無しさん
2024/07/24(水) 07:25:15.81ID:Py4dd1Kh たしかにXY問題だな
「異なる型が入り乱れてイテレートしたい」←何のために？
「異なる型が入り乱れてタプルがある」←どうやってそれが出来た？
「異なる型が入り乱れてイテレートしたい」←何のために？
「異なる型が入り乱れてタプルがある」←どうやってそれが出来た？
957デフォルトの名無しさん
2024/07/24(水) 08:43:52.20ID:NUYI7xpt ・タプルは型を混合できる
・タプルはイテレートできない
・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う
で良いんじゃない？
・タプルはイテレートできない
・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う
で良いんじゃない？
958デフォルトの名無しさん
2024/07/24(水) 08:43:57.79ID:sCVmnNU/ とりあえず出来ました
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()
}
}
みなさんありがとうございました
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デフォルトの名無しさん
2024/07/24(水) 08:50:34.05ID:NUYI7xpt XY問題だとか言うけど、上のFizzBuzイテレーターなんかはXとYのどちらとも関係ないでしょ
既にあるデータに対してイテレートする方法でなく、FizzBuzを0から生成するだけだから
それをしつこく何度も書くあたりが本物
既にあるデータに対してイテレートする方法でなく、FizzBuzを0から生成するだけだから
それをしつこく何度も書くあたりが本物
960デフォルトの名無しさん
2024/07/24(水) 09:24:46.95ID:eaHzhPzb >>959
それな
それな
961デフォルトの名無しさん
2024/07/24(水) 09:30:08.78ID:+W2StRcH 意味のないFizzBuzzを散々書いておいて答えられなくなったら急に質問者を攻撃する複オジくん草
962デフォルトの名無しさん
2024/07/24(水) 12:35:19.94ID:qFVR7Ywl 必要な個数のタプルを配列に変換するコードでいいんじゃないかな
これは長さ自由に機械的にマクロで生成できそう
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()
}
}
これは長さ自由に機械的にマクロで生成できそう
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デフォルトの名無しさん
2024/07/24(水) 12:36:33.67ID:qFVR7Ywl あとはタプルに登場する型を列挙して
例えばこんなコードを機械的に自動生成させてしまえばいいね
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}"),
}
}
}
例えばこんなコードを機械的に自動生成させてしまえばいいね
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デフォルトの名無しさん
2024/07/24(水) 12:38:12.03ID:qFVR7Ywl そうするとタプルの中の型の順番は任意でよくて
タプルをラッパーにかませるだけで利用できるよ
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}");
}
}
タプルをラッパーにかませるだけで利用できるよ
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デフォルトの名無しさん
2024/07/24(水) 12:43:52.56ID:mjGiit/q 効いてる効いてるw
966デフォルトの名無しさん
2024/07/24(水) 12:49:36.37ID:TJmYfYAi 「XY問題だから相手にするだけ無駄」と言い放っておいてからの〜〜
967デフォルトの名無しさん
2024/07/24(水) 17:04:11.48ID:1Kw3Uuff もっと建設的な話題はないの？
968デフォルトの名無しさん
2024/07/24(水) 19:14:00.84ID:UKniupNy 5chより建設的なコミュニティを列挙し移住を検討するのが目下最も建設的な話題である
969デフォルトの名無しさん
2024/07/24(水) 21:00:33.77ID:bzm5y73f 最近出た便利クレートの話とかすれば良いんじゃね？
970デフォルトの名無しさん
2024/07/24(水) 22:25:44.31ID:mF9Tvkg9 ベストな日付処理クレートについて議論しよう
971デフォルトの名無しさん
2024/07/25(木) 08:45:26.25ID:q/t9CUhu おすすめクレートの話はしてほしいな～
972デフォルトの名無しさん
2024/07/25(木) 10:09:56.78ID:P+cFrEvf クレートの話をしてくれー、と
973デフォルトの名無しさん
2024/07/25(木) 22:41:22.06ID:zdgCFOr2 クレートではないけれど今日リリースのRust 1.80でLazyCell, LazyLockが安定版に入ったよ
グローバルな変数を外部クレート無しで書きやすくなる
グローバルな変数を外部クレート無しで書きやすくなる
974デフォルトの名無しさん
2024/07/25(木) 22:49:30.69ID:9YYk7vP+ >>973
それ、OnceCell使ってたコードは全部置き換えた方がいい奴？
それ、OnceCell使ってたコードは全部置き換えた方がいい奴？
975デフォルトの名無しさん
2024/07/25(木) 23:18:37.32ID:zdgCFOr2 >>974
自分はそれを言えるほど詳しくないけど、必ずしも必要ではないと思う
依存クレートを減らせる点で嬉しいし、今から書くコードでは新しいものにして良いと思うけど、今使ってるものをすぐに置き換える必要があるとまでは思わない
特にライブラリを作ってる場合は、rustcを今日リリースされたばかりの最新バージョンに上げないとライブラリをビルドできなくなるということなので、もう少し待った方が良いかもしれない
自分はそれを言えるほど詳しくないけど、必ずしも必要ではないと思う
依存クレートを減らせる点で嬉しいし、今から書くコードでは新しいものにして良いと思うけど、今使ってるものをすぐに置き換える必要があるとまでは思わない
特にライブラリを作ってる場合は、rustcを今日リリースされたばかりの最新バージョンに上げないとライブラリをビルドできなくなるということなので、もう少し待った方が良いかもしれない
976デフォルトの名無しさん
2024/07/26(金) 00:25:09.02ID:/65SSmn2 OnceLockからLazyLockへ移行すると
変数宣言と初期化関数が離れていた可読性の問題が解決するとともに
例えばget_or_initを一箇所にするために一つ関数を用意したりするなどしていた手間も省けるようになるね
そして何よりも最大のメリットはDerefによりアクセスできる利便性
変数宣言と初期化関数が離れていた可読性の問題が解決するとともに
例えばget_or_initを一箇所にするために一つ関数を用意したりするなどしていた手間も省けるようになるね
そして何よりも最大のメリットはDerefによりアクセスできる利便性
977デフォルトの名無しさん
2024/07/26(金) 23:32:15.42ID:/65SSmn2 とりあえず定番のこのあたりを置き換えた
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new("...").unwrap());
static SE: LazyLock<Selector> = LazyLock::new(|| Selector::parse("...").unwrap());
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new("...").unwrap());
static SE: LazyLock<Selector> = LazyLock::new(|| Selector::parse("...").unwrap());
978デフォルトの名無しさん
2024/07/27(土) 11:02:49.38ID:WfV9QQMJ LazyLockよさそうね
979デフォルトの名無しさん
2024/07/27(土) 18:38:25.11ID:U5WpGSyZ 俺の今日のハマりポイントを紹介
bindgenにC++のコンストラクタを作らせると、データが壊れる
よく調べたら公式ドキュメントのConstructor semanticsに書いてあった
https://rust-lang.github.io/rust-bindgen/cpp.html
コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので
struct内部を参照したポインタが変なところを参照してバグる
bindgenにC++のコンストラクタを作らせると、データが壊れる
よく調べたら公式ドキュメントのConstructor semanticsに書いてあった
https://rust-lang.github.io/rust-bindgen/cpp.html
コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので
struct内部を参照したポインタが変なところを参照してバグる
980デフォルトの名無しさん
2024/07/27(土) 19:30:58.99ID:s18eFGvS C++も部分的に使えるとはいえ、FFIするならCのAPIにしておく方が無難な気はする
981デフォルトの名無しさん
2024/07/27(土) 20:04:50.53ID:U5WpGSyZ982デフォルトの名無しさん
2024/07/28(日) 15:27:45.35ID:v6kdbv5j983デフォルトの名無しさん
2024/07/28(日) 15:29:40.57ID:v6kdbv5j984デフォルトの名無しさん
2024/07/30(火) 01:24:35.90ID:xgbf/AIH >>979
この件って、RustはC++と比べて無駄にムーブするから遅いってこと？
この件って、RustはC++と比べて無駄にムーブするから遅いってこと？
985デフォルトの名無しさん
2024/07/30(火) 06:04:09.29ID:RHAjweCG 無駄な移動は消える
cargo asmで生成コードを見ることでそれを確認できる
移動前と移動後のアドレスを表示させて最適化を阻害することで元は別々となる例も確認できる
cargo asmで生成コードを見ることでそれを確認できる
移動前と移動後のアドレスを表示させて最適化を阻害することで元は別々となる例も確認できる
986デフォルトの名無しさん
2024/07/30(火) 12:06:12.26ID:tiWzrJ23987デフォルトの名無しさん
2024/07/30(火) 19:02:27.28ID:dzXOiSL/988デフォルトの名無しさん
2024/07/30(火) 20:13:33.28ID:VUdF4pDl >>985
最適化のかかり具合でバグが消えたり現れたりする嫌なパターンだな
最適化のかかり具合でバグが消えたり現れたりする嫌なパターンだな
989デフォルトの名無しさん
2024/07/30(火) 20:41:43.84ID:+5mpqNgW990デフォルトの名無しさん
2024/07/30(火) 22:41:22.15ID:GjQxUZ/0 >>989
本人じゃないのに出しゃばらせて頂きますが…。
Rust単体じゃなくて、C++との相性問題ですよ。相性最悪って書いてるんだから。
起きようがないじゃなくて、実際に起きてるらしいじゃないですか。
最適化で治るのなら大したことじゃなくても、デバッグ時にハマるの確実な類のバグ。
将来的に全部Rustで書けば起きないような問題も、過渡期の今は良く起きます。
「Rustを使えば」「Rustなら」。
そうでしょうけど、実際問題ライブラリがなければ既存のC/C++ライブラリ使う場面は多々あるでしょう。
（枯れたライブラリならなおさら）
これはRustに限らず、後続の言語全てが抱えている問題です。
本人じゃないのに出しゃばらせて頂きますが…。
Rust単体じゃなくて、C++との相性問題ですよ。相性最悪って書いてるんだから。
起きようがないじゃなくて、実際に起きてるらしいじゃないですか。
最適化で治るのなら大したことじゃなくても、デバッグ時にハマるの確実な類のバグ。
将来的に全部Rustで書けば起きないような問題も、過渡期の今は良く起きます。
「Rustを使えば」「Rustなら」。
そうでしょうけど、実際問題ライブラリがなければ既存のC/C++ライブラリ使う場面は多々あるでしょう。
（枯れたライブラリならなおさら）
これはRustに限らず、後続の言語全てが抱えている問題です。
991デフォルトの名無しさん
2024/07/30(火) 22:49:06.91ID:MqLM+D1V 最適化じゃなくて単に移動の問題
Box::newで要素を直接ヒープに作れない (いちどスタックに作られてからコピーされる) のと同じで、コンストラクタを抜ける前に構造体が maybeuninit::assume_init で移動する
その上で構造体のアドレスがC++のメソッドにthisポインタとして渡される際に問題を引き起こす、というように思える
だとすると最適化の有無は関係なく起こる気がする
ついでにいえば >>987 もあまり意味のない発言で、移動はムーブの訳語でもある (例えばC++の仕様の訳語に移動コンストラクタという表現がある) し、そもそもこの問題はムーブセマンティクスによるものでもない
これはStringやVecが持つリソースを所有権ごと移動することで効率的に別の変数に割り当てるもので、構造体のアドレスのようなローレベルなものとは違うかと
Box::newで要素を直接ヒープに作れない (いちどスタックに作られてからコピーされる) のと同じで、コンストラクタを抜ける前に構造体が maybeuninit::assume_init で移動する
その上で構造体のアドレスがC++のメソッドにthisポインタとして渡される際に問題を引き起こす、というように思える
だとすると最適化の有無は関係なく起こる気がする
ついでにいえば >>987 もあまり意味のない発言で、移動はムーブの訳語でもある (例えばC++の仕様の訳語に移動コンストラクタという表現がある) し、そもそもこの問題はムーブセマンティクスによるものでもない
これはStringやVecが持つリソースを所有権ごと移動することで効率的に別の変数に割り当てるもので、構造体のアドレスのようなローレベルなものとは違うかと
992デフォルトの名無しさん
2024/07/30(火) 22:59:00.85ID:MqLM+D1V 移動とムーブが仕様として別物だというなら、移動は英語でどう表現されてるんだ？
993デフォルトの名無しさん
2024/07/30(火) 23:00:06.83ID:L/ylOhaJ994デフォルトの名無しさん
2024/07/30(火) 23:13:56.95ID:EnloT7kO >>979
>>値をムーブしちゃうのでstruct内部を参照したポインタが変なところを参照してバグる
Rustでそのような自己参照はムーブでライフタイム切れとなるためバグは発生しなくて
自己参照を保ちたいならば値がムーブしなければよくて
値がムーブしないためにはスタック上でそのまま使うかヒープ上に確保して使えばよくて
それを保証するためにRustではPinという枠組みがあって安全に取り扱えるようになってるよ
>>値をムーブしちゃうのでstruct内部を参照したポインタが変なところを参照してバグる
Rustでそのような自己参照はムーブでライフタイム切れとなるためバグは発生しなくて
自己参照を保ちたいならば値がムーブしなければよくて
値がムーブしないためにはスタック上でそのまま使うかヒープ上に確保して使えばよくて
それを保証するためにRustではPinという枠組みがあって安全に取り扱えるようになってるよ
995デフォルトの名無しさん
2024/07/30(火) 23:19:18.00ID:MqLM+D1V996デフォルトの名無しさん
2024/07/30(火) 23:48:00.88ID:dZ3/RfBM 同意
997デフォルトの名無しさん
2024/07/31(水) 11:32:49.64ID:yHR2oE13 結合が密過ぎないかこの言語
998デフォルトの名無しさん
2024/07/31(水) 11:35:31.65ID:yHR2oE13 >将来的に全部Rustで書けば起きないような問題
さっさと仕事しろおまいらってことですね判ります
さっさと仕事しろおまいらってことですね判ります
999デフォルトの名無しさん
2024/07/31(水) 12:10:03.24ID:yHR2oE13 >>985
Pin
Pin
1000デフォルトの名無しさん
2024/07/31(水) 12:10:59.00ID:yHR2oE13 Pin<Arc<T>>
10011001
Over 1000Thread このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 65日 5時間 29分 33秒
新しいスレッドを立ててください。
life time: 65日 5時間 29分 33秒
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 【中国外務省】日中関係悪化は高市氏に責任と名指しで非難… ★5 [BFU★]
- 【インバウンド】中国からの“渡航自粛”…ツアー1000人分の直前キャンセル｢キャンセル料は免除してくれ｣ ことしいっぱいキャンセルに [１ゲットロボ★]
- XやChatGPTで広範囲の通信障害 投稿や閲覧できず [蚤の市★]
- 「国民の憤りを引き起こした」中国側“高市首相発言の撤回改めて要求” [どどん★]
- 【サッカー】日本代表、ボリビアに3発快勝 森保監督通算100試合目を飾る…鎌田、町野、中村がゴール [久太郎★]
- 【ローソン】ロゴの「L」で誤解生んだコーヒーカップ、デザイン変更へ 在庫使い切る3か月後にリニューアル [ぐれ★]
- 「遺体、安倍、会いたい」👈逆から読んでみて [175344491]
- 【悲報】SANA、発言撤回拒否 [769931615]
- ジャーナリストがテレビで解説「台湾問題は高市総理から言ったのではなく、立憲民主が日本の対応可能能力を暴こうとしたから」 [359572271]
- 【悲報】トランプ聖帝「高市…さん…でしたっけ？」 [878970802]
- 嫌儲、復活 [377388547]
- 山上、死刑回避し減刑か 山上母の供述で一気に酌量ムードへ [804169411]