[過去ログ] Rust part24 (1002レス)
上下前次1-新
抽出解除 レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
88: デフォルトの名無しさん [] 2024/06/10(月) 20:09:22.20 ID:QAB9rEB/(3/4) AAS
ボイス・トォ・スカル
電磁波音波攻撃が判明する
人間は電磁界を発生させている
※被害者の身体に痕跡あり
パーキンソン病の原因物質、脳内の可視化に成功
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
96: デフォルトの名無しさん [sage] 2024/06/12(水) 00:41:51.20 ID:wUm4+4hy(1) AAS
ゼロから学ぶRust システムプログラミングの基礎から線形型システムまで (KS情報科学専門書)
Kindleで本日のみ¥500
267(1): デフォルトの名無しさん [sage] 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年短く殺害!
非器機所持者に
世界で初めて固体電池を採用しパワー・安全性・耐久性・バッテリー寿命が超絶高まった最大出力4000Wのポータブル電源「YOSHINO B2000 SST」は家電を複数余裕で動かせてUPSとしても使用可能
2023年12月28日
※最上位は最大出力 6000w
これを最低4機?被害者に向けて配置して合計24000wの電磁波を集中できる配置にしていると犯人は宣言
ウナギの放電」は近くの生物の遺伝子を組換えていた!?
2023/12/11
287: デフォルトの名無しさん [sage] 2024/06/20(木) 20:00:53.20 ID:9lgCTTyf(1) AAS
>>280280(3): デフォルトの名無しさん [sage] 2024/06/20(木) 17:45:56.15 ID:sFnTxIc/(1/2) AAS
Rustのマクロは全言語の中でも優秀だからね
手続きマクロの強力さと利便性は他では代えがたい
宣言マクロももちろん衛生的(健全)で汚染がない
Scheme
301: デフォルトの名無しさん [sage] 2024/06/21(金) 14:19:00.20 ID:TK0ahnJz(1) AAS
競プロ勢だよ
381(1): デフォルトの名無しさん [sage] 2024/06/26(水) 15:00:49.20 ID:KtPyzxFO(1) AAS
C書くしかない時代だったからC勉強できたけど
Rustがある時代に純粋な教養としてC勉強なんて苦行できないだろ
修行僧かよ
393: デフォルトの名無しさん [sage] 2024/06/27(木) 09:50:18.20 ID:OTNDZ+yC(1/4) AAS
>>372372(2): デフォルトの名無しさん [sage] 2024/06/25(火) 23:30:51.26 ID:oKw2Pfcc(1) AAS
>>347
展開しないほうがよい
展開する時も二重ループは発生するだけでなく単なる計算より重い
さらに本来は回避できる浮動小数点を使わざるを得なくなる
そして>>342のコードをその例のような静的ではなく問題入力値に応じて動的に作り出さなければならない
一方で展開しないならばRustコード数行だけで済み任意の問題に対応できる
割り算部分も0/N=0かN/N=1だけなので整数で済む
PyO3おすすめ
413: デフォルトの名無しさん [sage] 2024/06/27(木) 18:50:13.20 ID:veLj9zg3(4/4) AAS
あ、なるほど
&mutみたいに*mutって書けば実体を扱えるわけか
431(1): デフォルトの名無しさん [sage] 2024/06/28(金) 00:57:19.20 ID:UvqDoogo(2/2) AAS
>>430430(1): デフォルトの名無しさん [sage] 2024/06/28(金) 00:48:52.30 ID:uAgz1Jdl(3/5) AAS
>>429
実用的に問題があって、機能できていない。
Rust の仕様に明るくて低レイヤのメカニズムに明るくても Rust で OS は書けないから。
現状では Rust の実装に明るいという要素が求められていて、ある程度はそういうものかもしれないけど仕様 (というか文書化というべきかな) の明確化が十分とは言えない。
本気で言ってるのかなあ
デバイスドライバはRust製に置き換えられたよ
OSもRustで新たに作られて機能することも判明してるけど
既存のOSは書き換えコストの問題だから別問題だね
468: デフォルトの名無しさん [sage] 2024/06/29(土) 15:23:13.20 ID:PsPEDCdZ(2/5) AAS
デジタル小作人やめるレベルの大手術ではなく
地主との関係が変わらないことを保証したいんだな
486: デフォルトの名無しさん [sage] 2024/06/29(土) 20:23:40.20 ID:KH8yb7Br(6/6) AAS
>>481481(1): デフォルトの名無しさん [sage] 2024/06/29(土) 18:13:00.59 ID:E9RFAyQx(1) AAS
>>469
その逆のリファクタリングを影響範囲が大き過ぎて無理って話をcargoのissueで見たことある
cargoはそれ以外でも技術的負債が溜まってるけど影響範囲が大きくなるから簡単に手を入れられないってことを中の人がよくボヤいてるね
だった
558: デフォルトの名無しさん [sage] 2024/07/02(火) 08:41:47.20 ID:hGRi0mb2(1/2) AAS
>>544C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。
もちろんそれを引き継いだ C++ も。
C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。
言語仕様を素朴に実装したら型はわからないんだよ。
printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。
関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。
586: デフォルトの名無しさん [sage] 2024/07/05(金) 10:29:56.20 ID:G0wJmtVU(1) AAS
>>574 >>577rstk より tk ( 外部リンク:crates.io ) の方が良いよ
732(2): デフォルトの名無しさん [] 2024/07/10(水) 22:01:49.20 ID:HryWiaEt(4/4) AAS
>>721721(3): デフォルトの名無しさん [] 2024/07/10(水) 13:29:52.02 ID:kPG9kWdt(1/2) AAS
>>701
そのやり方がなぜ悪いのか理解できませんので、教えてください。
例えば、C++だと、以下の様にするのも別に悪いやり方ではないような
気がするのですが。
class Number {・・・};
Number add(Number &a, Number &b);
Number mul(Number &a, Number &b);
class Integer : public Number {・・・};
class Rational : public Number {・・・};
「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、
これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話
例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、
新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。
この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。
これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。
「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする
こうならないようにするには
a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する
b. 代数的データ型を使う
という方法があり、 Rust では b. の方法も使いやすいので、個人的にはそこが良いなと思う
771(1): デフォルトの名無しさん [sage] 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
>>829829(1): デフォルトの名無しさん [sage] 2024/07/13(土) 14:35:50.27 ID:MYuplL5h(1/3) AAS
つまりRustのトレイトは
LSPの原義に従うと対象外となり
拡張して考えるとLSPを常に満たす
ことになるわけか
意味の上で考えるとしても「常に」は満たさないかと
struct MyString(String);
impl Clone for MyString {
fn clone(&self) -> Self {
Self("元の文字列と関係ない文字列".to_string())
}
}
のようにすれば、そのトレイトが期待する動作に反した型は作れるわけで
引数や戻り値のシグニチャの同一性だけに注目するならtraitに違反することはできないけど、それなら継承やインタフェースでも同じで、「LSPに違反してはならない」という原則はそもそも意味がない (常に違反できないから) ってことになるし
837: デフォルトの名無しさん [sage] 2024/07/13(土) 16:10:18.20 ID:MYuplL5h(3/3) AAS
>>836836(1): デフォルトの名無しさん [sage] 2024/07/13(土) 16:03:55.44 ID:E+PNnzD+(2/2) AAS
829でPartialEq/PartialOrdを例に出したのは
この2つのtraitがsuper/subの関係にあるからで
Cloneとその実装型の関係とは別だよ
PartialEqとPartialOrdの等価判定についてのLSPを考えてる
PartialOrd: PartialEqとする以上
PartialOrdの比較はPartialEqの等価条件を保存すべき←LSP?
みたいな
確かにそちらの例は二つのトレイトが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.048s