C++相談室 part78 - 暇つぶし2ch

C++相談室 part78 ..

2:デフォルトの名無しさん
10/02/13 23:20:55
■基本■
[C++ FAQ]
　URLﾘﾝｸ(www.parashift.com)
　URLﾘﾝｸ(www.bohyoh.com) (日本語)
　　Cとその仕様を比較しながらの解説なので分かりやすい。
　　***** 質問の前に必ずこの二つに目を通してください *****
[C/C++ リファレンス]
　URLﾘﾝｸ(www.cppreference.com) （英語）
　URLﾘﾝｸ(www.cppreference.com) （↑の日本語訳だけどまだ未完）
[禿 Stroustrup]
　URLﾘﾝｸ(www.research.att.com)
[C++ International Standard]
　URLﾘﾝｸ(www.iso.org)
[JTC1/SC22/WG21 - C++]
　URLﾘﾝｸ(www.open-std.org)
　　ここから規格の最新（2003より新しい）ドラフトがダウンロードできる。
[JIS X3014]
　URLﾘﾝｸ(www.jisc.go.jp)
　　ISO規格の日本語訳。JIS X 3014:2003はISO/IEC 14882:2003 (E)に対応。

3:デフォルトの名無しさん
10/02/13 23:24:24
■Libraries■
[Boost]
　Boost URLﾘﾝｸ(www.boost.org)
　(日本語) URLﾘﾝｸ(www.kmonos.net)
　(日本語) URLﾘﾝｸ(shinh.skr.jp)
[標準ライブラリ]
　SGI-STL URLﾘﾝｸ(www.sgi.com)
　STLport URLﾘﾝｸ(stlport.sourceforge.net)
　GNU libstdc++ URLﾘﾝｸ(gcc.gnu.org)
　Apache C++ Standard Library (STDCXX) URLﾘﾝｸ(stdcxx.apache.org)
　STLFilt URLﾘﾝｸ(www.bdsoft.com)
　(日本語) URLﾘﾝｸ(episteme.wankuma.com) （※1999年発行注意）
[Loki]
　URLﾘﾝｸ(sourceforge.net)
　LokiPort-MSVC6sp5 URLﾘﾝｸ(fara.cs.uni-potsdam.de)

4:デフォルトの名無しさん
10/02/13 23:28:14
■Books■
amazon.com　C,C++関連書籍
　URLﾘﾝｸ(www.amazon.com)

The C++ Programming Language
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) (翻訳)
C++ Primer (3rd Edition)
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) (翻訳)
The C++ Standard Library
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) (翻訳)
Effective C++
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) (翻訳)
More Effective C++
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) (翻訳)
Exceptional C++
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) (翻訳)
More Exceptional C++
　URLﾘﾝｸ(www.amazon.com)
Exceptional C++ Style
　URLﾘﾝｸ(www.amazon.com)

5:デフォルトの名無しさん
10/02/13 23:29:23
■Books(Templateまわり)■
Effective STL
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) （翻訳）
Modern C++ Design
　URLﾘﾝｸ(www.amazon.com)
　URLﾘﾝｸ(www.amazon.co.jp) （翻訳）
C++ Templates
　URLﾘﾝｸ(www.amazon.com)
C++ Template Metaprogramming
　URLﾘﾝｸ(www.amazon.com)

6:デフォルトの名無しさん
10/02/13 23:30:53
長いソースを貼るときはここへ。
　URLﾘﾝｸ(codepad.org)

7:v(^・^)v
10/02/13 23:36:05
基本のリンクは少し更新しといた。あと Libraries のリンクを復活させといた。

後は好きにして。

8:デフォルトの名無しさん
10/02/13 23:48:06
近縁スレでも貼る？

　【初心者歓迎】C/C++室 Ver.71【環境依存OK】
　ｽﾚﾘﾝｸ(tech板)
　初心者はこちらへ

　C言語なら俺に聞け（入門編）Part 60
　ｽﾚﾘﾝｸ(tech板)
　C言語はこちらへ

ぐらいか？

9:デフォルトの名無しさん
10/02/14 02:08:30
前スレの話だけど、関数テンプレートならinline付けずに
ヘッダに定義書いても全然問題ないことをどっちか片方が知らないように感じた。
俺の誤解だといいんだけど。

10:デフォルトの名無しさん
10/02/14 08:16:00
>>9 さすがにそれは無いでしょ。それだと判断基準以前の話になってるはず。

11:デフォルトの名無しさん
10/02/14 09:26:00
前スレの方が上とはけしからん

age

12:デフォルトの名無しさん
10/02/14 09:59:23
STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

13:デフォルトの名無しさん
10/02/14 10:06:33
ところで現在のC++0xは
いつ頃正式なC++になるんですか？

14:デフォルトの名無しさん
10/02/14 10:12:35
2011年10月23日2時13分25秒頃

15:デフォルトの名無しさん
10/02/14 10:19:30
VS2010はSP1で完全対応してくれるんかいな

16:デフォルトの名無しさん
10/02/14 17:31:43
>>12
地鎮乙

17:デフォルトの名無しさん
10/02/14 19:14:00
if else文で文字列のパターンを32個
チェックするのが、どうにも気持ち悪いのですが
何か別の方法はないでしょうか？

18:デフォルトの名無しさん
10/02/14 19:15:46
関数ポインタとの連想配列作るとか

19:デフォルトの名無しさん
10/02/14 19:16:36
パターンを配列に入れてループ

20: ◆GWRSHcLrd6
10/02/14 19:18:15
どうも。
スマートポインタにメモリプールを実装してみました。
(なんか保守的GCみないな感じになりましたが・・・)

まだうｐしてませんが(随分汚いので)、ベンチだけ取ってみました。

21:デフォルトの名無しさん
10/02/14 19:21:35
で、ベンチは？

22: ◆GWRSHcLrd6
10/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:デフォルトの名無しさん
10/02/14 19:30:10
既存の実用アプリでレポ

24:デフォルトの名無しさん
10/02/14 19:30:31
まずはスマポのソースうｐ

25:デフォルトの名無しさん
10/02/14 20:03:40
C++ではメソッドチェーンを、あんまり使わないんだね

26:デフォルトの名無しさん
10/02/14 21:01:28
>>25
多用されてるでしょ。主にoperator系、特にストリーム操作とか。
印象は違うかもしれないけどオブジェクトのメソッドがオブジェクト自身を返して連鎖していくって意味では
まさにメソッドチェーン。

27: ◆GWRSHcLrd6
10/02/14 21:03:39
メモリプールの仕組みがこんなんなんですけど、効率のいい方法はどんなのが
あるんですか？

URLﾘﾝｸ(cdtest.genin.jp)

>>25
効率が悪いからでは？

28:デフォルトの名無しさん
10/02/14 21:10:01
>>27
このスマポってライセンス何なの？
まだ考えてない？

29: ◆GWRSHcLrd6
10/02/14 21:15:53
ま、まだ考えてないです・・・
ライセンスは何がいいんでしょう・・・？

30:デフォルトの名無しさん
10/02/14 21:20:00
ただの習作でしょ。
実用プログラムに組み込みたいと思ってる奴なんて要るの？

31:デフォルトの名無しさん
10/02/14 21:21:41
Googleのメモリ管理でいい。tcmallocとかいうやつ

32:デフォルトの名無しさん
10/02/14 21:21:48
アロケートしたメモリのバイト数分だけジェリービーンズで支払う

33:デフォルトの名無しさん
10/02/14 21:29:51
まだソース見ないから分からないけど
NYSLライクなら昔作ったスレッドセーフ用のスマポと比較して
性能が良かったら使おうと思った
ライブラリに合わせて改変することになるだろうからLGPLとかだと無理なんだけど
この先も色々評価して高速化するなら需要はあるんじゃね？

34:デフォルトの名無しさん
10/02/14 21:32:57
>>27
こんなの遅くて使いものにならんでしょ。
以下の問いに対して、少なくともdlmallocよりも高効率なのかよw？

こんな糞データ構造で、メモリの空き領域をどうやって効率的にさがせる
のか答えてみろよw？これじゃ単なる線形リストだろw

このスレに2度と来るないいな？わかったか？

35:デフォルトの名無しさん
10/02/14 21:35:20
>>34
>>27 の質問を良く見てみろ

36: ◆GWRSHcLrd6
10/02/14 21:35:44
>>30 >>33
まあ、これから頑張って独自性がでるようになってきたら、
ライセンスをつけたいと思います。
それまでは改変自由で（まだ大したものじゃないですしね）。

>>31
tcmalloc、ググりました。
こういうアロケートの仕方もあるんですね。
でもあれってアロケートはシステムコールとかで
バリバリにコーディングされているのかな？

ちょっとコード見てきます。

37: ◆GWRSHcLrd6
10/02/14 21:37:33
>>34
申し訳ないです・・・

38:デフォルトの名無しさん
10/02/14 21:37:45
>>34
突然どうした
ちょっと落ち着け

39:デフォルトの名無しさん
10/02/14 21:38:24
速度はたいした問題でない。既にある物より圧倒的に遅いなら別だが。
安定していて使いやすいこと。
しかしGoogleのメモリ管理もあまり流行ってないし、普及させられるほどの価値ある物は出来ないと思う。
メモリプールしても全体の速度向上はほとんど望めない。
普及させられるとしたら、boost互換のインターフェースでboostよりメリットがあること。

40:デフォルトの名無しさん
10/02/14 21:42:38
>>36
メモリ操作のみなら、Googleのメモリ管理は超速だが
実際にアプリに組み込むと何の変化も出ない。
現実アプリはメモリの生成・解放ばかりしていない。
プールはおまけにするか、Google任せにしてスマートポインタ開発のほうが
需要出ると思う。

41:デフォルトの名無しさん
10/02/14 21:54:29
Googleはこんなこともしてたのか知らんかった。
ちょっと見てみたけどtcmallocって改良版dlmallocみたいなのか。

42:デフォルトの名無しさん
10/02/14 22:48:55
>>27
線形以外の探索ってどんなのがいいのかねぇ

43:デフォルトの名無しさん
10/02/14 22:59:37
>>27
このプールから削除する場合はどうなるんだ？使い捨て？

44:デフォルトの名無しさん
10/02/14 23:04:19
>>42
最速の固定長の小メモリブロックアロケータは simple segregated storage だとわかりきっている。
探索しないでいい。

45:デフォルトの名無しさん
10/02/14 23:36:17
ヒープメモリーにヒープ構造を！w

46:デフォルトの名無しさん
10/02/14 23:50:34
boost::shared_ptrにもメモリプールを使うオプションがあったような

47: ◆GWRSHcLrd6
10/02/14 23:54:13
>>43
inner_ptrの方でゼロ初期化され、新たなアロケートで再利用されます。

というかカウント0のものはゴミとみなして新しくAllocした時にそれを使います。

で、ブロックが空、なおかつ、ブロックを多く確保しすぎている場合は
そのブロックはdeleteされて前後のブロックをリストで繋ぎます。

>>45
そうなんですよｗ

48:デフォルトの名無しさん
10/02/14 23:59:54
じぶんに考え。

N 十分大
char* p[0]・・・p[N] メモリブロック
メモリの使用状態を1ビットで表す　00011100010101000000
連続領域が必要なら0の連続を選択。
はじめはp[i]はNULLにしておく。

49: ◆GWRSHcLrd6
10/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:デフォルトの名無しさん
10/02/15 00:00:37
>>47
いったい何を目指しているの？

メモリブロック確保の速度なんて operator new の実装に任せておけばいいこと。
そんなところをがんばるよりも、他にすることは無いの？

51: ◆GWRSHcLrd6
10/02/15 00:01:08
って感じです。

52:デフォルトの名無しさん
10/02/15 00:02:15
カオス

53: ◆GWRSHcLrd6
10/02/15 00:02:56
>>50
すいません。高速化しようと思って少しそれてしまいました・・・

54:デフォルトの名無しさん
10/02/15 00:03:49
マルチスレッドでメモリ探索にロック掛けると速度落ちると思うから
キューに入れて順番に処理すると良い思うが、キューへのアクセスにロックが必要
ロック無しにする方法ないか。

55:デフォルトの名無しさん
10/02/15 00:05:52
wait-free lock-freeのwikiみると、アトミック命令使えばロック無しのマルチスレッドできるらしいが。

56:デフォルトの名無しさん
10/02/15 00:07:06
operator new よりGoogleメモリ管理の方が高性能。

57:デフォルトの名無しさん
10/02/15 00:08:51
>>54 URLﾘﾝｸ(www.google.co.jp)

58:デフォルトの名無しさん
10/02/15 00:09:43
>>56
なら operator new を Google メモリ管理で置き換えればいいじゃない。

59:デフォルトの名無しさん
10/02/15 00:23:34
>>57
実装方法わからん。cas命令らしいけど

60:デフォルトの名無しさん
10/02/15 00:46:42
マルチコア時代のLock-free入門
URLﾘﾝｸ(www.slideboom.com)
これによると std::shared_ptr (C++0x) はとてつもなく遅くて使えんとあるな。
だから Hazard ポインタを使えともある。

61:デフォルトの名無しさん
10/02/15 01:01:25
>>60
スマートポインタでLock-freeにするには？という話なのに、
Lock-freeを実現するために使用するスマートポインタの話をするのは順番が逆でしょう。

でも >>60 のような用途に使える軽快なスマポは確かに欲しいけど。

62:デフォルトの名無しさん
10/02/15 01:14:46
CAS命令は結構コストかかるのよ。
可能なら、RCU的な手法にする方が良い。

URLﾘﾝｸ(www.atmarkit.co.jp)
みたいな記事もある。

63:デフォルトの名無しさん
10/02/15 23:47:17
RCUってなあに？

64:デフォルトの名無しさん
10/02/15 23:48:21
正直
マルチコア時代
を相手にするならスマポのコストが問題となることは
大抵ないと思うんだが。

65:デフォルトの名無しさん
10/02/15 23:49:25
>>63
記事の中よめよ
リンク先にまるなげだけどちゃんとあるだろう
Wikipedia項目ﾘﾝｸ

66:デフォルトの名無しさん
10/02/15 23:55:18
で、依存無しのCASとかRCUとかはどう実装するんだ？

67:デフォルトの名無しさん
10/02/16 00:06:35
無理無理

68:デフォルトの名無しさん
10/02/16 00:59:05
>>64
マルチコア関係なくね？

69:デフォルトの名無しさん
10/02/16 01:48:54
>>64
おい！

70:デフォルトの名無しさん
10/02/16 08:04:43
通信系の処理プログラムを書いてるんですが
処理担当スレッドを作る場合、必要になったらbeginthread（もしくはbeginthreadex)で
スレッドを起動して作業が終わったらおしまいとするのとスレッドプールをするのでは
どちらがいいのでしょうか？

71:デフォルトの名無しさん
10/02/16 13:05:40
>>70
頻繁に起動終了を繰り返すようなものならスレッドプールが良いと思うよ。
スレッドの生成破棄もコストはあるからね。

72:デフォルトの名無しさん
10/02/16 15:32:45
getter/setterについて悩んでいます。

●getterについて
・setterに対してgetterも用意されていたら、隠蔽になっていないのではないか？
・利用者がsetした時の情報を保持すればgetterはいらないのではないか？
●setterについて
・コンストラクタの引数で受け取る物は、setterも用意したくなるが同じ機能を２箇所に書いている感が？

書いたクラスが各メンバ変数に対してgetter/setterが存在する物になっていると、
無駄に手間をかけただけの構造体なんじゃないかと不安になります。
必要十分なgetter/setterを持つクラスを設計するには、どういう事を考えればいいのでしょうか？

73:デフォルトの名無しさん
10/02/16 15:45:03
>>72
>・setterに対してgetterも用意されていたら、隠蔽になっていないのではないか？

なんでそうなる
他にもいろんなprivate変数持ってる場合がほとんどだろ

74:デフォルトの名無しさん
10/02/16 15:54:44
>>73
「コンストラクタも含めて外部からget/setされないメンバ変数」を持たないクラスも多いです。
10個近くの設定値が必要なクラスとか、コードのうちgetter/setterが占める割合が多くなって、「なんだかなー」と思います。

75:デフォルトの名無しさん
10/02/16 15:59:39
そう思うなら思い切ってpublic変数にすればいいだろ
でもgetter/setterを敢えて持つ理由は、プログラマに「今private変数を
いじってますよ」という事を常に意識させる効果がある

76:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/02/16 16:39:05
>>75
一貫性がないのは嫌なので、public変数にするとなると全てのクラスをpublic変数にする事になって、これも嫌な感じがします。

>>76
確かに隠蔽性がなくなるわけではありませんでした。
インターフェイスがすっきりしないのが嫌なところですね。

設定値が多い時は、構造体に纏めてget/setするという事ですね。

78:デフォルトの名無しさん
10/02/16 17:08:13
そのたくさんある変数はすべてset/getする必要があるの？
内部実装のためにあるデータだってあるでしょ

外部から見たときにset/getする必要があるやつだけ
publicなsetter/getterを定義すればいいよ

79:デフォルトの名無しさん
10/02/16 17:30:04
vectorにクラスを入れるということは普通しないのでしょうか？

80:デフォルトの名無しさん
10/02/16 17:30:44
よくやる

81:デフォルトの名無しさん
10/02/16 17:37:08
むしろやらないでどうする

82:デフォルトの名無しさん
10/02/16 17:40:03
>>79
とても若干良くある
クラスのコピーコストが気になるレベルならポインタ格納するなりlist使うなりするけど。

83:デフォルトの名無しさん
10/02/16 17:49:29
>>60
明確な実装方法を表したサイトってないの？

84:デフォルトの名無しさん
10/02/16 17:51:39
クラスを入れる、っていう表現がまかり通るのが驚き。

85:デフォルトの名無しさん
10/02/16 17:58:08
>>83
そんなものはない！

86:デフォルトの名無しさん
10/02/16 18:03:51
#define class struct
オヌヌメ

87:デフォルトの名無しさん
10/02/16 18:09:34
>>71
なるほど
ちなみにスレッドプールしておいたスレッドの空き/使用中の管理というのは自分でやる必要があるのでしょうか？

88:79
10/02/16 18:25:17
よくやるんですね。ありがとうございます。
自分のプログラムで変なエラーが出てしまったので、もしかしたら間違ったやり方をしているのかと思いました。
できるんなら、何とかしてみます。

89:デフォルトの名無しさん
10/02/16 18:35:46
たぶんコピー、代入あたりで間違えてるんだろうな

90:デフォルトの名無しさん
10/02/16 18:43:27
pimplを勧める

91:デフォルトの名無しさん
10/02/16 18:45:18
#undef class

92:デフォルトの名無しさん
10/02/16 19:00:34
>>87
beginthread云々からWin32と仮定すると
IOCPに管理させるのが楽かもよ。

93:デフォルトの名無しさん
10/02/16 20:48:19
POSIXじゃないの？

94:デフォルトの名無しさん
10/02/16 21:25:46
おめーはpthreadも知らずWin32も知らないのか

95:デフォルトの名無しさん
10/02/16 22:00:15
誰に言ってるんだ？

96:デフォルトの名無しさん
10/02/16 22:12:52
誰が？

97:デフォルトの名無しさん
10/02/16 22:22:49
ワッフルワッフル

98:97
10/02/16 22:23:48
誤爆しました。

99:デフォルトの名無しさん
10/02/16 22:24:19
え？

100:デフォルトの名無しさん
10/02/16 22:25:08
ｗｗ

101:デフォルトの名無しさん
10/02/16 22:38:45
うむ。苦しゅうない。

102:デフォルトの名無しさん
10/02/17 00:38:25
何の？

103:デフォルトの名無しさん
10/02/17 01:05:07
>>53
以前メモリプール使用のスマポで計測結果張ったものですが、こんなメモリプールつこてます。
URLﾘﾝｸ(codepad.org)
メモリ的にも処理的にも無駄を減らした実装でまだまだシンプルですが、使えるポイントはあると思います。

104:デフォルトの名無しさん
10/02/17 01:11:05

int get()
{
return mVal;
}

これよりも効率よくmValを外部に返す方法ってありますか？

105:デフォルトの名無しさん
10/02/17 01:17:18
>>72
まずインターフェースだけ考える。どんな変数を持ってるとかは敢えて考えないぐらいのつもりで、
とにかく利用者にとって自然な操作だけをメンバ関数（コンストラクタ含む）として列挙する。

それが済んでから、それらのメンバ関数を実装するための変数を必要なだけそろえる。

これなら「隠蔽になっていない」などという心配は起こりようが無いし、余計なコードも発生しない。

インターフェースを考える段階で、利用者から見て中にどんなデータが入っているのか
明らかでありメンバ関数呼び出しが煩雑なだけに見えるようなら、ただの構造体でいい。

106:デフォルトの名無しさん
10/02/17 01:38:40
>>103
Test継承したら使えないジャマイカ

107:デフォルトの名無しさん
10/02/17 02:06:51
>>104 ねーよｊｋ

108:デフォルトの名無しさん
10/02/17 02:13:11
>>104
#define get() mVal

foo.get();

109:デフォルトの名無しさん
10/02/17 04:46:59
スレッドセーフなキューが作れれば全てのマルチスレッドは統一的に扱えるはず
とおもって探した。
lock-free wiat-freeかはしらないがこれ。無料だとこれくらいかと。

Thread Safe Template Library
URLﾘﾝｸ(sourceforge.jp)

IntelR Threading Building Blocks
URLﾘﾝｸ(www.threadingbuildingblocks.org)

110: ◆GWRSHcLrd6
10/02/17 07:22:13
>>103
あ、なんか僕が今作りなおしているやつも似た作りです。
これが効率よさそうですよね。

そういえばboostのsimple_segregated_storage(だっけ？)ってどういう仕組み何でしょうか？

>>109
なるほど。ちょいと見てみます

111:デフォルトの名無しさん
10/02/17 10:38:15
可変長引数パラメータて、使いどころがよくわからないんですが
どういった時に使うんでしょうか？
同じようなことができるboostのfunctionもです。

掴み所を教えてください

112:デフォルトの名無しさん
10/02/17 10:58:46
>>111
可変長引数パラメータって何？
関数引数の ... のこと？

113:デフォルトの名無しさん
10/02/17 11:23:46
>>112
そうです。
使い方はわかるし、boostも使い方は理解できるんですが
何に使うのかがわからないんです。

特に後者のboostは、仮想関数の引数としてfunctionを利用しても
結局テンプレートだからオーバーロードになるわけですよね？
呼び出し側で型指定するわけですし、多態的に動作させるのもできないのでは？

ここで混乱している感じです。

114:デフォルトの名無しさん
10/02/17 11:26:48
>>113
printf() とか。
まぁ C++ では基本的に使わないな。

boost::function とは関係ないと思うけど、何のこと言ってんの？

115:デフォルトの名無しさん
10/02/17 11:32:54
>>114
返り値の型、引数の型を指定して関数ポインタを楽に生成できるじゃないですか。

このテクニックを利用して、引数の数、型が変化する処理を多態的にさせたいんです。

116:デフォルトの名無しさん
10/02/17 11:43:01
>>113
可変長引数に関しては>>114に同じくprintfがいい例だと思う。
可変長引数は、C++ではあまり推奨おらず、printfに関してもboost::formatを使った方がいい。
URLﾘﾝｸ(www.kmonos.net)

boost::functionに関しては、引数の型(個数も含む)が違えば、boost::functionの型も変わる(boost::functionはクラステンプレートであってクラスそのものではない)。
テンプレートによる静的多態なので、仮想関数の動的多態のようには扱えない。

117:116
10/02/17 11:55:42
付け加えておくと、
・可変長引数とboost::functionの使いどころは別である
・boost::functionは関数ポインタを使いやすくした物

あと、>>116の最後の行は紛らわしい書き方だった。
boost::functionの１つの具現化(戻り値と引数の型が同じ)においては、関数ポインタによる動的多態である。

118:デフォルトの名無しさん
10/02/17 12:11:45
>>117
なるほど！
多態とはまた別物なんですね。
ボリモルフィズムが一気に広がるかもと思ったんですがね。

ありがとうございました。

119:デフォルトの名無しさん
10/02/17 12:22:49
>>115
boost::function<void ()> で、引数は全部 bind するとか、
boost::function<void (std::vector<boost::any> const&)> で引数について型消去しながらやりくりするとか。

120:デフォルトの名無しさん
10/02/17 13:01:27
(´；ω；｀)さ、さ、さむいお

121:デフォルトの名無しさん
10/02/17 13:22:58
利用者が仮想関数を呼び出す時、仮想関数の実装を知らなけば引数を渡せなくなって、ポリモーフィズムのメリットがなくなる気がするけど。

122:デフォルトの名無しさん
10/02/17 14:15:09
いらない

123:デフォルトの名無しさん
10/02/17 15:13:58
非ブロッキング、ロックフリー、ウェイトフリーの定義

URLﾘﾝｸ(www.gameenginejp.com)

124:デフォルトの名無しさん
10/02/17 15:37:29
スレッドセーフのSTLクラスは使えるな。
boostのどのライブラリより上では。
boostにこんなのないだろ。

125:デフォルトの名無しさん
10/02/17 15:45:26
ありますがな・・・

126:デフォルトの名無しさん
10/02/17 15:46:17
ありませんがな・・・

127:デフォルトの名無しさん
10/02/17 15:50:33
TBBの日本語サンプルサイトつくってくれよ。
マルチコア時代で、CPUメーカー製の、フリーのこのライブラリは強力すぎる。
できたら毎日クリックしに行くからさ。

Wikipedia項目ﾘﾝｸ

抜粋

並列処理アルゴリズム
parallel_for　ループ間で依存性がない単純なループの並列処理
parallel_reduce　指定した範囲をより小さな範囲に再帰的に分割し並列処理
parallel_scan　並列プリフィックスを計算
parallel_while　不明領域、動的領域変更を伴う独立したループ操作
parallel_sort　並列処理でソートを行う
pipeline　パイプライン処理

コンテナクラス
concurrent_hash_map　STLのmapクラスをスレッドセーフにしたもの
concurrent_queue　STLのqueueクラスをスレッドセーフにしたもの
concurrent_vector　STLのvectorクラスをスレッドセーフにしたもの

128:デフォルトの名無しさん
10/02/17 16:13:42
サンプルはないけど日本語リファレンスあるし間に合ってる感じ

129:デフォルトの名無しさん
10/02/17 18:53:08
もうひとつだけ例を見てみましょう。
static LONG flag;
if (flag == FALSE) {
flag = TRUE;
...
flag = FALSE;
}

このコードがまずいことはもうお分かりですね。 NT にはフラグのチェックとセットをアトミックに行える InterlockedCompareExchange がありますから、そちらを使いましょう。
if (InterlockedCompareExchange(&flag, TRUE, FALSE) == FALSE) {
...
InterlockedExchange(&flag, FALSE);
}

URLﾘﾝｸ(hp.vector.co.jp)

130:デフォルトの名無しさん
10/02/17 18:58:30

8スレッド
InterlockedIncrement 4.398sec
InterlockedCompareExchange 4.460sec
CriticalSection 6.297sec
URLﾘﾝｸ(d.hatena.ne.jp)

VC++ CriticalSectionの速度
何もないループが、0.515106秒に対しクリティカルセクションでは7.089556秒となった。
URLﾘﾝｸ(www.cycleof5th.com)

同期オブジェクトの要約
速度
クリティカルセクション高
ミューテックス低
セマフォ低
イベント低
メータードセクション高
URLﾘﾝｸ(msdn.microsoft.com)

131:デフォルトの名無しさん
10/02/17 19:08:05
スレッドセーフなキューを複数個用意してキューにデータ来たら、
それぞれ直列に動作する関数を動かしたいんだけど
作業が終わったらキューを観察に行くけど無かった場合、次に入ってくるまで
どうやってまてばいいんだ? ひとつとしてビジーループはあるが。
それなら別変数用意してロック掛けた方が良い。ロック無しで出来る?
キューは一カ所にしてすべての処理関数スレッドで共有する方が無駄ないか。

132:デフォルトの名無しさん
10/02/17 19:22:53
キューに挿入する側が、余りのスレッドを監視して空いてたら処理させればいいか。
これならロック無しでアトミック命令だけでいけそう。

133:デフォルトの名無しさん
10/02/17 19:24:54
しかしスレッドを生成するコストも馬鹿にならないから
スレッドの生成・消滅はせず、恥に生成したやつを使い回したいところ。
やっぱロックいるか。処理終了してキュー待ちのロック。

134:デフォルトの名無しさん
10/02/17 19:27:47
スレッドの生成は恥

135:デフォルトの名無しさん
10/02/17 19:41:16
wait付きのビジーループでいいか

136:デフォルトの名無しさん
10/02/17 20:32:25
C++でコルーチンってできないの？

137:デフォルトの名無しさん
10/02/17 20:32:53
boostにあるにょ

138:デフォルトの名無しさん
10/02/17 20:35:08
あるんだ
boostまじ何でもあるな
奴らはいったい誰と戦ってるんだ

139:デフォルトの名無しさん
10/02/17 20:37:11
言われてみるとその言葉かなりしっくりくるよな。
C++の最適化に伴う変態記法なんて禿に親を殺されでもしない限りできないし。

140:デフォルトの名無しさん
10/02/17 20:39:02
>>138
部品の足りない世界じゃないの？

というかWTLもC#並に充実させてください

141:デフォルトの名無しさん
10/02/17 20:45:06
駆動系の部品はハイスペックだが
シートもハンドルもなく部品丸出しの車

142:デフォルトの名無しさん
10/02/17 20:47:45
C++はC++です車ではありません
好い加減な比喩は滑稽なのでやめてください

143:デフォルトの名無しさん
10/02/17 20:48:41
コルーチン
Wikipedia項目ﾘﾝｸ

Boost C++の何て言うライブラリで出来るのですか？

144:デフォルトの名無しさん
10/02/17 20:49:43
boost.cotoutine
vaultにあるにょ

145:デフォルトの名無しさん
10/02/17 20:52:04
>>141
部品丸出しな上
自己責任で組み替え自由な仕様だな。

146:デフォルトの名無しさん
10/02/17 20:52:32
>>141
部品丸出しな上
自己責任で組み替え自由な仕様だな。

147:デフォルトの名無しさん
10/02/17 20:52:41
>>141
部品丸出しな上
自己責任で組み替え自由な仕様だな。

148:デフォルトの名無しさん
10/02/17 20:53:21
車への例えがどれも的外れでワロスｗ

149:デフォルトの名無しさん
10/02/17 20:53:33
>>141
部品丸出しな上
自己責任で組み替え自由な仕様だな。

150:デフォルトの名無しさん
10/02/17 20:55:48
だからといってヨソの車がそんなに安全かというと……

151:デフォルトの名無しさん
10/02/17 20:57:31
>>144
valtですか。
ありがとうございます。

152:デフォルトの名無しさん
10/02/17 20:58:22
Boost.Coroutine
URLﾘﾝｸ(hamigaki.sourceforge.jp)

2009-12-12 - melpon日記 - C++すら（ｒｙ
Boost][C++]Boost.勉強会の資料
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(melt.sytes.net)
・Boost.Fiber という対抗馬も最近出てきた

153:デフォルトの名無しさん
10/02/17 20:59:10
理想的には部品丸出しではないが、
バカが作ると部品を理解していなければならなくなる
仕様だな。

154:デフォルトの名無しさん
10/02/17 21:06:26
マルチスレッドキューでロックしないサンプルできた。読み込むに失敗・キューがないときにwaitはいれたが。

#include "include/tbb/concurrent_queue.h"
#pragma comment (lib, "tbb.lib")
#include <process.h>
#include <windows.h>
#include <iostream>
using namespace std;
using namespace tbb;

concurrent_queue<int> que;
int s[2]={0,0};

unsigned WINAPI fnc(void *n) {
int x,num=(int)n;
while(1) {
if( !que.try_pop(x) ) { Sleep(100); continue; }
if(x==-1)return 0;
s[num]+=x; }
}

int main() {
HANDLE hd[2];
int n;
for(n=0; n<2; n++) hd[n]=(HANDLE)_beginthreadex(NULL, 0, fnc,NULL, n ,NULL);
for(n=0; n<=1000; n++) que.push(n);
que.push(-1); que.push(-1);
WaitForMultipleObjects(2, hd, TRUE, INFINITE);
cout<< s[0]+s[1]<<endl;
getchar(); }

155:デフォルトの名無しさん
10/02/17 21:08:51
0から1000まで足すだけ。キューへマルチスレッドでpush、popして
読み取って空いてるスレッドが足し合わせていくサンプル。
答えは合ってたよ。

156:デフォルトの名無しさん
10/02/17 21:10:28
キューではロックしているだろうがな。そこを自作せずに済んだという話だ。

157:デフォルトの名無しさん
10/02/17 21:20:49
プログラム組んでて
returnって打ったつもりだったら

tryit,

って打ってた
なんか感動した

158:デフォルトの名無しさん
10/02/17 21:21:46
rをtにずらして打ってみると・・・！？

159:デフォルトの名無しさん
10/02/17 21:22:04
ゴルゴはtrycatchfinallyを0.5秒でタイプするらしい

160:デフォルトの名無しさん
10/02/17 21:23:35
>>157
夢を感じた

161:デフォルトの名無しさん
10/02/17 21:33:09
HDL ではごく普通というか大前提の話なんだが
直列処理という枠に凝り固まった頭で見ると驚きの連続なんだろうな

162:デフォルトの名無しさん
10/02/17 21:39:17
任意の整数を返す関数が、失敗も正常フローだった場合に
すっきりするエラー通知の仕方はある？

163:デフォルトの名無しさん
10/02/17 21:40:28
任意の整数を返す関数が、失敗も正常フローだった場合に
すっきりするエラー通知の仕方はある？

164:デフォルトの名無しさん
10/02/17 21:42:11
任意の整数を返す関数が、失敗も正常フローだった場合に
すっきりするエラー通知の仕方はある？

165:デフォルトの名無しさん
10/02/17 21:45:58
任意の整数を返す関数が、失敗も正常フローだった場合に
すっきりするエラー通知の仕方はある？

166:デフォルトの名無しさん
10/02/17 21:46:42
パラメータになんか持たせるとか

167:デフォルトの名無しさん
10/02/17 21:57:56
なにを？

168: ◆GWRSHcLrd6
10/02/17 22:01:15
_beginthreadとCreateThreadは何が違うんですか？
というかどっちを使った方がいいんですか？

169:デフォルトの名無しさん
10/02/17 22:07:13
>>167
判断できる情報を

>>168
適材適所。常にどちらかがよいということはない

170:デフォルトの名無しさん
10/02/17 22:11:21
C++の配列サイズ指定で変数は使えることもあるんでしょうか？それともコンパイラ依存でしょうか？
MinGWで下をコンパイルは正常にでき（Warningも出ない）、arrayのsizeofは32byteとなってちゃんと確保されているようです。

#include <iostream>
using namespace std;
int main() {
int num = 3 + 5;
int array[num];
for (int i = 0; i < num; i++) {
array[i] = i;
}
cout << sizeof array << endl;
}

171:デフォルトの名無しさん
10/02/17 22:12:44
正確にはC++ではなくC99で使える様になったはず

172:デフォルトの名無しさん
10/02/17 22:18:32
>>170
gccの独自拡張

173:デフォルトの名無しさん
10/02/17 22:25:20
>>168
CreateThreadはWindowsAPI、_beginthreadはCランタイム。

CreateThreadで生成したスレッドでCランタイム関数を使うとExitThreadしたときにわずかだがメモリリークが発生するため、
MSはそのような場合には_beginthreadを使うように推奨している。

174: ◆GWRSHcLrd6
10/02/17 22:32:21
なるほど。
参考になりました。

unix - windows 互換のスレッド関係の関数は無いんですかね・・・

175:デフォルトの名無しさん
10/02/17 22:38:29
Cランタイムって何？

176:154
10/02/17 22:41:42
修正。引数渡す場所間違えて一スレッドしか動いていない。
#include "include/tbb/concurrent_queue.h"
#pragma comment (lib, "tbb.lib")
#include <process.h>
#include <windows.h>
#include <iostream>
using namespace std;
using namespace tbb;
#define N 3
concurrent_queue<int> que;
int s[N];
unsigned WINAPI fnc(void *n) {
int x,num=(int)n;
while(1) {
if( !que.try_pop(x) ) { Sleep(100); continue; }
if(x==-1){ cout<<"正常終了number:"<<num<<endl; return 0;}
s[num]+=x;Sleep(rand()%50); }}

int main() {
HANDLE hd[N];
int n;
for(n=0; n<N; n++) s[n]=0;
for(n=0; n<N; n++) hd[n]=(HANDLE)_beginthreadex(NULL, 0, fnc, (void*)n, 0 ,NULL);
for(n=0; n<=50; n++) que.push(n);
for(n=0; n<N; n++) que.push(-1);
WaitForMultipleObjects(N, hd, TRUE, INFINITE);
int sum=0;
for(n=0; n<N; n++) {cout<< "スレッド"<<n <<"の合計 "<<s[n]<<endl; sum+=s[n]; }
cout<<"総和 "<<sum<<endl;
getchar(); }

177:デフォルトの名無しさん
10/02/17 22:44:40
>>174
pスレッド windowsというのがあるが、おすすめしない。
一度にアクセスが起きるとバグった経験有り。同じ物をwindowsの命令に書き換えたら動いた。
スレッドのどれか一つ　or全部の終了待ちがない気がする。

178:デフォルトの名無しさん
10/02/17 22:47:23

Open Source　POSIX Threads for Win32
URLﾘﾝｸ(sourceware.org)

179:デフォルトの名無しさん
10/02/17 22:51:55
一時期windowsであっても、linuxの互換コードで書くべきだという考えが起こり
全て統一しようとしたがPthread for winがうまく動作しないので諦めた経験ある。
現在の環境で生産性の良い、短いコードで済ますのが一番という考えになった。
完成品が出来なければ意味ない。完成していれば他OSへも移植しやすい。

180:デフォルトの名無しさん
10/02/17 23:00:42
QtやBoostその他ラッパライブラリじゃできないの？

181:デフォルトの名無しさん
10/02/17 23:02:56
Qtもboostも標準にはいってないじゃん
サイズもでかいし
linuxでどこでも使えるのはPthreadだけでは

182:180
10/02/17 23:07:16
>>181
その方、Pthreadはいつから標準になったと申すか。

183:デフォルトの名無しさん
10/02/17 23:09:31
POSIX Threads, or Pthreadsのライセンスは
This implementation is free software, distributed under the GNU Lesser General Public License (LGPL).

え？誰も聞いてないって？

184:デフォルトの名無しさん
10/02/17 23:13:49
入ってないlinuxはないんでは。c/c++がコンパイル可能な環境なら。

185:デフォルトの名無しさん
10/02/17 23:16:36
標準っていうか、プリインストールって言いたかったわけか。

186:デフォルトの名無しさん
10/02/17 23:18:22
ち、違うよ。

187:デフォルトの名無しさん
10/02/18 00:57:43
どっちもbccでうごかん。　
lock-freeの高速キューを作ってくれよ。
インラインアセンブラ・マクロの特殊構文の多用が原因と思われる。
windows 標準のcas命令のみで頼む。

Thread Safe Template Library
URLﾘﾝｸ(sourceforge.jp)

Intel Threading Building Blocks
URLﾘﾝｸ(www.threadingbuildingblocks.org)

188:デフォルトの名無しさん
10/02/18 01:43:02
bccなんてポンコツ捨てろよ

189:デフォルトの名無しさん
10/02/18 04:41:14
bccは毎年新規で販売してるんだぞ。
コンパイル速度速くて良いんだこれは。

190:デフォルトの名無しさん
10/02/18 04:49:50
httpサーバーなどへIf-Modified-Sinceをつける場合statでファイルの更新日付を
取得してどのように変換すればいいのでしょうか？

日本時間に直すサンプルは見かけるのですがGMTのまま文字列化する方法が
わかりません

191:デフォルトの名無しさん
10/02/18 08:08:13
スレッドセーフキューがマルチスレッドの要なんです
マクロやアセンブラ使わずに書いてくれると喜ばれますよ

192:デフォルトの名無しさん
10/02/18 08:22:15
STLportがスレッドセーフなSTLだった
これつかお

193:デフォルトの名無しさん
10/02/18 11:43:35
わざわざいうな

194:デフォルトの名無しさん
10/02/18 15:34:49
>>190
strftimeじゃできないの？

195:デフォルトの名無しさん
10/02/18 19:14:32
プロの方はスマートポインタを使うのが基本とのことですが、例えば引数なんかも
hoge( shared_ptr<Test>& sp )といったかんじになるんでしょうか？
それとも受け渡しは生のポインタで行い、オブジェクト側でスマートポインタに格納ような
使い方ですか？

196:デフォルトの名無しさん
10/02/18 19:44:09
参照渡しだよ

197:デフォルトの名無しさん
10/02/18 20:07:01
STLportがbccでコンパイルできん

198: ◆GWRSHcLrd6
10/02/18 20:43:01
>>195
僕はクラスのメンバ関数が前提なら、
関数を所有するクラスがオブジェクトをメンバ変数に保持するときはスマートポインタを、
一時的に使うだけなら参照で渡します。

>それとも受け渡しは生のポインタで行い、オブジェクト側でスマートポインタに格納ような
一番やっちゃいけない気がするんですけど・・・

199:デフォルトの名無しさん
10/02/18 21:44:30
>>171 >>172
アドバイスありがとうございます。
手元のどの参考書見ても変数は使えないと書いてあってあれ？と思っていたしだいです。
Visual C++で使えないようなのでgccだけなんですね。

200:デフォルトの名無しさん
10/02/18 22:19:13
>196 >19
ありがとうございます。
今試してみましたが同一ポインタを複数のshared_ptrに格納すると、
shared_ptrの数だけデストラクタが呼ばれてしまうんですね。
基本は参照で複製を作らないようにするということですね。

201:デフォルトの名無しさん
10/02/18 22:21:29
>>200
そう。
RAIIを徹底しろ。

202:デフォルトの名無しさん
10/02/18 22:21:59
失礼しました。
>>196 >>198でした。

203:デフォルトの名無しさん
10/02/18 22:22:59
g++やVC++などの有名どころのC++コンパイラについてお聞きしたいのですが、
コンパイル時定数を使った
URLﾘﾝｸ(codepad.org)
こんなifによる分岐があるとします。

このとき、成果物.exeはちゃんと最適化されて
分岐が消えるのでしょうか？

よろしくお願いします。

204:デフォルトの名無しさん
10/02/18 22:25:05
codepadで使ってるg++とVC9.0では消失を確認

205:デフォルトの名無しさん
10/02/18 22:36:54
ありがとうございます。
const bool ctc = 100; // compile-time constants
を
bool ctc = 100; // NOT compile-time constants
にしても同じでしょうか？
(volatileは付けません。)

お手数をおかけ致しますが、よろしくお願いします。

次ページ