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/ 266 名前：デフォルトの名無しさん mailto:sage [04/06/26 12:49] 同じく同意しかねる。ただ不満はある。 C++の言語が難しくて聖書のようにあげられる代表的な数冊の本を 読破理解しないと使いこなせないような言語になっちゃうのは 見た目に直感的じゃないからと思う。 267 名前：デフォルトの名無しさん mailto:sage [04/06/26 13:02] でも全体としての言語仕様の大きさはともかく、 すぐ上で挙げられている「テンプレート」や「STL」といった個々の要素に関しては、 習うより慣れろを地で行ってると思うよ。本はリファレンス的に使えばそれで。 268 名前：デフォルトの名無しさん mailto:sage [04/06/26 14:42] C++の難しさは言語仕様よりも使用方法のノウハウの難しさのような気がする 個々はたいした事はないのに組み合わさったときの威力は大きく、それを利用するためだと思う。 template <typename H,typename T> struct TypeList { typedef H head ; typedef T tail ; } ; と書かれれば、これがどんな定義なのかはC++をちょっと知っていれば判るが これをどう活用するのかとなると急に難しくなる。 分りやすい書籍を作るのに従来通りの言語仕様の本とライブラリの本だけでは補えない部分があるのに その部分を上手く解説した本はあまり無い気がする。 269 名前：デフォルトの名無しさん mailto:sage [04/06/26 15:16] >>268 それ、発想が Lisp 的なんよね。 Lisp 知ってる人からすると、そのコードも見ただけで何がしたいかすぐ分かる。 template を使ったメタプログラミングって関数型言語と似てるらしくて、 Lisp 的表現が良く使われる。 270 名前：デフォルトの名無しさん mailto:sage [04/06/26 15:29] 実際のコードは逐次処理的にかいてTypeList等で それらのコードを組み合わせる構造を記述して GenScatterHierarchy等で実際にコードを組み合わせて 実装を生成する。 関数型言語だと構造だけでなく実際に実行されるコードも 関数型っぽく記述しなきゃいけないってのが、慣れてない人間 にとっては厳しい。 そういう意味でC++でのMPっての有難いんだよな。 271 名前：デフォルトの名無しさん mailto:sage [04/06/26 21:29] 馬鹿は馬鹿なりの使い方すればいいし、 頭いい奴は頭いいなりの使い方すればいい ってだけの話なんじゃないの？ 272 名前：デフォルトの名無しさん mailto:sage [04/06/26 21:40] >>271 両者が一緒にいるときはどうしたらいいのでしょう。 273 名前：デフォルトの名無しさん mailto:sage [04/06/26 22:12] 一番はバカにコードを書かせないで頭いいヤツに全部かかせることかな。 そっちの方が早く、優秀なモノが出来るだろう。 274 名前：デフォルトの名無しさん mailto:sage [04/06/26 22:21] 根幹にあたる部分を、頭いい奴にザッと作らせる。 頭悪い奴には、ただひたすらそれを使うか、応用する部分を作らせる。 プログラミングに限った話じゃないがナ。 275 名前：デフォルトの名無しさん mailto:sage [04/06/27 02:40] >>272 ベアプログラミングで鍛えるべし。 勉強するきないやつなら、いじめるべし。 276 名前：デフォルトの名無しさん [04/06/29 15:53] ネタふり C++のグローバル変数初期化タイミングは難しすぎ。 dynamic initilizationなグローバル変数にいたっては main前に呼ばれることすら保証されてない。 dynamic initilizationなグローバル変数の初期化の スレッド安全性とか考えると頭痛くなる。 また、main前の初期化順序もある程度は制御したい。 翻訳単位のモジュール性を向上させる意味でも。 こればっかりはjavaが羨ましいよ...。 277 名前：デフォルトの名無しさん mailto:sage [04/06/29 17:37] グローバル変数使うなよ 278 名前：デフォルトの名無しさん mailto:sage [04/06/29 17:46] データメンバ　≒　グローバル変数 279 名前：デフォルトの名無しさん [04/06/29 17:54] Cをやってきた人はC++が出来ないと嘆く人が多いですよね？ 自分はC++から入ったんでCの理解はさほど困らなかったんですが、 教授でもそういう人が居ますよ。駄文失礼しました。 280 名前：デフォルトの名無しさん mailto:sage [04/06/29 17:57] 出来ないんじゃなくてやる気が無いだけだろ。 CとJavaがあればC++いらないし。 281 名前：デフォルトの名無しさん mailto:sage [04/06/29 19:19] >>279 多い？そんなに聞かないけど。。 プログラムスタイルの違いに始め戸惑うだけじゃない？ 282 名前：デフォルトの名無しさん mailto:sage [04/06/30 00:13] >>281 現場では意外に多いよ。テンプレートや継承を勉強せずにいきなりソース見るから理解できるわけもないんだけど。 283 名前：デフォルトの名無しさん mailto:sage [04/06/30 04:34] >>276 そういうのは処理系依存になる事も多いね #pragma で明示的に指示できる処理系もあるよ 組み込み向けでは、コンパイラメーカーにリクエストだすと機能追加してくれる事もあるし 判り難い標準仕様よりも、そっちに頼っていたりする事が多いです。 284 名前：276 mailto:sage [04/06/30 10:14] >>283 確かに、処理系依存では有るけど・・・。 言語内でそういうのを保証しようとするとstaticなlocal変数とか 利用する羽目になるけど、スレッド安全性とかコストとかの問題も あるし。main先頭でいちいちリソース初期化等の処理を書くってのも モジュール性の観点から考えるといまいちな気がするしなぁ。 285 名前：デフォルトの名無しさん mailto:sage [04/07/02 00:35] >>279 C++よりもCのほうが難しいだろう。 C++なら簡単にできたことがCだといくつかの要素に還元せねばならず、 しかも全部横並びの関数になるため凝集度が低くなってしまう。 あとからメンテするのが大変。 C++を極めた人間のC++ソースと Cを極めた人間のCのソースなら 前者のほうが分かりすい。 286 名前：デフォルトの名無しさん mailto:sage [04/07/02 00:39] >>285 ソースの分かりやすさと言語の難しさは違うと思われ。 287 名前：デフォルトの名無しさん mailto:sage [04/07/02 22:26] >>282 ヴァカみたいにテンプレートや継承使いまくってるタコソースなんか見る気がしないということでは ? 288 名前：デフォルトの名無しさん mailto:sage [04/07/03 01:27] >>285 C++で本格的にプログラムを書いた事が一度もありませんね？ 289 名前：デフォルトの名無しさん mailto:sage [04/07/03 09:06] >>288 煽っているつもりだろうが、それはむしろ逆だろ、本格的に書けばC++の方がやさしい C++の言語仕様は厄介だから、ちょこっと書く分には難しい。 変な煽りはヤメレ 290 名前：デフォルトの名無しさん mailto:sage [04/07/03 23:43] >>289 別に、C++でも、C風に書くこともできる 291 名前：デフォルトの名無しさん mailto:sage [04/07/04 04:21] おじさんはextern "C" {}のトリコ 292 名前：デフォルトの名無しさん mailto:sage [04/07/05 02:14] Ｃ＋＋の仕様準拠率がもっとも高いコンパイラって、 現時点では何になるのでしょうか？ もしかしたらスレ違いかもしれないけど、 これだけ「難しい言語」だと 仕様に準拠するのも大変そうだなぁということで…。 293 名前：デフォルトの名無しさん mailto:sage [04/07/05 14:53] 準拠度そのものを比較したってのは知らないけど、 Boostのレギュレーションテストは参考になるね。 ttp://boost.sourceforge.net/regression-logs/ 294 名前：デフォルトの名無しさん mailto:sage [04/07/05 18:25] 本格論議はよくわかんないけど、std::map なんかがやっぱり便利だから、 よく初心者の勉強用に用いられる「単語の出現頻度を調べよ」みたいな プログラムは、C の場合より著しく簡単になるよね・・・ 295 名前：デフォルトの名無しさん mailto:sage [04/07/10 14:16] >>282 それはソース云々より設計がタコ どんな言語で書いてもタコはタコ まC++はタコさ加減が露呈しやすい言語ではあるが VBなんかだとみんなタコだからカモフラージュになるしな タコじゃないほうが浮いて目立って困る 296 名前：デフォルトの名無しさん mailto:sage [04/07/10 14:20] 295=タコじゃないつもりのタコ 297 名前：デフォルトの名無しさん mailto:sage [04/07/10 16:32] いきなり設計云々が出てくる辺りがとっても蛸。 298 名前：295 mailto:sage [04/07/10 18:48] >>287と>>282を間違えたあたりがタコorz 299 名前：デフォルトの名無しさん [04/08/07 19:46] 言語仕様がタコなC++の時代は終わった これからはtemplateを使う必要がないJavaの時代です 300 名前：デフォルトの名無しさん mailto:sage [04/08/07 19:50] >>299 ｳｾﾞｰあげんなﾎﾞｹ　程度の低い釣りは秋田 301 名前：デフォルトの名無しさん mailto:sage [04/08/08 01:33] >>293 やっぱりboostなんて使えないってことかな。 302 名前：デフォルトの名無しさん mailto:sage [04/08/08 01:34] >>301 意味がわかりません。 303 名前：デフォルトの名無しさん mailto:sage [04/08/08 01:45] >>302 移植性が低いってことでは 304 名前：デフォルトの名無しさん mailto:sage [04/08/08 09:08] boost が使えなくて泪目で boost なんて必要ないんだぁぁぁっ て事ですな。 305 名前：デフォルトの名無しさん mailto:sage [04/08/11 03:38] >>299 >templateを使う必要がないJavaの時代です 1.4でがんばってね。 306 名前：デフォルトの名無しさん mailto:sage [04/08/12 06:24] 現場だと継承、テンプレート一切使わないってこと多いな。 テンプレートなんてそんな難しいか？ boostはともかく、STLと簡単なテンプレートぐらいなら誰でも理解できるだろ？ テンプレートが難しいってのは、一部の天才が作った ジェネリックプログラムとかのこと？ 307 名前：デフォルトの名無しさん mailto:sage [04/08/12 06:55] サイズが10倍になるのでプロの現場では使われません。 308 名前：デフォルトの名無しさん mailto:sage [04/08/12 07:00] テンプレートが難しいんじゃなくて、テンプレートを使って書かれたコードに、 テンプレートパラメータの名前省略されたものが多かったり traitsとかpolicyに分解されてコードが細切れの散り散りだったり その上、#ifdef等で切り刻まれていて全体像を把握しづらいコードが多いというだけのこと。 309 名前：デフォルトの名無しさん mailto:sage [04/08/12 07:38] そりゃぁセンスのない奴が書けばテンプレートに限らずね。 >>307 仮令10倍であっても作業効率が上がるのであればプロだからこそ使いますが。 #サイズ云々する現場なんて寧ろ限られるって。 310 名前：デフォルトの名無しさん mailto:sage [04/08/12 17:09] DinkumwareのSTLはセンスの無い奴が書いたのか？ 311 名前：デフォルトの名無しさん mailto:sage [04/08/13 05:03] C++の仕様はセンスの無い奴が書いた 312 名前：デフォルトの名無しさん mailto:sage [04/08/14 01:18] >>310 コンパイル時のリソース消費を少しでも軽減するためらしい。 あとは、真似防止か。 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を使う事だったようです。 最近使えるようになったんでしょうね、うれしくてたまらないみたいです。

---

---

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

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