25/07/21 17:48:51.39 yY37yx4X.net
>>437
あー、なるほどねー
Webの技術使うからそのままWeb系の攻撃が可能になってるところあるのか
Web参照する系のアプリはあぶないねー
447:デフォルトの名無しさん
25/07/21 18:02:43.94 yY37yx4X.net
そうするとTauriは権限あるからいい�
448:ｯど類似のブラウザベースのGUIアプリとかガバガバなんじゃないの？ 問題になってたりするの？
449:デフォルトの名無しさん
25/07/21 18:52:16.65 pK2qnHJn.net
>>439
ElectronはWebView毎にNode.js APIの使用可否を指定できる
特定の操作だけを許可したい場合は明示的にAPIを定義することもできる
Tauriは後発ゆえにセキュリティをアピールしてFUDに訴える戦略を採ったのだろうけど、一般的には上記で十分
450:デフォルトの名無しさん
25/07/21 19:49:20.87 yY37yx4X.net
>>440
ブラウザベースのGUIアプリでWebViewにネット上のリソース読み込ませるのって普通のWebアプリよりリスク高いね
HTML/CSS使えるのは便利なんだけどな
451:デフォルトの名無しさん
25/07/21 21:31:05.10 QA4DTPlF.net
そんなことない
452:デフォルトの名無しさん
25/07/21 22:03:02.11 yY37yx4X.net
WEBアプリはブラウザで止まるけどGUIアプリは直でマシンを狙われるじゃん
普通のWEBアプリよりリスクあるってかセキュリティ的な課題が多いよ
権限とスコープで範囲絞ればまだ何とかなるけど
453:デフォルトの名無しさん
25/07/21 22:21:38.00 yY37yx4X.net
でもElectronはVS Codeなどの実績もあるし結局開発者次第だろうな
俺はWebアプリよりセキュリティ的にシビアな開発になるという認識になったが
454:デフォルトの名無しさん
25/07/21 23:05:50.42 zPKMB/NN.net
>>443
何がどう危険なのかすら理解しておらず無知すぎる
例えばシェル上でwgetやcurlなどを用いてHTML/CSS/JavaScriptや画像や動画やPDFなどをダウンロードしたことない？
それで何が危険だった？
当然危険なことは何もない
一方でウェブのセキュリティ例えばXSSクロスサイトスクリプティングも
万が一敵のサイトのJavaScriptを実行してしまう設定だとしてもそこでお漏らしできるのはクッキー情報など閉じた中のデータだけだ
じゃあ見知らぬデータ由来でローカルのファイルアクセスしてしまうリスクはどこで起きるか？
ウェブと全く関係ない普通のGUIアプリのリスクと全く同じだ
455:デフォルトの名無しさん
25/07/21 23:23:03.67 Lh9K5xSF.net
危険なものを安全だと思い込むのは危険だ
逆に、安全なものを危険と思い込むのは、安全か危険かで言えば、危険なことは全く何もない
456:デフォルトの名無しさん
25/07/21 23:39:49.57 PNGKWXZj.net
いや普通にweb特有のリスクあるでしょ
OSネイティブのGUIアプリではXSSなんて起こらないし
tauriやelectronは、ローカルファイルへのアクセス等をフロント側のプロセスに公開してる都合上、乗っ取られた時のリスクは普通のブラウザよりも大きい
(webブラウザのようなサンドボックスなら「VS Codeでローカルのソースコードを表示する」なんてできないわけだし)
electronもtauriもセキュリティの話をドキュメントで説明してるんだから、それが必要になる理由はちゃんとある
457:デフォルトの名無しさん
25/07/21 23:44:31.69 COp00WAH.net
>ウェブと全く関係ない普通のGUIアプリのリスクと全く同じだ
それもまた違うんだけどな
458:デフォルトの名無しさん
25/07/21 23:46:37.15 yY37yx4X.net
>>445
いやいやいやいや
curlとブラウザを一緒にされては困るｗ
ブラウザはscriptを読み込んだら実行される可能性があるがcurlは実行されない
それからcurlを使うのは知識のある開発者だがGUIアプリは無知な一般ユーザーも使う
まったく条件が違う
459:デフォルトの名無しさん
25/07/21 23:53:29.42 ljGk1Vvp.net
>>447
XSSはブラウザの中の制限されたjavascriptの世界の中の話
サンドボックスの中なので何もすることはできない
外に対して唯一できることはWebサイトアクセスのみ
ローカルファイルアクセスは不可能
GUIアプリがWebベースかどうかでリスクの差は生じない
460:デフォルトの名無しさん
25/07/21 23:55:20.01 Z3GJzxqV.net
>>449
トンデモ連投する前にゼロから勉強し直したら？
461:デフォルトの名無しさん
25/07/21 23:58:28.52 moBe7I/z.net
最も安全なGUIアプリはWebアプリですよ
WebアプリはWebブラウザにバグがない限りリスクがありません
Webサイトアクセスと同じですから
462:デフォルトの名無しさん
25/07/22 00:03:58.73 qTyrO8F1.net
ブラウザにバグがなくてもアプリに脆弱性があればダメだし
アプリに脆弱性がなくてもユーザーが情弱だとダメ
>>450-452みたいにね
463:デフォルトの名無しさん
25/07/22 00:18:03.27 pyIlPdKS.net
比較するならネイティブGUIアプリが最も危険だよな
極端な場合バグもしくは意図的な仕込みでローカルファイル全消去までありうる
ユーザとしては信頼できる大手など提供のアプリしか使いたくない
一方でWebアプリは普通のWebサイトへのアクセスと同じだからユーザにとって何か新たなリスクは生じないため気軽に使える
Webアプリ提供側もWebサイト運営と同じで何か新たなリスクは生じない
464:デフォルトの名無しさん
25/07/22 00:30:43.05 sPs3Reb2.net
XSSはまだいいがCSRFだよな
こっちも条件そろえば行けるんであれば開発難易度はWeb+GUIで高くなるね
465:デフォルトの名無しさん
25/07/22 05:32:27.74 Z1PZI78m.net
・テレポートが完全に否定されました
量子物理学が「宇宙の輪廻転生」を否定―我々の宇宙は一度限りのものだった
2025.07.21 22:00:10 MONDAY
URLﾘﾝｸ(nazology.kusuguru.co.jp)
>>近年注目を集めている量子重力理論という新しい分野です。
>>これは重力に量子力学の考え方を取り入れ、従来の物理法則では説明できない現象にもアプローチする理論です。
>>これは重力に量子力学の考え方を取り入れ、従来の物理法則では説明できない現象にもアプローチする理論です。
>>例えば、真空中でもごく短時間だけ負のエネルギーが現れる現象（カシミール効果）や、ブラックホールがエネルギーを放出するホーキング放射という不思議な現象が知られています。
>>これは従来の特異点定理が前提としている「エネルギーはどこでも負にならない」という仮定を根本的に揺るがすものです。
>>そのため現在の物理学界では特異点重視派と回避派が理論的なしのぎを削っている状況にあります。
>>第一に、完全な特異点の形成を回避できる可能性があることです。
>>第二に、多くの人が抱く「ではビッグバンの前には何があったのか？」という一般の人の素朴な疑問にも「前の宇宙があった」と答えられるため、科学的にも物語的にも興味を惹くものでした。
>>本質的には「宇宙やブラックホールが崩壊する過程で、もしもエントロピーが常に増加し続ける（＝GSLが成り立つ）限り、いかなる場合も完全な崩壊＝特異点形成を避けることはできない」という定理を証明したのです。
>>つまり、量子効果をどんなに考慮しても、特異点が必ず現れてしまうという結論になり、ビッグバウンスを起こすには基本的な物理法則の一つであるエントロピー増大則を破らなければならない、ということが明らかになったのです。
>>その結果、宇宙全体が収縮の後に再膨張するという「ビッグバウンス型」のシナリオも、少なくとも通常の物理法則の枠組み内では否定されることになりました。
>>少なくともブーソ氏をはじめ多くの物理学者は「どんな理論においても、時間が止まる境界のようなものは残るだろう」と考えています。
466:デフォルトの名無しさん
25/07/22 09:59:34.52 xERdX2Ve.net
自分で食べる物よりも他人に食わせる物のほうが危険
他人を説得しようとする奴が危険とも言える
467:デフォルトの名無しさん
25/07/22 10:19:02.40 bqrJIbUz.net
>>454
いろいろと正気を疑うレベルなのでWebアプリのセキュリティ入門本(徳丸本とか)を1冊読むことをお勧めする
468:デフォルトの名無しさん
25/07/22 10:22:43.10 bTRjdqOd.net
ネイティブアプリだと起動ユーザの権限でなんでもできてしまうもんな
ウェブアプリはブラウザと同じレベルで安心
469:デフォルトの名無しさん
25/07/22 10:30:29.84 WFyTuJby.net
最近だとWebもネイティブもやらずにElectronやTauriみたいなのから入る人もいるから、
>>435みたいに「そもそも普通のネイティブや普通のWebより潜在的に危険な仕組みである」という重要なコンテキストを理解しないまま進んじゃう人も増えてくるだろうね
Electronのドキュメント方はその辺わりと正直に書いて脅かしてくるからいいけど、
Tauriはどっちかというと危険性を伝えるより安全をアピールするトーンで書かれてるからわりと悪質
470:デフォルトの名無しさん
25/07/22 10:42:54.89 wLw5OpNP.net
>>458
徳丸本に書いてあることはWebアプリ化しないWebサイトでも守るべきことばかりだぞ
>>454で正しい
471:デフォルトの名無しさん
25/07/22 11:14:02.23 nBMr2uk5.net
>>454のいうWebアプリというのが一般のWebブラウザを使ってインターネット経由で利用するアプリ(PWA含む)のことなのか、
ElectronやTauriを使用したアプリのことなのかによる
前者なら大きく間違ってはいないが、もし後者なら正気ではない
後者はWebのリスクとネイティブアプリのリスクの両方を兼ね備えており、
相乗効果として開発元に悪意や機能的なバグがなくてもユーザーの環境が破壊されたり悪用されたりし得る
472:デフォルトの名無しさん
25/07/22 11:27:16.62 wLw5OpNP.net
>>462
WebアプリとはWebブラウザがWebサーバに接続して利用する形態を指す
もちろんPWAを含む
この定義から外れたものをWebアプリと呼ぶことはない
473:デフォルトの名無しさん
25/07/22 11:40:44.64 xERdX2Ve.net
課金する権限を持ってないアプリを使いたいなあ
474:デフォルトの名無しさん
25/07/22 11:46:21.31 Jx9L1sHS.net
>>461
ああ複おじだったのか
じゃ正気じゃないのは皆が知ってる周知の事実なので別にいいや
他の人は複おじに騙されないように注意しよう
475:デフォルトの名無しさん
25/07/22 13:07:59.22 Z1PZI78m.net
Googleの強化版Geminiが数学オリンピックで金メダルを取る性能に到達、自然言語で動作し人間と同じ制限時間で解答を導き出す
2025年07月22日 11時04分
URLﾘﾝｸ(gigazine.net)
OpenAIの「実験的推論モデル」が数学オリンピックで金メダル相当のスコアを達成、GPT-5は近日中にリリース予定で「実験的推論モデル」はまだ先
2025年07月22日 11時03分
URLﾘﾝｸ(gigazine.net)
476:デフォルトの名無しさん
25/07/22 13:16:48.91 sPs3Reb2.net
ブラウザベースのGUIアプリはWebとデスクトップアプリの両方の知識がないと開発できんわな
アンドロイドに対応する場合はアンドロイドの知識も必要になるだろうし完全に玄人向けのフレームワークだな
このスレに書き込んだおかげでリリース前に知れてよかったわ
477:デフォルトの名無しさん
25/07/22 13:34:42.76 UK6DQpw5.net
>>447
ElectronやTauriはWebサーバを立てなくてよいことがメリットなのでXSSやCSRFなどの問題は起きないよ
478:デフォルトの名無しさん
25/07/22 18:57:13.96 ItZgAdsO.net
繰り返しになるがバカおじの言うことを信じちゃだめだぞ
The first line of defense for your application is your own code. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron applications
URLﾘﾝｸ(www.electronjs.org)
479:デフォルトの名無しさん
25/07/22 19:44:25.32 AMPQ7sAV.net
オフラインで完結してるならxssは関係ない
480:デフォルトの名無しさん
25/07/22 19:55:07.12 6h/EmHT/.net
>>469
それはyour own codeを守ればXSSは起きないという意味
他所のコードかつ空間分離なしの時のみXSSが起きる
481:デフォルトの名無しさん
25/07/22 21:30:04.22 WM9400yb.net
>>471
違います
バカおじは英語読めない上に機械翻訳もまともに使えないのか
482:デフォルトの名無しさん
25/07/22 22:06:38.30 xERdX2Ve.net
ゼロオーバーヘッド論法
あなたのコードで使われていない機能の悪影響はゼロ
483:デフォルトの名無しさん
25/07/22 22:52:21.05 9b+TW2Vs.net
>>471
複おじｗｗｗ
今日イチ笑わしてもらった
484:デフォルトの名無しさん
25/07/23 07:32:40.29 cQ85VHpL.net
・自然界の光が強いから特別な屋の中でしか思考を読み取れない
脳が放つ“秘密の光”の検出に初成功：思考を読み解く新技術への扉が開く
2025年6月18日1:25PM
URLﾘﾝｸ(xenospectrum.com)
★>>極めて精密な実験環境を構築
>>実験は、外部の光を完全に遮断した暗室で行われた。20人の被験者は快適な椅子に座り、頭部には脳波（EEG）を測定するためのキャップを装着。そして、脳の光を捉えるため、超高感度の光センサーである「光電子増倍管（PMT）」が頭の周りに配置された。PMTは、光子1個という究極の光量さえも検出できる驚異的なデバイスだ。研究チームはPMTを、視覚情報を処理する「左後頭部」と、聴覚や記憶に関わる「右側頭部」の2箇所に設置。さらに、
>>部屋の背景光（ノイズ）を測定するためのPMTも別に用意し、脳からの信号と明確に区別できるようにした。
・上記は特別な部屋の中で下記は実際に観測しての発表
はやぶさ2、科学観測でも活躍 銀河拡散光と星間塵の関係を新たに発見
2025/07/22 20:00
URLﾘﾝｸ(news.mynavi.jp)
>>光学航法望遠カメラ「ONC-T」を用いて撮影した天の川銀河中心の星間塵が多い領域の画像を解析。その結果、星間塵が多いほど、星間塵が星の光を散乱して作る淡い光である「銀河拡散光」の明るさが弱まることが判明
485:デフォルトの名無しさん
25/07/23 13:21:58.70 cQ85VHpL.net
Claude Sonnet 4に匹敵するコーディング特化のオープンモデル「Qwen3-Coder」をAlibabaが発表
2025年07月23日 10時45分
>>Qwen3-Coderの大きな特徴は、ネイティブで256Kトークンという広大なコンテキスト長をサポートするだけでなく、
>>「YaRN(Yet another RoPE-based scaling method)」という拡張技術を用いることで最大100万トークンまで対応可能である点です。これにより、リポジトリ全体を理解するような大規模なタスクにも対応できます。
>>C++、Java、Python、Ruby、Swift、ABAPなどを含む358もの多様なプログラミング言語をサポート。加えて、ベースモデルから一般的な能力と数学的能力を維持しつつ、コーディングに特化しているとのこと。
>>さらに、その能力を最大限に引き出すため、エージェントコーディング用のコマンドラインツール「Qwen Code」も同時にオープンソース化されています。このQwen CodeはGemini Codeをフォークして開発
>>するSWE-Bench Verifiedにおいて、Qwen3-CoderはCloud Sonnet 4よりも小さいモデルサイズでほぼ同等のスコア
ブラックホールに捕食されても生還した「奇跡の星」を確認
2025.07.23 WED
URLﾘﾝｸ(nazology.kusuguru.co.jp)
486:デフォルトの名無しさん
25/07/23 13:57:32.46 k/bh+dq3.net
Rustと全く関係ない日記貼るのやめてくれ
お前のメモ帳じゃない
487:デフォルトの名無しさん
25/07/23 19:50:36.44 cQ85VHpL.net
ボイス・トォ・スカル自動応答システムが下記でできるようになりました
リアルタイム翻訳の「DeepL Voice」がZoom Meetingsと連携開始、対応言語を拡大
URLﾘﾝｸ(news.mynavi.jp)
Copilot+ PCに最新のAI機能登場、7月のプレビュー更新プログラム「KB5062660」
URLﾘﾝｸ(news.mynavi.jp)
>>MicrosoftはWindows Insider Programでテストしていた設定アプリのAIエージェントを正式にリリースした。
※AIで何ができるかを全て書いている
488:デフォルトの名無しさん
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 効率化のために可変参照を使うのはやめたほうがいいとは思うけど。