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の滅多に使われないマクロあたりに嫌なバグが潜んでたとしても驚かないな
378:デフォルトの名無しさん
08/03/20 22:27:47
>>374
# vimのcpp用indentスクリプトの貧弱さは泣けてくる
379:デフォルトの名無しさん
08/03/20 23:22:49
まあ、昔からあってさらに頻用されてるやつは十分信頼性あると思うけどね。
380:デフォルトの名無しさん
08/03/20 23:27:46
っつー訳で
auto_ptr
は使うなと
381:デフォルトの名無しさん
08/03/20 23:39:18
>>374
はげど！
C互換もないのに.hって何だよ？と。
しかしライブラリを見てたらだんだん
ヘダファイルに拡張子なくてもよくね？と思えてきた
382:デフォルトの名無しさん
08/03/20 23:40:52
>>381
エディタで開くときに面倒・・・ただそれだけ。
383:デフォルトの名無しさん
08/03/20 23:46:18
ファイルを分類したいときも拡張子が無いと困るな。
384:デフォルトの名無しさん
08/03/20 23:47:13
拡張子に縛られてるOSは大変だな。
385:デフォルトの名無しさん
08/03/20 23:55:42
ファイル実体内にメタデータ仕込むとかも論外だけどな
386:デフォルトの名無しさん
08/03/20 23:58:24
ファイルシステムに組み込むよな、普通。
387:デフォルトの名無しさん
08/03/21 00:03:46
>>385
それってファイル壊してない？そんなOSがあんの？
388:デフォルトの名無しさん
08/03/21 00:03:49
拡張子だと気軽に書き換えられるからちょっと楽かも
389:デフォルトの名無しさん
08/03/21 00:08:28
xxx.tiff
↓
xxx.jpg
「劣化しますがよろしいですか？」
(OK) (キャンセル) (pngにする)
そんなOSがあったら、使いたくはないが、触ってみたい。
390:デフォルトの名無しさん
08/03/21 00:10:13
マックバイナリというものがあってだな
391:デフォルトの名無しさん
08/03/21 00:12:35
boostの主要な部分って、仕様は固定されてるの？
結局、そこが一番問題じゃないかね。
392:デフォルトの名無しさん
08/03/21 02:08:23
そういや、std::auto_ptr使うような場面でboost::shared_ptr使った時、
実行コスト的にはやっぱり不利になるんかな？
大した違いじゃ無いだろうけど、ちょっと気になる。
393:デフォルトの名無しさん
08/03/21 05:31:04
なる
394:デフォルトの名無しさん
08/03/21 07:07:25
shared_ptr の初期化にはメモリ確保が余分に必要。
参照カウンタが０になった時にはメモリの解放が余分に必要。
395:デフォルトの名無しさん
08/03/21 09:32:33
>>387
9までのMac OSってそうじゃないの？
396:デフォルトの名無しさん
08/03/21 10:08:28
>>394
あと削除子保持するコストも必要だと思う。
397:オガちゃん萌え ◆tyvkWCNtzY
08/03/21 19:34:49
Windowsならともかく、UNIX系は拡張子なんて慣例で付けるものでどうでもいい
が、やはりC++とCのヘッダファイルを区別するのに、hとhxxにしときたい
JAVAとかC#プログラマとかはC/C++でc/cpp、hのペアのファイル直すのがめんどいらしい
398:デフォルトの名無しさん
08/03/21 20:20:44
>>395
違うよ。
いわゆるMacBinaryはデータフォークとは明確に分離してる。
まあ、他のプラットフォームにしてみれば異質なものに代わりはないけど。
399:デフォルトの名無しさん
08/03/21 20:48:12
execが最初の2byteでシェルスクリプトを判断するようなものかな？
どうでもいいけど
400:デフォルトの名無しさん
08/03/22 02:44:49
どっちかと言うと、ファイルのプロパティとしてファイル名やパーミションやタイムスタンプがあるように、
ファイルタイプとクリエータがある感じ。
MacBinary形式と言うのは、これらのプロパティを128バイトのヘッダとし、その後にデータフォークと
(必要なら)リソースフォークを連結した特殊なファイル形式のこと。
401:オガちゃん萌え ◆tyvkWCNtzY
08/03/22 10:16:01
>>400
ファイル名、タイムスタンプ、権限や属性はファイルシステムで管理しているがMacは違うの？
ところで、list.sort()やalgorithmのsort条件を関数オブジェクト使って決めると思うが、
関数オブジェクトという言葉が通じない人が多い
operator()のオーバーロードってことではファンクタというほうがわかりやすいのだろうか？
402:デフォルトの名無しさん
08/03/22 14:22:24
関数オブジェクト自体は理解してるの？
ちなみに自分はファンクタという言い方はあとで知った。
403:デフォルトの名無しさん
08/03/22 14:53:28
関数オブジェクトって関数をオブジェクト化したみたいで好きじゃないな。
コード上で関数のように使えるだけで、関数とは全く関係ないのに。
404:デフォルトの名無しさん
08/03/22 15:19:09
作るのが面倒って点に関してはあまり好きじゃないが、
やってることはエレガントだとは思う。
405:デフォルトの名無しさん
08/03/22 17:22:14
クラスと何が違うのかわかんね
406:デフォルトの名無しさん
08/03/22 17:44:24
特別学級みたいなもんです
407:オガちゃん萌え ◆tyvkWCNtzY
08/03/22 20:16:13
>>402
ファンクタを理解しているか？って言われれば、理解しきっていると言えるほど俺は自信ないｗ
Cの時によく使った関数ポインタのような、イベントハンドリングのロジックを外部化したり、コールバックなんか
に使うもんだという理解が強いかな
あとは、ポリモーフィズムとして同一で処理ロジックだけカスタマイズするときにファンクタとすることが多い
話は変わるが、組込み系ではメモリシステムをラップすることが多いとおもうが、
operator new()、operator delete()、operator new []()、operator delete []()なんかをオーバーロードするときは
EffectiveC++なんかを読み返してしまうよ…
メモリシステムといってそこでリークやオーバーフロー、未初期化アドレスアクセスなんかしてたら偉いことに
なってしまうし
そもそも、自分はC++、STLを理解しきっているとは思ってないよ
先週その典型例があった、C++といいつつCでマクロを書いたのだが、printf()をラップして可変引数をログ出力
するってやつ。stdarg.hの使い方を分かってなかったｗ
そういう>>402は？
408:デフォルトの名無しさん
08/03/22 20:22:45
stdarg.h 使うってことはマクロじゃないんでない？
まあ、その関数をさらにマクロでラップしてるんだろうけど。
409:402
08/03/22 20:26:05
いや、402は、「あんたが理解してるか？」の意味じゃなくて、
「関数オブジェクトという言葉が通じない人は関数オブジェクトの存在を知らないから通じないんじゃない？」っていう意味です。
関数オブジェクトという用語を知らずに関数オブジェクトを使うかなあって思ったから。
自分も理解しきってないよ。簡単な関数オブジェクト作れるレベル。
410:デフォルトの名無しさん
08/03/22 20:51:00
なんで雑談してんの？
411:デフォルトの名無しさん
08/03/22 23:17:29
相談が無いからだろう
相談できる雰囲気でもないがね
412:デフォルトの名無しさん
08/03/23 00:44:28
何で雑談しているのかを聞く それも雑談なんじゃね？
自分の胸に聞くのがはえーんじゃね？
413:デフォルトの名無しさん
08/03/23 01:03:59
>>407
ひょっとして有名人？
関西でPGでかつどうしてんの？
414:デフォルトの名無しさん
08/03/23 01:10:46
とりあえず２期のオガちゃんは萌えた。
415:オガちゃん萌え ◆tyvkWCNtzY
08/03/23 20:37:34
>>409
ざらにいるんじゃないか、ファンクタを知らないPGは
だけど、今のPRJはユースケース駆動モデルでOOPかつAOP的コンセプトを多分に取り入れてる
から、ファンクタや関数オブジェクトの名前すら知らないようではさすがにPGとして使えない
デザインパターンの幾つかを理解しているくらいは最低求められる
とはいいつつも、知らずにそういうパターンを使っているってことは経験あるとおもうよ
大抵はライブラリとして用意されてるものを別途作って無駄なことやってることになるんだろうけどねｗ
>>410-412
まぁ固いこと言わないでマターリやろうよ
>>413
いや、有名人でもなんでもないよｗ
出身地は関西だが、都内で仕事してるしさ
>>414
オガちゃんいいよな！
416:オガちゃん萌え ◆tyvkWCNtzY
08/03/23 20:41:16
>>408
可変引数を使うのにstdarg.hを使ったよ
va_start()やらはマクロを通して最終的にコンパイラ組込み型だからさ
ログ吐き用とはいえ、%SSっていう変なリテラルを敢えて作って、UTF-16の文字列をUTF-8(ASCII)
に変換してログ出しするってのを作ったわけなのだが、案外はまってしまったｗ
417:デフォルトの名無しさん
08/03/24 12:37:23
緒方賢一に萌えるスレはここですか?
418:デフォルトの名無しさん
08/03/27 00:46:11
そうです。
419:デフォルトの名無しさん
08/04/16 01:48:57
vectorにデータを追加した時にメモリ確保に失敗した場合、検出する方法ってありませんか？
newでいうbad_allocの例外をキャッチするような感じ。
420:デフォルトの名無しさん
08/04/16 02:12:07
bad_alloc捕まえれば？
URLﾘﾝｸ(hpcgi1.nifty.com)
421:デフォルトの名無しさん
08/04/16 02:18:03
>>420
な、なんだこの低レベルなやり取りは…
422:419
08/04/16 02:26:03
>>420
お！
VC2005で確認しました。
STLでもbad_allocスローしていたんですねｗ
あざ～す♪
423:デフォルトの名無しさん
08/04/16 02:58:35
アホすぎる
424:デフォルトの名無しさん
08/04/16 03:43:19
VC6 ではデフォルトで new が bad_alloc 投げなくて
アクセスバイオレーションになるのは有名な話だけどね。
425:デフォルトの名無しさん
08/04/16 07:17:17
で？何処にVC6だという前提が示されていたの？
426:デフォルトの名無しさん
08/04/16 08:01:17
なんだこの意味不明の質問
427:デフォルトの名無しさん
08/04/16 20:34:00
で、どこにＶＣ６でないという前提が示されていたの？
とでも言ってほしんだろうか
おまえらもっと仲良くしろよ
タダでさえ過疎ってんのに
428:デフォルトの名無しさん
08/04/16 21:03:38
424 は 豆知識としてとらえるのが普通だと思うんだけどな。
419の環境がどうとかじゃなくて。
429:デフォルトの名無しさん
08/04/16 22:01:51
常識人は一人だけ。残りは全員アホ。
そんな微妙すぎるリンクを貼った>>420がまず意味不明。
>>424の内容はもっともだが、VC6世代なら誰でも知ってる常識レベル。
なぜあえてそこだけピックアップして言及したのか意味不明。
何にカチンと来たのか、その後の煽り合いも意味不明。
つまりお前ら全員意味不明。
430:デフォルトの名無しさん
08/04/16 22:17:11
なぜあえて、というところは>>419>>420>>422の「bad_alloc がスローされるんだ♪」
という流れを見ての、ちょっとした老婆心じゃね？
431:デフォルトの名無しさん
08/04/17 00:17:46
>>429
要するに、君は色んなことの意味がことごとくわからない人、なわけだよね。
可哀相だけど、馬鹿につける薬って無いらしいから・・・合掌。
432:デフォルトの名無しさん
08/04/17 02:22:42
おまえら昔はぬるぽ返してたんだよとか
今でもnothrowとかできるんだよとか
ちゃんと教えてやれよ
433:デフォルトの名無しさん
08/04/17 02:28:35
この程度で煽りに見えるとか
434:デフォルトの名無しさん
08/04/17 07:10:34
VC だとぬるぽは VC6 までだね。
だからこそ STL で >>424 が起こる訳だが。
435:デフォルトの名無しさん
08/04/17 07:23:43
>>433
ま、煽りではあると思うよ、実際。
煽りと感じないことをアピールして煽り耐性自慢してもしょうがない。
436:デフォルトの名無しさん
08/04/17 19:15:49
仲良くしようよ。
437:デフォルトの名無しさん
08/04/17 20:11:21
friend関数を
438:デフォルトの名無しさん
08/04/18 11:08:29
窓から
439:デフォルトの名無しさん
08/04/18 11:12:05
こんにちは
440:デフォルトの名無しさん
08/04/18 12:20:53
やあ、おぜうさん
441:デフォルトの名無しさん
08/04/18 18:48:43
まあ、ごきげんやう
442:デフォルトの名無しさん
08/04/20 12:21:42
よひてんきですね
443:デフォルトの名無しさん
08/04/20 12:47:47
庭にはてふてふも飛んでます
444:デフォルトの名無しさん
08/04/22 13:36:50
std::list::erase の引数の型は std::list::const_iterator の方が適切ですよね?
445:デフォルトの名無しさん
08/04/22 13:42:02
なんで？
446:デフォルトの名無しさん
08/04/22 14:58:19
std::list::erase() に渡した反復子の参照先が将来的に変更されることがないからです。
447:デフォルトの名無しさん
08/04/22 15:09:25
constなポインタでもdeleteできるから、
それもある意味整合性があると言える気がする。
448:デフォルトの名無しさん
08/04/22 20:57:09
同じタイプのmapが２つあったときに、
片方のmapにもう片方のmapの要素を全部移動する方法ってありませんか？
swapみたいにコピーしないで済む方法があればいいんですが。
449:デフォルトの名無しさん
08/04/22 23:28:33
swapじゃダメな理由は？
450:デフォルトの名無しさん
08/04/22 23:29:25
joinしたいからswapじゃダメなんじゃね
451:デフォルトの名無しさん
08/04/22 23:38:01
>>449
450さんの言われたとおりです。
限定的にしか使わないクラスをsecondにしてるので
operator=オーバーライドしてコスト下げるしかないかなぁとは思っています。
Boostとかであればそれでもいいんですが。
452:デフォルトの名無しさん
08/04/22 23:39:45
second をポインタにして、
実体はリストに保持しておくとか。
453:デフォルトの名無しさん
08/04/29 01:25:04
STLportのVC9正式対応版はよくれ
454:デフォルトの名無しさん
08/05/05 17:27:47
typedef std::iterator<std::bidirectional_iterator_tag, char> MyIterator;
MyIterator it;
*it = 'A';
これは、何がいけないんでしょうか？
455:デフォルトの名無しさん
08/05/05 17:38:17
int* p;
*p=0;
これのどこがいけないと思いますか？
456:デフォルトの名無しさん
08/05/05 17:44:16
なぜ質問に質問でこたえるのですか？
457:デフォルトの名無しさん
08/05/05 17:58:26
質問に質問で答えてはいけないのですか？
458:側近中の側近 ◆0351148456
08/05/05 18:03:57
>>454
(っ´▽｀)っ
itの記憶領域確保しろよ☆
it = new MyIterator('A');
かな？
459:デフォルトの名無しさん
08/05/05 18:11:05
え？
460:デフォルトの名無しさん
08/05/05 18:13:01
>>455>>458
そういう問題じゃないだろ
そもそもstd::iterator<>はインスタンスを作ることを意図したクラスじゃないし、
operator*も定義されてない
461:デフォルトの名無しさん
08/05/05 18:19:39
>>460
いや、阿呆なのは458だけでしょ。
>455の例えはよくわかる。
462:デフォルトの名無しさん
08/05/05 18:23:11
俺にはさっぱり分からん
463:側近中の側近 ◆0351148456
08/05/05 18:23:46
>>461
(っ´▽｀)っ
そうだよ。(っ´▽｀)っがヴァカなだけだよ
464:側近中の側近 ◆0351148456
08/05/05 18:26:04
(っ´▽｀)っ
だってC++よくわからないんだも～ん☆
465:デフォルトの名無しさん
08/05/05 18:26:07
m9('A')
466:デフォルトの名無しさん
08/05/05 19:29:39
>>454
じゃあ、どんな動作を期待しているのか述べてみよう。
467:デフォルトの名無しさん
08/05/05 20:51:15
>>461
胴囲
468:デフォルトの名無しさん
08/05/07 21:58:26
>>455の例えは全然わからんな。
何が言いたいの？
469:デフォルトの名無しさん
08/05/07 22:01:40
何も指してないイテレータを参照剥がししてどうすんだ？
わかりやすくポインタで例えてやろうかあぁ？
470:デフォルトの名無しさん
08/05/08 06:00:33
もし>>469なら、やっぱり的外れだろ
std::iterator<>はそもそもイテレータじゃないんだから
471:デフォルトの名無しさん
08/05/08 07:23:47
ぼくにも分かりやすいようにガンダムで例えてください
472:デフォルトの名無しさん
08/05/08 11:49:01
ガンダムの格納庫はあるのに、
肝心のガンダムがない
473:デフォルトの名無しさん
08/05/08 12:48:04
std::string とかでぬるぽ使えないのはなんで？
474:デフォルトの名無しさん
08/05/08 12:49:07
>>473
どういう動作をさせるためにどうやって使いたいのかわからない。
475:デフォルトの名無しさん
08/05/08 14:19:39
>>474
const char * にNULLを渡すか空文字を渡すかで動作が違う関数があると、
それをstd::stringでラップするときに微妙に困るじゃない。
476:デフォルトの名無しさん
08/05/08 14:36:20
boost::optionalの出番か?
477:デフォルトの名無しさん
08/05/08 15:07:11
>>475
class my_string : public std::string {
bool m_is_null;
public:
my_string() : m_is_null(true) {}
operator=(const char* p) { if (p==NULL) set_null() else set_string(p); }
operator=(const std::string& s) { set_string(s); }
void set_null() { m_is_null = true; clear(); }
void set_string(const std::string& s) { m_is_null = false; *this = s; }
bool is_null() { return m_is_null; }
}
478:デフォルトの名無しさん
08/05/08 19:30:54
>>477
実は同じのを作って使ってるんだ。でもありがとう。
479:デフォルトの名無しさん
08/05/08 19:58:46
Concrete Containerをplubic継承www
480:デフォルトの名無しさん
08/05/08 20:02:34
と笑う人もいるので、抽象化して
template <class T> Nullable : public T
{
...
};
などしておいてはどうだろうか
481:デフォルトの名無しさん
08/05/08 20:14:25
仮想デストラクタのないクラスはpublic継承しちゃだめだろ常識的に考えて・・・
482:デフォルトの名無しさん
08/05/08 20:16:28
delete されるような場面でアップキャストしなけりゃ良いんじゃね？
483:デフォルトの名無しさん
08/05/08 20:16:43
すると笑う人は笑わないのか？
484:デフォルトの名無しさん
08/05/08 20:26:28
結局boost::optional自作になるのか
485:デフォルトの名無しさん
08/05/08 20:42:08
なんで継承したがるんだ
486:デフォルトの名無しさん
08/05/08 21:01:00
楽にかつ安全に特徴を追加する方法って無いのかねぇ…
487:デフォルトの名無しさん
08/05/08 21:33:02
普通にオーバーロードを活用すればいいんじゃね？ >486
488:デフォルトの名無しさん
08/05/08 22:14:23
std::string * でいいような…それかboost::optional<std::string>
489:デフォルトの名無しさん
08/05/09 01:12:47
const char *でいいだろ・・・
490:デフォルトの名無しさん
08/05/09 02:04:55
話は逸れるけど、逆にnullが存在し得る参照型Stringを持つJava/C#を触ると、
nullの存在がうっとおしいと思うときがあるから不思議。
491:デフォルトの名無しさん
08/05/09 07:19:30
ぬるぽ
492:デフォルトの名無しさん
08/05/09 08:13:15
>>490
そうそう、無効値としてnullか""のどちらにするか結構悩む。
493:デフォルトの名無しさん
08/05/09 11:55:38
std::iterator は仮想デストラクタないけど public 継承していいんですか?
494:デフォルトの名無しさん
08/05/09 13:04:18
EBOがあるからいいんじゃないか？
495:デフォルトの名無しさん
08/05/09 13:06:26
間違えたｗ
気にしないで・・・。
496:デフォルトの名無しさん
08/05/09 13:17:01
>>493
typedefしかしてないクラスだから、public継承しないと意味無いと思うけど。
497:デフォルトの名無しさん
08/05/09 15:25:34
このほうが安全じゃない?
class my_iterator : private std::iterator<Tag, Type> {
typedef std::iterator<Tag, Type> super_t;
public:
using super_t::iterator_category;
using super_t::value_type;
using super_t::difference_type;
using super_t::pointer;
using super_t::reference;
};
498:デフォルトの名無しさん
08/05/09 18:20:17
std::iterator や std::unary_function のようなクラスは
protected な非仮想デストラクタが定義されていればいいのに。
499:デフォルトの名無しさん
08/05/09 18:23:23
>>498
自分が何言ってるかわかってるのかｗ
500:デフォルトの名無しさん
08/05/09 18:53:04
それ自身インスタンス化することないし、基本クラスとして使うこともないし
いいじゃないの?
501:デフォルトの名無しさん
08/05/09 19:07:08
データメンバもメンバ関数もないクラスにアップキャストしても
何もいいこと無いからな
502:デフォルトの名無しさん
08/05/09 19:56:40
マーカインタフェースという概念があってだな。
503:デフォルトの名無しさん
08/05/09 20:22:33
>>499
C++ Coding Standardsの50項目目に紹介されている。
504:デフォルトの名無しさん
08/05/09 20:30:15
URLﾘﾝｸ(www.open-std.org)
で提案している人がいますね。
反論もあるようです。
505:デフォルトの名無しさん
08/05/09 21:04:17
反論の根拠ってなんでしょうか。
506:デフォルトの名無しさん
08/05/09 21:04:56
>>504に書いてある
507:505
08/05/09 21:13:02
そこの部分だけ一回で理解できなかったのですが、理解できました。ありがとう。具体的なケースはよく分かってませんが。
508:デフォルトの名無しさん
08/05/10 02:18:22
URLﾘﾝｸ(www.wakhok.ac.jp)
ここを見て、stringのメンバ関数findの実装が知りたいと思い、
stringファイルの中を検索してみたんですが見つかりません(環境はVC2008EE)。
find関数は廃止されちゃったんですか？
509:デフォルトの名無しさん
08/05/10 02:27:12
VC++ならコードを書いて、右クリックの定義へ移動が便利。
510:508
08/05/10 02:36:53
thx
xstringファイルに定義されていました。
インクルードの経路が複雑・・・。
511:デフォルトの名無しさん
08/05/10 11:21:32
>>482
>ほとんどの台は左第一停止で引き込み100%だったっしょ。（チェリーバーは順押しで引き込み100%）
いや、だから「すげー細かい」ってことだったんで・・・
スーパーヘビーメタルについては「リプor緑/リプ/リプ」がJacInなんで引き込み100%かと・・・
URLﾘﾝｸ(www.pachinko-club.com)
ミラクルUFOに関してはわからず・・・
>初BET枚数の異なる2種類ボーナス △ デビルメイクライ3 ロデオ 4種類REGの内、1つが1枚、他は2枚
リオパラダイスがBIG/REGでBET枚数違ったような・・・（リオが3月でDMCが6月）
512:デフォルトの名無しさん
08/05/10 12:34:56
業界初ｽﾚか。珍しい誤爆だなあ。
513:デフォルトの名無しさん
08/05/10 15:50:42
ごめんなさいorz
514:デフォルトの名無しさん
08/05/10 19:18:19
やっべ何言ってるかさっぱり分からんｗ
うちらも外から見たら同じなんだろうけど
515:デフォルトの名無しさん
08/05/10 22:31:28
>>514
> うちらも外から見たら同じなんだろうけど
むかしガイドライン板に「一度も行ったことない板に行ってみるスレ」ってのがあって、
この板を覗いた奴の感想は「わけわからん。半分ぐらい日本語じゃない」だったなｗ
516:デフォルトの名無しさん
08/05/10 23:07:22
マジでまったくわからんなｗ
まぁ、俺はこの板の内容も半分以上わからんが
517:デフォルトの名無しさん
08/05/11 02:54:05
そういわれるといかにも初心者丸出しな質問でさえ高度に見えてくるぜ
518:デフォルトの名無しさん
08/05/13 01:01:43
す、すいません・・・
STLをかじり始めの者なのですが、質問があります。
std::ofstreamだのstd::wofstreamだのをいじってみたのですが、
どうしてもユニコードでファイル出力ができません。
std::setlocale("japanese")とやってみると、どうやらshift-jisの
テキストが出力されてしまうみたいなんですが・・・。
STLを利用してユニコードのテキストファイルを出力するには
どうすればいいのでしょうか？よろしくお願いします。
ちなみにVC9を使用しております。
519:デフォルトの名無しさん
08/05/13 01:28:34
>>518
ストリームをテキストモードで開いているとUnicodeからANSIへの変換が暗黙のうちに行われます。
バイナリモードで開くとこの変換は行われません。
520:デフォルトの名無しさん
08/05/13 02:03:53
wchar_tはUTF-16だったりUTF-32だったり処理系定義だということに注意。
521:デフォルトの名無しさん
08/05/13 02:08:04
>>518
VC限定ならpubsetbufで大丈夫なはず。
URLﾘﾝｸ(msdn.microsoft.com)
ただしVCのバージョンによっても挙動が違ったはず。
binaryでも大丈夫になったのかな？
最終手段としてはwchar_t*をchar*に無理やりキャストして書き込むとか。
522:518
08/05/13 03:33:12
>>519
>>520
>>521
のみなさん、返答ありがとうございました。バイナリで書き込まない
といけなかったのですね・・・。>>521さんの貼り付けてくれたサンプル
コードでなんとか分かりました。やっとUTF-16のテキストファイルを
作成することができました。ありがとうございました。
523:デフォルトの名無しさん
08/05/13 08:40:07
C#とかの.NET系なら、UTF-16,UTF-8,UTF-32,Shift_JIS,ISO-8859-x,Windows-xxxやら、
システムがサポートする文字コード全て、パラメータ指定するだけで出力出来るんだけどね。
524:デフォルトの名無しさん
08/05/13 08:57:05
つlibiconv
525:デフォルトの名無しさん
08/05/13 15:10:11
つICU
526:デフォルトの名無しさん
08/05/13 15:18:48
つmlang
527:523
08/05/13 18:58:21
C#とかの.NETなら、標準ライブラリのみで、普段入出力に使用しているクラスに
パラメータとして文字コードを追加していするだけでいいんだけどね。
528:デフォルトの名無しさん
08/05/13 19:13:27
それだけの理由でC#を使えるようならとっくに使っているわ。
529:518
08/05/15 21:06:15
す、すいません・・・
その後、いろいろと読み漁ってみた結果、上記のままの理解では、
このスレを読んでいる、同じ疑問を持った人に、無用な誤解を与える
恐れがあるかも知れないので、分かったことを書いておきます。
std::fstreamなどのストリームの文字コードの自動変換は
std::localeクラスの中にあるファセット(文字セット間の変換、通貨、日付と時刻
などの地域化を司るクラス)と呼ばれる部分で行っているらしいです。
で、文字コード変換を司るファセットはcodecvtと呼ばれており、自分の望んだ
文字コードに変換したい場合は、codecvtの派生クラスを作成するのが、
本来のやり方のようです。で、こんなもんを自分で書くのがよいのか、それとも
既に誰かが書いていて、それを利用できるようになっているのか、というところ
までは、まだよく分かっていません。
URLﾘﾝｸ(imt.uni-paderborn.de)
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(docs.sun.com)
大変お騒がせしました。これにて失礼します・・・。
530:デフォルトの名無しさん
08/05/15 23:15:51
Boost.IostreamsがUTF-8のcodecvtを持っていたはず。
一般のライブラリでの実装と言えばそれくらいしか知らないけど。
531:デフォルトの名無しさん
08/05/21 21:31:09
唐突で申し訳ありませんが、以下、２点質問させてください。
ご意見で結構なので、よろしくお願いします。
①eraseで、listから登録しているクラスのポインタを削除した場合に、
→リストから削除したクラスのデストラクタはコールされる？
リストから要素のみ削除されると理解していたのですが、
VC6.0のSTLのドキュメントを読んだところ、
N回のeraseでN回のデストラクタが呼ばれると書いてあったため困惑中。
②マルチスレッドアプリでコンテナなどを用いるのは危険？(VC6.0を想定)
→MSDNにて、eraseを複数のスレッドから同時に実行するとデッドロックする
という記載等があったため、少なくともVC6.0のSTLは
マルチスレッドアプリを作る上で適当でないと思い始めている段階。
実際、beginなどの引数なし関数コール時にアプリが落ちた経緯あり
532:デフォルトの名無しさん
08/05/21 21:37:54
「listから登録しているクラスのポインタを削除」の意味がワカラン
こういう日本語もワカル人がいるので不思議
そういう人を待て
533:デフォルトの名無しさん
08/05/21 21:41:21
std::list<T>なら、eraseしたときに該当するオブジェクトのデストラクタが呼ばれる。
std::list<T*>なら、該当するオブジェクトとはlistの要素たるT*のオブジェクトであり、
T自体のデストラクタは呼ばれない。
Tオブジェクトのデストラクタが呼ばれるようにしたければ、
boost::shared_ptrでも使えというのがC++の現状。
534:デフォルトの名無しさん
08/05/21 21:42:41
>>531
1. について
ポインタ要素を erase してもデストラクタは呼ばれません。
実体を格納している場合には erase でデストラクタが呼ばれます。
2. について
読み取り専用なら安全です。更新があるなら、明示的に排他制御
しましょう。
535:デフォルトの名無しさん
08/05/22 00:29:50
>>533 534
回答ありがとうございます。
概ね、当方の理解と一致しており、胸を撫で下ろしました。
質問事項②のマルチスレッドでの使用に関しては、
別スレッドでswap/uniqeなどで
iterator iの参照先の内容が変わることを考慮すると、
begin等も容易には使えないですね。
ちなみに、今、他人のソースをレビュー中でして、
人のソースを見ていると、自分の理解が正しいのかどうか
ちょっと不安になってきたりと・・・oTL
536:デフォルトの名無しさん
08/05/22 01:10:30
>>535
unique後はそもそもイテレータが無効になるから、マルチスレッド以前の問題だね。
537:デフォルトの名無しさん
08/05/22 01:33:51
>>535
スレッド安全性については規格では何も規定していないから、実装ごとにドキュメントを
読む必要がある。ドキュメントに記載がなければ、同時アクセスは一切できないものと
考えたほうがいい。そういう実装もあるので、最大限の移植性が必要なら同時アクセスは
一切できないものと考えるべき。
538:デフォルトの名無しさん
08/05/22 12:03:22
Intel謹製のスレッドセーフSTLがあったような・・・
あとポインタ格納しつつeraseしてもデストラクトする実装ならboost::ptr_listってのがある
539:デフォルトの名無しさん
08/05/22 20:39:50
>>537
自分もそうおもふ
540:デフォルトの名無しさん
08/05/22 21:56:49
VC 7.1以降だと文書化されている。
URLﾘﾝｸ(msdn.microsoft.com)
あるオブジェクトについて、同時読取り可、単一スレッドの書込み可。
同時書込みや読み書き同時は不可。
スレッドごとに別のオブジェクトを読み書きするのは問題ない。
例外的にストリーム出力は同時書込み可。
541:デフォルトの名無しさん
08/05/22 22:19:18
テンプレートライブラリはクラスのマクロみたいなもんですよね？
コンパイル時に全部展開されるので多用する場合はメモリを無駄に消費しそうなんですが、
比較的大規模なアプリを作るときは、やはりコンパイル済みのライブラリを使うべきなんでしょうか？
例えばMFCとSTLはどのように使い分けるのが賢いんでしょうか。
542:デフォルトの名無しさん
08/05/22 22:48:06
同じテンプレートを同じ型で別の場所でインスタンス化した場合はリンカが重複を除去する場合が多い
なので、規模が大きくなるほどテンプレートのオーバーヘッドの割合は減少すると思う
MFCとSTLでは重複するのはコンテナくらい
コンテナはSTLの方が大分出来が良いので、基本的にコンテナはSTLのを使えば良いと思う
MFCにべったり近い処理をするときなどは専用のコンテナが使いやすいこともあるかもしれない
結局はケースバイケースかな
543:デフォルトの名無しさん
08/05/22 23:08:54
＞リンカが重複を除去する場合が多い
重複除去は仕様。必ず行われる。
544:デフォルトの名無しさん
08/05/22 23:22:41
重複除去しないとstatic変数のユニーク性が保証されなくなる。
545:デフォルトの名無しさん
08/05/23 06:04:20
>>541
例えば CODE セグメントとか .text セクションが 10 倍になって困るのか？
一割り増しでも困るなら、使うのをやめというたほうがいいだろう。
なんというか、なんでもいいから毎月雑誌読もう。二年もするとだいぶ変わる。
546:デフォルトの名無しさん
08/05/23 07:27:13
コピペ思い出した
547:デフォルトの名無しさん
08/05/23 12:17:37
boostで重いやつ（regex、spiritなど）を多用するとメモリ不足になる（VC++なら/Zm指定要求してくる）
さらに酷いとコンパイラやリンカが落ちる。
STLレベルならそこまでのことにはならないが、テンプレートの副作用だな。
548:デフォルトの名無しさん
08/05/23 12:21:04
lambdaなんか使うとtypoが原因でコンパイラが落ちるからなｗ
549:デフォルトの名無しさん
08/05/23 23:25:01
それはメモリ不足とは別。
550:デフォルトの名無しさん
08/05/24 09:26:13
vectorって単なる動的配列として使ってもOKですか？
たとえば、こんな風にバッファとして直接vectorに値を書き込むのはvectorの使い方として適切？
std::vector<char> TestV;
TestV.resize(MAX_PATH);
::GetCurrentDirectory(TestV.size(),&(TestV[0]));
std::cout<<&(TestV[0])<<"\n";
551:デフォルトの名無しさん
08/05/24 09:27:32
なぜstringを使わない？
552:デフォルトの名無しさん
08/05/24 09:43:05
>>550
vectorの内部バッファの連続性は規格で保証されているのでok
>>551
現時点ではstringの内部バッファの連続性は保証されてなかった気がする。
553:デフォルトの名無しさん
08/05/24 09:44:54
別に連続性云々じゃなくて……
まあいいや。
554:デフォルトの名無しさん
08/05/24 09:54:28
文字配列でない配列にstringを使う方が頭おかしいだろ
そんなコードさわりたくねえ
555:デフォルトの名無しさん
08/05/24 09:57:50
vector<char>って書いて有るじゃん
556:デフォルトの名無しさん
08/05/24 10:24:53
std::string str=string(&(TestV[0]));
std::cout<<str<<std::endl;
とでも書かないと満足できない人なんだよ、きっと。
557:デフォルトの名無しさん
08/05/24 17:11:20
>>553
「まぁいい」って、>>551を書いた根拠がまさにそれで、
立場が無くなって言葉濁してるだけでしょ？ｗ
558:デフォルトの名無しさん
08/05/24 18:17:31
も前らおちつくんだ
559:デフォルトの名無しさん
08/05/24 18:31:26
&(TestV[0])でポインタ得るのはどうよ
560:デフォルトの名無しさん
08/05/24 18:39:25
&TestV[0]
561:デフォルトの名無しさん
08/05/24 20:31:27
&*TestV.begin() ならマジックナンバーが現れなくていい
とか言いたいのかな
562:デフォルトの名無しさん
08/05/24 21:31:08
vector::data()はまだ規格に入ってないんだっけ?
563:デフォルトの名無しさん
08/05/24 22:13:29
>>562
C++0x
564:デフォルトの名無しさん
08/05/25 23:33:58
自分用のライブラリで、
2箇所でSTLを取り入れただけで、.libのファイルサイズが3倍になったんだけど
テンプレート導入でサイズ急膨張って常識なんすか？
565:デフォルトの名無しさん
08/05/26 00:08:32
:テンプレートは結局、自動的にコードを生成する機能といえるのでうまく使わないと予想外にコードが大きくなる。
566:デフォルトの名無しさん
08/05/26 00:27:48
STLを使うとコードが10倍に？
567:デフォルトの名無しさん
08/05/26 00:28:44
>>564
デバッグ情報じゃねーの？
568:デフォルトの名無しさん
08/05/26 02:42:07
元のライブラリが10KByteで30KByteになったとかだったら驚かない。
3MByteが9MByteになったとかだったら、なにやったんだよと思う。
569:デフォルトの名無しさん
08/05/26 02:46:15
シンボル情報削れば大したことにならんと思うが
570:デフォルトの名無しさん
08/05/26 10:31:54
OSもコンパイラもそれらのバージョンも言わずに３倍とな！？
571:デフォルトの名無しさん
08/05/26 12:38:03
コンパイラはg++です
572:デフォルトの名無しさん
08/05/26 12:50:12
VC++でexpressive入れた途端に未最適化コードとmapファイルが1MB増えた覚えはある
573:デフォルトの名無しさん
08/05/27 21:44:52
>>561
そこは &TestV.front() だろ・・・常考。
574:デフォルトの名無しさん
08/05/28 02:04:01
STLスレだけにテンプレ通りの話をしてるのですね
575:デフォルトの名無しさん
08/05/28 22:48:49
template<class T>
class ListEx
{
list<T> m_list;
list<T>::iterator m_itr;
};
iterator の行でエラーになります。
何がいけないのでしょうか？
576:デフォルトの名無しさん
08/05/28 22:52:47
typename list<T>::iterator m_iter;
577:デフォルトの名無しさん
08/05/28 22:57:16
>>576
ありがとうございます
エラーは出なくなりました。
でも、 typename がなぜ必要なのかわかりません。
どこを調べたらいいのでしょうか？
578:デフォルトの名無しさん
08/05/28 23:14:34
>>577
一度、Effective STLを読んでおいた方がいいんじゃないか？
579:デフォルトの名無しさん
08/05/28 23:20:22
>>577
URLﾘﾝｸ(www.google.com)
580:デフォルトの名無しさん
08/05/28 23:22:34
型なのかメンバ変数なのかハッキリしろコラァ！
とコンパイラが怒るから
581:デフォルトの名無しさん
08/05/29 10:23:16
この文脈では list<T>::iterator のTは型に決まってるだろ、と小1時間ほど問い詰めてやりたい
582:デフォルトの名無しさん
08/05/29 10:31:12
Tじゃなくて、iteratorが型かどうかわからない。
583:デフォルトの名無しさん
08/05/29 11:24:32
template<typename T> struct list{ enum{ iterator = 0 }; };
だったらlist<T>::iteratorをする時にはtypenameの代わりに何が必要なのか
584:デフォルトの名無しさん
08/05/29 12:45:15
>>583
何もいらない。
typenameがないときは、暗黙のうちに値として扱われるよ。例外もあるけど。
585:デフォルトの名無しさん
08/05/29 12:50:33
>>581
実際VC++だとtypename無くても通るっぽい？
賢いというよりテンプレート宣言を読むときは「あーはいはい」って感じで
実際に型当てはめてからチェック開始してるのかね
586:デフォルトの名無しさん
08/05/29 19:36:19
>>582
なるほど、
typename list<T>::iterator m_iter;
は list<T>::iterator がタイプ名だとコンパイラに教えているのか
やっと納得できた
587:デフォルトの名無しさん
08/05/30 01:04:10
C++続けるつもりなら読むべきものをまず読んどけ
588:デフォルトの名無しさん
08/05/30 02:06:07
SICPですね、わかります
589:デフォルトの名無しさん
08/05/30 02:43:43
SICPとはまた時代遅れの物を
590:デフォルトの名無しさん
08/05/30 22:33:28
TR1のお勧め参考書おしえてくれ
591:デフォルトの名無しさん
08/05/30 22:40:10
>>590
つTechnical Report 1
592:デフォルトの名無しさん
08/05/31 01:30:22
ちょっと質問です。
ＳＴＬ辺りに「テーブルクラス」なんてありますか？
イメージとしては、データベースのテーブルをオブジェクトとして扱うクラスです。
result = DBDATA.summary(var1) ;
こんな感じです。
593:デフォルトの名無しさん
08/05/31 02:36:59
>>590
EffectiveC++の第三版はtr1にちょっと触れてる
594:デフォルトの名無しさん
08/05/31 07:56:28
>>592
イメージとしては、データベースのテーブルをオブジェクトとして扱う
クラスはない感じです。
595:デフォルトの名無しさん
08/05/31 12:12:08
>>592
STLだけでやるなら、連想系コンテナとアルゴリズムを組み合わせる感じかね。
596:デフォルトの名無しさん
08/05/31 12:19:01
>>590
とりあえずboost本買ってみるのは
597:デフォルトの名無しさん
08/05/31 14:49:33
>>592
where句が限定されているならmapでいいんじゃないの？
っていうかDB的に使うなら普通にsqliteでも使った方が無難だよ。
598:デフォルトの名無しさん
08/05/31 15:20:14
O/Rマッパーが欲しいんじゃね
DataSetとか
599:デフォルトの名無しさん
08/06/03 22:37:03
mapは、要素の追加または削除を行ってもそれ以外の要素の参照は保たれたままな事が保証されていますか？
600:デフォルトの名無しさん
08/06/03 22:38:01
追記です。要素への参照の他に、キーのについても同じ事が言えますか？
601:デフォルトの名無しさん
08/06/03 22:40:26
自己解決しました。ありがとうございました。
602:デフォルトの名無しさん
08/06/03 23:09:11
死ね
603:デフォルトの名無しさん
08/06/03 23:43:37
死ねっていう奴と
死ねって言われた奴は
死ねばいいのに
604:デフォルトの名無しさん
08/06/03 23:59:17
そして伝説へ･･･
605:デフォルトの名無しさん
08/06/04 00:06:56
死んでもそれ以外の人の参照は保たれたままな事が保証されていますか？
606:デフォルトの名無しさん
08/06/04 01:00:47
死して屍拾う者なし、ってメモリリークのことですか？
607:デフォルトの名無しさん
08/06/04 08:44:19
GC「骨くらいは拾っておいてやるよ」
608:デフォルトの名無しさん
08/06/04 08:45:30
デストラクタ「生ける者の為の卒塔婆」
609:デフォルトの名無しさん
08/06/04 13:11:39
std::mapのイテレータに順ずるものから、木構造の右部分木、左部分木をそれぞれ取得して
木を追跡したいんですが、そういうことは可能でしょうか？
610:デフォルトの名無しさん
08/06/04 13:13:10
赤黒木使ってたら左部分木と右部分木だけとは限らないよ
アルゴリズムの本読んでみ
611:デフォルトの名無しさん
08/06/04 13:17:24
>>609
std::map が木で実装されているとは限らないので、そういう操作は無い。
木の追跡（？）自体がやりたいわけじゃないと思うんだけど、結局のところ何がしたいの？
612:デフォルトの名無しさん
08/06/04 13:26:33
>>611
upper/lower_boundで解決しました。
613:デフォルトの名無しさん
08/06/04 13:36:39
やっぱり解決しませんでした。もういいです諦めます。STL死ね。
614:デフォルトの名無しさん
08/06/04 13:41:17
お前が死ね
615:デフォルトの名無しさん
08/06/04 14:21:17
すぐファビョる所を見ると朝鮮人か
616:デフォルトの名無しさん
08/06/04 14:23:03
私が死ぬのであなた達は死ななくてもよいのです
617:デフォルトの名無しさん
08/06/04 15:05:12
STLは生き物ではないので死ぬことはできません
618:デフォルトの名無しさん
08/06/04 15:18:03
私のお墓の前で泣かないでください
619:デフォルトの名無しさん
08/06/04 15:46:50
STLの考え方に頭が付いていかない所を見ると
頭が悪いかジジイかのどちらかだろう
620:デフォルトの名無しさん
08/06/04 16:07:29
お尋ねします。
vector<vector<bool>> TempA;
vector<vector<bool>>::iterator itr1;
vector<vector<bool>>::iterator itr2;
と宣言したとします。
itr1 = TempA.begin();
itr2 = TempA.begin();
としたのち、
TempAのたとえば2行目と3行目の中身すべてを比較したいとき、
itr1++;itr2 += 2;としてiteratorを進めて、
*itr1 == *itr2の比較を一度行えばいいのでしょうか？
それとも、各行でiteratorを作成して、
各行ベクトルの列座標に対応したiteratorを回す必要がありますか？
p.s.この動作のあと、一致している行を、
itr2=Temp.erase(itr2);
みたいに削除したいのです。
621:デフォルトの名無しさん
08/06/04 16:34:38
>>620
要するに二つのvectorを==で比較できるかってことだよな
できるよ
622:デフォルトの名無しさん
08/06/04 16:46:22
>>621
ありがとうございます。
行に対応するvectorの各要素の比較という認識で大丈夫でしょうか。
623:デフォルトの名無しさん
08/06/04 18:17:13
そう。要素ごとに==で比較してる
624:デフォルトの名無しさん
08/06/04 18:19:40
>>622
23.1 Container requirements に
a == b は a.size() == b.size() && equal(a.begin(), a.end(), b.begin())
と等価と書いてある。
625:デフォルトの名無しさん
08/06/04 22:12:31
>613
map使わずにソート済vector使えばいいんじゃね？
626:620
08/06/05 10:43:24
>>623
亀レス申し訳ない。
ありがとうございました。
そういう情報ってどのヘッダーを見ればいいんでしょうか？
vector.hを眺めていてもさっぱりです…。
627:デフォルトの名無しさん
08/06/05 11:34:56
>>626
ヘッダーには書いてないだろう･･･
お使いのコンパイラのリファレンスマニュアル等を読め
VCならこのへん↓
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx
628:デフォルトの名無しさん
08/06/05 13:25:16
>>626
C++の規格書一回読んでみるのもいい。
629:デフォルトの名無しさん
08/06/05 20:20:37
vectorかその内部でincludeしてるファイルに書いてあるんじゃね。実装が。
630:デフォルトの名無しさん
08/06/06 10:17:16
イテレータを返すbegin, endが、どうして戻り値の型が違うだけで（iterator, const_iterator）オーバーロードされた関数を特定できるのかが分かりません。
自分で同じ様な事をしようとしてもSTLとは違いコンパイラが関数を特定できずに失敗します。
631:デフォルトの名無しさん
08/06/06 10:22:06
>>630
戻り値の型じゃなくて、引数リストの後ろの const の有無が違う。
632:デフォルトの名無しさん
08/06/06 10:36:05
>>631
それは実装側のbegin, endの定義ですよね？
自分で作ったものもconst_iteratorを返すものは引数リストの後にconstをつけているんですが、
これは利用する側が呼び出すときには特に関係ない様です。
まさか container_type::const_iterator it = ((container_type::const_iterator (container_type::*)()const)container.begin)();
なんてしなきゃいけないんですか？
633:デフォルトの名無しさん
08/06/06 11:24:47
iteratorからconst_iteratorへの変換はできるようになってる?
634:デフォルトの名無しさん
08/06/06 11:27:59
変換できるようにしたら const_iterator begin() const の必要性なくならないか？
635:デフォルトの名無しさん
08/06/06 11:31:44
なんで?
constなインスタンスに対してイテレータ取得できなくなっちゃうじゃん
636:デフォルトの名無しさん
08/06/06 12:59:04
VC7
template<class _Ty,class _Alloc>
class _Vector_iterator : public _Vector_const_iterator<_Ty, _Alloc>
637:デフォルトの名無しさん
08/06/06 19:44:07
>>636
補足しとくと、iteratorは基底クラスであるconst_iteratorに変換できるといいたいだけ。
constなしbegin()の戻り値はiteratorだからconst_iteratorにも変換されうる。
begin()の戻り値を渡す先がconst_iteratorかiteratorかで、
begin()の種類（後ろにconst付きか否か）が選択されているわけじゃない。
638:デフォルトの名無しさん
08/06/06 22:14:29
>>632
MyContainer c = ...
MyContainer const& cc = ...
MyContainer::const_iterator = c.begin();
MyContainer::const_iterator = cc.begin();
これをトレースするといいよ。