C++相談室 part94

1 ：12/02/18

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。
前スレ
C++相談室 part93
http://toro.2ch.net/test/read.cgi/tech/1324922431/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.77【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1323692486/
■長いソースを貼るときはここへ。■
　http://codepad.org/
　http://ideone.com/

2 ：12/02/18

■基本■
[C++ FAQ]
　http://www.parashift.com/c++-faq/
　http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
　　Cとその仕様を比較しながらの解説なので分かりやすい。
　　***** 質問の前に必ずこの二つに目を通してください *****
[C/C++ リファレンス]
　http://en.cppreference.com/w/cpp （英語）
　http://ja.cppreference.com/w/cpp （↑の日本語訳だけどまだ未完）
[Stroustrup]
　http://www2.research.att.com/~bs/
[C++ International Standard]
　http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=50372
[JTC1/SC22/WG21 - C++]
　http://www.open-std.org/jtc1/sc22/wg21/
　　ここから規格の最新ドラフトがダウンロードできる。
[JIS X3014]
　http://www.jisc.go.jp/app/pager?%23jps.JPSH0090D:JPSO0020:/JPS/JPSO0090.jsp=&RKKNP_vJISJISNO=X3014
　　ISO規格の日本語訳。JIS X3014:2003はISO/IEC 14882:2003 (E)に対応。

3 ：12/02/18

■Libraries■
[Boost]
　Boost http://www.boost.org/
　(日本語) http://www.kmonos.net/alang/boost/
　(日本語) http://shinh.skr.jp/boost/
[標準ライブラリ]
　SGI-STL http://www.sgi.com/tech/stl/
　STLport http://stlport.sourceforge.net/
　GNU libstdc++ http://gcc.gnu.org/libstdc++/
　Apache C++ Standard Library (STDCXX) http://stdcxx.apache.org/
　STLFilt http://www.bdsoft.com/tools/stlfilt.html
　(日本語) http://episteme.wankuma.com/stlprog/ （※1999年発行注意）
[Loki]
　http://sourceforge.net/projects/loki-lib/
　LokiPort-MSVC6sp5 http://fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport

4 ：12/02/18

■Books■
amazon　C,C++関連書籍
　http://www.amazon.com/exec/obidos/tg/browse/-/3956/ref=br_bx_c_1_3/
　http://www.amazon.co.jp/b/?node=754384
The C++ Programming Language
　http://www.amazon.com/exec/obidos/ASIN/0201700735/
　http://www.amazon.co.jp/exec/obidos/ASIN/475611895X/ (翻訳)
C++ Primer (3rd Edition)
　http://www.amazon.com/exec/obidos/ASIN/0201824701/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756140068/ (翻訳)
The C++ Standard Library
　http://www.amazon.com/exec/obidos/ASIN/0201379260/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756137156/ (翻訳)
Effective C++
　http://www.amazon.com/exec/obidos/ASIN/0201924889/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756118089/ (翻訳)
More Effective C++
　http://www.amazon.com/exec/obidos/ASIN/020163371X/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756118534/ (翻訳)
Exceptional C++
　http://www.amazon.com/exec/obidos/ASIN/0201615622/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894712709/ (翻訳)
More Exceptional C++
　http://www.amazon.com/exec/obidos/ASIN/020170434X/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714833/ (翻訳)
Exceptional C++ Style
　http://www.amazon.com/exec/obidos/ASIN/0201760428/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714663/ (翻訳)

5 ：12/02/18

■Books(Templateまわり)■
Effective STL
　http://www.amazon.com/exec/obidos/ASIN/0201749629/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714108/ （翻訳）
Modern C++ Design
　http://www.amazon.com/exec/obidos/ASIN/0201704315/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/ （翻訳）
C++ Templates
　http://www.amazon.com/exec/obidos/ASIN/0201734842/
C++ Template Metaprogramming
　http://www.amazon.com/exec/obidos/ASIN/0321227255/

6 ：12/02/18

　　　　　　　　 ／￣＼
　　　　　　　　 |　^o^　|　＜　はんにんは　このなかにいます
　　　　　　　　 ＼＿／
　　　　　　　 　/　　　ヽ　　　
　　　　　　　　|　|　　 | |
　　　　　　　　|　|　　 | | 　　　　
　　　　　 　　｜| 　　｜|
　　　　　　　　し|　 i　|J＝二フ
　　　　　　 　　 .|　 |｜
　　　　　　　 　｜ ﾉ ﾉ
　　　　　　　　　.| .| （
　　　　　　　　　/ |＼.＼　
　　　　　　　　　し' 　￣
　　　　　＿
　　　　　 　|　　／￣＼
　　　　　　　￣|　　　　|
　　　　　＿|￣ ＼＿／

7 ：12/02/18

お前やろ

8 ：12/02/18

shared_ptr<IHoge> make_hoge(int id) {
switch(id) {
case HOGE0: return shared_ptr<IHoge>(new Hoge0);
case 〜
}
}
上のようにポリモーフィックな返り値を返す関数があるんだけどnewのコストを削りたい
アロケーターを使う他になにかいい手はないですか？
標準で可変長のスタック領域を扱えたりすると便利なんですが…

9 ：12/02/18

配置new

10 ：12/02/18

make_sharedでnewの呼び出しを2回から1回に減らせる。

11 ：12/02/18

単純な質問ですみませんが、
何故shared_ptr側にオブジェクトを自動アロケートする
メソッドが無いのでしょうか？
引数でオブジェクトのポインタを渡すよりshared_ptr側で
オブジェクトを生成させた方が安全だと思うのですが？

12 ：12/02/18

>>11
make_sharedがあるから

13 ：12/02/18

>>12
あっなるほど・・・
make_sharedってCustom Deleter使いたい時は
自前でAllocator作るしかないですかね？

14 ：12/02/18

class Hoge {
public:
Hoge(int x);
void func(void) ;
};
template <class Del> class HogeEx : public Hoge {
public:
HogeEx(int x, Del const & del) : Hoge(x), mDel(del) {}
~HogeEx(void) { mDel(this); }
private:
Del mDel;
} ;
shared_ptr<Hoge> p =
make_shared<HogeEx<DelType> >(100, deleter) ;
適当に書くとこんな感じかな
HogeExとmake_sharedはもう少し工夫して汎用化してもいい

15 ：12/02/18

int a[] = {7,0,3,4,0,6};
を
{7,3,4,6,0,0}
のように0を後ろに移動させるようなSTLのアルゴリズムありますか？

16 ：12/02/18

std::remove

17 ：12/02/18

0を削除するつもりではないならstd::partition

18 ：12/02/18

順番を保存したいならstable_partition

19 ：12/02/18

stable_partitionでうまいこと出来ました。

20 ：12/02/18

iostreamに関する質問です
自作マニピュレータでストリームのモードを一時的に変えて、元に戻したいのですが
std::ios::dec等、引数の無い書式フラグの戻し方はわかったのですが、
（例えばlong sv_f = setf(ios::hex, basefileld); →自作処理後、最後に setf(sv_f)で戻す）
setfill('0')の戻し方がわかりませんﾎﾞｽｹﾃ、

21 ：12/02/18

removeとpartitionってどう違うんだ？

22 ：12/02/18

なんとなく自己解決したっぽい
ostream::fill()を使うらしいですた、
つまり、次のでおk
ios_base::fmtflags sv_f = stream.setf(ios::dec, ios::basefield);
char sv_ch = stream.fill('0');
stream << setw(2) << s << setw(2) << d << /* ... */ << ends; // 自作処理の一例
stream.setf(sv_f);
stream.fill(sv_ch);
return stream;

23 ：12/02/18

>>21
removeが確実に移動・コピーするのは残す値のみで、除去する値をわざわざ末尾の方に移動・コピーするかは実装依存。
int a[] = {7,0,3,4,0,6};
のときにremoveで0を除去した場合
{7,3,4,6,0,6}
のようになる実装もある。

24 ：12/02/18

>>23
なるほど

25 ：12/02/19

C++ではCと異なり変数宣言をスコープの先頭で行わなくてもよくなりましたが、
あるC++のコードでは、次行で即代入を行うような変数もわざわざ宣言を分けてスコープの先頭に置いていました。
{
int a;
a = some_process();
}
こうすることの意味を私なりに考えてみましたが、
・C言語からの移行・もしくは癖
・コーディングルールによるため
・非POD型との統一のため
・デバッグのし易さ(?)
・表記ミス
個人的には可読性の面からも宣言と初期化をまとめたくなりますが、
int a = some_process();
何か意味があれば教えてください。

26 ：12/02/19

昔は
int a;と
a = some_process();の間に変数aを使うコードがあったが削除されて無くなった
つまり分けてる意味は特にない

27 ：12/02/19

objective-cの後に習う言語はC++かCだと、どっちがいいですか？

28 ：12/02/19

>>26
特に意味は無いのですね。ありがとうございます。

29 ：12/02/19

(1)(2)のように自由関数を引数とする場合には、&が有っても無くても動作するのに、
(3)(4)のようにメンバ関数を引数とする場合には、&が無いと動作しません。
これはなぜでしょうか？
---------------------------------
struct Test{
void testFunc( ){ cout << "Test::func()" << endl; }
};
void func( ){ cout << "::func()" << endl; }
template<class T>
void XXX( T f ){ f( ); }
template<class T, class U>
void YYY( T obj, U f ){ (obj.*f)( ); }
int main( )
{
　XXX( &func ); // (1)OK
　XXX( func );　// (2)OK
　YYY( Test(), &Test::testFunc );　// (3)OK
　//YYY( Test(), Test::testFunc ); // (4)NG
　return 0;
}

30 ：12/02/19

そういう仕様だから

31 ：12/02/19

さらに
XXX( **********func );
これでもOKだ

32 ：12/02/19

プログラミングアートの基本テクニックの一つだね

33 ：12/02/19

&付けるのが言語仕様的に正しいんだっけ?

34 ：12/02/19

普通の関数はあっても無くても良い
メンバ関数は必須

35 ：12/02/20

Cとの互換性のため引き継いだ仕様とC++の仕様

36 ：12/02/20

fprintf(FILE *,・・・)　があると思います。
ここの FILE * のところには stdout も使えると思いますが、
この部分に指定するストリームを自作したいのですが、どんな感じにするんでしょうか。
とりあえず手始めに
fprintf したら指定ファイルのほか、同時に stdout にも出力するような拡張ストリーム作りたいです。

37 ：12/02/20

つ[popen("tee specified.file")]

38 ：12/02/20

>>36
方法が無いわけではないけど、出来ないと思った方がいい
標準Cライブラリ(printf系)でなく標準C++ライブラリ(iostream)を使うこと
もしくは単にfprintfを2回(ファイルとstdout)呼ぶ
fprintfに指定するのはOSが管理するファイルディスクリプタなので
介入するには低レイヤーなライブラリを使うか、fprintfを自作関数として置き換えるか
環境依存な方法(ファイルシステムソケットなど)を使うか、など
・・・普通はやらない

39 ：12/02/20

ストリームを自作するならiostream側でやろうぜ
streambufを自作してiostreamに食わせりゃいい

40 ：12/02/20

C++ストリーム形式のライブラリって頑張って作った割にみんな使ってくれなくてちょっと泣きそうになるよね
オペレーターがキモいのはわかるんだけどでも標準なんだから仕方ないじゃんみたいな

41 ：12/02/20

キモいというのもあるけど
printf形式が楽なんだよね
boost::format使えばいいんだろうけど

42 ：12/02/20

フォーマットマニピュレータくらい用意しててもいいのにな
新旧標準出力同士なぜ上位互換的使い勝手は目指さなかったのか

43 ：12/02/20

演算子オーバーロードが楽しくて
ちょっとはしゃいじゃったんだよ

44 ：12/02/21

反面教師になったのさ

45 ：12/02/21

boost::formatがC++11に入らなかったのは何でだろう

46 ：12/02/21

いまさら言語内言語風に後戻りとかアホすぎだから
プラグインスクリプトか諦めてC++素直に使い括弧バカで通すほうがマシだわ

47 ：12/02/21

iostreamはオーバーヘッド少な目で拡張性の高い仕組みだと思うけど
<<のオーバーロードはホントはしゃいじゃった感じだな

48 ：12/02/21

stream と vector<bool> は可愛い存在。

49 ：12/02/21

個人的にはvector<bool>に助けられてる。

50 ：12/02/21

ベクブー使う奴はクズ

51 ：12/02/21

iomanipは補間候補さえ出てくれば問題ないんだけどなあ

52 ：12/02/21

> 個人的にはvector<bool>に助けられてる。
サイズはbool*size()じゃないでしょ？

53 ：12/02/21

ビット配列なんて別クラスでいいのに・・・

54 ：12/02/21

ビットセットあるやん

55 ：12/02/21

ビットセットはいつもなんか忘れてるな

56 ：12/02/21

実際のブツのできはともかく
論理的な機能と物理的な実装を切り分ける好例ではある

57 ：12/02/21

bitsetはサイズ固定じゃないの

58 ：12/02/21

やるならboost::dynamic_bitsetだな

59 ：12/02/21

サイズ非固定のbitsetって何に使うんだ？

60 ：12/02/21

bitsetすら使う事がないからよく分からない

61 ：12/02/21

基数変換がちゃんと出来る人は、Bitsetで多倍長演算クラスつくると凄そうだなーと思う。
俺できないから、そういうクラス作るとどうしても無駄が出来る。

62 ：12/02/22

>>59
グラフ構造、論理閉包

63 ：12/02/22

パイプすると一回で読み取れるのがスペースか改行までに
勝手になっているんですけど、改行だけにすることはどうやればできますか？

64 ：12/02/22

まず関数名でも書こうか

65 ：12/02/22

読み取り関数名ですか？
それなら<<ですけど。

66 ：12/02/22

訂正
>>でした。

67 ：12/02/22

getline

68 ：12/02/22

ありがとうございます。

69 ：12/02/22

64ビットアプリのばあい
intの代わりにlong longを使い
floatの代わりにdoubleを使うという選択で
最高のパフォーマンスが出せるという
認識であってますか？

70 ：12/02/22

あってない

71 ：12/02/22

どこがあってませんか？
詳しく教えてください。

72 ：12/02/22

大きいものを使う必要あるの？

73 ：12/02/22

>>71
ちょっと考えればわかる
解らなければ向いてないから違う業界に行ったほうが君のためだよ

74 ：12/02/22

業界に入ってないのでわかりません教えてください。

75 ：12/02/22

じゃあ向いてないからやめなさい

76 ：12/02/22

なぜ実測しない

77 ：12/02/22

template<typename T, typename U>
void hoge(const T&, const U&){} //A
template<typename T>
void hoge(const T&, const int&){} //B
template<typename U>
void hoge(const int&, const U&){} //C
template<>
void hoge(const int&, const int&){} //D
BとCを定義すると、Dは特殊化ではないとなりました。
BかCのどちらかを削除するとコンパイルできたのですが
DはAの特殊化なのか、BまたはCの特殊化なのか
どちらですか? (区別する必要性はおいといて)

78 ：12/02/22

こうじゃね？
template<>
void hoge<int,int>(const int&, const int&){} //D

79 ：12/02/22

>>76
わかっているなら教えてくださいよ。

80 ：12/02/22

>>78 なるほど、これならいけました。
引数が2つあるので、Aの特殊化になるみたいですね。
BとCを定義した状態で
void hoge<int>(const int&, const int&){} //D
としたら、特殊化できませんでした。
曖昧な場合は特殊化できないみたいですね。
しかも、どうやっても明示できない状況もあるようです。

81 ：12/02/22

>>71
intの定義を調べましょう
intが32bitだと断定してるところはクソサイトだと思って構いません

82 ：12/02/22

>>81
それは知ってます。
16ビットが32ビットになったときみたいに64ビットになったと思っていたら
３２ビットだったという経験をしたからlong longを使うという発想にいたったわけです。

83 ：12/02/22

本当に調べましたか？
intは「処理系に最適なサイズ」になります
コンパイラ開発者達が最適だと判断したものよりも
long longの方が最適であると思うのならばそちらを使うのも良いでしょう
その際は実測してから使うことを勧めます

84 ：12/02/22

64bit整数が最適でも32bit整数のほうが速いなんてことはいくらでもある
ケースバイケースで実測する他無い

85 ：12/02/22

intが最速って保証は無かったような…
実測するしかない

86 ：12/02/22

>>82
数値演算の速度と64bitアプリかどうかは無関係
「64bitアプリ」の「64bit」はアドレス空間のこと
int, long long, float, doubleには関係ない
関係あるのはポインタ

87 ：12/02/22

32bitで2回処理が必要なところを64bit1回で済むなら速くなる
そうでなければ変わらない

88 ：12/02/22

実測してから使うのは良いけど
その実測も注意が必要だな
仮に算術演算で64bit整数の方が良い性能だったとしても
配列などで要素数が多い箇所を64bit整数にすると逆に性能が劣化するということがあり得る
単純なケースでの実測結果があらゆるケースに適用出来るとは限らないことを
認識しておく必要がある

89 ：12/02/22

> intの代わりにlong longを使い
64bit環境なら、intは64bitにするというのが普通。
処理系によっては、わざと32bitにしてるかもしれん。
じゃあ、64bit環境でのlong longは何bitなのか？
処理系依存だよなぁ、わからん。
> floatの代わりにdoubleを使うという選択で
昔のC処理系の仕様では、内部演算はdoubleで行うことになってた。
floatでの演算には、必ずdoubleとの型変換が介在した。
なので、floatよりdoubleの方が速かった。
今のC++処理系の実装は、知らん。
どっちみち、処理系の実装に依存することに変わりはないわけだ。

90 ：12/02/22

どこの世界の普通だ

91 ：12/02/22

intが64bitの処理系挙げてみろよ

92 ：12/02/22

64bitでも互換性等の理由からintは32bitが普通だw
ILP64の実例なんて聞いた事無いぞ

93 ：12/02/22

Wikiより
データモデル short int long long long ポインタ 処理系
LLP64 16 32 32 64 64 Microsoft Win64 (X64/IA64)
LP64 16 32 64 64 64 ほとんどのUnixとUnix風OS (Solaris, Linux, etc.)
IP64 16 64 32 64 64 ?
ILP64 16 64 64 64 64 HAL
SILP64 64 64 64 64 64 ?

94 ：12/02/22

IP64って規格違反じゃね

95 ：12/02/22

IP64とか規格で許されないのになんで載せてんだか

96 ：12/02/22

intが64bitだと16bitか32bitのどちらかが
拡張整数作らないと使えないからねえ

97 ：12/02/23

32ビットだとレジスターにintを二つ入れて並列演算するから
long longより速いなんてことないですよね？

98 ：12/02/23

は？

99 ：12/02/23

ひ？

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【計測】LabVIEW相談室【制御】 (527)
IS<インフィニット・ストラトス>総合 (491)
自然言語処理スレッド　その３ (462)
ネットワークプログラミング相談室 Port27 (846)
JavaScriptスレ2 (316)
メガデモを語る fr-08 (603)
--log9.info------------------
お土産の模造刀、持っていたら逮捕･･･北海道 (203)
こんな刃物は嫌だ！ (678)
メーカーはハーフセレーションのナイフを廃止しろ (218)
【村雨】古今東西　世界の名剣【ラグナロク】 (313)
妖刀をあげるスレ (439)
【今夜も】ナイフ、いい話２【聞かせて】 (316)
女性の刃物趣味って変ですか？ (446)
関のナイフ工場で働きたい！ (863)
最先端★ウォーレントーマス★ナイフ (330)
通り魔容疑の高２、自宅から刃物数十本 (181)
ウィリアムヘンリーの魅力を語ろう 02 (131)
今日買った刃物を報告するよ (178)
刃物オタにありがちなこと (272)
USMCファイティングナイフ (151)
なぜ刃物に宗教的な意味が込められるのか (140)
【銃刀法違反】丹羽義典逮捕【自由刃物】 (312)
--log55.com------------------
☆★鮨屋でよく頼むネタは？？？★★
トンキンジジイちんこめし
IDに寿司ネタが出るまで(´・ω・｀)するスレ166貫
伝説のすた丼 43杯目
なか卯33
【かつ丼】かつや53杯目【とん汁】
松屋　102
吉野家総合170