【悲報】プログラミングの大先生、嫌儲で激論レスバ どっちの勝ち? [364799964]
■ このスレッドは過去ログ倉庫に格納されています
https://imgur.com/ 55 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:33:50.22 ID:kq23qcgY0St.V >>1 プログラム関連においてエラーが出て意味不明に思う場合 それは断じて英語が読めないからではない プログラムの技術に関するスキルが足りてないからだ 例えばヒープとスタックに関する技術を知らん人が スタックエラーを翻訳して読んだところで何が理解できるというのか? この回答者も返事が間違っていて 英語を読めるように努力するのではなく メモリやアドレスに関するIT技術を高めることがエラー対処になると言わなくちゃいけない 恐らくこの回答者の実力も大したことないと思うわ 60 番組の途中ですがアフィサイトへの転載は禁止です (中止W 078f-eAyv) 2023/02/14(火) 14:35:08.83 ID:YcwzkYpW0St.V >>55 何のエラーか一切書かれてないのに良くそこまで妄想できるな 病気だろ 70 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:36:21.03 ID:kq23qcgY0St.V >>60 エラーというのはメモリに関するものが基本だろ おまえもプログラムなんて組んでないな ちょっとした言葉で実力なんてバレちゃうんだよ 80 番組の途中ですがアフィサイトへの転載は禁止です (中止 Sd4a-XiwN) sage 2023/02/14(火) 14:37:45.23 ID:PwdsPRWrdSt.V BE:821322453-2BP(1000) >>70 質問者と同じレベルだよ君は 87 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:38:50.72 ID:kq23qcgY0St.V >>80 NULLにしたってアドレス参照不能から来てる スタックもヒープも・・・とにかく お前らなんぞがプログラミングを語るな 102 番組の途中ですがアフィサイトへの転載は禁止です (中止W 078f-eAyv) 2023/02/14(火) 14:41:18.21 ID:YcwzkYpW0St.V >>87 スタックオーバーフローなんてCでもめったにあり得ないが頭大丈夫? 8ビットマイコンでもいじってんの? まあ8ビットマイコンでもそんなエラーは出ないがな Cにはスタックオーバーフローを予測する機能がないから 108 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:42:32.86 ID:kq23qcgY0St.V >>102 例えば多重に継承してるのを禁止した言語である場合 エラーは何をもって判断してると思う? 116 番組の途中ですがアフィサイトへの転載は禁止です (中止W 078f-eAyv) 2023/02/14(火) 14:44:21.39 ID:YcwzkYpW0St.V >>108 javaのことを言ってるのかな インタープリタ言語ごときでメモリのエラーがーとか臍で茶が湧く 127 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:45:48.97 ID:kq23qcgY0St.V >>116 ヒープに対するアドレスが重複してたらエラーを出すんだよ メモリ以外の何物なのか、それ 今度から俺もやってみよう 説明が面倒な話が出たら「圧倒的に速い」連投 日本の少子高齢化問題への対策は? 「子作りしないから少子化が圧倒的に速い」 「圧倒的に速い」 深みも知性も消し飛ぶフレーズだな >>196 ヒープをどうしても必要な時には、その案1は基礎テクニックだから行なうだけの話だね スタック上だと存在期間が限定されるというのはその通りだけど、 例えばメイン関数でスタックで確保したものは終了まで使えるし、 同様に、関数呼び出しととその呼び出し子孫関数のみで使うならば、そのトップ関数のスタック上確保で十分なわけよ じゃあコンストラクタでインスタンスを作る場合はどうか?となるだろうけど、それもコンストラクタの「呼び出し元」のスタック上で確保されれば大丈夫 ここで「呼び出し元」は多段に遡れることにも注意 このようにヒープ利用はどんどん減らすことができる 最近の一部の言語はこのようにして実行効率を上げている >>197 CS出身です >>201 callocじゃなくてallocaね スマホ打ちだと予測変換で単語が化けて意味が通らなくなる ID無しの嫌儲統失廃人と 「圧倒的に速い」Rustくんは同一人物かな 脳内に物理モデルもプログラミングモデルも作れずに ひたすら文章を丸暗記して理解した事にする 知能の低い人がやけに多いと思ったら 同じタイミングで連投する統失廃人だね あと言わずもがなの話だけど ・嫌儲統失廃人 ・「圧倒的に速い」文章丸暗記芸のあたま弱い人 どっちも興味ないからNG済みな お前が何を書いても共有NGで誰も読まない >>203 malloc相当のヒープ管理プログラムを書いたことある人にとっても、あるいはコードを読んだことある人にとっても、ヒープ領域での確保と解放の管理がスタック領域と比べて非常に遅くなるのは常識 まずはコード読んでごらん スタックならスタックポインタの加減算で済むのだから、圧倒的に速い 話がちょっと変わるけど 脳内にモデルを作れず文章丸暗記で理解したフリをする人は 応用が全く効かないからすぐ足元を見透かされる 脳内にモデルを作れている人は たとえ単語や表現が違っても同じ構造の話が出てくれば すぐにモデルに当てはめて回答できるし それを別の側面から眺めた話や 他の構造をもつ他のモデルの話も 差分や構造変換や相違点として理解する事ができるから 話が弾む >>209 ねえ、ヒープのほうが圧倒的に遅いってデータ出したけど エラーメッセージは言うほど英語関係ないな BASIC使ってた中学生の頃でもなんとなくで理解してたし こういう早口君が脆弱性だらけのコードを書くんだよ(苦笑 てかエラーメッセージが英語でパニック起こしてるくらいなんだから メモリとかヒープとか関係ないやろ もっとスクリプト寄りの言語やろ そこら辺が全くできていないのに 自分は賢いと勘違いしているのが 嫌儲統失廃人だから どんなに話題や文体を変えても 同じ類の障害を持った人だと すぐバレてしまう 書き込みが二人程度しかいない過疎時間帯のスレで 全く同じ障害を抱えた人が複数現れる確率は 常識的に極めて低いから、いくら自演で連投しても 同じ愚か者の戯言だとすぐわかるのが健常者の視点 ID:nra79zCo0 この人、ヤバないか・・・ やっぱりラマン散乱にいつまでもしがみついている人の知能はとてつもなく低いなぁ 養護学校に残った方が良かったんじゃね >>216 知能の低い人は2〜3行のレスを書くのがやっとなんだろうけど チャット感覚で話し言葉をゴリゴリ打てば スマホでもこの程度の文は普通に連投するよ パソコンで書いてた時は1分間に10レスくらい書けて 頭の悪い人をパニック状態に陥れてしまったから それ以降は携帯とスマホからしか書き込んでいない モダンな言語も普通にヒープよりスタックのほうが圧倒的に速いという前提で作られてるわけで それに文句言うなら自分で言語でも作ってみたらいいんちゃうの あとエビデンスも提示してさ それにCの話しかしてないのも気になる 他の言語だとドレ使えるんだろうか、この人 嫌儲統失廃人の人は職場に居場所がなくて 朝から晩まで24時間365日25年間匿名掲示板にへばりつく一種のホームレス ネチネチネチネチ この手の奴って数年に1回派遣で紛れ込んでくるんだよな んで初日から誰も相手にしなくなって速攻消えていく 組込やろうや しょうもない話を仏の顔で見守れるようになるぞ 知ったかプログラマA vs しったかプログラマB ふつうヒープやスタックのポインタ見ても誰もわからん >>229 最近の言語はそのへんを言語レベルで自動サポートしてプログラマーに負荷なく実行効率を上げている 例えばGoはコンパイラが自動的に解析してヒープを使わなくてよいと静的に判断できるならスタック上に確保する 例えばRustはもっと積極的にスタック上での確保で済むように設計されポインタ(参照)の扱いについても安全と効率をGC無しで両立させている ケンモメンはいちいち決めつけるのやめてくれないかなぁ どっちでもいいわそんなの あと人格否定も辞めてほしい >>229 プログラミング言語開発コミュニティや 情報科学専門家にとっては常識だけど この板にはその手の人はあんま居ないみたいね ある程度大きなデータをヒープに取るかスタックに取るかを そのデータへのアクセス状況をコンパイラが分析して 最適化する技術は1980年代からあったね それをオブジェクト/インスタンスに拡張したコンパイラーがあったかどうかはちょっと謎。 gccベースのObjectiveCコンパイラとか Squeakのコンパイルで吐き出すC++ソースあたりだと gccの最適化オプション経由で結果的にやってたかもしれない 何が言いたかったかと言えば 最近の話ではないという指摘 >>230 スタックしか使わない言語はオブジェクトの存在期間が 生成元関数の時間スコープに限定されるから 言語仕様が多少特殊で、ローカル変数構造体しか使わない ようなプログラミングスタイルになるね GCが関係ないのも当たり前で、そもそもGCが必要になるような存在期間が自由なオブジェクトは作らないという縛りゲーだね。むしろヒープに移動可能にした方がマシだと思った まあそういうのわからない人にはメリットしか目に入らないんだろうけど 逆にクラウドサービスで、メモリ管理にまつわるオーバーヘッドやバグ(メモリーリークや参照の残る巨大オブジェクトの問題)を取り除きたいという課題の下では、その言語仕様が歓迎され使われるのも当然だと思う >>236 スタック上に確保すると生存期間の制限を受けるのはその通りだけど 必要とする生存期間の範囲のトップ関数のスタック上で確保すれば何ら困ることはなく自由に使える 極論すればメイン関数のスタック上で確保すれば生存期間はフルである そしてデメリットは無い もちろんヒープ上が向いている用途には適材適所でヒープを用いればよい しかしどちらでも構わない用途ならばスタック上に確保した方が有利である やっぱりデメリットを理解していない人だ オブジェクト生成をトップレベルのメイン関数等に限定する話は、資源の予約と解釈すればクラウドサービスの要求に合致するが その代償として、メイン関数レベルで生存期間不定のオブジェクトを全て網羅的に生成する縛りとなって プログラミングスタイルにスタイルとして不自由さが残る それをデメリットだと理解できないのは 自由なプログラミングスタイルを知らず クラウドサービス向けスタイルだけが正しいとする 宗教的信仰の話になってしまうから 情報科学としては難がある 自分の強い信仰を他人に押し付けようとするのは 愚かな行為だね で次に、Rust言語でヒープ上にオブジェクトをアロケートした時、その生成と廃棄は ・明示的指示 ・リクエスト単位(メイン関数スコープ) ・セッション単位(メイン関数を複数回呼び出し一連の作業をするスクリプト単位/メモリオブジェクトなのでサービスを落としたら消滅) ・永続化(DBやCookie等への保存/参照) のおよそ4つのスコープに分類されて その管理は残るよね >>239 全てをスタック上に確保と主張しているのではないんだよ 例えば静的には予測できずに個数が動的に生じるものやサイズ不定なものなどはヒープに確保することになる 逆に言えば静的に必ず必要なものだと分かるものやサイズ上限が分かっているものはスタック上に確保できるものが多い そしてヒープ利用よりスタック利用の方が有利なのはご存知の通りだから可能な限りスタック上での確保が有利という話 仮にヒープ側オブジェクトのスコープ管理の支援機能が無いとしたら、それはWebベースのサービス開発のオーバーヘッドとなるから、今後の言語/ライブラリの拡充が期待されるね >>241 最後の行繰り返すのやめてくんない? こちらにとっては35年前の記事の時から知ってる話を 書き込みのたびにしつこく繰り返されるのは 強迫観念が強すぎて嫌な気分になるよ 他の人にも指摘されてない? >>240 Rustはヒープに関してもメモリ解放は完全に自動なのでプログラマーが指示することはない ヒープで確保したものについても使われなくなった時点で即座に自動で解放される これはコンパイラがコンパイル時点でそれらを静的に解析できる言語仕様になっているため可能となっている 従来のプログラミング言語と比べると革命的な進歩というか違いがあるから最初は理解しにくいだろうが 078f-eAyvが中級レベル 0a56-D0vNはその辺の中小企業で働いてる底辺レベル、初級ですらない >>242 それRustの話ならば既にWebベースでいくらでも使われている現実があるよ 既に書いたようにヒープ上であろうがスタック上であろうが言語システム側が責任を持ってメモリの自動解放までしてくれるため、 GC無しでもメモリ安全性がある初のプログラミング言語となっている なんかおかしな話になってきたな 前提知識 オブジェクトの自動開放にはGC以外にリファレンスカウントという方式があって、オブジェクト型のポインタ参照が追加されるたびに+1、ポインタ参照が廃棄されるたびに-1して、ゼロになったら廃棄する。ただしその方法も実行時に余分なオーバーヘッドは起きる。 コンパイラの静的解析でヒープ上オブジェクトの自動廃棄ができるという主張は、 静的解析だけで存在期間が割り出せるオブジェクトに関しては有効だが 動的挙動、例えば実行時の入力に応じて存在期間の変わりえるオブジェクト、例えばタイマーオブジェクトを静的解析で開放タイミングを決定するのは難しい。もちろん、開放のヒントとなる情報(特定の関数が呼び出されたタイミングで不要になりそう)はあり得るけど、そのタイミングで追加入力でタイマー時間再延長をしたら存在時間は決定的とは言えなくなる。 その辺を加味すると、ヒープは最悪、プログラムの終了まで持ち越すという消極的な結論しか出せなくなる。 あとはセッションスコープと永続化に回答がない時点で、状況は察した。 >>246 Webベースで使われている前提は知ってるけど セッションと永続化に関するソリューションの話が出てこない時点で、あんま詳しくない人なのだと察した >>247 それは知識不足がちょっと多いかな たぶんベストなのはRustのメモリ管理の仕組みを勉強するとこだと思われる ヒープ上に確保しても必要としなくなったら即座に自動メモリ解放されるように設計されている せめてC++のunique_ptrを理解していればRustはそれを通常状態にしたことが一端だから導入としては理解しやすくなると思う まあクラウドサービスは並列サーバクラスタで運用するのが普通だから、セッション情報はDBMSとCOOKIEに保存/参照がデフォだな ヒープ上オブジェクトの存在期間をコンパイラの静的解析で自動廃棄するというのは全部のことではなくて そこから漏れる静的存在期間不定のオブジェクトは メイン関数やリクエストハンドラーのスコープで 自動廃棄だろうな > スタックオーバーフロー フォルダを巡回するプログラムを何も考えずに書くと発生するな 今のPCでも結構すぐに逝く >>249 最初からunique_pointerだと説明すればいいじゃん 言語的バックグラウンドが全く違うから 共通概念を使って対話を試みたけど 使うべき専門用語はちゃんと出さないと とても曖昧で捉えどころのない話になって あなたの言語的バックグラウンドの不足をこちらは感じているよ >>248 ヒープでの永続化については 実際にヒープでメモリ確保するどの言語でもいいからプログラミングすると分かるけど 必ずヒープへの参照(ポインタ)またはその連鎖を常に誰か変数が持っているわけよ もしある段階まで進ん誰もそのヒープ上への参照を持つ変数がいなくなったら、それはそのヒープ領域を誰も必要としなくなったことを意味するのよ その段階もしくは直前で、例えばC言語だったら手動でメモリ解放をし、Rustだったら言語機能としてコンパイラが自動でメモリ解放コードを挿入 イベントの解除漏れによるメモリリークはどうすんの? >エラーというのはメモリに関するものが基本だろ ここでもう読む気しなくなるからな プログラム以前の頭の問題 メモリに関するものはエラーというか例外になりそうだよなあ 大まかにいうと>>247 リファレンスカウントでは複数オブジェクトからの参照を許すのに対して、 C++で参照を一箇所に限定する形で実装したのがunique_ptr って話だね それ最初に説明すべき話 >>255 win32でゴリゴリ書いてるけど大体メモリーだな >>253 その話はリファレンスカウンター方式で上限1に限定した話だね 相手の力量を読み取れない人との会話は周りくどくて疲れるね 周りに相互理解できるレベルの人が少ないと どんな相手にも重要キーワード抜きの周りくどい説明をするようになりがちで、結構大変 >>257 C++もRustも複数参照の方も対応しているよ C++ではshared_ptrそしてRustではRcを使って複数参照のメモリ自動解放も可能 これらのみがリファレンスカウンタを利用します >>259 いいえ違います C++のunique_ptrもRustの通常もリファレンスカウンタは使いません 結局この人は、相手の力量もわからずに周りくどい説明ばかり垂れ流して、それを情報科学ほ共通概念で説明しても反応しないという事は、情報科学の人ではないな 最初は文章を丸暗記してる人かと思ったけど 今時点の印象は基本教養の不足したC++プログラム関係者という印象 >>261 後半部、キミのアホさ加減がよくわかった リファレンスカウンター方式で解釈すると unique_ptrは上限1でコピー不可/譲渡可の リファレンスカウンターと等価だという極めて単純な話 最初から気になっていたけど 自分の視点だけしか見えていなくて 視点変更が不得意な人だね なんだかなぁ でもリファレンスカウンターには反応せず あとからshared_ptrの話を持ち出してきたあたり リファレンスカウターという概念を知らない文化圏の人なんだろうけど、それって基礎教養なしの独学の人なのかと気になった 情報科学の共通概念で話が通じないのはしんどいね もしや高校生くらいの人なのかな 情報科学抜きで突っ走れるのは それくらいの年代までだし でもそれはそれでいい事だと思う >>263 リファレンスカウンタなんて持ち出さなくても説明できる概念だよ もちろん無理やり上限1のケースと解釈してもいいがそこは主要な原理ではありません C++のunique_ptrもRustも自動メモリ解放を実現している基本原理はRAIIなのでそこを押さえておきなさい あなたの話って高校生のような大胆な断言が多過ぎるけど それは独学で強い信念を持った結果なのか 基本教養が無くて等価という概念を受け入れる事ができずに 何でも向こう水に否定してしまう幼さなのかな 面倒 >>266 幼稚だね どこで学位を取るとそんなに狭量で 興味のまるでそそらない話を他人に押し付けて回るあほみたいになるのか知りたいわ 頭バカな人と大差ない >>264 リファレンスカウンタなんて使ったら遅いし無駄なのでC++でもRustでも極力使わないようにしてやむを得ない最小限でのみ用います どちらの言語もC言語と異なりRAIIをサポートとしているため単独参照ならばカウンタを使わずとも使用が終われば自動でヒープ解放できるわけです >>266 あと「基本原理」という言葉を出した以上は リファレンス論文は出してね 言語的バックグラウンドがまるで異なる人に 自分のバックグラウンドを リファレンス無しに押し付けるのは 研究者や教職員ではない、高校生レベルの人だと認識 してるけどね >>101 相手が知らない単語を多く使った方の勝ち という争いに変わってる >>270 等価という概念を理解していない事はもうよくわかったから 意味のない演説は不要だよ キミは他人が何を理解して話をしているのか 察する能力が低過ぎて、共同作業ができない人だね ここからが見どころ リファレンス論文が出せたら合格 出せなかったり 原典ではない日本語解説ページしか出てこなかったら 例の英語論文を読みこなせない人の変種でしかない 英語がわからない中高生でも作るもん作ってる人はいるから・・・ プログラミング初心者でVSCodeの設定につまずいて 実質まだなにもやってないんだけど 『.txtと.mdなど開いたファイルごとにtheme(テーマ)設定を変わるようにしたい』 っていう俺のこの疑問はどうやったら解決するの? 検索しても、あまりにも答えが出ない。 出なさすぎるので、 もしかすると自分は、初心者特有の非常識なアプローチをしてるのではないか?という不安。 Resource Acquisition is Initializationの論文一覧 https://scholar.google.co.jp/scholar?hl=ja&as_sdt=0%2C5&q=Resource+Acquisition+Is+Initialization&btnG= ちなみに検索トップでは 原理(principal)ではなくてIdiomと説明している だいたい底が見えたね 原理とイディオムの区別ができない人 >>271 RAIIのリファレンスを出せってマジ言ってるの? じゃあRAIIも知らずにC++やRustのメモリ自動解放を批評していたわけ? ちなみにRAIIはメモリだけでなく他のリソース自動解放にも使われている原理だよ 例えばファイルの自動クローズとか イディオムを原理と言ってしまう幼さに絶望 原論文やリファレンスも出せない って事は、その用語の定義や初出を調べずに ただ何となくC++とRustの文脈で原理と呼ぶ人が居るから それを真似しているだけ 俺さいしょからRustには全く興味ないと断った上で 齟齬のある説明に突っ込んでるんだけど 思い込みの激しいひとは大変だな C++コミュニティはLisp/Smalltalkコミュニティの10〜20年後追いのエピゴーネンだからあんま重視してないのだけど C++の人って車輪の再発明に気付かずに大見得切っちゃう幼さが珠に傷だね まあとりあえず有力そうなリファレンスはこれかな [B] The boost C++ libraries B Schäling - 2011 - books.google.com … RAII stands for Resource Acquisition Is Initialization. The idea behind this idiom: forany resource acquired,an object should be initialized that will own that resource and close itinthe … この書籍のリファレンスを掘らないとそれ以前の歴史は引っ張り出せない >>281 リファレンス出せばいいのにね リファレンス出せないから逆ギレとか 負け宣言だね RAIIを知らなかったということはC++でもメモリ含めたリソース扱ったことないのだろうけど なぜヒープでのメモリ確保やメモリ自動解放の議論で暴れているのだろう 理解ができないならばガベージコレクションのある言語を使っていてもいいんだよ この観点からはプログラミング言語は大きく3つに分かれているのだから (1) ガベージコレクションのある言語はすべて自動で楽だけど遅い (2) C言語などは手動メモリ解放となりミスると危険だが速い (3) Rust言語などは自動メモリ解放で安全で楽で速い ちなみにC++はスマートポインタ必須の時のみ(3)に近い状況 この高校生の人、何が原因でRAIIのリファレンスも出せずに負け犬宣言を繰り返してるの? Rustには全く興味がないと一番最初に宣言した上で 説明の齟齬や欠落を指摘してやったのに 逆ギレ負け犬宣言して信仰告白コピペ継続とか まるで英語論文読めない落ちこぼれの嫌儲の人みたい 嫌儲でガチ統失って一人おばさんが居るけど その人も誰も興味のないコピペを大量に貼って スルーされて発狂してんだよな この高校生っぽい人もこんな場所で暴れても不毛だから 未踏かなんかで拾ってやれよと思う ちなみに共通点 ・喧嘩腰 ・説明不足を指摘されても認めず意地を張る ・理解を示してやっても逆ギレ ・原理とイディオムの相違、等価モデルの概念といった 基本教養に問題がある ・リファレンスを決して出せない 知っているのが常識だと言い張って 己の不明を誤魔化す ・定型文連投 結構似てるよね id:nra79zCo0はコンピューターサイエンスをちゃんと勉強した人ではあるんだろうが Rustの知識はないので、自分がズレてることを自覚できてない Rustの所有権はリファレンスカウンタと違う リファレンスカウンタってのは、参照されてる側を監視してるわけだけど 所有権は参照してる側を監視している だから、参照している側のライフタイムが終わったら、即座に参照されている側も終わる 方向性が逆だし、無駄な時間のロス、確認処理もない 統失1号登場かな わざわざ金を払ってIDとワッチョイ消して 共有NGされているかわいそうな人 まあこんな過疎スレで一日に何回も似たタイプの書き込みがあるのは、必然的に似た傾向の人だね 何を理由に統失って言ってるのか、なんで統失にこだわってるのかがさっぱりわからん 俺別に妄想とかしとらんし、脳汁ドバーみたいな言葉の羅列もしとらんしなあ 多分あなたが統合失調症で現場を離脱した人とかなんじゃなくて? いま寛解状態とかじゃない? でもなんか思い込みで他人を断定しすぎてるから、気を付けたほうがええで >>282 RAIIで2011年の書籍を出してくるとは驚く! C++が世に出たのは日本で言えば昭和の時代だよ C++の作者Stroustrupの書いた書籍「プログラミング言語C++」の日本語版の初版が手元にあるけど発行日は1988年11月15日 その最初の時からRAIIに基づいてデストラクタが自動的に呼ばれていたのだから RAII (Resource Acquisition is Initialize)というイディオムのリファレンスを求めているのに そのイディオムに名前が付く前のC++ finaliz処理を RAIIイディオムの使用例だと言い出してしまったら それはそのイディオム自体が後付けのバズワードに過ぎない事を証明しているように見えるな ビャーンストラウストラップ自身がRAIIに類する言葉を使い始めたのはいつなの?w あと、イディオムとよく似た概念でパターンランゲージというのがあって、使用例自体は1970年から80年にかけて開発されたSmalltalkシリーズのクラスライブラリの中にも多数使われているのだけど それを建築設計分野の意匠の組み合わせ方を指す「パターンランゲージ」という表現で扱い始めたのは1987年、 その成果を書籍デザインパターンとして出版したのは1994年で そっから派生したのがイディオム関連本だから まあせいぜいその辺りが非公式な使い始めじゃないかと推測する あと、デストラクタの中で追加の終了処理をする話は デストラクタの登場当時だろうから 1970年とか1967年Simula言語とか それよりも古い言語まで遡れる可能性が高いね で、その大昔からある概念をまとめて整理してRAIIというイディオムで表現したのは誰でいつ? >>294 RAIIの概念を知らなかった人に言ってもムダかもしれないけど RAIIという呼び名はどうでもよくてというかこの呼び名は実は評判悪いこともあるくらいで その中身の原理が重要なので一言で言い表すためだけに使われてる >>296 リファレンスがどうしても必要なら初出はこれかな Sutter, Herb (1999) "Exceptional C++" Addison-Wesley ISBN 0-201-61562-2 論文書くときに引用する時くらいしか初出なんて気にしないけど拘る意図がわからない それよりもGCやリファレンスカウンタ無しでC++スマポやRustがどうやって安全にヒープメモリ自動解放を実現できているかをこれで理解できたかい? >>297 やっとリファレンスを出してきたか 次の課題はRAIIの原著に即した定義ね 他の論文や書籍がイディオムと呼んでいるものを あなたは何度も原理だと言い張ったのだから それが原理と書かれているのか イディオムと書かれているのか それ以外の概念として呼ばれているのか あなたは自分の発言を検証するべきだ もちろん、そんな責任を放棄して 無責任な言葉を使うのもあなたの自由 結局スマートポインタのひとつunique_ptrで実装してあると説明すれば終わる話を 齟齬のある表現で何度も説明したり それを指摘されるとC++のRAII原理だ知ってるのが当たり前だと言い出してリファレンスを出さなかったり あなたの言動は物凄く効率が悪いよね >>219 元スレの方見てみろ やばい人だわ 嫌儲のプログラミング関係スレって何でもこんなにやばい人湧くんだろ >>10 組み込み以外よく知らない人なんじゃないかな >>300 キミがレスしてる相手が嫌儲で一番ヤバい統失の人だぞ ID無し嫌儲統失の人はたぶん学生時代から この種のゼミ形式の会話ができなくて ロンダ時に指導教官と大喧嘩して それで学生を理解する教員になるかと思ったら 学生相手にも誤爆罵倒トラブルを起こしたり ブログで学生への罵倒を繰り返して 今の状態になったんだよな ゼミでまともに議論するスキルのない人の末路 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる