Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

公式
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 part25
https://mevius.5ch.net/test/read.cgi/tech/1722354386/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/11/23(土) 22:17:13.62

>>951
>>941が言ってるのは外部クレートの構造体で可視性にしろメソッドにしろ勝手にいじれないって前提での話だと理解してたんだけど
違うの？

**デフォルトの名無しさん** · 2024/11/23(土) 22:29:09.24

>>952
可視もアクセスもない外部の構造体のフィールドを！
フィールド毎に別スレッドで並列に書き換えたい！
ってことかよ
ワロタ

>>941もそこまでバカげた無茶を求めてない
求めてることは既に解決しただろう

**デフォルトの名無しさん** · 2024/11/24(日) 01:29:38.03

スライスの内部を弄るのはunsafeだけど
その構造体の内部は安心安全だからunsafeがどこにも現れないんだな

**デフォルトの名無しさん** · 2024/11/24(日) 01:59:38.19

Vectorの標準機能
好きなところで2分割する方法
スレッドでま利用可能

fn main() {
let mut vec = vec![1, 2, 3, 4, 5, 6];
let mid = vec.len() / 2;
let (left, right) = vec.split_at_mut(mid);

println!("left: {:?}", left); // [1, 2, 3]
println!("right: {:?}", right); // [4, 5, 6]

// 両方のスライスを同時に変更可能
left[0] = 10;
right[0] = 40;

println!("vec: {:?}", vec); // [10, 2, 3, 40, 5, 6]
}

**デフォルトの名無しさん** · 2024/11/24(日) 02:07:14.81

vecの機能
chunks_mutを使用する方法（等分割）
指定したサイズで複数個のスライスの可変参照

fn main() {
let mut vec = vec![1, 2, 3, 4, 5, 6];
let mut chunks = vec.chunks_mut(vec.len() / 2);

if let (Some(left), Some(right)) = (chunks.next(), chunks.next()) {
println!("left: {:?}", left); // [1, 2, 3]
println!("right: {:?}", right); // [4, 5, 6]

left[0] = 10;
right[0] = 40;
}

println!("vec: {:?}", vec); // [10, 2, 3, 40, 5, 6]
}

**デフォルトの名無しさん** · 2024/11/24(日) 17:24:11.96

Rustで書いたら危険だけどCなら安全に書ける例を教えてくれ

**デフォルトの名無しさん** · 2024/11/24(日) 18:13:55.87

>>941
rayonは確かに標準ではなく外部だが
C/C++では今も作り出せていないrayonやtokioなどの基盤ライブラリを
Rustが生み出すことができた勝因は
標準ライブラリを最小限にして外部のクレートに多くを託す方針をとったため

それでもなお標準ライブラリだけに拘るならば
その>>940の例はrayonを使わずに以下のように書くことができる

std::thread::scope(|scope| {
let mut rest: &mut [i64] = &mut buf;
while let Some((area, new_rest)) = rest.split_at_mut_checked(AREA_SIZE) {
rest = new_rest;
scope.spawn(|| {
area.iter_mut().for_each(|n| {
*n = f(*n);
});
});
}
});

**デフォルトの名無しさん** · 2024/11/24(日) 18:18:22.12

rayonってCから使えないの？

最近はたまにCから呼び出せるようにしたRustのクレートを見かけるよな
以前とは逆向きだ

**デフォルトの名無しさん** · 2024/11/25(月) 09:33:08.05

科学＋ンニュース 5ch

保守派もリベラル派も「自分の政治的信念に合致したニュース」を信じやすいという研究結果 [すらいむ★]
https://itest.5ch.net/egg/test/read.cgi/scienceplus/1732447647

コメントも含めて読むと
陰謀論が収まら無い理由が判明する

**デフォルトの名無しさん** · 2024/11/25(月) 15:15:08.59

>>957
Rustは安全なものでもunsafe付けたら危険になる言語

**デフォルトの名無しさん** · 2024/11/25(月) 17:19:35.66

>>958
結局、全体の可変参照&mutがある時
・structは各フィールドの&mutを同時に安全に得られる
・スライスはsplit_at_mut_checkedで任意に分割したサブスライスの&mutを同時に安全に得られる
つまりunsafeの必要なく安全に同時に書き換え可能ということだね

**デフォルトの名無しさん** · 2024/11/25(月) 17:20:53.69

>>961
unsafeは危険という意味ではなくて
C/C++と同じようにプログラマーがその部分のコードの安全性の責務を持ちなさい、という意味だよ
もしそれを危険と呼ぶならC/C++のコードは常に全てが危険

**デフォルトの名無しさん** · 2024/11/25(月) 17:46:18.55

よくrustと他の言語で比較するときに条件を揃えてないのが多すぎる印象。
パフォーマンスで差が出る部分でHashMapがある。デフォルトのハッシュ関数が安全に振られてるからちょっと遅い。高速化するなら下記のような感じ。

use std::hash::BuildHasherDefault;
use std::collections::HashMap;
use rustc_hash::FxHasher; // より高速なハッシュ関数

// FxHasherを使用したHashMap
type FastMap<K, V> = HashMap<K, V, BuildHasherDefault<FxHasher>>;

fn main() {
// 高速なハッシュマップの作成
let mut fast_map: FastMap<i32, String> = FastMap::default();
fast_map.insert(1, "fast".to_string());
}

**デフォルトの名無しさん** · 2024/11/25(月) 17:55:45.25

昔、PHPでHashDos攻撃でサーバーが止まるという問題があった。特定のハッシュ値を生成するようなパターンで速度が著しく低下する。なので今はwebで外部からデーターが送られて来る時は安全なハッシュ関数を使う。
このハッシュが安全かどうかで処理速度が変わるのだけど、他の言語では昔のままのが多い。それでrustとC++を比較して遅いとか言われる事がある。安全か速度か選べるから両方揃えて比較してくれ。

**デフォルトの名無しさん** · 2024/11/25(月) 18:58:14.92

FxHash使うと結構速度変わるんだよな

**デフォルトの名無しさん** · 2024/11/26(火) 10:38:32.10

rustとかでi32とかVecとかHashMapとかにmethodを勝手にimplして使うことについて問題とかないですか？

**デフォルトの名無しさん** · 2024/11/26(火) 10:56:47.14

coherenceの縛りがあるから勝手にimplすることはできない

**デフォルトの名無しさん** · 2024/11/26(火) 11:04:59.40

なんらかの trait を impl するという意味なら好きなようにやって構わないが、複数の型に impl する必要がある場合 (多相性を利用することを想定する場合) を除いては関数として定義したほうが良いことも多い。

**デフォルトの名無しさん** · 2024/11/26(火) 12:22:11.23

>>967
まず技術的にはRustは孤児ルール(orphan rule)により他へ影響を与える汚染を防げる仕組みがあるのでコンパイルが通るなら大丈夫
新たなメソッドを増やすには自分で用意したトレイトの中で行うことになるのでその自作トレイトをuseしない限り他への汚染の影響は無し

したがってあとは有用性と可読性の問題かな
例えばジェネリックに処理するためのトレイト境界とその新たなメソッドを用意するのは有用かつ必須でよく行われる
単に自作型に変換したいだけならば新たなトレイトとメソッドを用意せずとも
impl From<既存型> for 自作型して
let x: 自作型 = 既存型値.into(); など

**デフォルトの名無しさん** · 2024/11/26(火) 12:32:30.35

>>970
ありがとうございます
他のライブラリー影響する気がしたので聞いてみました

**デフォルトの名無しさん** · 2024/11/26(火) 19:48:39.21

Traitのimplが出来るのは型を定義したcrateかtraitを定義したcrateだけだから、他のライブラリには影響しない
メソッドの名前が被っていてもそのtraitをuseしないと使えないし、最悪useすることになってもtraitを指定してメソッドを呼べる

**デフォルトの名無しさん** · 2024/11/27(水) 16:06:33.32

「ツールの使い方覚えるだけ」

まさにそれ

**デフォルトの名無しさん** · 2024/11/29(金) 21:54:35.06

こうすれば実行時に確定する値を&'staticにできるね
static HOME: LazyLock<String> = LazyLock::new(|| std::env::var("HOME").unwrap());
let home: &'static str = &*HOME;

**デフォルトの名無しさん** · 2024/11/30(土) 00:45:06.70

unsafeとは危険という意味で合ってるが、魔女のようなものを狩る行動を意味しない
信念と行動が合致しない方が得だから合致しない

**デフォルトの名無しさん** · 2024/11/30(土) 18:20:12.51

所有者をスタック上に置くからライフタイム管理が必要になる
それを避けて&'staticするには3つの方法がRustで提供されている
(1) 所有者を最初から持たない
(2) 所有者をスタックに置かない
(3) 所有者を捨てる

**デフォルトの名無しさん** · 2024/11/30(土) 19:42:09.81

データをRustの外に置けば、ライフタイム管理から逃れられる
たとえばファイルに書いてしまう

**デフォルトの名無しさん** · 2024/11/30(土) 23:10:39.19

(1) コンパイル時に値が確定して静的に配置されるものが該当
(2) 実行時に値が確定してstatic変数に遅延配置させるものが該当
(3) 実行時に値が確定してleak()させるものが該当
いずれも&'staticで安全に参照できる

**デフォルトの名無しさん** · 2024/11/30(土) 23:33:27.96

C++もスマートポインタがあるからポインタ管理を推進する側の勢力だった
だからC++を使わなくてもCで十分という意見に説得力があった
今では、管理に反対する奴も賛成する奴もどっちもC++に不満を感じている

**デフォルトの名無しさん** · 2024/12/01(日) 21:53:13.54

let や　let mut を見たとたん、「だーめだ、こりゃあ。数値計算に使えねえ。fortranの方が余程ましだ。」
と思った。大体、letなんてBasicで出てきそうなワードを「変数束縛」という深刻な概念に結びつけている
時点で作った奴はセンスねえと思うわ。

**デフォルトの名無しさん** · 2024/12/01(日) 22:06:15.87

ブラックフライデーで複オジポエムが続いてたかと思えばさらに輪をかけた常識知らずが来たw

**デフォルトの名無しさん** · 2024/12/01(日) 22:10:53.24

そうか？　俺にはお前の額に馬と鹿が見えるが

**デフォルトの名無しさん** · 2024/12/01(日) 22:44:04.77

>>774
アンロードが起きうるstatic変数は制御下に置くためスレッドローカルに置く
thread_local! {
static VAR: RefCell<Foo> = RefCell::new(Foo::new());
}
ちゃんとdropするためメモリリークは起きないことが確認できる
impl Drop for Foo {
fn drop(&mut self) {
println!("DEBUG: drop Foo");
}
}

**デフォルトの名無しさん** · 2024/12/02(月) 13:25:55.50

>>980
大丈夫か？比較対象がfortranやbasicでは歳が知れるぞ。今時の言語知らんのかい？

**デフォルトの名無しさん** · 2024/12/02(月) 13:32:19.67

変数束縛とかいきってるとこにセンス感じないのは同意

**デフォルトの名無しさん** · 2024/12/02(月) 13:38:57.47

ML 系言語が基礎になってるから用語もそっちで一般的なものが使われてる。

**デフォルトの名無しさん** · 2024/12/02(月) 13:43:46.67

>>986
ML知ってるならより奇妙に感じるはずだよw

**デフォルトの名無しさん** · 2024/12/02(月) 14:01:48.04

lispや初期のMLからletの使い方は変わってないと思うけど何がしたくて何が出来ないと言ってるのか分からん。

**デフォルトの名無しさん** · 2024/12/02(月) 14:48:33.18

伝統的には、引数とグローバル変数を区別せず自由変数とする
自由ではない変数は束縛されている
ただし関数がネストするなら、引数は束縛変数とするほうが需要に合致する

**デフォルトの名無しさん** · 2024/12/02(月) 18:48:24.16

free variables/bound variablesのbindingと
name bindingのbindingは無関係ではないけど使われる文脈も意味も違う
letの話は後者

それに昔々のThe Bookではvariable bindingsという用語が使われてたが
わかりにくいという理由でかなり前にvariablesという用語に変更されてる

**デフォルトの名無しさん** · 2024/12/02(月) 18:54:23.80

>>739
メモリリークとは実行中に使用していないメモリが解放されないことでメモリ使用量が膨らんでいくことだから
実行を終えた時にメモリ解放するか否かはどうでもいい話でそれをメモリリークとは呼ばない

Box::leak()でも実行を終えた時にメモリは解放されないがRustでは普通に使われている
例えばcargo crateでもleakさせまくっているが何ら問題ない

cargo-0.84.0/src/cargo/core/package_id.rs: let inner = Box::leak(Box::new(inner));
cargo-0.84.0/src/cargo/core/source_id.rs: let inner = Box::leak(Box::new(inner));
cargo-0.84.0/src/cargo/util/interning.rs: let s = str.to_string().leak();

**デフォルトの名無しさん** · 2024/12/02(月) 20:05:14.90

最近勉強始めたけど
::で躓いて脱落しそう

**デフォルトの名無しさん** · 2024/12/02(月) 20:19:44.41

ダブルコロンは他の言語C++からPHPまで使われており
Rustでもそれらと同様に名前空間を示すpathの区切り文字として使用されている
https://doc.rust-lang.org/reference/paths.html

**デフォルトの名無しさん** · 2024/12/02(月) 20:22:50.81

>>990
えーとletという用語に文句言ってるだけで、プログラムの機能的には問題ないということでいいの？

**デフォルトの名無しさん** · 2024/12/02(月) 20:39:13.67

ら、ら、ラストー🦛

**デフォルトの名無しさん** · 2024/12/02(月) 20:39:36.01

ら、ら、ラストー🦛

**デフォルトの名無しさん** · 2024/12/02(月) 20:39:59.86

ら、ら、ラストー🦛
ら、ら、ラストー🦛

**デフォルトの名無しさん** · 2024/12/02(月) 20:40:22.73

ら、ら、ラストー🦛
ら、ら、ラストー🦛

**デフォルトの名無しさん** · 2024/12/02(月) 20:40:45.44

ら、ら、ラストー🦛
ら、ら、ラストー🦛
ら、ら、ラストー🦛

**デフォルトの名無しさん** · 2024/12/02(月) 20:41:08.42

ら、ら、ラストー🦛
ら、ら、ラストー🦛
ら、ら、ラストー🦛

**1001** · Over 1000

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

**1002** · Over 1000

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

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

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

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

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