[過去ログ] Rust part30 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
1: 05/28(水)09:31 ID:ciITeZ5D(1) AAS
公式
外部リンク:www.rust-lang.org
外部リンク:blog.rust-lang.org
外部リンク:github.com

公式ドキュメント
外部リンク:www.rust-lang.org

Web上の実行環境
外部リンク:play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
外部リンク:doc.rust-lang.org

※Rustを学ぶ際に犯しがちな12の過ち
外部リンク:dystroy.org

※Rustのasyncについて知りたければ「async-book」は必読
外部リンク:rust-lang.github.io

※次スレは原則>>980が立てること

前スレ
Rust part29
2chスレ:tech

ワッチョイスレ
プログラミング言語 Rust 4【ワッチョイ】
2chスレ:tech
876: 06/18(水)11:50 ID:7xP0Uzu5(1) AAS
>>874
落ちてはいけないシステムをUB地雷だらけのC++で書くことが愚か
877: 06/18(水)11:52 ID:qy96omZz(1) AAS
>>875
Rustのスレでシステム全体って何やねん
説明してみ
878
(1): 06/18(水)12:16 ID:iDJPvmxA(1) AAS
「意図したpanic」禁止したら良い
その「意図」が正しいのかコンパイラが静的分析出来ないから
879: 06/18(水)12:29 ID:rx2CZFrG(1) AAS
>>878
panicはプログラムやスレッドが続行不可能な時に正しく終了させるためにあります
禁止は困ります
880: 06/18(水)13:09 ID:uPLWgFQC(1) AAS
mseditorがpanicしたら編集中のデータが飛ぶけど、それが「正しく終了」か?
881: 06/18(水)14:28 ID:AeXwuQQu(1) AAS
ヌルポやバッファオーバーランに比べれば比較的マシ
882: 06/18(水)15:01 ID:90mEbGf5(1) AAS
意図的ヌルポでセグフォと
意図的unwrap panicでabortは同じ
883: 06/18(水)15:13 ID:5Mu65nKv(1) AAS
会社の怖い先輩が俺のコードはunwrapでいいんだよと言ったら、そうするしかないよね
884
(1): 06/18(水)15:24 ID:45cvT+VF(1) AAS
まさかとは思うがnullチェックしてれば防げた障害だと思ってるやつがいるのか?
885: 06/18(水)15:37 ID:s5c+Ng5v(1/2) AAS
ぬるぽでクラッシュしたと聞いたけどnullチェックで防げないぬるぽってあるんすか
886: 06/18(水)15:49 ID:FHNv6txf(1) AAS
今どきC++で新たなコードを書くから悲惨な事故が起きた
887: 06/18(水)16:01 ID:hZyAyOg0(1) AAS
>>884
Rustなら防げたと言ってるあのおじさんを除けばそこまてのバカはいないかと
888: 06/18(水)16:01 ID:s5c+Ng5v(2/2) AAS
設定がおかしい場合の例外処理フローはあったけどそこに入る前にぬるぽで爆死した認識
889: 06/18(水)16:35 ID:YaS/uO3Z(1) AAS
RustならコンパイラがAIよりも厳密なチェックをしてるから防げるだろ
890: 06/18(水)17:03 ID:d8qsI0SX(1) AAS
Rustは言語仕様が優れているけど
言語仕様が腐っていればAIでも防げない
891: 06/18(水)17:43 ID:mspDq+p2(1) AAS
世界最長のコンテキストウィンドウ100万トークン入力・8万トークン出力対応にもかかわらずたった7800万円でトレーニングされたAIモデル「MiniMax-M1」がオープンソースで公開され誰でもダウンロード可能に
2025年06月18日 11時43分
外部リンク:gigazine.net
>>MiniMax-M1は、合計4560億のパラメーターが含まれており、トークンごとに459億のパラメーターがアクティブになるとのこと。これはDeepSeek R1の8倍に相当するコンテキストウィンドウです
>>以下のグラフは競技レベルの数学、コーディング、ソフトウェアエンジニアリング、エージェントツールの使用、長文理解タスクにおけるパフォーマンスを主要な商用AIモデルと比較したもの。赤色がMiniMax-M1で、どのタスクにおいても競合AIモデルに匹敵するパフォーマンスを発揮できている
>>MiiniMax-M1はいくつかのベンチマーク、特に長いコンテキスト駆動のベンチマークでClaude Opus 4のパフォーマンスを上回りました」と報告
※AIを動作させている動画あり
↓上記のAIお下記をプレイさせれば性能が判明する
Gemini 2.5 Proは手持ちのポケモンが瀕死になるとパニックに陥る
2025年06月18日 12時30分
外部リンク:gigazine.net

[プロテクトガードやセキュリティーホール発見可能]
※1 プログラムのバグ技[裏抜け道]を使用できる=チートコードを発見可能
・ マリオカートのショートカットはプレイヤー「極悪人」の表の抜け道でNPC「一般人」は使用不可能
[インサイダー/談合/なねーロンダリング/霊感商法など行う時の悪行で音波や電波をしての悪行の方法を発見可能
※ 政治家の法律上の抜け道を仕込める=ある業種だけの法律の抜け道を発見可能
[一般大衆の思考である特定の極悪人から目線を特定の統合失調症へ返させる装置]
※ AIは正確な情報で人間を信用させれる=AIは嘘の情報を一部混ぜて人間を洗脳できる
892: 06/18(水)18:45 ID:JUQ8VjRJ(1) AAS
まさかとは思ってたがnullチェックで防げたと勘違いしてるやつ結構いるんだな
893: 06/18(水)19:12 ID:M/E4rLLd(1) AAS
>読み込みデータに空白フィールドがあり、これがヌルポインタとなって参照した時点でクラッシュを引き起こした。
894
(2): 06/18(水)20:36 ID:QsB71xf7(1) AAS
OptionやResultの型をきっかけとして問題に気付けた可能性はあるんじゃない?
あくまで間接的な可能性でしかなく、この件をもってRustだったら起きなかったとかいうのはアホ丸出しだけども
895: 06/18(水)20:49 ID:JDJPNF+q(1) AAS
Rustなら上位へそのエラー返して
その入力データに対するAPIでエラー返すだけだろ
896: 06/18(水)22:27 ID:/Y6EEbbi(1) AAS
>>894
いいかげんにしろよ
Rustでどうやって問題が起きるんだよ
897
(2): 06/18(水)22:47 ID:BBnSRnVn(1) AAS
この件については、クラッシュを回避しエラーレスポンスを返したところで結局障害になることには違いがないからだな
898: 06/18(水)22:51 ID:ikP0pQuf(1) AAS
>>894
間接的な可能性もないでしょ
899
(1): 06/18(水)23:03 ID:0KvtUriT(1) AAS
>>897
Googleのレポート見ろよ
エラーを返せていれば障害にならなかった
900: 06/18(水)23:18 ID:dYsLBH+C(1) AAS
>>899
そんなことどこにも書いてないぞ
エラーを返していればなんで障害にならないんだ?
回復不能なエラーだぞ
901: 06/18(水)23:25 ID:7PLt8980(1) AAS
Rustなら回避できたケースだけど
無理!と言う人は具体的に無理なシナリオを示してみたら?
902: 06/18(水)23:41 ID:sPCFWro/(1) AAS
ワロ
理解できないから教えてくれと言えばいいものを
903: 06/18(水)23:53 ID:jD4yZQcZ(1) AAS
公式読めよ
Rustにしてればポリシー変更データをエラーにして受け付けず落ちることもなく被害なし
904
(1): 06/19(木)00:10 ID:oQzIUk1I(1) AAS
設定のミスで1台のATMが使えなくなるか全部のATMが使えなくなるかみたいな話でしょ
どっちも障害だから同じだって考え方もあれば
障害を1台に抑えることに価値があるって考え方もある
Rustでも防げないって人は前者だしRustなら防げたって人は後者
どっちの考え方もそれなりに正しい
905
(1): 06/19(木)00:25 ID:KZlMfI+O(1) AAS
>>897
exponential backoffが実装されてなかったから
リクエスト単位のエラー返しにしてた場合は
復旧にもっと時間がかかってたと思われる

かといってC++でヌルポはだめだけどな
906
(2): 06/19(木)00:48 ID:ftBjTcDx(1) AAS
>>905
新たなポリシー変更要求がエラーで受け付けられなくて落ちることもないから障害が起きていない
907
(1): 06/19(木)01:27 ID:l2wwX0Hv(1/2) AAS
>>906
どこにそんなこと書いてる?
新しいポリシーがSpannerに書かれてレプリケートされた後の話だろこれ
908
(1): 907 06/19(木)01:37 ID:l2wwX0Hv(2/2) AAS
ああ、もしかしてポリシーのチェックというのをポリシー自体のバリデーションと勘違いしてるのかな
正しくはポリシーに基づいてAPIリクエストをチェックする処理のことなんで、新しいポリシーが反映された結果としての障害だよ
909: 06/19(木)01:38 ID:QXnAvsJc(1) AAS
>>904,906
君は何を言ってるんだい?
Googleのレポート見ろよ&&公式読めよブーメランが刺さってるぞ
910: 06/19(木)02:14 ID:Pd2QOZgo(1) AAS
>>908
新しいポリシーを反映させないか
反映させても空白のみエラーで飛ばせば障害は起きていない
911: 06/19(木)04:21 ID:yro0K3vV(1) AAS
Rustにしとけってことか、速い話が
912: 06/19(木)05:04 ID:ct5m24p0(1) AAS
落ちるプログラムを各リージョンにバラ撒かなければ何製でも防げてる
もちろんRustなら確実に防げた
913: 06/19(木)06:59 ID:tFafecL1(1) AAS
とにかくRustにすれば安心安全
これはもう常識
914: 06/19(木)11:59 ID:cYRDzc4D(1) AAS
ちゃんとした人が、Rustを使った場合に限る。
セキュリティもそうだけど、人が関わると碌なことがない。
915: 06/19(木)12:27 ID:/pQfT2SX(1) AAS
Rustは安全に配慮したコンセプトはいいけど、それを徹底できていない。
せめてSafe Rust強制モードとpanic禁止モードは用意しておくべきだった。
916: 06/19(木)21:29 ID:67nyX+fT(1/3) AAS
CPUとメモリは自由なunsafeが本質なので下位のライブラリは標準もデファクトもunsafeで作られている
917: 06/19(木)21:38 ID:67nyX+fT(2/3) AAS
panicは意図せず混入防止も兼ねてこんな運用が多いかな
[lints.clippy]
missing_panics_doc = "warn"
918: 06/19(木)21:49 ID:nNn4PbNI(1/2) AAS
標準ライブラリが内部では unsafe だらけというのは確かにそう。
外側に対しては安全になるように配慮してるけど、バグが絶対にゼロかというとそんなことはないし、実際に発見されたこともある。
まあ unsafe に限らず処理系や標準ライブラリにバグがあることを疑ってたらきりがないからそこらは割り切らないと仕方なくない?
919
(1): 06/19(木)21:56 ID:6vmjzLKI(1) AAS
みんな律儀にResultは全てちゃんとハンドリングしてるの?
Mutex.lock() なんかは気にせず unwrap してるんだけど
920: 06/19(木)22:11 ID:nNn4PbNI(2/2) AAS
>>919
ロックが失敗するのはスレッドがパニックしたとき。
つまりハンドリングするならそのスレッド内のエラーであるべきで、 Mutex.lock の失敗に対してハンドリングしても出来ることがない。
そこは普通は unwrap してよいところだと思う。
921: 06/19(木)23:34 ID:67nyX+fT(3/3) AAS
そのmutex毒入り状態からの復帰処理をしたい場合はunwrapせずにErr時に処理とclear_poison()する
922
(1): 06/20(金)00:31 ID:xog7LFS0(1/5) AAS
これおもしろー

外部リンク:blog.guillaume-gomez.fr

ポインターアクセスより配列の方が速いんやー
923
(1): 06/20(金)01:02 ID:SpbybkFq(1) AAS
unwrapではなくexpectを使う。
924
(1): 06/20(金)01:08 ID:xog7LFS0(2/5) AAS
>>923
いや、Optionにはunwrap使ってええんやで
コードに合わせて柔軟に対応すりゃバグは防げるよ
ビジネスロジックのバグは入念なテストしないと見つけられないけどね
ビジネスロジックのバグでシステム障害になることもまあ、あるっちゃあるよねテストしてなきゃ
925: 06/20(金)01:13 ID:/9Nz/yYP(1/2) AAS
>>922
昔読んだが00~99のテーブルをコピーするところだな
配列境界検査は起きないコードだから速度は同じ
926: 06/20(金)01:18 ID:/9Nz/yYP(2/2) AAS
>>924
panic許容シーンでない場合
絶対Some保証できない場ではunwrapもexpectも使わないよな
927
(1): 06/20(金)07:50 ID:d5bZ3vB1(1/2) AAS
expectに書く文がいまいち分からんのだよな
エンドユーザーがその一文だけ見て何か意味があるとも思えないし
デバッグする開発者向けなら結局前後の文脈込みで見るしかないから
unwrapにして詳細をコメントに書いたほうがいい気がしている
928
(1): 06/20(金)08:04 ID:Op1qS17W(1) AAS
>>927
ユーザに文章を示してpanicさせたいの?
文章をprintかeprintしてからpanic!呼んだら?
929
(1): 06/20(金)08:15 ID:d5bZ3vB1(2/2) AAS
>>928
いや、そうじゃなくて「unwrapの代わりにexpectを使ってunwrapしても大丈夫な理由を明記すべき」みたいな言説があるじゃん?
そのときにexpectに書くべき文がわからんって話

ユーザ向けにエラーとして表示したいならそりゃ普通にResult使うし、
どうしてもパニックしたいならprintlnすればいいのはその通りだけど
930: 06/20(金)08:22 ID:xog7LFS0(3/5) AAS
基本フロントエンド側とAPIのエラーコード、エラーメッセ仕様は最初に決めておくから、あとは「どの関数レイヤーで」そのIFに合わせこむかだけじゃない?
ここのスレ多分Rustを業務用で使ってる人ばっかだから仕様の取り決めとから雇用主から降ってくるもんだと思うけど。返すエラー定義決まってなきゃそもそもテストコード先に書けないし、納品物にもテスト結果入れれなくて困るしな
931: 06/20(金)08:25 ID:xog7LFS0(4/5) AAS
個人的にはtracing::debug!で自分用のデバッグ出力はON/OFFしてるけど、エラーコードやエラーメッセージは案件別に全然仕様が違うwwwやめてwwwから、仕方なくErrで一旦上げてresponse.bodyに詰め込む直前で相手さんの期待する結果になるようにparseしてることが多い

フロントエンド側で翻訳ぐらいせえやーって思うけど、たまにバックエンドで各言語に合わせて翻訳やってくれー案件もあったりするしバラバラで何考えてんのかはよー分からん
932
(1): 06/20(金)09:04 ID:ymNSNGAk(1) AAS
>>929
外部リンク[html]:doc.rust-lang.org
に尽きると思うが、何がわからんのかわからん
原則としては例外ケースが生じない確信があろうとエラーコンテキストは引き継がれるべきで、
panicさせるのは当該ケースの対処のしようがないことがその場で明らかなケースのみ
そして君のコード内でコントロールのしようがない事象である以上は基本的にそれは外部要因によるものだろうから、その要因を記載すればいい
933: 06/20(金)09:47 ID:Dy/CHU8X(1/2) AAS
>>932
外部要因ならコード作者は制御できないんだからResultで表現すべきではない?
unwrapするケースって「このコードパスではxは(自分が書いたロジックが間違ってなければ)確実にSomeだから安全にunwrapできるはず」みたいなのだと思うんだけど、
その文をexpectに書いたとして誰が読むんだ?って疑問
934: 06/20(金)10:32 ID:p4ugM+VW(1) AAS
panic時のメッセージは未来の自分を含めて他の開発者向け

ここの2つを読んでおくといいと思う
外部リンク:burntsushi.net
外部リンク:www.thecodedmessage.com
935: 06/20(金)11:10 ID:Dy/CHU8X(2/2) AAS
開発者向けにコードの意図を説明するのって普通はコメントだと思うんだよね
例えばunsafeを使っても安全な理由とかもコメントで書くし
なのにunwrapに限ってわざわざ文字列リテラルで書く理由が分からない(複数行や長文も書きづらいし)
コメントとの違いは実行時に表示できることではあるけど
実行時にその一文を出せて嬉しいか?
開発者なら結局周辺含めてコード読むんじゃない?
936
(2): 06/20(金)11:19 ID:FlGaOpZd(1) AAS
書いてて思ったけど「このメッセージが表示されたらライブラリのバグなんでこのGithubまで報告してね」
みたいなメッセージなら意味あるかな、という気がした
エンドユーザーが見てちゃんと理解できるから実行時に出す意味もあるし、
ライブラリの内部エラーだからアプリケーション側には責任がないことも表明できるし
937: 06/20(金)11:25 ID:xog7LFS0(5/5) AAS
>>936
これいいな。OSSならそんな感じだしエンタープライズなら開発担当部門書いとこ
938: 06/20(金)12:33 ID:3ZKjcbd7(1) AAS
バグなんて他にもいくらでもあるんだから、それこそunwrapに限ってそんな懇切丁寧なケアをする理由がない
やらかした犯人なんてgit blameですぐわかる
939
(1): 06/20(金)13:09 ID:LFsGGVpd(1/2) AAS
expectは使用者とか使用状況に対する期待だと思ってた
メッセージはコメントのPanicsに対応させる感じ

/// ...
///
/// # Panics
/// - Panics if the given size is 0.
///
pub fn make_buffer(size: usize) -> Buffer {
let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");
// ...
}
940: 06/20(金)15:04 ID:3ZuChe0s(1/2) AAS
>>939
基本的にはその考え方で正しい。
でも標準ライブラリや処理系すらそうしてないし、現実は理想通りではない。
941
(1): 06/20(金)16:00 ID:r2H2v8it(1) AAS
Haskellにはならなかったな
Rustにもならないのでは?
942: 06/20(金)16:21 ID:+wQsfMK/(1) AAS
>>941
Rustは本来的にはコーディングの誤りに対して939のようにわりと問答無用でpanicする指向だと思うけど、
関数型というかHaskellかぶれのオモチャにされてるせいで実行時panicダサいみたいな空気が醸成されてきている一方で、
なんでも型のコンテキストで上手に扱えるほど型に表現力があるわけでもないから中途半端な感じになってるね
943: 06/20(金)16:41 ID:3ZuChe0s(2/2) AAS
システムプログラミング言語としての性質があるから仕方がない面はある。
ハードウェアやら OS やらが Rust の性質に従ってくれるとは限らないので言語の側で合わせないと仕方がない。
944: 06/20(金)16:53 ID:IXOAfd5T(1) AAS
Rustバランスいいよな
抽象度の高い記述ができつつC言語の代替もできる
945: 06/20(金)17:25 ID:LFsGGVpd(2/2) AAS
Haskellもボトム型あるから変わらんだろ
どの型の値も計算できない可能性を内包してる
946: 06/20(金)18:40 ID:0ePzwW3B(1) AAS
>>936
そういうのはまとめてpanic handlerに書いたほうがいいんじゃないかな
最近はあまり使われてないかもしれないけどhuman-panicとかがそれ用

あとstdのリファレンスにもexpectに書くメッセージのスタイルについて解説があった
外部リンク[html]:doc.rust-lang.org
947
(2): 06/21(土)18:45 ID:usD2bL3Y(1) AAS
>pub fn make_buffer(size: usize) -> Buffer {
>let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");

事前条件がNonZeroなら
pub fn make_buffer(size: NonZeroUsize) -> Buffer
にしたほうが堅さという意味ではよくない?
948: 06/21(土)19:54 ID:aOIRcMzj(1) AAS
外部入力が起源のデータに対しては必ずエラーを返す
プログラム自身発ならバグであり続行不可なのでpanicしてもよい
949
(1): 06/21(土)19:55 ID:CfyG8iYl(1) AAS
>>947
NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
NonZeroにしたところで結局呼び出し元でのチェックが0との比較からOptionのチェックに変わるだけのことでしかなく、
コードが冗長かつ余計なoptionが入ることでノイズが増え意図が不明瞭になるし、
unwrapしちゃったらpanic時のエラーもわかりづらい
ダメってわけじゃないが呼び出し元のことを考えると独善的な感が否めない
950: 06/21(土)22:49 ID:qYLKV/K+(1/2) AAS
>>949
>NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
Optionと一緒に使うためのものというのはよく意味がわからない

例えばOptionに置き換えて考えてみたとしてこういう実装があったらおかしいと思わない?
fn make_buffer(size: Option<usize>) -> Buffer {
let size = size.expect("size must not be None”)

}

簡単に型で表現できないものならまだわかるんだけど
951: 06/21(土)23:02 ID:qYLKV/K+(2/2) AAS
呼び出し元は外部入力なら
let size = NonZeroUsize::new(input_size)?;
let buffer = make_buffer(size);

定数なら
let buffer = make_buffer(NonZeroUsize::new(1024).unwrap());

validation前とvalidation後で型を変えるプラクティスと同じでこっちのほうが望ましいことのほうが多いんじゃないかという気がする
952: 06/21(土)23:54 ID:l7fBsL1H(1) AAS
整理されて今はこう書くNonZero::<usize>::new(1024)
いずれにせよ外部データ由来時でもpanicさせ得る>>947は筋が悪い
953: 06/22(日)00:46 ID:DjMaTCto(1) AAS
slice::windowsとかstdでも似たような実装はそれなりにある
pub fn windows(&self, size: usize) -> Windows<'_, T> {
let size = NonZero::new(size).expect("window size must be non-zero");
Windows::new(self, size)
}

windowサイズはバグ以外では0を指定しないだろうという想定だと思うがcalleeとcallerのコードを書く人間が異なっていて認識の齟齬があったりすればバグになるからエルゴノミクスとバグリスクのトレードオフってことになる
954: 06/22(日)01:30 ID:MKJ6VV9n(1) AAS
docコメントの
///
/// # Panics
///
/// Panics if `size` is zero.
///
とセットで見ないといけない
955
(1): 06/22(日)09:45 ID:fHVyA0qw(1/2) AAS
RAIIが破綻するレベルのパニック、という意味の専門用語があればいいんだよね
956: 06/22(日)12:30 ID:4aXQSYOG(1) AAS
・人間の思考「脳波」は頭蓋骨の外に漏れない
人間の脳は発光していた!「脳が放つ光」の観測に初成功
2025.06.19 12:00:38 THURSDAY
外部リンク:nazology.kusuguru.co.jp
>>カナダ・アルゴマ大学(Algoma University)の最新研究で、ついにこの「脳の光」を頭蓋骨の外から観測することに成功したのです。
>>UPEは細胞の代謝活動、特に酸化反応によって発生する副産物の一種です。
>>以来、UPEはあらゆる植物や動物の細胞からも確認されており、生体内の酸化ストレスや老化、さらにはがんの診断補助にも応用が期待されてきました。
>>脳は体の中で最も代謝が活発な臓器のひとつであり、神経活動に伴って活性酸素が多く発生します。
>>チームは今回、20人の健康な成人を対象に、特殊な装置を用いた実験を実施しました。
>>被験者は真っ暗な部屋に座り、頭には脳波計を装着。
>>その周囲には、光電子増倍管(PMT)と呼ばれる極微弱な光を検出する装置が配置されました。
>>そして被験者には、目を開ける/閉じる、あるいは音楽(120BPM)を聴くといったシンプルなタスクを行ってもらい、その間のUPEと脳波の変化を同時に測定したのです。
☆>>まず、脳からのUPEは背景光(周囲の空気中のノイズ)とは明確に異なる変動パターンを持つことが判明したのです。
>>とくに後頭部(視覚野)と側頭部(聴覚野)から検出された光は、安静時でも一定のリズムと変動性を示し、他の部位とは異なるスペクトル的特徴を持っていました。
>>さらに目を閉じたときに増える「アルファ波」と呼ばれる脳波の活動と、UPEの強さが同期していることも発見されました。
>>これはつまり、脳の電気的な信号(脳波)と、化学的な代謝反応(UPE)が連動していることを意味します。
>>この成果は、従来のfMRIやPETスキャンのような「重装備で高コスト」な装置を使わずとも、非侵襲・低刺激で脳機能の状態を“光”から読み取る可能性を示すものです。
>>研究者たちはこの新しい手法を「光脳波記録(photoencephalography)」と名付けました。
957: 06/22(日)12:58 ID:LDKwjazM(1) AAS
>>955
パニックのレベルじゃなく処理単位の特性だけどUnwindSafeがある
958: 06/22(日)23:16 ID:fHVyA0qw(2/2) AAS
無限ループがあれば、終了しないスレッドや呼ばれないデストラクタもありうる
bottomもabortもpanicも、無限ループよりはマシだから禁止されない
959: 06/22(日)23:59 ID:ohTY4CfY(1) AAS
exitよりもpanicが優れている
多くのメリットがある
960: 06/23(月)15:14 ID:Lo0+xYyX(1/2) AAS
無職や転職をしたい
上記の方を紹介していただけませんか?

誰でも歓迎❣
未経験でも40歳まで採用しています⭕

ぜひご相談ください🙏

外部リンク:i-c-i.jp

電話番号
03-6459-0063
961: 06/23(月)15:14 ID:Lo0+xYyX(2/2) AAS
株式会社アイ・シー・アイ
野村総合研究所が設立した、信頼と実績のあるIT企業です。
未経験でも大丈夫!40歳までの方ならどなたでもご応募いただけます。
日本の大手大企業のソフトバンク、キャノングループ、富士産業で働けます!
雇用形態は無期雇用派遣。一つの現場で最低5年間じっくりインフラ運用監視の経験が積めます。

年収は280万円、賞与は年3回と安定した待遇をご用意し、「社員の人生を幸せにするため」の福利厚生も充実しています。

当社はまだまだスタートアップ。数年後には事業規模、
会社規模を倍増させたいと考えています。
その際、あなたには会社の中核メンバーとして、一緒に会社を引っ張っていただきたいのです。
962: 06/23(月)18:22 ID:uX2oVrQ8(1) AAS
人売りの奴隷集め
963: 06/23(月)21:09 ID:0odK9WS3(1) AAS
Z世代の皆様にしっかり稼いで頂きたいという思いから、高収入案件をご紹介させていただいております。
964
(2): 06/24(火)22:23 ID:KcGBlJeb(1) AAS
Rustへ移行のためのドキュメント「C++ to Rust Phrasebook」発表
外部リンク:techfeed.io

C++でおなじみのイディオムや設計パターンを、Rust流にどのように書き換えるかを体系的に示したリファレンスである。
各章は具体的なコード例と、それに伴う設計上のトレードオフについての解説で構成される。
「C++ならこう書くがRustでは?」と行き詰まった場面で索引的に参照する使い方も想定されている。
965
(1): 06/25(水)23:33 ID:zC2X3VO4(1) AAS
>>964
「C++ to Rust Phrasebook」
外部リンク:cel.cs.brown.edu
966: 06/26(木)23:30 ID:IZtnbrew(1) AAS
外部リンク:facet.rs
967
(1): 06/27(金)22:34 ID:9/4Hvrnc(1) AAS
所有権を返すfoo()で&foo()をそのまま使える時と
エラーとなるためlet tmp = foo(); してから&tmpを使わされる時と
temporary lifetime extensionルールが関係しているの?
968: 06/27(金)23:03 ID:1LWAsQhh(1) AAS
>>967
おそらくそうだけどコード見ないことには何とも
969: 06/28(土)00:59 ID:CvmYv9Uy(1) AAS
躁鬱が激しいな
970: 06/28(土)13:45 ID:YWzO1cVn(1) AAS
つるつるわれめ
971: 06/28(土)21:59 ID:cIKPEg+8(1) AAS
RPITでもTAITでもないimpl Traitは何と呼ばれているの?
972
(1): 06/29(日)02:06 ID:9bVKBGV1(1) AAS
Announcing Rust 1.88.0
外部リンク:blog.rust-lang.org
973: 06/29(日)02:41 ID:712DhJe3(1/2) AAS
>>964-965
boost使いまくってたら
974: 06/29(日)02:43 ID:712DhJe3(2/2) AAS
わろす
外部リンク:uchan.hateblo.jp
975: 06/29(日)03:42 ID:FAAHlPSo(1) AAS
まだ中3女子がいた時代か…
976
(7): 06/29(日)23:21 ID:kcK1wtsO(1) AAS
>>972
便利になったなー

if let Channel::Stable(v) = release_info()
 && let Semver { major, minor, .. } = v
 && major == 1
 && minor == 88
{
 println!("`let_chains` was stabilized in this version");
}
977: 06/30(月)21:42 ID:Xr9zaQtP(1) AAS
if文を分けなくてよくなったんか
letした変数を次の条件で使えるのは便利だな
978: 06/30(月)23:28 ID:Ewx8aV4S(1) AAS
let else でもチェーンできるのかな
979: 07/01(火)01:45 ID:RyiUYuGe(1) AAS
let chainとかtryブロックとか時間かかりすぎで将来が心配
980
(1): 07/01(火)08:40 ID:WjfKubzq(1) AAS
ぶっちゃけクソsyntaxだろw
981: 07/01(火)08:56 ID:WFD2epuk(1) AAS
プログラミングしたことある人ならば
>>976のようなケースがよく出てくることがわかる
この構文がないと多段ifで可読性が落ちる
982
(1): 07/01(火)13:13 ID:wS9kOuak(1) AAS
むしろなんで最初から用意しようとしなかったのか不思議で仕方がない機能

>>976の例は説明用とはいえ中の人がSemverをChannelで包むのはいただけない
983: 07/01(火)23:18 ID:fT6MdngX(1) AAS
>>976
最近まともな進化がなかったが、久しぶりにいい変更点が来た感じする
984
(1): 07/02(水)08:10 ID:h5Fr+SaE(1/2) AAS
ガイジプログラマーだけど質問あるガイジ?
ガイジガイジガイジ死んだ方が良いガイジ地頭悪いガイジ
死ぬガイジ虚言だから死なないガイジガチで死んだ方が良いガイジ
985: 07/02(水)08:12 ID:h5Fr+SaE(2/2) AAS
後輩が気を使って僕に席を譲ってくれたガイジ…死んだ方が良いガイジ…死にたいガイジ…
986
(5): 07/02(水)14:18 ID:jzgTyLq2(1) AAS
>>976
if文の途中でパターンマッチングできてlet等で変数宣言できるようなプログラミング言語は他にありますか?
987: 07/02(水)15:55 ID:J+FNqJjG(1) AAS
>>984
ガイジガイジよいしょよいしょ
988: 07/02(水)18:49 ID:NOqRQoPr(1) AAS
>>986
いくらでもあるだろw
なんでそれをRustスレで聞くんだよ
複…、バカなの?
989: 07/02(水)21:26 ID:Oh5RPAnK(1) AAS
>>986
LISP 系や ML 系だと出来るのが多いと思う
990
(1): 07/02(水)21:52 ID:oQJmxzOP(1) AAS
>>986
今回の>>976のようなif条件内で連鎖できる言語はないが単純なものならある
991: 07/02(水)21:56 ID:VJuqxJR/(1) AAS
C#でもisで出来るでしょ?もちろん&&でつなげられる
992
(1): 07/02(水)22:41 ID:z9oJfvdC(1) AAS
みなさんおわかりだろうか
>>976

>>986

>>990
993: 07/02(水)22:47 ID:upgcwtw3(1) AAS
C#はようやくリストのパターンマッチングができるようになったところ
994: 07/02(水)23:40 ID:+kkKLbZ1(1) AAS
>>982
仕様を定めるため慎重に議論されてきた
糖衣構文が定められたが既存のdrop順序と合わないと判明した
今年からのRust 2024 editionで新たに定めることで解決してこのたび導入された
995: 07/03(木)00:15 ID:Wcs1wXTl(1) AAS
>>992
本人以外全員分かってると思う

そして…
996: 07/03(木)11:05 ID:FLjzPh5e(1) AAS
時は動きだす
997: 07/03(木)11:33 ID:dZ3pJe+2(1) AAS
シンタックスシュガーだから中途半端なんだよな
998: 07/03(木)16:19 ID:44NH8ILk(1) AAS
パターンマッチングはユニフィケーションにまで発展しないかね。
999: 07/03(木)19:28 ID:OMTYLr6T(1) AAS
>>986
Perl最強だぞ
1000: 07/03(木)19:58 ID:080rUSul(1) AAS
おわり
1001
(1): 1001 ID:Thread(1/2) AAS
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 36日 10時間 26分 35秒
1002
(1): 1002 ID:Thread(2/2) AAS
5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。

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

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

▼ UPLIFT会員登録はこちら ▼
外部リンク:uplift.5ch.net

▼ UPLIFTログインはこちら ▼
2ch板:login
1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 1.445s*