【C++】STL(Standard ..
[2ch|▼Menu]
285:デフォルトの名無しさん
05/11/21 17:47:41
class FinallyCloseHandle {
private:
  HANDLE h_;
public:
  FinallyCloseHandle(HANDLE h) : h_(h)
  { if (h==INVALID_HANDLE_VALUE) throw; }
  ~FinallyCloseHandle() { CloseHandle(h_); }
};

というクラスを用意して

HANDLE file = CreateFile(...)
auto_ptr<FinallyCloseHandle> fch(new FinallyCloseHandle(file));

として、スコープを抜けるときに自動解放するようにしてるんですが、
これを汎用的に行う方法はないでしょうか

CloseHandle以外にも、いろいろ終了処理はありますが、
それに対して毎回似たようなクラスを作るのは、スマートとは思えません
atexitみたいな形で、スコープを抜けるときに呼び出す関数を
積んでおくことができると理想なのですが

286:デフォルトの名無しさん
05/11/21 17:56:11
boost::move_ptrやshared_ptrみたいに削除子を指定するのはダメ?

287:デフォルトの名無しさん
05/11/21 18:10:35
>>286
サンキュー!そのものズバリが見つかったーよ
URLリンク(boost.cppll.jp)

以前、どこかのWebでスコープを抜けるときにコードを実行できるようなことを読んだ覚えがあって、
「スコープ 終了処理 指定」とかいろいろぐぐっても、なかなか見つけられなかったけど、
削除子で検索したら一発でした

288:デフォルトの名無しさん
05/11/21 18:59:33
その手のテクニックなら ScopeGuard も候補になるかな.

289:デフォルトの名無しさん
05/11/21 21:01:19
>>285
FinallyCloseHandle hFile = CreateFile(...);ではだめなのか?

290:デフォルトの名無しさん
05/11/22 00:49:20
>>288
さんくす!ScopeGuardも調べてみた

URLリンク(www.kmonos.net)
ここに実装例があったけど、ようは終了処理の関数と引数の参照を入れとくのね
勉強になります

>>289
あ、newじゃなくても良いですね
287に書いていますが、以前、どこかのwebでこの方法を見たとき
おぼろげにテンプレートを使って実現していたような覚えがあったので、
こんな風な書き方になってました

291:デフォルトの名無しさん
05/11/22 12:22:58
(数値地図から)200×200の数の行列?を読み込まし、iと、i+1と、j、 j+1で四点をとり、その4点の一番大きい値から小さい方へいくプログラムがつくれません
参照できるサイトありますか?わかる人いますか?ヒントください><
もう三ヶ月悩んでます、助けて
馬鹿な為ほんとプログラムわからないんです


292:デフォルトの名無しさん
05/11/22 12:31:21
>>291
マルチ死ね

293:デフォルトの名無しさん
05/11/22 20:16:26
指定した条件に合致したインスタンスを指すイテレータを返す関数を作るときは
その返却値となるイテレータにNULLを使っていいんでしょうか?

294:デフォルトの名無しさん
05/11/22 20:25:50
>>293
つ[std::find_if()]

295:デフォルトの名無しさん
05/11/22 20:29:51
普通はendが返るんじゃね?

296:デフォルトの名無しさん
05/11/22 20:30:05
>>293
NULLはポインタにしかない。

297:デフォルトの名無しさん
05/11/22 21:53:50
>>294
うあ、そんな便利なものが…。
使ってみます。ありがとうございました。

>>295
>>296
なるほど。
std::find_if()してきて、それがend()かでエラー判定するんですね。
ありがとうございました。

298:294
05/11/22 23:17:49
<algorithm>や<numeric>はその手のロジックの宝庫だからね。
この辺に慣れるとちょっとした集計なんかがループを書かずにできる。

299:デフォルトの名無しさん
05/11/24 00:24:57
ちと古いネタにレスします
C++は一週間ぐらい前に始めたばかりなのでよくわかってないかもしれないけど、その辺はフォローよろしくです。
>>267
FILE * からfstreamを生成する場合、FILE*のクローズの責任(というよりFILE*の所有者)は誰になるのでしょう?
古いVCだとFILE*からfstream作った時は明示的にclose()呼ぶようにとか書いてあったような気がするんだけど、これじゃあまり使い道が・・・
自分で作ったfstream(Widefilename版)だとFILE *から作ってもデストラクタでクローズしてしまいます。
fstream(_wfopen(...))みたいな使い方を想定してます。

300:267
05/11/24 07:48:28
>>299
すまん。
たまたま耳にしただけであって,そこまで詳しいところは読んでいない。
でも俺が作るとしたら後者の方式(fstreamが所有権を持ちデストラクタでクローズする)にするな。

301:デフォルトの名無しさん
05/11/24 08:35:29
gcc拡張のstdio_filebuf, stdio_sync_filebufは、closeなし。
cin, cout, cerrのfilebuf先は、main()出た後のstdin, stdout, stderrのclose任せ。

302:デフォルトの名無しさん
05/11/24 18:25:52
ofstream ofs("output", ios::out | ios::binary);
list<int> mylist;
for (int i = 0; i < 10; i++)
mylist.push_back(i);
copy(list.begin(), list.end(), ostream_iterator<int>(ofs));

これで
00 00 00 00 01 00 00 00 02 00 00 00...というバイナリファイルが出来るという
わたしの願いは裏切られ、0123456789というテキストファイルが出来た。
なぜだろうね?

303:デフォルトの名無しさん
05/11/24 18:46:50
>>302
ios::binaryってフラグは、CR+LFのようなOS依存コードをcookedではなくて
rawで書け、って意味。

std::ostream_operator<int>←って指定してるじゃん。これじゃあ << で
出力したのと全く同じ。

バイナリで書きたければwrite()を使いなせえ。

304:デフォルトの名無しさん
05/11/24 18:50:17
あ、put()でもいいよ。

305:デフォルトの名無しさん
05/11/24 18:53:43
どうしてもアルゴリズムでバイナリを出力したければ、ユーザー定義の
バイナリ出力反復子を作るか、<<を多重定義し、バイナリ出力
専用のクラスを作り、for_eachで渡すか、だなあ。

306:302
05/11/24 19:23:10
詳しくありがとう。

307:デフォルトの名無しさん
05/11/24 19:46:18
反復子のユーザ定義は、traitsの引き継ぎが面倒なので、バイナリ出力
クラスを作ってみた。

#include <fstream>
#include <list>
#include <algorithm>

class OutBin {
 std::ofstream& of;
public:
 OutBin(std::ofstream& ofs) : of(ofs) {}
 void operator()(int i) {
  of.put(static_cast<char>(i));
 }
};

int main()
{
 std::ofstream ofs("output", std::ios::out | std::ios::binary);
 std::list<int> mylist;
 for (int i = 0; i < 10; i++)
  mylist.push_back(i);
 std::for_each(mylist.begin(), mylist.end(), OutBin(ofs));
}

308:デフォルトの名無しさん
05/11/24 20:07:49
これも反復子に手を加えない一例。std::copy()が使える。

#include <ostream>
#include <fstream>
#include <list>
#include <algorithm>
#include <iterator>

class OutBin {
 int j;
public:
 friend std::ostream& operator<<(std::ostream& os, const OutBin& o);
 OutBin(int i) : j(i) {}
};

std::ostream& operator<<(std::ostream& os, const OutBin& o)
{
 os.put(static_cast<char>(o.j));
 return os;
}


int main()
{
 std::ofstream ofs("output", std::ios::out | std::ios::binary);
 std::list<int> mylist;
 for (int i = 0; i < 10; i++)
  mylist.push_back(i);
 std::copy(mylist.begin(), mylist.end(), std::ostream_iterator<OutBin>(ofs));
}

309:デフォルトの名無しさん
05/11/25 07:26:24
私は、fstream系をデバッグトレース出力にしか使わないなぁ。
とりあえずトレースしたいときは、色んな構造体に対して<<演算子がオーバライドされてると、便利だ。
でも、一般のファイルを読み書きする時は専らcstdioを使う。
皆さんはどう?

310:デフォルトの名無しさん
05/11/25 08:30:44
cstdio を使う理由なんて、互換性以外に何があるんだ。
使いわけたりしねぇよ…。

311:デフォルトの名無しさん
05/11/25 09:14:02
fstreamって何でこうもまあ低速なの?

312:デフォルトの名無しさん
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
さすがにそれはどうかとw
確かに俺も毎年4月は確認するけどさwww

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の勉強を始めて・・・何故か本の真ん中からはじめたので右も左もわからず・・・・

って感じです。今までネットワークエンジニアとして修行していたのでプログラミングは、つぅあっパリですw

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
1.c_str()は'\0'が途中にあるとまずい
2.size()とともに用いればまずくない
3.そういうときはc_strじゃなくdataを使う
4.ヌル終端文字列を前提とした既存のC関数に渡すときc_str()のほうが安全
5.1に戻る


446:デフォルトの名無しさん
05/12/17 20:40:22
>>439の実証コードはまだですか?
>>439の正しさが確認されないことには、
議論が進まないのでなるべく早目にお願いします。

447:デフォルトの名無しさん
05/12/17 20:44:06
>>445
多分、3.は必要ないから、無限ループには陥らない。

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
懐かしいなw

467:not 463
05/12/18 01:03:25
そりゃそうでしょ。
「実行ファイルのサイズが10倍になる」を受けてるレスだから。

468:デフォルトの名無しさん
05/12/18 01:12:09
URLリンク(www.google.com)

469:デフォルトの名無しさん
05/12/18 01:30:19
>>468
ワロスwwwww

470:デフォルトの名無しさん
05/12/18 01:36:26
懐かしさと共にワロスwwww

471:デフォルトの名無しさん
05/12/18 01:45:39
自作自演乙

472:デフォルトの名無しさん
05/12/18 02:03:26
>>471 がどれを自作自演と言いたいのか判らない。

473:デフォルトの名無しさん
05/12/18 05:32:51
だってこのスレに書き込んでるの俺一人しかいないしw

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
よくわからん流れだが
500は頂いとくよ

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だけだし。


次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

4274日前に更新/228 KB
担当:undef