- 1 名前：v(^・^)v mailto:sage [2010/02/13(土) 23:18:03 ]
- C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。
前スレ
C++相談室 part77
pc12.2ch.net/test/read.cgi/tech/1263556932/
- 2 名前：デフォルトの名無しさん mailto:sage [2010/02/13(土) 23:20:55 ]
- ■基本■
[C++ FAQ]
www.parashift.com/c++-faq-lite/
www.bohyoh.com/CandCPP/FAQ/ (日本語)
Cとその仕様を比較しながらの解説なので分かりやすい。
***** 質問の前に必ずこの二つに目を通してください *****
[C/C++ リファレンス]
www.cppreference.com/ （英語）
www.cppreference.com/wiki/jp/ （↑の日本語訳だけどまだ未完）
[禿 Stroustrup]
www.research.att.com/~bs/
[C++ International Standard]
www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38110
[JTC1/SC22/WG21 - C++]
www.open-std.org/jtc1/sc22/wg21/
ここから規格の最新（2003より新しい）ドラフトがダウンロードできる。
[JIS X3014]
www.jisc.go.jp/app/pager?id=15868
ISO規格の日本語訳。JIS X 3014:2003はISO/IEC 14882:2003 (E)に対応。
- 3 名前：デフォルトの名無しさん mailto:sage [2010/02/13(土) 23:24:24 ]
- ■Libraries■
[Boost]
Boost www.boost.org/
(日本語) www.kmonos.net/alang/boost/
(日本語) shinh.skr.jp/boost/
[標準ライブラリ]
SGI-STL www.sgi.com/tech/stl/
STLport stlport.sourceforge.net/
GNU libstdc++ gcc.gnu.org/libstdc++/
Apache C++ Standard Library (STDCXX) stdcxx.apache.org/
STLFilt www.bdsoft.com/tools/stlfilt.html
(日本語) episteme.wankuma.com/stlprog/ （※1999年発行注意）
[Loki]
sourceforge.net/projects/loki-lib/
LokiPort-MSVC6sp5 fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport
- 4 名前：デフォルトの名無しさん mailto:sage [2010/02/13(土) 23:28:14 ]
- ■Books■
amazon.com C,C++関連書籍
www.amazon.com/exec/obidos/tg/browse/-/3956/ref=br_bx_c_1_3/
The C++ Programming Language
www.amazon.com/exec/obidos/ASIN/0201700735/
www.amazon.co.jp/exec/obidos/ASIN/475611895X/ (翻訳)
C++ Primer (3rd Edition)
www.amazon.com/exec/obidos/ASIN/0201824701/
www.amazon.co.jp/exec/obidos/ASIN/4756140068/ (翻訳)
The C++ Standard Library
www.amazon.com/exec/obidos/ASIN/0201379260/
www.amazon.co.jp/exec/obidos/ASIN/4756137156/ (翻訳)
Effective C++
www.amazon.com/exec/obidos/ASIN/0201924889/
www.amazon.co.jp/exec/obidos/ASIN/4756118089/ (翻訳)
More Effective C++
www.amazon.com/exec/obidos/ASIN/020163371X/
www.amazon.co.jp/exec/obidos/ASIN/4756118534/ (翻訳)
Exceptional C++
www.amazon.com/exec/obidos/ASIN/0201615622/
www.amazon.co.jp/exec/obidos/ASIN/4894712709/ (翻訳)
More Exceptional C++
www.amazon.com/exec/obidos/ASIN/020170434X/
Exceptional C++ Style
www.amazon.com/exec/obidos/ASIN/0201760428/
- 5 名前：デフォルトの名無しさん mailto:sage [2010/02/13(土) 23:29:23 ]
- ■Books(Templateまわり)■
Effective STL
www.amazon.com/exec/obidos/ASIN/0201749629/
www.amazon.co.jp/exec/obidos/ASIN/4894714108/ （翻訳）
Modern C++ Design
www.amazon.com/exec/obidos/ASIN/0201704315/
www.amazon.co.jp/exec/obidos/ASIN/4894714353/ （翻訳）
C++ Templates
www.amazon.com/exec/obidos/ASIN/0201734842/
C++ Template Metaprogramming
www.amazon.com/exec/obidos/ASIN/0321227255/
- 6 名前：デフォルトの名無しさん mailto:sage [2010/02/13(土) 23:30:53 ]
- 長いソースを貼るときはここへ。
codepad.org/
- 7 名前：v(^・^)v mailto:sage [2010/02/13(土) 23:36:05 ]
- 基本のリンクは少し更新しといた。あと Libraries のリンクを復活させといた。
後は好きにして。
- 8 名前：デフォルトの名無しさん [2010/02/13(土) 23:48:06 ]
- 近縁スレでも貼る？
【初心者歓迎】C/C++室 Ver.71【環境依存OK】
ttp://pc12.2ch.net/test/read.cgi/tech/1264774545/
初心者はこちらへ
C言語なら俺に聞け（入門編）Part 60
ttp://pc12.2ch.net/test/read.cgi/tech/1264920499/
C言語はこちらへ
ぐらいか？
- 9 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 02:08:30 ]
- 前スレの話だけど、関数テンプレートならinline付けずに
ヘッダに定義書いても全然問題ないことをどっちか片方が知らないように感じた。
俺の誤解だといいんだけど。
- 10 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 08:16:00 ]
- >>9 さすがにそれは無いでしょ。それだと判断基準以前の話になってるはず。
- 11 名前：デフォルトの名無しさん mailto:ageage [2010/02/14(日) 09:26:00 ]
- 前スレの方が上とはけしからん
age
- 12 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 09:59:23 ]
- STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
- 13 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 10:06:33 ]
- ところで現在のC++0xは
いつ頃 正式なC++になるんですか？
- 14 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 10:12:35 ]
- 2011年10月23日2時13分25秒頃
- 15 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 10:19:30 ]
- VS2010はSP1で完全対応してくれるんかいな
- 16 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 17:31:43 ]
- >>12
地鎮乙
- 17 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 19:14:00 ]
- if else文で文字列のパターンを32個
チェックするのが、どうにも気持ち悪いのですが
何か別の方法はないでしょうか？
- 18 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 19:15:46 ]
- 関数ポインタとの連想配列作るとか
- 19 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 19:16:36 ]
- パターンを配列に入れてループ
- 20 名前： ◆GWRSHcLrd6 [2010/02/14(日) 19:18:15 ]
- どうも。
スマートポインタにメモリプールを実装してみました。
(なんか保守的GCみないな感じになりましたが・・・)
まだうｐしてませんが(随分汚いので)、ベンチだけ取ってみました。
- 21 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 19:21:35 ]
- で、ベンチは？
- 22 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/14(日) 19:26:26 ]
- ループは10000, サンプリングは5で行いました。
boost::shared_ptrのベンチマーク(非スレッドセーフ)
単純な生成ループ: 15, 空ポインタに代入: 12
オブジェクトのリセット: 25, オブジェクトのコピー: 24
オブジェクトの解放: 9
framework::smart_ptrのベンチマーク(with メモリプール)
単純な生成ループ: 3, 空ポインタに代入: 12
オブジェクトのリセット: 12, オブジェクトのコピー: 12
オブジェクトの解放: 6
トータルスコア:
boost::shared_ptr: 85
framework::smart_ptr: 45
boost::shared_ptrに対する性能
単純な生成ループ: 500.0%
空ポインタに代入: 100.0%
オブジェクトのリセット: 208.3%
オブジェクトのコピー: 200.0%
オブジェクトの解放: 150.0%
全体: 188.9%
いやあ、劇的ですわ
ソースが汚いので、奇麗に書きなおせばあと10%はアップすると思います。
- 23 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 19:30:10 ]
- 既存の実用アプリでレポ
- 24 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 19:30:31 ]
- まずはスマポのソースうｐ
- 25 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 20:03:40 ]
- C++ではメソッドチェーンを、あんまり使わないんだね
- 26 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:01:28 ]
- >>25
多用されてるでしょ。主にoperator系、特にストリーム操作とか。
印象は違うかもしれないけどオブジェクトのメソッドがオブジェクト自身を返して連鎖していくって意味では
まさにメソッドチェーン。
- 27 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/14(日) 21:03:39 ]
- メモリプールの仕組みがこんなんなんですけど、効率のいい方法はどんなのが
あるんですか？
cdtest.genin.jp/projects/smart_ptr/pool_system.png
>>25
効率が悪いからでは？
- 28 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:10:01 ]
- >>27
このスマポってライセンス何なの？
まだ考えてない？
- 29 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/14(日) 21:15:53 ]
- ま、まだ考えてないです・・・
ライセンスは何がいいんでしょう・・・？
- 30 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:20:00 ]
- ただの習作でしょ。
実用プログラムに組み込みたいと思ってる奴なんて要るの？
- 31 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:21:41 ]
- Googleのメモリ管理でいい。tcmallocとかいうやつ
- 32 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:21:48 ]
- アロケートしたメモリのバイト数分だけジェリービーンズで支払う
- 33 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:29:51 ]
- まだソース見ないから分からないけど
NYSLライクなら昔作ったスレッドセーフ用のスマポと比較して
性能が良かったら使おうと思った
ライブラリに合わせて改変することになるだろうからLGPLとかだと無理なんだけど
この先も色々評価して高速化するなら需要はあるんじゃね？
- 34 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:32:57 ]
- >>27
こんなの遅くて使いものにならんでしょ。
以下の問いに対して、少なくともdlmallocよりも高効率なのかよw？
こんな糞データ構造で、メモリの空き領域をどうやって効率的にさがせる
のか答えてみろよw？これじゃ単なる線形リストだろw
このスレに2度と来るないいな？わかったか？
- 35 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:35:20 ]
- >>34
>>27 の質問を良く見てみろ
- 36 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/14(日) 21:35:44 ]
- >>30 >>33
まあ、これから頑張って独自性がでるようになってきたら、
ライセンスをつけたいと思います。
それまでは改変自由で（まだ大したものじゃないですしね）。
>>31
tcmalloc、ググりました。
こういうアロケートの仕方もあるんですね。
でもあれってアロケートはシステムコールとかで
バリバリにコーディングされているのかな？
ちょっとコード見てきます。
- 37 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/14(日) 21:37:33 ]
- >>34
申し訳ないです・・・
- 38 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:37:45 ]
- >>34
突然どうした
ちょっと落ち着け
- 39 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:38:24 ]
- 速度はたいした問題でない。既にある物より圧倒的に遅いなら別だが。
安定していて使いやすいこと。
しかしGoogleのメモリ管理もあまり流行ってないし、普及させられるほどの価値ある物は出来ないと思う。
メモリプールしても全体の速度向上はほとんど望めない。
普及させられるとしたら、boost互換のインターフェースでboostよりメリットがあること。
- 40 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:42:38 ]
- >>36
メモリ操作のみなら、Googleのメモリ管理は超速だが
実際にアプリに組み込むと何の変化も出ない。
現実アプリはメモリの生成・解放ばかりしていない。
プールはおまけにするか、Google任せにしてスマートポインタ開発のほうが
需要出ると思う。
- 41 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 21:54:29 ]
- Googleはこんなこともしてたのか知らんかった。
ちょっと見てみたけどtcmallocって改良版dlmallocみたいなのか。
- 42 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 22:48:55 ]
- >>27
線形以外の探索ってどんなのがいいのかねぇ
- 43 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 22:59:37 ]
- >>27
このプールから削除する場合はどうなるんだ？使い捨て？
- 44 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 23:04:19 ]
- >>42
最速の固定長の小メモリブロックアロケータは simple segregated storage だとわかりきっている。
探索しないでいい。
- 45 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 23:36:17 ]
- ヒープメモリーにヒープ構造を！w
- 46 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 23:50:34 ]
- boost::shared_ptrにもメモリプールを使うオプションがあったような
- 47 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/14(日) 23:54:13 ]
- >>43
inner_ptrの方でゼロ初期化され、新たなアロケートで再利用されます。
というかカウント0のものはゴミとみなして新しくAllocした時にそれを使います。
で、ブロックが空、なおかつ、ブロックを多く確保しすぎている場合は
そのブロックはdeleteされて前後のブロックをリストで繋ぎます。
>>45
そうなんですよｗ
- 48 名前：デフォルトの名無しさん mailto:sage [2010/02/14(日) 23:59:54 ]
- じぶんに考え。
N 十分大
char* p[0]・・・p[N] メモリブロック
メモリの使用状態を1ビットで表す 00011100010101000000
連続領域が必要なら0の連続を選択。
はじめはp[i]はNULLにしておく。
- 49 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/15(月) 00:00:16 ]
- 2つアロケート ↓
0001 ABCD 1234 5678, 0001 4321 DEDE 5678
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
解放 ↓
0000 0000 0000 0000, 0001 4321 DEDE 5678
~~~~~~~~~~~~~~~~~~~
アロケート(再利用) ↓
0001 0123 2567 ABAB, 0001 4321 DEDE 5678
~~~~~~~~~~~~~~~~~~~
アロケート(ブロック追加) ↓ ブロック2をnew
0001 0123 2567 ABAB, 0001 4321 DEDE 5678
0001 0CCC 1224 5555, 0000 0000 0000 0000
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
解放 ↓
0001 0123 2567 ABAB, 0001 4321 DEDE 5678
0000 0000 0000 0000, 0000 0000 0000 0000
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
不必要と判断、ブロック2をdelete
0001 0123 2567 ABAB, 0001 4321 DEDE 5678
- 50 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:00:37 ]
- >>47
いったい何を目指しているの？
メモリブロック確保の速度なんて operator new の実装に任せておけばいいこと。
そんなところをがんばるよりも、他にすることは無いの？
- 51 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/15(月) 00:01:08 ]
- って感じです。
- 52 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:02:15 ]
- カオス
- 53 名前： ◆GWRSHcLrd6 mailto:sage [2010/02/15(月) 00:02:56 ]
- >>50
すいません。高速化しようと思って少しそれてしまいました・・・
- 54 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:03:49 ]
- マルチスレッドでメモリ探索にロック掛けると速度落ちると思うから
キューに入れて順番に処理すると良い思うが、キューへのアクセスにロックが必要
ロック無しにする方法ないか。
- 55 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:05:52 ]
- wait-free lock-freeのwikiみると、アトミック命令使えばロック無しのマルチスレッドできるらしいが。
- 56 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:07:06 ]
- operator new よりGoogleメモリ管理の方が高性能。
- 57 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:08:51 ]
- >>54 www.google.co.jp/search?q=lock+free+queue
- 58 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:09:43 ]
- >>56
なら operator new を Google メモリ管理で置き換えればいいじゃない。
- 59 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:23:34 ]
- >>57
実装方法わからん。cas命令らしいけど
- 60 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 00:46:42 ]
- マルチコア時代のLock-free入門
www.slideboom.com/presentations/133166
これによると std::shared_ptr (C++0x) はとてつもなく遅くて使えんとあるな。
だから Hazard ポインタを使えともある。
- 61 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 01:01:25 ]
- >>60
スマートポインタでLock-freeにするには？ という話なのに、
Lock-freeを実現するために使用するスマートポインタの話をするのは順番が逆でしょう。
でも >>60 のような用途に使える軽快なスマポは確かに欲しいけど。
- 62 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 01:14:46 ]
- CAS命令は結構コストかかるのよ。
可能なら、RCU的な手法にする方が良い。
www.atmarkit.co.jp/flinux/rensai/watch2010/watch01b.html
みたいな記事もある。
- 63 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 23:47:17 ]
- RCUってなあに？
- 64 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 23:48:21 ]
- 正直
マルチコア時代
を相手にするならスマポのコストが問題となることは
大抵ないと思うんだが。
- 65 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 23:49:25 ]
- >>63
記事の中よめよ
リンク先にまるなげだけどちゃんとあるだろう
ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%89%E3%83%BB%E3%82%B3%E3%83%94%E3%83%BC%E3%83%BB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88
- 66 名前：デフォルトの名無しさん mailto:sage [2010/02/15(月) 23:55:18 ]
- で、依存無しのCASとかRCUとかはどう実装するんだ？
- 67 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 00:06:35 ]
- 無理無理
- 68 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 00:59:05 ]
- >>64
マルチコア関係なくね？
- 69 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 01:48:54 ]
- >>64
おい！
- 70 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 08:04:43 ]
- 通信系の処理プログラムを書いてるんですが
処理担当スレッドを作る場合、必要になったらbeginthread（もしくはbeginthreadex)で
スレッドを起動して作業が終わったらおしまいとするのとスレッドプールをするのでは
どちらがいいのでしょうか？
- 71 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 13:05:40 ]
- >>70
頻繁に起動終了を繰り返すようなものならスレッドプールが良いと思うよ。
スレッドの生成破棄もコストはあるからね。
- 72 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 15:32:45 ]
- getter/setterについて悩んでいます。
●getterについて
・setterに対してgetterも用意されていたら、隠蔽になっていないのではないか？
・利用者がsetした時の情報を保持すればgetterはいらないのではないか？
●setterについて
・コンストラクタの引数で受け取る物は、setterも用意したくなるが同じ機能を２箇所に書いている感が？
書いたクラスが各メンバ変数に対してgetter/setterが存在する物になっていると、
無駄に手間をかけただけの構造体なんじゃないかと不安になります。
必要十分なgetter/setterを持つクラスを設計するには、どういう事を考えればいいのでしょうか？
- 73 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 15:45:03 ]
- >>72
>・setterに対してgetterも用意されていたら、隠蔽になっていないのではないか？
なんでそうなる
他にもいろんなprivate変数持ってる場合がほとんどだろ
- 74 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 15:54:44 ]
- >>73
「コンストラクタも含めて外部からget/setされないメンバ変数」を持たないクラスも多いです。
10個近くの設定値が必要なクラスとか、コードのうちgetter/setterが占める割合が多くなって、「なんだかなー」と思います。
- 75 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 15:59:39 ]
- そう思うなら思い切ってpublic変数にすればいいだろ
でもgetter/setterを敢えて持つ理由は、プログラマに「今private変数を
いじってますよ」という事を常に意識させる効果がある
- 76 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 16:10:53 ]
- >>72
class widget {
public:
inline void set_x(int _x) { x = _x; }
inline int get_x(void) { return x; }
private:
int x;
};
↓内部仕様を変更したくなった
class widget {
public:
inline void set_x(int _x) { p->set_x(_x); }
inline int get_x(void) { return p->get_x(); }
private:
impl *p;
};
しっかり隠蔽になってるね
基本的に公開する必要があるなら全部アクセサでいい
未来永劫仕様を変えない保証があるなら丸出しでもいい
コンストラクタの分だけセッターを作る必要はない
単純セッターなら普通は
void set(const Obj &obj) { m_obj = obj; }
hoge.set(Obj(a1, a2));
こうする
- 77 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 16:39:05 ]
- >>75
一貫性がないのは嫌なので、public変数にするとなると全てのクラスをpublic変数にする事になって、これも嫌な感じがします。
>>76
確かに隠蔽性がなくなるわけではありませんでした。
インターフェイスがすっきりしないのが嫌なところですね。
設定値が多い時は、構造体に纏めてget/setするという事ですね。
- 78 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:08:13 ]
- そのたくさんある変数はすべてset/getする必要があるの？
内部実装のためにあるデータだってあるでしょ
外部から見たときにset/getする必要があるやつだけ
publicなsetter/getterを定義すればいいよ
- 79 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:30:04 ]
- vectorにクラスを入れるということは普通しないのでしょうか？
- 80 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:30:44 ]
- よくやる
- 81 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:37:08 ]
- むしろやらないでどうする
- 82 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:40:03 ]
- >>79
とても若干良くある
クラスのコピーコストが気になるレベルならポインタ格納するなりlist使うなりするけど。
- 83 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:49:29 ]
- >>60
明確な実装方法を表したサイトってないの？
- 84 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:51:39 ]
- クラスを入れる、っていう表現がまかり通るのが驚き。
- 85 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 17:58:08 ]
- >>83
そんなものはない！
- 86 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 18:03:51 ]
- #define class struct
オヌヌメ
- 87 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 18:09:34 ]
- >>71
なるほど
ちなみにスレッドプールしておいたスレッドの空き/使用中の管理というのは自分でやる必要があるのでしょうか？
- 88 名前：79 mailto:sage [2010/02/16(火) 18:25:17 ]
- よくやるんですね。ありがとうございます。
自分のプログラムで変なエラーが出てしまったので、もしかしたら間違ったやり方をしているのかと思いました。
できるんなら、何とかしてみます。
- 89 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 18:35:46 ]
- たぶんコピー、代入あたりで間違えてるんだろうな
- 90 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 18:43:27 ]
- pimplを勧める
- 91 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 18:45:18 ]
- #undef class
- 92 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 19:00:34 ]
- >>87
beginthread云々からWin32と仮定すると
IOCPに管理させるのが楽かもよ。
- 93 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 20:48:19 ]
- POSIXじゃないの？
- 94 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 21:25:46 ]
- おめーはpthreadも知らずWin32も知らないのか
- 95 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 22:00:15 ]
- 誰に言ってるんだ？
- 96 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 22:12:52 ]
- 誰が？
- 97 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 22:22:49 ]
- ワッフルワッフル
- 98 名前：97 mailto:sage [2010/02/16(火) 22:23:48 ]
- 誤爆しました。
- 99 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 22:24:19 ]
- え？
- 100 名前：デフォルトの名無しさん mailto:sage [2010/02/16(火) 22:25:08 ]
- ｗｗ
|
 |
