【悲報】プログラミングの大先生、嫌儲で激論レスバ どっちの勝ち? [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 ヒープに対するアドレスが重複してたらエラーを出すんだよ メモリ以外の何物なのか、それ イディオムを原理と言ってしまう幼さに絶望 原論文やリファレンスも出せない って事は、その用語の定義や初出を調べずに ただ何となく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無し嫌儲統失の人はたぶん学生時代から この種のゼミ形式の会話ができなくて ロンダ時に指導教官と大喧嘩して それで学生を理解する教員になるかと思ったら 学生相手にも誤爆罵倒トラブルを起こしたり ブログで学生への罵倒を繰り返して 今の状態になったんだよな ゼミでまともに議論するスキルのない人の末路 RAIIの原理が働かないCなどの言語だとデストラクタも動かずメモリ自動解放もできないことが分かれば大丈夫だよ >>299 RAIIは言語に依存しない概念だけど unique_ptrはC++言語だけの特殊な実現例であって一般的な話ではない 例えばRustはunique_ptrを必要としない RustだとCopy実装型以外は所有権があるし スタック上に確保であってもライフタイムが管理されるため親関数で確保したスタック領域は呼び出し子孫関数で使えるけど逆は無理とコンパイル時点で安全に排除できる さらに参照の扱いも違っていてそこはデータ競合を含めた安全性の保証の差となっている >>300 あら、そうなの じゃあスルーしといたほうがいいんだなあ IT系って過重労働で精神ぶっ壊れちゃった人が多いのかもしれない 言ってることがコロコロ変わり始めた 何かの学習成果を反映し始めたのだろうけど 誰もRustに興味のない場所で 定義すらはっきりさせることの出来ないRAIIを振り回して 原理なのかイディオムなのか明確にすることもなく概念と呼び変えて なかなかいい加減な人だな でもそれが人間本来のいい加減さなんだろうな 草生えた でもこちらが質問していることには答えずに コロコロ変わった話を一方的にレスされるのは 不愉快極まりないよね そこら辺の人間関係の基本はどうなってるのよ リファレンスを前にしてもなお 質問されたことに答えないのは 自分に都合の悪い話は無視するという 嫌儲統失おばさんと全く瓜二つで 相手にする価値ゼロだよな 一言で言うと「こいつRAIIの基本原理ダーと叫んだけど、辻褄合わなくなって誤魔化したな」 >>307 ヒープの自動解放の話ならC++とRustしかメジャーな言語ないでしょ あとは自動回収のガベージコレクション言語になっちゃうし もし他にあるならC++とRustと比較して出してよ あまり詳しくなさそうだから無理せずにね >>309 一番最初からRustに興味ないと宣言したし 真ん中辺でC++はLisp/Smallltalkのエピゴーネンだから重視していないと宣言したよな 興味ない話を、お前さんの興味だけが理由で語る義務は俺には一切無いね デストラクタのカスタマイズに関してはSmallltalkのあたりには出現していて、GNU SmallltalkとかSqueak (両方ともネイティブコンパイル可能) は確認可能 GCが無いと言う言語縛りには付き合う義務は一切ないね、それはキミ自身の価値観であってこちらには関係ない ヒープの自動開放はリファレンスカウンタ式の言語で実装できていて、X Windowシステムの初期実装言語CLUあたりがそれじゃないかな 日本では木村研出身の久野さん他が研究していた言語 まあかわいそうな人だよね 俺興味ないって宣言してから ツッコミを入れているのに 首尾一貫した説明を最後に崩して泥をつけ 興味ないと宣言済みの赤の他人に 自分の興味本位の話をしつこくして それでこの人の人生は豊かになるの? 似たような趣味の人と語り合えば丸く収まるのにね >>311 ヒープの自動解放はリファレンスカウンタ無しでも可能 リファレンスカウンタは参照数の管理に必要なだけであって、共有参照がなければリファレンスカウンタが全く必要なく実現できているように、リファレンスカウンタは本質ではない 結局PCオタクやゲームオタクによくいる 自分の選択を正しいと信じるだけに飽き足らず 布教まで始めちゃったものの信心のコアがいい加減だから 辻褄の合わない説明を繰り返して フレーム議論になってるだけ 時間の無駄でしかない >>313 お前の書き込み、同じ話を何回も繰り返す念仏が多過ぎる お前以外の人は、既に内容を把握した話を何回も繰り返す 偏執狂には興味がないからいい加減にしたら 宗教とか入れば、同じ話を何回でも繰り返せるから 向いてるんじゃね この手の人って人間関係が オタクバトル系オンリーなんだろうね 他の人は喧嘩腰の会話を嫌って水を向けているのに 本人はオタクバトル仲間ができたと思って 同じ話を何回も繰り返す それって中高生のメンタルだよな >>315 じゃあリファレンスカウンタなんて必要なくてもヒープで確保したメモリの自動解放ができる仕組みを ようやく理解できたということかね? それならばよろしい オタクが嫌われる理由 ・ちょっと話しかけると 際限なく信仰話を続ける ・リファレンスを出せと言われると 知ってて当たり前だから出す必要が無い という信仰コミュニティの価値観を振り回す ・それでもリファレンスを出させて そこに何と書かれているか 原理と書かれているのかイディオムと書かれているのか 質問してやると答えられなくなってしまう ・テンパった末に長時間主張していた話を 全部ひっくり返して破産状態のまま それでも会話を続けようとする 病人だわな というわけでおしまい 原理かイディオムか答えなかった時点で失格 意外と面倒見てる自覚があるけどw まあバトル系の人にとっては敗残記録になるんだろうな 信仰の一つのリファレンスを出さされて 信仰の間違いを指摘されたのだから >>258 ローカルな閉じたアプリなんでしょ。 業務ならDBやネットワーク、ファイル等にアクセス しまくる。 データの有無や内容不正の方が 圧倒的に多い。 メモリが原因なんてまず無い。 あったら仕事にならないわ。 バカがいて突っ込んだけどバカだからしつこく絡まれたって感じか よくあること あと気になったのはつまらない虚言を強弁する癖 虚言を弄さず誠実に答えれば会話が進むのに 思い込みで強弁と虚言を繰り返して それは一目見て矛盾に気づくレベルの虚言だから 近付いてもメリットがないと一目でわかってしまう 普通は発言を吟味しないと虚言に気付かないくらい 繊細な虚言をするもんだけど この人は最初から喧嘩腰のバトルモードだから 不要に目立つ虚言が齟齬を発生して 手口がバレてしまう メモリ解放ってやったことないわ そこまでメモリ使わんわな パソコン触ったことなさそう あれ?Cもgccなら今はstack protectorデフォでつけられなかったっけ? 言語仕様の話? >>247 >オブジェクトの自動開放にはGC以外にリファレンスカウントという方式があって、オブジェクト型のポインタ参照が追加されるたびに+1、ポインタ参照が廃棄されるたびに-1して、ゼロになったら廃棄する。ただしその方法も実行時に余分なオーバーヘッドは起きる。 参照カウントはそもそもGCだよ JavaなどのGCという広義の意味としても、世代の低いものには参照カウントは積極的に使われてる もうこの説明の時点でこいつがマウントしかできない ろくに仕様や実務知らない奴なのがわかる ちうか仮にもCS出身名乗るならググって出てきた素人の説明そのまま引用すんなよな… Mark and Sweepぐらいサラッと出てくんだろ JVMのメモリモデルまで突っ込んでる話してるし >>246 こいつもそうかGC無しでとか言ってるし >>331 その通りでGCの実現方法としてトレーシング方式とリファレンスカウンタ方式があるのだけど ここで話は少し複雑でリファレンスカウンタを使っていても実は2種類に分かれる ・1つはGC実行時にリファレンスカウンタがゼロのものをまとめて『回収』し、トレーシング方式と同様にこのGCを時々行なう ・もう1つはリファレンスカウンタがゼロになった瞬間に即座に『解放』してしまう 後者はまさにCでの手動freeやC++でのunique_ptrでの自動解放やRustでの自動解放と同じタイミングで即座に行なわれるためガベージコレクションとはみなさないことが多い その方式を取る言語としてSwiftがあり、C++のshared_ptrやRustのRcも同じであり、いずれもGCとはみなされていない こういう昼間っから喧嘩腰の人専門板に多い 特にpc関連とかプログラマーとか 以前にスマホの初心者が質問するスレでiPhone使いだけどこういう疑問があって質問したいけど って言ったら即レスでiPhone使いは頭悪いとかそれに同調するような意見ばっかで結局質問に答える人いなかった それもこのスレみたいに平日の真っ昼間に 結局知人に聞いて解決したけどなんか引っかかる部分というか哀れに感じた 質問の仕方が悪かったのかもしれんけどそれ以前にiPhoneだからとかで区別してるのは確実にオッさんだしこいつらなんだよって感じで余計哀れに思ったや まずこの手の議論をする前に競技プログラミングのランクをお互いに示して 戦闘力を見せ合ったうえで議論すれば良いと思う Rustはどっちかというとメモリ管理しやすいというより全く逆の発想で スタックに積みスコープを限定しライフタイムを圧縮し 一意型に似た方式を使いヒープ確保すらもRcなどで利用するのも本来邪道なようにして メモリ管理を極力減らすことでバグ出さないようにできるのが売り そして>>266 も完全に勘違いしてるね これは所有権移転できる時点で>>263 のが正しいし 何よりRAIIは初期化時の確保と解放の責任先の話であって メモリの解放点が初期化した文脈でのスタックやスコープで決まるなんて話では全くないです PHPしか使えない底辺ウェブプログラマだからヒープだの言われてもわからんわ >>337 補足しておくとなんで参照カウント1のが正しいと言ってるかというと moveセマンティクスによる移動がその動作そのものだから 本当に本来の意味で一意=uniqueを示すなら最適化によるeliminationをいちいち期待するまでもなく そのmoveのコードすらいらない Rustはそういう意味では単なる参照カウント1からは少し脱却してるけど再使用の禁止はできないから一意型には足りない >>334 見なされてないは単なる詭弁でしかない 普通に参照カウント方式というGC タイミングが違うだけ >>337 いいえ Rustで所有権が移動していくのはその通りですが 最後に所有権を保持している変数がRAIIによって尽きるときにstd::ptr::drop_in_placeすなわちデストラクタが呼ばれることで 最終的なメモリ解放が行われます >>340 全然ちがいます ガベージコレクション(GC)はその名の通り溜まったゴミをまとめて回収します しかしshared_ptrやRcではゴミは溜まりませんし、まとめて回収されることもありません GCとみなされないことが多いのはそのためです 嫌儲にプログラムモメン(土方モメン)が多いのはこの仕事が過酷な証なんやろなあ 働きぶりを見てもジャアアアや終わりだよ言いたくなるのもわかるわ >>342 なんかしょうもない話になってきたな… それ完全に思い込みだよ 会話終わらせるためにまず結論から押し付けるけどRefCountがGcでない派は普通にマイナー https://twitter.com/imos/status/818835251011076096 なぜ君と違ってそう考えてる人がこれだけ多いのかというとCS領域ではGC扱いとなってるから copygcみたいに特別な処理がないならGCじゃないと思ってるなら完全に勘違いでネイティブ言語のGCライブラリはまさにRcの方式だった https://twitter.com/5chan_nel (5ch newer account) >>341 それはこちらの説明を少し詳しく書いただけで何の反論にもなってない RAIIはまとまって解放し管理を楽にするだけで 君の反論した文脈には関係がない メモリ管理におけるオブジェクト解放の起点それそのものはRAIIではない >>344 ちゃんと>>334 の区別説明を読みましょう リファレンスカウンタ方式のガベージコレクションはもちろんあります それとは別にリファレンスカウンタ方式の即時メモリ解放もあるだけです そのアンケートはその二つを区別していないから全く意味がありません なんかRAIIがscoped_ptrみたいなのと一緒に語られるから意味を勘違いしてる人めっちゃ多いけど 本来これはオブジェクトの内包するリソースを外から初期化解放させる行儀の悪いものを正す話だから全く別 たまたまscoped_ptrやrefcountのメモリ管理に使いやすく目的と合致しただけ >>346 読みましょうじゃなくて普通にGCだから gcにまるで別スレッドや別コンテキストである必要性を勝手に要件にしてはいけないよ >>346 それとアンケートもはんろんになってないよ 反対側のがmark and sweepと区別ついてないのが多いだろうしね >>45 全く意味がわかってない ChatGPTはアホや >>345 全て間違ってますよ RAIIはまとまって解放しません RAIIは尽きたものだけが、そのタイミングでデストラクタ発動となり解放となります そしてRAIIの機構がない言語(例えばC)ではメモリ自動解放を実現できません >>341 の通りです heapエラーはJavaの流れをくんだApexでも割と出ますね どっちにも言えるけど優秀なエンジニアって知識欲があるわけ 知らないことを聞いたら反発じゃなく「そうなんだ!」って嬉しくならないやつはエンジニアに向いてない つまりその視点で会話を見るとどっちもエンジニアとして大したことないなってのがわかる 平日昼間の固執してるのも謎 今はリモートワーカー増えてるからサボってるぞ https://www.eidos.ic.i.u-tokyo.ac.jp/ ~tau/lecture/programming_languages/gen/slides/pdf/06-gc.pdf#page21 これの21ページ見りゃわかるけど CS領域の人は普通にreference countingはgcって考えてるんだよ ただJavaが出てmark and sweepがメジャーになってからそれがGCだと思う人らが増えてしまったのでそう考える奴がいる事は否定しない ただ真面目に勉強してるならちゃんと考え改めなさいね >>351 一応言っておくけどC言語でもOOPとして書いてるなら普通に可能 RAIIは初期化と解放の責任の概念だから >>356 いいえ違います 例えばRustはRAIIですがクラスはありません ガチガチの組み込みやだったが、ヒープのエラーとか出るんか。 どんなクソソフト作ったらでるのか聞いてみたいもんだ 2人とも気が合ってるな そして毎日嫌な思いをしてそう >>357 いいえ C言語はRAIIではないためリソースの自動解放は無理です したがってメモリ自動解放も無理です >>358 また詭弁かよアホくさ C++から発生した概念なので関係ないはありえない ただ実現にはクラスそのものは必要ないというだけ そしてお前さんはスコープや参照カウントをセットに考えてる時点で完全に勘違いしてる 一応こっちもちゃんと説明するけどさ 解放の起点はスコープ抜けた時のコンパイラのライフタイム制御だからね? やってるのはコンパイラであってRAIIの機構ではない RAIIはあくまでその起点から自らの内包するリソースを解放するという機構なだけ >>361 自動解放はRAIIの話ではない リソースの初期化と解放の責任をクラスの概念にしただけ 完全に勘違いしてる そもそも概念の話抜きにするなら 厳密な意味でのRAIIはイディオムなんだからC++と同等な機構以外じゃ無理だよ クラスでリソース管理するって概念なんだから RustでRAIIは伝えたい意味は通じなくないけど 厳密に言ったらPimpleをRustでやってるとか言ってるぐらい意味不明な文面 >>362 珍しくこの部分だけは合ってる 「RAIIはあくまでその起点から自らの内包するリソースを解放するという機構なだけ」 そこを分かっているなら後はunique_ptrの仕組みを理解すれば RAIIによってメモリ自動解放されることが分かるし RAIIがないC言語ではメモリ自動解放できないことも分かるはず そしてクラスは無くともRAIIがあるRustではメモリ自動解放できることも分かるはず あともうちょっとだから頑張れ >>178 もうこのお約束キーワードとお約束の話の持っていき方が出てくる時点で こいつがa_watcherくんだって事がわかる ほらほら山形大学ガー天羽ガーっていつもみたいに鳴いてみせろよw >>365 クラスは一切関係ない クラスがないRustにもデストラクタはある そしてリソースを使用終えた状態になった時に自動的にデストラクタが呼ばれればRAIIは成立する >>364 いや、文系がプログラマーやるとこうなるというだけ。 >>367 それはRAIIの自動解放ではなく スコープによる破棄や参照カウントが自動開放なだけだよ 詭弁もここまでくるとすごいな お前の論理を援用するならコンストラクトとかデストラクタをマニュアルで呼んだらRAIIじゃないって事になっちまうよw 本当知ったかだけで強弁してるくせに傲慢な奴だな Rustもほとんど知ったかぶりしてんだろな >>369 自動かどうかが関係ねえんだよw マジで頭おかしいなお前 >>367 つかこの文面見てるとmoveセマンティクスすら理解してねえなこいつ 本当知ったかだらけ >>371 思い込みばかりで投稿するのはやめて少しは調べなさい Rust公式でもRAIIだと明記しているし 第三者であるWikipediaでもRAIIのページにはRustとあり、RustのページにはRAIIとある あなたが完全に間違っていますよ >>373 moveは所有権すなわち解放義務が移動するたけであってRAIIの枠組みとは全く別の独立した話ですよ まずはちゃんと勉強したほうがいいですよ 最終的に所有権を持つローカル変数がRAIIにより消滅するときに デストラクタが呼ばれることでメモリ解放されます C++ならばunique_ptrのデストラクタがそれを担います Rustならば各型のデストラクタが担います >>374 まずRust公式のRAIIの説明にそもそも自動解放なんて含意ないよこれ ただこの文面お前が勘違いしちゃったのもわかるわ >so whenever an object goes out of scope, its destructor is called and its owned resources are freed. スコープと一緒に内包したリソースも開放されますって説明したらスコープによる解放がRAIIって思っちゃうもんね あくまで解放の起点になるのは変数部分の話なのに そしてまだ勘違いしてるけど俺はそもそもRustがRAIIじゃないって言ってるわけでもない クラスを使わない広義のRAII(Cなどでも通用する)ならわかるから それを否定するならRustもRAIIではない >>375 お前からunique_ptrの話してんのになんでもRAIIの文脈だと思ってる時点でお前が勉強不足だよマヌケw つかここまで説明してやってんのに俺を初心者扱いする事でしかプライド保てないって情けないと思わんの? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる