1 名前:デフォルトの名無しさん mailto:sage [2009/05/04(月) 21:04:54 ] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 前スレ C++相談室 part66 pc12.2ch.net/test/read.cgi/tech/1231640498/ ※part63, part66 が重複していたようですので part69 としました。
331 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 05:56:50 ] >>325 destructor はディストラクタではなくデストラクタね。発音的にも用語的にも。 ディスクトップでなくデスクトップなのと同じで。
332 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 10:51:25 ] >>330 関数が2つになっちゃうけど、 クラス内に template<typename T> friend bool operator <(const Hoge &lhs, T rhs); template<typename T> friend bool operator <(T lhs, const Hoge &rhs); って書けば、関数テンプレートの定義を外に書けると思う…たぶん それか、関数テンプレートをやめて定義を特殊化して書いてもいけるんじゃないかな。 間違ってたらサーセン
333 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 16:13:37 ] >>322 を見て思ったんですが、 ファイルを読み込み文字列検索するだけでこんな長く分り難いにコードにえーって感じなんですが、 C++を使って書くとこれより短く解りやすいコードになるんですか? それはどんな感じになるんですか? >>322 で printf("%d番目に見つかりましたよ\n", i); return 0; ここでreturnしているんですが、ここではfreeしなくて良いんですか?
334 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 16:41:01 ] >333 main() {system("grep abcde 文字列が入ったファイル");} >free リークしていないので問題ないが、姑に目を付けられる。
335 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 16:53:00 ] でも突然サブルーチンに昇格する可能性もあるから、 常にfreeした方がいいよ。
336 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 17:02:55 ] >>334 >free 見つかった時、見つからない時の両方でfreeしないなら良いけど 片方しかしてないって、C使いらしくないんじゃない? 短いコードでたった2箇所を管理するだけなのに、それすら出来ないなんて
337 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 17:55:44 ] freeの仕様について言及しただけで、 >>322 のソース自体に文句付けるなら もっといろいろあるだろ。
338 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 21:07:11 ] return 0; を break; に置き換えるとか?
339 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 21:14:11 ] ファイルを一気に読むのが好きになれない、俺なら1行ずつの処理にする。
340 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 21:15:00 ] 配列まではすんなり頭に入ったけど、ポインタとかクラスのメンバ関数とかわけわかんねー・・ なんにしても作りたい物が無ければ頭に入らない気がしてきたんだけど、ドリルみたいなものって無いですか
341 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 21:16:19 ] 宿題スレに山ほど
342 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 21:19:51 ] こんなスレあったのか、ありがとう
343 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 21:35:44 ] >>341 宿題スレはいいよな 糞問ばっかりだけど最初のうちは数こなす方が大事だし
344 名前:310 mailto:sage [2009/05/18(月) 23:20:37 ] >>332 なるほど。 やはり関数を1つにまとめ、かつ (特殊化をすると妨げられる)汎用性を保とうとするならば Dan Saksの More C++ Idioms/friend 関数の生成(Making New Friends) - Wikibooks ttp://ja.wikibooks.org/wiki/More_C%2B%2B_Idioms/friend_%E9%96%A2%E6%95%B0%E3%81%AE%E7%94%9F%E6%88%90(Making_New_Friends) すなわちEffective C++でいう後者の方式しかないようですね。 ありがとうございました。
345 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 23:30:53 ] 次はコナン風で頼む。
346 名前:デフォルトの名無しさん [2009/05/18(月) 23:32:24 ] どっちのコナンだよ
347 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 23:43:35 ] やってくれるのか? わくわく
348 名前:デフォルトの名無しさん mailto:sage [2009/05/19(火) 01:23:32 ] コナン・ザ・グレート風で頼む。
349 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 23:15:48 ] クラス中の宣言の中でメンバ関数の定義をした場合、 自動的にinline展開要請になるんだよね? では クラス中の宣言の中でfriend関数の定義を記述した場合、 inline展開要請になるのかい?
350 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 23:32:49 ] ^^
351 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 23:35:26 ] inline展開陳情のほうがいいかも。
352 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 23:49:36 ] 俺のBCC 6.1.0ではオプションを付けない限り inline は全部無視される\(^o^)/ デバッグの時の事を考えてだと
353 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 00:48:25 ] >>352 BCC以外でもみんなそうだけど……。
354 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 15:44:38 ] 同じ質問になるのですが、86とは別人です。 コンストラクタで例外を投げるな、というのをかなり以前Cマガジンで読みました。 その後、Google や >>93 で、コンストラクタ内で例外を投げる時に 適切にリソースを解放すれば問題ない、というのが多かったのですが、 以下のサイトに気になる記述も見つけました。 ttp://www.geocities.jp/chacha_yhk1219/prog/prog004.html newで作ったときにオブジェクト自体がリークしてしまう monoist.atmarkit.co.jp/fembedded/symbian/symbian04/symbian03.html ポインタが返ってこない。知らないポインタは消せない コンストラクタで例外を発生させてもよいが、その場合は new するな、 という理解でよいでしょうか。
355 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 16:19:13 ] >>354 Symbianは組込だからそうなっていないのかもしれないが、普通はその心配は要らない。 その場合は確かにプログラムで対処できないので、言語が面倒を見てdeleteしてくれる。 規格では15.2にそう定められている。 ちなみに、そういうわけでnewを定義するときには必ず対応するdeleteを定義しないといけない。 ttp://www.fides.dti.ne.jp/~oka-t/cpplab-placement-new-2.html
356 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 17:13:34 ] >>355 規格での項番まで示していただきまして、有難う御座います。 15.2/2 の箇所ですね。 規格に正しく準拠した処理系であれば問題ないとことで、懸念なく利用したいと思います。 有難うございました。
357 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 22:49:39 ] 初心者ではないと思っていたのですが、初心者からこんな質問を受けて 的確に答えられなかった自分が恥ずかしいです。どなたか、模範解答を教えてください。 「ヘッダファイルの用途と、使用によるメリットは理解できました。 ただ、cpp ファイルを分ける目的がわかりません。 また、cpp ファイルを複数持たせた場合、ビルド順はどうなるのですか?」 宜しくお願いします。
358 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:01:32 ] むしろcppファイルを分けないでどうやってまともに開発しているのか分からないぐらいだが。 分割コンパイルすることで仕様変更に伴う再コンパイル時間の短縮とかも見込めるけど、 それ以上にそもそも他人が作ったクラスとかを使いたい(再利用したい)場合とか cppファイルが分かれてなかったら再利用できないだろ。
359 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:06:45 ] >>358 その観点で考えると、うちのプロジェクトは基本的にほどんどがヘッダファイルで構成されていて、 クラスは基本的に .h で作って #include で取り込む、っていう方法を取っています。 なので、再利用には困りません。 ほとんどがヘッダっていう考え方がNG? あと、ビルド順序はどうなるものですか?やってみたんですが分かりませんでした。
360 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:07:48 ] いやまて。ヘッダファイルに直接定義を書き込んでいるのか? そんなことできないだろ。
361 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:10:52 ] 出来るだろ。じゃないとboostのビルド不要なライブラリは実現できないよ。
362 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:12:36 ] 「ビルド順はどうなるか」って、質問者はもちろん、>>357 自身も理解してない気配。 分割コンパイルやリンクについてわかってないまま脱初心者とは。 ちなみに、グローバルやclass-staticな変数の初期化順については 何も規定されていないことが規定されている。 ということは、リンク順についてそれが当てはまることを意味するが 規格に「リンク」という単語が出ているかは知らない。 cppの分割については>>358 と同じ。 classにわけたり、意味的なまとまりにわけたりして まともなものを作るのなら分割するのが当然。 >>359 Javaチックな書き方ってことかね。 別にそれならそれで良いんじゃないの。 .hに全部書く、ということは、「ビルド(コンパイル)時間の短縮」なんて 露ほどにも考えていないということだから、 再利用もできるし分割コンパイルなんて必要無いかもね。
363 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:13:20 ] 言い方がまずかったか。「できないものがある」。こうだな。 もしかして、全部 inline にしたり、あらかじめ obj にしたりしてあるのだろうか。
364 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:17:24 ] >>359 >クラスは基本的に .h で作って #include で取り込む、っていう方法を取っています。 >なので、再利用には困りません。 >ほとんどがヘッダっていう考え方がNG? マジ?? その会社 大丈夫??? 考えて見ればcppファイルが1つだけなら関数の定義とかを.hに書き込んでも バイナリの時点で重複は起らないが(hでインクルードガードしていること前提ね。) それにしても、、、ねぇ。。。
365 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:18:54 ] >>360 dllexport が必要な時と、main() 系、コールバック系以外はすべてヘッダファイルなんです。 クラスの定義や構造体など、ほとんど。 ヘッダファイルの考え方が違うのかな… >>362 規定が無い点について理解しました。 確かにうちのプロジェクトのソースはビルド時間かなりかかるんです… .cpp で書くと分割コンパイルされて速度が向上するということですね。 まったく知りませんでした。。 まさに java チックです。 なので、include 順序がかなり大事で問題も結構起きるんですよね。 でも私個人的には、c++ で開発しているので、c++ の基本を知りたいです。 >>363 全然、そんなことないんです>< おまけに、プリコンパイルヘッダもないので時間ばかりが掛かって…
366 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:21:28 ] >>365 ヘッダに定義を全部書いたら、クラスのインタフェースに全く影響を及ぼさない 変更であっても、そのヘッダに依存するソースファイルすべてが再コンパイル されるじゃないか。その程度も分かってない会社って一体・・・
367 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:22:39 ] >>364 インクルードガードしてもできないよ。 インクルードガードは同一翻訳単位内でしか有効ではないから。
368 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:25:16 ] >>364 そうなんですよ!! .cpp ファイルは main 用に1つだけあって、あとは .h の処理を呼び出したり、 クラスを生成してクラスに処理を任せたり、、、 グローバル関数までもが .h に居る始末です。 >>366 まさにその通りですね。 これでも一部上場なのですが、本当にお恥ずかしいです。
369 名前:364 mailto:sage [2009/05/23(土) 23:25:54 ] >>367 いやできるでしょ。 cppが1つしかないんだぜ? ってことは翻訳単位も(恐ろしいことだが)一つってことじゃん。
370 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:27:17 ] すでに拡張子の意味を逸脱した使い方なのはわかった
371 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:29:20 ] >>369 あぁ、そういうことか。理解したw すごいな。
372 名前:357 mailto:sage [2009/05/23(土) 23:33:35 ] 結論としては、>>370 がおっしゃっているように、 拡張子の意味を確実に逸脱しているのですね。 みなさんがおっしゃったように、リンクの意味を理解していなかったようです。 分割ビルドは十分理解できました。 今一度教えてください。みなさんは .h を基本的にどのような用途で利用されていますか? また、現状のように .cpp を1つだけもち、ほとんどすべてを .h に置くことで発生しうる 考えられる問題がありましたら教えてください。 >>369 すみません、私は理解できませんでした。 まだ初心者であることを思い知りました。 翻訳単位が1つだと、恐ろしいものですか?時間が掛かる、という観点でしょうか。
373 名前:369 mailto:sage [2009/05/23(土) 23:40:35 ] >>372 >翻訳単位が1つだと、恐ろしいものですか? そんな開発者見たことないから、恐ろしいと形容した。 >今一度教えてください。みなさんは .h を基本的にどのような用途で利用されていますか? あくまで宣言だけを書いておく。 MyClassを使う必要があればMyClass.hをインクルードする。 一方MyClass.cppにもMyClass.hをインクルードしておいて、別途コンパイルしておく。 こうすることで、MyClass.cppが変更されても他の大部分のcppは再コンパイルしないで済む。 あるいはMyClass.cppをコンパイルしてライブラリとして公開する場合、 他社には.hだけを見せるわけだから実装を隠せるとか。 >また、現状のように .cpp を1つだけもち、ほとんどすべてを .h に置くことで発生しうる >考えられる問題がありましたら教えてください。 他の会社や組織に公開する時に実装がだだ漏れになるとか
374 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:46:19 ] つか、どんな教科書で勉強したんだよ。 大概の教科書は分割の仕方書いてあるだろ^^
375 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:49:36 ] >>372 ビルドに時間が掛かって仕方がないだろう
376 名前:357 mailto:sage [2009/05/23(土) 23:54:38 ] >>323 なるほど、、、将来を見据えた設計をしながら開発してるんですね。 なんかもう、うちの会社が悩ましいです。 >>374 会社の研修では一切… ちなみにほとんどのプロジェクトがそんな感じです。 java と COBOL 人間ばかりなので、include = そこにそのファイル内容を挿入、っていう 意味合いだけしか着目していないんだと思います。 >>375 その通りですね。勉強になりました。 今日皆さんにご指導いただいた内容を以って、会社の開発体制の改善を 促して以降と思います。 ありがとうございました。
377 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:55:23 ] まて、>>357 は本当にC++を扱う一部上場企業に勤めているのか? 例えば、分割コンパイルには関係ないようなC++の問題だしても解けるか?
378 名前:357 mailto:sage [2009/05/23(土) 23:55:32 ] >>376 ○ >>323 × >>373
379 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:56:27 ] どうせ元ABCのあそこだろ?
380 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:59:44 ] >>377 私も信じられなくなってきましたが、こんな開発者ばかりながらも、 一部上場です。 私はアセンブル系のドライバ開発あがりで、ウィザードを利用して ATL/WTL アプリケーションの 開発をやっているので、一から自分でファイルを作ってプロジェクトを構成したことがありませんでした。 20年弱もプログラミングをして来ましたが、初心者からはなかなか抜け出せませんね。 大変勉強になりました。
381 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 00:06:46 ] >>380 そうなのか。 じゃあもういっそC++やめて、各自が得意なCOBOLとかアセンブラやればいいのではないでしょうかね。。。 少なくとも一人、C++の知識がある人が居ないととんでもないことになるのでは。 まああなたがその一人になれば良いだけだが。 頑張ってください。
382 名前:デフォルトの名無しさん [2009/05/24(日) 00:07:00 ] >>380 大丈夫。そのやり方で会社が回っているならそれで正しい。 開発の仕方に正解なんてないんだし、そもそも他と同じことをやっていたらこのご時世生き残れない。 君の会社は君の会社なりのやり方を見つけたんだと思う。だから生き残っているんだろう。 もっと、堂々としていいよ。
383 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 00:16:10 ] >>381 なかなか COBOL やアセンブルの案件が見つからなくなってきたんですよね。。 でも、頑張ります!ありがとうございます。 >>382 ありがとうございます。 基本をしっかり抑えた上で、スタイルを大事にして行くことにします。
384 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 00:37:07 ] >>380 優秀であってもドカタ企業のドカタじゃどうしよもないよ 一部上場の正社員とドカタ企業のドカタじゃ霄壌の差
385 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 02:15:34 ] 言わなくてもわかってるからもうドカタに触れるのやめようよ 可哀想だろ俺が
386 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 02:27:32 ] 一部上場ならお給金もそれなりでしょ まともな本買いましょうよ
387 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 02:39:06 ] 初心者にまともな本買えって言っても、 どれがまともな本なのかわからんでしょ まともな本教えましょうよ
388 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 02:54:41 ] 学生の勉強じゃない仕事の事なんだから、休みの日にでも本屋に出向いて 中を見て初心者なりでも”自分”で選ぶべきだと、俺は思う で、幾つかの本を読破してこそ、まともな本かどうかの判断が付く脱初心者になって行くんだと思う その最初のステップを”初心者”と言う理屈で飛ばすような奴が プログラムの本を読んで技術力を上げていくなんて出来ないだろ そもそも、本人が教えてと言ってるならともかく 初心者なんだから教えるべき、と言って自分は教えてない奴は好きじゃないw
389 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 02:59:18 ] 兎にも角にも禿本は重要だよな。 特に後半の設計に関する部分を読んでない人は多いと思うけど、色々含蓄あるし。
390 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 03:02:13 ] 俺が書いたネタレスに入魂レスとは.... ネタと分かるように語尾を>>386 と同じにしたのに 釣られる奴居るんだな
391 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 03:05:39 ] >>388 長々と小言を言う暇があるなら、自分が薦める本を挙げればいいのに。 >>390 釣りならVIPでも行ってやれば?
392 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 03:15:54 ] だから最初の理解なんて人それぞれ 俺が良いと言ったって、合う合わないがある、だから教えないし、 自分でググるなり、本を手に取れって言ってるじゃん アンタゆとり?
393 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 03:25:13 ] 釣りに延々とマジレスしてきもいな
394 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 03:25:14 ] 以下のプログラムがうまく行かないのですが、 解決方法を教えて下さい。 5 class B; 6 7 class A{ 8 public: 9 int hoge; 10 A(int i){ i = hoge; } 11 12 B conv(){ return B(hoge); } 13 }; 14 15 class B{ 16 public: 17 int hoge; 18 B(int i){ i = hoge; } 19 20 A conv(){ return A(hoge); } 21 }; ------------------- エラー test.cpp: In member function ‘B A::conv()’: test.cpp:12: error: return type ‘struct B’ is incomplete test.cpp:12: error: invalid use of incomplete type ‘struct B’ test.cpp:5: error: forward declaration of ‘struct B’
395 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 04:39:09 ] Bの定義より後にA::convの定義を置けば上手くいく。 class B; class A { public: int hoge; A(int i) { i = hoge; } B conv(); }; class B { public: int hoge; B(int i) { i = hoge; } A conv() { return A(hoge); } }; B A::conv(){ return B(hoge); }
396 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 04:40:16 ] class B; class A { ... B conv(); ... }; class B { ... }; B A::conv() { return B(...); }
397 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 04:45:07 ] >>395 >>396 ありがとうございます。
398 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 05:36:49 ] complexは実数、虚数にreal()、imag()でアクセスするわけですが、 この関数って参照返すだけだから、 それだったら内部の実数、虚数変数に直接アクセスした方が関数呼び出し無い分早いだろうし、 ソースコードも見やすく(多分)なると思うのですが、 これには何か理由があるのでしょうか?
399 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 08:12:11 ] ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E6%8A%BD%E8%B1%A1%E5%8C%96
400 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 10:53:54 ] >>398 基本的に内部の実装に触れられるようにしちゃうと いざインターフェースは変わらないが実装が変わるような仕様変更をするときに 悲劇がおこるからとか。
401 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 14:06:24 ] あと、関数呼出のオーバーヘッドなんてないと思っていいよ。 それくらいコンパイラの最適化でいともたやすく消え去るられる。
402 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 14:11:10 ] そんなことはない だったらなぜわざわざinlineなんて予約語が用意されてるんだ? 関数呼び出しを減らすのは高速化の基本のキだ ウソを教えるのはやめろ
403 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 14:15:36 ] >>402 の年齢が気になる
404 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 14:15:42 ] 現在は なんでもかんでもゲッタセッタ教 の勢が強いから 狂信者の戯言は聞き流して己が道を進めばいいと思うよ
405 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 14:20:59 ] 下駄雪駄教徒だって、下駄雪駄は基本的にインライン関数にするだろう アウトラインの下駄雪駄なんておぞましいものは狂信者でも書くわけがない 少なくとも長いループ内では、アウトライン関数を呼んではいけない これは今も重要なガイドラインだ
406 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:01:18 ] 少なくともC++でフィールド変数直接アクセスするのは 百害あって一利なしだな。 >>402 >>401 が言ってるのはreal/imagの話だろ。 言葉足らずならそう指摘すればいいのに。力抜けよ。
407 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:05:37 ] ja.wikipedia.org/wiki/%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89_ (%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6) 下の方のアクセサの項目
408 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:06:24 ] せったげったって言うけどさ hoge.hage.foo.bar.set_value(0); とかはあったとしても hoge.get_hage().get_foo().get_bar().set_value(0); なんてことはしないよね この辺みんなどうしてるんだろ。 hage や foo は public なメンバにするよね?でもそれだと統一感ないよね?
409 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:08:19 ] どっちもねーよ
410 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:12:41 ] データ主体なものは構造体にしている メンバ関数はコンストラクタ、コピー、シライライズ、ダンプ、アサートぐらいしか定義しない それと同じ目的の変数は構造体にまとめる class A
411 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:15:28 ] 途中で送ってしまったぜ 後ろの段落は class の中で struct xxx_param とか struct xxx_item, xxx_state とかを定義して まとめてあつかう
412 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:18:06 ] おなじくどっちもねーよ > hoge.hage.foo この辺までですでに内部状態の一貫性を壊していると思われ(setの場合)。 設計が悪いから作り直せ。
413 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:38:47 ] え?でもさ、よくしらないけど、フォームアプリなんて System.Form.SetValue() みたいにどんどん深くなっていってない? 実モデルでたとえても、例えば 部屋A.本棚B.本C.ページD.GetText(); みたいな例は十分にありえるんじゃないの?
414 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 15:39:02 ] >>402 は今でもregisterを使っているのだろうか。
415 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 16:02:00 ] せめてこうだろ void foo::set_bar_value(int n) { bar.set_value(n); } void hage::set_bar_value(int n) { foo.set_bar_value(n); } void hoge::set_bar_value(int n) { hage.set_bar_value(n); } hoge.set_bar_value(0); 俺はvector3やmatrix44みたいなのは公開してるなあ。 あとは、クラスとして独立させるほどでもないが、関連のあるメンバ変数をグループ化したいときに structを使ってる。
416 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 16:05:06 ] >>413 System.Form.SetValue() どこのC#? あとそれ名前空間と混ざってるから。
417 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 16:13:50 ] でも名前空間って要するに全メンバがpublic静的なクラスのことだろ
418 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 16:21:41 ] >>415 それはない
419 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 16:38:05 ] しょぼい設計でなければ 名前空間で内部状態を壊されることはないから問題ない。
420 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 17:11:46 ] class A{ B* get(); } というクラスで、get()メソッドをインライン関数にしたい テンプレートクラスと同様に同じヘッダファイルに実装を書く場合、 inline B* A::get(){ コード } の「inline」は意味があるのでしょうか?
421 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 17:15:11 ] ない というか意味があるかないかで言うなら、inlineは常に意味がない コンパイラは自由にインライン化要請を無視できるし、要請されてない関数をインライン化することが出来る
422 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 17:25:36 ] 規格上はそうだが、一応現実的には意味はあるから、意味なしと言い切ってしまうのは誤解を招くのでは。 例えば俺が使っているコンパイラは「inline指定に従う/無視する」「inline指定がなくても勝手にinline化する/しない」 などの指示を自分で出すことができる。
423 名前:422 mailto:sage [2009/05/24(日) 17:26:22 ] もちろん環境依存の話だから、詳しくは「自分が使ってるコンパイラについて調べてね」ってことだけど。
424 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 17:33:39 ] inlineは、コンパイラの最適化云々ではなく、 ヘッダに直接(= インラインで)定義するぞ、という意味だと思えばいい。
425 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 17:53:20 ] >>424 変な誤解を生むから詳しく知らないなら 黙ってるか断定的に書くな。
426 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 18:02:20 ] >>424 適当なこと書くなよ。 cppファイルにてもinlineは書けるわけだし もう何が何なのかw
427 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 18:05:30 ] >>424 インラインに”ヘッダに直接”という意味があったなんて白なkったおれはどうすればいい?
428 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 18:06:30 ] "C++" "ヘッダに直接" "インライン"の検索結果 5 件中 1 - 5 件目 (0.33 秒)
429 名前:426 mailto:sage [2009/05/24(日) 18:08:40 ] >>428 よくやったwww
430 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 18:35:56 ] ところで>>420 でinlineを付けなかったらリンカエラーにならない? そういう意味でinlineはいると思うんだけど。
431 名前:デフォルトの名無しさん [2009/05/24(日) 18:37:06 ] んなわけない。