C++は難しすぎ 難易度:2

1 名前：前々スレ985 mailto:sage [03/12/18 06:52] 理解できないわけないだろ！ デザパタも知らずにC++使いの質を下げるC厨には げんあり 前スレ達 難易度:1 pc2.2ch.net/tech/kako/1058/10586/1058675178.html 難易度:2 1pc2.2ch.net/test/read.cgi/tech/1063323615/ 313 名前：デフォルトの名無しさん mailto:sage [04/09/03 12:27] Loki を理解するよりも、STL のソースを読むほうが難しいと思う。 314 名前：デフォルトの名無しさん mailto:sage [04/09/03 13:54] 実装によるだろ（ｒｙ 315 名前：デフォルトの名無しさん mailto:sage [04/09/04 23:55] >>313 じゃあ、M$版の奴。 316 名前：デフォルトの名無しさん [04/09/06 13:52] C++使えると豪語する奴=本当はCしかできない低脳 pc5.2ch.net/test/read.cgi/prog/1094445966/ 317 名前：デフォルトの名無しさん mailto:sage [04/09/06 22:56] 漏れはC++よりもVBが難しい 318 名前：デフォルトの名無しさん [04/09/08 11:03] C#やっとけ。嫌ならDやっとけ。嫌なら(ry 319 名前：Ruby!! mailto:Ruby!! [04/09/08 17:09] Ruby!!!!!!!!!!!!! 320 名前：デフォルトの名無しさん mailto:sage [04/09/08 19:10] C++って使いどころがない。 for_eachとかいつ使うんだこんなの、forの劣化版でしかない。 321 名前：デフォルトの名無しさん mailto:sage [04/09/08 20:10] 例の「ほげ言語のパラドックス」の意味がよくわかるねｗ 322 名前：デフォルトの名無しさん [04/09/08 22:51] >>302 inline 323 名前：デフォルトの名無しさん [04/09/08 23:25] >>320 お前、あれだろ。車を「こんなの地球温暖化の原因になるだろ」って難癖つけて 乗らないだろ。 324 名前：デフォルトの名無しさん [04/09/08 23:44] 車と地球温暖化って？ なに言っての、このボンクラ どこかで聞きかじったのかしらん？ｗ 325 名前：デフォルトの名無しさん [04/09/09 00:47] 車と地球温暖化の二つの単語から 「聞きかじった」とかいう発想が出てくるのが凄いｗ 「なに言っての」のあたりといい、かなり必死なようで。 理由はわからんが。げらげら 326 名前：デフォルトの名無しさん [04/09/09 01:29] ↑またまた新手の厨が出現ｗ 327 名前：デフォルトの名無しさん [04/09/09 01:30] >>325ってきっと、偉そうなこと言っときながら、GUIなPCしか触ったことないんでしょうね。 DOS時代を知らないんだな、こういう香具師。 328 名前：デフォルトの名無しさん [04/09/09 02:02] 悔しいからって二つも書かなくていいぞ、324ｗ 329 名前：デフォルトの名無しさん mailto:sage [04/09/09 03:01] C++は使いまくりだろ。俺はCの方がよく使うけど。 一番使うとこがないのはRubyとJava。 330 名前：デフォルトの名無しさん mailto:sage [04/09/09 03:35] 言うまでも無いけど、仕事によって使用頻度が違ってくるからなあ。 普通は使わない言語の方が多いだろ。 逆に、まんべんなく使用するとなったら、それ部署たらいまわしにさ（ｒｙ 331 名前：デフォルトの名無しさん [04/09/10 22:07:23] Java言語仕様も包含してC+++ つーのはどう？ えーい、こうなったら、VBやDelphiも許してしまう てんこもり言語「C+++++」のお出ましだ！ ・・・もうマニアしか使えねぇな 332 名前：デフォルトの名無しさん mailto:sage [04/09/10 22:21:24] class C+++++: public C++, public Java, public VB, public Delphi, protected C#; 333 名前：デフォルトの名無しさん [04/09/10 22:26:06] 最強言語Ruby!!!!!!!!!!!!!!! 334 名前：デフォルトの名無しさん mailto:sage [04/09/10 22:46:31] class 最強言語: public C+++++, private Ruby; 335 名前：デフォルトの名無しさん [04/09/11 13:34:55] >>332-334 　 (ﾟДﾟ );;; ＜ｽｹﾞｪ・・・ 336 名前：デフォルトの名無しさん mailto:sage [04/09/11 13:39:36] private Rubyという言葉に笑った。 言いえて妙 337 名前：デフォルトの名無しさん mailto:sage [04/09/11 14:07:08] C++って、何でもできるのがいいよね。 ビットフィールドとか共用体をCから引き継いでるから エンベディッドのきつい環境でも、メモリを節約しつつ ある程度見やすく書けるし。 メンバ関数ポインタを配列に突っ込んだりやりたい放題。 一人で組むんなら最高の言語だよ。 338 名前：デフォルトの名無しさん mailto:sage [04/09/11 15:32:40] >>337 >一人で組むんなら 人数が何か関係してるのか？ 339 名前：デフォルトの名無しさん mailto:sage [04/09/11 19:22:16] >>338 多人数で組むなら、あんまりトリッキーなコードは書けないじゃん。 それならJavaでも大差ない。 340 名前：デフォルトの名無しさん [04/09/12 00:43:44] 俺、最近<boost/preprocessor.hpp>の利用による繰り返し処理を勉強中何だけど もしかして、これって、perlなどの言語でちょちょいと書いて、出力して、コピペ したほが可読性の面からもいいんじゃないかと気づいてしまったんだけど まだまだ理解が足りないというかとなのかな。 341 名前：デフォルトの名無しさん [04/09/12 01:32:06] C++ってそんなに難しいか？ STLが超便利でCなんてやってらんない体になってしまった 342 名前：デフォルトの名無しさん mailto:sage [04/09/12 02:08:55] >>341 幸せな時期だね。 343 名前：デフォルトの名無しさん [04/09/12 05:17:05] 286上のQuick C、MASMの時代からC、C++一筋で趣味、仕事でやってきて 他の言語はいらないとまじめに思ってたんだが・・・最近、C#をCつながりで やってみるかと覗いてみたら・・・もうC++の時代は終わりかもしれんな。 C++を身につけた人間があえて乗り換える必要はないが、新人にC++を教えたり 薦めたりする気はなくなったよ。これからやる人はC#やった方が良いな。 .NET→WinFXと進んでいこうとするならなおさらだな。 344 名前：デフォルトの名無しさん [04/09/12 05:55:31] www.square-enix.co.jp/shop/goods/images/series_cre4_06.gif 小さすぎて見えんがな('Д`) 112 名前：名前が無い＠ただの名無しのようだ ：04/09/09 21:07 ID:s4msPAUO www.ffcompendium.com/EspMon/necron9-b.jpg www.ffcompendium.com/EspMon/necron9-a.jpg 345 名前：デフォルトの名無しさん [04/09/12 17:33:17] >>343 C#は絶対にC＋＋は超えらんないと思うよ C#って実質Windowsでしかつかえねーじゃん WindowsでもDLL内の関数なりクラスを使うとなると 面倒だし・・・ 挙げだすと枚挙に暇がない WindowsではVC++&MFCこれ最強 ま　ち　が　い　な　い！ 346 名前：デフォルトの名無しさん mailto:sage [04/09/12 18:51:02] オトトイ、キ・ヤ・ガ・レ！ 347 名前：デフォルトの名無しさん [04/09/12 19:26:19] Windows + C言語のみでMFCも使わずWin32APIネイティブ。 自分でWinProcからMSGをディスパッチしる！　＜これ最強。 348 名前：デフォルトの名無しさん mailto:sage [04/09/12 20:10:59] >>345 > C#は絶対にC＋＋は超えらんないと思うよ それはそうなんだ、言語の汎用性という意味からするとあなたの言ってる事は 非常に正しいんだ。 > C#って実質Windowsでしかつかえねーじゃん これもまさしくそうなんだ。 でも、仕事って、まぁ俺の場合はそうなんだけど、９割方Win絡みなんだよね。 でもって、次の世代のWindowsが06年に出るかどうかは別として何時か、近い 将来は必ず出るんだよね。で、そのWindowsからはWin32Apiはネイティブじゃなくて WinFXでエミュレートされるんだよね。となると、これから始める人があえてwin32api に精通する必要はなくなるんだよなぁ。むしろ、今は.NETのクラスライブラリの使い方 に精通した方が良いと言える。 > WindowsではVC++&MFCこれ最強 > ま　ち　が　い　な　い！ 現行ではね。Win32Apiがその存在意義を失うであろう、ここ２〜３年の間わって話し だよな。OSのネイティブAPIがWinFXのクラスライブラリになれば話しはがらっと変わるよ。 まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み 拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを 1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒 要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。 ただ、間口を広げるという観点からは他のプラットフォームでも使えるC&C++を知っとく ってのは悪くないとは思うけどね。 349 名前：デフォルトの名無しさん [04/09/12 21:27:02] じゃあ、その画像処理処理コードをC++で書き直してみたら？ C#がC++を凌げない答えがそこにあるから。 350 名前：デフォルトの名無しさん mailto:sage [04/09/12 21:27:08] >>348 > まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み > 拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを > 1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒 > 要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。 ま、まじっすかそれ？ 351 名前：デフォルトの名無しさん mailto:sage [04/09/12 21:52:58] >>349 やりましたよ。C++だと.3秒で終わりました。テスト用に作ってる 画像処理用ライブラリなんですけどね。巨大なサイズのビットマップを 読み込んでフィルタ処理するって奴です。 現行だとC++の方が10倍程速いですね。しかしですね、ここが大きな問題 なんですが、C#でもbitmapクラスを使わずにそのままメモリに展開して ポインタ使ってアクセスすると.4秒程度で終わってしまうんですね。ファイル 読み込みにはもちろん.NETのクラスライブラリを使用してます。 個人的にはC#でunsafeなコードを書くのは邪道だとは思うんですが、やろうと 思えば問題ないって話ですね。dll呼び出しするほど手間でもないですし。 インラインアセンブラ使うような感じですね。となると話しはややこしくなってきます。 C#に対するC++の現行での利点は、 ・ポインタを駆使出来る。 ・win32apiへのアクセスが容易である。 ・ネイティブコードを吐ける。 とまぁ既存のライブラリ資産の問題を抜きにすればこんなところです。後ろの２つは ここ２〜３年で利点でもなんでもなくなってしまう訳です。で、１つ目に関してもボトル ネックとなるような肝い部分ではC#でも問題なく使用出来る、となればほとんど差は なくなってしまうんですね。やはり考え込んでしまいますね。ただ、プロジェクトの規模 が非常に大きくなってきた時のGCの挙動というのがどの程度パフォーマンスに影響を 与えるのか現時点では読めません。コードでの工夫のしようはありますが、最終的には VM任せですから。まぁこのあたりもMSが最適化していくような気はしますが。 一つはっきりしときたいのは私はC++を否定するつもりは毛頭ありません。ただ、スレタイ にもあるとおり「C++は難しすぎ」と感じる人がいるのだとすれば無理して今から覚える 必要は、Win上での開発を念頭に置いているのなら、ないんじゃないかなと思っただけです。 >>350 ほんとです。ソースはそのままコンパイルやり直しただけでその程度のパフォーマンスの 向上が見られました。βがとれた時はそれなりに期待しても良いのかなという気にはなり ましたね。 352 名前：デフォルトの名無しさん [04/09/12 22:14:50] 俺はc#がVBSのような運命を辿るような気がして成らないんだけど・・・ 353 名前：デフォルトの名無しさん mailto:sage [04/09/12 23:16:22] > C#に対するC++の現行での利点は、 > ・ポインタを駆使出来る。 > ・win32apiへのアクセスが容易である。 > ・ネイティブコードを吐ける。 C#はどれもできるぞう。 ところで、最初のはあんまりうれしくないなあ。 354 名前：デフォルトの名無しさん [04/09/12 23:23:24] Ｒｕｂｙ最強言語 Ｒｕｂｙ！！！！！ Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Ｃω 355 名前：デフォルトの名無しさん mailto:sage [04/09/12 23:59:55] >>353 脊髄反射？ ポインタ使える事は >>351 も知ってるようだぞ？ ポインタは確かにアレなんだけど、本流になるには絶対必要だと思うね・・・残念ながら。 Native 呼び出しはモノによっては結構面倒。単にアクセスの容易さだけなら C++ のが当然上だよ。 確かに普通の Win32 API はそれほど面倒なのに突き当たった事はないけど、 COM だとラッパー作るのが大変なの多いね。TLB とか無い場合は。 もちろん JNI みたいなのよりは全然マシだけど。 それから、C# で直接ネイティブコードは吐けないんじゃない？ インストールしたマシン上で変換はできるけど。 356 名前：デフォルトの名無しさん mailto:sage [04/09/13 00:10:56] まぁ何にせよ楽なのはC#だわな。 別に両方使えれば問題ないさね。適材適所。 357 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:36:37] >>355 本流ってよくわからんが、洗練されたC++コードにはポインタは登場しないよ。 ポインタが飛び交うなら、それはC++の顔をしたCだと思う。 358 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:38:54] っつうか355みたいなのは若い（よね？）ならいいけど 年くってたらヤバいと思いなされ。 359 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:47:40] >>358 何か言いたいならはっきり言えよ 360 名前：デフォルトの名無しさん [04/09/13 02:06:50] >>357 それはおまいがC++が書けないからだよ　ｗ 361 名前：デフォルトの名無しさん mailto:sage [04/09/13 02:13:48] >>357 すまん。自分はポインタつかいまくり。 スタックに積むオブジェクトとヒープに確保する オブジェクトは明確に区別している。 それでヒープに確保するためのオブジェクトはどうしても ポインタになる。スマートポインタはつかっているけど 生のポインタのほうが適切だと思う場所もあるので それで生のポインタをつかっている。 362 名前：デフォルトの名無しさん mailto:sage [04/09/13 09:04:59] >>361 > 生のポインタのほうが適切だと思う場所もあるので そういう場所がほとんどなくなるのが、最近のC++のやりかただと思うのよ。 特殊な例を特長なんかにしないほうがいいよ。 363 名前：デフォルトの名無しさん mailto:sage [04/09/13 14:18:22] >>362 どうやって？ 364 名前：361 [04/09/13 16:54:41] 自分の場合、ヒープに確保するタイプのインスタンスは 以下のような管理の使い分けをしている。 (依存、関連、集約、コンポジションぐらいは理解しているよね) [依存] ケース1 : あるメソッドローカルでつかわれるインスタンスで メソッドをぬけるとインスタンスが不要になる場合。 auto_ptrかscoped_ptrをつかう。 ケース2 : あるメソッドの引数として渡されるインスタンス。 渡されたインスタンスはそのメソッドの中でしかつかわれない。 この場合は生ポインタ。理由はインスタンスの寿命にメソッドは 関知しないためスマートポインタにする意味がない。 [単項関連] ケース1 : 格納するクラスがインスタンスの寿命の管理をしないといけない場合。 この場合はauto_ptrかscoped_ptrかshared_ptr。 ケース2 : 格納するクラスがインスタンスの寿命に関知しない場合。 この場合は生ポインタかweak_ptr。 365 名前：361 [04/09/13 16:55:34] [集約] 基本的な方針は単項関連と同じ。集約のコンテナにはSTLコンテナ をつかい、スマートポインタをつかう場合にはshared_ptr (これじゃないとコンテナに格納できないから)をつかう。 [コンポジション] 問答無用にSTLコンテナ+shared_ptr。 こんな感じ。依存のケース2のような場合はスマートポインタを つかう意味がないし、別に特別なケースでもなくてよくあるんだけど。 366 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:01:42] 洗練されたC++の流儀とは、boostを使う事だったようです。 最近使えるようになったんでしょうね、うれしくてたまらないみたいです。 367 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:08:53] ↑Boost分かってない香具師の僻みｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!! 368 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:17:20] 標準がしょぼいせいでいろんなもんが乱立する事態になってる 369 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:23:25] なんたらptrとかほにゃららptrとか確かにウザィよね。 ライブラリレベルでやるもんじゃねえよ。 370 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:29:55] >>367 と言う事にしたいのですね。 自分の場合とか言いながら、長々と何を言うかと期待すれば boost入門ページの最初の方に書いてある事を書いてみただけ。 ヤレヤレ そんな事はboostの名前を知ってるような人間は誰でも（活用しているかはともかく）承知している事で、 それでもあえて生ポインタを使っているケースは多々あるのに、それを否定するだけの説得力（代案）が 先の文章には無い。 371 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:37:11] とりあえず否定だけしてみて自分の意見は無い香具師ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!! 372 名前：361 [04/09/13 17:44:29] だからスマートポインタ最大限に利用したとしても 生ポインタをつかうケースがあるって例をあげてみた んだけど。 >そんな事はboostの名前を知ってるような人間は誰でも >（活用しているかはともかく）承知している事で、 >それでもあえて生ポインタを使っているケースは多々あるのに、 >それを否定するだけの説得力（代案）が先の文章には無い。 361の発言みれって。自分も生ポインタつかいまくりだって。 373 名前：デフォルトの名無しさん mailto:sage [04/09/13 18:01:12] >>372 使いまくったらダメだろｗ 374 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:56:19] >>364 依存のケース２で生ポインタ使ってるところは参照が適切だと思うが、いかがか？ 375 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:58:55] 話の途中で悪いが、今の「ポインタを使いまくる」の意味は、 自力でnew/deleteしまくるって意味だよな？ 376 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:59:47] >>375 ちがうだろう。 377 名前：デフォルトの名無しさん [04/09/14 00:59:58] void******** (********a)(void******** (********)(void********)); なんて普通に使ってますが、何か？ 378 名前：361 mailto:sage [04/09/14 01:19:12] >>374 ヒープに確保するオブジェクト限定の話なので、生ポインタです。 個人的にヒープに確保したインスタンスの参照をとるのは 抵抗があるかな。 たしかにスタックに積むオブジェクトや構造体ならむしろ参照の ほうが望ましいと思います。 379 名前：デフォルトの名無しさん mailto:sage [04/09/14 01:49:54] >>378 その抵抗には何か根拠がある？ まるで意味の無い区別だと思うが。 ヒープ上の（動的）オブジェクトを引数に取る関数と スタック上の（自動）オブジェクトを引数に取る関数とで オーバーロードでもするつもりか？ 380 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:44:40] いつのまにかスレタイに沿った話題になってる 381 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:47:18] >>375 「生の」な。 生のポインタを渡したり、受け取ったり、コピーしたり、 インクリメントしたり、引き算したり、足し算したりすることかなあ。 そういうCみたいなコードはさすがにメンテするのも疲れる。 382 名前：デフォルトの名無しさん [04/09/14 02:48:46] それはおまいが`使えない'香具師だからだYo 383 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:50:29] む、「Cみたいな」は禁句か？ 384 名前：デフォルトの名無しさん [04/09/14 04:32:03] >>382 話についていけないお馬鹿さんが 無視して書き込まなくてもいいのでは? ;-) 385 名前：デフォルトの名無しさん [04/09/14 05:22:30] 無視して書き込む? ;-) 386 名前：デフォルトの名無しさん mailto:sage [04/09/14 07:03:25] つーかね、 システムコールがiteratorに移行しない以上、 ポインタ（アドレス渡し）は永遠に不滅です。 387 名前：デフォルトの名無しさん mailto:sage [04/09/14 09:05:47] システムコールなんてwrapされる最たるもんだろ 主パスの処理にシステムコールが出てきたりするなら、C以前だなそりゃ 388 名前：361 [04/09/14 09:53:58] >>379 設計の段階でヒープに確保するオブジェクトとスタックに積む オブジェクトは「明確に区別している」ので、同じクラスの インスタンスがヒープに確保されたりスタック積んだりとまちまちに なることはないので、オーバーロードする必要はない。 クラスによってヒープに確保かスタックに積むかが決定している。 ヒープに確保するオブジェクトの例をあげればポリフォーリズムが 必要なクラス、スタックに積むクラスは通貨型やベクトル型、 複素数型、クォーターニオンなど。 C++ではオブジェクトをヒープで確保することを強制できないので とりあえずコピーコンストラクタや代入演算子をprivate属性に するぐらいはやっているが、最終的にはドキュメントに書いている。 Compositeパターンのように子ノードの削除の責任が親ノードにある 場合、delete演算子かスマートポインタで破棄するんですが、 これがスタックにつまれていると親ノードの都合で削除できない ので問題になる。こういうのは仕様できっちりきめるしか 回避方法がないのはC++の欠点だと思っている。 ...というか、こういうガイドラインって一般的ではないのかな。 とりあえずつかいわけとしてはC#の値型と参照型に近い 感じなんですが。 389 名前：デフォルトの名無しさん mailto:sage [04/09/14 10:15:27] >>388 > 設計の段階でヒープに確保するオブジェクトとスタックに積む > オブジェクトは「明確に区別している」ので、同じクラスの クラスを使う側のローカルな操作なら自分の決定を前提とできるだろうけど、 クラスや関連関数を提供する側では、どちらに確保されるかと言う前提は持てないだろう。 > ヒープに確保するオブジェクトの例をあげればポリフォーリズムが "polymorphism" な。 > C++ではオブジェクトをヒープで確保することを強制できないので コンストラクタを protected にして、ヒープに確保するstaticな 生成関数を用意すればできるよ。 > これがスタックにつまれていると親ノードの都合で削除できない > ので問題になる。こういうのは仕様できっちりきめるしか > 回避方法がないのはC++の欠点だと思っている。 他の言語なら仕様でキッチリ決めないで回避できるの？ > ...というか、こういうガイドラインって一般的ではないのかな。 > とりあえずつかいわけとしてはC#の値型と参照型に近い C#は詳しくないけど、それを表したいなら、 　C#:値型 → C++:メンバを並べたクラス型 　C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型 こんな感じの対応付けにならないか？ 390 名前：361 [04/09/14 10:40:07] >"polymorphism" な。 すんまそん。typoです。マジで恥ずかしい。 >コンストラクタを protected にして、ヒープに確保するstaticな >生成関数を用意すればできるよ。 そういえばそうだった。忘れていました。 C#だと構造体は必ずスタックにつまれる(ボキシングするとヒープに 移るけど)し、クラスはヒープに確保される。まあC#の場合はも ともとGCがあるからインスタンスの破棄のことは考えなくていいんだけど。 391 名前：361 [04/09/14 11:13:37] >C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型 これって俗にいうHandle-Bodyだよね。これも設計ポリシーによってはアリですね。 昔の(今は知らん)xerces-cもそうだったような覚えがある。 392 名前：デフォルトの名無しさん mailto:sage [04/09/14 14:17:40] 横槍ですが... >>388 >Compositeパターンのように子ノードの削除の責任が親ノードに >ある場合 むしろ私の場合は、Compositeパターンによる関連性と寿命管理を 分離する設計が殆どです。Compositeパターンにより関連付けられた オブジェクト群を利用するオブジェクトと同じ寿命を持った オブジェクトを用意し、それに保持させるって感じです。 そういった意味では、ライブラリがクライアントの用意するオブジェクト の寿命を管理する設計よりも、ライブラリはあくまでもそのオブジェクト間の 関連性だけを利用するようにし、その関連性の利用期間を外部に通知できる ようなインターフェースを用意します。オブジェクトの寿命が本質的に あいまいな場合のみshared_ptrを使いますが、稀なような気がします。 393 名前：361 [04/09/14 14:48:48] >むしろ私の場合は、Compositeパターンによる関連性と寿命管理を >分離する設計が殆どです。Compositeパターンにより関連付けられた >オブジェクト群を利用するオブジェクトと同じ寿命を持った >オブジェクトを用意し、それに保持させるって感じです イメージとしてはFlyweightのようなオブジェクトプールを つかうって感じでしょうか?ちがったらすみません。 一応、GoFの本を確認したところ「component を削除するのは誰か」 という段落で「通常は親ノードが子ノードを削除するのが最もよい」 とは書いてありますが、そうでなければいけないとは書いてないですし、 例外のケースもあげられています。 >あいまいな場合のみshared_ptrを使いますが、稀なような気がします。 個人的にもshared_ptrをガーベージコレクションのかわりに つかうことは殆どないです。thisポインタ問題(shred_ptrの thisポインタはスマートポインタで管理されていない。 一応回避策はありますが)や循環参照でメモリリークが 発生したりするので意外とつかいにくいです。むしろ コンテナに入れることができる唯一のスマートポインタ というつかいかたが多いです。 クライアントが生成したインスタンスをライブラリ側で 寿命を管理する必要があるかどうかは議論の余地がありますね。 394 名前：デフォルトの名無しさん mailto:sage [04/09/14 14:49:56] とりあえず、俺に責任は無い。 395 名前：デフォルトの名無しさん mailto:sage [04/09/14 23:50:16] C++でポリモーフィズムを使う時って、ヒープに実態確保して、ポインタ使うしかないの？ 396 名前：デフォルトの名無しさん mailto:sage [04/09/14 23:56:41] スタックに確保して参照を使うのもアリです。 397 名前：デフォルトの名無しさん mailto:sage [04/09/15 01:24:57] で、361よ。 > 個人的にヒープに確保したインスタンスの参照をとるのは > 抵抗があるかな。 これは具体的な根拠があるわけじゃない、ってこと？ 398 名前：361 [04/09/15 12:58:23] ヒープに確保したインスタンスを参照にすると削除するときに&演算子で ポインタに戻してやらないといけないのと、スマートポインタをつかう ことも多いので、参照をつかっているところとスマートポインタを つかっているところで表記がまちまちになって好きじゃない。 一貫性のある表記が好きという個人的な好みの問題。でも本当に わざわざヒープに確保したインスタンスを参照にする人って いるの? ポリモーフィズムは別にスタックに確保したオブジェクトでも できるけど、スタックに確保しちゃうとインスタンスの寿命の 管理の自由度が下がる。それにスタックに確保しちゃうと Factoryメソッドのようなメソッド内部で生成したインスタンス をメソッドの外部に提供するときにコピーコンストラクタが 必要になるのでそういうときに困る。例えばオブジェクトが ビットマップのような巨大なデータをもつ場合、コピーコン ストラクトのコストは大きいし、コピーコンストラクタを 書くのが難しいオブジェクトもある。なので必要のない コピーコンストラクタはprivateにして使用禁止にして つかわないようにしている。巨大なデータを持つオブジェクトは 前にもいった人がいるようにHandle-Bodyなんかでもいい (実際にHandle-Bodyをつかっていたり、文字列クラスなんかは CopyOnWriteをつかっている実装も多い)が、自分はHandle-Bodyを つかうスタイルではない。これもスタイルの問題。 399 名前：デフォルトの名無しさん mailto:sage [04/09/15 13:42:11] >>398 どこを縦読みすればいいのですか？ 400 名前：デフォルトの名無しさん [04/09/15 14:16:46] ポリフォーリズムをポリホと略すスレはここです 401 名前：デフォルトの名無しさん mailto:sage [04/09/15 17:20:36] |　　ポリフォーリズム の検索結果のうち 日本語のページ 約 7 件中 1 - 3 件目 (0.54 秒) あるからびっくりだ。 402 名前：デフォルトの名無しさん mailto:sage [04/09/15 19:32:31] 全部同一人物？ 403 名前：初期不良 mailto:sage [04/09/15 21:23:16] >>400 モーフィングとフォーミングを勘違いするなら分かるけど フォーリングと勘違いするというのは飛んでるなと思う。 3カウント入れちゃうよ 404 名前：361=別名ポリホ mailto:sage [04/09/15 21:35:53] だからマジtypoだって...。まだいりじるのか...。 本気で恥ずかしいんだからいじめんなよ。 405 名前：361=別名ポリホ mailto:sage [04/09/15 21:36:44] >>いりじる いじるの間違いだ。またtypo。もう嫌...。 406 名前：デフォルトの名無しさん mailto:sage [04/09/15 21:38:17] ていうか、ポリフォーリズムをモリモｰフィズムと間違えるのって恥ずかしすぎ。 407 名前：デフォルトの名無しさん [04/09/15 22:06:55] イリジウムのことね 408 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:12:54] はずかしすぎ。 アンテナでかすぎ。 409 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:24:30] どうtypoったらそうなるのか分からん 410 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:47:57] typoだけに突っ込んでいる人は、 そうやって話をはぐらかそうとしている 厨房なので無視するべし。 411 名前：374 mailto:sage [04/09/16 00:56:53] >>394 なんか、どちらかに誤解があるようだな。 >>364の [依存]ケース2 で言っていることは、 たとえば「あるメソッド」foo について、 　foo(T*); というふうに引数の型として生ポインタを使うということじゃないの？ それに対して、 　foo(T&); のほうが適切ではないかと言う突っ込みを>>374で入れている。 これは引数の型の話で、確保したインスタンスを 保持するための型は関係ないと思うんだけど、 漏れが>>364を誤読しているの？ 412 名前：374 mailto:sage [04/09/16 00:58:09] レスアンカー間違えた。 >>411 は >>398 宛てね。 413 名前：361=別名ポリホ mailto:sage [04/09/16 08:34:22] >>414 何度も同じようなことを書いてすまんけど、 1.クラス設計時にヒープかスタックか決めている 2.ヒープに確保するオブジェクトは常に(スマートポインタを含めた) ポインタとしてつかいたい 3.参照をつかわないのは参照とポインタが混ざって表記の揺れに なるからという好みの問題 別に参照をつかっちゃまずいっていう決定的な理由はない。 設計ポリシーとしてメソッドの引数は一貫して参照をつかうの であればそれはそれでいいんじゃないでしょうか?っていうか俺が 文句いうことじゃないけど。 逆にちょっと質問。setterのようなあるインスタンスを引数の値とって それをインスタンス変数に保持するメソッドで、かつ削除の権限が そのsetterを持つインスタンスにある場合、これも参照で渡すの? そうだとするとどこかの段階で参照からポインタに変換しないと 削除できないような気がするんですが。それともこの場合は 特別にポインタで渡すんでしょうか?

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef