【C++】STL（Standard Template Library）相談室 9

【C++】STL（Standard ..

159:デフォルトの名無しさん
08/03/06 21:51:10
やたらスレが伸びてると思ったら･･･
もうここの連中には仕事任せられんな
今後は>>170にすべてを託すこととする
なお異論は受け付けない

160:デフォルトの名無しさん
08/03/07 04:52:01
それは無意味にkskしろってことかい

161:デフォルトの名無しさん
08/03/07 09:34:55
string::swap について教えて下さい。

＞void func(string &sArg)
＞　string sBuf = "AAAAAA";
＞　sBuf.swap(sArg);

のときって、sBufの内容がsArgに移し変えられるっていうのがswapの機能だと思います。

この場合、実装に依存するんだと思いますが、
メモリのエリアがガバっとコピーされるのではなくてクラスの参照を交換してくれるんでしょうか？
性能的に優れてるものだったら、使いまくりたいですし。

一度も使ったこと無いので、swap後にちゃんとメモリ保持しててくれるんだろうか、
落とし穴は無いだろーななんてｶﾞｸﾌﾞﾙしてます。

162:デフォルトの名無しさん
08/03/07 09:55:42
>>161
stringだったら、内部で保持しているであろう
文字列へのポインタや長さなどといった変数だけが交換されるとみな仮定している。

一般的に、swapは例外を投げないとされており、
しかも、std::stringのswapはO(1)と規格で定められている。
だから、文字列の中身まで交換する実装はありえない。

163:161
08/03/07 10:29:50
ｻﾝｸｽ。

＞一般的に、swapは例外を投げないとされており、

へぇー、勉強になりました。

＞しかも、std::stringのswapはO(1)と規格で定められている。

勉強になりましたが、O(1)って何だ?_?

＞だから、文字列の中身まで交換する実装はありえない。

あ、そうなんですか？
例外を発生できないとなると、参照を交換する以外に実装無いと思うんですが。
だって、交換じゃなくてコピーならば、メモリを確保しないといけないし、そうなるとエラーが発生する可能性があるような。
って素人なのに生意気逝ってすみません。

164:デフォルトの名無しさん
08/03/07 10:37:30
O(1)というのは、例え文字列が長くてもswapが一定時間で終わらなければならないってこと。
文字列をコピーするなら、文字列が長くなればそれだけコピーに時間が掛かるから、この制限を満たせない。
詳しくは「計算量」でググれ。

>例外を発生できないとなると、参照を交換する以外に実装無いと思うんですが。
まさに>>162はそう言ってるんだと思うよ。
中身をコピーして交換するんじゃなくて参照(具体的にはポインタ)を交換する。

165:161
08/03/07 10:40:31
ﾗｼﾞｬ!

＞文字列の中身まで交換する実装はありえない。

つまり、中身をコピーする実装はありえない、って文章ですね。
で、そう言い切れる理由はO(1)で時間制限してて、”ま、参照を交換する実装にしる！”、っていわば指令が出てるわけですね。

166:デフォルトの名無しさん
08/03/07 10:58:42
>>165
deep copyをするとno throwの保障ができなくなる。

167:161
08/03/07 11:00:02
すみません、教えてｸﾝですみませんが、最後に記述を教えて下さいorz

swapを使いまくりたくなりました。
vector<char>とstringの間で、swapする記述はありますでしょか？

vectorメモリは連続しているので、vector同士だとswapできるんじゃないかと思ったのですが。
直にメモリアクセス？ｲﾃﾚｰﾀﾝを無視し過ぎるのも良くないとは思わないでも無いですが。

168:デフォルトの名無しさん
08/03/07 11:07:45
>vector<char>とstringの間で、swapする記述はありますでしょか？
ない。実装上も、例えばstringがnull終端の分だけ余計に内部バッファを持っているなら無理。

>vectorメモリは連続しているので、vector同士だとswapできるんじゃないかと思ったのですが。
vector同士ならできる。

169:161
08/03/07 11:09:58
＞ない。実装上も、例えばstringがnull終端の分だけ余計に内部バッファを持っているなら無理。

なるほど。納得。下手にやるとはまりますね。

＞vector同士ならできる。

vectorの異なる構造体同士でもできますか？
記述例超ｷﾎﾞﾝｗ

170:デフォルトの名無しさん
08/03/07 11:19:32
テンプレートパラメータが違うとダメだろう

171:デフォルトの名無しさん
08/03/07 11:28:20
記述例もなにも、vとv1が同じ型のvectorなら、
v.swap(v1);
で交換できる。vectorに限らずあらゆるコンテナで。

172:161
08/03/07 11:36:47
全部分かりました。有難うございましたorz

つまり、コンテナが違うとswapはキャストやらなんやらやヴぁい記述になるわけですね（はまるからやらないけど）

173:デフォルトの名無しさん
08/03/07 13:11:25
質問です。

クラスメソッドの引数で、

＞method(string s1) { method(s1.c_str()) }
＞method(const char *s1);

みたいな感じで、オーバーロードで「string」も「char *」も両方受け入れるようにしてるんですが、
どちらか片方だけ定義、ということにできますでしょうか？

174:173
08/03/07 13:15:17
２つ要るとしたら、stringベースとchar*ベースと効率が良いのはどちらでしょう？
まぁ、大差無いですか？

175:デフォルトの名無しさん
08/03/07 13:20:59
>>173
stringだけ書いとけばconst　char*からstringを暗黙に構築してくれると思うが、効率は良くないかも

176:デフォルトの名無しさん
08/03/07 13:37:12
>>173
片方がconst char * なんだから、string const & の方がいいんでないかい?
で、どっちみちstringを受ける方もconst char * 版を呼び出すなら要らないわけで。

177:173
08/03/07 13:37:33
何だ、そうでしたか。無駄に２つ作ってしまったorz

178:173
08/03/07 13:42:12
頭が混乱してましたが、

＞stringだけ書いとけば
の場合は、引数が入力である場合は、おｋ、

＞片方がconst char * なんだから、string const & の方がいいんでないかい?
これ（つまり、& ）を選択した場合は、２つ書かないといけないんですよね？

コンパイラで試せば良いのですが、皆さん普通はどうされてるのか知りたくて。

179:デフォルトの名無しさん
08/03/07 13:44:52
>>178
わけがわからん。何がしたいのか書きなおしてくれ。

180:173
08/03/07 13:48:53
ごめんなさい、テストプログラム書いたら違っていました。

つまり、
＞stringだけ書いとけば
でおｋ。

＞string const & の方がいいんでないかい?
でおｋ。

但し、char *を渡すと、W8030 Temporary used for parameter のウォーニングが出ると。

181:デフォルトの名無しさん
08/03/07 13:52:35
話を読む限りstringやconst char*である必要性を感じないし、
俺だったら初めと終わりのイテレータを引数に取るようにする。
stringでもconst char*でもないやつもかかってこい。

182:173
08/03/07 13:53:05
あ、「「string &」だとウォーニングだったのが、「string const &」だとウォーニング消えました。

つまりやりたかった、
＞string と char *の一本化、
および、
＞参照渡しでメモリ節約＆コンパイルウォーニング無し
の全て解決しました。orz

183:173
08/03/07 13:54:45
＞俺だったら初めと終わりのイテレータを引数に取るようにする。

はつみみです。

これ知っとくと大分楽できそうですね。何が良いのか調べてみます。
（参考サイトでも何でも教えて頂ければ参照します。レスで教えてというのも嫌われそうなので）

184:デフォルトの名無しさん
08/03/07 13:58:47
string const &が要求されてるところにconst char *を渡そうとしたら、stringの一時オブジェクトが作られて、
文字列の内容がコピーされるから、メモリの節約にはなってない

185:173
08/03/07 14:20:17
>>184
あっ、そーですか。
じゃぁ、今まで作った基礎クラスはそのままに２つのままにしておこうかなぁ。。。
悩む。

186:173
08/03/07 14:58:05
今、上記内容に沿って、”string const &型”に全面書き換え中ですが、
以外に頭が固いのが、stream系ですね。
っていうか、ifstreamとか引数にstring受け入れないっぽい。

187:デフォルトの名無しさん
08/03/07 15:26:37
>>186
コードを書く前に、もう少しきちんと勉強したほうがいいと思います。

188:デフォルトの名無しさん
08/03/07 16:40:31
class StringArg
{
const char* p_;
public:
StringArg(const string& str) : p_(str.c_str()) {}
StringArg(const char* str) : p_(str) {}
const char* get_arg() const { return p_; }
};

method(const StringArg& arg);

189:172
08/03/07 16:49:34
>>188
はじめそれに近い形で書いてたんですが（違いはstring側はconstにしてなかったとこだけ）、
メソッド宣言２行になると、以外にクラス部品作るのがしんどくて。
効率悪くても１つにしたいな、と思いました。

で結局、
＞StringArg(const string& str)
の方だけ活かして、
巨大なバッファで、かつ、char *の可能性がある場合のみは、188 の通り、
２つ宣言しようかと思っています。

190:デフォルトの名無しさん
08/03/07 16:50:09
↑
172じゃなくて、173でした。

191:デフォルトの名無しさん
08/03/07 16:58:43
>>189
多分お前は>>188を誤読してる
const char *をとるメソッドもconst string &をとるメソッドも用意せずに、
const StringArg &をとるメソッドを用意しろってことだろ

192:デフォルトの名無しさん
08/03/08 09:00:47
void Method(const char*); のみ用意して、
std::stringを渡したい場合は↓じゃあかんのか

std::string s;
Method(s.c_str());

193:デフォルトの名無しさん
08/03/08 20:47:51
#include <set>
using namespace std;

int main()
{
set<int> s;
s.insert(1);
s.insert(4);
(*s.begin()) = 5;
return 0;
}
上のプログラムは違法ですよね？
ウチのコンパイラは文句を言わないんだけどおかしいですよね？

194:デフォルトの名無しさん
08/03/08 20:53:45
>>193
とりあえずg++だとエラーになった

195:デフォルトの名無しさん
08/03/08 20:59:06
ふぁっきんBCC

196:デフォルトの名無しさん
08/03/08 21:03:38
>>193
C++2003 に準拠しているならそれでも規格の範囲内。
変更できないことが明記されるのは次の C++0x から。
URLﾘﾝｸ(www.open-std.org)

コンパイル通るからといっても、まずいことがわかってるなら
やらないでおいたほうがいいね。

197:デフォルトの名無しさん
08/03/08 21:04:28
>>193
Effective STL 第22項をどうぞ。

198:デフォルトの名無しさん
08/03/08 21:12:44
>>196
サンクス。STLってたくさん欠陥があるんですね。

>>197
サンクス。今度立ち読みします。

199:デフォルトの名無しさん
08/03/10 08:45:25
stringにバイナリ書き込みで、
resizeした後、・・・１
c_str()でポインタ取って、・・・２
memcpy・・・３
してます。

２ってSTL的には読み込み専用ポインタであり間違ったコードなんですが、
動作してるのでほっとこうか、正しく書こうか迷ってます。
どうしたら良いでしょう？

200:デフォルトの名無しさん
08/03/10 08:47:18
>>199
間違ったコードを正しく書くのに、何を迷うの？

201:デフォルトの名無しさん
08/03/10 08:50:50
>>199
必要な知識は全部持ってるみたいだが、何を訊きたいんだ？
未定義動作に依存するという欠点よりもそのコードが持つ利点が大きいと考えるなら
それを使い続ければいいし、そうでないなら書き換えればいい

202:デフォルトの名無しさん
08/03/10 08:50:55
いろいろ。

じゃ、直しておきまつ。

203:デフォルトの名無しさん
08/03/10 20:18:13
コンストラクタやassignとかappendがあるもんな。
イテレータにstd::copyでもいけるし。

204:デフォルトの名無しさん
08/03/11 09:05:07
＞イテレータにstd::copy

ｲﾃﾚｰﾀﾝって参照するだけじゃないんだ。
ｲﾃﾚｰﾀﾝがメソッド持ってるって考え方がイマイチわかんないんだおね。

205:デフォルトの名無しさん
08/03/11 15:29:40
いや、イテレータを引数に取れる関数だろ

206:デフォルトの名無しさん
08/03/11 19:51:25
イテレータは何かを反復するもの。「何か」は参照かもしれないし、操作かもしれない。

207:デフォルトの名無しさん
08/03/11 20:59:59
ifstreamで半角空白を含むファイル名や、日本語を含むパスで
ifstream ifile(フルパス名);で失敗してしまうのですが、これは仕様なのでしょうか？
仕様なのでしたら回避策はあるのでしょうか？

Visual Studio 2005SP1を使用しています。
よろしくおねがいします。

208:デフォルトの名無しさん
08/03/11 21:05:45
問題が再現する最小限のコードを貼れ。まずはそれからだ。

209:デフォルトの名無しさん
08/03/11 21:05:59
ロケールの設定とか？

210:デフォルトの名無しさん
08/03/11 21:29:37
コンパイルはVisualStudio2005 Command Promptで行いました。

#include <iostream>
#include <fstream>
#include <windows.h>

using namespace std;

int main(int argc, char **argv)
{
ifstream ifile("新規テキストドキュメント.txt");
if(ifile) {
MessageBox(NULL, "success", "info", MB_OK);
ifile.close();
} else {
MessageBox(NULL, "failed", "info", MB_OK);
}
return 0;
}

結果はfailedとでます。

211:デフォルトの名無しさん
08/03/11 21:31:17
間違えました。
フルパス名をコピペして、\を一つ減らしてエクスプローラーに貼り付けると正常に開けます。

ifstream ifile("d:\\新規テキストドキュメント.txt");

212:デフォルトの名無しさん
08/03/11 21:32:25
まさか、そのファイルがカレントディレクトリに置いてないとか言わないよな?
つーか、このスレより環境依存OKのスレかWindows関連のスレの方がいい希ガス。

213:デフォルトの名無しさん
08/03/11 21:42:30
ありがとうございます。
環境依存スレに行ってみます。

214:デフォルトの名無しさん
08/03/12 03:34:34
vectorに要素をpush_backするとき、全ての要素がこっそりと引越し、
要素を指していたポインタが無効になり、ひどい目にあうことが
あるということを知りました。

そこで質問なのですが、引越し時の要素のコピーは
コピーコンストラクタを使って行われるのでしょうか？
それとも単純にmemcpyなどで行われるのでしょうか?

215:デフォルトの名無しさん
08/03/12 04:23:23
>>214
コピーコンストラクタじゃなきゃヤバイでしょ。
あくまで例だけど、int型のメンバxと、そのアドレスを持つint*型のメンバpxがあって、
pxの値をmemcpyなんかした日にはえらいこっちゃ。

216:デフォルトの名無しさん
08/03/12 07:50:53
>>214
もすこし具体的にどうぞ。

>>215
あんたも何を言いたいんだか。

217:デフォルトの名無しさん
08/03/12 07:51:34
コピーコンストラクタでpxをdeep copyしてなければ同じようにえらいこっちゃ。だけどね。

218:デフォルトの名無しさん
08/03/12 07:53:22
>>217
それは別問題

219:デフォルトの名無しさん
08/03/12 07:56:14
>>214
再割り当て時にはコピーコンストラクタが使われるよ。

220:デフォルトの名無しさん
08/03/12 07:57:26
>>216
俺は第三者だけど、>>214が何を訊きたいかは分かるし、>>215の回答も理解できるよ。
>>215は当を得た回答だと思う。

221:217
08/03/12 08:01:58
deep copy するわけじゃないのか。215が言いたいのは。
コピーコンストラクタでpx=&xが必要ってことだな。多分。

222:デフォルトの名無しさん
08/03/12 08:06:43
STLはコピーを前提に作られている。そういうもの。

223:デフォルトの名無しさん
08/03/12 08:07:42
>>214
要素は引っ越しません。

224:デフォルトの名無しさん
08/03/12 08:46:07
>>221
コピーコンストラクタという言葉を使っているところからして、
ユーザー定義型がvectorにどう扱われるかを訊きたがってるんだろうな、と判断した上で、
「コピーコンストラクタを用いなければ"正しく"コピーできない型があり得るのに、
vectorが内部で勝手にmemcpyによるコピーで満足しちゃうなんてことは無いよ」
って回答した次第。

225:デフォルトの名無しさん
08/03/12 08:49:23
>>223
嘘をつくな

226:デフォルトの名無しさん
08/03/12 08:50:39
>>223
規格に"引っ越し"という言葉は書いてないという揚げ足をとってるのか？
それとも単にC++を知らないだけ？

227:217
08/03/12 09:01:52
I got it.

関係ないけどクラスをmemcpy、memcpyするソースをよく見かける。怖くて仕方ない。

228:217
08/03/12 09:02:25
memset、memcpyだった。

229:デフォルトの名無しさん
08/03/12 09:03:13
怖いじゃなくて、memsetだとプログラム落ちるだろ、jk

230:デフォルトの名無しさん
08/03/12 09:05:39
そういうのはCのノリが抜け切れてない年寄りが多いの？

231:217
08/03/12 09:15:12
>>229
落ちるとは限らないよ。仮想関数がないクラスではうまくいく。(memsetでセットする値が適切なら)

仮想関数があるクラスでmemset(this,0,sizeof(this))とかやると
仮想関数ポインタが0になるので、
ポリモーフィズム使用時にNULLポインタアクセスで落ちた。

だから抽象クラスにしたいときには、memsetしてないか全部チェックせなあかんかった。

>>230
そうだね。特に組込系が多いね。クラスを構造体の延長として使ってる。

232:217
08/03/12 09:22:43
URLﾘﾝｸ(sunlight.cocolog-nifty.com)

こういう変なことする人もいる。class S が仮想関数を持つクラスをメンバ変数に持ってたら
ダメじゃんって突っ込みたい。

スレ違いでゴメン！

233:デフォルトの名無しさん
08/03/12 09:28:30
突っ込みたいなら突っ込んであげればいいのに

234:デフォルトの名無しさん
08/03/12 10:05:25
>>232
君がインストラクタになってあげなさい

235:デフォルトの名無しさん
08/03/12 12:47:55
引っ越しって言えば、moveだろ。
copyを引っ越しと言うのは無理があり過ぎる。

236:デフォルトの名無しさん
08/03/12 12:49:21
>>235
引越しは後片付けしてから出て行くよ。

237:217
08/03/12 15:43:34
自分は暗黙のインストラクタでいいのでw

238:デフォルトの名無しさん
08/03/12 21:05:27
>>235
「copyを引っ越しと言」ってるようには見えないよ。「引越し時の要素のコピー」って書いてある。

コンピュータデータのmoveは、実際には「copyする」ことと「元を削除する」ことで成り立っているわけで、
つまり「move（ここではvectorの要素の再配置のこと）の手段としてのcopy」の表現だろう。

239:デフォルトの名無しさん
08/03/12 21:28:37
コピコンでは普通は deep copy する。
そういうもの。

240:デフォルトの名無しさん
08/03/12 22:56:24
参照カウント付きハンドルの場合はそうじゃないけど。
(boost::shared_ptr etc)

241:デフォルトの名無しさん
08/03/12 23:00:16
それは特殊例

242:デフォルトの名無しさん
08/03/14 00:11:29
インストラクタｗｗｗ

243:214
08/03/14 01:02:08
レス遅れてすみません。解答してくださったみなさん、
ありがとうございます。

でも、*ほとんどの* ケースでは、単純なmemcpyで済みそうなのに、
いつでもコピーコンストラクタが使われるという仕様に疑問を感じます。

コピーコンストラクタが使われるとなると、コピー元のオブジェクトに
対してデストラクタを呼び出す必要があります。これは、*ほとんどの*
ケースでは全く馬鹿馬鹿しい無駄です。

それならreserve使え、とおっしゃるかもしれませんが、どれだけの
領域をreserveしておけばいいのか、前もって計算できないことも
よくあります。

引越し時のコピーはmemcpyで行われるべきではないでしょうか？
>>215さんが出した例のような場合、ユーザーはreserveを使います。
どうでしょう？だめ？

244:デフォルトの名無しさん
08/03/14 01:08:07
allocatorを指定するとか。

245:デフォルトの名無しさん
08/03/14 01:26:34
>>243
そう、毎度コピーするのは無駄と誰もが思ったから、
今度の規格改定でムーブセマンティクスというものが導入されようとしている。

246:オガちゃん萌え ◆tyvkWCNtzY
08/03/14 01:27:09
インフラはmemsetやらをやたら使うよ
アーキテクチャ依存すんだからOOPは役に立たん
ドメインでアーキテクチャ依存せんようにするにはやむえない
…が、インフラのC型記述は拡張子.cにして欲しい
イヴァーヤコブソンはそんなユースケース駆動モデルを奨めている
STLですらQACでNGになられたんじゃ参るストーン

247:デフォルトの名無しさん
08/03/14 01:47:52
>>245
彼が不満に思っている状況の大半では，
move semantics は何の改善ももたらさないのでは？

248:デフォルトの名無しさん
08/03/14 01:53:02
そうか？移動なら、コピーに比べ格段に低コストだし、
前のオブジェクトのデストラクタは実質やることなくなる。
こういう問題だと思っていた。214が納得するかどうかは別としてだけど。

249:デフォルトの名無しさん
08/03/14 02:09:19
>>248
memcpy によってコピーできるオブジェクトというのは，
(C++0x において条件が緩和される) POD 型のオブジェクトに
およそ相当すると思いますけれど，これらのオブジェクトに対しては
コピーの操作と (move semantics でいうところの) move の操作は
同じ操作になると考えられるので「move semantics によって改善される」というのは
まずいのではないかな，と．

デストラクタに関しても， move を使っても copy を使っても
「実質やることがない」のはなんら変わりはないと思います．

250:デフォルトの名無しさん
08/03/14 10:11:23
>>249
ああ、たしかにPODだとそうだね。

言葉足らずですまん。俺は非POD型を入れることことを考えていた。
というのも243でデストラクタを呼び出さなければならないと言っているから、
214=243は非POD型を念頭に置いているのだと思ったため。

251:デフォルトの名無しさん
08/03/14 12:04:02
>>243
手元のVC8ではvector<char>とかvector<int>ならmemmoveを使ってくれたよ。
アラインメントを考慮してrep movsdで転送。

struct Foo{int a; int b;}; vector<Foo>だと単純にループ1まわりにつき
8byte転送するようなコードになってた。

PODを判定できれば両方memmoveに出来るんじゃないかな。

252:デフォルトの名無しさん
08/03/14 12:23:37
わかってない子が来た

253:251
08/03/14 13:03:30
ん、俺のこと？
俺はただ、>>243がpush_backでのバッファ拡張時にmemcpyやmemmoveのような
効率的なコピーが使われないと思いこんでいるようだったから、わかりやすい
反例を示しただけだよ。

>>243
> *ほとんどの* ケースでは、単純なmemcpyで済みそうなのに、

それで済むケースは実際にそうなる場合があるよ、と。

254:デフォルトの名無しさん
08/03/14 13:22:12
>>232のアホ顔軍曹に習ってくる様にｗ

255:251
08/03/14 13:40:35
ん？　仮想関数がらみとか、コピーコンストラクタでpxをdeep copyしなきゃ
ならないケースの話？
そういうクラスはPODとは呼ばないけど。

256:デフォルトの名無しさん
08/03/14 14:09:38
>>251
ちょうどVC8には、__is_podがある。
ただ、手元のVC9 EEのincludeディレクトリをgrepしたが、
使っていないみたいだったorz。

257:デフォルトの名無しさん
08/03/14 19:03:11
かなり初歩的な質問になるんですけど、std::setがどうやっても
当環境ではエラーを起こすのですが、原因わかりますでしょうか
#include <set>
#include <iostream>
int main(){
using namespace std;
set<int> nums; // 空のset
return 0;
}
この文を実行した場合、実行時に
Run-Time Check Failure #2 - Stack around the variable '_Lk' was corrupted.
と表示され,xtreeのソースが表示されます。
環境:WinXP Pro SP3
Visual Sturio 2008

258:257
08/03/14 19:12:24
すみません、早速自己解決しました。
単純にPlattformSDKのcrtにあるxtreeが読まれていたからでした
お騒がせしました。
...OSまで再セットアップしたのにorz

259:デフォルトの名無しさん
08/03/14 20:06:21
アルゴリズムに渡す、ちょっとした関数オブジェクトのクラスにどんな名前つけてる？

260:デフォルトの名無しさん
08/03/14 20:16:40
func

261:デフォルトの名無しさん
08/03/14 20:18:10
lambda

262:デフォルトの名無しさん
08/03/14 20:22:36
fuck

263:デフォルトの名無しさん
08/03/14 22:15:57
>>259
クラスの役割にかかわらず名前がつけられるなんて思わないでください。

264:オガちゃん萌え ◆tyvkWCNtzY
08/03/15 17:21:41
>>259
クラス名決める前に設計段階で静的モデルからクラス図作るからその段階で関数オブジェクトだろうがクラスだろうがメソッドだろうが役割に適した名前になるんじゃないの？
設計改善してコードリファクタリングの過程でまた適した名前にすると思うんだが？
STLとは関係ないし

使い捨てツール作るなら、名前なんかテキトー
動けばよろし

265:デフォルトの名無しさん
08/03/15 17:37:28
ちょっとした関数オブジェクトの事だろ
他言語なら匿名メソッドとかラムダですませちゃうような奴

そんなん設計段階で無い事の方が多い

266:デフォルトの名無しさん
08/03/15 21:04:14
はーやく来い来いC++0x

267:デフォルトの名無しさん
08/03/15 22:12:04
>>259

by

268:デフォルトの名無しさん
08/03/18 01:34:41
先日放送されたクローズアップ現代(NHKの番組)によると、
日本のプログラマ人口は20万人だそうです(かなり不足して
いるらしい)。この20万人の中で、C++の言語機能を一通り
理解して、STLやBoostなどのライブラリをそれなりに使い
こなすことのできるプログラマは何人ぐらいだと推測しますか？
あなたは20万人の中で上位何パーセントの層に属しますか？

269:デフォルトの名無しさん
08/03/18 01:41:05
マ板で聞いてこいやボケが

270:デフォルトの名無しさん
08/03/18 01:49:52
今は高度なソフトウェアの需要が少ないので
（そういう会社の数が激減したと言うか）
国内でスキルを持っていても活躍の場があまりない気がする。

271:デフォルトの名無しさん
08/03/18 01:53:09
>>269
やっぱり？でもマ版に入り浸っている人じゃなくて、
具体的なC++の質問に答えられる人にききたいんです。

272:デフォルトの名無しさん
08/03/18 01:58:25
C++経験者が30%、うち上記条件を満たす人間が30%と感覚で決めつけたとして
20*0.3*0.3=1.8くらいとかだったらいいなぁ・・・

273:デフォルトの名無しさん
08/03/18 02:02:42
boostともかく、STL使わないC++って、どういう使い方してたら発生するんだろう。
C++経験あったらSTLも使ってるんじゃないの？　（単純な疑問文です。）

274:デフォルトの名無しさん
08/03/18 02:11:44
MFCオンリーなんて人もいるんじゃね？

275:デフォルトの名無しさん
08/03/18 02:16:14
なるほど。

276:268
08/03/18 02:19:12
>>273
STLを使ってるといってもいろいろなレベルがあります。
vectorぐらいは誰でも使っていると思いますが、
コンテナとアルゴリズムを駆使して、コンパクトで
エレガントなプログラムを書くとなるとどうでしょうか？

>>268では "それなりに使いこなすことのできる" 人の数
を問題にしています。

277:デフォルトの名無しさん
08/03/18 03:55:52
STLのアルゴリズムは必ずしも最適解ではないからなぁ

278:デフォルトの名無しさん
08/03/18 04:54:27
>>268
2000人もいないだろ

279:デフォルトの名無しさん
08/03/18 05:10:49
わがまま言ってんじゃねえ
マ板に行け

280:デフォルトの名無しさん
08/03/18 09:06:30
STLやBoostを使えるのが、プログラマ人口の上位とは限らんすぃ

281:デフォルトの名無しさん
08/03/18 10:10:38
しかし、C言語しか使えない、もしくは、C/C++両方使えないのは、下位ケテーイ。

Boostって組み込みじゃ氏んでもツカエンよな。

282:デフォルトの名無しさん
08/03/18 10:34:45
C や C++ が必要とされる分野って、コンパクトでエレガントなコードよりも
効率が良くて高速なコードが要求されることが多いような気がする。
両立できればいいんだろうけどさ。

283:デフォルトの名無しさん
08/03/18 10:39:42
つまり、C/C++でエレガントなコードが書けたら上位けてーい。

284:デフォルトの名無しさん
08/03/18 10:40:29
C や C++ が必要とされる分野って、
開発環境がそれしかサポートしてないだけ

285:デフォルトの名無しさん
08/03/18 10:46:29
つまり、今の組み込みの分野。

C++はじまた。

M$/V$ｵﾜﾀｗ

286:デフォルトの名無しさん
08/03/18 19:49:08
>>268
活躍の場って組み込み系か？
ＤＢ系だとＣなんかよりＪａｖａ　ＶＢ　Ｃ＃のほうがラクだし需要あるし
ダカラナニ？って感じなんだが。
仮にその上位ってやつだったとして
給料が高くなる保障があるわけでもないし
くだらない話題だと思わないわけでもないかもしれない可能性がある

287:デフォルトの名無しさん
08/03/18 22:12:54
組み込みでC++使うにはSTLやBoostを使いこなす事とは別ベクトルのノウハウが要るよ

288:デフォルトの名無しさん
08/03/18 23:14:02
言語に特化した知識だけじゃたかが知れてる。

でも・・・C++かわいいよC++

289:デフォルトの名無しさん
08/03/18 23:14:44
ダメな子ほどかわいい（ぼそ

290:デフォルトの名無しさん
08/03/18 23:19:20
STL、Boostがあるからなんとか付き合っていけるんです。。。

291:デフォルトの名無しさん
08/03/18 23:21:46
STL、Boost使ってるけど、「shared_ptrを自分で書け」って言われても多分書けない俺はゴミ？

292:デフォルトの名無しさん
08/03/18 23:28:22
プログラマとライブラリアンは全然別だから気にすんな。

293:オガちゃん ◆tyvkWCNtzY
08/03/18 23:39:50
STL/boostは可汎的なライブラリで、これそのものを設計、開発するならそりゃ相当のスキルを要するかも？この世にまだこれらが無かったって前提で
最善の選択肢とは限らないし
だけど可汎的だから使うのはさほど大変じゃないと思う…が、使いこなすのはやはり難しいかも
JAVAのステータスがどんどん上がってC++のオブジェクト指向開発してるPRJ減ってきたような
C++でも構造体をpackしてmemcpyしてるのざらだもんなあ
今のPRJはユースケース駆動モデル(Rational統一プロセス)でOOPに加えてAOP的発想あるが…
スレ違いスマソ

294:デフォルトの名無しさん
08/03/19 03:27:01
テンプレートが絡むとソースが美しくないんだよなぁ、なんか。

295:デフォルトの名無しさん
08/03/19 04:13:55
おまえさんの美意識は知らんが、
型指定が冗長だからtypedefかヘルパー関数の嵐になるのは仕様。
C++0xのautoで解決されるのも仕様。
既存のライブラリをC++0x用にせっせと書き直す作業が待っているのも仕様。

296:デフォルトの名無しさん
08/03/19 07:23:45
解決はされないんじゃないかなあ。
メンバ変数に書く際には auto じゃどうしようもないだろうし。

297:デフォルトの名無しさん
08/03/19 09:42:06
template typedefが欲しい

298:デフォルトの名無しさん
08/03/19 10:15:40
>>295
既存のライブラリをわざわざC++0xでしか通らないように書き換えたりするの?

299:デフォルトの名無しさん
08/03/19 10:20:21
>>295
コイツは。。

300:デフォルトの名無しさん
08/03/19 15:42:21
この言語って機能が多すぎて大人数でプログラム組むの大変じゃない？

301:デフォルトの名無しさん
08/03/19 15:45:27
なんで？

302:デフォルトの名無しさん
08/03/19 15:50:05
多分MFCの話じゃね？それならそのとおり。

でも純粋C++なら安定部品を作ればよいだけ。

303:デフォルトの名無しさん
08/03/19 16:22:00
一口に「C++使える」と言っても、人によってその差は大きいから、
できる人からできない人まで集まってしまうという点では大変だと思っている。
同じようなレベルの人同士でならそう大変でもないはず。

304:デフォルトの名無しさん
08/03/19 17:28:32
まるで自分はできるとでも言ってるかのよう

305:デフォルトの名無しさん
08/03/19 18:01:01
ＣとＣ＋＋の差が分かってない人がほんと増えた気がする
だから困るかっていうと困るほどのものでもないんだが

306:デフォルトの名無しさん
08/03/19 18:02:16
>>305
C++がUNIXﾓﾝﾘｰで単なるC言語のプリプロセッサだったころの、
クラスって何、
の時代しってんのかぁ？ｺﾞﾙｧ。

307:デフォルトの名無しさん
08/03/19 18:05:18
俺が憶えた頃は、まだ一部のコンパイラでは
C++から一旦Ｃのコード吐いてからコンパイルしてたな。
もちろん例外処理なんて粋なもんは無かった。

308:デフォルトの名無しさん
08/03/19 18:06:45
まるで見当違いな>>306の突っ込みはいかがなものかと思う今日この頃
＞ＣとＣ＋＋の差が分かってない人がほんと多かった気がする
　　　　　　　　　　　　　　　　　　　　　　　　　　　~~~~~~~~
なら分かるんだけどね、ってどうでもいいスレ違い続けてんじゃねえ！ｺﾞﾙｧ。

309:デフォルトの名無しさん
08/03/19 18:09:53
いちいちコメントしないと気がすまない奴らばかりだな
STLの話しろや

310:デフォルトの名無しさん
08/03/19 18:10:51
ｲﾃﾚｰﾀﾝが無いとSTLの話できない椰子らｗ

311:デフォルトの名無しさん
08/03/19 18:14:28
できるできないとかどんだけ春なんだよ。
できて当たり前。
できないのは単にやってないか馬鹿だから。

312:デフォルトの名無しさん
08/03/19 18:17:11
STL、boostに関しては、それはいえない。
一通りやり終えるまでどんだけ。

313:デフォルトの名無しさん
08/03/19 18:17:16
でもさSTLとかも使ってないと忘れるよな。
おれ深く勉強したけど、もう1年くらいやってないから
忘れてるわC++　アハハハ

314:デフォルトの名無しさん
08/03/19 18:19:51
STLでなくても、1年あれば何だって忘れる。

315:デフォルトの名無しさん
08/03/19 19:00:49
スマートポインタが用意されているのに使わない人がいるとちょっとあれーと思ってしまう。

316:デフォルトの名無しさん
08/03/19 19:12:57
shared_ptrはBoostだから使わなかった、使えなかったという人がいたら、
TR1の普及で使うようになってくれるといいな。

317:デフォルトの名無しさん
08/03/19 19:19:42
Boostがなくてもメイヤーズの本見て作っておけばいくらでも使えたはず。

318:デフォルトの名無しさん
08/03/19 19:54:44
Boost/TR1が多数の現場で使えるようになるまで
何年かかることやら

319:デフォルトの名無しさん
08/03/19 20:46:08
shared_ptr っぽいものは boost とは別のライブラリに用意されてるけど
ほとんどの人が使ってない罠。
まずは啓蒙からだな・・・。

320:デフォルトの名無しさん
08/03/19 20:51:21
shared_ptr使わないなんてあり得ないな、おれは。自分でdeleteなんて嫌だよ。
もうそんな時代ではない。細部を理解する必要はあるけど。それこそメイヤーズ
みたいな貴重な本があるし。

321:デフォルトの名無しさん
08/03/19 20:55:19
Boost だから使えない、というような微妙な状況のときは、
自家製の refcount_ptr とか適当に作っちゃうなぁ。
代入や解放をスレッドセーフにしたいときとかも。

322:デフォルトの名無しさん
08/03/19 20:56:42
でも、scoped_ptr や auto_ptr で済む状況も多いと思う。
shared_ptr まで必要になるのって意外と少ない気がする。

323:デフォルトの名無しさん
08/03/19 21:00:51
Boostだって素人が作ってるわけではないし、むしろエキスパートが作ってる
んだから何が不満なんだよと言いたい。それとも何処の馬の骨とも分からないやつ
が作った自作ライブラリのほうが安全なのかよと。上司に言いたい。

324:デフォルトの名無しさん
08/03/19 21:05:42
こういった場合安全性よりライセンスが問題になることが多いが、
boost のライセンスってゆるゆるだよね？

325:デフォルトの名無しさん
08/03/19 21:13:21
場合によっちゃあソースコードレビューの対象にせざるを得ないから
（& Bootst はレビューしたくないから）自前で書く、ということもあるな。

326:デフォルトの名無しさん
08/03/19 21:14:49
あれだけレビューされてる boost を
もう一度レビューするのも車輪の最発明と大して変わらない作業のような。

327:デフォルトの名無しさん
08/03/19 21:16:08
ライブラリのプロが書いたソースを一般レベルのプログラマがレビューするのって
滑稽じゃね？と上司に言いたい。

328:デフォルトの名無しさん
08/03/19 21:18:08
STL もレビューしてんの？
あんなの読みたくもないが。

329:デフォルトの名無しさん
08/03/19 21:56:08
勉強になっていいじゃん >327

330:デフォルトの名無しさん
08/03/19 22:12:25
まあ勉強会としてはありかもしれない,、。

331:デフォルトの名無しさん
08/03/19 22:34:26
VS付属とSTLPortの実装を比べた事はあったなー。おもしろかった

332:デフォルトの名無しさん
08/03/20 05:11:22
小ささと速度を求めて、shared_ptr => intrusive_ptr => 俺スマートポインタ、と移行したことならある。
intrusive_ptr::operator=()が、いわゆる「スワップ技法」使ってるんだけど、これがBCB6だと遅くて。
こういう「局地的な場面」でまでboostを絶対視するのはいかんってことだね。
概ね信じろ、しかし盲信はするな、と。まぁ当たり前のことなんだけど。

333:デフォルトの名無しさん
08/03/20 05:25:05
ローカルな話題を堂々と振られるのもあれだな

334:デフォルトの名無しさん
08/03/20 05:30:12
「使う」話は遍くローカルだよ。

335:デフォルトの名無しさん
08/03/20 05:55:08
ローカルの事情で使いものにならないこともあると
言いたいのだろうけどそんなのはローカルの事情でしかないだろう。
一々ローカルにかまってたら標準の意味がないだろうよ。

336:デフォルトの名無しさん
08/03/20 06:14:08
>>332はローカルな事情をタネにして
>概ね信じろ、しかし盲信はするな
っていう一般的な意見を述べてるだけだろ

話題自体はローカルじゃないし、標準がどうあるべきだという話もしてないと思う

337:デフォルトの名無しさん
08/03/20 06:31:42
>>336
その結論に持っていくネタがなんだかなって話だろ？
俺も小ささとか速度で難癖つけるのはどうもずれているような気がする。
誰も速度が速いとかオールラウンドに使えるという話はそもそもしていないんじゃね。

338:デフォルトの名無しさん
08/03/20 06:34:34
>>335
> ローカルの事情で使いものにならないこともあると言いたいのだろうけど
いや、boostの実装には「手を抜いている」部分もあり、必ずしも細部までエキスパートの優れた仕事って
わけではない、という話。
つまり「ローカルの事情の話」ではなく「ローカルの事情を通して知ったboostの実装の話」ね。
だから「boostの話はスレ違いだ」は受け入れるけど、「上司の意向の話」以上にずれた話題と思われるのは心外だなｗ

そこから来る結論は>>336の通り。初心者がboostへの信頼を信仰にまで高めちゃいそうな流れだったから、
思考停止だけはしちゃいけないよね、というレスが事例付きで一つくらいあったほうがバランス良いと思ったんだ。

339:デフォルトの名無しさん
08/03/20 06:41:18
あ、すまんもう一つレスが入ったか。

>>337
難癖ではないよ。boost大好きだし。
> 誰も速度が速いとかオールラウンドに使えるという話はそもそもしていないんじゃね。
いや、>>332もそういう話はしてない。
「エキスパートが作ってるという話」「ライブラリのプロが書いたソースだという話」の一環として書いた。

エキスパートとかプロっていう表現が踊り出すと（この表現自体は正しい）、ある種の人間に
変な思考を植え付ける結果になることがよくあるんだ。
冷静に判断しなきゃいけないところで「boostのほうが凄いに決まってる！だってエキスパートが作ったんだもん！」
「だってライブラリのプロが書いたんだもん！」みたいなね。

そんな馬鹿は放っておけばいいという意見もあるだろうけど、でも俺は今回、信じすぎは良くないからね、
という一言があったほうが、流れとして適切だと判断したから書いたわけ。

340:デフォルトの名無しさん
08/03/20 07:18:46
車輪を再発明するよりSTLやboostで合うなら使っていこうよ
レビューされているぶん、俺たちが会社で書く似たようなコードより信頼性は高いだろう
これだけの話だろ

車輪が環境に合わない場合は自作するしかないけど(>>333 の場合)
自分で書くよりは信頼性が高いだろうというだけの話が
何故信仰や絶対という話になるのか理解に苦しむな…

341:デフォルトの名無しさん
08/03/20 07:20:39
リンクミス >>332 の場合

342:デフォルトの名無しさん
08/03/20 07:35:59
>>340
そう、それだけの話。
で、>>332も「それだけの話」なんだけど（boostは概ね信頼できるという「事実」に対して、
必ずしも我々を越えちゃいないという「事実」を例示付きで添えただけ）、妙に突っ込む人がいて長くなってる。

343:340
08/03/20 07:41:09
>>342
俺も突っ込んでる一人なんだが…ｗ

344:デフォルトの名無しさん
08/03/20 07:47:11
>>343
見ればわかるけど・・・。

345:デフォルトの名無しさん
08/03/20 07:50:01
この環境ではスピードが遅くて使い物にならん！だから自作した！
boostは盲信するな！絶対視するな！
こんなｲﾐﾌな展開にツッコミ入れない人間がどこにいるの。ﾜﾛｽ

346:デフォルトの名無しさん
08/03/20 07:52:42
ｲﾐﾌな展開になるように言い換えてるからじゃね？
そもそも>>332一つなら「展開」でも何でもないよ。単発だもの。「展開」は皆で「作った」んだよ。

347:デフォルトの名無しさん
08/03/20 07:54:29
なんかもう、1レスずつ突っ込み方が違っちゃってて、
数撃ちゃ当たる状態だな。そんなに必死に「やり込めたく」なるのかなぁ、俺のレス。

348:デフォルトの名無しさん
08/03/20 08:12:22
初心者です。STLのエラーメッセージが黒魔術で困っています。
皆さんはどのように理解してデバッグなさっていますか？

349:デフォルトの名無しさん
08/03/20 08:30:04
Effective STL に「STLのエラーを読めるようにしよう」みたいな項目がある。
要約すると、 std:basic_string< ～ > とかを string に置換して読むこと、
こういうエラーが出たときはこういうミスを犯している可能性が高いっていう対応を知ること。
俺はエラーメッセージは読まずにえらーが出てる最初の行だけ見て直すけどｗ

350:デフォルトの名無しさん
08/03/20 09:34:19
>>348
エラーメッセージは見るな
自分のソースを見ろ

351:デフォルトの名無しさん
08/03/20 09:35:11
C++　Templateにも追い方が少し書いてあったと思う

352:デフォルトの名無しさん
08/03/20 09:36:01
初心者って絶対自分のコード疑わずに
コンパイラのせいにするよなぁ
C++どころかCの頃からそうだったなぁ

353:デフォルトの名無しさん
08/03/20 09:46:10
言語に関らずそうだよ

354:デフォルトの名無しさん
08/03/20 10:49:36
VC++だとテンプレートの中でエラー・警告が出たら、
その呼出元も表示してくれるので、
ひとまず自分のソースコードのどこの行が悪いのかはわかる。
あとはにらめっこの始まりなんだけどね。

355:デフォルトの名無しさん
08/03/20 12:23:57
とりあえずエラー行を見る。
それで大体の場合は分かる。

それで分からない場合、
次はテンプレートの型とエラーの種類を見る。
長ったらしいテンプレート引数は別に見なくていい。

それで分からない場合にはいよいよテンプレート引数を見るけど、
大体はその中で自分で作ったクラスが悪さしていることが多いのでそれをまず見る。

それでもダメな時は全体を見る。

356:デフォルトの名無しさん
08/03/20 13:12:39
const指定が間違ってるとか
名前照合に失敗してるとか
そういうことが多いような

357:デフォルトの名無しさん
08/03/20 13:19:10
自作関数オブジェクトをアルゴリズムに適用するときとかね

358:デフォルトの名無しさん
08/03/20 13:29:42
>>356
constの有無程度なら「constがある/ない」で警告してくれればいいんだけど、型を変換できないと言われてtypedefしてない型を延々出されると何事かと思う。
もう慣れたけど。

359:デフォルトの名無しさん
08/03/20 13:57:09
STLの内部で使ってるの型を吐き出してくれるから、
VS付属→STLPortとか実装を取り替えると同じエラーでもメッセージがぜんぜん違ってくれる素晴らしい罠。

360:デフォルトの名無しさん
08/03/20 14:02:01
さてconceptはまだですか？

361:デフォルトの名無しさん
08/03/20 20:42:46
boostを盲進、過信するのはやや問題があるとは思う
特に納品物というか成果物としては。いくらboostのライセンスが軽いとはいえ。
boostの一部がTRで採用されて0xに反映されたら標準ライブラリとみなせるだろうけど…
いっぽうで、ツール類作るときは積極的に使用する。
tokenizerとかregexとか、bindなんか使うとやみつきになる

その点、STLはまずコンパイル・リンクエラーなってる場合はほぼ間違いなく自分のコードに問題あり
もしくは、VC++とかBorlandC++とかそういうコンパイラ
でも、テンプレートが展開されたエラーは原因を見つけるのに慣れないと苦労するのも確か。

362:デフォルトの名無しさん
08/03/20 20:53:02
>>361 は標準ライブラリを盲信、過信していると思う。

363:デフォルトの名無しさん
08/03/20 20:54:40
と凡人プログラマが申しております。彼は自分のプログラミング能力が
ライブラリ作成者よりも優れていると申しております。

364:デフォルトの名無しさん
08/03/20 20:55:03
そういうのを盲信って言うんだよw

365:デフォルトの名無しさん
08/03/20 21:07:18
見事に釣られてしまったようです。

366:デフォルトの名無しさん
08/03/20 21:11:49
>>362
361だが、過信してはいないつもりだが、エラーの要因はまず自分のソースを疑うね
その点はboostでも同じだよ
まぁ、そう考えればSTLはバグがないとまでは言わなくとも(実際にある)、自分のソースを疑うってだけだ
だから過信、盲進してるかもな
ただ、boostはコンプライアンス上の問題やらでdefect発生時にどうなのよ？ってだけだよ

技術的な観点では、俺にとってboostはSTLのサブセットだよ。なにせ、boostの開発に携わってるのは
C++標準化の連中なんだから
それに、>>363のいうようにあらゆるケースや検証をして世の中に出てきたSTLと、必要なテストしかしてない
自分の作成したコードが正しいなんて言う根拠はどこにもない
で、>>362はSTLよりも優れたテンプレートを作っていると？ｗ

367:デフォルトの名無しさん
08/03/20 21:18:08
boostはhppって拡張子が嫌い。

368:デフォルトの名無しさん
08/03/20 21:20:04
hppはまだいい
ippってなんじゃらほい

369:デフォルトの名無しさん
08/03/20 21:23:05
現行STLやboostのメンバー見れば凄いのが揃ってるのはわかる。
コンパイラ作成者やM＄のデヴェもいる。

370:361
08/03/20 21:32:54
>>367
俺、boost信者になってからは寧ろ好きになったｗ
だけど、自分のコードはやはり .h を拡張子にしたいね。前プロジェクトではboost使いまくりーの、
.hppを拡張子にしまくりーのだったがｗ

371:デフォルトの名無しさん
08/03/20 21:40:51
>>366
＞boostの一部がTRで採用されて0xに反映されたら標準ライブラリとみなせるだろうけど…
標準ライブラリと見なせることとコードの信頼性に何か関連性はあるのかね、と思ったのよ。

372:デフォルトの名無しさん
08/03/20 21:45:03
>>371
で、boost使ってて何かトラブったことあんの？

373:デフォルトの名無しさん
08/03/20 21:51:19
>>371
すくなくともベンダがリリース前にテストしたという信頼性は担保されるだろ

374:デフォルトの名無しさん
08/03/20 21:54:34
.h はCとの互換性を考えてあるヘッダのみに使って欲しいなあ
C++専用のヘッダは hpp とか hh とか hxx とか使って欲しい

# emacsで開くとc-modeになってしまったという経験がある
# もちろんファイルの先頭にモードを書いておけば済む話だけども

375:デフォルトの名無しさん
08/03/20 21:57:05
要件を満たすための全てのテストが通れば、boostを使っていようが自分で作ったライブラリを使っていようがok
自分で書いたコードが正しいと確信するための作業をboostにも適用すればいいと思う

…標準ライブラリもいろいろで、C++の仕様見てないんじゃないかと疑いたくなるようなのもあるよ

376:デフォルトの名無しさん
08/03/20 22:05:07
>>372
逆。
標準ライブラリと見なせなくても boost には標準ライブラリと同等の信頼性はあると思っている。

377:デフォルトの名無しさん
08/03/20 22:14:20
boostっていっても信頼性は一様じゃないと思うが
Boost.PPの滅多に使われないマクロあたりに嫌なバグが潜んでたとしても驚かないな

次ページ