[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
88: 2024/06/10(月)20:09:22.20 ID:QAB9rEB/(3/4) AAS
ボイス・トォ・スカル
電磁波音波攻撃が判明する
人間は電磁界を発生させている
※被害者の身体に痕跡あり
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
名市大、頭蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
省14
96: 2024/06/12(水)00:41:51.20 ID:wUm4+4hy(1) AAS
ゼロから学ぶＲｕｓｔ システムプログラミングの基礎から線形型システムまで (ＫＳ情報科学専門書)
Kindleで本日のみ￥500
267(1): 2024/06/20(木)00:30:45.20 ID:GE8fSxUT(1) AAS
chunksは使いにくくタプルにするのも面倒だな
275: 2024/06/20(木)10:13:19.20 ID:gE9bPm4O(1) AAS
正体不明ぼいす・とぉ・すかる【非接触型ムーンショット一式】
AIも発展してきて論文全て読み込ませて作成可能のAI返答なので実在している
世界中の建前
器機所持者と機器秘所持者と機器非所持者ぼいす・とぉ・すかる＝非接触型ムーンショットそんな物無い!
かくなる上は統合失調症だ!
煩いので統合失調症を薬や自殺したことにしてカルテに!
さらに最近は作成しやすいので脇が甘いチームを見つけ次第コロナや感染症で死亡したことにします!
世界中の本音は現実は無慈悲
内臓疾患やバイオテロでの殺害!
統合失調症寿命を平均25年短く殺害!
省7
287: 2024/06/20(木)20:00:53.20 ID:9lgCTTyf(1) AAS
>>280
Scheme
301: 2024/06/21(金)14:19:00.20 ID:TK0ahnJz(1) AAS
競プロ勢だよ
381(1): 2024/06/26(水)15:00:49.20 ID:KtPyzxFO(1) AAS
C書くしかない時代だったからC勉強できたけど
Rustがある時代に純粋な教養としてC勉強なんて苦行できないだろ
修行僧かよ
393: 2024/06/27(木)09:50:18.20 ID:OTNDZ+yC(1/4) AAS
>>372
PyO3おすすめ
413: 2024/06/27(木)18:50:13.20 ID:veLj9zg3(4/4) AAS
あ、なるほど
&mutみたいに*mutって書けば実体を扱えるわけか
431(1): 2024/06/28(金)00:57:19.20 ID:UvqDoogo(2/2) AAS
>>430
本気で言ってるのかなあ
デバイスドライバはRust製に置き換えられたよ
OSもRustで新たに作られて機能することも判明してるけど
既存のOSは書き換えコストの問題だから別問題だね
468: 2024/06/29(土)15:23:13.20 ID:PsPEDCdZ(2/5) AAS
デジタル小作人やめるレベルの大手術ではなく
地主との関係が変わらないことを保証したいんだな
486: 2024/06/29(土)20:23:40.20 ID:KH8yb7Br(6/6) AAS
>>481だった
558: 2024/07/02(火)08:41:47.20 ID:hGRi0mb2(1/2) AAS
>>544
C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。
もちろんそれを引き継いだ C++ も。
C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。
言語仕様を素朴に実装したら型はわからないんだよ。
printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。
関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。
586: 2024/07/05(金)10:29:56.20 ID:G0wJmtVU(1) AAS
>>574 >>577
rstk より tk ( 外部ﾘﾝｸ:crates.io ) の方が良いよ
732(2): 2024/07/10(水)22:01:49.20 ID:HryWiaEt(4/4) AAS
>>721
「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、
これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話
例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、
新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。
この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。
これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。
「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする
こうならないようにするには
a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する
省2
771(1): 2024/07/12(金)10:57:31.20 ID:KyXC0KGT(2/7) AAS
誤解は色々あるけど「努力すれば必ずゼロコストになるカラクリ」が
あると思ってるならそれが誤解だね
クイックソートやハッシュテーブルと同じく、最悪の場合のコストは低くない
830(2): 2024/07/13(土)15:25:32.20 ID:mV5TIlCk(5/8) AAS
>>829
意味の上で考えるとしても「常に」は満たさないかと
struct MyString(String);
impl Clone for MyString {
fn clone(&self) -> Self {
Self("元の文字列と関係ない文字列".to_string())
}
}
のようにすれば、そのトレイトが期待する動作に反した型は作れるわけで
引数や戻り値のシグニチャの同一性だけに注目するならtraitに違反することはできないけど、それなら継承やインタフェースでも同じで、「LSPに違反してはならない」という原則はそもそも意味がない (常に違反できないから) ってことになるし
837: 2024/07/13(土)16:10:18.20 ID:MYuplL5h(3/3) AAS
>>836
確かにそちらの例は二つのトレイトがsuperとsubの関係だからLSPを満たしてるけど
>>830の例はLSPとは関係ないな
957: 2024/07/24(水)08:43:52.20 ID:NUYI7xpt(1/2) AAS
・タプルは型を混合できる
・タプルはイテレートできない
・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う
で良いんじゃない？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s