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/05/27(月) 06:42:29.23

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

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/05/27(月) 08:12:23.89

Cloudflare、HTTPプロキシ開発用RustフレームワークPingoraをオープンソース化
ttps://www.infoq.com/jp/news/2024/03/cloudflare-open-sources-pingora/

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

>>1 乙

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

なんで黙ってﾜｯﾁｮｲスレのリンク消したの？

**デフォルトの名無しさん** · 2024/05/27(月) 21:10:59.53

>>1乙ust

**デフォルトの名無しさん** · 2024/05/27(月) 23:31:45.00

rust-lldって魔法？

**デフォルトの名無しさん** · 2024/05/28(火) 23:01:09.87

「Sudo for Windows」はRustで開発されている！
メモリ安全が重視される分野で採用が広がるRust言語
ttps://forest.watch.impress.co.jp/docs/serial/yajiuma/1594981.html
次期大型更新「Windows 11 バージョン 24H2」に
搭載されることが確定した「Sudo for Windows」が、
Rust言語で開発されていることがわかった。

**デフォルトの名無しさん** · 2024/05/29(水) 09:39:32.15

完全にRustは残る言語になってしまったね

**デフォルトの名無しさん** · 2024/05/29(水) 11:05:17.42

言語の生き残るか否かもWindows次第かな

**デフォルトの名無しさん** · 2024/05/29(水) 13:45:30.43

この言語を支持してるやつは総じてデバッグ能力が低い

**デフォルトの名無しさん** · 2024/05/29(水) 13:56:47.79

なるほどそれはもうやるしかないね

**デフォルトの名無しさん** · 2024/05/29(水) 14:07:58.08

今更こんなのだけで一喜一憂するの？

ちなみにAzureCLIもRustだぞ
MacでHomebrewでインスコする時にRustのコンパイル始まって凄く時間掛かる

**デフォルトの名無しさん** · 2024/05/29(水) 14:55:30.35

ʕ◔ϖ◔ʔ

**デフォルトの名無しさん** · 2024/05/29(水) 16:53:17.15

>>12
テスト走らせるんじゃあかんの？

**デフォルトの名無しさん** · 2024/05/29(水) 17:06:12.76

>>9
これ仕組み上、console APIやTUIは動作しない
(それと肝心なところのほとんどがunsafeなのは見なかったことに)

**デフォルトの名無しさん** · 2024/05/29(水) 19:19:21.66

そういや、sudoとかの引数のバッファオーバーフローとかって、std::env::args_os使っていれば安全なのかな？

**デフォルトの名無しさん** · 2024/05/29(水) 22:46:32.28

unsafeはRust外のFFI/API境界でのやむを得ない出現か
unsafeを使うことで効率的かつ安全なパターンになる時のいすれかだが
後者のパターンは特定のプログラムから切り離してsafeなインターフェースを提供する汎用ライブラリに閉じ込めるのが好ましく
標準ライブラリはそのようにして出来ている

**デフォルトの名無しさん** · 2024/05/30(木) 12:31:47.54

つまりwindowsクレートはsafe interfaceの提供をサボってるということ？

**デフォルトの名無しさん** · 2024/05/30(木) 12:33:13.48

Rustと外側との境界はunsafeにせざるを得ないのは当たり前なのに肝心なところはunsafeと言われてもなぁ。
レビューすべき箇所が局所化されるだけでも十分なメリットだろ。

**デフォルトの名無しさん** · 2024/05/30(木) 14:46:49.26

>>20
>>21
どちらも正しい
Rustとその外側の境界部分で必ずunsafeが生じるからそこを問題にすることはない
ただしその部分は安全なインタフェースを提供するモジュールかできればクレートとして分離するのが好ましい

**デフォルトの名無しさん** ころころ · 2024/05/30(木) 16:38:16.78

Rust製Webサーバーで一番使われてるフレームワークって何だろ
MySQLと親和性高いなら使ってみたい

**デフォルトの名無しさん** · 2024/05/30(木) 18:56:43.74

>>23
axumとsqlx

**デフォルトの名無しさん** · 2024/05/30(木) 21:16:17.01

>>24
ありがと、試してみよう

**デフォルトの名無しさん** · 2024/05/31(金) 21:36:08.12

コンパイル前にcargo sqlx prepareでDBサーバからデータの型を得ておくことで静的型チェックできる仕組みなんだね

**デフォルトの名無しさん** · 2024/06/01(土) 10:39:11.44

へー、便利そう。
だけどこういう仕組みってカラム追加時のDBのマイグレーション辺りが入ってくるととたんに難しくなるんだよなぁ。

**デフォルトの名無しさん** · 2024/06/01(土) 22:15:15.67

>>27
そういうDBテーブル構成変更するとどんなプログラミング言語でも何らかの対応が必要となるよ
Rustでsqlx利用ならばDB構成変更した時にcargo sqlx prepareで型をDBから入手し直せばコンパイル時に静的に型チェックされるから楽で安全だね

**デフォルトの名無しさん** · 2024/06/01(土) 22:32:36.24

DBの構成管理をどこで行うかという話
その辺の道具類は他言語に比べてRustはまだまだなので
DB側のツールで管理しておくという昔ながらのやり方が現状のベスト

**デフォルトの名無しさん** · 2024/06/01(土) 22:35:04.27

スクラッチのPHPみたいにSQL直書きからのexecuteはナシ？

**デフォルトの名無しさん** · 2024/06/01(土) 22:44:45.41

>>30
Rustのコード内にSQL直書き文字列を書ける
その上でデータベースとの静的な型チェックもされるのがsqlxのメリット

警備員[Lv.6][新芽] · 2024/06/01(土) 22:51:53.44

それで実行計画も取れるの？

**デフォルトの名無しさん** · 2024/06/01(土) 23:58:30.16

実行計画はDBのデータではないから型チェックは意味ないような

**デフォルトの名無しさん** · 2024/06/02(日) 09:14:40.51

>>21
機械語に近い部分がunsafeなのは当たり前だけど
それを手書きしていることを納得させるのが難しいんだろう
一番自動化されてるフレームワークを使ってみたいんだろ

**デフォルトの名無しさん** · 2024/06/02(日) 12:55:11.71

接続相手の仕様が形式化されたデータとして存在すれば
Rust 上の関数との対応付けを自動化できることもあると思うけど
形式化されたデータは誰かが準備しないといけないことには変わりないからなぁ。

Windows では API の仕様記述を WinMD と呼ばれる形で標準化してるけど
それだって WinRT (ちょっと高級な API) が前提になっているのでそんなに万能ではない。

あらゆる仕様を記述できるほど自由度 (複雑さ) のあるフォーマットにしたら結局は
プログラムを書くのとそんなに変わらんようになるので自動化できる部分は自動化して
ややこしい場合は手書きするという割り切りしないと仕方ない。

**デフォルトの名無しさん** · 2024/06/02(日) 23:32:50.95

Unix系システムコールとの共通部分は
ファイルシステムなど標準ライブラリとして安全なインターフェイスを提供できてるね
Windows特有部分も同じようにMicrosoftがsafeなライブラリを公式に用意することが望ましいのかな

**デフォルトの名無しさん** · 2024/06/03(月) 08:58:28.03

>>35,36
なるほど。結構時間経ったと思うが厳しい。

Microsoftがsafeなライブラリを公式に用意するまで、
プロダクションでのRust採用は様子見するのが良さそうだ。

Linux特有の機能が必要な場合も同様に様子見するのが良さそうだ。

**デフォルトの名無しさん** · 2024/06/03(月) 09:53:26.77

>>37
Windows クレートはもうかなり充実してるよ。
メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。
unsafe なのは本質的に unsafe なのでどうしようもないし。

Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。

**デフォルトの名無しさん** · 2024/06/03(月) 12:15:09.36

>>37
LinuxでRustで困ってることないよ
様子見しなきゃいけないことがあるのならば具体的に挙げてみたら？

**デフォルトの名無しさん** · 2024/06/03(月) 15:47:20.28

>>38
>本質的に unsafe
良いキーワード出た、深掘りしてくれ

これとか
github.com/tokio-rs/io-uring

io_uringが本質的にunsafeだとでも思ってるのかな？

**デフォルトの名無しさん** · 2024/06/03(月) 16:27:42.41

本質的にC++な機能といえば多重継承
多重継承は他の言語に移植できない
万一できたとしたらそれは自動生成ではなく手作業で工夫されたコードだろうね

**デフォルトの名無しさん** · 2024/06/03(月) 17:17:59.54

Win32APIを素で提供しようと思ったらunsafeなのは仕方ないので、もう一枚ハイレベルなラッパーかませてsafeにしてほしいところではある。

**デフォルトの名無しさん** · 2024/06/03(月) 19:27:13.29

だからモダンな WinRT に移行しようね！

**デフォルトの名無しさん** · 2024/06/03(月) 20:11:34.31

WinRTってWin32のAPI網羅できてるの？
モダンなAPIが古いのを機能的に網羅できてないから仕方なく使ってる気持ちなんだけど。

**デフォルトの名無しさん** · 2024/06/03(月) 20:49:12.70

WinRT は「おおよそ」には Win32 API の機能を網羅しているが
根本的なパラダイムが違っていて単純には置き換えられない場合はある。
最初から WinRT を前提として作っていれば Win32 API 抜きで行けることは多いよ。
ゼロではないところがイライラするかもしれんけど。

**デフォルトの名無しさん** · 2024/06/03(月) 21:57:04.03

>>41
クラス多重継承は問題多すぎなダメな機能なので多くの言語で禁止している
クラス継承そのものが問題を多く抱えているため各機能のインターフェースなどを実装するのが望ましい
Rustならば複数のトレイト境界を指定することでそれら複数のトレイト機能を実装した任意の型を対象に抽象的なプログラミングができる

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

かきを最新AIに重箱の隅をつつく用意尋ねましょう
全ての電磁波は強い低周波も高周波も被爆する?
電磁かいが強い場所は20Hzと55Hzは磁気閃光これも被爆している.?
音波も強い場合は被爆する?
※自然界の化学科学の観測結果論文と人間の人工物で可能な化学と科学論文を読み込ませておく
是者と校舎を別々で回答する用意する
さらに制度を挙げるなら
グレーゾーンの論文をできるともいえるしできないともいえる用意認識させる

現在の科学が正しいのならなら電磁波攻撃はこのグレーゾーンの論文を使用しているので逃亡できている?

統合失調症電磁は音波なら周囲の者被爆している!?
寿命が短いのと免疫力低下起きて当然

**デフォルトの名無しさん** · 2024/06/04(火) 20:02:17.33

GPT4-Vの100分の1のサイズで同等の性能を誇るマルチモーダルモデル「Llama 3-V」が登場、トレーニング費用はたった8万円
2024年05月29日 14時00分
OpenAIがサム・アルトマンCEOを含む「安全・セキュリティ委員会」を設置、さらにGPT-4後継モデルのトレーニングを開始
2024年05月29日
「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
※対象者【被害者】そっくりの返答が可能
たった数秒の音声データから音声合成が可能な「VoiceCraft」
2024年04月16日 07時00分
OpenAIがわずか15秒の音声からクローン音声を生成できるAIモデル「Voice Engine」をリリース
2024年04月01日
会話相手を数秒見つめて声を登録するだけでその人の声だけを聞くことができるAIヘッドホンシステムが開発される
2024年05月30日
※対象者の声を個別に録音

**デフォルトの名無しさん** · 2024/06/04(火) 21:25:19.75

std::ptr::addr_eqでdyn同士やdynと通常参照を比較してもいいんだよね

**デフォルトの名無しさん** · 2024/06/05(水) 02:32:30.56

比較の方法が複数あるとして
最も優秀な方法に依存するのではなく抽象に依存するのが定石だよな

**デフォルトの名無しさん** · 2024/06/05(水) 13:57:39.45

>>17
>肝心なところのほとんどがunsafe

当たり前やん
そもそも観なかったことにするための機能なんだし

**デフォルトの名無しさん** · 2024/06/05(水) 14:16:34.14

言語のパラダイムでどれだけ頑張っても言語の外はその規則に従ってくれないよ。
そこらへんの境界線でおおよそどこでも信頼できるインターフェイスは ABI だけ。
根本の部分が C の影響下にある状況のほうは変えようがない。

一応 unsafe rust という選択肢が登場した分だけだいぶんマシになってんだよ。

**デフォルトの名無しさん** · 2024/06/05(水) 14:19:53.54

>>38,52
>本質的に unsafe

本質的にunsafeの定義、早う

**デフォルトの名無しさん** · 2024/06/05(水) 14:28:05.14

C/C++のコード全体が常にunsafeすなわち自動的な安全保障なしなのに対して
Rustはsafe部分のコードが自動的に安全保障されるという明確な違いがある

**デフォルトの名無しさん** · 2024/06/05(水) 14:33:58.97

>>38,54

定義するとは何かすら知らないレベルでRustやってるのかよw

**デフォルトの名無しさん** · 2024/06/05(水) 15:41:52.55

定義するとは何かも知らなくても書けるのがRustの良いところ

**デフォルトの名無しさん** · 2024/06/05(水) 18:13:30.31

なぜ定義なんだ
喩え話では駄目な理由を考えるとすぐ思いつくのは、喩え話は非○○的だから駄目なんだよね

**デフォルトの名無しさん** · 2024/06/05(水) 19:11:15.28

>>49
dynはアドレスとvtableの対なので使える

use std::fmt::Display;
let i = 12345;
let r = &i;
let d: &dyn Display = &i;
// assert!(eq(r, d)); // 型が不一致でコンパイルエラー
assert!(addr_eq(r, d)); // アドレスが一致

文字列strはアドレスと長さの対なのでこのように比較できる

use std::ptr::{addr_eq, eq};
let s1 = "abcdef";
let s2 = &s1[..3];
let s3 = &s1[3..];
assert!(!eq(s1, s2)); // 長さが異なるので不一致
assert!(addr_eq(s1, s2)); // アドレスが一致
assert!(!addr_eq(s1, s3)); // アドレスが不一致

文字列をバイト列に読み替えたときにも使える

let b1 = s1.as_bytes();
// assert!(eq(s1, b1)); // 型が不一致でコンパイルエラー
assert!(addr_eq(s1, b1)); // アドレスが一致

**デフォルトの名無しさん** · 2024/06/05(水) 19:38:28.12

>>53
safe にするのが不可能(少なくともそれ単体は)というシンプルな意味で使ってるつもりだが

**デフォルトの名無しさん** · 2024/06/06(木) 22:14:32.57

fn 単純にこの比較も<T>(slice: &[T], index: usize) {
　let p = &slice[index];
　let q = &slice[index..];
　// assert!(eq(p, q)); // 型不一致
　assert!(addr_eq(p, q));
}

**デフォルトの名無しさん** · 2024/06/07(金) 12:52:26.48

グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
https://ascii.jp/elem/000/004/202/4202481/

**デフォルトの名無しさん** · 2024/06/07(金) 23:50:20.38

as *const ()でupcastして比較しているだけなのか

**デフォルトの名無しさん** · 2024/06/08(土) 04:40:43.01

Option<String>型のxがある時に
x.as_ref()とするとOption<&String>が得られ
x.as_deref()とするとOption<&str>が得られることがわかりました

Option<&String>型のyがある時に
y.as_deref()としてもOption<&String>のままになりました
yからOption<&str>を得るにはどうすればいいのでしょうか？

**デフォルトの名無しさん** · 2024/06/08(土) 09:07:24.88

let tmp = Some(y.unwrap().clone());
let hoge = tmp.as_deref();

**デフォルトの名無しさん** · 2024/06/08(土) 09:09:50.82

cloneしたくなかったら
let hoge = Some(y.unwrap().as_str());

**デフォルトの名無しさん** · 2024/06/08(土) 10:33:13.95

unwrap()は基本的には使ってはいけない。

使ってもよい場合は論理的にNoneが絶対に来ないことが保証されてる場合で、
直前にNoneではないことをチェックしていて明白な場合と、
構造的にそこにNoneが来ないことをコメントで明記している場合のどちらか。

**デフォルトの名無しさん** · 2024/06/08(土) 10:34:38.61

もう一つは簡易プログラミングをする場合で、
そこにNoneが来た時に処理続行の意味がなく、
パニックという形でプログラムを終わらせても構わない場合。
これは本来はきちんとエラー処理対応するのが好ましい。

**デフォルトの名無しさん** · 2024/06/08(土) 10:39:31.95

ドキュメントのサンプルでは、
エラー処理は邪魔なので簡易的にunwrарが多用されているが、
それをそのまま用いるのがマズい理由は上述のため。

**デフォルトの名無しさん** · 2024/06/08(土) 10:45:50.57

「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
リコーと理研、技術の実用化の“兆し”を察知するアルゴリズムを開発
2024/06/05
グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
2024年06月06日

**デフォルトの名無しさん** · 2024/06/08(土) 11:07:47.98

>構造的にそこにNoneが来ないことをコメントで明記している場合

これはexpectのことを言ってるのかな？
panic!することには変わりないが

警備員[Lv.1][新芽] · 2024/06/08(土) 11:13:56.61

truckに手をだす勇者はいないのか？
https://github.com/ricosjp/truck

**デフォルトの名無しさん** · 2024/06/08(土) 11:35:42.10

>>63
y.map(|s| s.as_str())
or
y.map(String::as_str)

**デフォルトの名無しさん** · 2024/06/08(土) 11:44:51.45

>>70
単にunwrapでpanicさせるんじゃなくて
unwrap_orやunwrap_or_elseなどを使ってfallback valueを返す

>構造的にそこにNoneが来ないことをコメントで明記している場合
個人的に↑これには賛同しかねる
コードが脆弱になるから

**デフォルトの名無しさん** · 2024/06/08(土) 12:33:54.09

構造的にNoneでないことを期待しているロジックならチェックしたところでどうせリカバリできないんだし
単にパニックでいいと思うけどな

**デフォルトの名無しさん** · 2024/06/08(土) 12:53:40.15

事前条件・事後条件に反するときは panic するのが推奨されてなかったっけ？
要するにそういうことが一度でも起きたらバグが含まれているプログラムということだから修正するという前提がついてる。
あらゆるルートを想定するのも無意味だし、想定しないルートに入ったまま続けてもろくなもんじゃないので変なところがあったら止まったほうがいい。

ライブラリとして提供するなら expect にするに越したことは無いが
ただの panic でもスタックトレースは出せるし、
発見するのが自分 (またはチーム内などの身内) で修正するのも自分なら多少は雑でもよかろ。

**デフォルトの名無しさん** · 2024/06/08(土) 13:02:44.03

>>68
サンプルでrust unwrар好きだなと思っていたんだが、そんな理由で多用だったのか

**デフォルトの名無しさん** · 2024/06/08(土) 13:06:19.28

パニックさせるということはNoneかどうかをチェックしているということ
そしてパニック用のコードもそこに含まれるということ
そのため高速化がシビアなケースではunwrap_unchecked()が使われている
unsafeなので確実な監視対象となる点でむしろ好ましいケースもありうる
とはいえ特殊な場合を除き非推奨です

**デフォルトの名無しさん** · 2024/06/08(土) 14:06:17.67

ロジック的に None でありえないことをコンパイラが見抜ける状況でなら最適化で余計なチェックが消えることもあるし、分岐予測で速度的ペナルティはどうでもよくなることもある。
チェックするにしたって単発ではナノ秒単位の処理なので速度的に足を引っ張ることはまずない。
動画処理とか機械学習とかいった計算量が大きいものならチューニングが必要になることはあるかもね。

**デフォルトの名無しさん** · 2024/06/09(日) 00:14:30.88

例えばここにある`self.front.as_mut().unwrap()`や`front.next_kv().ok().unwrap()`のunwrapの使い方は妥当？
https://github.com/rust-lang/rust/blob/master/library/alloc/src/collections/btree/navigate.rs#L79-L80

**デフォルトの名無しさん** · 2024/06/09(日) 00:37:45.34

>>79
if self.is_empty() {
　None
} else {
　以降にあるから内部構造ロジックにより問題なし

**デフォルトの名無しさん** · 2024/06/09(日) 00:50:28.83

でもmatch self.front.as_mut() {
　Some(x) => で書けるならunwrap無い方がいい

**デフォルトの名無しさん** · 2024/06/09(日) 01:03:57.65

例えば>>65ならば
match y {
　Some(s) => s.as_str(),
　None => None,
}

そのNone => Noneの時はmapに簡略できる
y.map(|s| s.as_str())

それをメソッド記法でなくフルに書くと
y.map(|s| String::as_str(s))

ここで|s| f(s)はfと簡略できるためこうなる
y.map(String::as_str)

**デフォルトの名無しさん** · 2024/06/09(日) 08:02:48.25

全ての波【電磁波】で下記の症状が起きる
理由は電磁波が強いために起こるか電磁波が通過すれば磁気が生じて鉄分が振動して間接的に鼓膜などが振動する
マイクロ波聴覚効果を用いた音声伝送に関する検討
2018/03/05
https://www.bookpark.ne.jp/cm/ieej/detail/IEEJ-ZT181039-PDF/
マイクロ波聴覚効果 Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E6%B3%A2%E8%81%B4%E8%A6%9A%E5%8A%B9%E6%9E%9C
>>マイクロ波を照射された被験者は、クリック音やブザーのようなうなり音が聞こえる
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
https://news.mynavi.jp/techplus/article/20240604-2958879/
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
https://news.mynavi.jp/techplus/article/20240606-2960578/
※電磁波も振動させれると記載あり
最低でも下記ノ電磁波の威力が必要なら行っている者全員補足されている
GPSの電波は超微弱
https://gigazine.net/news/20240421-gypsum-gps-receiver/
［２２］米国特許５８６８１００号
【ＧＰＳ位置情報を使用した動物コントロール・システム】
一例ですが年々受信機の感度は向上している
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/
電磁波音波攻撃をされている部位ごとにホルモンや異常物質などの観測
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html

**デフォルトの名無しさん** · 2024/06/09(日) 22:41:10.47

今はOptionにas_slice()があるんだな
Some(x)なら[x]でNoneなら[]のスライス
アドレスは同じで長さが1か0なのか

**デフォルトの名無しさん** · 2024/06/10(月) 07:48:45.58

AIの性能が上がれば世界情勢が見えてくる
にゅーーすで話していることもそれらしきことを話すようになる

まづボイス・トォ・スカルが存在している場合としていない場合を問う
そのあとに人間の行動をどのように行動するかを問う

交友関係全てわかる範囲で入力しておく
社会っ情勢を知るにはさらにどういった役職等も調べておく

自分が使用しているボイス・トォ・スカルを本物か偽物化も割り出せる

**デフォルトの名無しさん** · 2024/06/10(月) 12:58:47.18

>>80
本当に内部ロジック上問題がないのかを確認するために見る必要のある範囲が広すぎるのが問題

>>81
if self.is_empty()を生かしたままという意味なら
不変条件を満たしてないコードが埋もれるのが問題
if self.is_empty()を無くすという意味なら
コードで表現したい意図から乖離するのが問題

**デフォルトの名無しさん** · 2024/06/10(月) 13:47:20.88

不眠症にカップ麺やスナック菓子などの「超加工食品」が関係しているという研究結果
https://gigazine.net/news/20240610-insomnia-linked-ultra-processed-foods/

インターネットの都市伝説「The Backrooms」の起源となった画像の正体はどうやって判明したのか？
https://gigazine.net/news/20240610-origin-of-the-backrooms/

GoogleのGeminiとMicrosoftのCopilotが過去のアメリカの大統領選挙を含めた世界中の選挙の結果を正常に返していないことが判明
https://gigazine.net/news/20240610-google-microsoft-chatbots-election-questions/

**デフォルトの名無しさん** · 2024/06/10(月) 20:09:22.20

ボイス・トォ・スカル
電磁波音波攻撃が判明する
人間は電磁界を発生させている
※被害者の身体に痕跡あり
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
名市大、頭蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
分子研など、金ナノ粒子が円偏光の左右選択性を70倍に高めることを発見
2024/06/06
弾性乱流と古典的なニュートン乱流との共通点を発見――弾性乱流を記述する数学的理論の開発に寄与　OISTら
2024-5-29
京大、テラヘルツ波の照射で超伝導体の臨界電流を制御できることを実証
2024/05/28
産総研など、1000個以上の量子ビットを制御可能な超伝導回路の原理実証に成功
2024/06/05
名大など、水素原子の約1/20の超高精度で収差補正できるX線顕微鏡を開発
2024/05/09

**デフォルトの名無しさん** · 2024/06/10(月) 20:09:43.09

細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発阪大など
2024/05/07
OIST、有機電気化学トランジスタのON時に生じるタイムラグの原因を解明
2024/05/07
並行世界でタイムリープを繰り返す!?効率的な新しいシミュレーション技術
2024.05.22
東大、電子回折パターンの減少とエントロピー増加の対応を実証
2024/06/03
理研など、「スキルミオンひも」の観察とその詳細な融解過程の記録に成功
2024/05/23 19:29
東大など、金属3Dプリント中の2D画像から3D多孔質構造を予測する手法を開発
2024/06/03

**デフォルトの名無しさん** · 2024/06/10(月) 23:46:59.09

>>84
スライスだから&[x][..]だね

**デフォルトの名無しさん** · 2024/06/11(火) 05:30:39.25

男性の精子の減少、携帯電話の使用と関係か最新研究
2023/11/02
https://www.cnn.co.jp/fringe/35211064.html
放射線と被曝
https://www.kan-etsu-hp.ne.jp/wp-content/themes/kan-etsu-hp/assets/kanetsu-hospital/department/pdf/radiology/radiation.pdf
>>エネルギーが極端に大きくなると X 線やガンマ線と呼ばれる放射線の一種になります。
※電磁波音波攻撃被爆している?

MrIは強力な磁場を利用しているので被爆しない

冷凍した人間の脳組織を解凍した後も正常に機能する技術開発
2024.05.12
https://karapaia.com/archives/52331859.html

1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功
2024年05月10日
https://gigazine.net/news/20240510-human-brain-mapped-in-spectacular-detail/
幼児期の脳活動から18歳時点でのIQを予測できるという研究結果
2023/09/09
https://gigazine.net/news/20230909-brain-activity-toddler-predict-18-iq/

パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/

**デフォルトの名無しさん** · 2024/06/11(火) 05:31:04.86

日常的な蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961214/
細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発阪大など
2024/05/07
https://news.mynavi.jp/techplus/article/20240507-2941335/

脳が鮮明に見える！世界最強の磁束密度で脳をスキャンするMRI「イズールト」
2024.04.05
https://nazology.net/archives/148090
※5分で全身スキャン完了するのかな

**デフォルトの名無しさん** · 2024/06/11(火) 06:55:26.94

電磁波兵器の特許情報/Google検索で下記が判明
電磁波過敏症低周波騒音被害の症状が出現

設立 1998年テクノロジー犯罪の撲滅
Https://media.toriaez.jp/s2972/32686.pdf
P77-身体・運動機能が遠隔から操作される P78-五感が遠隔から操作される
ギャングストーキングと電磁攻撃 - 広島修道大学学術リポジトリ
https://shudo-u.repo.nii.ac.jp/record/3395/files/SG63205.pdf

下記を頭部などで再現

人間の「第六感」磁気を感じる能力発見
2019/03/19
https://www.sankei.com/article/20190319-6UGPQVLP4BLEDJYGVSX3WW6A4A/
髪の毛ほど薄いのに音を75％カット！MIT開発の「革新的防音カーテン」
2024.05.13
https://nazology.net/archives/149896

言葉に出さずとも内なる声を解読する、脳の読み取り装置が解発される
2024.05.20
https://karapaia.com/archives/52331884.html

**デフォルトの名無しさん** · 2024/06/11(火) 22:42:05.37

>>90
配列でもベクタでも[..]を付ければスライスへ変換されるわけか

**デフォルトの名無しさん** · 2024/06/11(火) 23:50:24.15

【AI】IQ100超えを達成したAIモデルのClaude 3は「いい性格」を持つようにトレーニングされている [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1718025035/l50

**デフォルトの名無しさん** · 2024/06/12(水) 00:41:51.20

ゼロから学ぶＲｕｓｔ　システムプログラミングの基礎から線形型システムまで (ＫＳ情報科学専門書)

Kindleで本日のみ￥500

**デフォルトの名無しさん** · 2024/06/12(水) 13:31:07.00

Rustの作者と対話をしなくてもRust上級者になれるのは
作者の心を正確に読めるからではなく
あまり正確ではない当てずっぽうと試行錯誤が嫌いではないからだと思う

**デフォルトの名無しさん** · 2024/06/12(水) 17:47:51.37

はじまた
https://www.youtube.com/live/GiVA0MiHCV0

**デフォルトの名無しさん** · 2024/06/12(水) 21:31:56.44

>>94
どちらもstd::slice::SliceIndexによるものだが
その前にVecはstd::ops::Derefでsliceに変換されるのに対して
配列はstd::marker::Unsizeが実装されていて
std::ops::CoerceUnsizedでsliceに変換される点が異なる

**デフォルトの名無しさん** · 2024/06/13(木) 02:53:52.72

人間に匹敵する知能を持った汎用人工知能を開発した研究者に総額100万ドルの賞金を授与するコンテスト「ARC Prize」が開催

**デフォルトの名無しさん** · 2024/06/13(木) 08:11:01.44

zlib-rsの0.2.0きたね
ttps://github.com/memorysafety/zlib-rs

**デフォルトの名無しさん** · 2024/06/13(木) 08:58:47.14

>>99
Vecはヒープに依存し、かつスタックに移動するのが不可能
「サイズ」を定義できないデータは（スタックに）移動できない

個人の感想です
が、これが「知能」だと思うよ

**デフォルトの名無しさん** · 2024/06/13(木) 11:16:55.93

>>95
IQ=2x偏差値

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/06/13(木) 19:06:39.65

>>101
元のzlibとの速度差はどれくらい？

**デフォルトの名無しさん** · 2024/06/13(木) 19:19:21.58

>>104
ガンガンポイント増えるな

**デフォルトの名無しさん** · 2024/06/13(木) 19:53:32.56

zlib-rsはzlibと比較してまだ圧倒的に足りてないからパフォーマンス評価のしようがない
ttps://github.com/memorysafety/zlib-rs/issues/49

**デフォルトの名無しさん** · 2024/06/13(木) 21:05:44.12

>>107
先は長いね

**デフォルトの名無しさん** · 2024/06/13(木) 21:29:59.05

RustはC/C++に置き換わるのか？

警備員[Lv.5][新芽] · 2024/06/13(木) 21:36:14.88

無理無理かたつむり

**デフォルトの名無しさん** · 2024/06/13(木) 21:37:00.52

計画も陰謀もないんだよ

**デフォルトの名無しさん** · 2024/06/13(木) 21:59:02.47

>>104
めっちゃ面白そう
　

**デフォルトの名無しさん** · 2024/06/13(木) 22:16:54.37

>>109
時間さえあれば

**デフォルトの名無しさん** · 2024/06/13(木) 23:52:05.18

>>109
C/C++がRustに置き換わっていってる

**デフォルトの名無しさん** · 2024/06/14(金) 08:05:53.63

>>109
その前にSafe Rust相当のsafe c++とか出るんじゃない？
標準化できるかわからんが。

警備員[Lv.7][新芽] · 2024/06/14(金) 08:11:27.55

C++はUTF-8の扱いを何とかして欲しいね。

**デフォルトの名無しさん** · 2024/06/14(金) 08:28:16.67

>>115
C++をいくら強化してもそれは不可能だと皆がわかった
既存C++資産メンテ用限定としてはCarbonがある
それ以外は全てがRustへの移行に向かっている

**デフォルトの名無しさん** · 2024/06/14(金) 08:44:54.37

>>117
別のサブセットを作るだけだよ。
unsafe rustに対するsafe rustみたいなもの。

**デフォルトの名無しさん** · 2024/06/14(金) 08:53:45.79

>>118
それは無理だとわかったので誰も進めていない

**デフォルトの名無しさん** · 2024/06/14(金) 08:54:29.15

C++やってればそれが不可能なことくらいわかると思うんだけどな

**デフォルトの名無しさん** · 2024/06/14(金) 08:56:27.95

聖地に向かっている者だけが地政学を信じている

**デフォルトの名無しさん** · 2024/06/14(金) 09:19:59.81

>>109
現在進行形だけどC/C++が絶滅するわけじゃなさそう

**デフォルトの名無しさん** · 2024/06/14(金) 10:01:07.05

>>115
C++のロードマップを見てくると良いよ

**デフォルトの名無しさん** · 2024/06/14(金) 11:03:03.69

今考えられてるアノテーションではmaybe safer C++になるだけで根本的にsafeではない

既存資産を活用するという最大のメリットを捨てて非互換新言語を作れば可能だけどRustがある現状で誰もそんな事に投資しないから実現不可能

**デフォルトの名無しさん** · 2024/06/14(金) 11:28:58.36

>>117
carbonとか完全に忘れてたわ。あれ絶対c++やRustより先に無くなるやろ

**デフォルトの名無しさん** · 2024/06/14(金) 17:00:20.45

https://imgur.com/a/layer-A7vGJjY
使い分けは
こんなイメージ

**デフォルトの名無しさん** · 2024/06/14(金) 17:29:32.96

C++を安全にしようとすると標準ライブラリの各インターフェースから全て作り直しとなり
標準でないライブラリも同様なので既存のコード資産は使えず全面書き直しとなってしまう
それだけでは済まなくて互換性のない言語仕様も取り入れないといけない
なんとか手間暇かけてそこまで頑張って安全なC++ができあがっても何の意味もメリットも無くなってることに誰もが気付いた

**デフォルトの名無しさん** · 2024/06/14(金) 17:31:19.78

色使いが目にunsafeすぎる

**デフォルトの名無しさん** · 2024/06/14(金) 18:01:13.88

zlib-rsで移植のほぼ完了したdeflateを見ればよくわかるけどすごくメモリ安全だぞ
現実を見ろ

**デフォルトの名無しさん** · 2024/06/14(金) 18:18:31.44

>>109
ゲーム分野のC/C++は置き換わらない

**デフォルトの名無しさん** · 2024/06/14(金) 18:24:39.72

ゲームなんざ脆弱性があろうが最悪クラッシュさせりゃいいからな😁
まともなゲームエンジンフレームワークのないRustを使う意味がない
それよかクラッシュしたら人死の出るようなところのRust化が優先

**デフォルトの名無しさん** · 2024/06/14(金) 19:04:14.04

ネットワーク対戦ゲームだと細工したパケット送ると
バッファーオーバーフローで云々とよくある
脆弱性になるじゃん

**デフォルトの名無しさん** · 2024/06/14(金) 19:13:14.40

>>132
そんなつまらない欠陥じゃなくてC++ではなくRust選ぶ利点になりえる脆弱性を言ってよ

**デフォルトの名無しさん** · 2024/06/14(金) 20:42:46.16

今すぐ物を作るのは損
10年後20年後に作れば得
これがインフレだが
本当はどちらか一つだけ選ぶのは損で両方選ぶのが得だと思わないか

**デフォルトの名無しさん** · 2024/06/14(金) 21:29:25.97

>>133
あなたがつまらんかどうかが評価軸じゃないので

**デフォルトの名無しさん** · 2024/06/14(金) 22:51:10.89

>>134
>今すぐ物を作るのは損
>10年後20年後に作れば得
>これがインフレだが

違う
前提が間違ってるので議論が成り立たない

**デフォルトの名無しさん** · 2024/06/14(金) 23:07:33.93

C++書くのダルイんよ
Rustのゲームエンジン来るの待ってる

**デフォルトの名無しさん** · 2024/06/14(金) 23:46:55.69

ゲームはまずdirectxやopenglとかがrustで書き直されないことには何も始まらんと思うわ

**デフォルトの名無しさん** · 2024/06/15(土) 00:13:27.25

この板はプログラムを作らない人のための板ですね

**デフォルトの名無しさん** · 2024/06/15(土) 00:24:57.03

作ると断言するが、時の指定まではしていない

**デフォルトの名無しさん** · 2024/06/15(土) 04:55:57.02

>>138
WebGPUの参照実装であるwgpuを知らんのか。
ライブラリ使う側のIFはだいぶsafeだよ。
まぁ、バックエンドは結局、valkanやOpenGLになるけど。

**デフォルトの名無しさん** · 2024/06/15(土) 06:54:41.07

>>138
それらは書き直されてもunsafeばっかになって意味ないだろ

**デフォルトの名無しさん** · 2024/06/15(土) 07:07:04.66

OSのシステムコールだって生ポインタを渡したりunsafeな仕様だけど
Rustはsafeなインターフェースのライブラリとして提供して安全に使われているよ

**デフォルトの名無しさん** · 2024/06/15(土) 08:12:25.38

AIに組み込まれた検閲による命令拒否を打ち消してあらゆる種類の質問に応答できるようにする「アブリテレーション」とは？
2024年06月14日
※自分の身近な人の嘘や陥れようかが話されたことと実際の動き【動画撮影含む】っを解析すれば判明
スポーツで動的シミレーションなどをする不正をしているや審判の判定がおかしいも判明
日常生活の動きも同時に併用されればボイス・トォ・スカルを使用しているかが判明

スマフォにAIが搭載されるので容易に判定
120フレームと8ｋ【人間の網膜の解像度と同じ】あればかなり制度が上がる

相手の望まない手助けは数週間持続する高いストレスを与える！
2024.06.13
↕サイコパスはどう考えるのかな
使えない人」を排斥するとき周りの人の心は痛みにくいと判明
2021.05.22 SAT
ネット上で問題発言をする人は、暗い性格特性「ダーク・トライアド」かもしれない
2021.04.02 FRI
ナルシストは他の人よりも早くCEOの地位にたどり着く
2021.02.09 TUE
つい被害者を責めてしまう「公正世界仮説」とは何なのか？
2019.07.22 MON
「無能」でもOK？　社会的地位の高い人ほど信頼されやすい理由とは
2019.06.02 SUN

**デフォルトの名無しさん** · 2024/06/15(土) 08:12:46.55

「問題を指摘する人」に問題があると思い込む心理バイアス「自発的特性転移」が陰謀論を生んでいるという主張
2024年05
悪いニュースを伝えた人は理不尽に嫌われてしまうことが明らかに
2019.05.17
「恋人がサイコパス」だった時の見分け方とは
2018.12.09 SUN
ロンドン市民の娯楽だった？！近代イギリスの公開処刑
2023/12/17
スラップ訴訟
>>ある程度の発言力や社会的影響力のある、社会的に優位といえる立場の者が、特に発言力や影響力を持たない相対的弱者を相手取り訴訟を起こすこと。
巨大IT企業から「法的措置をちらつかせる停止通告書」を受け取った場合の対処方法とは？
2024年02月01日 08時00分

**デフォルトの名無しさん** · 2024/06/15(土) 10:23:21.15

サイバーエージェント、画像認識できる75億パラメーターの日本語LLM公開　商用利用OK
サイバーエージェントは6月13日、日本語大規模言語モデル（LLM）に画像認識機能を追加した大規模視覚言語モデル（VLM）「llava-calm2-siglip」を公開した。

「ChatGPT」画像を見ながら人間みたいに話せる新機能、今後数週間でリリースと予告
OpenAIは6月14日、同社の公式Instagramアカウントを通じ、ChatGPT（GPT-4o）に音声と映像を同時に理解する機能を追加し、今後数週間以内にリリースすると発表した。

画像生成AI「Stable Diffusion 3 Medium」公開　プロンプトの理解力が上がり、リアルな画像が生成可能に
Stability.aiは6月12日、同社が開発する画像生成AI「Stable Diffusion 3」シリーズの最新モデル「Stable Diffusion 3 Medium」を発表、無償の非商用ライセンスおよびクリエイターライセンスの下で利用可能だ。
サイバーエージェント、画像認識できる75億パラメーターの日本語LLM公開　商用利用OK
サイバーエージェントは6月13日、日本語大規模言語モデル（LLM）に画像認識機能を追加した大規模視覚言語モデル（VLM）「llava-calm2-siglip」を公開した。

「ChatGPT」画像を見ながら人間みたいに話せる新機能、今後数週間でリリースと予告
OpenAIは6月14日、同社の公式Instagramアカウントを通じ、ChatGPT（GPT-4o）に音声と映像を同時に理解する機能を追加し、今後数週間以内にリリースすると発表した。

画像生成AI「Stable Diffusion 3 Medium」公開　プロンプトの理解力が上がり、リアルな画像が生成可能に
Stability.aiは6月12日、同社が開発する画像生成AI「Stable Diffusion 3」シリーズの最新モデル「Stable Diffusion 3 Medium」を発表、無償の非商用ライセンスおよびクリエイターライセンスの下で利用可能だ。

**デフォルトの名無しさん** · 2024/06/15(土) 11:03:47.63

>>143
それなら既存のRustラッパーでよくね？

**デフォルトの名無しさん** · 2024/06/15(土) 12:50:26.14

根っこの技術がc/c++製でガワだけrustで、それでc++を置き換えたと言えるのか？

**デフォルトの名無しさん** · 2024/06/15(土) 12:55:07.64

>>148
置き換える意味があるかないかの問題でしょ
ほぼシステムコールなグラフィックAPIのRust実装の有意義性はあるのか

**デフォルトの名無しさん** · 2024/06/15(土) 13:06:53.11

>>148
根っこを捨ててpure Rust で再構築したとして
それは置き換えたんじゃなくて
別のものを似せて造り治しただけじゃないのか

**デフォルトの名無しさん** · 2024/06/15(土) 13:08:57.41

>>149
完全に pure Rust の OS があったとして
その上で動くアプリケーションは全て Rust で描かないといけない世界が良いのか
Rust OS の上でも C/C++ で開発したい(API は C 相当)のかで意見が変わる

**デフォルトの名無しさん** · 2024/06/15(土) 13:33:19.67

完全に純粋に一人で打席に立つことは
そいつの年収やそのカネの所有権を定義するのに必要みたいな感じでしょ

**デフォルトの名無しさん** · 2024/06/15(土) 15:03:07.44

勘違いしてる人が多いようだけど
Rustの目的は全てをRustで書くことではなく安全にすることなんだよ
だからOSシステムコール呼び出しもRust(と最小限の各アーキテクチャ毎のレジスタ積み等)で頑張るのではなくCで書かれたlibcを用いている
つまりRustのunsafe部分を最小限にするとともに、unsafeだが枯れて安全なlibcを活用している

**デフォルトの名無しさん** · 2024/06/15(土) 15:11:35.25

勘違いしてんのはここでまともなRustの話ができると思ってるお前だよ

**デフォルトの名無しさん** · 2024/06/15(土) 15:51:53.03

概論でいいんならこれ貼るよ

オブジェクト指向を学ばなかった話
https://qiita.com/adaiimps/items/e04ae03371435aeffe87

**デフォルトの名無しさん** · 2024/06/15(土) 15:54:39.14

自分は pure Rust に全然拘っていないし
むしろ unsafe 大好きだが
pure Rust に拘ってる人や
unsafe 絶対無くせって言ってる人も居るのを知ってる
後者は基地外

**デフォルトの名無しさん** · 2024/06/15(土) 16:13:09.69

use std::io::{self, BufRead, BufReader};
const FULL_BITS: u32 = (1 << 26) - 1;
fn main() {
　let mut shortest: Option<String> = None;
　for line in BufReader::new(io::stdin()).lines() {
　　let line = line.unwrap();
　　let mut bits = 0;
　　for b in line.as_bytes() {
　　　let index = match b {
　　　　b'A'..=b'Z' => b - b'A',
　　　　b'a'..=b'z' => b - b'a',
　　　　_ => continue,
　　　};
　　　bits |= 1 << index;
　　}
　　if bits != FULL_BITS {
　　　continue;
　　}
　　if let Some(ref shortest) = shortest {
　　　if shortest.len() < line.len() {
　　　　continue;
　　　}
　　}
　　shortest = Some(line);
　}
　if let Some(shortest) = shortest {
　　println!("{shortest}");
　} else {
　　eprintln!("ERROR: no matched lines");
　}
}

**デフォルトの名無しさん** · 2024/06/15(土) 17:55:06.95

ソースコードのコピペで止まるスレ

**デフォルトの名無しさん** · 2024/06/15(土) 20:29:16.21

ソースコード貼るなんて暴力ですよ！

**デフォルトの名無しさん** · 2024/06/15(土) 21:06:34.26

コピペしただけなんだけどね

http://mevius.5ch.net/test/read.cgi/tech/1691038333/6

**デフォルトの名無しさん** · 2024/06/15(土) 21:09:34.98

>>156
unsafeは好き嫌いというよりも
最下層のCPUとメモリもしくは境界のFFIで必須な存在とみるべきではないかな
ただしそこだけにunsafeを閉じ込めて一般プログラマーはsafeなインタフェイスのみを使う

**デフォルトの名無しさん** · 2024/06/15(土) 21:10:47.55

一行のコードも書かずに形而上学みたいにプログラミングを学ぶ贅沢はいいね

**デフォルトの名無しさん** · 2024/06/15(土) 21:54:03.45

Rust「で」作るんじゃなくてRust「を」作る秘密が知りたいんだよね
すべてのソースコードがコンパイル時に手元にあったとして、メモリの使途を解析してしまえるなんて普通は思わないからね
この点を「たまたま思いついた天才がいた」で済ませたくない

**デフォルトの名無しさん** · 2024/06/15(土) 22:10:08.33

Copy型とそうでない型。よろしい
Copy型の自動変数みたいにそうでない型もスコープを抜けると解放。それはよろしい
しかしそんなものは遥か実用に遠い

**デフォルトの名無しさん** · 2024/06/15(土) 22:29:19.17

いったい何がきっかけでメモリの使途を把握してしまえるかもと思ったか
それが分かるまでごくごくゆっくりとしか勉強しないよ

**デフォルトの名無しさん** · 2024/06/15(土) 22:33:28.01

ヒープを一切使わないパラダイムは昔に戻っただけ
スタックの安全性だけを考えてヒープはライブラリに任せる

**デフォルトの名無しさん** · 2024/06/15(土) 22:46:06.16

全部スタックでやってるって本当の話なの？

**デフォルトの名無しさん** · 2024/06/15(土) 22:51:02.34

allocaとかとっくにあったよ？

**デフォルトの名無しさん** · 2024/06/15(土) 23:22:17.89

逆のものを想像してんだけどな
スタックでなくヒープにあっても同じなのがRustじゃないの？

**デフォルトの名無しさん** · 2024/06/15(土) 23:47:36.34

参照の寿命が尽きても参照元のデストラクタは呼ばれない
だから参照元がヒープにあろうがなかろうが参照の寿命はスタックに基づいて決めてしまえば良い

**デフォルトの名無しさん** · 2024/06/16(日) 00:42:56.54

>>170
「参照元」は誤用か
参照先と言うべきだったか

**デフォルトの名無しさん** · 2024/06/16(日) 00:50:00.04

>>169
スタック上への参照とヒープ上への参照をRustでは区別しない
ライフタイムさえ満たしていればどこを指していても区別なく参照を扱う
そのため、従来行われてきた「安全にヒープ上でに領域を確保してヒープ上への参照を返す」をしなくても
ライフタイムさえ満たしていればスタック上への参照を安全に渡したり返したり自由にできるようになった
そのため、従来はヒープ上に確保していていたケースがRustではスタック上に置くことができるようになり、その点でも高速化に寄与している

**デフォルトの名無しさん** · 2024/06/16(日) 01:00:26.12

複オジのレスはいつも通り8割は嘘だな

**デフォルトの名無しさん** · 2024/06/16(日) 01:15:13.88

>>172
別にC言語だってallocaの返したポインタとmallocの返したポインタを区別しないけど

**デフォルトの名無しさん** · 2024/06/16(日) 01:25:03.80

誰が解放するか責任もなく解放忘れや多重解放を生むＣ言語は論外だろ
解放されたスタックフレームやヒープエリアを指し続けているポインタが残ったりな

**デフォルトの名無しさん** · 2024/06/16(日) 01:32:46.10

C言語と違って区別しないわけじゃないし、C言語と違って高速ってわけでもない

**デフォルトの名無しさん** · 2024/06/16(日) 01:39:48.74

C言語同様に区別しないし、C言語同様に高速なんでしょう

**デフォルトの名無しさん** · 2024/06/16(日) 01:45:22.24

そろそろ自己隔離しとけザコども

結局C++とRustってどっちが良いの？ 9traits
ttps://mevius.5ch.net/test/read.cgi/tech/1701997063/

**デフォルトの名無しさん** · 2024/06/16(日) 03:32:45.56

へえ、コピーじゃなくて移動をデフォにしちゃうのか

**デフォルトの名無しさん** · 2024/06/16(日) 04:03:11.69

>>174
mallocで得たポインタとallocaで得たポインタは明確に区別しなければならない
mallocで得たポインタのみfreeの対象としなければならない
この区別はCプログラマーの責務でありミスると破綻する

**デフォルトの名無しさん** · 2024/06/16(日) 04:10:20.19

>>180
コンパイラが区別してくれるわけじゃないからそう書いた
今はRustコンパイラの秘密を探ってるんだし

**デフォルトの名無しさん** · 2024/06/16(日) 04:28:58.35

Rustはヒープで確保したメモリ領域も完全自動で安全にメモリ解放されるからプログラマーの負担がなくていいよね

ヒープへの参照とスタックへの参照に区別がないだけでなく
それらをたとえ混ぜて関数間で渡したり返したりたらい回しにしても安全で
もし安全でない使い方をした時はライフタイムが切れてコンパイルエラーになるから自由と安全が両立されてるね

警備員[Lv.18] · 2024/06/16(日) 04:37:34.79

解放されたスタックフレームが残って、どうやって呼び出し元に帰るつもりなんだろう。😱

**デフォルトの名無しさん** · 2024/06/16(日) 04:43:29.58

メモリはコピーじゃなくて（所有権の）移動がデフォ
所有者がスコープを抜けるとメモリは解放
所有者に別の値が代入された際もメモリは解放
代入元は所有権が移ると未初期化の扱いになる

これだけでもかなり面白いね

**デフォルトの名無しさん** · 2024/06/16(日) 04:50:45.28

>>183
C/C++/Rustすべて関数が呼び出し元に戻るときにスタックフレームは自動解放されます
もしその破棄されたスタックフレーム上を指すポインタ(参照)がどこかに残っていた場合、
C/C++ではそのポインタ使用でそこをアクセスしてしまい気づかないバグや穴となるでしょう
Rustではコンパイル時点でライフタイムエラーとなるため問題が起きないです

**デフォルトの名無しさん** · 2024/06/16(日) 05:46:32.57

正体不明のボイス・トォ・スカル
マイクロ波聴覚効果の機能より

神の声兵器は機器の場所が割れているので
ハッキング下と奪取後に器機を複製できた音を宣言していた

電磁波音波なのでむやみに器機に仕掛けると誰かが攻撃しているとすぐに設置したものは察知するが
その監視網をかいくぐるということは一発で危機をジャックしたことになる

そして機器の性能は年々よくなるので自分に行って見分けがつかないくらいになると器機使用者が幻覚を見ていると錯覚し始める

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

メモリはそれ自体は無論のこと、それを指すポインタもひとつしかないわけだ

**デフォルトの名無しさん** · 2024/06/16(日) 07:56:02.10

この発想は正直なかったわ
ひとつのメモリをあちこちから参照すればするほど高効率みたいな思い込みがあるからね

**デフォルトの名無しさん** · 2024/06/16(日) 10:08:57.93

>>167
>全部stack
そういう描き方をすればそうなるってだけで
そういう描き方ならCでも出来る

**デフォルトの名無しさん** · 2024/06/16(日) 10:11:02.64

>>169-171
CにBoxを導入すれば解決

**デフォルトの名無しさん** · 2024/06/16(日) 10:13:30.02

>>173
ほんそれ

**デフォルトの名無しさん** · 2024/06/16(日) 10:32:48.33

で、配列の要素だったり構造体のメンバだったりは「移動済み」にできない？

**デフォルトの名無しさん** · 2024/06/16(日) 10:36:59.18

とにかく&をつければアドレスを借用できて、その生存規則違反はコンパイラがはじく、と

**デフォルトの名無しさん** · 2024/06/16(日) 10:41:20.79

新参に教えといてあげると
172, 175, 180, 182あたりはすべて複製おじさん(通称複オジ)という同一人物だよ
知ったかぶりで出鱈目ばかり書いて全く反省しないという
悪い意味で有名な人ので騙されないように注意してね

**デフォルトの名無しさん** · 2024/06/16(日) 10:51:27.98

1日10行推敲するより1日1万行書いた方が数値化に貢献しやすいからしょうがない

**デフォルトの名無しさん** · 2024/06/16(日) 11:21:38.24

ボローチェッカーは作るのも使うのも難しそう
よくこんなこと可能だと思ったもんだ

**デフォルトの名無しさん** · 2024/06/16(日) 11:48:19.48

Rustの中ではつまらないというか泥臭い部分だね

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

>>196
ライフタイムについてまじめに知りたいなら（ある程度Rustには慣れた前提として）NLLのRFCを読むのをおすすめしたい
ttps://rust-lang.github.io/rfcs/2094-nll.html

そろそろこれよりいい資料は出ないもんかね……というかReferenceに明記してもらえんかね
なんか1.79でも地味にルールが拡張されたようだし

**デフォルトの名無しさん** · 2024/06/16(日) 12:23:11.10

ええっと、メモリの所有者が
・スコープを抜けること
・別の値が代入されること
・別の変数に所有権を移動させること
はもともと検出できる前提なのだよね
ボローチェッカーと言ってもその３つの組み合わせに毛が生えた程度なのかどうか

**デフォルトの名無しさん** · 2024/06/16(日) 12:27:02.82

>>198
全ての言語仕様を「仕様書」としてまとめる提案は出ているんだけど何年も動きがないんだよね……