09/06/14 10:14:10
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。
前スレ
C++相談室 part69
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
09/06/14 10:15:25
■基本■
[C++ FAQ]
URLﾘﾝｸ(www.parashift.com)
URLﾘﾝｸ(www.bohyoh.com) (日本語)
Cとその仕様を比較しながらの解説なので分かりやすい。
***** 質問の前に必ずこの二つに目を通してください *****
[C/C++ リファレンス]
URLﾘﾝｸ(www.cppreference.com) （英語）
URLﾘﾝｸ(www.cppll.jp) （↑の日本語訳だけど最新は反映しない）
[禿 Stroustrup]
URLﾘﾝｸ(public.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:デフォルトの名無しさん
09/06/14 10:16:10
■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)
4:デフォルトの名無しさん
09/06/14 10:17:19
■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 STDCXX URLﾘﾝｸ(incubator.apache.org)
STLFilt URLﾘﾝｸ(www.bdsoft.com)
(日本語) URLﾘﾝｸ(www005.upp.so-net.ne.jp)
(日本語) URLﾘﾝｸ(www.wakhok.ac.jp)
[Loki]
URLﾘﾝｸ(sourceforge.net)
LokiPort-MSVC6sp5 URLﾘﾝｸ(fara.cs.uni-potsdam.de)
5:デフォルトの名無しさん
09/06/14 10:18:34
入門ページなど
URLﾘﾝｸ(www.cplusplus.com)
・入門,一覧,使い方
URLﾘﾝｸ(www5c.biglobe.ne.jp)
・メソッド一覧
URLﾘﾝｸ(www.wakhok.ac.jp)
・サンプルプログラム集
URLﾘﾝｸ(www.s34.co.jp)
6:デフォルトの名無しさん
09/06/14 10:19:28
Apache STDCXX URLﾘﾝｸ(incubator.apache.org)
は
Apache C++ Standard Library (STDCXX) URLﾘﾝｸ(stdcxx.apache.org)
というのは指摘済みでした。ごめんなさい。とりあえず訂正。
■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ﾘﾝｸ(www005.upp.so-net.ne.jp)
(日本語) URLﾘﾝｸ(www.wakhok.ac.jp)
[Loki]
URLﾘﾝｸ(sourceforge.net)
LokiPort-MSVC6sp5 URLﾘﾝｸ(fara.cs.uni-potsdam.de)
7:デフォルトの名無しさん
09/06/14 10:20:08
結論
Cでいい
8:デフォルトの名無しさん
09/06/14 10:25:44
Boost C++ Libraries
URLﾘﾝｸ(www.boost.org)
Boost 翻訳プロジェクト
URLﾘﾝｸ(boost.cppll.jp)
Let's Boost
URLﾘﾝｸ(www.kmonos.net)
boost info
URLﾘﾝｸ(shinh.skr.jp)
9:デフォルトの名無しさん
09/06/14 10:39:30
最悪言語C++は不要
スレも不要
10:デフォルトの名無しさん
09/06/14 10:54:15
C++で作れない人にとってはC++は不要
Cスレに帰れ
11:デフォルトの名無しさん
09/06/14 11:11:49
c++最高
12:デフォルトの名無しさん
09/06/14 11:25:53
>>1乙
13:デフォルトの名無しさん
09/06/14 11:33:21
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
14:デフォルトの名無しさん
09/06/14 12:27:14
誤爆
15:デフォルトの名無しさん
09/06/14 16:52:33
テンプレはまだ続きます
16:デフォルトの名無しさん
09/06/14 17:27:51
『C++再考』
17:デフォルトの名無しさん
09/06/14 17:29:40
『C++サイコ』
18:デフォルトの名無しさん
09/06/14 19:51:02
std::string myString = GetHogeString();
みたいにした場合、これ以降 myString に対する操作はすべて myString.c_str() のみで、
その他の操作はいっさいしないと仮定した場合
const char * pStr = myString.c_str();
としておいて、以降ずっと（いつの日かmyStringが破棄されるまで）
pStr を使っていても問題ない？
19:デフォルトの名無しさん
09/06/14 19:54:33
>>18
問題ない。
myString が破棄されるか、 myString の非 const メンバ関数を呼び出すまで
c_str() の戻り値は有効。
20:デフォルトの名無しさん
09/06/14 19:57:06
規格書広げるまでもなく
"いつの日"が1msec後で、1msec後にpStrが向こうになったら困るから、
"いつの日か"破棄されるまでずっと有効。
21:デフォルトの名無しさん
09/06/14 21:00:47
開封後はお早めにお召し上がりください
22:デフォルトの名無しさん
09/06/14 21:44:06
仮に
class A {
public:
A() {
m_String = ::GetHogeStr();
m_pStr = m_String.c_str();
}
const char * GetStr() {
return m_pStr;
}
std::string m_String;
const char *m_pStr;
};
みたいにしてあった場合、例えば
std::vector<A> a;
とかやってると a の操作によっては中身が再配置されてまずいんでないの？
23:デフォルトの名無しさん
09/06/14 21:58:49
>>22
おまいは何を勘違いしているんだ。
m_pStrの中身が0x12345678だったとして、
仮にアフリカに再配置されたとしても0x12345678のままだぞ。
24:デフォルトの名無しさん
09/06/14 22:10:27
いや、そうじゃなくて
std::vector<A> vec;
A a;
vec.push_back(a);
const char *a_str = vec[0].GetStr();
vec.push_back(...);
vec.push_back(...);
...
てやったときにさ、a0 が最後まで無効にならないって保障はあるのかと。
vec が保持してるのは A* じゃなくて A じゃん。
25:デフォルトの名無しさん
09/06/14 22:11:17
すまん a0 → a_str とよみかえてくれ
26:デフォルトの名無しさん
09/06/14 22:12:07
>>22
元の質問ではっきり「これ以降 myString に対する操作はすべて myString.c_str() のみ」って
前提がおいてあるのに、なんでわざわざ問題のある状況を作って「まずいんでないの？」とか
スレ汚すの？
27:デフォルトの名無しさん
09/06/14 22:13:41
スレを汚したい年頃だからさ
28:デフォルトの名無しさん
09/06/14 22:15:47
パンツ汚したら親に見つからないように風呂場で洗え＾＾
29:デフォルトの名無しさん
09/06/14 22:16:21
>>24
保障あるよ
30:デフォルトの名無しさん
09/06/14 22:19:08
myString がグローバル変数だとか、単なるローカル変数ならいいけどさ、
クラスのメンバだったりするとまた話は変わってくるでしょ。
myString に対するそうさが c_str だけとわかっていても、それを含んでいる
インスタンスの扱いによっては、myString を直接いじらなくても
おかしくなる可能性があるんじゃない？
31:デフォルトの名無しさん
09/06/14 22:21:59
>30
え！マジで
32:デフォルトの名無しさん
09/06/14 22:27:22
class A {...}
std::string <A>
とかやったら、内部バッファが拡張されるたびに
あたらしい領域にAのコピーがつくられて、
古い領域にあるA が全廃棄になるものとばかり思っていた
33:デフォルトの名無しさん
09/06/14 22:29:27
そもそも値のセマンティクスを持たないものをSTLコンテナの中に入れちゃらめ＾＾
R.マッサー先生がそう書いてたでしょ？
34:デフォルトの名無しさん
09/06/14 22:45:08
>30
>インスタンスの扱いによっては、myString を直接いじらなくても
>おかしくなる可能性があるんじゃない？
何でわざわざmyStringが破棄される場合の話がでてくるの？
はじめから>>18でもmyStringが破棄されたときは問題だと認識されているが。
いつmyStringが破棄されるか、というのはまったく別の話だろう。
35:デフォルトの名無しさん
09/06/14 23:07:06
あまり考えずに丸投げで聞いてみるが
C++でCPSスタイルって出来る？
テンプレート/関数ポインタともに
型の制限は受けるよね、多分
36:デフォルトの名無しさん
09/06/14 23:08:16
できるよ。
37:デフォルトの名無しさん
09/06/14 23:27:44
template <typename T> void mandelbrot(T cont){
//z=z*z+cを色々計算
cont.parse(z.real(),z.imag());
}
void mandelbrot2(void (*cont)(double,double)){
//略
cont(z.real(),z.imag());
}
一応これで出来そうには思うが
2回以上連続して適用は無理だよな
operator()で統一するぐらいが現実的か
38:デフォルトの名無しさん
09/06/15 00:56:33
前スレのABC案に答えてくれた人ありがとうございました。
とりあえずB案で、それがボトルネックになる事態が発生するまでそうしておこうと思います。
39:デフォルトの名無しさん
09/06/15 00:57:43
普通Aからだろ。まあいいが。
40:デフォルトの名無しさん
09/06/15 01:06:28
個人的にはCがいいかと思っていたのですが、Bでもさほど問題にはならないだろうし、
なにより早すぎる最適化であるという指摘を受けて、なるほどと思いました。
Aであることのメリットは何でしょうか？
41:デフォルトの名無しさん
09/06/15 01:12:44
ちなみにCがいいかと思った理由は、スコープを限定できる(C#でいうusingのような)ことと、
ループ内でインスタンス生成することのコスト(が最適化されるかどうかも含めて)を、
そのコードを初めて見た人が心配しなくてすむだろうと思ったからです。
42:デフォルトの名無しさん
09/06/15 01:36:47
ブロック式が出てきたら関数化が必要だと思うきがす・・・るけど，採用しなかったならＯＫ
43:デフォルトの名無しさん
09/06/15 22:11:48
>>38
お前は何を聞いていたんだ。
コピーコンストラクタには3歳児が10まで数える処理が
含まれているって言ったろ？
44:39
09/06/15 23:18:20
>>40
ああ、ごめん。おれもBだわ。勘違いしてた。
45:デフォルトの名無しさん
09/06/15 23:23:11
>>43
コピーコンストラクタは速いが、デストラクタでは100まで数えておふろから出る処理が含まれてたと思う
46:デフォルトの名無しさん
09/06/15 23:42:18
それが問題になるならその時に対処すればいい
47:デフォルトの名無しさん
09/06/16 05:24:12
そもそも真にボトルネックになっているかどうかが分からない。
実測するしかないだろう。
・コピーコンストラクタで毎回生成する方式
の方が速いこともあれば
・代入演算子で毎回生成する方式
の方が速いこともある。
前者は毎回メモリをスタックに確保する必要がある＋コピーコンストラクタを起動する必要がある
が、確保場所は好き好きに決めて良いから速いかもしれない。
後者は毎回メモリをスタックに確保する必要がない＋代入演算子を呼び出す必要がある
が、確保場所は既にきまっちゃっているわけで、自由度がないかもしれない。
てな感じでしょうかね。