【C++】STL(Standard Template Library)相談室 4at TECH
【C++】STL(Standard Template Library)相談室 4 - 暇つぶし2ch481:デフォルトの名無しさん
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だけだし。

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
簡単で標準的なスマポを標準テンプレートライブラりーで
教えてくださいって、既にテンプレートを貼ってあったら
ごめんなさい。

ちなみに、紅白の大鳥はスマップです。←見ねーよ
戦後60年を見るね。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)
>コンパイルがどう見ても通らないソースなんだが。
>何を言いたいんだ?
某のコンパイラは通らないか、ソースが間違っているのですか。
ついでにVC6 VC2005での問題点も指摘してください。



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
600

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として
ダウンロードされています。

 サイトからダウンローダーを起動しているHTMLは以下の通りでした。

  location.href = "hangXme://URLリンク(gamestring.hangXme.co.jp:10000)なんちゃら";

 試しに【ファイルを指定して実行】で hangXme: と実行してみると、該当EXEが起
動します。これはプロトコルとして登録されているのでしょうか?よく分からないので
すが 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
コンテナに位置と大きさを持った物体を格納してます。
物体の数が1万以上あるからいちいち衝突判定をしていると遅くなるので、
どの物体とどの物体が接触しているという情報を記録しておこうと思いました。
要素のアドレスを使おうと思ったのですが、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
このおっさんの名前見るたびに、
インリンの顔が浮かぶ。
なんかM字ビターンに似てねぇ?

679:デフォルトの名無しさん
06/01/29 13:30:48
オマイラ本人がいないからって言いたい放題だなw

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
だったら禿がこのスレ見たら泣くな
日本語も分かりそうだしw

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
関係ない。「例外安全」の意味わかってんのか?

771:デフォルトの名無しさん
06/02/22 07:02:16
>>769
キャッチ漏れがあっても最後に確実に検出できるのがいいとこでそ。

772:デフォルトの名無しさん
06/02/22 07:10:09
関数内でエラーを拾った場合に、メンバ変数なり引数変数なりを
関数呼び出し前の状態に戻しておいて、処理が呼ばれなかったことにしつつ
例外を投げるのが例外安全だっけ?


773:デフォルトの名無しさん
06/02/22 07:32:38
>>772
それは例外安全性のレベルが与える保証のうち、強い保証というもの。

774:デフォルトの名無しさん
06/02/22 08:42:51
>>772
URLリンク(www.research.att.com)
URLリンク(public.research.att.com)
URLリンク(public.research.att.com)
URLリンク(public.research.att.com)

用語を知るってのは、単なる記憶力の問題じゃなくて、
基礎概念を整理して理解するってことにつながるから、
URLリンク(www.research.att.com)にあることくらいは理解した方がいい。

英語苦手でも、簡単な英語で書かれているから、翻訳ソフト併用で問題なく読めるはず。

775:デフォルトの名無しさん
06/02/22 08:44:20
Deep C++にも例外の記事があったような気がしたがどうだっけ?

776:デフォルトの名無しさん
06/02/22 08:47:35
手元に 「Exceptional C++ (訳本)」 があるので、
例外中立と例外安全のところ読み返しときます。

777:デフォルトの名無しさん
06/02/22 08:47:42
>>775
あれは連載の途中で間違いの訂正が入っていたりするんで
途中だけ読むようなことは危険。
通して読めば、例外への誤解~理解を追えるので有益。

778:デフォルトの名無しさん
06/02/22 09:03:16
例外中立も例外安全も知らずに
例外を使っていたオレ。

779:デフォルトの名無しさん
06/02/22 09:35:50
Schmidtってちょっととぼけたところあるからな。
筆量はすごいんだが。

780:デフォルトの名無しさん
06/02/22 09:39:44
>>752はやっぱり変な気がする。
最終的に例外キャッチしない場所だったら、at使うよりも、
デバッグ版のSTL使うとか、assert入れるとか、デバッグ版とリリース版で[]とatを切り替えるとか
するのが筋でなかろうか。
まぁ速度気にしないならどうでもいいけど。

781:デフォルトの名無しさん
06/02/22 09:56:15
>>780
最終的に例外をキャッチしない場合でも範囲オーバー時の動作が違うわけで。
operator[]() で範囲オーバーしたら未定義動作。
at() で範囲オーバーしたら terminate() 。
環境によってはこれだけで十分な理由になり得る。

782:デフォルトの名無しさん
06/02/22 14:49:38
あー確かに。「誤動作即再起動」なプログラムには充分意味があるよ。
U/I持ってたらそうはいかないんだろうけど。

783:デフォルトの名無しさん
06/02/22 17:40:41
vector<double> a(n),b(n)
の2つの vector があって、
sort(a.begin(),a.end()) とsort をしています。
このとき、a の並び替えと全く同じ順番になるように
b も並び替えたいのですが、どうすればいいでしょうか?
class x{
double a
double b
firend operator<(const x&, const x&)
};
のような構造にして vector<x> c を作り sort(c.begin(),c.end());
とやればいいのは分かるのですが、a と b はメモリ上に
連続して配置する必要があるので、この方法は使えません。
いいアイデアがございましたら、ぜひよろしくお願いいたしますm(__)m


784:デフォルトの名無しさん
06/02/22 18:11:01
aのsortに合わせてbの要素も入れ替える様、sortを修正しろ。

a,bが小さいなら、class x { double a; int seq; } でseqに順番入れてソート、
bをseqみながら入れ替え。

785:デフォルトの名無しさん
06/02/22 18:19:03
>>783
boost::zip_iterator + a だけを見る比較
でいけるんじゃね?

786:783
06/02/22 18:25:56
レスどうもありがとうございます。
STL の sort をどこかに copy して修正すればいいのでしょうか?
STLの改造は今までやった事がないので、よく分からないのですが、
sort 命令に相当する source をSTLの中から探し出して、
それを改造し、自前で修正し、新たなソースファイルに
するということでしょうか?それともsort 文だけ
再定義する方法があるのでしょうか?

787:783
06/02/22 18:28:37
786は784へのレスです。
>>785
そんなのがあるのですか!boost::zip_iterator というのは
使ったことがなかったのですが、ぜひ勉強してみます。
やはりSTL だけでスマートにやるのは難しいでしょうか?

788:デフォルトの名無しさん
06/02/22 18:36:48
>>786
sortを修正すると言うより、sortに渡す関数オブジェクトを作れと言うことだろう。

789:デフォルトの名無しさん
06/02/22 19:32:27
関数オブジェクトによるソートといえば、
VC6のstd::list::sort()は欠陥で有名だよな。
std::sort()は大丈夫だけど。

790:デフォルトの名無しさん
06/02/22 19:47:39
xをsortしてから、a,bに全要素コピーし直す…
空間的にも時間的にも無駄が多いが

sortを自分で書くしかないか?
std::sortをコピペしてきて
swapの部分だけ二重にするとか

この2通りしか思いつかない

791:デフォルトの名無しさん
06/02/22 19:55:17
aのソート結果を使ってコピーする関数オブジェクトを作ってbからbNewにコピーしたら?

792:783
06/02/22 19:55:36
>>788
レスありがとうございます。
790さんが言われるように swap 自体を書き換えないといけない
ような気もするのですが、いかがでしょうか?

793:783
06/02/22 20:25:16
>>791
すみません、関数オブジェクトを使い慣れていない初心者でして、
考えてみたのですがよく分かりませんでした。具体的に
どのようにすればよろしいでしょうか?

794:デフォルトの名無しさん
06/02/22 20:31:27
>>790
> xをsortしてから、a,bに全要素コピーし直す…
> 空間的にも時間的にも無駄が多いが

これが一番簡単だよ
vector<x> tmp(n);
として、tmp[i].aとtmp[i].bに、a[i]とb[i]をすべてコピー
つぎにtmp[i].aでtmpをソート
a[i]とb[i]にtmp[i].aとtmp[i].bをすべてコピーする

795:デフォルトの名無しさん
06/02/22 20:55:42
>>789
VC6はそういうの苦手なの有名じゃん

796:デフォルトの名無しさん
06/02/22 21:01:24
std::sort(pair_iterator(a.begin(), b.begin()), pair_iterator(a.end(), b.end()));

で、両方のイテレータを操作してくれるような
イテレータアダプタ pair_iterator を作ればいいんじゃね?

797:デフォルトの名無しさん
06/02/22 21:18:41
>>796
それはsort側で両方の要素を同時にswapできるのか?
iteratorの指す先は単一の要素の気がするが

798:797
06/02/22 21:26:45
std::swapを特殊化すればできるかもしれないが、
前スレ
スレリンク(tech板)
の議論によれば、
std::sortがstd::swapを使用する保証はないらしい

799:デフォルトの名無しさん
06/02/22 21:36:20
>>795
苦手て(w

800:デフォルトの名無しさん
06/02/22 22:08:43
>>799
んじゃ正確に

ダメぽ

801:783
06/02/22 22:50:23
>>798
なるほど、そうですか。。。
>>794 の方法や、>>784 の class x { double a; int seq; } の方法で
地道にやる事にします。sizeof(double) > sizeof(int)なので、転送する
バイト数が少ない int seq の方法が有利かも。
いろいろとどうもありがとうございましたm(__)m > 皆様


802:デフォルトの名無しさん
06/02/22 23:10:09
配列インデックスの配列 vector<size_t> c を作って、
比較関数に a[c[i]] < a[c[j]] のようなものを渡して sort() 。
あとは出来上がった c に従って a, b を並べればいい。
ダメかな?

803:デフォルトの名無しさん
06/02/22 23:13:40
index table (permutation) から実際の配列をソートしなおす
アルゴリズムって結構面倒だったような

804:デフォルトの名無しさん
06/02/22 23:15:46
最適化は後からやればいいんだよ

805:デフォルトの名無しさん
06/02/22 23:24:38
>>803
テンポラリ使えば簡単。

806:783
06/02/22 23:34:43
>>802 >>805 そうですね。この方法がベターな気がします。
どうもありがとうございました。

>>803 あくまでも tmp を使わない方針で、index table から配列を
ソートしなおすアリゴリズムを実装する位なら、最初から自前で
直接 sort する関数を作ってしまう方がよさそう(w


807:デフォルトの名無しさん
06/02/23 02:01:07
車輪の再発明をして、STLとのパフォーマンス差に愕然としないと、
一流のプログラマにはなれませんよね?

808:デフォルトの名無しさん
06/02/23 02:09:05
>>807 先にソースを読んで悟ることができる人もいるだろう。

809:デフォルトの名無しさん
06/02/23 02:12:13
プログラムを書くのも大事だけど、人のソースを読むのもかなり大事なんだよな
能力を高める秘訣については俺も知りたいもんだけど

810:デフォルトの名無しさん
06/02/23 08:09:54
人は、「vectorなんて初心者向けだろw」とタカをくくって、後で間違いに気づく。

811:デフォルトの名無しさん
06/02/23 09:56:52
真の初心者にはstd::map<long, T>を使わせるべき。

812:デフォルトの名無しさん
06/02/23 10:45:02
再発明した車輪の改良をして、STLとのパフォーマンス差に優越感を抱いた後で
例外安全とか柔軟性の差に愕然としないと一流のプログラマにはなれません

813:デフォルトの名無しさん
06/02/23 10:48:28
初めて出会った時からSTLにどっぷり依存してるから、
STL使わないという人を本気で不思議に思う。

814:デフォルトの名無しさん
06/02/23 11:03:33
初期の漏れ
 どうでも良いところをstl任せにできるから、
 重要な部分のチューニングに時間取れてウマー!

今の漏れ
 パフォーマンスはどうでも良いのでstlで出来ることは非効率でも全てstl任せ。
 その分上位構造として複雑なアルゴリズムで難しい処理が実装できてウマー!

特定の処理の実行速度だけ見ると昔の漏れの方が優秀・・・

815:デフォルトの名無しさん
06/02/23 11:09:10
STLは、フレームワークでもあるから、
自前特定領域チューニングコンテナを作る時にも設計の手間が大幅に省ける。
ステファノフ万歳

816:デフォルトの名無しさん
06/02/23 11:29:14
>>814
STL使用コードを低レベルなバッファアクセス並みに高速化できないのは、単に君が努力不足だから。

実体コンテナを使うだけでなく、その各要素へのアドレスvectorを利用すれば、
いくらでも低レベルなバッファアクセス並みの速度にできる。

817:デフォルトの名無しさん
06/02/23 11:38:55
sort()がswap()所以で遅いというなら、ポインタ配列に入れてCライブラリのqsort()すればいいだけ。
STLだと遅くなるとか言ってる奴は馬鹿丸出し。

818:デフォルトの名無しさん
06/02/23 11:42:52
>>816
なるほど。んではちょっと教えて欲しいんだけど、
「高々N個程度の物を納める可変長配列
 (ただしNは小さくて、全体をスタックにも取れる)」
ってのはどう効率的に書けますか?

vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・

やっぱり↓こういうのをちゃんと作るのかな。
一度作れば汎用的に使えそうだし。
URLリンク(www.open-std.org)

819:デフォルトの名無しさん
06/02/23 11:44:47
boost 使えばいいのか・・・

820:デフォルトの名無しさん
06/02/23 11:54:29
>>818
>vector< int > hoge(); hoge.reserve(N); だと効率悪いし・・・ 

は?vectorのせいじゃなくて、動的メモリを確保するタイミングが悪いだけだろ。
STLコンテナ使用をやめてallocやnewで記述したとしても同じことだ。
設計の段階から見直すことが先だろう。
同じバッファが再利用できないか、つまりは、スコープの見直し。

821:デフォルトの名無しさん
06/02/23 11:57:33
boost::ptr_container ?
早くこれにもシリアライザを用意して欲しいな。
まぁシリアライザだけ自分で書いてもいいけど。

822:デフォルトの名無しさん
06/02/23 11:57:38
>>818
Nが固定ならvector(size_type n)を使おうよ…

823:デフォルトの名無しさん
06/02/23 12:03:27
>>820
再利用できないとき、
あるいはしたくないときにはどうすればよいのか教えてください。

特にマルチスレッドのプログラム(やスレッドセーフなライブラリ)の場合
なかなかそう都合よくは行かないことも多くて。

824:デフォルトの名無しさん
06/02/23 12:05:41
>>822
それだと最初からサイズNじゃない?
>vector< int > hoge(); hoge.reserve(N);
と意味が違うような・・・

というか(スレ違いだけど) boost::array<int, N> hoge; で解決。

825:デフォルトの名無しさん
06/02/23 12:08:14
>>824
あ、やっぱりboost::array は完全固定サイズだから、
「高々Nの可変長」ってのとは違うような・・・

寝ます。

826:デフォルトの名無しさん
06/02/23 12:09:01
>>824
何言っているか理解不能。
お題をちゃんと示せよ。

827:デフォルトの名無しさん
06/02/23 12:12:29
>なかなかそう都合よくは行かないことも多くて

多いか?
不可能であると頑なに決め付ける根拠が希薄なわけだが。

828:デフォルトの名無しさん
06/02/23 12:22:23
「高々N」は「上限がN」ということなので、上限固定として扱って問題ないと思うが、
「高々N」とはどういう意味で使っているのか?

829:デフォルトの名無しさん
06/02/23 13:28:16
もう面倒だからvalarray使えや

830:デフォルトの名無しさん
06/02/23 13:34:15
多分capacityが不変でsizeが可変なvector風コンテナのことを言ってるんだと思う。

831:デフォルトの名無しさん
06/02/23 13:57:40
だったらvectorでいいような。

832:デフォルトの名無しさん
06/02/23 13:59:10
いや、vectorだとスタックに取れない。

833:デフォルトの名無しさん
06/02/23 14:01:50
上限はそうだけど、なるべくメモリ消費したくないのでは?

834:デフォルトの名無しさん
06/02/23 18:56:02
自分でスタックに確保するアロケータを作ってそいつをstd::vectorに渡せばいけるのでは?
と思ったが、標準のコンテナに渡せるアロケータの要件を守れなさそうな気がする。

835:デフォルトの名無しさん
06/02/23 19:20:58
そこで、std::basic_string<Hoge>。
VC8だと。16バイトまではstackに確保してくれる実装になってた。

836:デフォルトの名無しさん
06/02/23 19:48:35
>>835
basic_stringは制約が・・・

837:デフォルトの名無しさん
06/02/23 23:58:27
>>834
allocate()でalloca()使ったからといって問題になることはないよ。

838:デフォルトの名無しさん
06/02/24 11:28:44
URLリンク(msdn.microsoft.com)
>セキュリティに関するメモ Windows XP では、try/catch ブロック内で _alloca を呼び出した場合は、catch ブロックで _resetstkoflw を呼び出す必要があります。

VC限定だけど、こんなへんてこ仕様の非標準関数はあまり使いたくない

839:デフォルトの名無しさん
06/02/24 11:45:02
べつにallocaなんて使わなくても、内部に配列を抱え込めば済む話じゃ。

840:デフォルトの名無しさん
06/02/24 11:52:01
まあ「高々N」だからな。

841:デフォルトの名無しさん
06/02/24 11:54:41
>>838
変な仕様というか、allocaの引数が可変だから、
スタックチェックに引っ掛からないように調整し直す必要があるんだろ?
通常終了時は関数出口辺りで調整するコードを実行するんだろうけど。

842:デフォルトの名無しさん
06/03/08 19:40:47
STLで環状リストってありますか?
++iteratorでぐるぐる回るやつが理想です。

843:デフォルトの名無しさん
06/03/08 20:41:51
ないです。

844:デフォルトの名無しさん
06/03/08 20:45:42
++iteratorの代わりに、
++iterator; if (iterator == ringList.end()) iterator = ringList.begin();するだけだろ。

845:デフォルトの名無しさん
06/03/08 21:12:04
>>843-844
レスありがとうございます。やはり無いですか。
>>844で示されたようにすればいいんですが、環状リストとして扱っているということを
コード上にも(アルゴリズム的に)反映させたいと思ってたので残念です。

846:デフォルトの名無しさん
06/03/08 21:20:33
>>845
844の動きをするイテレータを自作すればいいと思うのだが。

847:デフォルトの名無しさん
06/03/08 21:43:24
>>844みたいなことを内部的にしたいが為だけにiteratorのクラステンプレートを
自作するのは、まぁ、億劫な話だわな。

848:デフォルトの名無しさん
06/03/08 21:58:09
そこでboost iteratorsですよ。

849:デフォルトの名無しさん
06/03/08 21:58:51
そんなあなたにBoost.Iterator

850:デフォルトの名無しさん
06/03/08 22:01:06
つboost::iterator_adaptor

851:デフォルトの名無しさん
06/03/08 22:04:09
>>848-850
おまえら、合体しる。

852:デフォルトの名無しさん
06/03/09 01:20:26
>848-850をbindしようと思います

853:デフォルトの名無しさん
06/03/09 08:18:30
>>845
添字を循環させるってのはどう?
index = (index + 1) % array.size();

854:デフォルトの名無しさん
06/03/09 08:37:59
>>853
そういうことをするoperator []を持つコンテナを作るってのはどう?

855:デフォルトの名無しさん
06/03/09 08:41:18
>>854
まあ、言いたいのはそういうことです。
fetch_first, fetch_next, fetch_last で実装してもいいかも。

856:デフォルトの名無しさん
06/03/09 14:47:51
boost::iterator_adaptor で実装しようと思ったら思いの他難しいな…。

857:デフォルトの名無しさん
06/03/09 15:51:30
RandomAccessIteratorの要件を満たさないから
そこだけmpl::if_で分岐を入れる必要があるな。

858:デフォルトの名無しさん
06/03/09 15:59:35
ブーストってなんですか><?

859:デフォルトの名無しさん
06/03/09 16:22:14
そろそろ "><" を NG ワードに入れてもいい季節かな?

860:デフォルトの名無しさん
06/03/09 16:25:20
やめてください!><

861:デフォルトの名無しさん
06/03/09 22:36:15
>>857
いや,ベースとなるイテレータが RandomAccess なら満たすんじゃないですか?

862:デフォルトの名無しさん
06/03/09 23:12:35
>>834あたり
遅くなりましたが、
URLリンク(www.tantalon.com)
にある StaticAlloc ってのがそういう感じに使えそうですね。

vector::swap時のアロケータとの整合性とか考えると、
自前でコンテナ書いた方が良いという気もしてきますた。

863:デフォルトの名無しさん
06/03/09 23:23:23
>>861
うまく順序を定められない。
pとqが異なるとき、[p,q)も[q,p)も空でない区間だから、
p < q かつ q < p である必要がある。

864:861
06/03/10 00:30:39
>>863
う~ん,これ設計として大別して2つあるんですね.
今,対象とする範囲の大きさを仮に10としたときに,
it と it + 10 が同値である (it == it + 10 が常に true) というあり方と,
it と it + 10 が同値でない (it == it + 10 が常に false) というあり方の2つです.

自分としては後者の設計を想定していて, it と it+10 はイテレータとしては同値ではなく
単に dereference の結果「たまたま」同じ値が返ってくるだけという考え方です.
この立場ではイテレータアダプタは readable だが writable ではない,となります.
こちらの設計ではイテレータアダプタオブジェクトが,現在の場所を指す
ベースイテレータオブジェクトと何らかのオフセット値を同時に保持する必要があります.
(ただし,ベースが RandomAccess なら保持するのはオフセット値だけで良いです)

多分 863 さん的には前者の立場かと思うんですが,前者の場合
全順序性のような RandomAccess 固有の問題に限らず,
一般に std::distance の意味が一意に定まらず,混乱すると思うので
(最小の正の値を返す,といったような何らかの一貫した立場を取ることはできますが)
個人的にはちょっと設計的に微妙な感じはします.

865:デフォルトの名無しさん
06/03/10 00:54:52
>>864
なるほど、後者の設計を思い付かなかった。
こっちの方がずっと扱いやすそうだ。

866:デフォルトの名無しさん
06/03/10 08:49:14
基本的なことで質問です
STLって便利?ではなくて使ったほうが良いですか?

867:デフォルトの名無しさん
06/03/10 09:11:47
C++でSTL使うのはWindowsをマウスで操作するぐらいに自然なことだ。

868:デフォルトの名無しさん
06/03/10 09:39:06
C++でSTLを使わないのは、裸の女を見てオナニーをするようなものだ。
STLを使うのは、オナニーではなくセックスをするようなものだ。

869:デフォルトの名無しさん
06/03/10 09:44:14
初心者の君が天才でもないかぎり、どんなに頑張ってもSTLより高速なコードは書けないだろう。

870:デフォルトの名無しさん
06/03/10 10:16:35
C++はSTLを使ってこそ本領を発揮できる。

871:デフォルトの名無しさん
06/03/10 10:19:02
>>870
そこまでヨイショするほどのもんでもないと思うが。
でも、STLは使え。>>866

872:デフォルトの名無しさん
06/03/10 10:26:54
>>867
Windowsをマウスを使わずにキーボードショートカットだけで操作するのは別に非効率とは限らないが、
C++でSTLを使わないのは非効率だ。

>>868
裸の女を見てオナニーをしても不毛ではあるがセックスに伴う責任は回避できる。
しかし、C++でSTLを使うことにセックスに伴うような責任は発生しない。

>>866
まぁ、使ってみろ。いいもんだ。

873:デフォルトの名無しさん
06/03/10 10:40:29
そうなんですか・・・これから勉強か~~

874:デフォルトの名無しさん
06/03/10 11:09:03
というか、STLの知識は他の言語でも役立つだろう。
これからどの言語もSTL風のコレクションクラスを持つことになるだろうから。
実際JavaやC#でも…

875:デフォルトの名無しさん
06/03/10 11:28:25
>>874
javaのあの脳味噌が腐ったようなGenerics実装みてよくそんな希望的観測が抱けるな。

876:デフォルトの名無しさん
06/03/10 11:37:25
実装? 仕様じゃなく?


877:デフォルトの名無しさん
06/03/10 11:40:53
>>876
漏れは「仕様」より一つメタな概念としての"Generics"ってのがあって、
C++ の template やら "Java の Generics" ってのはそれの実装だ、
という(脳内で)考えてるので自然に読めますた。

878:デフォルトの名無しさん
06/03/10 11:46:05
まあ仕様の間違いでしょ。

JavaのGenericsは、特殊化なしの制約付きとしてはそれほど悪くないんじゃない?
コアなC++使いにとっては貧弱に思えるけれども。


879:デフォルトの名無しさん
06/03/10 12:21:20
JavaのGenericsは切な過ぎる。
特殊化なしの制約なんてもう耐えられない。

880:デフォルトの名無しさん
06/03/10 12:31:52
特殊化しなくちゃ

881:デフォルトの名無しさん
06/03/10 12:36:26
JavaのCollectionの内部イタレータというのも切ないな。
実装の隠蔽という面からは、あれも正しいんだろうけども。

STL.NETは公開延期だけど、やっぱりJavaよりになるんだろうな。
特殊化はC++とCLOSくらいしかないし。

882:デフォルトの名無しさん
06/03/10 13:40:43
え、特殊化ねーの?(;゚Д゚)

883:デフォルトの名無しさん
06/03/10 15:07:49
C++/CLIはgenericでなく、templateなら特殊化可能だったよ。
genericはnew制約とか余計な思想強制されるんでいらね



884:デフォルトの名無しさん
06/03/12 04:45:43
STLPortの5.0.2を使ってみたりしてるんだけど、
hash_setがなんか遅いような気がする
気のせい?

885:デフォルトの名無しさん
06/03/12 11:44:32
VC7のよりは速い

886:デフォルトの名無しさん
06/03/13 13:54:59
vectorから不連続な複数要素をインデックス指定で一度に効率よく削除するにはどうするのが一番いいんだぜ?

#include <stdio.h>
#include <vector>
#include <algorithm>

template<class T>
bool VectorErase(std::vector<T>& vt, std::vector<unsigned int>& ve)
{
 std::vector<T>::iterator    p1, p1Src, p1Dst, p1End;
 std::vector<unsigned int>::iterator  p2, p2End;
 unsigned int i, nMaxElement;

 // 削除するインデックスが配列サイズより大きいかチェック
 nMaxElement = *std::max_element(ve.begin(), ve.end());
 if (vt.size() <= nMaxElement){
  return false;
 }

 if (ve.size() > 0){
  p2 = ve.begin();
  p2End = ve.end() - 1;
  for (i = 0; p2 != p2End; ++p2, ++i){
   // 次の削除要素までコピー
   p1 = vt.begin() + *p2;
   p1Src = p1 + 1;
   p1Dst = p1 - i;
   p1End = vt.begin() + *(p2 + 1) - 1;
   for (; p1 != p1End; ++p1){
    *p1Dst++ = *p1Src++;
   }
  }

887:デフォルトの名無しさん
06/03/13 13:55:33
  // 次の削除要素がなければ、残りはコピーだけ
  p1 = vt.begin() + *p2;
  p1Src = p1 + 1;
  p1Dst = p1 - i;
  p1End = vt.end() - 1;
  for (; p1 != p1End; ++p1){
   *p1Dst++ = *p1Src++;
  }

  // リサイズ
  vt.resize(vt.size() - ve.size());
 }

 return true;
}

void main()
{
 std::vector<unsigned int> vecData;  // 対象データ
 std::vector<unsigned int> vecErase;  // 削除インデックス (要昇順ソート、ユニーク)
 unsigned int    i, nMaxData;
 nMaxData = 10;
 vecErase.push_back(0); vecErase.push_back(4); vecErase.push_back(7); // 削除インデックス作成
 for (i = 0; i < nMaxData; ++i) vecData.push_back(i); // データ作成
 VectorErase(vecData, vecErase); // 削除実行
 for (i = 0; i < vecData.size(); ++i) printf("vecData[%u]: %u\n", i, vecData[i]); // 結果表示
}

888:デフォルトの名無しさん
06/03/13 14:17:13
どうするのが一番いいんだぜ?って何語だぜ?

889:デフォルトの名無しさん
06/03/13 14:41:45
>>887
面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
#つーか、>886は効率悪そうでw
テンプレート化はしてないけどするにしても簡単でしょ。
static void VectorErase(vector<unsigned> & vecData, unsigned idx)
{
vecData.erase(vecData.begin() + idx);
}
static void VectorErase(vector<unsigned> & vecData, vector<unsigned> const & vecErase)
{
for (vector<unsigned>::const_reverse_iterator it = vecErase.rbegin(); it != vecErase.rend(); ++it) {
VectorErase(vecData, * it);
}
}


890:デフォルトの名無しさん
06/03/13 15:02:56
なぜvectorから要素を効率よく削除できるのはどうしてだぜ?

891:デフォルトの名無しさん
06/03/13 15:12:13
>面倒なことせずに、簡単に行こうよ。それでパフォーマンステストしてから効率を考えよう。
汎用の部品は最低限の最適化をしておいても損はないと思う。
とりあえず、>>889はO(n^2)なので問題外じゃないだろうか。

892:デフォルトの名無しさん
06/03/13 15:25:50
std::remove_ifは?

893:デフォルトの名無しさん
06/03/13 15:51:35
>>892
std::remove_if()はiteratorが渡されないからインデックス配列を扱う用途には向いてない希ガス。

>>891
同意。しかし、vectorの要素をインデックスで削除する用途はそれほどない希ガス。

>>887
インデックスを作る段階で、std::remove_if()をいきなり実行できないのかな?

894:886@Athlon64 3000+
06/03/13 20:33:38
nicegay達、レスありがとうだぜ?
簡単に試したところ、条件次第でremove_ifと速度が入れ替わる(500~1000万件
で±数十ミリ秒程度)のですが、平均的に速そうでかつムラがなさそうなので、
データクラスに削除フラグを持たせてremove_ifを使う方向で考えてみます。


895:デフォルトの名無しさん
06/03/13 20:52:14
>データクラスに削除フラグを持たせて
ほんとにそんな侵入的な方法が必要なのか?
すごく気持ち悪いんだが。

もちろん、おまえが良いというならそれで良いんだけど。

896:デフォルトの名無しさん
06/03/13 21:37:34
要素がスマートポインタ的な実装の場合、テンポラリvectorに生き残りを
コピーしてvectorごとswapするのが速い悪寒だぜ。

897:デフォルトの名無しさん
06/03/14 00:35:14
日本語でおk

898:デフォルトの名無しさん
06/03/14 01:18:36
・削除するインデックスのリストはソート済
・削除する要素が存在しないときの最適化はしていない
という条件だとこんな感じ?
まだまだ汎化&最適化できそうだけど、もういいや。
void VectorEraser( std::vector<int>& target, std::vector<int>& erase)
{
 std::vector<int> result;
 std::vector<int>::iterator tb(target.begin());
 std::vector<int>::iterator ti(target.begin());
 std::vector<int>::iterator te(target.end());
 std::vector<int>::iterator ei(erase.begin());
 std::vector<int>::iterator ee(erase.end());
 while((ti != te)&&(ei != ee)) {
  if (*ei == std::distance(tb, ti)) {
   ++ei; ++ti;
  } else {
   result.push_back(*ti);
   ++ti;
  }
 }
 result.swap(target);
}

899:デフォルトの名無しさん
06/03/14 01:23:20
>>894
niceなguyとniceなgayは微妙に違うんだぜ。
両方兼ねている人もいるだろうけど。

900:デフォルトの名無しさん
06/03/14 06:54:23
>>898
それだとtargetとeraseのサイズに比例した一時領域を食うからアンマリ良くないと思う。
コピーを作るより破壊的にコンテナに直書きしていったほうがコストが抑えれる。

void VectorEraser( std::vector<int>& target,const std::vector<int>& erase) 
{ 
    std::vector<int>::const_iterator ei(erase.begin());
    std::vector<int>::const_iterator ee(erase.end());
    std::vector<int>::iterator di(target.begin());
    std::vector<int>::iterator tb(target.begin());
    std::vector<int>::iterator ti(target.begin());
    std::vector<int>::iterator te(target.end());
    for(;ei != ee;++ei) {
        std::vector<int>::iterator x(tb);std::advance(x,*ei);
        di = std::copy(ti,x,di);
        ti = ++x;
    }
    di = std::copy(ti,te,di);
    target.resize(std::distance(target.begin(),di));
}

901:デフォルトの名無しさん
06/03/14 11:31:03
>>900
ループの最初の一回を外に出してコピーしないようにすると
より高速になりますね。
最初にif (ei != ee)が要りますが。

902:デフォルトの名無しさん
06/03/16 18:36:16
質問失礼します。
現在構造体にSTL stringのメンバを複数おいて利用しているのですが、
どうもメモリリークが起きてしまいます。
起きているのはそのメンバに有効な文字列(1バイト以上)が入ったときのみのようです。
入るのはoperater =によってです。
Debug実行の後の出力では
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {68} normal block at 0x00CD2568, 32 bytes long.
と、出力されています。構造体にstringは使用出来ないのでしょうか?
ご教授お願いします。

903:デフォルトの名無しさん
06/03/16 18:38:55
>>902
レガシーな構造体のつもりで安直なメモリ転送したりメモリコピーをしていなければ大丈夫。

904:902
06/03/16 18:44:46
memcpy Zeromemory等の関数は使用してないです。
もちろんstring内データ直アクセスも。
構造体内に構造体が3つあってそこにもstringやらintやら混ざってるのが悪いのでしょうか。
・・・そんなわけないですよねぇ・・・。
ちなみにSTLは.NET2003標準のやつです。

905:902
06/03/16 18:56:06
度々すみません。情報追加です。
構造体を使用しているのはクラスのpublicメンバで、
m_typData.strA = "aaaaaaaaaaaaaaaa";
等としたところでリークしていました。また、上記例から文字が一文字減るとおきませんでした。
その直前までsrAは未初期化の状態です。

906:デフォルトの名無しさん
06/03/16 19:06:34
>>904
その構造体を free で解放してたりしませんか?

907:902
06/03/16 19:11:14
>>906
していません。したら落ちます、構造体自体はそのまま
TYPE_DATA typData; の様な使い方をしているので。
string以外のメンバはint DWORD SIZE RECT POINT さらに構造体などですが、
いずれもメモリ操作系の関数は使用しておらず、すべてoperater =や+=等ばかり使用しています。

908:デフォルトの名無しさん
06/03/16 19:27:56
とりあえず再現性のある最小のコードを貼れ。
話はそれからだ。

909:902
06/03/16 19:34:37
最小ソースです Win32 Console VC++.NET 2003で作成

// CRTデバッグ
#define _CRTDBG_MAP_ALLOC

// CRTデバッグ
#include "stdlib.h"
#include "crtdbg.h"

#include <string>
using namespace std;
struct TYPE_A
{
string a;
};

void main(void)
{
TYPE_A typData;

typData.a = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";

// CRT メモリリーク確認
_CrtDumpMemoryLeaks();
return;
}


910:デフォルトの名無しさん
06/03/16 19:39:07
>>909
typDataがスコープから抜ける前にリークチェックしてるよ

911:デフォルトの名無しさん
06/03/16 19:41:20
あと
・mainの戻り値にvoidはやめなさい。
・stdlib.hやcrtdbg.hがなぜ""で囲まれてるのか?


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