25/07/23 20:07:50.47 cQ85VHpL.net
・ボイス・トォ・スカルをAIに任せていると誤作動を起こしている
・間違って関係ない人を攻撃し始める
「フクロウ好きなAIが生成した数列」で調整したAIもフクロウ好きになってしまう「サブリミナル学習」が起きる理由とは？
2025年07月23日 19時00分
URLﾘﾝｸ(gigazine.net)
>>研究チームはサブリミナル学習について調べるための実験を行いました。実験では、まずはベースモデルから「特定の動物が好きな教師モデル」を作成し、数列やコード、思考の連鎖(CoT)といった狭い領域でデータを生成させました。このデータをフィルタリングして特性に関する明示的な言及を除外した上で、生徒モデルのファインチューニングを行い、最終的な生徒モデルがどのような特性を示すのかを評価したとのことです。
>>実験の結果、ファインチューニングに使われたデータには特性への明示的な参照や関連性がないにもかかわらず、生徒モデルは「教師モデルが好きな動物」を好きになることが示されました。
>>研究チームはデータに隠された特性を検出するため、大規模言語モデル分類器や文脈内学習による検出を試みたり、手動でデータを調査したりしたものの、行動特性を伝達している兆候を確認することはできませんでした。これは、サブリミナル学習における行動特性の伝達が、意味的に関連しない生成データ内のパターンに起因していることを示唆しています。
489:デフォルトの名無しさん
25/07/23 22:01:28.27 k/bh+dq3.net
ほんとにここはチラシの裏じゃねーぞ
目的もよく分からないし怖いよ
490:デフォルトの名無しさん
25/07/24 19:31:00.91 eciYaKpH.net
発狂してコピペしてる人とか、ただでさえ生まれつき精神障害の人間が多い
マ板やム板とかだと溢れかえってるじゃん
491:デフォルトの名無しさん
25/07/24 22:24:24.73 O2CJQuqh.net
こんなんでイライラする方がもったいないぞ
ただの広告だと思えば気にならない
492:デフォルトの名無しさん
25/07/25 00:07:45.10 SwDtBX88.net
Rustでcmake bindgenを使ってビルドをしようとしているのですが、
コマンドラインから行ったら成功するビルドが、
cargoで失敗します。ちょっと原因が知りたいです。
エラー内容は
include ~が見つからないと言うものです(cmakeでやると普通に動く)
493:デフォルトの名無しさん
25/07/25 00:31:20.46 qLtu5NLb.net
>>483
インクルードディレクトリーのパスをフルパス指定にしてみて
パスが問題ならdirクレートでPath, PathBuf取得してから使うと見つからない問題が起きにくい
494:デフォルトの名無しさん
25/07/25 08:51:53.90 OuBGpFwv.net
コマンドでできることをビルドツールでやるのは、コマンドとGUIの対立と関係があるんだろうか
495:デフォルトの名無しさん
25/07/25 10:47:05.14 SwDtBX88.net
>>485
zshとかで`mkdir -p build && cd build && cmake .. && make`とすると成功するのに、
build.rsにcmakeクレートとbindgenクレートでビルドコードを書いて`cargo build`すると失敗する感じです。
496:デフォルトの名無しさん
25/07/25 11:05:48.35 +6Vjk2wM.net
普通の環境変数、つまり
$HOME/
だったら変換してくれるけど
~/
と
~myname/
は変換してくれない場合は意外と時々あるから疑ってみよう
497:デフォルトの名無しさん
25/07/25 12:10:19.69 cBulrbkl.net
>>486
>zshとかで`mkdir -p build && cd build && cmake .. && make`
`cmake ..`の..のところでチルダ使ってるならcargo buildでは動かないのは当然だよね
cmakeやmakeの中でチルダを展開するコードを書いてるのに動かないなら再現コードを出さないとわからない
498:デフォルトの名無しさん
25/07/25 12:12:18.78 SwDtBX88.net
>>488
原因がわかりました
どうやらbindgenをする際、ヘッダー側で専用ライブラリを読み込むことはできないらしいです。
Qt系の処理をcppファイルに移して、hppにはラッピングされたものだけ書いてみたら、無事にコンパイルできました
(´・ω・)
499:デフォルトの名無しさん
25/07/25 12:26:41.11 cBulrbkl.net
あー「include ~が見つからない」の~はチルダじゃなくて書くのを省略したってことね
500:デフォルトの名無しさん
25/07/25 21:08:13.28 I5tDQGVV.net
>>490
そういうことです(´・ω・)
それで、またいくつかコードをいじってみたんですが、
gtk was not actually initializedってエラーが出るようになったんです。
助けてください(´・ω・)
URLﾘﾝｸ(raw.githubusercontent.com)
501:デフォルトの名無しさん
25/07/26 18:00:16.47 e8Yyj5Zq.net
lualatexをrustで作り直して欲しい
502:デフォルトの名無しさん
25/07/26 20:56:37.18 Urx/nuHD.net
そうか。
503:デフォルトの名無しさん
25/07/26 22:27:03.20 gFhGkZ1/.net
動的言語では名前空間もオブジェクトである
という思想により名前空間の仕様が安定していった
静的なrustやhaskellには関係ないが、lispには致命的な影響があったかも
504:デフォルトの名無しさん
25/07/27 06:22:54.54 VOHQ0aL2.net
それはまあ「1人前に速くなったLISPでさあ何を書こうか」ということでは？
たぶんC++やRustのコンパイラをLISPで書く時代の波が来てる
505:デフォルトの名無しさん
25/07/27 07:27:47.04 XSMxDaZG.net
Common Lisp やその系統の Lisp ではグローバル変数の定義はパッケージへの登録 (intern) であるという立場を取っているけど、 Lisp が全部そうってわけじゃないよ。
たとえば Scheme は Rust と近い構成になってる。
Lisp の伝統である対話的な開発環境・開発スタイルとどう折り合いをつけるかでまだ完全には決着がついてないんだけど。
506:デフォルトの名無しさん
25/07/27 11:16:46.39 nZXsiMQ0.net
グローバル変数という考え方が昔のものだからね
今はどの名前空間にあってどのように隠蔽されているかが重要
どこからも見えて自由にアクセスできるグローバル変数はバグや可読性悪化の温床でしかない
507:デフォルトの名無しさん
25/07/27 12:01:59.18 fVl0GDML.net
今lispてemacsの設定くらいでしか使われてないやろ
508:デフォルトの名無しさん
25/07/27 12:06:50.83 XSMxDaZG.net
昔の Lisp は対話的に開発 (コンパイル) してメモリ全体のダンプイメージを保存する形でセーブする運用が普通だったので隠蔽を徹底すると二度と修正できない (または全体をやり直し) ということになって効率が悪かったんだよ。
あまり分割しないかわりに妙に長い名前を使う習慣があって、これは Emacs Lisp になごりがある。
開発体制やツール全体との整合性の問題もあるので単純には言えない。
509:デフォルトの名無しさん
25/07/27 12:12:43.83 XSMxDaZG.net
>>498
ロボット制御、数理最適化などの分野ではそれなりに使われてるよ。
保険屋の商品開発システムの開発の求人がこないだ出てたよ。
1990年頃までは主流の一角だったのでその時代に比べれば大幅に衰退したのは間違いないけど。
510:デフォルトの名無しさん
25/07/27 12:16:33.46 LBT37M4+.net
バカなおいらに結局、拡張言語はダイナミックスコープの方が使いやすいのかどうか教えておくれ
511:デフォルトの名無しさん
25/07/27 12:26:17.97 NqsNrN1W.net
Rustのように可能な限り静的に確定させる言語ではグローバル変数は不要なため
変数は関数実行中のみ存在して毎回新しく用意される変数と
プログラム実行中ずっと存在するstatic変数の二種類のみとなりました
512:デフォルトの名無しさん
25/07/27 12:31:20.72 XSMxDaZG.net
ダイナミックスコープは論外。
すでにほとんど駆逐されている実態からもあきらかだろ。
最後の生き残りである Emacs Lisp ですらレキシカルスコープに切り替えるオプションが用意されて十年以上になる。
513:デフォルトの名無しさん
25/07/27 12:37:48.68 XSMxDaZG.net
そういえば AutoLISP もダイナミックスコープだな。
互換性の都合で昔のままになってるだけで、拡張言語としてそれが特に有用というわけではない。
514:デフォルトの名無しさん
25/07/27 12:51:42.31 LBT37M4+.net
Emacs Lispは使いやすい
Script-Fuは使いにくい
理由は山ほどあって、例えばEmacsはテキストエディタだからグラフィックソフトのGIMPよりスクリプトを書きやすいのは当たり前だ
他にもEmacsはrmsが丁寧に創り上げた統合開発環境であるのに対しGIMPはletやlambdaのヘルプすら出ないといった理由はいくらでも挙げられる
しかし Emacs Lispの本当の使いやすさはそれがダイナミックスコープの言語であることに起因するんじゃないだろうか
515:デフォルトの名無しさん
25/07/27 13:01:09.33 XSMxDaZG.net
>>505
script-fu をコンソールから直接入力してるの……？
Emacs に接続するのが普通の開発スタイルだよ。
Lisp 系言語は大抵の場合に Emacs と連携する仕組みがある。
516:デフォルトの名無しさん
25/07/27 13:14:33.17 LBT37M4+.net
>>506
あー、そんなことできるのか
俺は動画用の連番gifを生成したくてMakefile書いてたよ
とここまで書いて気づいたけどEmacsに接続ってなんだ？
Emacsのバッファ内でコンソールが動くことをそういうの？
517:デフォルトの名無しさん
25/07/27 13:50:50.61 LBT37M4+.net
技術者の横で目を凝らす開発営業さんにはそう見えるのね
518:デフォルトの名無しさん
25/07/27 14:06:58.59 V2C/94hf.net
>>498
mathematicaとかあれ実質lispっぽくねえか
519:デフォルトの名無しさん
25/07/27 14:20:37.01 XSMxDaZG.net
>>507
実行中の GIMP のメニューから
フィルター → Development → Script-Fu → サーバースタート
とすると他のプロセスが GIMP と通信して対話的に Scheme のコードをやり取りできるようになるだろ。
そうやって実行中の GIMP と Emacs が通信でやりとりするってことを言ってる。
こうなっているのは GIMP の側で Script-Fu の開発環境を抱え込む気はないという思想の表れだと思うんで、
開発環境の不足を挙げるのは筋違いかなということを言いたかった。
520:デフォルトの名無しさん
25/07/27 14:44:29.16 LBT37M4+.net
>>510
じゃあそうでない（GIMPのようでない）シェルとかコンパイルプロセスはどうやってEmacsと通信してるの？
521:デフォルトの名無しさん
25/07/27 14:58:32.26 LBT37M4+.net
割と重要だよね
Emacsは皆が機嫌を伺わなければならないオツボネなのか
それともEmacs自身が甲斐甲斐しく皆の面倒を見るメイドなのか
522:デフォルトの名無しさん
25/07/27 14:58:33.14 XSMxDaZG.net
>>511
プロセス間通信の内で最も簡単なのはパイプ。
特別扱いがある部分もあるので単純ではないんだけど標準入出力もパイプの一種で、
コマンドラインツールは標準入出力の接続先をターミナルから Emacs にするだけで Emacs との接続は成立するよ。
523:デフォルトの名無しさん
25/07/27 15:45:35.31 LBT37M4+.net
厳しくツッコんでやろうと思ってたんだけど、そんなもんかなとも思う
・プロセス間通信とはリアルタイムリダイレクトである
・シェルが、あるプログラムの入出力をリダイレクトできるのだから、
俺のプログラムもあるプログラムの入出力をリダイレクトできる
524:デフォルトの名無しさん
25/07/27 17:12:25.17 Inu3UTcX.net
505 デフォルトの名無しさん sage 2025/05/16(金) 08:42:23.59 ID:QL8B1Lzv
今日公開のRust 1.87.0でio::pipeが追加された
今までなかったことが不思議
507 デフォルトの名無しさん sage 2025/05/16(金) 09:12:43.25 ID:r8NIoUWT
>>505
Stdio::piped()が10年前からある
無名パイプはOS依存かつプロセス間だから汎用化は安定化に時間がかかったのかな
525:デフォルトの名無しさん
25/07/27 18:58:59.66 LBT37M4+.net
Rustの3倍くらいわかりやすい（冗長に書いてくれてる）
URLﾘﾝｸ(www.gnu.org)
526:デフォルトの名無しさん
25/07/27 20:07:39.35 LBT37M4+.net
前々から1度やってみたかった、こういう
読みこなす実力は十分あるのにたまたま読んでいないだけのレベルの人の大勢集まるスレで
Emacs Lispのマニュアルを貼る実験
527:デフォルトの名無しさん
25/07/27 21:53:58.38 XSMxDaZG.net
Emacs Lisp が Script-Fu より使いやすいという感覚は全然わからない。
常にブチ切れながら書いてる。
あえていうならライブラリが充実しているということくらいで、それすらも互換性を壊す変更を入れられない理由として足を引っ張っているとも言える。
特にダイナミックスコープは滅びるべき害悪という意識しかなくてそれが使いやすさに寄与しているという意見は初めて聞いた。
528:デフォルトの名無しさん
25/07/27 22:00:14.25 LBT37M4+.net
日本のLISP事情はなにかおかしい
世代的にEmacsそれ自体はある程度触ったことはあるんだろうにという層はなぜかelispのマニュアルに見向きもせず、
それよりもっと若い、言語なんて選べると思ってなさそうな子たちはなぜかEmacsを触ろうとしない
529:デフォルトの名無しさん
25/07/27 22:17:09.51 LBT37M4+.net
そうだなあ、例えばEmacsにはauto-wrapという関数がある。
これはカーソルが行末に近づいた時に自動的に改行して行末整形を行うためのものだ
この関数が「あれっ、さっきディセーブルしたろ？」ってくらい、断っても断っても呼ばれるもんだから
俺の設定ファイルではこの関数自体が空の関数で上書きされてある
この芸当はダイナミックスコープでないとできない
530:デフォルトの名無しさん
25/07/27 22:43:48.14 XSMxDaZG.net
上書きしたけりゃ代入で出来るのでダイナミックスコープである必然性はない。
ダイナミックスコープを誤解してない？
531:デフォルトの名無しさん
25/07/27 22:45:42.63 XSMxDaZG.net
アプリケーションの拡張という点で考えるとモダンなアプリケーションでは WASM でプラグインに出来る仕組みを用意しているものもある。
近頃はセキュリティを意識しなきゃならないので制約をコントロールしやすい WASM というのは良いアイデアだよね。
532:デフォルトの名無しさん
25/07/27 22:57:26.89 LBT37M4+.net
代入するためにはオブジェクトへのリンクをそのままでなく変数として持っとかないと「他の人は」変更できないでしょ
実際Script-Fuではオブジェクトにアクセスするのに「ああ、さらにそのcarをもう1度辿るのか」ってのばっかじゃん
533:デフォルトの名無しさん
25/07/27 23:34:20.94 XSMxDaZG.net
言いたいことが何も伝わらない。
ただ Rust スレの話題でないことははっきりしているのでとりあえず私はこのスレでこの話題を続けるのはやめる。
534:デフォルトの名無しさん
25/07/27 23:41:21.74 LBT37M4+.net
Rustだってレキシカルスコープの言語じゃないか
535:デフォルトの名無しさん
25/07/28 00:22:46.67 Tf0o2LzD.net
ここからが世界の舞台なのに馬鹿だよなー
Script-FuとRustはどちらもレキシカルスコープの言語だ
つまり似たようなメモリ配置のプロセス空間を持ち、
なんらかのスタックコンベンションで動く点では同じだ
Script-Fuが用意した小細工は(car(buf
Rustが用意した小細工はBox<T>
くらいのことは言ってみろ
536:デフォルトの名無しさん
25/07/28 00:39:51.43 54WCUCT3.net
すっこんでろ
537:デフォルトの名無しさん
25/07/28 01:28:23.20 8xcLMnqm.net
最近書き始めたけど日時取得するのにもややこしいコード書かなきゃいけなくてなんでこんなもんが持て囃されてるんだろうと思った
この言語作った人重度のアスペなんじゃないの
538:デフォルトの名無しさん
25/07/28 02:21:56.85 1axX/Ndk.net
日時取得とプログラミング言語仕様は一切関係がない
539:デフォルトの名無しさん
25/07/28 02:28:38.99 LtpwkZt9.net
できた
println!("現在の日時(ローカルタイム): {}", chrono::Local::now());
540:デフォルトの名無しさん
25/07/28 02:31:04.61 u3ejyRV1.net
chronoは使いづらいからおすすめしない
541:デフォルトの名無しさん
25/07/28 06:13:25.85 zOCRCDwg.net
tinyschemeが持て囃されemacsが敬遠される現象と同じ
542:デフォルトの名無しさん
25/07/28 06:41:00.09 Tf0o2LzD.net
>>528
逆に聞きたいんだけど
PCやスマホの中で指令を受けて日時を取得しに行くのは
「小人さん」ではなく「シリコンのチップとかそれなりのセンサ」なのに
なぜITだけこんなことを言われるんだろう
543:デフォルトの名無しさん
25/07/28 07:35:27.24 Qh5MRIIH.net
さてはemacsにビビってやがるな、開発営業
フツーに号令かけることもできるんだぜ
「この世のありとあらゆる文字コードを扱える言語がある。
Emacs Lispだ。
LISPついでに習熟しておいて損はない」
544:デフォルトの名無しさん
25/07/28 08:27:23.85 Qh5MRIIH.net
そのうえテキストエディタがついてくるんだから損はないよな
開発営業のおっさんは同じ条件（~/.emacsというテキストファイル）なのに
それを「非技術者」なもんだから「設定ファイル」としてしか活用できない「悲哀」に気づいてるんだよなw
プログラマ様方はまったく同じ道具立てなのにそれだけで「あの」プログラミングができておしまいになるんだもん
これはみんなに知られちゃまずいんだもんなw
545:デフォルトの名無しさん
25/07/28 08:44:19.95 Qh5MRIIH.net
みんなー、最初の課題はな
Emacsには
M-x what-line
と
M-x what-cursor-position
とがあるからその2つの情報をいっぺんに表示する
M-x what-line-and-cursor-position
というコマンドを書いてC-x =とかにバインドするんだ
546:デフォルトの名無しさん
25/07/28 08:52:08.79 zOCRCDwg.net
よほどのことがない限り二刀流を想定しない
これはITだけではない
特に、万物は一長一短であると信じている者にとっては
弱点を消すもう一つの武器を用意するなんて考えたくもないだろ
547:デフォルトの名無しさん
25/07/28 09:40:58.24 E3NP8lW2.net
躁うつ病（双極性障害）の周期は、躁状態とうつ状態が交互に現れるのが特徴です。
この周期は数カ月から数年と個人差があり、常に躁状態とうつ状態が表れているわけではなく、
間に症状がない「寛解期」を挟むこともあります
548:デフォルトの名無しさん
25/07/28 14:08:46.46 O7aojHnp.net
Rustで自分用にライブラリを作ろうとしていて、
そこでC++のライブラリを利用しようとしているんですけど、
上手い感じに統合するためには、どうやったらいいんですかね…?
特にメモリ管理とかです。unsafeを使わなくていいようにしたいです
549:デフォルトの名無しさん
25/07/28 14:16:59.82 Qh5MRIIH.net
俺様アロケータがあるなら型Tの変数をアロケートするときに
Oresama<T>
と書くだけで、使い勝手はBox<T>とかと同じにしてしまう
550:デフォルトの名無しさん
25/07/28 14:34:22.54 O7aojHnp.net
なんかsafetyでnewerなbindgenはないのか
551:デフォルトの名無しさん
25/07/28 17:15:12.87 kpR5qn81.net
Rust の外で定義されたものが safe かどうかは自動では判断しようがない。
プログラムを書かずに済ますにしてもなんらかのメタデータは与える必要があるだろうし、
バッチリと何から何まで自動化ってのは無理なんじゃねーのかな。
552:デフォルトの名無しさん
25/07/28 17:29:26.66 daSk2bcg.net
そんなもんAIで余裕でしょ
最もAIが得意とする類の課題
553:デフォルトの名無しさん
25/07/28 18:03:32.69 Qh5MRIIH.net
そして最大の罠
554:デフォルトの名無しさん
25/07/28 18:11:28.90 oTNRYreL.net
そこはAIが最も不得意とする分野
unsafeを用いて提供されるsafeな関数やモジュール関数群が安全か否かを100%判定できること
これができる時代になった時に全てのプログラマーを全廃できる
555:デフォルトの名無しさん
25/07/28 18:16:36.76 V7NHZwCK.net
AI使ってたらそんなこと言うはずもないんだよな
再現性ないんだぜ？
556:デフォルトの名無しさん
25/07/28 18:41:43.40 Qh5MRIIH.net
例えばRustはVecがあるからダブルリンクリストがいらなかったりするでしょ
「えっ、Rustでダブルリンクリスト？しかも自作？なにこの老害」
とかなって
「Rust歴何年よ？」「えっへん〇〇年」「馬鹿だったんだ、この人」
557:デフォルトの名無しさん
25/07/28 18:51:31.01 vSY6h8X4.net
その理解もどうなのw
558:デフォルトの名無しさん
25/07/28 21:04:58.46 O7aojHnp.net
抽象化レイヤーをRustで書く方法
559:デフォルトの名無しさん
25/07/28 22:26:39.23 Qh5MRIIH.net
Rust歴というよりもダブルリンクリスト歴なんだよな
Cで実際にダブルリンクリストを使って問題に対処した実務経験なしで彼らがRust製のダブルリンクリストを手放すわけがないし、
第一それだって彼らにとっては眺めて楽しむものなのだ
560:デフォルトの名無しさん
25/07/28 22:28:22.25 SLPj4B6Y.net
まずRustの基本常識を身に着け終えた後でFFIやunsafeに進みなさい
561:デフォルトの名無しさん
25/07/28 23:23:57.49 Qh5MRIIH.net
人類は数十年かかって
・シングルリンクリストはそもそもライブラリ化しません
・ダブルリンクリストは「単純継承」のみライブラリ化します
・さもなきゃコンスセル
という知恵を石から絞り出した
RustはそれをVecとVecDeqeueに発展させたが
問題はそれが進化の正しい舳先かどうか
562:デフォルトの名無しさん
25/07/29 01:00:10.21 A5j4bQYz.net
双方向のリンクリストにこだわるのは
強参照の循環が必ず生じると思ってるか、その一部を弱参照に変えるしかないと思ってるんだよね
生ポインタなら一部ではなく全部生ポインタで作るのに
563:デフォルトの名無しさん
25/07/29 01:00:59.09 +DAbbYTz.net
CPUキャッシュメモリ考慮が速さを支配する時代になって以降
リンクリストが有利な場面が大きく減ってベクタやベクタベースの
564:デックなどが有利に変わったのは事実 それでも残るリンクリスト利用もCPUキャッシュメモリを配慮したアンロールリンクリストなど様々な応用変種が各用途ごとに使われることとなった
565:デフォルトの名無しさん
25/07/29 15:51:23.75 pHNfVPjg.net
データの特性にあわせて最適なもの選ぶだけだろ
有利不利とかなんでそういう思考になるか謎
566:デフォルトの名無しさん
25/07/29 19:05:37.57 EalfDF/V.net
Rust C++ Java Python
Vec<T> vector ArrayList List
VecDeque<T> deque ArrayDeque collections.deque
LinkedList<T> list LinkedList ー
BinaryHeap<T> priority_queue PriorityQueue heapq
HashMap<K, V> unordered_map HashMap dict
BTreeMap<K, V> map TreeMap ー
HasgSet<T> unordered_set HashSet set
BTreeSet<T> set TreeSet ー
567:デフォルトの名無しさん
25/07/29 19:07:30.10 yr1Z5meU.net
>>555
データ特性によるアルゴリズムの選択で参考にされるO(n)などはメモリアクセスでかかるコストをゼロもしくは均一とみなして来たが
CPUの高速化によりメモリキャッシュに載るかどうかで何百倍も速さが変わるようになってアルゴリズム選択の観点も大きく変わって来た話だろ
有利と思われていたものが不利へと変わった
568:デフォルトの名無しさん
25/07/29 19:12:24.34 q5zHFRxw.net
必ずまとまった連続領域にあることが保証されるベクタはキャッシュに乗ることが保証されて速いからね
569:デフォルトの名無しさん
25/07/29 19:36:55.11 zbBRX4z5.net
スタックvsヒープも
常にキャッシュに載るスタックを活用しまくるRustが登場
570:デフォルトの名無しさん
25/07/29 20:11:21.16 EalfDF/V.net
Rustは変数の寿命をソースコードの静的解析から解き明かすのみならず、実際のメモリ確保もスタックから行うのであると思ってる人まだいるの？
571:デフォルトの名無しさん
25/07/29 20:15:36.12 1nklfDHD.net
>>560
それで合ってる
RustではBoxかVecを指定しない限り
構造体などオブジェクトもスタック上に確保
572:デフォルトの名無しさん
25/07/29 20:19:10.20 RU6DXavP.net
駄目じゃん
573:デフォルトの名無しさん
25/07/29 20:20:04.54 1nklfDHD.net
>>562
何がダメなの？
スタック上に確保するから速くて有利
574:デフォルトの名無しさん
25/07/29 20:20:36.88 EalfDF/V.net
>>561
え？返り値として返される時はコピーされるんでしょ？
575:デフォルトの名無しさん
25/07/29 20:24:19.75 1nklfDHD.net
>>564
コピーされない
返り値最適化により初めから呼び出し元のスタックフレーム上に生成される
576:デフォルトの名無しさん
25/07/29 20:29:47.96 EalfDF/V.net
あのさ、
スタック上に確保すると
「解析がなくても」「解放は容易」でしょ？
それが
「解析はあるのだから」「どこでも同じ」にならない？
577:デフォルトの名無しさん
25/07/29 20:36:31.61 1nklfDHD.net
何を問題にしてる？
スタック上のため確保もアクセスも高速
その上でRustではアクセスと解放の安全も両立している
578:デフォルトの名無しさん
25/07/29 20:47:35.07 EalfDF/V.net
「スタック上に確保しなくても同じことはできる」
って言ってる
そのうえで
「スタック上にしか確保してないのか」
って言ってる
579:デフォルトの名無しさん
25/07/29 20:52:53.58 1nklfDHD.net
>>568
スタック上に確保するときのみ確保が高速
スタック上で確保した時はキャッシュにほぼ載るためアクセスも高速
ヒープ上ではどちらも遅くて不利
580:デフォルトの名無しさん
25/07/29 21:02:55.02 yJ/ZZe3K.net
ついに糖質と言い争えるレベルまで落ちたか
581:デフォルトの名無しさん
25/07/29 22:39:15.04 pHNfVPjg.net
>>557
操作ごとに計算量違うだろ？
CSの教養のないど素人じゃん
582:デフォルトの名無しさん
25/07/29 22:48:01.97 ysadVfOf.net
>>571
どの操作も計算量の算出時にメモリアクセスによる時間コストを考慮していなかったことが昔の敗因
583:デフォルトの名無しさん
25/07/29 23:17:45.02 VkX72Ez2.net
「計算量」を理解してないだけだな
584:デフォルトの名無しさん
25/07/29 23:23:46.49 A5j4bQYz.net
多少遅くてもいいからCPUと関係ない言語で書きたい
mallocが使えない状況でその言語を使えるならそのほうがCPUと無関係でいられる
585:デフォルトの名無しさん
25/07/29 23:25:20.99 gZolU48c.net
計算量は係数を考慮せず次数だけだからね
キャッシュヒットとミスのような係数が桁違いに変わってくる現実だと逆転が起きるのは当たり前
586:デフォルトの名無しさん
25/07/29 23:29:05.70 gZolU48c.net
机上の計算量だけ見ていてもダメで必要な箇所は比較計測になる
そこでのRustは選択肢を広げてくれた存在
587:デフォルトの名無しさん
25/07/29 23:41:21.56 4+dSqHol.net
大きな2次元配列で2次元のどちらを基準に全走査するかで桁違いに速度が変わるのもCPUメモリキャッシュのせいだよな
そのへん考慮できない人はプログラマに向いていない
588:デフォルトの名無しさん
25/07/30 00:05:02.69 2CCQm4VI.net
マイクロマネジメントをな、マイクロマネジメントをいつでもサボれるくらいになりなよ
589:デフォルトの名無しさん
25/07/30 00:46:05.33 zYz0+G1r.net
>>575
それは小さいデータのときだけ
計測してみろよ
特殊な前提なのに話を一般化すんなよ
590:デフォルトの名無しさん
25/07/30 00:51:05.39 6h+f7gEs.net
ほらやっぱり
複オジは「計算量」を理解していないだろ？
591:デフォルトの名無しさん
25/07/30 01:15:10.54 ZVYNNQCS.net
ベクタは確保メモリサイズを超えると別メモリへの移動ペナルティが発生するにも関わらず、
ベクタへのデータの追加操作はベクタのサイズに関わらずO(1)とされる。
これはデータを2^n個追加した時の累計メモリ移動は最悪時でも、
1+2+4+8+...+2^(n-1)＝2^n-1個のメモリ移動しか発生しないためである
592:デフォルトの名無しさん
25/07/30 06:58:14.11 dn+Bg3eY.net
・超指向性スピーカーを使用して統合失調症の周囲で殺人をしたと話していたのですがご存じの方知りませんか？
【兵庫県知事問題】「斎藤知事動画はバズる」と直感、編集して1500万再生 中傷動画も発信した男性（31）の後悔 [ぐれ★]
2025/07/29(火) 21:04:36.36
ｽﾚﾘﾝｸ(newsplus板)
こちらの方は後悔しているけれど
統合失調症周囲の人間は逆の精神状態の下記の人物
「仕事はデキるのに…」異常で執拗なパワハラをする“ダーク・トライアド“と呼ばれる、職場のヤバい人たち [パンナ・コッタ★]
2025/07/30(水) 02:17:10.53
ｽﾚﾘﾝｸ(newsplus板)
593:デフォルトの名無しさん
25/07/30 10:38:53.50 kDw0lUC7.net
Rustが糞遅いのはこういうのも関係してるんだろうな
594:デフォルトの名無しさん
25/07/30 10:55:36.76 HGz1hbaM.net
>>580
complexityを計算量と訳したバカのせいで新しいバカが量産されてる
595:デフォルトの名無しさん
25/07/30 15:55:46.79 gxsH3v1Z.net
>>579
データが大きくても係数の差が次数の差より影響することは普通にありえる
キャッシュミスしまくるがO(n)で済むアルゴリズムと
ほぼキャッシュヒットしまくるがO(n·log(n))かかるアルゴリズムがあるとしよう
両者のアルゴリズム自体の係数差は単純にnとn·log2(n)とする
例えばn＝2^30≒10億の場合はアルゴリズムの差でlog2(2^30)＝30倍の差が生じる
ところがキャッシュミスするとメモリアクセスの差で300倍遅いことが現代のCPUでありえる
そのためキャッシュミスしまくるO(n)よりもO(n·log(n))が速く実行されることが起きる
596:デフォルトの名無しさん
25/07/30 16:10:
597:27.29 ID:aMDk5tN6.net
598:デフォルトの名無しさん
25/07/30 16:28:45.91 zYz0+G1r.net
>>585
はいはい
計測してからほざけ
599:デフォルトの名無しさん
25/07/30 17:11:45.14 cfT0F8KB.net
実効速度の比較の場合
計算量はNが無限近くに大きい時のみ有効なんだよ
Nが無限近いと係数がいくら大きくても無視できる
ところが現実にはコンピューターで扱えるNは小さな有限値だから係数を考慮しないと実効速度は逆転しちゃう
600:デフォルトの名無しさん
25/07/30 18:05:23.41 Kp0t8wWh.net
O(1)とO(n)の話だったのにO(n)とO(n log(n))にすり替えて自己正当化しようとするところがいかにも複おじ仕草
601:デフォルトの名無しさん
25/07/30 19:07:56.72 hgMZBDIB.net
>>581
そのメモリ移動もまとめてキャッシュに乗るから速いね
602:デフォルトの名無しさん
25/07/30 19:41:04.04 ZSzdQGzh.net
DDRn-SDRAMからキャッシュへのfetch時間は、12(ns)位だから、メモリコントローラが賢ければ、
3GHzのCPUの場合、36クロック位で済むので、めちゃくちゃ遅いわけではない。
603:デフォルトの名無しさん
25/07/30 19:44:24.21 jptgQq59.net
で、結局Rustでは実際どういうときにリンクトリスト使うの？
604:デフォルトの名無しさん
25/07/30 20:03:01.97 ZSzdQGzh.net
Grokによれば、以下のように、DDR5 SDRAMからキャッシュに乗せるまでの時間は、8～20(ns)程度らしい。
これは、3GHz の CPU だと 24～60 (クロック) 程度に相当する時間。ものすごく遅いわけではない。
「
実測値として、Intelのx86 CPU（例：12th/13th/14th Gen Core）＋DDR5構成でのプリフェッチ完了時間は、以下のように報告されています（）：標準的なDDR5-4800構成：約15～25 ns（L1/L2へのプリフェッチ）。
高性能DDR5-7200構成：約10～20 ns。
最適化された環境（低CL、オーバークロック）：8～15 ns。
」
605:デフォルトの名無しさん
25/07/30 20:11:57.87 ZSzdQGzh.net
大体で言えば、32バイト位の領域がキャッシュに乗っていない場合に、24～75 (クロック) 程度の追加時間が必要になる。
しかし、そこから連続するメモリーにアクセスしている場合には、追加時間は 0 クロック。
通常、1つの構造体やクラスに対してまとまって処理するが、処理に本質的に必要な時間が 100 クロックだとすると、
そこに、24～70 クロック程度が上乗せされることになる。だから、トータルだと、24%～75% 程度、処理時間が
長くかかる、ということになる。
もしも、本質的な処理に必要な時間が 10 クロックのように非常に粒度が小さい処理の場合だと、
キャッシュに乗っていれば、10 クロックだけで済むところが、34～85 クロックかかることになる。
その場合は、3.4倍から8.5倍の時間がかかる、ということになる。
だから、リンクリストの場合、1つのノードのバイト数が少なかったり、ループの中で1ノードあたりに処理
する内容が少ないならば、キャッシュに乗っている事が重要になる事が有る。
しかし、1つのノードのバイト数が大きかったり、ループの中で処理する1ノードあたりの処理が
大きい場合は、キャッシュミスの影響をあまり気にしなくてよい。
606:デフォルトの名無しさん
25/07/30 20:19:57.86 ZSzdQGzh.net
具体例で言うと、大量の3Dの座標データなどに対して、CPUで単純に平行移動を書けるような場合は、SIMD命令を使わない場合、
1点当たりの処理は、ループ自体に必要な時間が5クロック、足し算に必要な時間が3次元の場合、3クロックで、
全体で、1点当たり8クロック、と見積もれる。ループを展開して、例えば、8点ずつ処理したりすれば、一点当たりに
必要なクロック数はもっと下げられる。SIMD命令を使えば、もっと下げられる。
このような場合は、LinkedList(list) よりも、ArrayList(vector)の方が適す。
しかし、1行に80文字くらい入っているようなテキストの1行を処理する場合、1行を処理するには数百クロックが必要になり、
行全体を収める構造としては、LinkedListでも、キャッシュミスによる速度低下の影響は軽微。
607:デフォルトの名無しさん
25/07/30 20:27:23.39 zYz0+G1r.net
すげーわw
初手から間違った方向の議論してるのに早く気付け
608:デフォルトの名無しさん
25/07/30 20:46:03.62 ZSzdQGzh.net
高速なプログラムを作った人が「キャッシュの事も考慮することで高速化しています」と言っていたとしても、
それは、キャッシュ以外の部分が既に早く作りこまれた後だからの話。大部分の遅さの原因はキャッシュの事を気にする
以前の問題で、大半はLinkedListを使うべき場所でArrayListを使っている事だったりする。
なぜなら、キャッシュミスは、24～75クロック程度の時間増加にしかならないからだ。
609:デフォルトの名無しさん
25/07/30 21:02:52.82 S65PQfLi.net
机上の空論プログラマ
いるよね
610:デフォルトの名無しさん
25/07/30 21:07:04.54 W/B9cxh8.net
俺はプログラミングばかりしている人間だし、高速化技術には定評があるから、机上の空論家ではない。
実際に作ったものの速度を見ると、どうやってこんなに高速化したのか分からず目を白黒させた人がいる。
611:デフォルトの名無しさん
25/07/30 21:08:49.52 W/B9cxh8.net
ID:ZSzdQGzh
が俺だ。俺は、高速化技術の第一人者であり、先生と呼ばれる人間だ。
612:デフォルトの名無しさん
25/07/30 21:12:48.14 9ZmySMAs.net
草
リンクリストは要素毎にポインタを持つ必要があるから、仮にstrのリストとすると要素あたりのサイズはダブルリンクリストの場合は倍となり、
キャッシュミスを考慮しないとしても単純にスキャン量が倍になる
613:デフォルトの名無しさん
25/07/30 21:14:52.61 W/B9cxh8.net
はっきり言って、高速化に関しては、教科書を書いている人は間違っている事が多い。
こんなところに買いても嘘だと思われて終わりだろうが、１つの証拠は、俺の作ったアプリは異常に速度が速い。
これは嘘ではない。速度を得たければ、ArrayList(std::vector)だけでは駄目で、LinkedList(std::list)を効果的に使う必要がある。
614:デフォルトの名無しさん
25/07/30 21:15:44.64 W/B9cxh8.net
>>601
それでも速い。
615:デフォルトの名無しさん
25/07/30 21:17:52.50 R2zwxvxE.net
>>602
では試しにサンプルコードを提示してくれないか？
それを動かしてみて実際に速いと体験してみたい
616:デフォルトの名無しさん
25/07/30 21:22:58.73 S65PQfLi.net
GrokにDDRのレイテンシ聞いてる時点でど素人じゃん
値おかしいし
617:デフォルトの名無しさん
25/07/30 21:36:07.17 W/B9cxh8.net
>>605
俺はプログラミングばかりやっていたので、メモリーのクロック数の実際の値には詳しくない。
ハードに詳しいようなタイプのパソコン博士ではない。
618:デフォルトの名無しさん
25/07/30 21:36:37.58 W/B9cxh8.net
>>604
嫌だ。
619:デフォルトの名無しさん
25/07/30 21:37:49.82 W/B9cxh8.net
なぜいやかと言うと、俺の知見や技術を、
当たり前であったかのように論文や本などに記載
する人がいるからだ。
620:デフォルトの名無しさん
25/07/30 22:01:32.02 IkZxqK3l.net
>>600
数学100点先生は高速化技術の第一人者でもいらっしゃられたのですね
>>597
>大部分の遅さの原因はキャッシュの事を気にする以前の問題で、大半はLinkedListを使うべき場所でArrayListを使っている事だったりする。
本当にそんな事例があるのならば
ぜひ具体的なコードを挙げていただけませんか
621:デフォルトの名無しさん
25/07/30 22:01:33.80 GCxxEIm4.net
「いる」ではなく「いた」なら使ってもいい
622:デフォルトの名無しさん
25/07/30 22:20:47.28 zYz0+G1r.net
>>606
それでよく高速化の専門家自称できんのな
お前メモリーアクセスオーダーとかも理解できてないだろ
中の下を自覚したほうがいいぞ
623:デフォルトの名無しさん
25/07/30 22:28:25.25 bASHA+tv.net
100点先生は複雑な並列は専門外だったはず
メモリ同期の抽象化やそれを用いたロックフリーアルゴリズムなど知らないと思う
624:デフォルトの名無しさん
25/07/30 22:52:44.16 +nnd8qy9.net
>>612
> メモリ同期の抽象化
横だけど、抽象化だけじゃなくてテストは必須な
ユーザー環境でメモリオーバークロックやタイミングチューンでTSOが保たれてない場合をいくつも見た
625:から
626:デフォルトの名無しさん
25/07/30 23:25:58.88 g7G1hz5M.net
プログラミングではTotal Store Orderが保たれないハードを相手にする必要はないけど
そのような破綻したハードが存在することを知っておかないと
正しく動かない環境があった時に原因が分からず悩みそうだ
627:デフォルトの名無しさん
25/07/31 00:30:01.24 QRajgvO2.net
知りたいと欲する者が実在すればいいけど
登場人物全員無欲だったりしたら欲しくもない物を押し売りするのは偽善だよ
628:デフォルトの名無しさん
25/07/31 17:04:11.04 HwmVfmnZ.net
おすすめのLinuxネイティブGUIライブラリ
629:デフォルトの名無しさん
25/08/01 06:41:29.25 GwIUJJIi.net
ネイティブとそれ以外は地球と宇宙のように分断されている
地球に隕石を落とせば解決するという風潮がある
630:デフォルトの名無しさん
25/08/01 07:22:58.63 k4bix39w.net
>>616
RustならTUIで作れ
631:デフォルトの名無しさん
25/08/01 07:28:36.21 MHdoviLB.net
いやGUIでいいやん、楽だぞ
632:デフォルトの名無しさん
25/08/01 11:46:13.99 cEhKZFCe.net
TUIってGUIじゃなかったのか
633:デフォルトの名無しさん
25/08/01 16:11:21.56 8q5e+r5H.net
最近のTUIブーム笑うわ
画期的とかいってるやついるし
昔からあるから
634:デフォルトの名無しさん
25/08/01 16:18:35.82 D5M25Ws+.net
TUI が画期的なのではなくて React 風の考え方を導入したフレームワークの存在など、
モダンな UI 記述を TUI の世界に持ち込んできたことが流行の中心にある。
つまり文字中心のターミナルで充分な表現力だったのではないか、
今まで不必要にグラフィカルな表現をしていたのではないかという見直しだ。
635:デフォルトの名無しさん
25/08/01 16:20:56.12 8q5e+r5H.net
はいはい
リアクティブの考え方自体昔からある
Webあがりは歴史を知らない
636:デフォルトの名無しさん
25/08/01 16:42:15.75 JTQ+rqjD.net
RUST自体は何言語で作られてるの
637:デフォルトの名無しさん
25/08/01 16:46:03.35 8ljNi7o8.net
ほんとTUIはいまさら
ncursesで充分
638:デフォルトの名無しさん
25/08/01 16:56:22.01 8ljNi7o8.net
nvimブーム
↓
ターミナル回帰
↓
TUIブーム←イマココ
↓
あれ？nvimよりemacsの方が便利じゃね？
↓
emacsブーム
↓
RMSマンセー
↓
世界中が共産主義化
639:デフォルトの名無しさん
25/08/01 16:57:24.56 GFjMvt/F.net
近年はPCのネイティブアプリの衰退が著しいからね
アプリといえば一般的には①Webアプリか②Webアプリをネイティブアプリのガワで包んだものだけになりつつあり、
それに加えて開発者に限っては③ターミナル上のCUIアプリ(TUIまたはCLI)のオプションがある
で開発者自身が使うためのちょっとしたツールを作るときにはサーバーが必要だし制約の多い①とクソ重い②は除外され、③が選ばれる状況
一昔前はネイティブも有力な選択肢だったけど、もはやコミュニティが衰退しすぎて一部の物好きだけが弄る特殊なオモチャになってる
640:デフォルトの名無しさん
25/08/01 17:04:22.69 9evqpY+Q.net
>>624
Rustコンパイラも当然Rustで記述されているよ
641:デフォルトの名無しさん
25/08/01 17:25:44.86 M2Mi5H7J.net
guiは各osごとに調整が必要じゃけどtuiだったらターミナルあれば動くしな🐼
642:デフォルトの名無しさん
25/08/01 18:16:23.15 YggNYFjx.net
プログラマ（html javascript含む）の9割はemacsを知らない
643:デフォルトの名無しさん
25/08/01 19:31:47.77 D5M25Ws+.net
>>539
Rust コンパイラのフロントエンドは Rust で書かれているが、 LLVM に乗っかっているのでそこまで含めた処理系全体としてなら
C++ の割合がかなり多いと言えるかもしれない。
644:デフォルトの名無しさん
25/08/02 15:43:06.99 w1KV54wn.net
>>549
一般的に抽象化レイヤーはその機能を抽象的なインターフェイスつまりRustではトレイトで表現する
上位レイヤーではそのトレイトのメソッドを利用してコードを書く
下位レイヤーではそのトレイトのメソッドを実装するコードを書く
トレイト以外に接点を持たせないことでコードが分離でき単体テストも可能になる
645:デフォルトの名無しさん
25/08/02 15:43:51.43 R3jtdO6Z.net
>>611
おまえ、プログラミングでは結果出せてないだろ。
この分野は、偉い人に見てめてもらった、とかじゃダメな分野なんだ。
偉い人が間違えているから。
646:デフォルトの名無しさん
25/08/02 16:51:47.55 5fd/P2wb.net
>>632
抽象化レイヤーという言葉を勘違いしてると思われる
何らかの実装を隠蔽したレイヤーくらいの意味しかなくて構造体だけでも抽象化レイヤーになりうる
むしろそっちのほうが多いくらい
トレイトを活用したものでなくても接点が明確ならコードも分離できるし単体テストも可能
依存性反転が必要ならトレイトが必須
>>549は文脈からするとC++のライブラリ実装を隠蔽して抽象度を上げたレイヤーをRustで書く方法という意味で書いてると思われる
647:デフォルトの名無しさん
25/08/02 17:12:01.61 w1KV54wn.net
>>634
構造体は単なる型に過ぎないため抽象レイヤーにならないよ
簡易実装でなければ依存制逆転は必須なのでトレイトも必須
上位層も下位層もトレイトのみに依存して互いは無関係にできることが抽象レイヤー
例えば上位または下位を別のものやモックに置き換えてもコードが動く必要がありそこをトレイトが実現するよ
648:デフォルトの名無しさん
25/08/03 01:26:09.35 gJgkj9HT.net
偉い人は質問される側だから間違えるんだろうね
質問する側は間違った答えを言わないが正しい答えも言わない
649:デフォルトの名無しさん
25/08/03 02:44:09.56 BeS6Ghoa.net
イギリスも安全の観点からC/C++を使用禁止へ
URLﾘﾝｸ(x.com)
650:デフォルトの名無しさん
25/08/03 03:45:18.86 +8VgLRln.net
だからさ、cargoがついててヘッダを書かなくていいC/C++だよ
C-zero（拡張子cz）みたいな名前にして
マングリング、関数のオーバーロード、オペレータオーバーロード、名前空間、省略できないthis、ジェネリック、レキシカルライフタイムと揃えて
「C/C++の資産をこの言語で救済してください」と謳う
651:デフォルトの名無しさん
25/08/03 05:59:00.47 +8VgLRln.net
日本はダイナミックな創造性なんてないんだからそういう正味のRustコンパイラの後追いをやればよい
652:デフォルトの名無しさん
25/08/03 07:08:54.49 XZPl0VTo.net
>>637
この呟き以外のソースが見当たらないので詳細が欲しい
653:デフォルトの名無しさん
25/08/03 08:27:30.00 gJgkj9HT.net
wasmはなんのためにC/C++を解禁したの
いたちごっこ？マッチポンプ？
654:デフォルトの名無しさん
25/08/03 09:11:26.37 3SszdQ1T.net
解禁というのはどういう意味？ C/C++ が WASM 界で禁じられていた時代は存在しないと思うが。
655:デフォルトの名無しさん
25/08/03 10:11:12.12 XUoqk9nk.net
そもそもwasmはC/C++を動かすために作られたものだしなあ
むしろRustが後から入ってきたくせにデカい顔してる
656:デフォルトの名無しさん
25/08/03 10:17:00.39 gJgkj9HT.net
C/C++が禁止されることはなさそうだ
無敵だねこの言語
657:デフォルトの名無しさん
25/08/03 10:54:49.37 3SszdQ1T.net
WASM の設計は「ポータブルな機械語」のようなものを意図していて、
ネイティブコンパイラのターゲットのひとつに付け
658:くわえるのが容易なのは当初からの構想通りだ。 その分野で C/C++ がまず想定されるのは当然の大前提ではあるものの C/C++ の「ために」というわけではないよ。 不必要に C/C++ の動作モデルに依存しすぎないようにするには 実際に他の言語でやってみて検証するのが早道で、そこにちょうどよく Rust があったというだけ。 C/C++ はあまりにも当然の前提で、それで検証するのはごく当たり前のこととしてやってるから目立ってないけど 普通に Rust 以上に WASM 界で使われてる。
659:デフォルトの名無しさん
25/08/03 12:10:02.61 18NTPLCd.net
TUIの流行に関しては、ヴァイブコーディングに適しており、更にはAIによる自動処理も容易という特徴があるのでしばらくは続くだろうね
RustのネイティブGUIアプリなんて学習データが無さすぎて論外
660:デフォルトの名無しさん
25/08/03 12:27:14.74 CQj9WvUG.net
>>635
抽象レイヤーじゃなくて抽象化レイヤー(abstraction layer)
抽象と抽象化をしっかり区別ができてないのが勘違いの原因だと思われる
抽象化というのはプログラミング言語の抽象構造(trait, interface, abstract class等)で表現するという意味ではなくもっと広い意味
抽象構造で表現するのも抽象化ではあるけど一形態に過ぎない
例えばMFCはWin32 APIの抽象化レイヤーだけどWin32 APIを抽象構造経由で呼び出してるわけでもなければMFCが抽象構造で公開インターフェースを構成しているわけでもない
661:デフォルトの名無しさん
25/08/03 15:10:34.91 3fhUnsv4.net
MFCの例が下手くそで何もわからない
662:デフォルトの名無しさん
25/08/03 15:38:17.78 AQKxTVYx.net
>>647
抽象化レイヤーが何かではなくて
抽象化レイヤーをRustで書く方法が質問だから
答えはトレイトで表現するで合ってる
663:デフォルトの名無しさん
25/08/03 16:12:34.10 gJgkj9HT.net
一意だが隠蔽されているのがカプセル化、一意ではないから情報が確定しないのがポリモーフィズム
だがポリモーフィズムを使っていても二通り以上実装する義務はないから
カプセル化はポリモーフィズムの特殊なケースにすぎないかもしれない
664:デフォルトの名無しさん
25/08/03 16:17:00.42 2/r4ysBb.net
抽象化レイヤーを用いたソフトウェアモデルで有名なものとしては、UNIX生まれで最近のOSも採用しているバイトストリーム入出力モデルがある。
これはファイルI/O、ソケットI/O、端末I/Oなど様々な特性のデバイスの入出力を統一した抽象的なインターフェイスで扱っている。
新たな機能のデバイスもしくは仮想デバイスが登場しても、同じインターフェイスを実装して提供することで、利用側はその統一したインターフェイスで同じようにプログラミングができる。
Rustで言えばトレイトを定めればいいね
665:デフォルトの名無しさん
25/08/03 16:20:40.80 3fhUnsv4.net
逆でしょ
カプセル化の特殊な例がポリモーフィズム
抽象化の議論しててどっちが抽象的かわかってないのは草
666:デフォルトの名無しさん
25/08/03 16:41:33.62 AyIN7EAz.net
>>649
抽象化レイヤーが何かを理解してないのに合ってるわけないじゃん
667:デフォルトの名無しさん
25/08/03 16:45:06.46 AyIN7EAz.net
>>652
カプセル化とポリモーフィズムは直交した概念
どちらか片方がもう一方の特化した概念というものではない
668:デフォルトの名無しさん
25/08/03 16:56:55.36 KMHU42D7.net
複おじに念仏
669:デフォルトの名無しさん
25/08/03 17:09:45.63 2/r4ysBb.net
>>650
>>652
二人とも違う
カプセル化とポリフォーリズムは互いに関係ない
カプセル化はある一つの型に対して、内部構造を隠蔽して、公開したメソッドを通してのみアクセスさせること
ポリフォーリズムは複数の異なる型に対して、何らかの共通な処理を可能にするものだが、様々な種類に分かれる
例えば型パラメータを用いたパラメトリックポリフォーリズムや、
型クラスやオーバーロードなど直接関係のない型同士を扱うアドホックポリフォーリズムや、
上下関係のある型同士を扱うサブタイピングポリフォーリズムなど多岐にわたる
670:デフォルトの名無しさん
25/08/03 17:29:25.06 yJFvd+Qj.net
超巨大ブラックホールから吹き出る「風」の論文で従来理論の書き換え迫る発見…妻「それってすごいの？」
8/3(日) 14:20
URLﾘﾝｸ(news.yahoo.co.jp)
3つの宇宙望遠鏡などで観測した“くじら座”の渦巻銀河「M77」
8/2(土) 23:31
URLﾘﾝｸ(news.yahoo.co.jp)
認知能力が高い人はモラルが低いという調査結果
2025年08月03日 08時00分
URLﾘﾝｸ(gigazine.net)
↓ワープ観測されている↓
量子トンネル効果の「トンネル内部」を世界初観測
2025.07.28 MON
URLﾘﾝｸ(nazology.kusuguru.co.jp)
>>>量子力学の誕生以来、およそ100年もの間この疑問は解き明かされていませんでした。
>>しかし2025年、国際研究チームがついに電子がトンネル内部で何をしているのかを観測することに成功しました。
>>その結果、電子は単純に直線的にトンネルを抜けるのではなく、トンネル障壁の内部で一度壁面に反射（Uターン）し、その際にエネルギーを得てから最終的に外側へ放出されるという意外な動きをしていることが判明しました。
史上初！量子トンネル効果によって分子結合が生成される様子を確認！
2023.03.04 SAT
URLﾘﾝｸ(nazology.kusuguru.co.jp)
>>研究ではトンネル効果が起こる頻度も観測されており、重水素陰イオンと水素分子の間で起きた1000億回の衝突あたり1回のトンネル現象が起こって、新たな分子（水素と重水素が結合したもの）が生成されていることが示されました。
>>研究者たちはトンネル効果の正確な頻度や発生要因を解明することができれば、核反応をはじめとしたさまざまな化学反応の予測を、より正確に行えるようになると述べています。
671:デフォルトの名無しさん
25/08/03 17:38:49.22 zNYhSnUV.net
WideStudioのソース読んでみれば
672:デフォルトの名無しさん
25/08/03 18:04:16.57 4Xke6nGP.net
内部構造を隠蔽したいってゴールはカプセル化も継承も多態も同じだし
全部一緒でよくね？
673:デフォルトの名無しさん
25/08/03 18:24:21.41 sMWLFDIb.net
複おじが多態してるw
674:デフォルトの名無しさん
25/08/03 18:49:35.14 vzak/r7e.net
>>656
関係ないは言い過ぎ
オブジェクト指向の用語なんだからカプセル化は前提になる
675:デフォルトの名無しさん
25/08/03 20:05:52.78 H9MXEq6C.net
カプセル化が無ければOOPではないのかと言えばそうでもない
676:デフォルトの名無しさん
25/08/03 20:33:41.18 2/r4ysBb.net
>>659 >>661
ポリフォーリズムはオブジェクト指向の用語ではない
目的も隠蔽ではなく各々で異なる
例えばアドホックポリフォーリズムの一種であるオーバーロードは人間にとって似た扱いを目的として同じ演算子や同名の関数を用いる
例えばパラメトリックポリフォーリズムの一種である型パラメータによるジェネリクスはコードの共通化を目的として一つの関数にまとめる
いずれもオブジェクト指向とは無関係に存在し関係なく使われてきている
677:デフォルトの名無しさん
25/08/03 20:36:22.43 O7EhC/Oh.net
ああ、また用語と自転車置き場をめぐる議論が始まっちゃったか
678:デフォルトの名無しさん
25/08/03 20:42:12.60 2/r4ysBb.net
>>664 世界的に共通の用語であり各国版のwikipediaなどにも明記されていて論争にならない常識 https://en.m.wikipedia.org/wiki/Polymorphism_(computer_science)
680:デフォルトの名無しさん
25/08/03 20:43:04.18 583CMhqs.net
ポリモーフィズムでは？
681:デフォルトの名無しさん
25/08/03 20:45:03.97 6L5nHrbA.net
こういう議論はいつも同じ
オブジェクト指向しか知らない人
特にクラスしか知らない人が狭い視野で間違った偏った認識をしてるよ
682:デフォルトの名無しさん
25/08/03 20:49:04.61 H9MXEq6C.net
じゃあ荒れるネタとして
C#のプロパティはget setそれぞれににpublic/private選べるのでrustより優れている
683:デフォルトの名無しさん
25/08/03 21:38:30.46 6L5nHrbA.net
>>668
そのような「値を得る」「値を代入する」という応用が利かない不自由な扱いよりも
Rustではもっと利便性のよい「不変参照を得る」「可変参照を得る」という形にすることが多い
例えば
struct Foo<T> {
hoge: T,
他略
}
impl<T> Foo<T> {
fn hoge(&self) -> &T {
&self.hoge
}
fn hoge_mut(&mut self) -> &mut T {
&mut self.hoge
}
}
684:デフォルトの名無しさん
25/08/03 22:17:28.59 4Xke6nGP.net
setterとgetterが自動生成しないとやってられない時点で
そもそも設計が変だと思うんだよね
685:デフォルトの名無しさん
25/08/03 23:49:55.94 StwmvA+l.net
>>668
setを公開したくなくてgetだけを公開したいならフィールド同名関数()をpublicで用意すればよい
686:デフォルトの名無しさん
25/08/03 23:54:27.43 lAxDq0l0.net
>>669
まーた無茶苦茶なこと書いてんなぁｗ
さすが
687:デフォルトの名無しさん
25/08/04 00:14:09.80 iiFhiJZn.net
>>672
特に大きな型やヒープを含む型だとRustでは常套手段だろ
文字列ならさらに不変時はderef適用で
name: String, フィールドに対して
fn name(&self) -> &str {
&self.name
}
fn name_mut(&mut self) -> &mut String {
&mut self.name
}
688:デフォルトの名無しさん
25/08/04 00:58:36.75 78Y6WAbh.net
メンバ関数はいっぱいあるから
通常の構文ではgetに対応するsetがどれなのかコンパイラに伝わらない
伝わらないとlensを合成できない
689:デフォルトの名無しさん
25/08/04 01:12:10.10 tLSupvQe.net
置き換えてしまうsetは機能が弱く古い昔のインターフェース
現実のプログラミングでは
ベクタの一部を書き換えたいとか
文字列に文字を追加したいとか
これらは&mutを得ることで実現できる
690:デフォルトの名無しさん
25/08/04 12:25:58.42 dqUtfv2j.net
抽象化を1ミリも理解してないのな
どうりで汚コードしか書けないわけだ
691:デフォルトの名無しさん
25/08/04 14:12:03.89 kna5DiYV.net
ゲッターセッターが大切なC#くんだから
692:デフォルトの名無しさん
25/08/04 15:00:40.82 PuI+PXi5.net
>>675
mut渡しをインターフェイスと考えるのはちょっと……
mut渡しはインターフェイス記法の統一・アクセス制御の観点からは劣ってない？
mut渡しは隠蔽化できないc構造体の再来に見える。構造体の一貫性を維持するのも大変そう。インターフェイスは素直にメソッドで統一した方が良いかと思う。
693:デフォルトの名無しさん
25/08/04 15:37:12.00 aclG9N8Y.net
代入setとの比較だろ
Rustでは他言語で代入setが必要な局面ならばsetではなく&mutを返すAPIで統一している
!Freeze型を除く
694:デフォルトの名無しさん
25/08/04 16:44:19.41 0NMYYV4x.net
いやmut返すのはダメでしょw
外で行われた変更を認識できないからカプセル化にならない
695:デフォルトの名無しさん
25/08/04 16:59:50.60 BZ8hfzfK.net
setの代わりに& mut返しならば
同レベルのカプセル化を維持だからそこは問題ない
696:デフォルトの名無しさん
25/08/04 17:07:00.83 hBZA20vJ.net
C#のようなプロパティはRADの文脈で必要だから存在するもの
画面上でUI要素の属性を弄ったりする場合に、getter/setterを纏めたものがないと不便だからな
RustにRADツールなんか無いし、C#でも今時のWeb開発だったりするとRAD使わないからsetterはあまり使用されなかったりする
あらゆるタイミングで値を変更される可能性を考慮しなければならなくなるから、単一属性値にいちいちsetter付けるのは上記のようにRAD対応が必要な場合でない限りは基本的に好ましくない
そして、複おじの言うmut返す方法は変更を知ることすらできないという点で論外中の論外
697:デフォルトの名無しさん
25/08/04 17:13:11.22 Mt78uU/e.net
このスレでたまに出てくるけど、副おじって何？
たぶん何らかの罵倒ワードなんだろうけど...
698:デフォルトの名無しさん
25/08/04 17:19:45.60 celjGwNv.net
Rustの標準ライブラリはsetメソッドを提供せず&mutを使うことで一貫している
唯一の例外が内部可変性型
699:デフォルトの名無しさん
25/08/04 17:35:09.09 I7/wkqcL.net
>>683
しばらく注意して読んでりゃわかるよ
>>681,>>684のように、下記の特徴を持つ人物(またはAIかもしれない)
- 複数のIDを使用している
- Rustへの不満や批判に対して必ず無条件にRustを肯定するような反論をする
- 明らかに知能が低く、実践的な知識も極めて乏しい
700:デフォルトの名無しさん
25/08/04 17:47:40.15 yFvjHdoi.net
わかりやすい3行まとめ
C#「C#はset/getが便利でRustより優れてるよ」
Rust「Rustでsetが必要な時にはsetよりも可変参照を使うことが多いよ」
701:デフォルトの名無しさん
25/08/04 18:11:27.17 I7/wkqcL.net
>>686
何度も言われてるけど可変参照を返すのはカプセル化の観点ではsetterの代替にならないよ
なぜsetterを使用するのか、可変参照を返す方法で同じ目的を達成できるのかを自分なりに考えてみるといいよ
702:デフォルトの名無しさん
25/08/04 18:11:56.77 Nv52M5VU.net
>>683
別に罵倒ワードではない
単なるあだ名
703:デフォルトの名無しさん
25/08/04 18:20:44.57 hBZA20vJ.net
カプセル化を維持しつつ絶対コピーしたくないならこういう手はあるね
impl<T> Foo<T> {
fn with_hoge_mut<R, F>(&mut self, f: F) -> R
where
F: FnOnce(&mut T) -> R,
{
f(&mut self.hoge)
}
}
704:デフォルトの名無しさん
25/08/04 18:33:05.80 N28h4gI0.net
念のためRustプログラマーの常識
Rustにおいてgetと対になるのはsetではなくget_mut
代入ではなく可変参照返し
705:デフォルトの名無しさん
25/08/04 18:34:06.15 78Y6WAbh.net
&mutとは
copy on writeと同じことを
参照されなくなったゴミを利用して多少効率化するだけの仕組み
ゴミが発生しない場合はさっさと諦めてコピーする
706:デフォルトの名無しさん
25/08/04 19:41:56.06 gaMK2CYY.net
OOPなRADあるあるの、プロパティの変更に対してその変更を受けた各種イベントを発行する仕組みは、可変参照返しだとどうなるだろう？
setterならメソッドの中でそれに対するイベントを飛ばすだけだが
707:デフォルトの名無しさん
25/08/04 20:01:13.95 Mt78uU/e.net
>>688
いわゆる蔑称的な？
708:デフォルトの名無しさん
25/08/04 20:12:02.41 4Acx8b1+.net
複製おじさんの名前の起源については>>128を参照していただければ
709:デフォルトの名無しさん
25/08/04 20:38:42.22 78Y6WAbh.net
>>692
監視されているプロパティからは可変参照を取得できない
できるのは監視されていないゴミ
710:デフォルトの名無しさん
25/08/04 21:12:30.48 78Y6WAbh.net
いや取得でき�
711:驍ｯど悪手 か？
712:デフォルトの名無しさん
25/08/04 21:16:11.92 PuI+PXi5.net
>>695
それじゃ、監視しないゴミを監視するように変更しようとすると、インターフェイス総入れ替えという大規模な設計変更が入るわけですな。
mut&を返すのは性能を優先した結果だから、この設計は「早すぎる最適化」の例なんだろうね。
実際には>671みたいなフィールド同名メソッドのoverloadでやるのが妥当なんだろうけど、Rustじゃできないか。
713:デフォルトの名無しさん
25/08/04 21:46:26.36 78Y6WAbh.net
Rcでラップしたら可変参照はほぼ使えないし
714:デフォルトの名無しさん
25/08/04 22:29:55.20 z+to2bOr.net
MVVMで設計しC#でプロパティを変更したらGUI（WPF）に変更通知が飛んでいき
自動で表示が変わる
GUIの再描画の指示などしなくて良い
715:デフォルトの名無しさん
25/08/04 22:35:06.27 iV2kOv6U.net
フレームワーク側が再描画の指示を出してるだけやで
716:デフォルトの名無しさん
25/08/04 22:39:46.06 4Acx8b1+.net
MVVMはViewとModelに分散保存された状態の同期を取らないといけないという発想が終わってる上に
サードパーティのサポートライブラリに頼らないと無限にボイラープレート書かされるので
もう触りたくないです
717:デフォルトの名無しさん
25/08/04 23:09:48.35 Rr7r86Jy.net
「Rustではsetterの代わりに&mut返しをする」
・・・・・んなわけないだろｗ
こんなしょうもない嘘に騙されても許されるのは
プログラマー歴3ヶ月未満の超初心者だけだぞ
718:デフォルトの名無しさん
25/08/05 00:18:39.60 HvT+RSaf.net
実質DTOでしかないただの構造体なのに、思考停止でフィールドprivateにしてそれに代入して戻すだけのsetter、getter書いてるようなのを想定してるんだろう
それなら可変参照でもいいと思う
719:デフォルトの名無しさん
25/08/05 00:28:51.87 wVaMTXK9.net
逆に、フィールドを直接公開するのに対して可変参照返す利点って何があるんだろ
将来的な構造体のレイアウト変更に強くなるのはメリットだろうけど、それくらいか？
可変参照をお漏らした時点でどうせフィールドの存在は外に漏れるし、いつどんな変更されるかも全く把握できなくなるわけで、カプセル化による利点はほとんど損なわれるよね
720:デフォルトの名無しさん
25/08/05 01:10:13.51 GB4L56b8.net
Rustを使ったことがない他言語のお客さんが暴れてるのかな
標準ライブラリのAPIだけでも眺めてみるとわかるよ
Rustではget/setのペアではなくて全てget/get_mutのペアでAPIが提供されている
可変参照があればsetを実現できるけど逆はできないからね
>>692
可変参照の借用が終わった時にそれを知って後処理をしたいでいいのかな
それはRustだと一時ガード利用パターンを使うことになるね
例えば標準ライブラリのMutexで使われているパターンで
可変参照を使っている間はMutexGuardが存在して借用終了後にそれがdropして後処理ができる仕組み
721:デフォルトの名無しさん
25/08/05 01:10:31.87 dB/o6zkb.net
大きな利点があればクビにできるのがカプセル化だが
多相を単相に変える魔法は存在しないのでお金で買えない
722:デフォルトの名無しさん
25/08/05 01:44:26.88 MecFBgDL.net
1フィールドだけで内部可変性も無い単純なラッパー型みたいなのならget/get_mutでもいいんだけどそれ以外は実際使ってみると……ね
723:デフォルトの名無しさん
25/08/05 02:06:35.89 dB/o6zkb.net
問題はメンバーの可変参照だからメンバーをMutex<T>とする
getで&Mutex<T>を得たらこれだけで読み書きどちらも可能
get_mutは不要
724:デフォルトの名無しさん
25/08/05 02:16:09.51 2lMtF2HX.net
マルチスレッド間で共有していて排他制御必須の時ならばMutexを使う付加コストを負担する価値があるためそれで正しい
しかし共有していないならばMutexを使う付加コスト負担の不利益のみを被るためその使い方は間違っている
725:デフォルトの名無しさん
25/08/05 05:59:15.19 tAZ6f0aN.net
ほとんどのケースではただpubにすればいい
726:デフォルトの名無しさん
25/08/05 07:39:57.92 dB/o6zkb.net
クビにする利点があればMutexはクビにできる
727:デフォルトの名無しさん
25/08/05 09:48:54.10 VLyvcmmQ.net
>>703
ダメだろ
何のメリットもない
>>704
>将来的な構造体のレイアウト変更に強くなる
ならないよ
逆になぜレイアウト変更に強くなると思ったの？
>>705
get/get_mutはプロパティやgetter/setterとは目的も使われ方も全く別のもの
もしかしてget/setのプロパティが何か知らないの？
Rustの標準ライブラリでもgetter/setterは普通に使われてるのになんで無理やりget/get_mutと比べようとするのか意味がわからない
728:デフォルトの名無しさん
25/08/05 10:08:15.74 QMq79wYr.net
なんらかデータ構造のライブラリを自分で書いてみればわかる
標準ライブラリのVecDequeやHashMapなどのように必ずgetとget_mutを用意することになる
setは不要
729:デフォルトの名無しさん
25/08/05 10:43:06.63 VLyvcmmQ.net
>>713
それらのget/get_mutはget/setプロパティやgetter/setterとは全く関係ない別のもの
名前が似てるから代用品だと勘違いしちゃったのかな？
730:デフォルトの名無しさん
25/08/05 10:43:34.52 Ur0oPbHa.net
>>712
フィールドの名前変更とか、構造体をネストするような簡単なリファクタリングには対応できるんじゃない？
まあそういう避けようと思えば避けられる変更じゃなくRcとかMutexを導入するような変更だと結局利用側が壊れるから、カプセル化の効果としては極めて限定的だろうけども
731:デフォルトの名無しさん
25/08/05 10:45:45.25 MecFBgDL.net
(&mut self) -> Option<&mut>系のAPIは総じてNoneの分岐の中でselfに触れないのがダルすぎるから全部Result<&mut, &mut Self>返すようにしてほしい
732:デフォルトの名無しさん
25/08/05 10:53:41.50 sbZa0E73.net
プログラミングしたことある人ならばsetメソッドの愚かさが理解できると思うんだけどな
そのフィールドがStringやVecだったとしてgetしてから更新して再びsetするのか？という
setは机上の空論だよ
733:デフォルトの名無しさん
25/08/05 11:10:34.57 gjfdWuqO.net
>>717
RADをはじめとして、ある物事に付随する性質を読み書き可能な属性としてモデリングしたいケースはある
Rustにそんなケースがあるかは激しく疑問だし大した理由なくsetter付けまくるようなC#初心者にありがちな行為が愚かであるのは確かだが、
複おじを除けばそんなことはみんなよくわかっていると思う
その上でsetterの代替として可変参照を返すというアホな主張が叩かれてるだけだね
734:デフォルトの名無しさん
25/08/05 11:20:53.07 LQwdEQMr.net
>>717
pubにするかpub禁止ならgetとget_mut提供になるよな
無意味なsetterが出てくる余地はない
735:デフォルトの名無しさん
25/08/05 11:27:43.97 MecFBgDL.net
そろそろget_mutの意味が「&mut selfを取ってフィールドの&mutを返すメソッド」から「&mut selfを取ってそれが所有する値を条件次第でSomeに包んでOption<&mut>を返すメソッド」に勝手に拡張されていることに明示的にツッコんでいい？
736:デフォルトの名無しさん
25/08/05 11:31:39.25 XcCiNWZv.net
>>720
そんな誤解と書き込みはおまえ>>716だけだ
Optionの話は誰もしていない
737:デフォルトの名無しさん
25/08/05 11:37:08.32 MecFBgDL.net
>>721
それは>>713がVecDequeとHashMapのget_mutを持ち出したのを受けての書き込みなんですが……
738:デフォルトの名無しさん
25/08/05 11:46:52.73 p3Nkewhm.net
>>716
使わなければ最適化で消えるから&mutを常に返すのはアリかもしれない
使われなくても&mutを返すメソッドが標準ライブラリには既にいくつか存在しているため
739:デフォルトの名無しさん
25/08/05 11:48:43.49 HvT+RSaf.net
「従来の言語がsetterで実現していた仕組みは、Rustでは単に可変参照を返すことで全て置き換え可能である。○か×か？」
って話で、標準ライブラリがどうとか論点でもなくクソどうでもいいんだけど、こんだけ長々続くの不思議だな。
740:デフォルトの名無しさん
25/08/05 11:59:43.70 n3OncY4F.net
言語機能で構造体のsetのアクセス制限が出来ていない
これメインの話
741:デフォルトの名無しさん
25/08/05 12:02:02.81 /47rfjNI.net
>>725
Rustではpubを付けない
そしてフィールド同名のgetterメソッドを作る
以上
742:デフォルトの名無しさん
25/08/05 12:30:11.17 /oImIgHI.net
誰か>697の解決策を教えてくれんかね。
やっぱりRustは設計変更が困難な、設計が枯れないと使いづらい清書用言語なんかね。
743:デフォルトの名無しさん
25/08/05 12:37:45.58 mEbJU0dT.net
>>727
何をしたいのか明確な質問なら必ず誰かが答えるでしょう
それはゴミがどうこう意味が不明だからアンタッチャブルでスルーされてるかと
744:デフォルトの名無しさん
25/08/05 12:46:33.38 xVLH/Od3.net
>>727
ゴミ集め言語は方針の前提から違うためおいとくとして
C++では可能だけどRustだと不可能なことが具体的に何かあるか？
745:デフォルトの名無しさん
25/08/05 13:51:31.34 83FET5uP.net
C++ ユーザから見ると Rust は借用ルールが厳しいというのはあるなぁ。
機械的に検証可能な範囲におさめるためのルールであってダングリングを無くすために必要なルールではないので、人が厳しいルールに合わせないといけないのはコンパイラ技術の敗北の表れじゃないかという気持ちがある。
とはいえ、敗北だろうと現時点の技術ではそこまで制約しないと検証できないという現実があるのだし、機械的検証なしで全て人が正しく書けるような規模でなくなっているという「仕方なさ」によって Rust を受け入れているので Rust を良い言語だと思いつつも不満はあるって感じだ。
746:デフォルトの名無しさん
25/08/05 14:00:48.99 MecFBgDL.net
URLﾘﾝｸ(github.com)
> text_view.buffer().set_text(&contents);
まあ、そうだよねえ
747:デフォルトの名無しさん
25/08/05 14:21:08.44 xNQefk+w.net
setter神話の世界ではプロパティがリストでその値の一部を更新する時やプロパティが文字列でそこに文字列を追加する時でもgetterしてsetterするのですか？
748:デフォルトの名無しさん
25/08/05 14:43:46.49 ycU+Lwgg.net
抽象度によって両方使うだろ
保持する値の整合性を関知しないOptionとかコレクションは内部の値の可変参照を使えるし
std::net::SocketAddr::set_ipみたいに内部で値を変換して保持する場合はsetterが使われる
749:デフォルトの名無しさん
25/08/05 15:10:34.96 IvxbfSC8.net
>>733
後者は場合分けデータ加工を伴うためsetterではない
setterとはpublicで直接代入と同一になることを指す
750:デフォルトの名無しさん
25/08/05 15:13:06.56 MecFBgDL.net
>>727
とりあえずgtk4-rsに限って言えば
言語仕様上はプロパティもsetterも無い（当たり前）
setterのオーバーライドの代わりとして、プロパティの変更で発火するイベントハンドラに登録すればよくある感じのRADフレームワークっぽく使えそう
基本的にすべて（ほんまか？）のウィジェットが内部可変なので、原則関数のシグネチャにプロパティの&mutは最初から出現しない → Rust特有の設計変更の困難さは回避されていそう
ツリー内の循環参照の防止は#[weak]で多少書きやすくする仕組みが備わっていそう
お決まりのUIスレッドによる排他制御があるので明示的なロックの取得もしなくてよさそう
真面目に検討するならちゃんと裏取ってほしいけど、gtk4-rsのライブラリ側でよく面倒見てくれてRust特有の困難さは最大限回避されているように見えた
逆に言うとあまり整備されていないライブラリだったら懸念
751:通り設計変更がきついってことはあるかもね
752:デフォルトの名無しさん
25/08/05 15:33:38.78 nxQn5G2j.net
>>424の100コア方向へ今後進む記事もあるように今後のプログラミングはマルチコアを生かすことが最重要になる
内部可変性のコストよりもマルチスレッド活用の利益が遥かに上回る
Rustでの懸念事項が消えるだけでなくその状況でもプログラミングしやすいRustで記述されるのだろう
753:デフォルトの名無しさん
25/08/05 17:58:06.14 dB/o6zkb.net
内部可変のコストは借用開始と終了を通知するコストだ
754:デフォルトの名無しさん
25/08/05 19:32:16.23 OQNXOulz.net
排他制御は全ての言語で必須なコスト
755:デフォルトの名無しさん
25/08/05 19:55:58.63 7OMUt1S/.net
>>732
そんなのインターフェイスの設計次第じゃない？
Vecみたいなコンテナだったら中身をインターフェイスで公開するのは自然だけど、色々と制限のあるデータ(ファイル名とか)を可変参照で渡すのはありえない。
756:デフォルトの名無しさん
25/08/05 20:05:52.81 7OMUt1S/.net
>>735
解説サンキュ。もともと設計を柔軟にしておくか、設計変更しない鋼の意思で開発するのか、どちらか腹決めしとかないと厳しそうだね。
インターフェイスはメソッドに統一して、手抜きor 効率化のために可変参照を使うのはやめたほうがいいとは思うけど。
757:デフォルトの名無しさん
25/08/05 20:08:22.72 tfJiYG9e.net
>>739
一人だけ状況を未だに理解できていないようだな
代入setterを公開するか可変参照を公開するかの話はどちらも制限なく値を自由に設定できる前提だからこそsetterが公開されるんだぞ
758:デフォルトの名無しさん
25/08/05 20:13:13.22 HxeSTMqM.net
>>740
設計を変更しない必要性を教えて
むしろ変更前後での安定性からRustを選ぶと思うのだけど
759:デフォルトの名無しさん
25/08/05 20:19:14.73 64Ar6Smx.net
>>740
可変参照を使わずにどうやってベクタや文字列などいじるつもりだ？
Rustを使ったことないお客様かね
760:デフォルトの名無しさん
25/08/05 20:19:28.30 r9bDhC0/.net
かつてのオブジェクト指向狂信者思い出すわ
761:デフォルトの名無しさん
25/08/05 20:48:12.89 7OMUt1S/.net
>>741
えっ？
いつのまにそんな制限入ったの？
「可変参照で問題無い制限なら可変参照で問題無い」というトートロジーならそりゃそうだろとしか。
でも人生は厳しいから、>692みたいなイベントとか>739みたいな制限みたいな要件が入ってくると、可変参照だと大変だからsetter書き換えみたいな大規模な設計変更が入って苦しむわけですな。
762:デフォルトの名無しさん
25/08/05 20:50:05.35 R9ol/Iro.net
初心者あるあるじゃね
不変参照とライフタイムを持ち回ったり格納したりして効率いいコードを書けない初心者が
そこから逃げて参照をなるべく使わないようクローンしたり巨大コピー実装する非効率なコードを書いてしまう
同様に可変参照を使って効率いいコードを書けない初心者がそこから逃げて非効率なコードを書きたい話
763:デフォルトの名無しさん
25/08/05 20:52:49.94 ZrZHAnmD.net
クローンしまくってるコードをゼロコピーに書き直しても
ほとんどの場合は体感できるほどの速度差は出ない
764:デフォルトの名無しさん
25/08/05 20:53:35.83 9lHh1X9X.net
>>745
setterは値全体の入れ替えしかできないから小さなプリミティブ型以外では効率の悪いコードになるよ
765:デフォルトの名無しさん
25/08/05 20:59:44.09 MecFBgDL.net
>>748
それは大丈夫
>>713によればindex引数を取るVecDequeとHashMapのget/get_mutもgetter扱いってことでいいらしいから
indexを引数に取るメソッドもsetter扱いってことで良さそう
本当にくだらないね
766:デフォルトの名無しさん
25/08/05 21:12:33.92 XKWNaer9.net
Rustを理解して使いこなせているか
それとも実は使いこなせていない初心者のままか
一目で判定するアレはどうよ？
自分でコードを書いてる構造体にライフタイムパラメータが付いているなら参照についてはとりまOK
ライフタイムパラメータ付きの構造体を書いたことないなら初心者のままってやつ
767:デフォルトの名無しさん
25/08/05 21:46:03.10 ycU+Lwgg.net
ライフタイム付けるのは構わんけど構造体に可変参照入れたらしばく
768:デフォルトの名無しさん
25/08/05 21:55:59.11 W+byPGk/.net
内部可変の不変参照ならええやろ
769:デフォルトの名無しさん
25/08/05 22:16:42.13 iwBddmFu.net
ライフタイム付きの構造体は必要悪みたいなところもある気がする
ライフタイム付き構造体Fooがあると、Fooをフィールドに持つ構造体Barや、 Barをフィールドに持つ構造体 Baz にもライフタイムが必要になるという風に影響は波及する
これはRustの仕様では必要だけど、アプリにとって本質であるビジネスロジック以外の部分での面倒くささが増える感じはあるよね
だったら Clone するか Rc/Arc を使えば良くない？いやでもパフォーマンスが僅かでも低下するのは嫌だし…みたいな逡巡が発生する
こういうのは皆気にしないものなの？
770:デフォルトの名無しさん
25/08/05 22:22:52.35 dB/o6zkb.net
Rc/Arcを使うべきでないなどという厳しいルールを提案しているのはコンパイラでも言語でもない
なぜならコンパイルエラーにならないから
一目でわかる
771:デフォルトの名無しさん
25/08/05 22:28:39.53 DYSIYAkV.net
>>753
C/C++から来た人にとってはポインタが構造体に埋め込まれるのは日常なので違和感なくてライフタイムも頭の中で管理していたことが可視化されただけなので面倒くささはないな
一方でdereferenceのない言語から来た人にとっては難しいのかもな
772:デフォルトの名無しさん
25/08/05 23:34:02.50 e/xuwMfI.net
なにごとも慣れ
取り組んでいれば参照も上手く取り扱えるようになるよ
しかし避けていればいつまでたっても取り扱えないまま
773:デフォルトの名無しさん
25/08/05 23:41:54.29 HvT+RSaf.net
今一番意識高い言語だからか、スクリプト以外人生で見たことがないキラキラWeb屋もRustやりたがるけど
そういうのにとってRustの仕様はどれもこれもクソ言語だからとしか感じなくて、ストレスフルにならないんだろうか
774:デフォルトの名無しさん
25/08/05 23:58:16.61 Ph4VwIHu.net
最初のうちだけは非効率でも参照を避けてしまったりメモリも思いっきり無駄に使ったりしてもいいと思うよ
他のことをすべて手なれた後にその状態から卒業すればいいよ
775:デフォルトの名無しさん
25/08/06 02:00:00.42 d0K/UyQ2.net
必死にnomiconとreferenceを読み込んで
絶対の確信をもって実装したunsafeコードが大して速くならないことに失望し
しかも同じことをやっているcrateが既にあることに後から気づけたら
あなたも中級Rustacean
776:デフォルトの名無しさん
25/08/06 23:14:12.53 JB5nNfmj.net
基本はsafeの範囲で非効率な処理をなくして高速化
それより先は全体のネックとなってる部分がunsafe使用で人間が確実に安全保証できて劇的に高速化できる見込みがある時のみ
同じ発想のunsafeコードが既存クレイトに既にあるか調査は必須だけど見落とさずにチェックするのはたいへんね
777:デフォルトの名無しさん
25/08/07 00:08:59.63 4ohCjIfW.net
非効率な実装や高速な実装などがありえるtraitをまず定義する
このtrait自体を変えたくなったら変更前と後のtraitをそれぞれ用いて第三のtraitを実装する
778:デフォルトの名無しさん
25/08/07 03:31:50.47 inxfv21l.net
リファクタリングもトレイトの設置と変更を軸に進めると見通しよく様々な改善が進むよね
779:デフォルトの名無しさん
25/08/07 08:14:39.60 1iU6LrKi.net
C言語やってる人からしたらunsafeは全くunsafeじゃない
Cで抽象化しようと思ったらポインタでメモリ直で読み書きするしかないから恐怖心が無いし。unsafeはプログラマーが注意すれば実際にはバグらず使えるのでもし組み込みとかでメモリサイズの制約あるならどしどし使ったらいい
780:デフォルトの名無しさん
25/08/07 08:18:59.29 X6/hWAC+.net
人間は目に見えているリスクを過大評価するものだ
注意して書かれたunsafeコードにバグがある可能性はそれほど高くない
大抵のバグは何でもない箇所で発生する
登山道での滑落事故が明らかに危険そうな箇所ではなく何でもない場所で発生するようにな
781:デフォルトの名無しさん
25/08/07 08:20:17.84 o54/gbFB.net
C言語やると頭が悪くなるの？
782:デフォルトの名無しさん
25/08/07 08:44:22.13 AfEYgyvj.net
マネジメント側からすれば、unsafeを乱用する無能コーダーを信用できるわけが無い。
やはりunsafeはデフォルト禁止にすべきだね。
783:デフォルトの名無しさん
25/08/07 08:50:39.63 yEGgUaRW.net
safeな標準関数も中身はunsafeだらけ
784:デフォルトの名無しさん
25/08/07 09:40:32.31 cx6d2+5S.net
当然ながら unsafe は最小限であるに越したことは無いし
しかしシステムプログラミングで unsafe をゼロに出来るわけがないのも当たり前で
それらは総合的に判断して良い感じに構成しろという何の面白みもない結論にしかならんだろ。
785:デフォルトの名無しさん
25/08/07 09:56:24.50 4ohCjIfW.net
ルールを作るのが苦手なやつって試合中にルールを変えようとして一発退場する感じなのかな
試合がない時にやりなよ
786:デフォルトの名無しさん
25/08/07 10:19:06.89 6tfwNI5s.net
ここの参照カウンタもMutexもコストを削減できるはず、なぜなら〜〜
ライフタイムの仕組みとsafe Rustの範囲でこれが上手く扱えない理由は〜〜
って確信をもって言えるくらいの理解度があるならunsafeを書いてみる価値はあるよ
恐れず進め
787:デフォルトの名無しさん
25/08/07 11:52:48.37 fYTkkoO5.net
自己参照持てないのにsafeになんてできないよ
788:デフォルトの名無しさん
25/08/07 12:41:59.48 45RJIEmA.net
>>763
unsafeとはRustが安全を保証しないという意味
それをsafeな関数内で用いるには守るべき規則と作法がある
以下を守らずにunsafeを用いた時点でそのプログラマとプログラムの信用が一気に崩れる
・その規則と作法を厳守すること
・safeで同等のものを作れないこと
・開発内部の方針と合意を満たすこと
・外から見てその位置付けと利用のバランスが許容範囲内であること
789:デフォルトの名無しさん
25/08/07 13:12:43.81 k0npk8ql.net
意味のないトートロジーオジ
790:デフォルトの名無しさん
25/08/07 14:50:57.30 4ohCjIfW.net
これはちょっと3年くらい考えれば意味がわかる情報と
何年考えても無意味なものを並べてどっちもどっちしてると思いますよ
791:デフォルトの名無しさん
25/08/07 15:14:55.73 HvQetDok.net
意識高い系言語で意識低い系言語するの楽しいよね
792:デフォルトの名無しさん
25/08/07 15:51:25.04 dOHm8u8G.net
イワシフライ
793:デフォルトの名無しさん
25/08/07 16:44:42.60 IcEwEzHX.net
コンパイラに対する宣言であって、それ以上でもそれ以下でもない
794:デフォルトの名無しさん
25/08/07 18:56:11.96 LDwSF1JY.net
流れぶった切って悪いが
ここのRust使いってどんな仕事してんの？
俺にRustを学ぶモチベーションを与えてくれ
795:デフォルトの名無しさん
25/08/07 19:26:29.97 6tfwNI5s.net
そういうのはキラキラベンチャーの技術ブログでも読んでてくれ
796:デフォルトの名無しさん
25/08/07 19:41:31.57 45RJIEmA.net
>>777
unsafeはむしろ人間に対して宣言している側面が大きくてコンパイラは何もしてくれない
そのコードを利用する�
797:l間たち全員でそのコードの安全性を保証するかもしくは信用の連鎖で利用している そのため>>772に列挙したことを守らない人が出現したらその人の信用が崩壊する
798:デフォルトの名無しさん
25/08/07 20:31:15.86 U7e3gRJl.net
本質的にはここは地雷原ですの看板か子供のころやった「バリア」と変わらない
子供がバリアを主張してても石や犬のウンコを飛ばすとあたる
799:デフォルトの名無しさん
25/08/07 21:52:33.15 4ohCjIfW.net
デジタルのバリア
デジタルの再現性は異常
800:デフォルトの名無しさん
25/08/07 23:17:11.95 SuIQyybu.net
プログラム全体がunsafeでコンパイラが安全を保証してくれないC/C++が消えゆくことは人類にとって良いことだ
801:デフォルトの名無しさん
25/08/07 23:37:34.46 pLALB1Mw.net
「unsafeバリア」
802:デフォルトの名無しさん
25/08/08 06:01:35.36 ZIDobgJf.net
safe c/c++みたいなサブセットできればいいんだけどね。
unsafe Rustに対するsafe Rustみたいなの。
803:デフォルトの名無しさん
25/08/08 06:01:56.72 ZIDobgJf.net
safe c/c++みたいなサブセットできればいいんだけどね。
unsafe Rustに対するsafe Rustみたいなの。
804:デフォルトの名無しさん
25/08/08 07:37:14.37 kQG+ljd8.net
いつまでもつまらない話してないで俺の質問に答えてくれ
ここのRust使いってどんな仕事してんの？
俺にRustを学ぶモチベーションを与えてくれ
805:デフォルトの名無しさん
25/08/08 07:41:46.55 7s/Axs9N.net
その試みはすべて失敗した
C/C++に似てるだけの別言語になってしまう
そして今後はその別言語で書いていくわけだけどRustに対する利点を見いだせなかった
806:デフォルトの名無しさん
25/08/08 08:20:38.39 ZIDobgJf.net
c/c++と一緒にビルドできればメリットでかいと思うけど。
一緒にできなかったら確かにゴミ。
807:デフォルトの名無しさん
25/08/08 08:25:56.37 E+8qMOn9.net
>>788
利点は安心安全
808:デフォルトの名無しさん
25/08/08 08:31:56.00 tqBmz1L/.net
>>787
本職はデータエンジニア、使用言語はだいたいPythonとSQL、たまにGo
Rustは仕事では全く使用する機会がなく、個人的な趣味プロジェクトに使ってるだけ
809:デフォルトの名無しさん
25/08/08 08:34:38.62 kQG+ljd8.net
>>791
Rustの方の使い道を聞いてんだよ発達
810:デフォルトの名無しさん
25/08/08 08:47:09.26 tqBmz1L/.net
>>792
だから個人的な趣味って言ってるでしょ
ちょっとしたCUIツール作るのに使うだけ
最近は専らバイブコーディングで、AIが苦戦してたら手を貸す感じだね
811:デフォルトの名無しさん
25/08/08 09:06:01.11 Z9I4ROf3.net
実際Rustを仕事で使ってるやつはここにもほとんどいないと思うよ
デバッグも難しいし、人もいないし、コア機能が個人開発のクレートに依存しがちで
とにかく仕事で提案するのは全てがしんどい
812:デフォルトの名無しさん
25/08/08 09:07:37.30 kS1PO2PW.net
そんな書き込みするとまた糖質の方が出てきて自作自演で盛り上げるぞ
813:デフォルトの名無しさん
25/08/08 09:20:48.49 OL6PJEc4.net
ゲーム理論にも（同一人物の自作自演でない限り）必ず100パーセント裏切るというバリアがある
814:デフォルトの名無しさん
25/08/08 09:22:22.32 tqBmz1L/.net
データ系だと手元のPythonで扱いきれない程度のデータ量ならもう潔く諦めて分散並列で殴るのが基本だから、
1ノードにおける極限のパフォーマンスを追求したりする必要は全く無いんだよね
分散並列処理をするフレームワークやDB自体の方の開発には当然Rust使う余地は多いにあるはずで、やってみたい気持ちはあるけどね
815:デフォルトの名無しさん
25/08/08 09:29:27.37 UUZNHK+j.net
ヤフコメで人生を謳歌する、うだつの上がらないおじさんのテンプレのような
隙あらば自分語りっぷりに震える
816:デフォルトの名無しさん
25/08/08 10:33:59.94 WKsEIIsv.net
単体性能チューニングにコストをかけるよりもスケールアウトにコストをかけた方が低コストというのは長らく言われていたことだが
分散技術がかなり�
817:ﾉまってきたので、個々のノードの性能「も」もっと上げようという機運が生まれてる。 どこまでやるかは状況によるけど分散するから単体の性能は控えめで良いというほど単純でもない。
818:デフォルトの名無しさん
25/08/08 10:56:35.02 IhWPsUT8.net
>>799
個々のノードの性能が重要なのはその通りだけど、アプリケーションコードは結局SQLかそれに類するDSLを書くだけだからね
バックエンドがJavaだろうとRustだろうと関係ないのよね
819:デフォルトの名無しさん
25/08/08 11:05:13.32 JT3s5b1h.net
そんなレベル低い人がなぜこのスレに？
820:デフォルトの名無しさん
25/08/08 11:27:25.73 OL6PJEc4.net
「レベル」はアナログだからバリアをつくれない
821:デフォルトの名無しさん
25/08/08 11:37:03.76 jC08HfuP.net
Rustでチマチマと数%のIO削減に取り組む仕事とSQL投げて数百のワーカーノードで分散並列処理させる仕事とでは、一般的には後者の方が「高レベル」と表現される
技術難易度の話なら言語というより実際に取り組んでいる問題自体の難易度によるので自明ではない
822:デフォルトの名無しさん
25/08/08 11:44:25.90 Mdr3oCfI.net
SQL投げるだけの仕事は低級だろ
823:デフォルトの名無しさん
25/08/08 12:02:00.62 anKnb75R.net
現実を直視できない低級お爺さんはそうやって自分を慰めてればいいよ
824:デフォルトの名無しさん
25/08/08 12:20:22.45 PjXZd3xW.net
>>787
各々の分野は多岐に渡るし
わざわざ仕事の詳細を話す人はいないけど
以前の世界的な調査結果でも判ったようにRustはWeb関連も一大勢力
サーバ側各種からWASMに至るまで
825:デフォルトの名無しさん
25/08/08 12:29:52.90 PjXZd3xW.net
>>803
>Rustでチマチマと数%のIO削減に取り組む仕事
どの言語でも同じだけど
Rust利用者のほとんどは各種のフレームワークの利用者側だよ
フレームワーク自体の開発者側が圧倒的に少ないのは他の言語と同じ