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/10(日) 16:36:43.08

>>727
最初からキレて始めればいいのでは？

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

英語が話せる人はこっちに移住しよう！！！できない人もDeepL片手にカモン！！！
https://www.rust-lang.org/community

日本語コミュはこちら！！！ってかいい加減放置されきった翻訳版の責任者のケツ叩きに行こうぜ！！！
https://rust-lang-jp.zulipchat.com/

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

>>728
キレるはともかく最初からelision rules貼ればよかった説は確かにそう、残念ながら二回目の機会がないが次はそうしてみるぜ
でもよお……こんなのrust-analyzerが完璧なinlay hint実装してくれりゃやらなくて済む話でもあるんだぜ

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

およ？ ID変わった
ID:OGC8ujy2=ID:tFJCBt9mです

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

>>722
staticはdrop呼ばれない

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

C++ で static オブジェクトの初期化順 (解体順) は問題を起こしがちだし、いっそそのへんは取り扱わないというのも妥当な判断のひとつではあるわな。

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

自動化をあきらめることは賛成
だが手動で解放する技術を不要な技術と見なすことには反対する

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

StringやVecみたいなヒープを使う型をstaticで管理させた場合って、valgrindみたいなメモリリーク検出ツールに引っかかったりする？
dropが呼ばれなくても終了時に一応はメモリ解放してるのか、それとも本当に何もしていないのか

**デフォルトの名無しさん** · 2024/11/10(日) 19:15:15.74

>>733
Rustならstatic変数初期化はOnceLockやLazyLockでマルチスレッド競合を含めて安全に初期化できる
static変数でdropはプログラムの終了時も起きないがメモリ解放問題は普通のOS環境では関係ないため問題ない
どうしてもdropしたいなら例えばOptionで包んでtake()で取り出すなどで手動drop()が可能

>>735
手動dropしないならばヒープ領域を持っていても解放されない
これはBox::leak()などで意図的にメモリを解放しないようにした場合でも同様
普通のOS環境ならこれでも問題は全く起きないが
組み込み環境などで確実にメモリ解放したいならば用意するメモリアロケータで対応する
つまりプログラム終了時にメモリアロケータを呼び出して管理している全メモリを解放させればよい

**デフォルトの名無しさん** · 2024/11/10(日) 19:59:43.87

質問の答えになってないし、組み込み環境で「プログラムが終了」したり、「管理している全メモリを解放」できるアロケータが必要などとまで言い出した

いやはや

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

>>735
>>661に適当にこれだけのmain足してvalgrindかけてみた

fn main() {
let s = "2021/07/04";
let (year, month, day) = yyyymmdd(s).unwrap();
println!("{}-{}-{}", year, month, day);
}

https://pastebin.com/UN84vEFb

まあ、リーク扱いで出るよね
こういうのがあんまり多いとマジのリークと区別付きづらくて大変そうだけど、なんかアノテーションみたいなので対策できたりするのかな？

**デフォルトの名無しさん** · 2024/11/10(日) 20:28:05.31

>>738
サンクス
過去にC++で似たようなケースで顧客から「あなたの所のライブラリを使うとメモリリークが検出されるんだけど？」って指摘されたことがあって気になった
説明して伝わる相手なら良いけど、そういう面倒な人からのクレームを避けたい場合はstaticは避けたほうが良さそうだな
本質的には重要な問題でないと思うけども

**デフォルトの名無しさん** · 2024/11/10(日) 20:28:35.21

>>737
組み込み環境であろうとなかろうと各プログラムは終了する
さらにOS環境でOS内であっても各カーネルモジュールのプログラムはアンロードで終了する
一方でもし完全にモノリシックな一つのシステムなら終了後をそもそも考える必要がない

メモリアロケータについては自作したことあるなら管理してるメモリの全解放なんて楽勝だと理解できるだろ
割り当て用に確保しているバッファを返却するだけだ

**デフォルトの名無しさん** · 2024/11/10(日) 20:52:25.18

お前ら、Rustでプログラム書いた後にvalgrind ってるの？
もうそういうの終わりにしたいからRust使ってるんじゃないの？

**デフォルトの名無しさん** · 2024/11/10(日) 20:53:16.70

相変らず単語ひとつひとつが独自用法すぎて解読が困難だね

mallocみたいなグローバルアロケータを自分で実装しようという話をしているのか？
それとも（allocator_apiがいまだにunstableなせいでボイラープレートモリモリ書かされる）typed_arenaやbumpaloのようなカスタムアロケータの話をしているのか？

前者だとしたらバッファという言葉が出てくるのがまず分からない、もしかしてヒープ領域全体のことをバッファと呼んでいて、確保/解放はsbrkのことを言っているのか？
後者だと「管理してるメモリの全解放」ですべての内容のDropしないといけなくて……って考えるとどう考えてもゲロクソむずいけど、全オブジェクトをManuallyDropに包んで返して責任放棄するのかな……

**デフォルトの名無しさん** · 2024/11/10(日) 20:56:00.86

>>741
できねーもんはできねーんだから適切な道具を使うんだよ、笑うならそこの嘘吐き宣教師を笑うんだな

**デフォルトの名無しさん** · 2024/11/10(日) 21:08:26.24

>>742
プログラム本体終了後のメモリ解放のためにdropは必要ない
プログラム全体終了後のメモリリークが組み込みなどで困るケースが対象なのだからそれらメモリを返却するだけでよい

sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだが
それをしなくてもプログラム終了後にメモリリークは起きないので普通のアロケータでは行われていない
メモリリークが起きうる特殊なOSや組み込みならアロケータが借りてるメモリを全返却すればよい

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

>>744
んでどっちのアロケータの話をしてるの？って

**デフォルトの名無しさん** · 2024/11/10(日) 21:22:25.58

>>745
普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きないから対策の必要がない
そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/10(日) 21:35:16.61

>>746
グローバルアロケータの話をしてんのか、カスタムアロケータの話をしてんのか、って聞いてんだよ

自分の頭の中の理屈をダンプするんじゃなく、言葉の定義をすり合わせる努力をしろ

**デフォルトの名無しさん** · 2024/11/10(日) 21:41:49.64

少なくともvalgrindとかperfmonみたいなやつは、プログラム終了時にヒープを辿って解放済みマークの無い場所を見つけたらリークって報告するんだし、一般的にはそれがリークだよ
プロセス終了時にメモリマップの割り当てが解除されるとか、どうでもええわ

**デフォルトの名無しさん** · 2024/11/10(日) 21:48:10.22

>>747
Rustでは#[global_allocator]指定でカスタムなグローバルアロケータを使える
プログラム終了後にメモリリークが起きうる組み込み環境なら対応した自作のアロケータを実装してそのように指定して用いる

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

>>729
May I talk about the ownership reproduction in the formal community web page?

**デフォルトの名無しさん** · 2024/11/10(日) 22:15:02.72

> プログラム終了後にメモリリークが起きうる組み込み環境
組み込みやったことないから知らんけど、そんな環境があんの？

**デフォルトの名無しさん** · 2024/11/10(日) 22:27:44.25

https://github.com/rust-embedded/embedded-alloc

組み込みの典型的なコードってこのREADMEのサンプルコードみたいなんでいいのかね
プログラム(main)は終了しない
ヒープの「解放」処理も無い
合ってるよな？

自由に使える物理アドレス空間の一部を実行時アロケーションのために使用するってだけなら、使い終わりにやる「解放」の処理というのは何の話を言ってるんだ？って思ってたけど
そんなものはない、で合ってるのよな？

**デフォルトの名無しさん** · 2024/11/10(日) 22:31:44.37

>>750
search first

**デフォルトの名無しさん** · 2024/11/10(日) 22:33:46.00

>>751
そういう特殊な環境を出してるのは俺ではないからね
すべてを明示的に解放しなくても我々が普通に使っている仮想メモリ利用では問題ないよという話と
組み込みだとそんな仮定はできなくてメモリリークしていく可能性があるよという話の両方が出ているから
後者でも対応したメモリアロケータを用意すれば対応できるよと解決策を示した

**デフォルトの名無しさん** · 2024/11/10(日) 22:41:08.35

>>753
What do you mean? What I want to do is talking and having a discussion, not searching.

**デフォルトの名無しさん** · 2024/11/10(日) 22:48:01.15

>>754
> そういう特殊な環境を出してるのは俺ではないからね
あれ、そうだっけって思って辿ってみたら言い出してたの>>604だったわ
やっぱお前じゃねーか複おじ

プロセスにしろ組み込みのプログラムにしろ、OSだかシステムファームウェアだかの外部の管理者的存在が行儀の悪いやつのケツを拭いてくれてるだけのことを、
常識的のあるプログラマは「リークしていない」とは言わないんだよ

**デフォルトの名無しさん** · 2024/11/10(日) 23:04:28.91

プログラムの最後に行儀よくbrkやsbrkでOSへメモリを解放しているアロケーターを見たことないな
OSにとってはどうでもいいことだからそんな行儀よさは不要なのだろう
ましてやアロケーターの内部でフラグなどをオフにするだけのfree()はプログラムの最後にいらない
実行中に再利用できるようにするかどうかが本質だろうね

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

えーではリークの定義に関して直接的反論はなしということで
以下はすべて誤りであったということでよろしいですね
対戦ありがとうございました

>>593「freeせずにプログラムが終了したり落ちたりしてもメモリリークは起きない」
>>604「freeを忘れてもあるいはfreeせぬまま異常終了となってもその仕組みによりメモリリークは起きない」
>>631「そしてfree()せずにプログラムが終了してもメモリリークは起きない」
>>744「sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだがそれをしなくてもプログラム終了後にメモリリークは起きない」
>>746「普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きない」
「そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない」

**デフォルトの名無しさん** · 2024/11/10(日) 23:26:36.38

static mutは明らかにunsafeなわけだが
紙一重でunsafeとは言えないstatic変数のことを
警戒するかそれとも無駄な警備を極限まで捨てた合理主義の皇帝みたいに思うか
そういう対立はよくある

**デフォルトの名無しさん** · 2024/11/10(日) 23:33:02.28

プログラム終了後にメモリリークが起きるとすればOSが面倒をみてくれない環境だけだから
そういう環境では特殊な専用のメモリアロケータを用意するしかないだろうね
それならその自作のメモリアロケータをプログラム終了時に呼んで後始末させればメモリリークは防げる
Rustのstaticでヒープを持つ型を使っても最後まで使うメモリをBox::leak()で確保してもメモリリークは起こらないので安心していい

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

Windows/Linux/macOSあたりなら
ファイルハンドルを閉じずにプログラム終了しても
OSが閉じてくれるから何の問題もない
的な主張？

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

> プログラム終了後にメモリリークが起きるとすればOSが面倒をみてくれない環境
また実在しない環境の話し始めた

**デフォルトの名無しさん** · 2024/11/11(月) 00:28:54.94

間違いを認めなくても勝手にすりゃいいけど、そんなんじゃ誰とも意思疎通できないままだぞ
いくら長文を書き連ねても一緒

**デフォルトの名無しさん** · 2024/11/11(月) 00:56:28.26

2種類ある

OSレベルのclose (例えばC言語でのシステムコールを呼ぶclose()) ならばOSが処理してくれるので異常終了含めてプログラム終了時にcloseしていなくても構わない
ただし各言語ライブラリのバッファリングなど他の機能を持つcloseはプログラム終了までに自分でcloseしないとその機能が完遂しない

一方でメモリ解放の場合
OSレベルのメモリ解放 (例えばbrk/sbrk) ならばOSがそのプログラムの仮想メモリ全体を無効にするのでプログラム終了時に解放していなくても構わない
メモリアロケーターライブラリのレベルのメモリ解放 (例えばfree()) もOSにとっては全く無関係な話なのでプログラム終了時に解放していなくても構わない

**デフォルトの名無しさん** · 2024/11/11(月) 01:04:17.69

組み込みは詳しくないんだが今ってOSを使わない
組み込みでRustとか使うの？
Rustのターゲットって多分何らかのOSありきだよね

**デフォルトの名無しさん** · 2024/11/11(月) 01:08:33.73

>>765
語尾にオジを付けな

**デフォルトの名無しさん** · 2024/11/11(月) 01:10:52.04

マ板久々なので意味がわからないｗｗ

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

webassemblyもなんか微妙な感じだしもったいない

**デフォルトの名無しさん** · 2024/11/11(月) 01:13:05.34

>>767
そっか、じゃあ過去のRust本スレを4年分復習してきな
あとここはム板だボケジジイ

**デフォルトの名無しさん** · 2024/11/11(月) 01:16:21.72

すまんのうｗｗ

**デフォルトの名無しさん** · 2024/11/11(月) 01:27:50.38

>>765
OS無しにも対応している
Rustの標準ライブラリstd::はOS前提の機能も入っていてOS無しだと機能しないものもある
Rustの必須な言語機能はcore::ライブラリに部分に分離してまとめてあるので
ベアメタルな組み込みなどではstd::を使わない#![no-std]を指定してcore::を使う
core::では数値型や配列やスライスに文字列(str)およびその複合型が使えるがヒープは対象外なのでVecやStringは標準機能としては使えないといった違いがある

**デフォルトの名無しさん** · 2024/11/11(月) 01:31:24.31

>>768
Wasm自体ブラウザ内も外もどんどん利用が増えてる
もちろんRustで記述が定番化してる

**デフォルトの名無しさん** · 2024/11/11(月) 01:32:59.90

>>771
とこういった感じの書き込みをするRust信者が複おじ
このスレを読む上での必須知識だから覚えておくように

**デフォルトの名無しさん** · 2024/11/11(月) 07:39:38.28

>>732
これ本当？
そうだとするとstatic使った動的ライブラリをアンロードしたら本物のリークが起きる可能性があるが。

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

>727
rustの質問するならclaude ai 3.5 sonetが圧倒的に優秀よ。

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

In the rust forum, we have to use English. How can I say “複おじ”? “Reproduction codger”?

**デフォルトの名無しさん** · 2024/11/11(月) 13:34:10.78

>>727
ほんまにごみ
数学的な(結論出てる)質問しても平気で間違う

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

RustというかCargoの質問なんだけど
crates.ioにリリースしてるもので
一つのcrateでバージョンがいくつかあって
最新のバージョンだけ残して他全部yankedにしてるのに
閲覧回数レポート(crateトップページの下の方の折れ線グラフ)で
yankedされてるバージョンがいつまでもアクセスがあって増え続けて
最新の方がそっちの勢いほどには増えてない
どういう原因が考えられる？

**デフォルトの名無しさん** · 2024/11/11(月) 14:34:31.51

>>778
単純にyankされたバージョン使ってる（つまりCargo.lockにそのバージョンが載ってる）ユーザが多いってだけでは？
yankしたからといって既存のユーザが使用禁止になるわけではないので

**デフォルトの名無しさん** · 2024/11/11(月) 22:49:05.67

>>551
Rustはリファクタリングや機能拡張保守などに適した言語と言われている
強力な静的型付け、借用チェック、参照競合チェック、メモリ競合チェックなどによりコードが思わず壊れることを防ぐとともに
問題点を実行時エラーや実行時デバッグへと遅らせてしまうことを最も少なくしてくれる言語である
そのため全体の開発変更時間が他の言語より短く済んでいる

また、トレイトとトレイト境界による自然なジェネリック化がレイヤー分離独立と最小限の変更での機能追加を容易にしている
どうしてもトレイト設計をし直さなければならない大規模改修の場合でも、上述のように盤石に機能するコードとするまでが早い

**デフォルトの名無しさん** · 2024/11/11(月) 22:59:26.02

借用まわりで質問させてくれ

struct Foo {
　data: Option<Vec<u8>>
}

impl Foo {
　fn do_something(&mut self) -> &mut [u8] {
　　if let Some(x) = &mut self.data {
　　　return x;
　　}

　　// `self.data` is assigned to here but it was already borrowed
　　self.data = Some(vec![0u8; 10]);
　　self.data.as_mut().unwrap()
　}
}

これで self.data への代入の際に「既に借用されている」というエラーが出るんだけど、これって回避できない？
最初の借用が if let Some(x) = ... の箇所で行われていることは理解できるんだけど、
if let のスコープを抜けても借用された状態が続く (以降のコードでの借用ができない) のが腑に落ちない

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

>>781
fn do_something(&mut self) -> &mut [u8] {
if self.data.is_none() {
self.data = Some(vec![0u8; 10]);
}
self.data.as_mut().unwrap()
}

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

>>774
Static items do not call drop at the end of the program.
https://doc.rust-lang.org/reference/items/static-items.html

Drop types placed in statics WILL leak.
https://github.com/rust-lang/rfcs/pull/1440

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

>>782
ありがと、これで回避できた
けど借用のルールはまだいまいち分かってない…

**デフォルトの名無しさん** · 2024/11/11(月) 23:52:53.38

staticはモジュールアンロードする可能性があるなら始末する時に手動dropできるように対処するしかないな
アンロードしないなら問題なし

**デフォルトの名無しさん** · 2024/11/12(火) 00:02:28.18

>>782
えーとOptionがnoneのとき値を入れたいという場合はもっと簡単に書けて

fn do_something()->&mut [u8] {
self.get_or_insert(vec![1,2,3])
}

という感じ。

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

>>781
&mut self.dataにも所有者がある
この匿名の所有者の寿命を'a
型を&'b mut T
とする
'bは'aより長いから'aがいくら短くても、借用された状態が続く

匿名をやめて名前をつければその名前でアクセスできる

**デフォルトの名無しさん** · 2024/11/12(火) 00:13:32.91

なるほど、リークしちゃうんだ。

**デフォルトの名無しさん** · 2024/11/12(火) 00:50:59.75

get_mut OR (insert AND get_mut)を
1ステップにまとめるのは気持ち悪いな

1ステップにまとめていいなら
最初からデフォルト値を入れといてもいいのでは？

**デフォルトの名無しさん** · 2024/11/12(火) 02:10:28.31

>>787
さすが複オジ
ぶっ飛んでるな

**デフォルトの名無しさん** · 2024/11/12(火) 03:23:50.67

>>781
この辺のルールかなって思ったけど正直分からん
https://doc.rust-lang.org/reference/destructors.html

return x;をpanic!()に変えるとコンパイル通ってしまうのはどこかに明確な説明があるかね……

**デフォルトの名無しさん** · 2024/11/12(火) 03:24:11.27

>>781
drop scopeの決定時に制御フローは考慮されないってことなのかなって思ったけど正直分からなくなってきた
https://doc.rust-lang.org/reference/destructors.html

return x;をpanic!()に変えるとコンパイル通ってしまうのはどこかに明確な説明があるかね……

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

>>789
複おじの発想が気持ち悪い

**デフォルトの名無しさん** · 2024/11/12(火) 10:15:49.34

>>781
省略せずに書くと
fn do_something<‘a>(&’a mut self) -> &’a mut [u8]

return xするとxのライフタイムは’a
xは&mut self.dataの一部なので&mut self.dataのライフタイムも’a
‘aのライフタイムに渡って&mut self.dataを借りておく必要があると解釈されるので
self.data = Some(vec![0u8; 10]);はエラーになる

マッチしない場合は借りないようにしてくれよと思うのはわかるが
これは今のバージョンのボローチェッカーの制約
nightlyで使える新しいボローチェッカーならエラーにならない

詳しいのは↓ここ
https://rust-lang.github.io/rfcs/2094-nll.html#problem-case-3-conditional-control-flow-across-functions

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

if self.data.is_some() {
return self.data.as_mut().unwrap();
}
や
if let Some(ref mut x) = self.data {
return x;
}
でも
エラーにならない

**デフォルトの名無しさん** · 2024/11/12(火) 10:23:41.85

>>793
複おじではないよ

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

>>794
新しいボローチェッカーって-Zpolonius=nextのことでいいの？
付けても通らなかったけど、これが通せることを目標にしてるって意味？

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

仇討ちして英雄になりたいのか
とんでもねえ話だなこれ

**デフォルトの名無しさん** · 2024/11/12(火) 13:38:59.51

>>797
-Z poloniusで通る

**デフォルトの名無しさん** · 2024/11/12(火) 14:07:23.60

>>799
おっいけたわありがとう
-Zpolonius=[legacy|next]だと思ってたらいつの間にやらon/offフラグになってたのね

**デフォルトの名無しさん** · 2024/11/12(火) 18:29:56.22

>>781
左右の型が一致しない(右だけ参照)この部分を
if let Some(x) = &mut self.data {
昔からの正規にrefを使って左右の型を一致させて
if let Some(ref mut x) = self.data {
こう書けばコンパイル通る点は興味深いな

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

どうしてこのプログラムがコンパイル通るのかがわからん
明らかにyの寿命はxより短いはずなのに、xより長生きすることが仮定された引数にyを渡したらエラーになるはずでは？
x,yの型をどういうのに変えたらこれをエラーにすることができる？
fn test<'a, 'b:'a> (_x:&'a (), _y:&'b ()) {
}
fn main() {
let x = ();
{
let y = ();
test(&x,&y);
}
}

**デフォルトの名無しさん** · 2024/11/13(水) 00:44:01.02

貸し借りの実態を操作したつもりが、「借りられるのに誰も借りてない」状態が続いただけで
実態が変わらなければエラーも起きない

**デフォルトの名無しさん** · 2024/11/13(水) 01:07:05.96

Rust信者って、説教くさいよね。

**デフォルトの名無しさん** · 2024/11/13(水) 01:22:28.48

急にどしたの？

**デフォルトの名無しさん** · 2024/11/13(水) 02:11:38.53

>>802
test画最適化されて消えてるんだろう

**デフォルトの名無しさん** · 2024/11/13(水) 08:18:30.90

>>803
変更を加えるとしたらどうしたらいいですか？

**デフォルトの名無しさん** · 2024/11/13(水) 08:30:57.78

国内では生成AIに話題を奪われてハイプがめっきり落ち着いた感があるな
世界的には中華圏を中心にまだまだ上昇の余地がありそうだが、国内では残念ながら一部のアーリーアダプタが騒いだだけの言語で終わりそうだ

**デフォルトの名無しさん** · 2024/11/13(水) 08:46:31.60

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

**デフォルトの名無しさん** · 2024/11/13(水) 09:16:26.38

お
refの出番あるじゃん
コンパイラのsuggestちゃんとしてくれよ

**デフォルトの名無しさん** · 2024/11/13(水) 09:17:25.81

>>807
変更を加えるには変更を加えれば良い

**デフォルトの名無しさん** · 2024/11/13(水) 09:19:24.12

>>808
國内の外注プログラマは二次請け三次請けで
コーディングの実態はインドやバングラ
日本人需要はもう無いかもな

**デフォルトの名無しさん** · 2024/11/13(水) 09:22:11.31

>>807
出題者の期待を裏切るような変更しかなさそうだね

微調整だけで解決してほしいとかリセットはやめてほしいとか
そういうのを裏切る

**デフォルトの名無しさん** · 2024/11/13(水) 09:43:08.15

>>802
x,yのスコープと&x,&yのライフタイムを混同してるように見える

fn test<'a, 'b: 'a>(x: &'a (), y: &'b ()) -> (&'b (), &'b ()){
(x, y)
}
とすれば’a: ‘bがなければ関数単体でエラー

fn test<'a, 'b: 'a>(x: &'a (), y: &'b ()) -> (&'a (), &'a ()){
(x, y)
}
fn main() {
let x = ();
let result: (&(), &());
{
let y = ();
result = test(&x, &y);
}
println!("{:?}", result);
}
↑のように&yのborrowをyのスコープを越えて利用すればエラー
でもこの場合の関数定義は’bを使わず全部’aにしても何も変わらない

**デフォルトの名無しさん** · 2024/11/13(水) 17:49:14.41

>>727
最近上がった孫さんの動画だと最新のchatgptはいいみたいだよ

**デフォルトの名無しさん** · 2024/11/13(水) 19:43:07.11

コードの生成なら Claude ai にしておけって。

**デフォルトの名無しさん** · 2024/11/14(木) 00:17:38.18

>>815
こないだ試してみたら、さほど良くなってないみたいだったが。

**デフォルトの名無しさん** · 2024/11/14(木) 04:49:13.06

Claude ai 無料でも有能で笑った

**デフォルトの名無しさん** · 2024/11/14(木) 09:48:02.77

>>817
それはバージョン o1 だった？

**デフォルトの名無しさん** · 2024/11/14(木) 17:17:13.60

>>819
ChatGPTではなく、OpenAI o1 のことかいな?

**デフォルトの名無しさん** · 2024/11/14(木) 20:42:25.26

すまん、違うものだったか
孫さんの動画でGPTの次のバージョンのような扱いしてたので同じかと思ってた

**デフォルトの名無しさん** · 2024/11/16(土) 05:20:14.39

アメリカ政府が「安全な言語を強制する」姿勢は、
「規制」だね。それによりC/C++だけが排除される。
ずる賢い連中だ。日本の半導体もそれで駄目になった。

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

>>822
C/C++のようなクズ言語は早く消えたほうがいい
今はZigやRustなど代替できる良い言語が色々ある

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

時間ライブラリ、chrono使いにくいなーと思ってtimeに乗り換えたけど
メンテ状態がいまいちだし、変な仕様がいくつもあるなーと悩んでた

今日 jiff を見つけて試してみたら、とても使いやすい
設計のベースがjsのTemporalということもあり、変な独自仕様が少なそう
作者が有名人だし、今後も期待できる
ただちょっとバイナリサイズが大きめかな

**デフォルトの名無しさん** · 2024/11/16(土) 09:37:53.01

>>822
規制と言うより新陳代謝。
c/c++にいくら新機能入れても無理が来てる。
ライブラリの都合上まだ仕方なく使ってるけど。徐々に置き換わって行くよ。

**デフォルトの名無しさん** · 2024/11/16(土) 14:25:13.85

プロが一番使っている言語であるところのC/C++だけが、
アメリカ当局の鶴の一声で潰されようとしている。

**デフォルトの名無しさん** · 2024/11/16(土) 14:55:20.01

欠陥言語C/C++が一掃されるのは良いこと
無知と怠惰が欠陥言語にしがみつく