05/11/25 09:58:43
>>310
iostream・fstreamはファイルサイズが無駄に大きくなる。
ちょっとしたコンソールアプリには、iostreamは大げさすぎる実装だ。
313:デフォルトの名無しさん
05/11/25 10:31:01
今時数十KB増えるくらい蚊に刺されたようなもんじゃん。
314:デフォルトの名無しさん
05/11/25 10:55:12
>>312
それなら C 使えば？
315:デフォルトの名無しさん
05/11/25 12:38:37
また莫迦が STL ｽﾚで stream の話してるよ…
316:デフォルトの名無しさん
05/11/25 12:45:01
>>315
過去ログと空気は読む物ってことだわな
317:デフォルトの名無しさん
05/11/25 12:55:52
まぁSTLという言葉の定義に持ち込む>>315のほうが馬鹿だけどね。
318:デフォルトの名無しさん
05/11/25 13:07:39
>>307-308
便乗で申し訳ないが、basic_ostream< wchar_t > への対応版も希望
319:デフォルトの名無しさん
05/11/26 10:46:08
URLﾘﾝｸ(dl.njfiw.gov.cn)
320:315
05/11/29 16:18:06
>>316-317
初代ｽﾚから居るが。
時々思い出したように粘着しているだけだ。
321:デフォルトの名無しさん
05/11/29 19:07:08
>>320
？ お前はまさにそこをイジられてるんだが、何をわざわざ説明してるんだ？
322:デフォルトの名無しさん
05/11/29 22:18:12
>>318
亀レスだが、コンストラクタを変換関数の代わりに使っているので、
OutBin(wchar_t)と、intとwchar_tを受け取った場合のフラグでも
増設して、operator<<の動作を切り替えればいいやん。
323:デフォルトの名無しさん
05/11/30 19:03:24
vector とかよりももっと複雑な、
一般のグラフ構造のリンク関係を持ったアイテム集合を
うまく扱うためのコンテナクラスライブラリってありませんか？
324:デフォルトの名無しさん
05/11/30 19:03:55
コンテナクラスライブラリってあんまり使わないみたいなんで
テンプレートクラスライブラリって言い換えます。
325:デフォルトの名無しさん
05/11/30 19:09:37
クラステンプレートであってテンプレートクラスではない。
STLには存在しないがboost::graphというものは存在する。
326:デフォルトの名無しさん
05/11/30 21:57:09
質問です。
以下のテンプレートクラスのstd::map<KEY, VAL>::iterator
の部分でコンパイルエラーが発生します。
コンパイルを通す方法ありますか？
環境： g++ 3.4.2
template<typename KEY, typename VAL>
class MyMap : public std::map<KEY, VAL>
{
public:
MyMap()
{
std::map<KEY, VAL>::iterator it = begin();
}
};
327:デフォルトの名無しさん
05/11/30 22:00:53
>>326
typename std::map<KEY, VAL>::iterator...
328:デフォルトの名無しさん
05/11/30 22:09:59
>>327
ありがとうございます。
どうしてtypenameをつけるとコンパイル通るんですか？
329:デフォルトの名無しさん
05/11/30 22:20:14
>>328
URLﾘﾝｸ(www.fides.dti.ne.jp)
330:デフォルトの名無しさん
05/11/30 23:11:44
>>329
停滞してるな
331:デフォルトの名無しさん
05/11/30 23:12:31
逃した魚は大きいぞ
332:デフォルトの名無しさん
05/11/30 23:59:56
>329
そこを読んで思ったんだが、
typedefの時にtypenameを書かないと通らないコンパイラってあるの？
typedefの引数？は型名に決まっているんだから必要ないように思えるだが。
333:デフォルトの名無しさん
05/12/01 00:14:14
>>332
そうやって勝手に標準規格をねじ曲げたのがVC7.1だろう。
VC7.1だけ使ってると、typenameが必要だって事が学習しにくい。
334:デフォルトの名無しさん
05/12/02 01:38:49
7.1はわりとtypenameについて忠実じゃなかったっけ？
6が酷かったのは覚えているが。
335:デフォルトの名無しさん
05/12/02 02:07:50
いや全然
336:デフォルトの名無しさん
05/12/02 02:12:05
そうか気のせいだったか。
337:デフォルトの名無しさん
05/12/04 20:17:12
>>333
typenameなんていらないじゃん。未熟なコンパイラを救うためだけのもんだろ。
338:デフォルトの名無しさん
05/12/04 20:21:40
>>337
typename は未熟な C++ 言語仕様を救うためのもんだよ。
コンパイラベンダがどうこうするもんじゃない。
339:デフォルトの名無しさん
05/12/04 20:30:15
即ち禿がC++に毛を生やす努力をすればtypenameはいらない。
340:デフォルトの名無しさん
05/12/04 22:16:07
お前らいつもいつも禿禿って…いい加減にしろよ？
341:デフォルトの名無しさん
05/12/04 22:42:49
あ、びょーん先生こんにちは。
今日も落ち武者ヘアー似合ってますよ。
342:デフォルトの名無しさん
05/12/05 22:45:19
vectorの安全性に関する質問です。
先頭要素のポインタを取得して、それを進めた場合
正しいアドレスを指す保障はありますか？
int *p;
std::vector<int> ivec;
ivec.push_back(100);
ivec.push_back(200);
ivec.push_back(300);
p = &ivec[0];
p++;
p++;
printf("%d", p);
一応これの出力は300と出ます。
343:デフォルトの名無しさん
05/12/05 22:53:11
>>342
vector<bool> 以外はある。
23.2.4-1
The Elements of a vector are stored contiguously, meaning
that if v is a vector<T, Allocator> where T is some type
other than bool, then it obeys the identity
&v[n] == &v[0] + n for all 0 <= n < v.size().
344:デフォルトの名無しさん
05/12/05 22:55:11
事前条件として !ivec.empty() に注意ね
345:デフォルトの名無しさん
05/12/07 19:20:03
Boostを使わずにSTLのみで、スマートにcsvファイルを読み込めたりする？
346:デフォルトの名無しさん
05/12/07 19:27:03
>>345
RFC4180を見る限り、スマートにってのは無理みたいだね。
347:デフォルトの名無しさん
05/12/07 19:33:15
>>346 そんな RFC があったのか・・・
348:デフォルトの名無しさん
05/12/07 20:00:03
たしか超最近出来たRFCだろそれ
349:デフォルトの名無しさん
05/12/07 20:56:06
>>346
そんなのあったのか
つかC/C++でCSVファイルを読むのはクソだるいんだよな
書くのは楽なんだが。
350:デフォルトの名無しさん
05/12/07 21:18:00
Java だと楽なの？CSVファイル読むの。
いや、俺、Javaほとんど使ったことないから。
351:デフォルトの名無しさん
05/12/07 21:43:47
CSVつってもExcel仕様のCSVとか色々あるんじゃないの。
引用符の処理や複数行のセルとかどうすんだとか。
352:346
05/12/07 22:26:19
>>347-349
今年10月にできてる
353:デフォルトの名無しさん
05/12/08 00:43:10
URLﾘﾝｸ(www005.upp.so-net.ne.jp)
ここの雛形を使ってイテレータを作ってみようと思ったんですが、
'iterator' : 定義されていない基本クラスが宣言されています
となってしまいます。
#include <iterator>
の他にする事があるんでしょうか？
354:デフォルトの名無しさん
05/12/08 00:57:48
名前空間じゃね?
355:デフォルトの名無しさん
05/12/08 01:06:30
>>354
using namespace std;
または
std::iterator
としたらすんなり通りました。
ありがとうございました。
356:デフォルトの名無しさん
05/12/08 01:18:01
RFCってのは4月にチェックするものだと言うすり込みがあるのでしらんかった。
357:デフォルトの名無しさん
05/12/08 01:23:57
さすがにそれはどうかとｗ
確かに俺も毎年4月は確認するけどさｗｗｗ
358:デフォルトの名無しさん
05/12/08 01:51:41
>>350
Javaは標準ライブラリに、StringTokenizer があるから、
少なくとも、C++標準だけでやるよりは楽。
359:デフォルトの名無しさん
05/12/08 01:53:16
>>358
StringTokenizerはCSVのパーシングにおいては何の役にも立たないと思うぞ
360:デフォルトの名無しさん
05/12/08 01:55:19
そうなの？
まぁ、でもRegexあるけど。
361:デフォルトの名無しさん
05/12/08 01:56:38
>>360
人に聞く前に>>346にせっかく挙がってるRFC嫁よ
362:デフォルトの名無しさん
05/12/08 02:25:12
a","b""bb","ccc CRLF
ﾋﾄﾞｽ
でもBNFがあったのですぐ解った
363:デフォルトの名無しさん
05/12/08 06:39:02
CSVが難しいのは、ハウス規格がたくさんあるからで、
>>358>>359>>360の言っているような問題じゃない。
>>362
Shift_JISだと、あのBNFじゃ駄目だけどね。
364:デフォルトの名無しさん
05/12/08 11:47:10
あー、RFCだから仕方ないけどCrLf限定になってるし2バイト文字が通らない。
これもまた実態に合わないのか。
365:デフォルトの名無しさん
05/12/08 12:02:30
Category: Informational
366:デフォルトの名無しさん
05/12/08 13:55:59
CSVなんかはPerlで読んじゃうな
前処理させとくだけでもずいぶん楽だし
367:デフォルトの名無しさん
05/12/08 20:25:06
>>366
正しいと思う。
CSVファイル読込が全体に占める消費時間は微々たる物になるケースがほとんどだし。
368:デフォルトの名無しさん
05/12/09 04:06:12
RFC 書いた人、実体分かって書いてるのかな。
369:デフォルトの名無しさん
05/12/09 12:23:24
Boost.Spirit フレームワークで、簡単お手軽CSVパーサを作れば
かなりイイ感じだが、>>345 は、「Boost を使わず」といってるし…
370:デフォルトの名無しさん
05/12/09 12:56:16
>>364
詳細きぼん。
マルチバイト文字に関しては
> Common usage of CSV is US-ASCII, but other character sets defined
> by IANA for the "text" tree may be used in conjunction with the
> "charset" parameter.
ってあるし、改行に関しても
> As per section 4.1.1. of RFC 2046 [3], this media type uses CRLF
> to denote line breaks. However, implementors should be aware that
> some implementations may use other values.
とある。別に制限するものではないと思うけど。
371:デフォルトの名無しさん
05/12/09 13:42:54
>>370
> 別に制限するものではないと思うけど。
このメディアタイプではCR LFのみだよ。
曖昧にしたら駄目じゃん。いまさらRFCにする意味が半減。
ローカルシステムはCRのみやLFのみかもしれないから、
実装する奴は気をつけろって事。
世間では色々乱れてるから、このメディアタイプ定義で
(インターネット上での)データ交換の規準ができた。
372:デフォルトの名無しさん
05/12/09 13:45:12
↓これね。
4.1.1. 行分断（改行）の表現
MIME"text"サウブタイプの正式書式は、必ずCRLF列（連続体）として行分断を
表現しなければなりません。同じ様にMIME"text"でのCRLFの出現は如何なるも
のでも行分断を表現します。行分断以外でのCRとLFの使用も禁じられています。
この規則は、書式もしくは文字セットもしくは含まれている設定に関わらず、
適用されます。
URLﾘﾝｸ(www.asahi-net.or.jp)
373:デフォルトの名無しさん
05/12/14 11:18:38
ポインタのlistのsortの仕方が分からないよ！
class MyClass {
int value;
bool operator<(const MyClass& o) {
return value < o.value;
}
};
template<class T>
class ptr_less
{
public:
inline bool operator()(T left, T right)
{ return (*left) < (*right); }
};
int main() {
std::list<MyClass *> mylist;
// 色々と要素挿入（省略）
std::sort(mylist.begin(), mylist.end(), ptr_less<MyClass *>());
}
エラーが一杯出る…
374:デフォルトの名無しさん
05/12/14 11:31:29
mylist.sort()
list に std::sort は使えないんじゃ
375:デフォルトの名無しさん
05/12/14 11:34:55
>>373
list.sort();
376:デフォルトの名無しさん
05/12/14 11:37:23
>>373
もうちと付け足す。std::sort()は、random access iteratorを要求している。
しかし、std::list::iteratorは、bidirectional iterator なので、コンパイルが
通らない。
それでは使い勝手が悪いので、std::list::sort()が用意されている。こちらは
マージソートが歴史的な理由から採用されており、bidirectional iterator
でも動くようになっている。
377:373
05/12/14 12:38:31
どうもありがとう！
でも、mylist.sort(ptr_less<MyClass *>());とやると、
error C2664: 'void __thiscall std::list<class MyClass *,class std::allocator
<class MyClass *> >::sort(struct std::greater<class MyClass *>)'
: 1 番目の引数を 'class ptr_less<class MyClass *>' から 'struct std::greater
<class MyClass *>' に変換できません。 (新しい機能 ; ﾍﾙﾌﾟを参照)
ｺﾝｽﾄﾗｸﾀはｿｰｽ型を持てません、またはｺﾝｽﾄﾗｸﾀのｵｰﾊﾞｰﾛｰﾄﾞ ﾚｿﾞﾘｭｰｼｮﾝがあいまいです。
というお叱りが。std::greaterしか受け付けない？
URLﾘﾝｸ(rararahp.cool.ne.jp)
ここのページによると原因はVC6だかららしい。
ついでに解決策を参考にして、何とかソート出来た！
378:デフォルトの名無しさん
05/12/14 14:06:07
>>376
ついでに補足しておく。
C++標準において、「std::list<>::sort()がStableソートであり、等価な要素の
相対的な位置関係が保たれること」が、保証されている。
で、歴史的な理由により、ほぼ全ての実装でマージソートが採用されている。
(が、その保証はない)
379:デフォルトの名無しさん
05/12/14 19:51:00
επιστημη ←こいつ調子に乗ってるな
何様だよ
380:デフォルトの名無しさん
05/12/14 19:55:23
こんなところで吠えてないで本人に直接言えよ
381:デフォルトの名無しさん
05/12/14 21:58:36
標準化メンバーの1人だっけ?
382:デフォルトの名無しさん
05/12/14 23:28:12
そだよ、標準ライブラリの一部も彼を含めた日本の標準化委員会の案
383:デフォルトの名無しさん
05/12/14 23:53:13
>>379
過疎スレにいってらっしゃい。
επιστημηってウザくね？
ｽﾚﾘﾝｸ(tech板)
384:デフォルトの名無しさん
05/12/15 23:21:33
ハーバート・シルトのSTL標準講座という本でSTLの勉強をしていたのですが
どうしてもわからないものにぶち当たってしましたました。
下記のソースのなかで
p = find_if(v.begin(), v.end(), iscomma);
とありますがこの中のiscommaが何も実引数を持たずに呼び出されています。
これってどういうことなのでしょうか？
もしお時間のある方いらっしゃいましたらご教授お願いいたします。
･･･････････････････････････・・・・・・・・・・・・・・・・
// find()とfind_if()の用例
#include <iostream>
#include <vector>
#include <algorithm>
#include <cstring>
using namespace std;
// chがカンマならtrueを返す
bool iscomma(char ch) {
if(ch==',') return true;
return false;
}
int main() {
vector<char> v;
vector<char>::iterator p;
char str[] = "One, Two, Three";
int i;
for(i=0; i<strlen(str); i++) v.push_back(str[i]);
p = find_if(v.begin(), v.end(), iscomma);
cout << "After find first comma: ";
while(p != v.end()) cout << *p++;
cout << endl;
return 0;
}
385:デフォルトの名無しさん
05/12/15 23:25:25
そこで呼び出されてるわけじゃない。
関数のアドレスを渡してるだけ。
386:デフォルトの名無しさん
05/12/15 23:26:58
>>384
そもそも呼び出されてすらないし。find_ifに関数渡してるだけでしょ。
find_ifの中の人がiteratorを実引数にしてiscommaを呼び出すってだけの話。
387:デフォルトの名無しさん
05/12/15 23:27:40
Oppsかぶったかぶった。
388:デフォルトの名無しさん
05/12/15 23:51:56
>>385-386
ものすごく納得いきました。ありがとうございます。
389:デフォルトの名無しさん
05/12/16 02:58:10
>>388 は qsort とか使ったことなかったのかな・・
390:デフォルトの名無しさん
05/12/16 06:00:51
皆が皆CからC++へ行くわけじゃないからね。
391:デフォルトの名無しさん
05/12/16 06:34:27
qsortはCの関数だがな
392:デフォルトの名無しさん
05/12/16 07:00:16
話がかみ合ってない悪寒
393:デフォルトの名無しさん
05/12/16 08:10:52
>>385
> 関数のアドレスを渡してるだけ。
関数オブジェクトを渡しています。
394:デフォルトの名無しさん
05/12/16 08:12:50
>>393
馬鹿ですか？関数と関数オブジェクトの見分け方ぐらい
付けられるようになっとけ。
395:デフォルトの名無しさん
05/12/16 11:09:08
>>387
オップス?
もしかして：Oops!
396:デフォルトの名無しさん
05/12/16 14:31:25
↓>>393の必死な言い訳
397:デフォルトの名無しさん
05/12/16 16:22:37
関数⊂関数オブジェクト
398:デフォルトの名無しさん
05/12/16 16:25:37
もう少しこう、うっかり騙されそうなネタで頼む
399:デフォルトの名無しさん
05/12/16 16:43:58
↓素直に自分の無能を認める>>393
400:デフォルトの名無しさん
05/12/16 17:07:28
俺が悪かった
401:デフォルトの名無しさん
05/12/16 17:12:16
いや俺のほうが悪い
402:デフォルトの名無しさん
05/12/16 17:51:26
私のために争わないで！
403:デフォルトの名無しさん
05/12/16 18:21:45
もうこれ以上
404:デフォルトの名無しさん
05/12/16 18:55:58
君のまわりに不幸の存在を俺は認めない
405:デフォルトの名無しさん
05/12/16 20:07:19
>>389
10月中旬ごろ標準Cの勉強を始めて
11月下旬に標準C++へ、MFCを使って電卓を作って、WinSockでechoサーバをみようみマネでつくり
昨日、初めてSTLの勉強を始めて・・・何故か本の真ん中からはじめたので右も左もわからず・・・・
って感じです。今までネットワークエンジニアとして修行していたのでプログラミングは、つぅあっパリですｗ
406:デフォルトの名無しさん
05/12/16 23:47:13
最初から読もうぜ。結構なんとかなってしまうけど、基本も大事だしね。
407:デフォルトの名無しさん
05/12/17 00:43:22
>>406
STLにも勉強する順番があるんですか？
408:デフォルトの名無しさん
05/12/17 00:55:26
>>407
私は>>406ではありませんが。勉強に順序はありません。でも、
一般的にはstd::vector<>が最初に紹介されていませんかね？
409:デフォルトの名無しさん
05/12/17 00:59:32
>>407
俺は>>406じゃないけど、STLを基本概念から全部理解しようと
したら大変だぜ。本が何冊も出ている。
よく使うコンテナやアルゴリズム、関数オブジェクトの使い方あたり
から少しずつ入って行けば楽なのではないかと思う。
410:デフォルトの名無しさん
05/12/17 01:22:06
vector → list → iterator → algorithm → functional → その他
くらいでいいんじゃね？
411:デフォルトの名無しさん
05/12/17 02:25:01
>>410
ご教授、ありがとうございます。
時間があればそのようなことをしたいと思います。
412:デフォルトの名無しさん
05/12/17 02:36:29
>>411
vector→list→map→algorithm→functional→[boost]
413:デフォルトの名無しさん
05/12/17 03:26:07
最初からLoki
414:デフォルトの名無しさん
05/12/17 03:48:00
>>412
はいはい。じゃーそれで
415:デフォルトの名無しさん
05/12/17 07:17:05
Vector → 窓の杜
416:デフォルトの名無しさん
05/12/17 09:35:09
Vector→Quaternion→Matrix
417:デフォルトの名無しさん
05/12/17 10:16:04
テンソルは？
418:デフォルトの名無しさん
05/12/17 10:41:51
>>414
わかればよろしい。
419:デフォルトの名無しさん
05/12/17 10:54:53
Scalar → Vector → Tensor
はいはい、テンソルテンソル。
420:デフォルトの名無しさん
05/12/17 11:04:45
>>419 わかればよろしい
421:デフォルトの名無しさん
05/12/17 11:08:09
>>419
わかればよろしい。
422:デフォルトの名無しさん
05/12/17 11:10:04
はいはい、すごいね、テンソルテンソル
423:デフォルトの名無しさん
05/12/17 12:19:52
>>410
> vector → list → iterator → algorithm → functional → その他
>>412
> vector→list→map→algorithm→functional→[boost]
俺は最初からiterator、algorithm、functionalを軽くやるスタイルが良いと思う。
ステファノフさんのオリジナルSTL本はこの流儀。
そういう意味ではvectorはC的な操作への誘惑が強く、
mapやsetが最初のコンテナとして適当ではないかと。
424:デフォルトの名無しさん
05/12/17 13:02:54
私は実務で使いながらだったから
vector → iterator → algorithm
の順に入ったな。
Cの経験が充分あるなら、取り敢えず可変長配列としてのvectorを見てから
それを一通り使い倒して他にいくと言う意味で悪くないと思う。
#例えばvectorのoperator[]に馴れてそこで留まる香具師にはどうせalgorithmなんて使いこなせないわけだし。
425:デフォルトの名無しさん
05/12/17 13:54:13
>>424
そえは業務でalgorithmを使っていないって事ですか？
426:デフォルトの名無しさん
05/12/17 14:02:05
ヘタレがvector使うとバグの温床になる
listとか使った方がまだまし
427:デフォルトの名無しさん
05/12/17 14:14:24
>>426
なんで？逆じゃないの？
428:デフォルトの名無しさん
05/12/17 14:23:39
vectorやstringは、今となっては設計が5年は古いよな。
algorithmを使えば済むものが、内部メソッドになってしまっている。
429:デフォルトの名無しさん
05/12/17 14:31:45
>428
stringはともかくvectorにそれ当てはまる？
430:デフォルトの名無しさん
05/12/17 15:18:02
>>428
あんた、実はあんまりSTLを知らないね。
std::algorithmを適用できないイテレータを持つコンテナに最適な
アルゴリズムを用意したのが、大抵の内部メソッドだ。
それから、std::stringは、STLには大抵入れない。random access iterator
を使えるので、適用できるアルゴリズムが多いのは確かだが、
用途が主に文字列の操作なので、Cのstring.hに対応する関数を
内部で持っただけ。
431:デフォルトの名無しさん
05/12/17 15:36:34
>>430
stringの後半の主張はどうかと思うぞ。
STL以前からあるクラスで、今やオールドタイプだ。
432:デフォルトの名無しさん
05/12/17 15:50:32
std::stringにバイナリを入れられるのは知ってるけど、果たして
std::stringの内部メソッドがそれに適したような格好になってるかな？
433:デフォルトの名無しさん
05/12/17 18:51:43
>>432
何がいいたいかよくわからん。
434:デフォルトの名無しさん
05/12/17 19:23:27
>>432
typedef basic_string<char> string; ですから、charなんなんでもありです。
ただしc_str()は'\0'が途中にあるとまずいですが。
>>430
SGIのSTLにstring入ってるぞ。
435:デフォルトの名無しさん
05/12/17 19:55:23
>>434
＞ただしc_str()は'\0'が途中にあるとまずいですが。
まずくないよ。size()とともに用いればいいだけ。
下のコードでヌル100文字で埋められていることを確認汁。
string str;
str.resize(100);
fwrite(str.c_str(), sizeof(string::value_type), str.size(), fp);
436:デフォルトの名無しさん
05/12/17 20:02:02
>>435
まずくないのには同意だが、そういうとき普通はc_strじゃなくdataを使うだろ。
437:デフォルトの名無しさん
05/12/17 20:15:33
>>436
data()は今の議論のテーマではない。
終端に確実にヌルが付加されるc_str()を使わずdata()を用いる利点など一切ない。
438:デフォルトの名無しさん
05/12/17 20:18:49
>>437
fwriteに渡すのに終端文字がいちいち付加される意味ないのでc_str()なんか使う意味ないだろ
439:デフォルトの名無しさん
05/12/17 20:19:39
何故?
実装によっては、capacity() != size() の時、
c_str()はdata()より重い処理になるよ。
>>435のようにsize()と使うならdata()ってのが定石だと思う。
440:デフォルトの名無しさん
05/12/17 20:20:10
>>439は、>>437へのレス
441:デフォルトの名無しさん
05/12/17 20:26:47
>>438
仕様変更に対する事前策を用意しておくことを無意味とは、大胆発言だな。
ヌル終端文字列を前提とした既存のC関数に渡すとき、
バッファオーバランの可能性を軽減することができる。
この点においてstring::c_str()は、string::data()やstringstream::str()より安全性に優れている。
ヌル終端保証されたc_str()と保証されないdata()。
一方で、c_str()とdata()が同じ挙動をするSTLも存在する。
どちらを使うべきかは一目瞭然だろう。
442:デフォルトの名無しさん
05/12/17 20:28:22
>>439
サンプルとなる、ソースと開発環境を書け。
443:デフォルトの名無しさん
05/12/17 20:32:35
>>441
バイナリデータブロックを扱っているところをnul文字終端に仕様変更する準備をしておくなんて
普通じゃないな
444:デフォルトの名無しさん
05/12/17 20:35:43
>>443
Unicode文字列をバイナリデータとして扱っている場合などはそうでもない。
何をもって普通というのかその人の経験量だろうけど。
445:デフォルトの名無しさん
05/12/17 20:38:55
１．c_str()は'\0'が途中にあるとまずい
２．size()とともに用いればまずくない
３．そういうときはc_strじゃなくdataを使う
４．ヌル終端文字列を前提とした既存のC関数に渡すときc_str()のほうが安全
５．1に戻る
446:デフォルトの名無しさん
05/12/17 20:40:22
>>439の実証コードはまだですか？
>>439の正しさが確認されないことには、
議論が進まないのでなるべく早目にお願いします。
447:デフォルトの名無しさん
05/12/17 20:44:06
>>445
多分、３．は必要ないから、無限ループには陥らない。
448:デフォルトの名無しさん
05/12/17 20:55:04
結論としては、nul終端が必要ない時はdata()を使え。ただし義務ではない。
449:デフォルトの名無しさん
05/12/17 20:59:41
data()を使う合理性が確認できない。という限定された結論しか出ていない。
c_str()に対するdata()のパフォーマンス優位性も一切確認されていない。
全ては信者の脳内にしか存在しない。
450:デフォルトの名無しさん
05/12/17 21:07:02
逆にc_str()の方が安全である実装はあるのか?
俺の知っている実装は全て、data()とc_str()は同じものを返すよ。
data()の時も実は'\0'で終端されているという…
451:デフォルトの名無しさん
05/12/17 21:13:43
>>450
size() == 0の時少し振る舞いが違うぞ。
まあ多くの実装で返ってくるものは同じだが(w
452:デフォルトの名無しさん
05/12/17 21:14:32
c_str()のdata()に対する優位性
・ヌル終端保証
・"c_str"というキーワードが他であまり使われないので、文字列検索が"data"に比べて簡単
data()のc_str()に対する優位性
・不明
453:デフォルトの名無しさん
05/12/17 21:15:15
VC++7.1はdata()がc_str()を呼んで、c_str()が_Myptr()を呼んでるよ。
454:デフォルトの名無しさん
05/12/17 21:17:31
>>441
そこでstringstream::str()を引き合いに出してくる理由がわからない。
455:デフォルトの名無しさん
05/12/17 21:19:15
data()のc_str()に対する優位性
・ソース内にc_str()と混在させることにより難読性を高めて、他のプログラマがコピペしにくくする著作権保護効果。
456:デフォルトの名無しさん
05/12/17 21:23:13
>>454
己の経験不足を報告するスレじゃないはずだぞ。
457:デフォルトの名無しさん
05/12/17 21:32:22
stringstream::str()はstd::stringを返すのだからss.str().c_str()という手段はないのか？
458:デフォルトの名無しさん
05/12/17 21:33:10
>>452
> data()のc_str()に対する優位性
Cスタイルの文字列を必要としている局面でないことが明確。
459:デフォルトの名無しさん
05/12/17 21:44:24
問題があるのは、stringstream::str()じゃなくてstrstream::str()だった。スマソ。
460:デフォルトの名無しさん
05/12/18 00:07:21
STL使うとどうなるの？
461:デフォルトの名無しさん
05/12/18 00:12:32
>>460
一気に実行ファイルサイズが10倍になります。
462:デフォルトの名無しさん
05/12/18 00:14:24
>>460
別世界が開ける。
463:デフォルトの名無しさん
05/12/18 00:48:02
>>461
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。
464:デフォルトの名無しさん
05/12/18 00:57:46
>>461,463
はいはい、他スレのテンプレわろすわろす
465:デフォルトの名無しさん
05/12/18 00:57:49
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
466:デフォルトの名無しさん
05/12/18 01:03:05
懐かしいなｗ
467:not 463
05/12/18 01:03:25
そりゃそうでしょ。
「実行ファイルのサイズが１０倍になる」を受けてるレスだから。
468:デフォルトの名無しさん
05/12/18 01:12:09
URLﾘﾝｸ(www.google.com)
469:デフォルトの名無しさん
05/12/18 01:30:19
>>468
ﾜﾛｽｗｗｗｗｗ
470:デフォルトの名無しさん
05/12/18 01:36:26
懐かしさと共にﾜﾛｽｗｗｗｗ
471:デフォルトの名無しさん
05/12/18 01:45:39
自作自演乙
472:デフォルトの名無しさん
05/12/18 02:03:26
>>471 がどれを自作自演と言いたいのか判らない。
473:デフォルトの名無しさん
05/12/18 05:32:51
だってこのスレに書き込んでるの俺一人しかいないしｗ
474:デフォルトの名無しさん
05/12/18 07:27:07
いつも思うのだが、>>463は正しいことを書いてる。
あの時点で注目されているのはテンプレートのコード生成に伴うサイズ増量であって、
Cランタイムがどのようにリンクされようがテンプレートと何の関係もない。
むしろ動的リンクの方がテンプレートによる増量がわかりやすいかもしれない。
475:デフォルトの名無しさん
05/12/18 07:31:10
i::::::::/'"￣￣ヾi
|:::::::| ,,,,,_ ,,,,,,|
|r-==（ ｡);（ ｡)
( ヽ :::__)..:: }
,＿＿__／ヽ ー== ; ほほう それでそれで？
r'"ヽ t､ ＼＿＿_ !
/ ､､i ヽ＿＿,,/
/ ヽﾉ j , j |ヽ
|⌒`'､__ / / /r |
{ ￣''ｰ-､,,_,ﾍ＾ |
ゝ-,,,＿＿＿＿_）--､j
/ ＼__ /
| "'ｰ‐‐---''
476:デフォルトの名無しさん
05/12/18 07:48:26
std::string使ってないなあ
MBSやsurrogateやらの対応が甘そうだったので自前で作った
477:デフォルトの名無しさん
05/12/18 08:06:26
std::stringから継承するという選択肢は無視かね。
MBS対応メソッドを追加すればすむだけなのに。
478:デフォルトの名無しさん
05/12/18 09:40:48
std::stringから派生するのはやめた方が……。
非仮想デストラクタだし、スライスも怖いし……。
479:デフォルトの名無しさん
05/12/18 10:03:16
>>478
非仮想デストラクタの心配は杞憂。
別のスコープで作られた派生クラスインスタンスを
基底クラスのポインタで破棄すべき状況が、
果たして文字列クラスで起こりうるかどうか考えよう。
ポインタを使いたくないからクラス化しているのに本末転倒な状況だ。
また、STLのコンテナやアルゴリズムがテンプレートを用いており、
継承をあえて使っていない理由についても考えよう。
ところで、「スライス」とは何？
480:デフォルトの名無しさん
05/12/18 11:36:17
>>479
基底クラスへのスライシングだろ。
非仮想デストラクタの場合と心配してるところの根は同じだと思う。
481:デフォルトの名無しさん
05/12/18 11:40:33
>>479
> ポインタを使いたくないからクラス化しているのに本末転倒な状況だ。
そんなあほな。
482:デフォルトの名無しさん
05/12/18 11:58:05
>>480
スライスが動詞でスライシングが動名詞だということだけはわかりました。本当にありがとうございました。
>>481
そういうもんですか？
自分でバッファを確保・解放するなら、
文字列クラスじゃなくて生のchar*でいい気がするけど、どうでしょうか。
暗黙のうちに解放されるコンテナの場合、>>479が触れているとおりテンプレートだし。
だめ？
483:デフォルトの名無しさん
05/12/18 12:40:10
スライシングすらわからんのなら出直してこい
484:デフォルトの名無しさん
05/12/18 12:46:34
>>476
std::wstringは？
>>477
char_traitsの自作は？
485:デフォルトの名無しさん
05/12/18 14:40:45
オススメはbasic_string<unsigned char>でUTF-8
いや、マジで。
486:デフォルトの名無しさん
05/12/18 14:55:54
1文字進めるとかは？
487:デフォルトの名無しさん
05/12/18 15:01:58
>>484
>std::wstringは？
ワイド文字列の罠
URLﾘﾝｸ(hw001.gate01.com)
488:デフォルトの名無しさん
05/12/18 15:34:13
Windows上で多言語対応が必要ないなら16bit化SJISをwstringにつっこむのが最強。
489:デフォルトの名無しさん
05/12/18 18:40:23
>>488
それAPIやライブラリ関数呼び出しの度にchar*またはwchar_t*に
変換せなあかんのか
最悪じゃん
490:デフォルトの名無しさん
05/12/18 19:28:16
>>488
UTF-16をwstringに格納することに比べどんな利点があるのか？
491:デフォルトの名無しさん
05/12/18 21:56:36
1文字進めるのが簡単
492:デフォルトの名無しさん
05/12/18 22:04:08
そして2文字戻す。
493:デフォルトの名無しさん
05/12/18 22:51:03
三歩進んで二歩下がる
494:デフォルトの名無しさん
05/12/19 09:49:59
>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。
(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん
495:デフォルトの名無しさん
05/12/19 10:12:46
>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。
(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん
496:デフォルトの名無しさん
05/12/19 11:18:52
>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。
(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん
497:デフォルトの名無しさん
05/12/20 21:18:46
>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。
(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん
498:デフォルトの名無しさん
05/12/20 21:37:00
>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。
(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん
499:デフォルトの名無しさん
05/12/20 22:42:51
>>479
> また、STLのコンテナやアルゴリズムがテンプレートを用いており、
> 継承をあえて使っていない理由についても考えよう。
(ﾟДﾟ)ﾊｧ?
テンプレート関係ないやん
500:デフォルトの名無しさん
05/12/20 23:23:51
よくわからん流れだが
５００は頂いとくよ
501:デフォルトの名無しさん
05/12/20 23:26:28
ショック！自作ゲームでわざわざタスクシステムを自前リストで作ってたけど、
STL使ったら直ぐに出来上がった。
今まで食わず嫌いしてて損したよﾏﾏﾝ。
502:デフォルトの名無しさん
05/12/20 23:47:06
まあまあ、苦労は一回はいいんでないかい。一回だけね。
503:デフォルトの名無しさん
05/12/20 23:59:43
ゲームのタスクシステムに向いてるのってsetとlistどっちでしょうか？
504:デフォルトの名無しさん
05/12/21 00:08:58
普通は組み合わせることになるんじゃないの？
mapのlistとか、vectorのmapとか。
setはあんまり出番なさそうだけど。
505:デフォルトの名無しさん
05/12/21 00:10:53
priority_queueだと思うが。
506:501
05/12/21 00:16:04
俺はlistで作ってみた。で、タスクは一定のメモリを使い回すのが利点なので、動的メモリ確保開放しないように作りたい。
で、結局push_frontでダミーを一定量確保したら一旦clearするようにタスクのファクトリを作ってみた。
push_back等で一定量確保した後で、eraseやclearを使った後は、前に確保した領域は使い回されている保障はあるのかな。
誰か詳細ｷﾎﾞﾝ。
507:デフォルトの名無しさん
05/12/21 00:18:58
そういう場合のためにアロケータがあるんだけどな。
508:501
05/12/21 00:21:48
>>507
なるほど偉い便利だな。これで心置きなく作れる。
ｻﾝｸｽ。
509:デフォルトの名無しさん
05/12/21 00:31:08
>506
そういうのはvectorだけじゃね？
reserve()があるのはvectorだけだし。
510:デフォルトの名無しさん
05/12/21 01:18:42
するとvectorのarg2に自前のアロケータテンプレート指定して作れって事ですかね。
安心できると思ったけど結構めんどいね。
511:デフォルトの名無しさん
05/12/21 01:34:11
>510
reserve()はアロケータの呼び出し自体を抑えて、動的メモリの再確保回数を減らす方法。
listで似たような事をしたければ自前アロケータの内部で似たようなことをするように作れ、と言うこと。
512:デフォルトの名無しさん
05/12/21 04:40:22
boost::poolをコンテナの第三引数に入れて、ベンチマークを取ったり
した。ケースバイケースだけど、こちらの方がわずかに速くなる場合がある。
逆に遅くなる事もある。環境や用途にも大きく左右されると思うので、
各自実験してみて欲しいが、なかなか面白いる
513:デフォルトの名無しさん
05/12/21 05:02:50
＞面白いる
いらん
514:デフォルトの名無しさん
05/12/21 05:11:03
かなタイプで、「。」を「る」に打ち間違えただけじゃないかー
そんなに責めるなよーorz
515:デフォルトの名無しさん
05/12/21 07:04:20
>>510
作らないでもいろいろある。
516:デフォルトの名無しさん
05/12/21 13:55:28
>>515
それを聞きたいいる
517:デフォルトの名無しさん
05/12/21 15:08:20
STLを学ぼうとして最初に思い込みが原因か疑問符がついたので質問させてください。
string型なのですが、char型配列→string型はもちろんできます。
逆も「読み取り専用」なら str.c_str(); で出来たのですが、string型に直接値を入れるのはできないのでしょうか。（設計思想的にできないのかなと思ってます）
例えば
strcpy(str.hoge(), "こんにちは");
なんて真似です。
作ってるアプリケーションでGetOpenFileNameを使っているのですが、
一旦char配列にファイルパスを受け取らせ、その後pathを保存しておくためのstring型に変換するべきなのでしょうか。
518:デフォルトの名無しさん
05/12/21 16:37:52
よくわからないけど、
std::string hoge;
hoge = "こんにちは"
ならできるよ？
519:デフォルトの名無しさん
05/12/21 16:44:07
お返事ありがとうございます。
それは = 代入演算子が使われているからですよね。
それではなく
sprintf(str.c_str(), "%d", 5);
などが出来ないかなと思いまして。
↑これ自体はやっちゃいけないらしいですけど、他でこの想定にかなう方法はあるのかなと。
Win32APIなどでは、char*を引数で渡して中身を入れてもらうAPIも多くあるので…。
520:デフォルトの名無しさん
05/12/21 16:48:31
要はstrcpy()とかsprintf()とかfgets()のような振る舞いをする関数で使いたいと言うことだろ。
ポインタを渡してそこに書いてくれるような。
521:520
05/12/21 16:49:51
がーん、リロードすべきだったw
で、WinAPIを使いたいだけならCStringという妥協でも委員でないの?
522:デフォルトの名無しさん
05/12/21 17:41:27
STLのstringはそういう扱いはできないということですね。
ありがとうございました。
523:デフォルトの名無しさん
05/12/21 18:08:18
stdio系使わずにstringstream使え
524:デフォルトの名無しさん
05/12/21 18:42:47
sprintf -> stringstream
fgets -> getline
とか、代替のものがあるので、それを使うのが一番じゃないかな。
525:デフォルトの名無しさん
05/12/21 18:59:21
>523>524
WinAPIで使いたい、って書いてあるやん。
526:デフォルトの名無しさん
05/12/21 20:03:24
std::string strprintf(const char *fmt, ...)
みたいな関数をでっち上げればいい。
527:デフォルトの名無しさん
05/12/21 20:27:50
んなことやるぐらいならboost::formatで。
528:デフォルトの名無しさん
05/12/21 20:29:26
boostは使いたくない
529:デフォルトの名無しさん
05/12/21 21:17:49
>>528 その心は？
530:デフォルトの名無しさん
05/12/21 21:21:00
>>519
WinAPI相手ならstd::vector<TCHAR>で我慢してくれ。
531:デフォルトの名無しさん
05/12/21 21:46:12
>>529サイズがでかくなるから
532:デフォルトの名無しさん
05/12/21 21:50:43
環境によるだろ。
俺は（略）
533:デフォルトの名無しさん
05/12/21 21:57:57
すげえ。ダイナm(略)
534:デフォルトの名無しさん
05/12/21 23:27:46
#include <stdafx.h>
後(略)
535:デフォルトの名無しさん
05/12/21 23:34:43
>>517
望みは捨てるな。
ｽﾚﾘﾝｸ(tech板:469-470番)n
469デフォルトの名無しさん2005/12/21(水) 06:05:51
URLﾘﾝｸ(www.open-std.org)
News 2005-12-19: The 2005-12 mailing is available (1600 kb tar.gz, .zip 1600 kb) individual papers
News 2005-12-17: The C++ Standard Library Issues List (Revision 40) is available (.tar.gz)
News 2005-12-17: C++ Standard Core Language Issues List (Revision 39) is available, also committee version
470デフォルトの名無しさんsage2005/12/21(水) 10:29:39
うげっ、std::string<>もメモリ上の連続性を仮定するようになるのかよ。
536:http://pc8.2ch.net/test/read.cgi/tech/1133007604/470
05/12/22 02:30:13
>>535
恥ずかしいから貼らないでくれorz
537:デフォルトの名無しさん
05/12/22 02:39:38
std::string hage="ﾋﾞｬｰﾈ";
hage[0] = 'ｳ';
いまでもこれならできたりする。
538:デフォルトの名無しさん
05/12/22 02:53:20
うむふ
539:デフォルトの名無しさん
05/12/22 10:17:18
>>535
いやっほーう！
540:デフォルトの名無しさん
05/12/22 10:35:35
>>535
> 530. Must elements of a string be contiguous?
> （中略）
> The characters in a string are stored contiguously, meaning that if
> s is a basic_string<charT, Allocator>, then
> it obeys the identity
> &*(s.begin() + n) == &*s.begin() + n
> for all 0 <= n < s.size().
か。
541:デフォルトの名無しさん
05/12/23 00:19:34
つ URLﾘﾝｸ(tricklib.com)
std::string location;
sprintf(capture_string(&location), "<%s>#%d", __FILE__, __LINE__);
542:デフォルトの名無しさん
05/12/23 05:38:16
>>541 突然なんだ？
543:デフォルトの名無しさん
05/12/23 14:25:28
>>542
ちょっとタイミング外したけど、>>519 に対してのﾚｽ。
544:デフォルトの名無しさん
05/12/23 18:14:09
dequeがサイズ拡大時に確保するメモリブロックのサイズって大体どれくらいなのでしょうか？
545:デフォルトの名無しさん
05/12/23 18:17:10
処理系による。
546:デフォルトの名無しさん
05/12/25 01:50:59
STLportっていつの間にURL変わったんだ？
ver5.0 出てるなんて知らなかった(////)
547:デフォルトの名無しさん
05/12/25 16:14:29
setとmultisetってどういう風に使い分ければいいんでしょうか？
548:デフォルトの名無しさん
05/12/25 16:15:32
>>547
使えばすぐにわかる。
549:デフォルトの名無しさん
05/12/25 22:00:03
setは集合。つまり重複要素を許さない。
multisetってのは集合ではなく、重複要素を許す。
550:デフォルトの名無しさん
05/12/26 11:31:17
>>549
普通「集合」は重複を許すと思うが。
すくなくとも数学ではそうだ。
551:デフォルトの名無しさん
05/12/26 12:02:11
>>550
よくわからん。
数学では
{1} = {1,1}
じゃないか？
552:デフォルトの名無しさん
05/12/26 12:04:06
数学では普通両者を区別するよ
高校数学までではこんなこと気にしないと思うけどね
553:デフォルトの名無しさん
05/12/26 12:06:13
数学だと重複してるものがいくつあっても同じと考えるから、
実質的に重複を許さないのと同じ
URLﾘﾝｸ(ja.wikipedia.org)
>集合は、順番を入れ替えたり、同じものを付け加えても、もとのものと等しい：
> {1,2,5,7,10} = {5,1,7,2,1,5,10,2}.
554:デフォルトの名無しさん
05/12/26 12:10:04
ZFは普通じゃないのか。
外延性公理
∀a∀b[a=b⇔∀x(x∈a⇔x∈b)]
555:デフォルトの名無しさん
05/12/26 14:15:30
質問です。
二次元dequeを作ろうと思っているのですが
deque<deque<int> > list;
として
list.push_back(deque<int>());
とすると、deque<int>のデストラクタが2回呼ばれてしまう気がします。
これはやって大丈夫なのでしょうか。
また、
deque<CHoge> > list;
list.push_back(CHoge());
でも同様にCHogeのデストラクタが二回呼ばれてしまい問題が出てしまいました。
dequeはクラスなどの「実体の配列」ではなく、「クラスのポインタの配列」にするべきなのでしょうか。
ですがそうするといちいちpop_backなどをする前にdeleteでデストラクタを呼んでやらなければならなくなり、結構面倒です。
使い方が根本的に間違っているのでしょうか？
実体のdequeがつくれ、pushやpopでコンストラクタやデストラクタが1度ずつ呼ばれてくれるのを期待しているのですが…。
556:555
05/12/26 14:16:32
補足です。
＞list.push_back(deque<int>());
＞
＞とすると、deque<int>のデストラクタが2回呼ばれてしまう気がします。
引数で作られた無名なくラスのデストラクタと、
アプリケーションの最後でlistが解放される際のデストラクタで計2回ということです。
557:デフォルトの名無しさん
05/12/26 14:19:42
>>556
コンストラクタが二回、デストラクタが二回走るだけで、
問題はない。
>deque<CHoge> > list;
>list.push_back(CHoge());
これも、CHogeのデフォルトコンストラクタ・コピーコンストラクタ・デストラクタが正しく定義されていれば
問題ないはず。
558:デフォルトの名無しさん
05/12/26 14:25:53
>>557
ありがとうございます。
なるほど。
しかしCHogeはポインタをメンバー変数として所持し、デストラクタでdeleteするようにつくられています。
auto_ptrを使うとよさそうですが、そうするとアップキャストできなくなるのが(CHoge内ポインタの役割上)問題です。
自前で参照カウントを作るか、素直にポインターで実装するべきでしょうか。
deque<CHoge*>
insertやpop, pushするたびに自前でdeleteすることになりますが…。
アドバイスいただければ幸いです。
ところでSTLには、実体を伸び縮みさせられるコンテナはないのでしょうか？
dequeはどうも実体を伸び縮みさせるのには向かないような…。
559:デフォルトの名無しさん
05/12/26 14:32:02
vector< vector<char> > を使って、
可変長構造体にキャストして使うことは可能。
ただ、実体自体を伸び縮みさせるのではなく、
そういうのをポインタで保持するのが普通だと思う。
560:デフォルトの名無しさん
05/12/26 14:35:06
なるほど。
vectorで実体を必要な分確保しておいて、それをdequeにあてはめるわけですね。
しかしvectorは配列が2の乗数を超えるように増えた場合に配列を作り直しますから、コンストラクタとデストラクタがふいなことで呼び出されてしまいそうです。
素直にポインタでやってみようと思います。
ありがとうございました。
しかし>>558でinsertやpop, pushするたびに～って書いてありますが
どう考えてもpopの時しかdeleteは呼びませんね。お恥ずかしい。
561:デフォルトの名無しさん
05/12/26 17:25:44
ポインタのコンテナで自前deleteがいやなら、スマートポインタのコンテナにすればいいじゃない。
ポインタをメンバー持ってるなら、ちゃんとコピー操作に手をいれておけよ。
禁止だけなら3行で済むし。
562:デフォルトの名無しさん
05/12/26 18:05:09
auto_ptrはコンテナの要素にすることが禁止されていなかったか？
563:デフォルトの名無しさん
05/12/26 18:06:51
STLport を使っているんですが、
string にバインドできる stream ってないでしょうか？
std::string str, day_status("善い日");
std::ostrstreambuf out(str);
out << "今日は" << day_status << "だ、便が出る";
std::cout << str << std::endl;
-- outpu --
今日は善い日だ、便が出る
こんなヤツ
564:デフォルトの名無しさん
05/12/26 18:08:16
>>562
boost::shared_ptr
565:デフォルトの名無しさん
05/12/26 18:09:43
>>563
stringstream
566:565
05/12/26 18:10:18
と、ちょっと用途が違うみたい。スマン忘れて
567:デフォルトの名無しさん
05/12/26 18:11:09
>>563
バインドはできないけど、std::ostringstreamからstr()でstd::stringを取り出せる。
568:デフォルトの名無しさん
05/12/26 18:20:12
>>564
うお、shared_ptrだったら大丈夫なのか。正直知らんかった。
コンテナが縮む時に、破棄された分の要素についてデストラクタが呼ばれるのって仕様上確定しているのかね？
確定していないからauto_ptr(とかshared_ptr)はダメなんだと思っていたんだが。
569:デフォルトの名無しさん
05/12/26 18:27:39
>コンテナが縮む時に、破棄された分の要素についてデストラクタが呼ばれるのって仕様上確定しているのかね？
当り前だ。それが保証されてなかったらそもそもコンテナがまともにつかえない。
auto_ptrがコンテナに入れられないのはコピーセマンティクスが破壊的だから。
570:デフォルトの名無しさん
05/12/26 18:29:38
>>565, >>567
ありがとうございます。
バインドできないのかー。
残念。
571:デフォルトの名無しさん
05/12/26 19:03:09
boostならpointer_containerもありますよっと。
572:デフォルトの名無しさん
05/12/26 23:54:01
vectorがA構造体の配列で
Aはメンバにid,dateを持っていて
例えばidが2を持つ一番初めの要素を検索するにはどのようにコーディングしたらよろしいのでしょうか
ご教授お願いします
573:デフォルトの名無しさん
05/12/27 00:03:34
>>572
自分ならこんな感じかな？
struct A_eq_id:std::binary_function<A,int,bool>{
bool operator()(const A&a,int n)const{return a.id == n;}
};
std::vector<A> vect;
std::vector<A>::iterator itr = find_if(vect.begin(),vect.end(),bind2nd(A_eq_id(),2));
574:デフォルトの名無しさん
05/12/27 00:07:23
#include <algorithm>
struct A_id_is_2 {
bool operator()(const A& a) {
return a.id == 2;
}
};
std::find_if(a_vector.begin(), a_vector.end(), A_id_is_2());
おもいっきし簡略化して書くとこんな感じか。
std::find_ifで調べてみるとよろし。
575:デフォルトの名無しさん
05/12/27 00:14:00
struct A {
bool operator(int key) const {return id == key;}
int id;
T date;
};
std::vector<A> foo;
std::find(foo.begin(), foo.end(), 2);
576:デフォルトの名無しさん
05/12/27 00:32:06
a_vector.begin() + rand() % a_vector.size(); // ←多分これが2
577:デフォルトの名無しさん
05/12/27 00:40:10
boost様の登場
#include<boost/lambda/lambda.hpp>
#include<boost/lambda/bind.hpp>
using namespace boost::lambda;
std::find_if(vect.begin(),vect.end(),bind(&A::get_id,_1)==2);
578:577
05/12/27 00:42:25
あ、getterの定義いらね
std::vector<A>::iterator itr = std::find_if(vect.begin(),vect.end(),bind(&A::id,_1)==2);
579:572
05/12/28 01:18:49
とりあえず573で出来ました
これは前に書いた出力のやつに似ているので自分にあっているっぽいです
boostも便利らしいですが色々ややこしく…な感じです
STLも殆ど分かっていないですし手をつけるのもどうかなと思うところもあります
(しかしどうしてこのような結果が得られるのか今ひとつ分からん
も少し格闘してきます
580:デフォルトの名無しさん
05/12/28 10:40:22
>>579
>575と>574が理解できれば>573はその中間と言うか、汎用型じゃん。
581:デフォルトの名無しさん
05/12/28 11:38:41
>>580
ハイハイ。知ったか君。
582:575=580
05/12/28 11:53:17
>>581
何か?
#今改めて>575を見たらoperator==になってない……_/￣|○
583:デフォルトの名無しさん
05/12/28 22:14:09
vector<char>からcharの配列を取り出すのはわかるのですが(&vector.front())、
list<char>からの取り出し方法が分かりません。
リスト構造なのでループで回さないと無理なのかとも思うのですが、良い方法が
あればご教授お願いします。
584:デフォルトの名無しさん
05/12/28 22:17:05
>>583
empty() の時は front() 呼び出しちゃだめだから気をつけて。
vector 以外のコンテナからC言語の組み込み配列を得るには
コピーして作るしかない。
585:デフォルトの名無しさん
05/12/28 23:05:23
>>583
ループを回す代わりにイテレータで。
std::list<char> ls;
// ……。
std::vector<char> v(ls.begin(), ls.end());
場合によってはstd::stringのほうが良いかもしれない。
586:デフォルトの名無しさん
05/12/28 23:53:40
えっと Windows で STLPort 4.6.2 を使っているんだけど、StlPort って
スレッドセーフってことでいいのでしょうか？
マルチスレッドなプログラム書いてて、再現が難しい（リリースモードのみ）
バグがあって原因を追究しているんだけど、スタックトレースを
とったら、stlport の _alloc.c で落ちたみたいなんですが・・・
587:デフォルトの名無しさん
05/12/29 00:01:47
メモリリークの類がalloc.cで落ちるのはよくある話。
588:デフォルトの名無しさん
05/12/29 00:32:40
>>584-585
ありがとうございました。
589:デフォルトの名無しさん
05/12/31 16:33:11
簡単で標準的なスマポを標準テンプレートライブラりーで
教えてくださいって、既にテンプレートを貼ってあったら
ごめんなさい。
ちなみに、紅白の大鳥はスマップです。←見ねーよ
戦後６０年を見るね。0：00英霊たちに合唱・・・亞ボーン
590:デフォルトの名無しさん
05/12/31 16:37:40
…(;ﾟДﾟ)
591:デフォルトの名無しさん
05/12/31 17:38:49
>>589 斬新だな。
592:デフォルトの名無しさん
05/12/31 18:29:36
某より引用 左辺値を減らしてから代入する気が
tPtr->inc(); tPtr = ptr; tPtr->dec();
次に示す簡単なサンプルは，スマートポインタークラスのテンプレート
MemMgrと呼ばれるサポートクラスから作成されます。
SP クラスは，とても基本的で，-> や = といった演算子を唯一，
オーバーライドしたものです。
SP メンバー関数は，カウントの使用方法を保つため，
MemMgr inc()と dec()を呼び出します。
#include <iostream.h>
//--------------- class SP
template <class T>
class SP {
T* tPtr;
public:
SP(T* ptr) : tPtr(ptr) { tPtr->inc(); }
~SP() { tPtr->dec(); }
T* operator->() { return tPtr; }
SP& operator=(T* ptr) {
tPtr->inc();tPtr = ptr;tPtr->dec();
return *this; }
};
//----------- class MemMgr
class MemMgr {
int inUse;
public:
MemMgr(void) { inUse = 0; }
void inc(void) {++inUse;}
void dec(void) {if (--inUse == 0)elete this;}
};
593:デフォルトの名無しさん
05/12/31 18:32:16
>>592
コンパイルがどう見ても通らないソースなんだが。
何を言いたいんだ？
594:デフォルトの名無しさん
05/12/31 18:44:22
年の瀬に湧くと話題の馬鹿でしょう。
595:デフォルトの名無しさん
05/12/31 19:31:46
>>592
URLﾘﾝｸ(www.borland.co.jp)
＞コンパイルがどう見ても通らないソースなんだが。
＞何を言いたいんだ？
某のコンパイラは通らないか、ソースが間違っているのですか。
ついでにＶＣ６ ＶＣ２００５での問題点も指摘してください。
596:デフォルトの名無しさん
05/12/31 19:44:43
だから elete って何よ。
597:
05/12/31 19:46:17
ひょードル強いな！
598:デフォルトの名無しさん
05/12/31 19:48:47
もう、寝ていいよ
（596だから elete って何よ）
599:デフォルトの名無しさん
06/01/03 22:23:13
それはねー、エリート宣言さ～
600:デフォルトの名無しさん
06/01/04 16:29:26
６００
601:デフォルトの名無しさん
06/01/06 18:29:58
std::numeric_limits<double> のメンバ関数を使って、
ある double 型の変数に格納されているのが
NaN かどうかを判定するってことは可能ですか？
つまり C99 における isnan() のようなものが
STL にも用意されているのでしょうか??
602:デフォルトの名無しさん
06/01/06 18:37:44
こんなん見つけた
URLﾘﾝｸ(www.kouno.jp)
603:デフォルトの名無しさん
06/01/06 18:43:23
結局 isnan() を使うしかないのか・・・
gcc だと C99 準拠だから isnan() がつかえるけど、
Visual C++ だと C99 準拠じゃないから isnan() がないんだよな。
でもよく見たら _isnan() があった。
とはいえ、nan() も処理系によって有ったり無かったりなんで、
std::numeric_limits<double>.quiet_NaN() のほうがいいかも
と思ったんだけど、結局 STL もそこまでは面倒見てくれないのか。
604:デフォルトの名無しさん
06/01/08 14:50:10
MinGWへのSTLport5.0.1のインストールやっとうまく行った・・・・
今までおかしかった原因は、-mthreadsをコマンドラインに与えてないせいでした。
STLportがマルチスレッドでビルドされるのは知ってたけど、4.6.2までは-mthreads
が不要だったので、はまってました。
この勢いでVC7.1にも入れよう。VC8.0もいじらないといけないし、大変だ。
605:デフォルトの名無しさん
06/01/09 15:02:07
std::vector<T> や std::list<T> に
T や T の派生クラスを混在して保持するように
したいのですが、可能でしょうか？
606:デフォルトの名無しさん
06/01/09 15:08:31
ポインタ若しくはスマートポインタを格納することは可能
607:デフォルトの名無しさん
06/01/09 15:13:50
std::auto_ptr ？
とおもったけど、これは色々文献を読んでみると
STLのコンテナの要素とすることは禁止されているみたいですね。
内部の実装がどうなってるのかは知らないけど。
格納したいクラスへのポインタをメンバに持つ
ラッパークラスでも作ろうかとおもったけど、
もしかして boost::shared_ptr で行けたりします？
って、ためしてみようっと。
608:デフォルトの名無しさん
06/01/09 15:17:13
>>607
>もしかして boost::shared_ptr で行けたりします？
はい
609:605=607
06/01/09 15:25:21
ふむ、うまくいったようです。
ありがとうございました。
610:デフォルトの名無しさん
06/01/09 15:49:29
boost を使っていいなら、 ptr_vector とかもあるよ。
611:605=607
06/01/09 16:13:01
げ、なんか便利そうなモノが他にもあるんですか。
boost は普段正規表現ライブラリくらいしか使わないんで、
boost の全貌を把握してないんですよ。
boost:ptr_vector もどんなもんか勉強してきます。
612:デフォルトの名無しさん
06/01/09 21:52:05
std::vector とかって operator[] では
std::out_of_range 例外が発生しないんですね。
at() なら発生するのに。
613:デフォルトの名無しさん
06/01/09 22:08:35
>>612
at() は範囲チェックをする分パフォーマンスが落ちるから、
範囲外へのアクセスを行う可能性がある時のみ使う感じで使い分けたりする。
614:デフォルトの名無しさん
06/01/13 01:51:05
mapで一度登録した値を変更したい場合一度削除しないと変更できませんか？
615:デフォルトの名無しさん
06/01/13 01:58:46
m[key] = value;
616:デフォルトの名無しさん
06/01/13 01:59:02
>>614
できます
617:デフォルトの名無しさん
06/01/13 02:11:38
どうもありがとうございます
618:デフォルトの名無しさん
06/01/13 17:43:32
stringとwstringの相互変換なtemplate又は、関数ってあります？
やっぱ、
MultiByteToWideCharとか使って変換しないと駄目？
619:デフォルトの名無しさん
06/01/13 18:41:13
お前が変換したいように変換しろ。
620:デフォルトの名無しさん
06/01/13 21:30:21
>>618
wstringつーかwchar_tのエンコーディングは標準でコレと定められているわけじゃない
（まあそれを言ったらcharだってそうだけどな。EBCDICとかあるし、結局何だって
つっこめる）
だから、実際に自分がどーゆーエンコーディングを用いているかに応じて、
変換も行わなければならない。「常に正しい方法」は存在しない、ということだ。
621:デフォルトの名無しさん
06/01/13 21:50:18
ISO C++的にはcodecvtクラスだろ。
関連クラス: locale, facets, codecvt_byname
622:デフォルトの名無しさん
06/01/15 03:12:03
>618
ここの一番下のサンプルでも見るといい。
URLﾘﾝｸ(hw001.gate01.com)
623:本田
06/01/15 17:58:26
>>586
> えっと Windows で STLPort 4.6.2 を使っているんだけど、StlPort って
> スレッドセーフってことでいいのでしょうか？
BCB6は、マルチスレッド対応と非対応を選択できるようだけど。
624:デフォルトの名無しさん
06/01/17 20:36:18
こんにちわ。質問をさせて下さい。
現在ブラウザからActiveXを介してローカルのEXEを起動するシステムを考えています。
いくつかのサイトを調査しました。その中でハ○ゲームのゲームインストーラの動作
を見ていて、よく分かりません。
ActiveX としては C:\WINDOWS\Downloaded Program Files\HgPlugiXJP21 Classとして
ダウンロードされています。
サイトからダウンローダーを起動しているＨＴＭＬは以下の通りでした。
location.href = "hangXme://URLﾘﾝｸ(gamestring.hangXme.co.jp:10000)なんちゃら";
試しに【ファイルを指定して実行】で hangXme: と実行してみると、該当ＥＸＥが起
動します。これはプロトコルとして登録されているのでしょうか？よく分からないので
すが rundll32.exe msconf.dll とかが関係しているのでしょうか？
ちなみに 「ファイルの関連付け」としてはレジストリに以下が設定されています。
HKEY_CLASS_ROOT\HanGXme\Shell\Open\Command
値：C:\WINDOWS\Downloaded Program Files\HGStartXJP21.exe %1
で、hangXame: を実行するとHGStartXJP21.exeが起動します。
この辺の仕組みが分かりません。よろしくご教授下さい．
板違いでしたら申し訳ありません。
625:デフォルトの名無しさん
06/01/17 20:38:59
>>624
全くスレ違い。Win板だと思う。
626:デフォルトの名無しさん
06/01/17 20:59:07
>>625
すいませんでした。
627:デフォルトの名無しさん
06/01/18 21:22:52
vector<char>にcharの配列を一気に代入したいです。
forループでpush_backするより効率がいい方法はありますか？
628:デフォルトの名無しさん
06/01/18 21:28:20
char buf[]="aiueo";
vector<char> hoge(&buf[0],&buf[0] + sizeof(buf)/sizof(buf[0]));
629:デフォルトの名無しさん
06/01/18 21:48:17
これでもいける
char buf[] = "hello";
std::vector<char> v;
v.assign(buf, buf + strlen(buf));
てか、stringをなぜ使わないのか。
参照カウントが気になる？
630:デフォルトの名無しさん
06/01/18 22:33:49
string って参照カウンタ持ってるのか。
独自のGCを使ってるってこと？
631:デフォルトの名無しさん
06/01/18 23:04:10
>>630
参照カウンタを使うかどうかは実装次第。
ただしメモリ確保自体にはテンプレート引数で指定されたアロケータ
（std::stringではstd::allocator<char>）が使われる。
632:デフォルトの名無しさん
06/01/18 23:06:35
>>630
そういう実装が流行ってた時代もあった。
でも今は全部コピーする実装が主流。
どちらにせよ実装依存
633:デフォルトの名無しさん
06/01/18 23:29:54
参照カウンタ方式stringが廃れた理由は何？
634:デフォルトの名無しさん
06/01/18 23:32:35
>>633
たとえばスレッド安全のためということがある。
635:デフォルトの名無しさん
06/01/19 03:09:19
>>628
>629で充分。つーか、それだとナル文字の分も追加されるぞ。
636:628
06/01/19 04:23:05
ありがとうございました。
637:デフォルトの名無しさん
06/01/26 10:27:02
インテルのコンパイラヘルプに、exportのキーワード。
まさか、対応してる？
638:デフォルトの名無しさん
06/01/26 10:30:40
でも、メンバテンプレートがない？
639:デフォルトの名無しさん
06/01/26 11:17:04
export ってなに～？これ？
WindowsでCOMコンポーネントを作るときに使うの？
C++ 属性 export は、データ構造体を .idl ファイルに配置し、
すべての言語で使用できるバイナリ互換形式としてタイプ
ライブラリで使用できるようにします。
クラスにパブリック メンバ (struct と同等) だけが含まれる場合でも、
属性 export をクラスに適用することはできません。
無名の enum や struct をエクスポートする場合は、
__unnamedx (x は連番) で始まる名前が付けられます。
// cpp_attr_ref_export.cpp
// compile with: /LD
[module(name=MyLibrary)];
[export]
struct MyStruct
{
int i;
};
もっと具体的に export でうれしくなれる例を教えて！
ﾊ_ﾊ
('(ﾟ∀ﾟ∩ 教えて！
ヽ 〈
ヽヽ_)
640:デフォルトの名無しさん
06/01/26 11:34:17
>>639
そのexportは無関係。
exportはtemplateの実装を隠蔽するための仕組み。
実装するにはリンカから変えなきゃ不可能に近い仕様なので、
実現してるコンパイラは一握りだけ(VCもgccも未実装)
例としてtemplate関数を定義する場合
template<typename T>
T add(T a,T b){return a+b;}
のように同じ翻訳単位に実装も一緒に書かないといけないが
export template<typename T>
T add(T a,T b);
のように書けば実装は別で定義されていることになってリンク時に結合される
これによってヘッダに大量の実装をおく必要が無くなってコンパイル時間の短縮等が期待できる。
641:デフォルトの名無しさん
06/01/26 11:45:37
まぁコンパイル時間の短縮ってもプリコンパイルヘッダに比べるとどうなんだかな。
642:638
06/01/26 11:50:25
すみません。自己解決しました。テンプレートの解釈があいまいになるところが
あったせいで、VC7でよくて、intelはだめだったというだけでした。
643:デフォルトの名無しさん
06/01/26 11:58:10
>>640
thx。
おもわず、だまされました。
644:デフォルトの名無しさん
06/01/26 17:55:52
std::vector に格納できるのは shared_ptr ですよね？
645:デフォルトの名無しさん
06/01/26 18:05:31
ほぼなんでも格納できます
646:デフォルトの名無しさん
06/01/26 18:17:20
>>645 ちょ、まっ、wwww
std::auto_ptr とかヤバス
647:デフォルトの名無しさん
06/01/26 19:00:36
>645
コピーできないものを「ほぼ」の除外対象にするのは如何なものかと思います。
648:デフォルトの名無しさん
06/01/26 21:53:10
まったく問題ないと思います。
649:デフォルトの名無しさん
06/01/26 22:42:49
>641
Sutter’s Mill: “Export” Restrictions, Part 1 & 2
URLﾘﾝｸ(www.cuj.com)
URLﾘﾝｸ(www.cuj.com)
↑の記事によると、dependent name はテンプレートの定義された文脈と、インスタンス化された文脈の双方を考慮して、
名前解決する必要があるので、テンプレートの定義が変更された場合、そのテンプレートがインスタンス化されている
翻訳単位を(少なくとも全てのテンプレートパラメータの組み合わせが得られる数までは)再コンパイルしなければならない。
この点は export があってもなくても同じなので、ほとんどの場合 export を使ってもコンパイル時間は短縮されないだろう、とのこと。
650:デフォルトの名無しさん
06/01/26 23:27:55
別のコンパイル単位で、
同じ文脈でインスタンス化される場合、
exportでやる流儀なら、一度で済むだろ。
651:デフォルトの名無しさん
06/01/26 23:50:18
>>649
加えて，ビルドツールが export による翻訳単位を超えた依存関係を
識別できなければならない，とか
たとえ無名名前空間で定義された export を指定されていない
テンプレートだとしても他の export されたテンプレート経由で名前が他の
翻訳単位に暴露されるなど，プログラムの挙動が非常に予測しにくくなる，とか
従来の
「～～テンプレートからインスタンス化された～～テンプレートからインスタンス化（以下略」
という楽しいコンパイルエラーメッセージに加えて
「～～翻訳単位からインスタンス化された～～翻訳単位からインスタンス化（以下略」
というさらに楽しいエラーメッセージが付加される，とか色々楽しいことが満載です．
マクロの名前を翻訳単位によって切れるのが，現状 export による
明らかな恩恵だと結論されていますけれど，これも本質的には
別次元の問題（C99 のスコープ付きマクロ）として解決されるべき問題ですし
"Exceptional C++ Style" に，20ページも使って
「現状，いかに export に期待できないか」が， Java の全言語仕様の実装に
2人年かかったのに対して export 「だけ」の実装に3人年かかった，
とかいう話なんかと一緒に恐ろしく詳細に載ってます．
652:651
06/01/27 00:04:54
649 に挙げられた記事と "Exceptional C++ Style" の
内容はほとんど同じものでした．すいません．
653:デフォルトの名無しさん
06/01/27 07:57:01
>650
その高速化は export を使わない場合でも可能だ、というのが記事の趣旨。
もちろん、#include してることで実装の読み込み自体は常に発生するけど、コードの生成までは必要ない。
Comeau compiler は export の場合と、#include の場合の両方でその高速化が可能って書いてあるけど
使ってないから本当かどうかは知らない。
654:デフォルトの名無しさん
06/01/27 08:59:24
>>653
> コードの生成までは必要ない。
一応生成しとかないと。(あるいはソースを保存しとくか)
g++だとweak symbolで生成している。
655:デフォルトの名無しさん
06/01/27 10:35:58
icc なんかで翻訳単位を超えたインライン化なんかも実装されてるわけで、
本質的に便利なことがあれば export も実装も普及するんでしょうね。
656:デフォルトの名無しさん
06/01/28 19:50:50
コンテナに位置と大きさを持った物体を格納してます。
物体の数が１万以上あるからいちいち衝突判定をしていると遅くなるので、
どの物体とどの物体が接触しているという情報を記録しておこうと思いました。
要素のアドレスを使おうと思ったのですが、vectorの場合要素の追加･削除で格納アドレスが変わってしまいます。
listならば下のコードで格納されている要素のアドレスが変わらないことは保証されていますか？
もしくはもっといい方法があれば教えてください。
list<int> a;
a.push_back( 1 );
a.push_back( 2 );
a.push_back( 3 );
a.push_back( 4 );
list<int>::iterator it = a.begin();
it++; it++;
int *p = &*it;
a.erase( a.begin() );
cout << *p << endl; // 3?
657:デフォルトの名無しさん
06/01/28 20:15:07
>>656
その物体オブジェクトに
ID持たせるとかすればいいんじゃね？
アドレスを使うというのはどうも・・・
オブジェクトの拡張ができないなら
map<id, object>とか
vectorとかlistの要素をpair<id, object>にするとか
658:デフォルトの名無しさん
06/01/28 20:16:25
>>656
記録しておきたい要素のインデックスをvectorで保持すればいいジャマイカ
それを添え字に使って位置と大きさとやらにアクセスすればよい。
何のためのvectorだよぅ
659:デフォルトの名無しさん
06/01/28 20:18:42
>>658
それじゃ要素の追加、削除でindexがかわるからまずいんじゃ？
660:デフォルトの名無しさん
06/01/28 20:24:04
>>656
list,set,mapのイテレータが無効になる条件は、
自分自身のイテレータを削除したときのみなので大丈夫と思う。
661:デフォルトの名無しさん
06/01/28 20:31:05
>>659
アドレスが変わるってそのことか。
てっきり要素数が変わった時にガバッと取り直すことかと思ったよ。
662:デフォルトの名無しさん
06/01/28 20:41:56
削除はどのくらいの頻度で起きるのかね。
頻度高いならvectorは得じゃないよね。位置詰めのcopyが起きるから。
663:656
06/01/28 21:38:49
>>657-662
ありがとうございます。
削除も結構な頻度でおこるんで、
とりあえず物体の情報をlistに格納して、衝突判定はそのイテレータを使う方法でやってみます。
664:デフォルトの名無しさん
06/01/28 22:10:49
そうね、listで書いてみて、ボトルネックが見つかれば、
自作も含めて、他のコンテナ考えた方がいいだろうね。
とりあえずコンテナの形態にべたべたに依存しないコード書いといて。
665:デフォルトの名無しさん
06/01/29 05:19:19
コンテナからある条件を満たす要素だけを集めた
新しいコンテナを作るのって一発でできないんですか？
666:デフォルトの名無しさん
06/01/29 05:30:57
>>665 「一発で」の意味がわからん。
667:デフォルトの名無しさん
06/01/29 05:43:34
>>665
たぶん、STLの範囲内でやるなら
remove_copy_if + back_inserter + 適当な述語関数
......どうでも良いけど、STLにcopy_ifが無いのは何故だろう。
668:デフォルトの名無しさん
06/01/29 05:52:19
>>667
入れ忘れちゃった。てへっ♥ by禿
669:667
06/01/29 06:02:25
>>668
を読んでいくら禿でも、そんなことないだろうとプログラミング言語C++を読んでみたら
------------------------------------------------------
残念なことに、copy_ifはどうしたわけか標準ライブラリが
提供するアルゴリズムセットから抜け落ちてしまった(私の過失である)
---------------------------------------------------------
by 禿
プログラミング言語C++第三版 P610より
やっぱ禿のせいか
ｳﾜｧｧｧｧｧｧヽ(`Д´)ﾉｧｧｧｧｧｧﾝ!
670:デフォルトの名無しさん
06/01/29 09:41:20
まあ、logical_not使えばいいし。
671:デフォルトの名無しさん
06/01/29 10:24:19
_ifなんてついてる時点で設計ミスだから禿は正しい
filter_iterator使え
672:デフォルトの名無しさん
06/01/29 10:31:49
今禿って言う香具師ちょっと来い( ﾟДﾟ)
673:デフォルトの名無しさん
06/01/29 10:55:35
はげって誰のこと？
画像はってよ。
674:デフォルトの名無しさん
06/01/29 11:53:09
URLﾘﾝｸ(public.research.att.com)
remove_copyも名前がおかしい。
675:デフォルトの名無しさん
06/01/29 11:54:21
あれえ？前は椅子に座って机に足かけてる画像だったような気がするけど。
ハゲのくせに足なげえとしか思ってたけど。
676:デフォルトの名無しさん
06/01/29 12:05:45
名前はAdaでMusser&Stepanovが書いた頃の流儀だな。
removeじゃなくてDeleteだが。Copy_Ifはこの頃からない。
677:デフォルトの名無しさん
06/01/29 12:15:54
ホントだ。写真変わってるね。
ﾊｹﾞのくせに生意気
678:デフォルトの名無しさん
06/01/29 12:25:27
このおっさんの名前見るたびに、
インリンの顔が浮かぶ。
なんかＭ字ビターンに似てねぇ？
679:デフォルトの名無しさん
06/01/29 13:30:48
ｵﾏｲﾗ本人がいないからって言いたい放題だなｗ
680:デフォルトの名無しさん
06/01/29 13:38:47
禿より♥
template <typename InputIterator, typename OutputIterator, typename Predicate>
inline
OutputIterator
copy_if(InputIterator begin, InputIterator end, OutputIterator destBegin, Predicate p)
{
while (begin != end)
{
if (p(*begin)) *destBegin = *begin;
++destBegin;
++begin;
}
return destBegin;
}
681:デフォルトの名無しさん
06/01/29 14:01:16
>>679
俺は本人の前でも言えるよ。日本語でなら。
682:デフォルトの名無しさん
06/01/29 14:03:11
>>679
俺も本人の前でも言えるよ。エスペラント語なら。
683:デフォルトの名無しさん
06/01/29 14:06:06
ﾋﾞﾔｰｿって言語学者だしエスペラント知ってそうだな
684:デフォルトの名無しさん
06/01/29 14:23:36
だったら禿がこのスレ見たら泣くな
日本語も分かりそうだしｗ
685:デフォルトの名無しさん
06/01/29 16:08:10
は・・い、いえビョ～～ン先生ごめんなさい。
私たちが間違ってました。
686:デフォルトの名無しさん
06/01/29 16:13:40
copy_ifがあるとき ヽ（´ー`）ノ
//全てのアルファベットを抽出
std::copy_if(hoge.begin(),hoge.end(),back_inserter(x),std::isalpha)
copy_ifがないとき（´д｀）
//全てのアルファベットを抽出
std::remove_copy_if(hoge.begin(),hoge.end(),back_inserter(x),std::not1(std::ptr_fun(std::isalpha)))
687:デフォルトの名無しさん
06/01/29 20:49:19
何この平和なスレ。
688:デフォルトの名無しさん
06/01/29 23:30:00
>>686
copy_ifはないけれどBoostがある。
namespace bll = boost::lambda;
std::remove_copy_if(hoge.begin(), hoge.end(), back_inserter(x), !bll::bind(std::isalpha, bll::_1))
689:デフォルトの名無しさん
06/01/30 23:46:56
あ～るはげた～ひる～さがり～♪
690:デフォルトの名無しさん
06/01/31 00:06:11
か～つら～につづ～くみち～♪
691:デフォルトの名無しさん
06/01/31 01:37:40
めーがーねーがーごーとーごーとー♪
692:デフォルトの名無しさん
06/01/31 12:11:59
func(float a[])
という関数に
vector<float> x;
を引数に渡したくて、
func(&(x[0]))
とやっているんだけど、うまくキャストができません。
どうすればいいでしょうか？ご教授よろしくお願いいたしますm(__)m
693:デフォルトの名無しさん
06/01/31 12:24:00
>>692
すまん、普通にそれで通るんだがコンパイラ何よ？
#include<vector>
void func(float a[]){}
int main(){
std::vector<float>x;
func(&(x[0]));
}
694:デフォルトの名無しさん
06/01/31 12:35:35
>>693
すまん、おれのミスだった。まちがって、
int main(){
std::vector<float>x;
func(x);
}
とやっていた。
いずれにしろバグが取れて助かりました。
どうもありがとう！
695:デフォルトの名無しさん
06/01/31 13:18:55
それバグじゃない
696:デフォルトの名無しさん
06/01/31 21:45:01
694の頭にバグがあったということだろう。
697:デフォルトの名無しさん
06/01/31 23:30:35
スキンヘッド推奨
698:デフォルトの名無しさん
06/02/01 05:53:56
サイドは残さなきゃダメだろ
699:デフォルトの名無しさん
06/02/06 16:43:38
std::vector<T> にて、T はデフォルトコンストラクタ
T::T() を持たなければダメなんでしょうか？？？？
たしかに T::T() を必要とするメソッドは有るよな。
初期化されないブツが投入されるのがイヤな時には、
とりあえず T::T() の中で何か throw するようにしておく？
でもそれだと実行時にしか検出されない･･･
って、書いてて気づいたんだけど、もしかして
T::T() を宣言だけしておいて定義しなければ
リンク時に気づくかも。
700:デフォルトの名無しさん
06/02/06 16:50:32
そんなに気になるならデフォルトコンストラクタをprivateにすればいいやん（;´Д｀）
701:デフォルトの名無しさん
06/02/06 17:05:05
>>700 ΣΣ（ﾟдﾟlll）ｶﾞｶﾞｰﾝ
そ、そうだった・・・・
702:デフォルトの名無しさん
06/02/06 17:11:54
>>699
>初期化されないブツが投入されるのがイヤな時には、
ってことはそのTは自前のコンストラクタを持ってるわけでしょ
ってことはT::T()が勝手に定義されることはないので
何もしなくてもコンパイルエラーになるよ
703:デフォルトの名無しさん
06/02/06 17:19:35
>>702 うん、で、そういうクラスを std::vector<T> に
格納しようとしたら、std::vector<T> のコンストラクタの
一つが T のデフォルトコンストラクタを要求するので
エラーになります。 private にしても同じく。
でも実際にはそのコンストラクタは呼ばれないので、
宣言だけして定義はしなくてもリンク可能です。
実際に使われてるか否か（コードが生成されているか否か）
に関わり無く、テンプレートの関数はとりあえず
実体が生成されるものとして構文と識別子のチェックが行われるようです。
704:デフォルトの名無しさん
06/02/06 17:20:12
って、それは C++99 が要求している事なのか、
たまたま VC++ 2005 の実装がそうなのか分かりません。
705:デフォルトの名無しさん
06/02/06 17:27:22
JIS X3014ではコンテナの要素の要件に定められていることは、
コピーコンストラクト可能であることと代入可能であることだけだった。
（デフォルトコンストラクト可能である必要はないと）
706:デフォルトの名無しさん
06/02/06 17:30:26
>>703
VCで試そうとしたけどエラーが出ない......
エラーの出る最小のソース希望
707:ごめん
06/02/06 17:50:27
俺の勘違い。
class Kurasu {
private:
int i;
public:
Kurasu(const int given_i) { i=given_i;}
};
void KurasuVector() {
std::vector<Kurasu> k(100);
}
そりゃエラーになるわ。
俺が明示的にデフォルトコンストラクタを必要とする
コンストラクタを呼び出してるんだからな。
void KurasuVector() {
std::vector<Kurasu> k;
}
なら問題 nothing 。
正直、スマンカッタ
708:デフォルトの名無しさん
06/02/06 21:59:19
>>704
C++は98。
709:デフォルトの名無しさん
06/02/06 22:00:44
>>708
つ2003
710:デフォルトの名無しさん
06/02/06 22:04:28
禿共のがんばり次第によっては06
711:デフォルトの名無しさん
06/02/06 22:13:51
>>710
禿曰く09
712:デフォルトの名無しさん
06/02/06 22:17:47
おのれ禿・・・
そんなに待てぬ
713:デフォルトの名無しさん
06/02/06 22:29:30
禿禿いうな禿
714:デフォルトの名無しさん
06/02/06 22:31:23
禿せめて08年中ぐらいにはお願いします。
そうすれば00年代にはそこそこ対応したコンパイラが出るかもしれません。
715:デフォルトの名無しさん
06/02/07 06:18:41
禿さんの禿って今も進行してるんですか？
716:デフォルトの名無しさん
06/02/07 07:14:10
>>715
まだ完全には実装されていない。
というか、写真によってちょっとずつちがうから、
そこはベンダー依存ではないか。
717:デフォルトの名無しさん
06/02/07 07:48:57
10年に出すと言うのも男の勇気ですぜ，禿の兄貴。
718:デフォルトの名無しさん
06/02/07 11:12:23
確か最速で x=9 ってヒゲが言ってた。
標準化のプロセスに時間がかかるらしいから、
禿やヒゲががんばっても多分早くはならない。
719:デフォルトの名無しさん
06/02/07 11:19:31
まあ無理に急いで糞言語になるか、標準化遅れて処理系がNEEEEEEになるかはトレードオフだしなぁ
720:デフォルトの名無しさん
06/02/07 11:29:31
どこがC++0xなんだよ
C++1xじゃねえか
禿だか髭だかフサフサだかしらねーけどとっととしやがれ
721:デフォルトの名無しさん
06/02/07 11:45:21
C++0x0a
722:デフォルトの名無しさん
06/02/07 20:19:28
クラスのポインタ配列のvectorを作成し、
foo.push_back(new CFoo()); とやると無論コンストラクタが呼ばれますが
foo.erase(foo.begin()); 等とした際に
CFooのデストラクタが呼ばれないのは、こういう物だと思うしか無いのでしょうか？
foo[0].~CFoo(); みたいな事をeraseする度にやるのは何かおかしい感じがします
723:デフォルトの名無しさん
06/02/07 20:26:15
>>722
スマートポインタ
724:デフォルトの名無しさん
06/02/07 20:32:37
>>722
eraseする前にデストラクタではなくdeleteを呼べ。
それでは面倒だから>>723。
或いはboost::ptr_vector。
725:デフォルトの名無しさん
06/02/07 20:33:52
deleteされるわけじゃないからね、リークするだけ
boost::shared_ptrとかptr_vectorとかあるけど
726:デフォルトの名無しさん
06/02/07 20:36:09
>>723-725
一応、こういうモノなんですね…、ありがとうございます
ptr_vector ていうのがぱっと見便利そうなので試してみます。
とても参考になります。
727:デフォルトの名無しさん
06/02/08 00:27:35
>>722,726
もう納得したみたいだが
CFoo* p = new CFoo();
foo.push_back(p);
foo.erase(foo.begin());
で、勝手にdeleteされた方が
おかしい感じがするだろ
728:デフォルトの名無しさん
06/02/08 09:39:50
boost::ptr_vector と
std::vector<boost::shared_ptr> と
どっちがおすすめ？
っていうか本質的な違いある？
729:デフォルトの名無しさん
06/02/08 10:53:13
>>728
>どっちがおすすめ？
ケースバイケース
>っていうか本質的な違いある？
要素が生ポインタかスマートポインタか。
730:デフォルトの名無しさん
06/02/08 10:58:31
>>729 そうか、 boost::ptr_vector は中身が生ポインタか。
だったら std::vector< std::auto_ptr > とおなじようなもんか？
と思ったけど、後者はやっちゃだめなんだよな。
とりあえず boost::ptr_vector のヘッダファイルでも読んでみます。
731:デフォルトの名無しさん
06/02/08 21:55:40
>>730
ptr_vectorは、ただ単にデストラクタで全要素をdeleteするだけだろ。
auto_ptrとは何の関係もない。
732:デフォルトの名無しさん
06/02/08 23:20:20
要素が削除されたときにdeleteされるから、概念的に各要素がauto_ptrと言えなくも無い。
所有権の移動が無いからboost::scoped_ptrの方が適当だが。
733:デフォルトの名無しさん
06/02/09 08:17:21
(ﾟДﾟ)ﾊｧ?
734:デフォルトの名無しさん
06/02/09 09:28:44
ゆとり世代か
735:デフォルトの名無しさん
06/02/09 10:47:39
732はきわめて妥当なこと書いてると思うが……
736:デフォルトの名無しさん
06/02/09 19:14:45
>735
同意。
737:デフォルトの名無しさん
06/02/09 20:00:25
概念的という言葉を使えば、その記述が妥当であるかのように錯覚する。
しかし、プログラマの目の前にあるものは、
あいまいな「概念」などではなく、具体的で厳密なものだ。
プラットホーム、コンパイラ、ライブラリへの依存を無視した「概念」という言葉は、
プログラマに何の解決ももたらさない。時に誤解さえ与えかねない。
738:デフォルトの名無しさん
06/02/09 22:09:49
概念は心の拠り所。
739:デフォルトの名無しさん
06/02/10 00:22:32
>>737
お空に消えてなくなるタバコの煙みたいなレスですね。
740:デフォルトの名無しさん
06/02/11 14:39:46
先月末にApacheの(元はRogue Waveの)STLが出てるけど、これ既出？
URLﾘﾝｸ(incubator.apache.org) の一番下
741:デフォルトの名無しさん
06/02/12 14:20:46
>>740
DL してみたんですけど、 VC6 へのインストール方法がわかりませんでした。。。
742:デフォルトの名無しさん
06/02/20 06:46:37
vectorを配列のように使った場合、配列と比較してパフォーマンスは落ちますか？
743:デフォルトの名無しさん
06/02/20 06:47:16
自分で計れカス
744:デフォルトの名無しさん
06/02/20 07:15:19
実装にもよるが素人が書いた場合、むしろ速くなる場合が多いのでvectorが利用できるなら利用することをすすめる
745:デフォルトの名無しさん
06/02/20 10:08:16
>>742 パフォーマンスに一番影響が出そうなところは
at() と operator[] のどちらを使うかってところかなぁ。
俺はもんげ～速度に厳しいときだけ operator[] 使ってる。
746:デフォルトの名無しさん
06/02/20 11:06:31
未だにat()を使ったことがない。
747:デフォルトの名無しさん
06/02/20 11:18:38
>>746 とりあえず安全のために
速度にうるさくないところでは
at() を使ってる。冷害出してくれるし。
748:デフォルトの名無しさん
06/02/20 11:20:28
あー漏れも同じだ
とりあえずat使って例外が飛んでこなかったらホットしてる
749:デフォルトの名無しさん
06/02/20 11:54:43
ホットで藤井隆を思い出した
750:デフォルトの名無しさん
06/02/20 13:04:53
漏れはfor_eachを使うからat()もoperator[]も使わんがな。
751:デフォルトの名無しさん
06/02/20 21:13:31
STL
ST
S
ST
SLL
752:デフォルトの名無しさん
06/02/20 22:08:02
at は安全だっつって使っておきながら catch してない人が居たなあ……。
753:デフォルトの名無しさん
06/02/20 22:49:12
>>752
投げられる例外すべてを catch する必要は無い。
754:デフォルトの名無しさん
06/02/21 12:42:04
>>752
コケてくれるという事は、検出出来ている、という事です。
安全ですね
755:デフォルトの名無しさん
06/02/21 12:59:15
「こけてくれる=安全」といえばこんな思い出が。
学生時代、あるプロジェクトにバイトで火消し投入された。
バイトを投入するあたり、相当DQNな会社だったわけだが、
まぁ投入される方としては時給もよかったしラッキーって感じ。
で、いつまで経っても原因不明のバグが出たりでなかったりで
リリースできん、って言う物だったんだけど、社内で共通に
使ってるライブラリみて唖然とした。すげぇ臭い物に蓋な
プログラム。例えば年齢を引数に取るコードで、負の値が
与えられたら勝手に0と見なす、みたいなことやってる。
で、漏れが assert 入れたら、お前のせいでバグが増えたってしばかれた。
756:デフォルトの名無しさん
06/02/21 14:58:19
以下のようなプログラムでa::bを使用すると
public: static class std::map<int,int,struct std::less<int>,class std::allocator<int> > a::b
というリンクエラーが発生します。
これはなぜなのでしょうか？
#include <map>
class a {
public:
static std::map<int,int> b;
};
757:デフォルトの名無しさん
06/02/21 15:03:53
class a{
...
};
static std::map<int,int> a::b; ← static メンバは外部定義しないとダメポ
758:デフォルトの名無しさん
06/02/21 15:09:38
>>757 宣言もしてないのにそんなこと出来るの？
759:デフォルトの名無しさん
06/02/21 15:34:47
その質問はよくわからんな
760:デフォルトの名無しさん
06/02/21 15:36:11
僕がSTLより高速なコードを書ける日来ますか？
761:デフォルトの名無しさん
06/02/21 15:36:34
来ません。
762:デフォルトの名無しさん
06/02/21 15:49:21
>>756
何その糞コンパイラ。
763:760
06/02/21 16:03:57
>>761
ありがとうございました。
それが分かっただけでも大満足です＾＾
764:デフォルトの名無しさん
06/02/21 16:54:05
>>757
以下のようにしたらエラーが出なくなりました。
ありがとうございます。
#include <MAP>
class a {
public:
static std::map<int,int> b;
};
std::map<int,int> a::b;
765:デフォルトの名無しさん
06/02/21 17:19:24
>>762
そのレスは意味が分からん
766:デフォルトの名無しさん
06/02/21 17:53:27
>>755
続きは？
767:デフォルトの名無しさん
06/02/21 18:36:01
>>766
確かにちょっと気になるな
ワッフルワッフル
768:デフォルトの名無しさん
06/02/21 18:52:03
それはつまり、どういうイヤらしいしばかれ方をしたか
詳細を書けということだな
ワッフルワッフル
769:デフォルトの名無しさん
06/02/21 22:58:38
キャッチしなくていいってのは、例外安全無視ってこと？
770:デフォルトの名無しさん
06/02/21 23:02:21
>>769
関係ない。「例外安全」の意味わかってんのか？