【C++】template 統合スレ -- Part4

C++ のジェネリックプログラミングの話をしましょう。
以下のスレッドを統合するスレです。

STLスレッド
Part1 http://pc.2ch.net/tech/kako/1004/10042/1004287394.html
Part2 http://pc3.2ch.net/tech/kako/1026/10267/1026793823.html

【C++】Boost使い集まれ！
http://pc3.2ch.net/test/read.cgi/tech/1033830935/ (html化待ち?)

Generic Programming with C++ Template
http://pc.2ch.net/tech/kako/1008/10085/1008593126.html
【C++】template 統合スレ -- STL/Boost/Loki, etc.
http://pc2.2ch.net/test/read.cgi/tech/1037795348/
【C++】template 統合スレ -- Part2
http://pc2.2ch.net/test/read.cgi/tech/1047978546/ (html化待ち)
【C++】template 統合スレ -- Part3
http://pc5.2ch.net/test/read.cgi/tech/1066493064/

関連スレ、その他リンクは >>2-5 あたりに。

関連スレ
C++相談室 part29
http://pc5.2ch.net/test/read.cgi/tech/1082047479/l50

リンク
STLPort
　http://www.stlport.org/

boost
　http://www.boost.org/

Loki
　http://freshmeat.net/projects/lokilibrary/
　http://www.geocities.com/rani_sharoni/LokiPort.html

ISO/IEC 14882
Programming languages -- C++
　http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
　http://www.kuzbass.ru/docs/isocpp/

boostに関する有名な日本語サイト

・boost info
http://user.ecc.u-tokyo.ac.jp/~g940455/wp/boost/

・Hattareme Programming
http://www.dodgson.org/lab/hat/

・Let's boost
http://www.kmonos.net/alang/boost/

・Regex
http://www.s34.co.jp/cpptechdoc/article/regexpp/

・Boostを使おう
http://www.emaki.minidns.net/Programming/tools/Boost/

またやってしもた。Part5立てる時は直してね。

【C++】Boost使い集まれ！
http://pc2.2ch.net/test/read.cgi/tech/1033830935/

参考図書

C++ Templates
　http://www.amazon.com/exec/obidos/ASIN/0201734842/
Boost C++ Libraryプログラミング(2004/5/10発売予定)
http://www.kmonos.net/wlog/38.php#_1245040501

今のうちに参考図書追加して宣伝してやるぜ！！ヒヒヒヒヒ・・・

・STL
Generic programming―STLによる汎用プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756134416/
Effective STL
http://www.amazon.co.jp/exec/obidos/ASIN/4894714108/

・テンプレートによるデザイン
Modern C++ Design
http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/

こんにゃのも。

・STL
STLによるコンポーネントデザイン
http://www.amazon.co.jp/exec/obidos/ASIN/475613422X/

ネタ無しage

教えてください。

class B;

template<typename T> class D : public T {
public: void foo(int x) const {
// ここから
if (T != B) {
T::foo(x);
}
// ここまでをコンパイル時に判断したい
};

のですが、どういった方法があるでしょうか?

>>9
template <typename T> struct IsB { enum { val = 0 }; };
template <> struct IsB<B> { enum { val = 1 }; };

template <typename T, bool t_isB> class D : public T {
public: void foo(int x) const { T::foo(x); }
};

template <typename T> class D<T, false> : public T {
public: void foo(int x) const {}
};

>>10
ありがとうございます。

書き忘れたんですが、D<T>::foo()の問題の部分の前後には実際にはいくらか
コードが入る予定です。なので、できればD<T>自体の特殊化ではなく、foo(の
一部)だけの変更でどうにかしたいのですが無理でしょうか?

>>11
1. class D のさらに基底クラス用意して、共通処理を protected メンバ関数にする。
2. D::foo() から、その protected メンバ関数を呼ぶ。
3. protected メンバ関数では this ポインタを static_cast<D*>(this) として D* に
　キャストすることで、D クラスのメンバ変数などを操作する。

>>11
template<typename T> class E: public T {
protected: void foo(int x) const {T::foo(x);}};

template<> class E<B>: public B {
protected: void foo(int x) const {}};

template<typename T> class D: public E<T> {
public: void foo(int x) const {E<T>::foo(x);}};

>>6
> ・テンプレートによるデザイン
> Modern C++ Design
個人的に凄く良書だとおもう

>>14
何をいまさら・・・
ところでboost本ってもう書店に並んでるの？

>>15
タダの宣伝だろ。
クソが。

>>12
なるほど（・∀・）！
ありがとうございました。

都内で売ってるトコあるならﾌﾂｰに欲しいが。

5/10発売って書いてあるようだけど。
cbook24もamazonもまだヒットすらしないな

部屋にModern C++ Designがあるので読み返して見ている。
いや正直俺には難し過ぎ・・・orz

struct A
{
　template<int I,typename T> A& operator=(const T& t)
　{
　　return *this;
　}
};

int main()
{
　A a;
　a = 1
　return 0;
}
代入演算子のどこに<100,int>って書けばいいか教えてください

>>21
a.operator=<100,int>(1);

>>19
だよねー。
ISBNで検索しても引っかかってくれない。

�d�j

結局 static const int と enum はどっちがベターなの？
規格上および実際のところ。

↓Blitzの質問

今2chで話題のＡ何とかの中の人のＭＦＣ講座！
みんないっちゃだめだよ〜ｗｗｗｗ
http://www.geocities.jp/aransk88/contents4.html

>>25
static const int の替わりに enum を使うのは
実装の遅れたコンパイラに対応するためのハック。

規格上は別物。
実際のところはなるべく意味の適するものを使うのがベター。

>>28
> static const int の替わりに enum を使うのは
> 実装の遅れたコンパイラに対応するためのハック。
factorial<>とかpow<>とか、よくあるcompile time computationに適したのはどっちでしょう?

>>29
enum はとり得る値が列挙された型を定義するので、意味が適しているとは思えない。
static const int のほうが意味が適していると思う。

実際問題としても、
int で特殊化した関数テンプレートにテンプレート引数を明示せずに列挙子を渡したとき、
特殊化したバージョンにならなくて困ったりする、かもしれない。
static const では明示的に型を指定することができるので
std::size_t や bool が使えて助かることがある、かもしれない。

>>30
ありがとうございます。過去スレ(Generic Programming with C++ Template)で議論になって
結論なしだったんで気になってて。

> int で特殊化した関数テンプレートにテンプレート引数を明示せずに列挙子を渡したとき、
> 特殊化したバージョンにならなくて困ったりする、かもしれない。
なるほど。どうなんだろ。

テンプレートはものの30分くらいで理解できたけど
アロケータってのが理解できないんですが
どうしたら良いのでしょうか？

>>32
Modern C++ Designを読みましょう。
第４章「小規模オブジェクトの割り当て」当たりがお勧め。

ネット上の資料で十分だろうから、
本なんか買う前にgoogleに聞いておくべきだな。

>>34
そうかもしれん。
取り敢えずアロケータを知るために最小限学習すべき要件。

１．メンバ関数
allocate()
construct()
destroy()
deallocate()
２．ＳＴＬの提供する関数
std::uninitialized_fill()
std::uninitialized_fill_n()
std::uninitialized_fill_copy()
３．ＳＴＬの提供するイテレータ
std::raw_storage_iterator

最低限これだけ知っていれば自分でアロケータを書く事が可能
になる。

そしてrebindの仕様に絶望するようになれば一人前。

>>36
typedefテンプレートか・・・・

ま、俺様コンテナを作る時、new/deleteの速度と効率に不満がある
人は(大抵不満があるはず)アロケータを一度書いてみよう。それか、
boostにもpool_allocという小規模チャンク用の高速アロケータがある。
メモリプールクラスを一から書けと言われるとぞっとする。

>>36
確かに(w

>>37
pool_allocatorって便利やね
boostを惚れ直しマスタ

>>39
俺もboost::pool_allocatorを使って標準STLのパフォーマンスが
どれくらい上がるか実験してミターヨ。

compiler : gcc3.3.3(MinGW)、STL library : STLport4.6.2

std::vector : 約60％up (pool_allocator) push_back()
std::list : 約26％down (fast_pool_allocator) push_back()
std::deque : 約100％down (pool_allocator) push_front()
std::deque : 約300％down (pool_allocator) push_back()

push_back()、push_front()だけの比較だけど、いまいちだな。
vectorは改善されたが他のコンテナは却って遅くなる。
それだけSTLportのアロケータは優れているって事か。
いや、STLportが自分のアロケータ用に最適化されていると
言うべきか。どなたか追試ヨロ。

ソースはここに置いておいた。「間違っとるぞ！」「こう書けば速いのに」
等レス希望。
ttp://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1076074304&res=9&fi=no

>>41
どのコンテナでも、内側のループ(j)を1,000や10,000じゃなくて、10^6くらいに
して比較したらどうなるかな？
それから、内側を十分回せば外側(i)は10,000も回さなくてもいいんじゃない？

アロケータの使い方を見ていたら、std::vectorの要素にコンストラクタで失敗するオブジェクト
を用いてはいけないことに気がついた。

>>41
そこの10にあげといたけど(SIZEを大きくすると)
GCCのdeque+pool_allocatorがやたら時間食うね。
サイズが分かってるときはvector+reserveが一番速くて
listはpool_allocator使った方が速い。

>>42-44
レスサンクス。10はなぜか手持ちのMinGW(3.3.3)で
cmp_rs.push_back(result(name+" cmp",( --rs.end() )->time / (--(--rs.end()) )->time *100 ));
の行が
C:\mingw\boost\pool2.cpp non-lvalue in decrement
と出るのでstd::advance()ででも書き換えてみるつもり。俺STLport使って
るから何か違うのかなと。

std::dequeは遅いねえ。push_front()は速いんだけどねえ。

--end()がエラーになるのはポインタを返す実装の場合だな。
確かboostにそのためのラッパがあったような。

template を使っていると、エラー処理をうまく書けなくなる
ことが多くならないですか？

>>46
boost::prior だね。

>>47
無いけど、例えばどんなケース？

>>43
> std::vectorの要素にコンストラクタで失敗するオブジェクトを用いてはいけない

そんなことないと思ってるんで、何故いけないのか解説きぼん。

http://www.boost.org/libs/pool/doc/interfaces/pool_alloc.htmlより
If you are seriously concerned about performance, use
fast_pool_allocator when dealing with containers such as std::list,
and use pool_allocator when dealing with containers such as
std::vector.

>>15
でも出てるけど、boost本が並んでる都内の本屋無い？
月曜発売なんだろうけど土日に読みたいんだよね、やっぱ。

>>49
俺もわからん
教えて>>43

なんでこれはコンパイルできないですか？
template<template<typename>class T,typename U>
struct X{};

template<typename T>
struct Y: X<Y,T>{};

int main()
{
　　　　　Y<int> y;
　　　　　return 0;
}
error C3200: 'Y<T>' : テンプレート パラメータ 'T' に対する無効なテンプレート引数です、クラス テンプレートが必要です。
error C3200: 'Y<T>' : テンプレート パラメータ 'T' に対する無効なテンプレート引数です、クラス テンプレートが必要です。　with　[　T=int　]

>>53
試してみたけど、Cygwin ＋ gcc 3.2 ではコンパイル通るな。
でも、標準C++準拠率が高いといわれる VC7.1 の cl でコンパイル通らなかったけど。

というか、

template<template<typename>class T,typename U>
↓
template<class T,typename U>

でいいのでは。
なんで gcc でコンパイル通るのかの方が気になる。

>>55
ん？X<Y,T>だぞ。X<T,T>じゃない。
よくみてみ。

>>53
> struct Y: X<Y,T>{};
ここで X に渡してる Y が、 template 引数を受け取った後に実体化される型 Y<T> と解釈されてしまうらしい。
解決法はわかんないけど。

珍しいワナにひっかかてますねｗ
以下が正しい書き方になります．

struct Y: X< ::Y,T>{};

>>58
> struct Y: X< ::Y,T>{};
へー。gcc3.2.2でも通った。はじめて見た。

北ーーーｗｗﾍ√ﾚｖｖ〜(ﾟ∀ﾟ)─ｗｗﾍ√ﾚｖｖ〜─ !!
罠だったのか。。。。。。。
レスしてくださった皆様ありがとうございました！！！！

>>58
どういう罠？

一応補足をば．class templateの内部でクラス名だけを書くと
実体化された型を指すことになります．

template<typename T>
class C{
// ここで`C'と書けば実体化されたCの型を表します．
// T = intで実体化されたなら，C<int>と同義になります．
};

問題は53さんのようにtemplate template引数を引き渡したいときで，
この場合，class内部から::を使って大域のクラス名を指すことによって解決できます．
ところがここにもう一つワナがあって<:がダイグラフとして認識されてしまう
（[と同じになる）ので，<と::の間にスペースが必要となり，
結果58の書き方になります．
GCCとVCのコンパイラの反応の違いは，恐らくsuper classの指定の部分を
クラスの内部と見るか外部と見るかの実装の相違から来ているものと邪推します．

template<typename T, typename S<T> >

こんな感じのをやりたいんですけど、コンパイルできません。
どう書けばいいでしょうか？

>>63
まずは日本語で表現できるかどうかやってみれ。

>>53-62
gccのバグで、3.4で修正が入ってる。
http://gcc.gnu.org/gcc-3.4/changes.html
ここで
"Inside the scope of a template class"を検索。

規格を交えた考察を。

規格の対応する項目は 14.6.1 -1-
型の名前となる条件は"when the name of the template is neither qualified nor followed by <"
とあるので、テンプレートの名前とするためには、名前を"qualified"にする必要がある。
そこで文法上の記号 qualified-id にどうにかマッチさせるために
名前空間の指定を行う必要があるわけで、かなり歪んだ表現であると言える。

しかも、ネストした名前空間内で宣言と定義を同時に行う（ごく普通の）場合、
名前空間のネストを全てグローバルからたどって指定する必要があるみたい。
宣言と定義を分ければ、
namespace xxx{ template<typename T> struct Y; }
template<typename T>
struct xxx::Y : X< xxx::Y , T > {};
using xxx::Y;
という書き方もできるようになるが、歪み方が変わったぐらいにしかならない。
一応、カット＆ペーストで名前空間を引っ越すことができるかな。

ここは template キーワードで修辞できるようにしてほしかったなぁ。
struct Y : X< template Y , T > {};
Defect Reportでも漁るか・・・。

こういうの見るとtemplateなんてC++のダメさを隠してる
だけなんだと痛感する

struct Y: X< Y,T>{};
struct xxx::Y : X< xxx::Y , T > {};
って自分で自分を定義してからだめな気がするんだが、
違うのかな？

>>67
新しい世界を開拓しているフロンティアなわけだが。

>>68 ﾁｶﾞｳﾖ

Expression Template についてわかりやすく解説してる書籍ありませんか？
それか、解説してくれるとありがたいんですが
目的は一応わかりました。

>>71
C++ Templates - the complete guide

Defect Report見てきた。
dkuugはなんか重い。
comeaucomputingに置いてある奴の方がアクセスが早いような気がしたんで、リンクはそっちに貼る。

templateキーワードを使った素敵な修辞はもちろん見当たらなかったけど、
>>62 の
> GCCとVCのコンパイラの反応の違いは，恐らくsuper classの指定の部分を
> クラスの内部と見るか外部と見るかの実装の相違から来ているものと邪推します．
これに関連するやつが見つかったのでここに記しておきます。

http://www.comeaucomputing.com/iso/cwg_defects.html#432
によると、injected class name（今回の件では>>57,>>62の言っているものにあたる）の
宣言地点はクラス定義の開き括弧のすぐ後だということになるらしい。
決まったのは2003/10のミーティングということなので、割と新しい話題のようだ。

ということは、
> struct Y: X<Y,T>{};
これで通るのが標準化委員会の意向ということになる。

逆に
template< typename T > struct A {};
template< typename T > struct B : A< B > {};
これは通らなくなり、２行目を
template< typename T > struct B : A< B< T > > {};
とする必要がありそうだ。
実際にやってみると、VC(Toolkit 2003)では両方OKで、gcc(3.3.1)では上だけエラーになる。
これはこれでまた一悶着起こりそうな予感が・・・。

そもそも"injected class name"がらみの問題が多すぎて、
本当でこれでいいのか、と心配になった。

>>72
これですか？読みやすいですか？洋書なので本屋にもなくて立ち読みすることできないんで。
http://www.amazon.co.jp/exec/obidos/ASIN/0201734842/qid%3D1084094234/249-4149864-2990714

>>74
pdfでDL(ry

>>75
いや寧ろCHM版の方が(ry

>>75
> pdfでDL(ry
あるの？

>>74
俺には結構わかりやすかったです。
東京の八重洲ブックセンターに置いたったから、もし近所なら立ち読みに行ってみるといいかも。

>>77
ある所にはあるがここにはとても書けない。hint : google

>>79
いや、売ってるの？という意味。
書籍は持っているんだが重くてな。

ｱﾏｿﾞﾇでプレミア価格ついてるんだが・・・
絶版？？

>>81
amazon.comとか紀伊国屋書店BookWebでなら注文できるみたいだよ。

>>73
ピンポイントなドキュメントで（ﾟдﾟ）ｳﾏｰです．

>>74
横から失礼．templateの基本的な文法事項から丁寧に解説してくれているので，
読みやすいと思います．後は英語が読めれば大丈夫かと．
文法だけでも複雑な場合(例えば53さんの事例もほとんどそのまんま載っています)から
C++のtemplateの文法の拡張の方向性まで網羅されており，
またtemplateの使い道も，分かりやすい例を交えてこれでもかというほど載っています．
まさにcomplete guideの名を冠するにふさわしい1冊かと．templateを極めたいなら是非．
ただ，高いのが少々難点・・・．

それにしても，templateの話題だけで500pオーバーの本が書けるC++に
末恐ろしさを感じるのは私だけでしょうか？

>>83
末恐ろしいというか単に
template って枠組みをそれまでの C++ に押し込むために
無理矢理やってるだけだよ。

何かコンピューター界って不便な所で我慢する癖が続くなあ。
６５０２にしろ８０８８にしろ、なぜかメインストリームになっているし、
Ｃ＋＋も文法的にすごく汚いのに山ほど本が出ているし。

で、なぜかすっきりした構造のハードウェアにしろ言語系にしろ、
あまり流行らずにマイナーになってしまうような。

>>85
そりゃ、プロセッサにせよ言語にせよ、泥臭いには泥臭いなりの理由があるから。
C++ のメリットを大半捨て去って、代わりに C++ に足りないものを一つ二つ実装
したところで、デメリットのほうが大きくなってしまう。

これが JavaScript, Java(EJB), VB みたいに、最初から C++ がターゲットとして
いなかったニッチ層を目指して投入されれば、話が違ってくるけど。いつの間にか
ニッチの方がメインストリームに変わることもあるしさ。

なんのメリットも無い、ただただ苦行の一つとしてのみ残ってる泥臭さが
こんなに幅を利かせているわけはないわなｗ

C++は取り去るとか整理するとかオートにするとかしないと単に追加したらさらにページ数が
増えることは間違いない。

#ポインタはなくさないで！

C++はともかくx86はPCのソフトウェア互換性以外幅を利かせる理由あるか？
今じゃ組み込みには絶対使わんしな。

>>89
C3は普通に組み込みに用いられてますが？

>>89
サーバ向けCPUだと圧倒的なコストパフォーマンスがある。

>>91
はぁ？

ゲラゲラ。
C3を、組み込みね。それを普通という感覚。

なんでtemplateスレでCPU談義が始まってんの？誤爆？

テンプレートを直接実行可能なCPUができるんだってよ。

>>95
はぁ？

な、なんだってー

>>96
ここにスペックの詳細があるよ。でも、このCPUじゃ使い物にならんとおもふ。
http://www.arabtimes.com/mixed3/2.jpg

>>93
「絶対」使われないはずなのに、使用例があるのはどういったことで？

>>98
真面目に教えてくれないか？ぐぐっても見つからんのだが。

>>99
>>93(=>>89)が知らなかっただけじゃないのか？

組み込み屋ってあちこちで頓珍漢な話でレス汚してるな。
世界が狭いからだろうな。

組み込み屋はtemplateスレに来るなよー。

C3を乗せられるようなものは組み込みとは言わんな。あれはPCそのもの。

専用にハードから起こしたら中身がなんであれ組み込みでいいんじゃないか?

ダントツでARM、次いでSHでしょ。

>>105-106
話が繋がってないよな。
>>106シェアに何の意味があるの？

C3が組み込みにふつーというレベルで使われてるかどうかってことだろ？

組み込み話はもうええやろ。

絶対に使われていないかどうかってことだろ？

製品になってる限り100%使用してないことはありえない。だが、そんなものをチョイスした時点で設計の恥さらし。

それが89の言い訳？

しょぼい言い訳だよね。

boost 本感想ｷﾎﾞﾝ

予想外に分厚かった。
読むのはこれから。

boost本ってもう売ってんの？10日発売らしいけどウチの近くの
本屋はともかくとしても紀伊国屋とかにも無かったんだけど…

uBlas使った逆行列計算の実装方法教えてください

>>116
売ってる。
かなり大量に平積みだったよ。

大阪は田舎だからね

激しく本依存なのですが、ちょっとばっかり教えてください。
Modern C++ DesignのGenScatterHierarchyの部分で（P72,P73あたり)
typedef GenScatterHierarchy<TYPELIST_3(int,string,Widget),Holder> WidgetInfo;
とやった後、これを使う時
WidgetInfo obj;
string name = (static_cast<Holder<string>&>(obj).value_;
としています。
これで正しいようなのですが、どうしてHolder<string>の参照としてキャストしているのかがわかりません。
Holder<string>にキャストすればいいんじゃないの？と思うのですが、コンパイラで弾かれます。
なぜ参照で無ければダメなのでしょうか・・・

激しく遅レスですが、なぜstd::vectorにコンストラクタで失敗するクラスを要素にしてはいけないのか。
多くのvectorでは内部でメモリの確保と要素のコンストラクタの呼び出しを別にしている。
メモリの確保は基底・もしくはメンバクラス（ここではとりあえず基底としておこう）で確保される。
この基底はvectorのコンストラクタが呼ばれる前に生成される。
そのあとvectorのコンストラクタで要素のコンストラクタを呼び出すのだが、
ここで途中で失敗すると、もちろんvector自身はコンストラクタが成功してないのでデストラクタが呼ばれない。
そしてスタックの巻き戻しによって基底のデストラクタが呼ばれる。
ここでメモリと要素のデストラクタの呼び出しが行われるのだが、問題がある。
メモリは基底の生成時に成功しているので大きさがわかり適切に廃棄される。
しかし、要素のデストラクタに対応するコンストラクタ呼び出しは継承先のvectorで呼び出され失敗しているので、
その数がメモリの大きさと一致しない。
よってコンストラクタの数とデストラクタの数の不一致が起こる。

>>121
コンストラクト失敗に出食わすまでに，
成功した要素についてはきちんとデストラクトされるのでは?

で，失敗した要素については，
それがクラスであれば，それを構成するメンバ変数の内
コンストラクトに成功しているものについてはデストラクタが呼ばれ，
失敗したメンバ変数については，
それがクラスであれば，それを構成するメンバ変数の内
コンストラクトに成功しているものについてはデストラクタが呼ばれ....
(以下，組み込み型まで繰り返し．)

ってのじゃないの?

なんか句読点の打ち方がおかしかった．すんません．
ついでにageとこう．

>>122
> コンストラクト失敗に出食わすまでに，
> 成功した要素についてはきちんとデストラクトされるのでは?

コンストラクト失敗に出食わすまでに成功した要素については，
きちんとデストラクトされるのでは?

>>121
俺もそれを期待していた。
たとえば

#include<vector>
#include<iostream>
using namespace std;
class obj{
public:
obj(){/*ここで失敗する可能性*/cout<< "constructor" <<endl; }
~obj(){cout<< "destructor" <<endl; }
};
int main(){
try{
vector<obj> v(10);
}catch(...){}
}

とでもしてvectorの途中たとえば５個目で失敗（例外を送出）したとするとどうなるか。
多分コンストラクタ５回デストラクタ１１回（このうち１回ずつはデフォルトのコピーのためのテンポラリ）
となるだろう。ようは余計にデストラクタが呼ばれる。少なくとも組み込み配列とは挙動が違う。
決して改良するのは難しくないはずなんだが・・・

メモリについては最終的にうまく開放されるから心配ない。
問題は生のメモリにたいしてコンストラクタを呼んでないのにデストラクタを呼んでしまうことだ。

>>124
gcc3.4.0とVC7.1で試して見たがコンストラクタがどちらも
1度しか呼ばれなかったよ？

デストラクタは10個呼ばれてたけど。

やってみた。BCC5.6.4にCodeGuardを効かせる。

class Test {
public:
　Test(int i = 0) { if (i == 5) throw std::exception(); }
};

int main()
{
　std::vector<Test> v;

　for (int i = 0; i < 10; i++)
　　v.push_back(Test(i));
}

CodeGuardの出力結果

Error 00001. 0x400000 (スレッド 0x04A8):
Exception 0xC0000005: Access violation at 0xE24028.
呼び出し履歴:
0x0CD1BE31(=CG32.DLL:0x01:01AE31)
0x0CD14BA9(=CG32.DLL:0x01:013BA9)
0x0CD142BE(=CG32.DLL:0x01:0132BE)
0x0CD1523E(=CG32.DLL:0x01:01423E)
0x0CD24DD2(=CG32.DLL:0x01:023DD2)
0x0CD010BB(=CG32.DLL:0x01:0000BB)

コード行が示されないのでmain()の後始末(デストラクタ部)にて
アクセスエラーが生じていると読める。

>>126
int i = 1;
class obj{
public:
obj(){
if(i++ == 5){throw std::exception();}
cout<< "constructor" <<endl;
}
~obj(){cout<< "destructor" <<endl; }
};
とでもしておこう。今コンパイラのないところにいるんで、確認できないが。

>>127
ああ、それでもいいのか。自分はメンバでなくコンストラクタのこと気にしてたんで。
try/catchで囲んでいないからじゃなくて？

私もやってみた．(g++ 3.3.3 on Linux regnie 2.4.25)
>>126は多分別問題なので，ソースを改編．
$ cat test.cpp
#include<vector>
#include<iostream>
#include<exception>
#include<algorithm>
using namespace std;
class obj{
size_t id;
public:
obj (size_t p): id (p) {if (id == 5) throw exception (); cout << "constructor " << id << endl;}
obj (const obj &p): id (p.id) {cout << "copy constructor " << id << endl;}
obj &operator = (const obj &p){cout << "assignment operator" << endl; id = p.id; return *this;}
~obj(){cout<< "destructor " << id <<endl;}
};
int main()
{
try {
vector<obj> v;
v.reserve (10);
for (size_t i (0); i < 10; ++ i)
v.push_back (obj (i));
} catch (const exception &p) {
cerr << "Catch!" << endl;
}
return 0;
}

結果，
$ ./test
constructor 0
copy constructor 0
destructor 0
constructor 1
copy constructor 1
destructor 1
constructor 2
copy constructor 2
destructor 2
constructor 3
copy constructor 3
destructor 3
constructor 4
copy constructor 4
destructor 4
destructor 0
destructor 1
destructor 2
destructor 3
destructor 4
Catch!
ちゃんとディストラクトできてるような.....

>>126が気になる．
dequeも同様の結果に．
コンストラクタは呼ばんのか....

ああ分かった．
$ cat test.cpp
#include<vector>
#include<iostream>
using namespace std;
class obj{
static size_t count;
size_t id;
public:
obj (): id (count ++) {cout << "constructor " << id << endl;}
obj (const obj &p): id (p.id) {cout << "copy constructor " << id << endl;}
obj &operator = (const obj &p){cout << "assignment operator" << endl; id = p.id; return *this;}
~obj(){cout<< "destructor " << id <<endl;}
};
size_t obj::count (0);
int main()
{
try{
vector<obj> v(10);
}catch (const exception &p){
cerr << "Catch!" << endl;
}
return 0;
}

結果
constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
copy constructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
destructor 0
1個はコンストラクタを呼んであとは，
それをコピーみたい．

>>130
VC7.1でもOKですた。

>>134
あー、そういうことですか。

>>134
コピー元として一次オブジェクトを構築し
すべての要素はそのコピーコンストラクトだよ。

>>129
うわぁ、try - catchで囲んだらCodeGuard掛けてもエラー出ないや。

class Test {
　int i_;
public:
　Test(int i = 0) : i_(i) { if (i_ == 3) throw std::exception(); else std::cout << "Ctor(" << i_ << ')' << std::endl; }
　~Test() { std::cout << "Dtor(" << i_ << ')' << std::endl; }
};

int main()
{
　std::vector<Test> v;

　try {
　　for (int i = 0; i < 6; i++)
　　　v.push_back(Test(i));
　}
　catch (const std::exception& e) {
　　std::cout << "Catch! " << std::endl;
　}
}

Ctor(0)
Dtor(0)
Ctor(1)
Dtor(0)
Dtor(1)
Ctor(2)
Dtor(0)
Dtor(1)
Dtor(2)
Catch!
Dtor(0)
Dtor(1)
Dtor(2)

コピーコンストラクタ忘れてた。逝ってくる...orz...

ああ俺もコピーコンストラクタ忘れてた。
スレ汚しした。ああしゃれになんねえorz

C++ Templates - the complete guide
読みました。うーんやっぱりExpression template むずい。
構文解析自前で書いてるんですよね。んー。頭がうにになりそう。
プロキシクラス(っていうのかなー?)のスパゲッティだわ・・・
でも、とりあえずサンプルプログラムのコンパイルは通りました。

ここの解説は比較的簡単なんですが説明部分をこぴぺしても
全然コンパイル通らないんですよ。class -> struct 変換は当然やったんですが
(2)のvectorのテンプレート引数の書式おかしいんじゃないかなぁ？

http://www.icot.or.jp/FTS/REPORTS/H12-reports/H1303-AITEC-Report3/AITEC0103-R3-html/AITEC0103-R3-ch3_4_4.htm

まだどうもクラスの関連がよくわかってないので
C++ Templates - the complete guide
と格闘してみます。ちょっと理解の手助けとしてアドバイスいただけるとありがたいんですが

えー、つまり、>>43はデマということでよろしいか？

>>141
コピペで通らないのと直接は関係ないですが，
「ここでは、明らかなコンストラクタやデストラクタ等や、public/privateは削除してある」
とあるので，コンストラクタやデストラクタは用意しましょう．
まず，(1)の"template<class Op>"の位置がおかしいと思います．
operator=をtemplateにするべきかと．これで(2)の記述とつじつまが合うはずです．
さらに細かいことを言うと，(3)の特殊化の他にoperator+(vector const &, Vop<Vb> const &)と，
operator+(Vop<Va> const &, Vop<Vb> const &)の特殊化が必要なはずです．

>まず，(1)の"template<class Op>"の位置がおかしいと思います．
あ！なるほど。
あと、
特殊化というのは
template<typename X>
のXに具体的な型を設定することなんでしょうか？
特殊化というのは一般的な名称なんでしょうか？

C++ Templates - the complete guide　のサンプルプログラムのクラスの依存関係
を絵に描きだしてみたんですが、たぶんここら辺はお決まりの書き方になるんじゃないかと
思うので、セクション18の最後に公式風にまとめてもらえるとありがたいのにと思いました。

特殊化=specialization
e.g. http://www.gotw.ca/gotw/049.htm
def: http://www.kuzbass.ru:8086/docs/isocpp/template.html

あ，143に書いてあるのはspecializationとは言えないですね．
ただのオーバーロードですね．間違えました．申し訳ない．

boost::regexで(|abc)みたいな表現って出来ないんでしょうか。
bad_expressionが投げられて、what()するとempty expressionと、そのままの答え。
perl互換じゃないのかとドキュメント見たりぐぐったりしたけど全然empty expressionに関する情報が無い。
regex_constantsにそれらしいフラグも無い。

>>147
それは ((abc)?) とどう違うの？

>>148
説明足らずでごめんなさい。
c/migemoっていうライブラリが(|abc)みたいなのを返しちゃうんで、
empty expressionをエラーにしない方法が欲しいんです。
欲しいというか、あるはずだと勝手に思い込んでます。

なるほど…。確かにboost::regexにそのオプションは見あたらんね。すまんわからん。
しかし、C/Migemoはワシも使ってるけど、(|abc) みたいなのを
返してきた記憶がないんだが、どういう入力すると出る？

>>150
faceで、洋風顔文字が返るんですが、
その中に"X-("なんてのがあって、それが原因でおかしくなってたみたいです。
migemo_set_operatorとregbase::bk_parensで解決です。
empty expressionはエラーにするのが正しい正規表現なんですね。
148さん、お付き合いいただきありがとうございました。

templateの型パラメータを限定するにはどうしたらいいんでしょうか

例えば整数型のみをパラメータにとる
(整数型以外をパラメータに渡すとコンパイルエラーになる)
クラステンプレートとか

>>152 boost::type_traits + ( boost::concept_check | BOOST_STATIC_ASSERT )

>>152

// 特殊化されていないものは、不完全な宣言のみ
template< typename T > class foo;

// 必要なものだけ特殊化
template<> class foo<int>
{
　　...
};

超初歩質問なんですが、
template<> って<>が空なのはどういう意味なんでしょう？

explicit specialization（明示的な特殊化）を行う場合の書き方．
154の場合では，Tがintという具体的な特定の型の場合のfooの定義を特殊化している．
templateなんだけれど，テンプレート引数の具体的な型が明示されるので
テンプレート引数が不要になり，結果template<>という書き方になると思えばよろしいかと．

template<int> class foo{
};
とはどう意味が違うんですか？

・一般的な型を引数にもつテンプレートの宣言
・ある型のみに限定した引数をもつテンプレートの宣言
は異なるってことです。特殊化っていわれるとちょっとニュアンスがちがうかな？
いわゆるストラウストラップ本の訳に出てくる特別バージョンです。
一般バージョンでは補えない場合、特別その型のみに限定したバージョンを用意できて
その場合後者の宣言になるってことです。

不完全な宣言て、Effective C++に出てくる
　コピーコンストラクタと代入演算子はprivateに宣言だけして定義はしない。
ってのに似てるな。

テンプレート引数のクラスを関数内で知ることって出来ますか？

template<typename T> void foo(T)
{
T が double の場合の処理{
}

Tがcomplexの場合の処理{
}
}

っていうことなんですが。
sizeofとか使うのはバグの元だと思うので・・・？

特殊化しれ。

特殊化するぐらいならテンプレート使う意味ないじゃーんって思うのだが？

じゃぁ if (typeid(T) == typeid(double)) とかで。

極めて簡単な処理ならともかく、
特別バージョン作らなくてすむ場合の方が少ないような希ガス。

>>164
なんかピンと来ないな。
なるべく簡単な（無理を言って済まんが）例を出してくれないか？

>>165
164じゃないけど。
特殊化がわからないって意味？それとも特別バージョンを作る理由がわからないってこと？

>>166
作る理由の方。曖昧な言い方でｽﾏｿ
特殊化を使う場面はTypeTraits系、メタプログラミング、最適化くらいしか思いつかない。
実際にもあまり書いた記憶がないので、例を見せてほしいなと。

>最適化くらいしか思いつかない。
これって重要ではないかと？
complex<zzz>/double/float をテンプレート引数に想定してるときで、
conjをたくさん使うようなところ。typeid だと実行時判定

>>167
そんだけ理由があれば十分かと。
160の要望を解決するためには（設計が悪いのかもしれないけどこれだけだとわからない）しないわけにはいかない。

typeidは使うなって教科書には書いてあるけど。数多くの特別バージョンが必要な場合に、実に有効だと思うのだが？
オーバーヘッドをネグれる場合、積極的につかっちゃ駄目なの？

確かに最適化は重要だと思うけど、多くの場合カプセル化できるような…
例えば、
namespace mymath{
inline double conj(double d) {return d;}
inline float conj(float f) {return f;}
/* ほかにもいろいろ;boost::enable_ifを使っても良いかな */
}
template <typename T> void f(T t)
{
using mymath::conj;
/* conj(t)を呼び出していろいろする */
}

だから、
>特別バージョン作らなくてすむ場合の方が少ない
ってのはやっぱりおかしいような気がする。

>inline double conj(double d) {return d;}
>inline float conj(float f) {return f;}
特殊化せずに局所的に型に応じたconjを自前で用意したわけで、結局、同じことじゃないかと。

つまり、fを特殊化する代わりにconjを特殊化（オーバーロードだけど）するようなスタイルなら、
fのような関数を書くたびに特殊化をする必要はない、ということ。
>>168はconjではなくfを特殊化するといっているように読めたので。
読み違えてたらｽﾏｿ

一箇所だけオーバーロードすればいいなら、特殊化するよりコードはグンと少なくてすむ罠

組み込み型のための特殊化、愛してるよ!

もう俺はお前がいなけりゃダメなんだ。

特別バージョンは人気ないな。

若干スレ違いですが、
プラウガさん、C magazineに翻訳連載始まりましたね。

>>171
若干話しそれますけれど，自分ならtraitsにしますね．

template<typename T>
struct numeric_traits{
BOOST_STATIC_ASSERT(false); // ちゃんとtraits定義してないとダメよ
};

template<>
struct numeric_traits<double>{
static double real(double const &d){ return d; }
static double imag(double const &d){ return 0; }
static double conj(double const &d){ return d; }
// その他もろもろ
};

template<>
struct numeric_traits<std::complex<double> >{
static double real(std::complex<double> const &z){ return std::real(z); }
// あと同様に
};

template<typename T>
class C{
// conjなどは全部numeric_traits経由で
};

mapのデータに構造体を指定した場合、イテレータを使って構造体メンバに
アクセスするにはどうすれば良いのでしょう？
以下のテストコードではエラーが出たのですが…
--
'data' : 'pair<int const ,struct ST>' のﾒﾝﾊﾞではありません。
--

typedef struct {
　int data;
} ST;

void main(){
　map<int, ST> mp;
　ST st;

　st.data = 2;
　mp[1] = st;

　map<int, ST>::iterator i = mp.begin();
　cout << (*i).data << endl;
}

>>180
> 　cout << (*i).data << endl;
cout << i->second.data << endl;

イタレータは、
for (p = &a[first]; p < &a[last] ; p++) { (略)
の汎化だよ。集合データをなめるポインタ。
ってこれスレ違いなんじゃあ…

イタタタタ

厨質問ですんませんが、STLportって具体的に何がSTLと違うんでしょうか？

>184
STLは規格で、STLportはSTLの実装の１つ

>>185
さっそくどうもです。
では、VC++とかに付属されてるSTLも実装の1つということですね。

最初から付属されてるのにSTLportをVC++用にわざわざｲﾝｽｺしてる人達がいるってことは、
付属物よりメリットがあるから、ってことですよね？

183は質問の仕方が悪かったですが、そういうメリットを知りたかったということです…

>186
VC6に付属しているSTLはﾝｺだったので、STLportを入れる人が多かった
VC7のSTLはだいぶマシになってる

ただし、STLportにはSTLで規定されていないコンテナクラスも含まれていたり、
#defineで設定を切り替えれるなどから、今でも入れる人は多い

>>187
なるほど、入れるメリットがありますね。切替もできるみたいだし。
説明どうもありがとうです。

>>187
> ただし、STLportにはSTLで規定されていないコンテナクラスも含まれていたり、
VS.NET 2003 だと hash ベースの連想コンテナも用意されてるよ。
STLport とはちょっとインターフェース違うけど。

ropeとか。まぁ使いどころが無いが。

LokiのSingletonを見て思うことがあるんですがみなさんの意見をお聞かせ願いたいのです。
Lokiのシングルトンは
class A
{
...実装...
};
typedef Loki::SingletonHolder<A> SingleA;

//実行部分
SingleA::Instance().method();

のような形で利用するわけですが、A自体はシングルトンになりません。
SingleAはシングルトンだけれどもAはいくらでも複製できてしまいます。
Aは一つしか生成できるべきではないっていう責務を満たしてなく、
大域的にアクセス出来る仕組みだけを提供しているように感じます。
Aをシングルトン的に扱うためには、A自体をシングルトンっぽく書いて
friend class SingletonHolder<A>;
とでもしないとなりません。
あんまり意味無い様に思うんですが、どうでしょうか。

>>191
> A自体をシングルトンっぽく書いて
なんのこっちゃ？
コンストラクタをprivateにするだけやん。

>>192
コンストラクタや、コピーコンストラクタ、代入演算子を
プライベートにするって言いたかっただけですが、書くのがめんどくてはしょってしまいました
すいません。

>>193
> コピーコンストラクタ、代入演算子を
ここはboost::noncopyableのアイディアを借りると楽になる。

楽に書けるだけじゃなくて仕組みも知りたいから自分で書いてるの！

>191
ある意味C++の哲学を表していますなぁ
『SingleA経由でアクセスするなら面倒を見てやるけど、わざわざAのオブジェクト作って
　アクセスしようとするんだったら面倒みないよ。勝手にすれば？』
つうことですかね。

>>195
ハァ？
ソース公開されてんだから読めよ。アホか。

>>197
ソースも読めない糞ガキがほざいてろ。カスが。

template <int N, int P = 1, int Q = 0, int A = 1, int B = 0>
struct fib {
enum { value = ((N & 1) == 1) ? 0 + fib<N-1,P,Q,A*(P+Q)+P*B,P*A+Q*B>::value : fib<(N>>1),P*P+2*P*Q,P*P+Q*Q,A,B>::value };
};

template <int P, int Q, int A, int B>
struct fib<0, P, Q, A, B>{
enum { value = B };
};

というコードはコンパイルできるのですが、0 + を消すとコンパイルできません。なんでですか?

さぁ？

>>199
VC++7.1だと 0 + なしでもコンパイルできたよ。コンパイラのバグじゃない？
それより、なんでそれがフィボナッチ数列を計算できてるのかわからんので教えてくれると嬉しいのだが…

ごめんなさい。コンパイルできてました。ただすごいたくさんの warningが出ます。
例えば fib<1>::value だと

pow.cpp: In instantiation of `fib<1, 1, 0, 1, 0>':
pow.cpp:27: instantiated from here
pow.cpp:16: warning: enumeral mismatch in conditional expression: `fib<0, 1, 0,
1, 1>::<anonymous enum>' vs `fib<0, 1, 1, 1, 0>::<anonymous enum>'

ってかんじです。0 + があればなにも出ません。
g++ (GCC) 3.3.3 [FreeBSD] 20031106 です。

>>201

(fib(n+2)) = (1 1)(fib(n+1))
(fib(n+1))   (1 0)(fib(n))

なので、
(1 1)
(1 0)
のn乗を考えればいいですよね。ずれてたらすいません。

>>202
enum は暗黙のうちに整数型に変換できる。したがって 0 + をつけると
0 + enum値 が整数型となって、value の定義は

enum { value = 整数型 };

となる。これは全く問題ないコードだよね。

いっぽう 0 + をつけないと

enum { value = 別の無名enum型 };

となる。これだと左辺の value の型と右辺の enum 型が、別々の
型だと認識されて警告出てるんじゃないかなぁ。C++ の規格が
どうかは知らんけど。

>>203
例えばこんなコードは warningでません。

template <int N>
struct test {
enum { value = test<N-1>::value };
};

template <>
struct test<0> {
enum { value = 99 };
};

先に templateが展開されてから型チェックされてるんじゃないんですかね。
三項演算子の後ろ二つが両方テンプレートクラスの enumだと warningでるみたいです。
片方が整数だったり整数との演算をしてると大丈夫みたいです。

テンプレートクラスじゃなくてもクラスの無名enumを三項演算子の第二項、第三項に
すると駄目みたいです。static const int にすれば大丈夫でした。

gcc 3.3.1 でも warning なんて出ないぞ。
しかし、書けるからといって再帰的な定義式をそのままプログラムにするのは
どうかと思う。

(ﾟДﾟ)ﾊｧ?

>>206
何故？

テンプレートでforループのアンローリングみたいなことやったら
コンパイル時にメモリ足りなくなった

>>209
オレもなった時あるなぁ。

つか、そういう小細工しても、うまいこと最適化かけられないのか
普通にfor書いた方が速度速くなったこともある。

それ以来あんまりやってね。

遊んでるだけなら面白いし、学生のコンパイラ研究なら楽しいけど、
売り物にしようとするとなぁ。
俺はそんなコード書いてもアセンブル結果を全く想像できないしな。

テンプレートでループの展開ってどうやってやるの？
inlineに頼って再帰？

>>212
こんなかんじ

#include <iostream>

template<int n> struct loop;

template<>
struct loop<0> { static void iter() { std::cout << "hoge 0" << std::endl; } };

template<int n>
struct loop {
static void iter()
{ std::cout << "hoge " << n << "\n"; loop<n - 1>::iter(); }
};

int main()
{
// for (int i = 4; i >= 0; --i) std::cout << "hoge " << i << "\n";
loop<4>::iter();

return 0;
}

STLコンテナの
コピーコンストラクタはアロケータオブジェクトをコピーしてくれるものの
operator=は、アロケータオブジェクトをコピーしてくれないようなんですが
なぜ？

>>214
20.1.5 -4- かな？

>>213
iterがキモイ

メタプログラムなんて実務で使ってる椰子いるの？

>217
程度問題が、それなりには。

>>213
さんくす。
こういうのにはテンプレートよりプリプロセッサなのかな。

ふつーのプログラムでいいんじゃないの？
ループ回数引数にしてさ。

>>220
それだと展開できないだろ！

>>219
C/C++のマクロは再帰的に展開できないよ。
m4だったら出来るけどね。

>222
そこで Boost の preprocessor ライブラリですよ。

結局template頼りかよ(w

BoostのPPは普通にCでも使えるけど？

っていうか、
そこまでして無理やりtemplateなんて使う意味あるの？
メタプログラムならbison++使うとか。

そんなこと言ったらLokiやboostの立場が

boostでmpl使ってるところなんてごく一部じゃない？
preprocessorは多用されてるけど、ほとんど可変個引数のエミュレート用だし。

別に否定してるわけじゃないけど、選択のうまい基準みたいなもんがあるような気がしてね。
一般のプログラミングで、sh/awk/perl/C++ をそれぞれ使い分けるのと同じ感じで、
テンプレートでできるとしても、考え方もコーディングもすごく難しいでしょ？
素直に考え付かないっていうか。

自分だけが使うものとか、ライブラリの内部実装だけで使われるなら使いまくってもいいんだろうけど。
みんなで見るような部分に入るようになると困るよな。わかってもらえるか心配だし。

>>229
同意・・・templateを応用する本読んでいると頭痛くなってくる。
特に他人と共有するコードの場合、そこまでして使う価値があると
思えない。

「書き込み専用コードは避けよう」ってやつか
プロジェクトの人間が皆templateを深く理解してるわけもないしな



ｵﾚﾓﾅｰ

つか、こんなもん理解したくないってヤツが大半かと

自分で書く分には便利だが保守させられる身になるとな。

自分ですらすら書ける椰子へ。
頼むから、メタプログラム、式テンプレートあたりをわかりやすくレクチャしてくれい。
ってかして下さい mOm

わかって、自分でもすらすら書いて、あんなもんは云々ってのはかっこいいけど。
理解する前にあんなもんっていうのは負け惜しみみたいで嫌ジャン。

MPは代替手段があるけどETはこれしか手段がないからな。
もっと簡単に、わかりやすくならないもんかね。

>>236
まあそれはそうだけど、仕事となると保守可能要員が減る
ことをわかってて書くほうがﾀﾁ悪いわな・・・

>>237
ETの特別版
http://www.amazon.co.jp/exec/obidos/ASIN/B00005R22Y

warata

>>237
> MPは代替手段がある

あるの？

MPとかETとかは、他の開発者に見えないように、内部の実装だけに使うのが良いんじゃないの？
「テンプレートとかわかんないし〜」とか言う馬鹿を相手にしなくて済むし。

テンプレートが解かってても、読むのめんどくさい。
関数を大きくしないとか、そんなレベル。

MPとかETって何？

MP: Metha Programming
ET: Expression Template

前者はホイミとかを唱えるのに必要なリソース。
後者は自転車で空を飛べるようになるライブラリ。

スマソ
× Metha
○ Meta

スマソ
× Metha
○ Metya

なんかギャグセンスがオヤジな香具師がいるな

いません

しかしメタプログラミングは template じゃなくても可能っていうか、無理やり template で
実装してるような気がするな。ほとんど魔法だし。
普通のプログラミング言語みたいな表記で出来た方が素直だと思う。
きちんとやろうとすると C++ の仕様と密接に関わってくるから難しいかもしれないが。

>>251
なぁ、あんた>>237か？

> メタプログラミングは template じゃなくても可能

ここらへん、ちょっと例でも挙げながら解説してみてくれないか？

>252
251 じゃないが、プロプロセッサメタプログラミング、ならびにコードジェネレータ
(bison++ とか) を使ってのメタプログラミングがあるね。

無条件にテンプレートメタプログラミングからの乗り換えを推奨できる代物じゃ
ないが。というか、テンプレートメタプログラミングの方がマシっつー場面が
多いと思われ。

filesystemスタティックリンクしたら、
バイナリ200KBも大きくなった。
いや便利なんだけど。

#define MYTYPE double

struct List
{
MYTYPE x1, x2, c3;
List * prev;
List * next;
};

そもそも、発端は、この程度のことだったんだよな。

>>254
環境によるだろ。
オプションを変更して、極力ランタイムを使用するようにすれば
使っても使わない時と比べ10octetほどしか増えない。

>>252
251 じゃないが、C++でなくていいならCLOSとか。
Adaのpackage、MLのmoduleなんかも。
しかしC++のはCLOSに続いて強力だねえ。
コンパイル時ということになれば、研究用の言語は除いて最強か。

>>256
（略

>>257
横槍ですが、CLOSにしろAdaにしろちょっと調べてみた限りでは
C++のtemplateとの違いはキーワードの違いでしかないような
気がしたんですがそんなことない?(template==defgeneric ?)
さらにAdaは特殊化できないからMPは厳しいみたいな記述も..。

メタプログラミング用に中間コード(生のソースじゃなくて、
パース後のデータ構造もツリーでもいいけど。)が見れるといいな。
Cで言えば、定数演算とインライン関数の展開された後のソースが
見れるような感じというか。

用途は何?
OpenC++ってのがあるけど。
http://www.csg.is.titech.ac.jp/~chiba/openc++.html

filesystemってunicode使えないの？

>コンパイル時ということになれば、
コンパイル時ですべてが決定するわけだから、型部分をエディタでちょいちょいと置換
するのと大差ないって説も・・・

それで済む以上のことをやっていない人間にとっては大差ないだろうな。

>>263
君はC/C++でプログラムする時にマクロを利用することを禁止する。
ちょいちょいと置換したまえ。痴漢じゃないよ(欝

>>263
結局実行ファイルが欲しいだけなんだから、実行ファイルをバイナリエディタでちょいちょいと
書くのと大差ないって説も・・・

最初から設計が簡単にできて仕様の変更もないなら
コードジェネレーターでもいいんだろうけどね

複雑なテンプレートをうれしそうに書くのは

昔あった
#define begin {
#define end }
と同じか？

そ、それは複雑なのか?

{}
と書く代わりに
begin end
で4倍複雑だ。

そ、そうか。
これから変数は一文字にしよう…

>>271
KVMじゃないんだから……

複雑であることはC++のテンプレートとは何の関係もないんだよね
本来は複雑なものをシンプルに実装するための仕組みだし。
複雑なものを実装することも出来るけど、それはテンプレートとはまた別の話。

vectorを配列ポインタとして、関数に使っているのですが、
いいのでしょうか？

こんな感じ
{
std::vectordata_vec;
...あんなことやこんなこと...
func( &data_vec[0] , data_vec.size() );
}

func( &data_vec.front() , data_vec.size() );
こっちでもよさそうだけど、[0]の方が、vector::front知らない人には分かりやすそげ。


現在うまく行ってるけど

vectorのメモリが連続するっていうのは保証されているのですか？

一度配列にコピー汁

new[]/delete[]、malloc/free
書くのまんどくさいから、vector使ってるんですが
駄目ですか？

>>274
保証されてる

オーバーヘッドが気にならなくて
例外安全性とかまで考えるとそういう理由もいいんでないの

ていうか>>274と>>276はどちらも今すぐEffective STL嫁って感じの質問だな

>>277
23.1.1にも23.2.4にもそんな事書いてないけど？

http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-defects.html#69

いろんなとこで話に上るけど

>279
ISO/IEC 14882-200 には 23.2.4 に次の追記がなされている。

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().

そろそろ古い規格書は捨てちゃえ。

まぁ、basic_string<T>にすれば無問題だな。

↑・・・・・↓

ttp://www.s34.co.jp/cpptechdoc/article/vectorastemp/
ttp://www.tietew.jp/cppll/archive/9693
このあたり嫁。

ttp://www.s34.co.jp/cpptechdoc/article/vectorastemp/
ttp://www.tietew.jp/cppll/archive/9693
このあたり嫁。

vectorなんか使わず素直に配列使えよ。
そんなに記述量かわるわけでもあるまいし。

俺のばやい。
ポインタで要素に自在にアクセスしたい場合や
速度がほしい場合はvectorは避けるようにしてるかな。

俺のばやい。
ポインタで要素に自在にアクセスしたい場合や
速度がほしい場合はvectorは避けるようにしてるかな。

別にiteratorでも使い勝手は同じだし、速度的にも全く差はないと思うが。
強いて言うならリサイズの必要が全くなければboost::*_arrayを検討する程度。

>>287
vectorを避ける理由にまったくなっていない。

EffectiveSTL読んで無い人はこのスレに書き込んじゃいけないんだよね？
>>1にもそう書いてあるはず。

g++で以下のコードが通らない。icpcは○。

#include <loki/Typelist.h>
#include <iostream>

class A {
public:
A( void ) { std::cout << "A" << std::endl; }
};

typedef TYPELIST_1( A ) TLA;

template< typename X >
class Show {
private:
Loki::TL::TypeAt< X, 0 >::Result a;
public:
Show( void ) : a() {}
};

int main( void ) {
Show< TLA >();
return 0;
}

>>287
別にvectorを採用しなければならない理由はまったくない。

物理メモリに直接アクセスするのが怖い奴ははじめからC#でもいじってろ。

stringは確かに便利、listもbitsetもまぁ存在意義は認めよう。自分で書いて雛形持ってない奴にとっては便利だろう。
ただし、配列ごときでvectorなんていうまどろっこしいtemplate使う奴は、単なる馬鹿。

>>295
なんでこのスレを読んでるのかと……
別に 295 が template 使わないのは構わんが、それを布教するなら
他でやった方が良いと思うぞ

>>295
可変長配列でもvector使わないの？

>stringは確かに便利、listもbitsetもまぁ存在意義は認めよう
この時点でSTL分からない奴なんだなーというのがバレバレなんですが

>可変長配列でもvector使わないの？
realloc使え

結局、resizeはrealloc使ってるんだよな。

>>299
可変長配列ごときでreallocなんていうまどろっこしい関数使う奴は、単なる馬鹿。

>>298
決め付け厨登場

>>295
>ただし、配列ごときでvectorなんていうまどろっこしいtemplate使う奴は、単なる馬鹿。
禿げしく同意

自分が思いつく動的配列に対するvectorの利点
・割り当てたメモリを（1回だけ，正しいサイズで）開放しなければならない，
　という責任を負わなくて良い
・配列のサイズに対する一貫性の責任を負わなくて良い
・例外安全性に対する負担が大幅に少ない（一般に例外安全性に対する
　認知度が低いので，このことが（ﾟдﾟ）ｳﾏｰに思われないことが多い．残念）
・アルゴリズムとの親和性が高い（一般にアルゴリズムの認知度が低いので，
　このことが（ﾟдﾟ）ｳﾏｰに思われないことが多い．残念）

自分が思いつく動的配列に対するvectorの弱点
・vectorの方が常に1, 2ワードほど余計にメモリを使う
・vectorは最大で2倍（実装によっては異なるが，多くは2倍）余計に
　メモリを使う可能性がある（ただしswap idiomによるshrink to fitで解消できるとされている）

割り込みすまん！
ＭＰのループ展開についてなんだが、
あれってなんのメリットあるの？
コンパイル時でなく実行時にループするんだから
結局なんのメリットもないような気がするんだが。

実行時に効率がいいってくらい？

>>305
コンパイル時にループを展開してしまえば、実行時に

1. ループ変数をインクリメント
2. ループ変数がループ終了条件に達しているかチェックして、条件分岐

という命令を省ける。特に最近のパイプライン化された CPU だと、後者の
条件分岐が重い命令なので、これを省けると実行時効率がグッと上がる
可能性がある。

>>292
- Loki::TL::TypeAt< X, 0 >::Result a;
+ typename Loki::TL::TypeAt< X, 0 >::Result a;
3.3.3ではこれで通る．

>>306-307
>コンパイル時にループを展開してしまえば、実行時に
>1. ループ変数をインクリメント
>2. ループ変数がループ終了条件に達しているかチェックして、条件分岐
>という命令を省ける。特に最近のパイプライン化された CPU だと、後者の
>条件分岐が重い命令なので、これを省けると実行時効率がグッと上がる
>可能性がある。

あっ、そういうことでつか！！
それで納得できますた。ありがとう(･∀･)

>>309
安易に納得しないほうがいい。
ループアンローリングによって高速化するのは極めて稀。
適用できる場面を探すほうが難しい。
それにアンロールできるような単純なループなら条件分岐の実行時間は実質０。
むしろ下手にアンロールするとコードサイズの膨張によってキャッシュの効率が低下、
その結果としてかえって遅くなるのが関の山。

動的配列なんか少なくとも俺は必要ない。

>・アルゴリズムとの親和性が高い
なんじゃ？こりゃ？
FFTのアルゴリズムと親和性が高いかい？
Berlekamp-Massey アルゴリズムといったいどこが親和性が高いんだ？
それともKalman Filterアルゴリズムと親和性が高いのかい？
いずれも何の相関性もない。
いったい何のアルゴリズムをいってるんだ？

STLのアルゴリズムだろ。
まあ、あれは配列にも適用できるんだが。

なぁーんだ。
ソートしたりカウントしたりといった。FFTも理解できん9図ガキでもわかるC++のアルゴリズムのことか

>>311
カルマンフィルタってアルゴリズムか？

>>310
307さんもパフォーマンスアップの「可能性がある」
という書き方ですが、場面を考えないといけないんでつね。
c++ templateは良い本ですがそこまで踏み込んで
書いてくれていませんね。でもアンロールがあまり役に
立たない可能性があると、ETとかはより一層場面を考えて
使わないといけないような気が。。。

>>314
mean square error を最小にするように Kalman gain を決定する算法そのものを
Kalman filter algorithmと言うんだよ。
大体、algorithm っていうのは算法、解法とか、手順のことを言うの。
STLのalgorithmなんて解法には値しない低レベルなもの。

別にアルゴリズムかどうかとレベルは関係ないだろ。
それにソートなんて単純に見えて相当奥が深いぜ。

>>314
フィルタというと工学屋にとってはろ波機構を意味する。
工学の場合、化学屋のいうフィルタも、電気屋のチェビシェフ/バタワース/FIR/IIRも
みーんなろ波機構。カルマンフィルタも雑音がある場合の状態変数推定機構。
ちょっと意味合いが異なるのが、数学屋とか経済屋のいう情報の増大機構そのもを
をフィルタという場合。これは表現上すごく紛らわしいし、情報の増大系とろ波機構
はきちんと区別するべきと主張したいのだが・・・

>>317
>それにソートなんて単純に見えて相当奥が深いぜ。
そんなに奥が深くて、評価や実装が難しいものなら標準化なんかしない。
簡単で、皆がよく使うものだから。標準化して用意してるんだよ。

>>313
お前はいまFFTを理解していない人間全てを敵に回した！

アフォ敵に回しても痛くも痒くもないんだが。

FFTごとき馬鹿でも理解できるだろ。
理解できなきゃ人間やめろ。

>>320
FFTぐらい理解してても何の自慢にもならないが、理解できなきゃ恥だな。
っていうより、理解できないことをここでわざわざ主張しなくてもいいってば。

なんだこりゃ、定番のジョークにそんなに必死になられても、どう反応すればいいのやら。

別に必死になってるわけでなくて暇ですることないから書き込んでるだけなのだが。

スレと関係ないこと書いて、誰かが
"スレ違い!"
と叫ぶのを待ってるわけなのだが。

スレ違い!↓

>>319
STLに限らずアルゴリズム一般の話をしてたんだが。

まあSTLに限ってもソートは
皆がよく使うものだからというのは同意だが
簡単だからというのは同意しない。

パフォーマンスを出すには複雑になるから
標準化して用意されているんだ。

わかった。
溜まってるのでソープにでも行ってくるわ。

>>328
>パフォーマンスを出すには複雑になるから
>標準化して用意されているんだ。
お前の頭ではソートごときでも複雑なんだろ。
お前には下僕プログラマがちょうどお似合い。
それ以上複雑なアルゴリズムは理解できないことを保証する。

char が unsigned でなければコンパイルエラーにするテンプレートを教えて
ください。charは型的にはsigned charでもunsigned charでもないので下のやつ
では駄目でした。

template<class T> class CharTest;
template<> class CharTest<unsigned char> {};

CharTest<char> ctc;

>>328
>簡単だからというのは同意しない。
使い手の手の加えようのないぐらいすでに評価が定まってるから標準化してるんだよ君。

できた

ここは見下し厨の多いインターネッツですね

また、録音か!

見下し厨、そんな態度で会社とかで大丈夫なんかね･･･
周りの人から見放されてないか心配だ･･･2chだから吠えてるだけですよね･･･

>>331
BOOST_STATIC_ASSERT(!std::numeric_limits<char>::is_signed);

こんな感じでどう?

>>332
外部仕様がシンプルなのと、実装がシンプルなのは話が全く違うわけだが。
UNIX なんかシステムコール 100 のオーダーしかなくて見た目はシンプルだが、
効率の良い実装を提供しようと思ったら大変だろ。

ソートアルゴリズムも「ソートする」という外部仕様は単純でも、それを汎用性が
高くかつ、そこそこ性能が出て、しかも例外安全な形で実装しようとなると、
いろいろめんどいワケだ。

まぁ、別に 332 が STL のソートアルゴリズムを評価しないのは構わんが、
その評価を他人に押しつけるのはヤメれ。ここは template 統合スレなんだし、
template 使わないなら余所で議論してくれよ。

>>336
彼は人間関係が築けなくても生きていける学生か研究者
ではないかと思われるわけだが

>>339
単なる無職ひきこもりだろ

STLport, boost, Lokiをｲﾝｽｺしようと思ってるですが
ｲﾝｽｺの順番はこの順が良いってのあります？

boostのインストールオプションでSTLportなんたらがあるようなので
STLportの方が先の方が良さそうですが

環境はWinXP pro + VS.NET2003です

STLPortが先、以下順不同

>>342
�dクスコ

STL的なFFT実装、pFFT++
http://www.mit.edu/people/zhzhu/pfft.html

>>308 遅レスですが、有難うございます。
気づきませんでした。何処を見たら気づけたのでしょうか？

>>345
ttp://tt.sakura.ne.jp/~suzu/template/typename.html

>>345
> 気づきませんでした。何処を見たら気づけたのでしょうか？
何となく．付けてみたら通った．(笑)
g++は3系列になるときにtypenameを要求されることが多くなった気がする．
(2系列がいい加減だったんでしょけど．)
それで付けてみた．

>>346
良いページですね．

boostの導入を考えてるんですが、
FAQをみるとboostは下位互換性がいつも保たれてるわけじゃないので、
プロジェクトごとにboostのバージョンを固定して使うようにとあります。

みなさんはプロジェクトとboostのバージョンの対応ってどうやって管理してますか？

こんな感じですか？

方法１:
プロジェクトごとにどのboostバージョンを使っているかコメントに書いておき、
マシンにバージョンのちがう複数のboostをいれて切り替えて使う。

方法2:
(ﾟεﾟ)ｷﾆｼﾅｲ!!

>>348
> プロジェクトごとにどのboostバージョンを使っているかコメントに書いておき、
コメントではなく Makefile に書いてる。インクルードパスとライブラリの検索パスを
プロジェクト毎に設定すれば良いだけ。

>>347
逆にVC7.1は頭が良すぎてtypenameを付けなくてもエラーが発生しない場合が
多いので、VC7.1を多用されている時は気をつけよう。

>>350
VC7.0 は、の間違い。VC7.1 は typename でエラー出すようになってるよ。

>>351
いや、VC7.1の場合だ。間違いではない。もうしょっちゅう経験している。

単にlevel設定が違うだけじゃ

vc6sp6、stlport4.2、lokiVC6port使用で
lokiのSingleton.hのここの部分で、
Throwerは定義されてません,とかエラーでるんだけど俺だけ？
throw std::logic_error("Dead Reference Detected");
のコメントはずして、Throwerをコメントすれば、コンパイルできるんだけど。
なんで、vc6用なのにコンパイラ通らないのか、謎なもんで。

namespace Loki{ namespace Private {
　namespace{
　void Thrower(const char* s) {throw std::logic_error(s); }
　}

　struct DefaultLifetime {
　　template <class T>
　　static void OnDeadReference(const volatile T* p = 0 ){
　　　// the throw will yield a C1001-internal compiler error.
　　　// The new level of indirection solves the problem
　　　// throw std::logic_error("Dead Reference Detected");
　　　Thrower("Dead Reference Detected");
　　}
　};
}]

ServicePack6なんて出たの？

VC++でLokiを使いたい時って
sourceforgeのLokiとLokiPortのどっちか片方だけで良いの？
それとも両方？

>>356
VC は、6, 7.0, 7.1 でまったく別モノだから、バージョンも書け。
たぶん sourceforge 版に取り込まれているとは思うけどな。

>>355
http://www.microsoft.com/japan/msdn/vstudio/downloads/sp/VS6SP6.asp

何か重要なものが変更されてたような気がしたが、まぁ気にしないでぶちこんでみた。
最適化まわりのバグがなくなって、変わりになにかがつかえなくなったような・・・。
アセンブラがつかえなくなったんだっけ？つっこみきぼんぬ。

あ、namespace Loki{ namespace Private { /*略*/ } }
の部分、Privateのネームスペースかかってない。

namespace Loki{ /*略*/ }
に訂正。

てか、開発者はなんでコンパイルとおるんだ？vc6つかってない？

>>359
Thrower("Dead Reference Detected");
↓
Loki::Thrower("Dead Reference Detected");

で良かったような気がする。

>>359
あと、リンクの際にシンボルの複数回定義云々のエラーが出るようだったら、Throwerをinline

>>360
ありがとうございます！
>>360の方法は俺もやってましたが、
>>361は知らんかったなぁ。
てか、複数回定義でなくて良かった・・・。
でてたら憤死してたかも。

>>357
> VC は、6, 7.0, 7.1 でまったく別モノだから、バージョンも書け。
これは失礼した
6, 7.0, 7.1全部ｲﾝｽｺしてあるけど使ってるのは7.1

> たぶん sourceforge 版に取り込まれているとは思うけどな。
あらそうなん

ｿｰｽﾎｹﾞとﾎﾟｰﾄVC7の両方落としてみたんだけど
片方にあって片方にないファイルがあったんで
どうなんだろうと思って

>>358
コード生成について結構致命的なバグが直っている。(必ず発生するものではないが)
それよりもIDEのバグが直ってるのが重要だと思うがな。
無くなったのはProcessorPack。
最新CPU対応したければとっととVC.NETにアプグレ汁ってことだな。

そうでなくても乗り換えた方がいいと思うがな。

テンプレートでスタックを習作しているんですが、
VC7.1でインクルード関連が良くわかりません。
どなたかご教授お願いします。
http://cgi.f20.aaacafe.ne.jp/~tori/html/upboard/updir/CStack3.lzh
ちなみにこれはソースのデバッグはまったくやってない闇コードです。

>>365
＞VC7.1でインクルード関連が良くわかりません。
ってどうわからないのかはわからないけどそれ以前の問題が大杉の気が
・ヘッダからcppをインクルード
・BOOLにtrue/falseを使ったり
・if forの後に空白がない
・「 { 」の前にも空白や改行がない
・なぜスタックにheightとwidthが出てくるのか

>・if forの後に空白がない
>・「 { 」の前にも空白や改行がない
これはどうでも良くないか？

俺もそう思った。問題を大杉に見せたかっただけちゃうんかと。

テンプレートの実体化を遅らせるにはどうすればいいですか
具体的にはstruct Bをテンプレートにしないで
以下のようなものをコンパイルしたいです

template<class T> struct A{};

struct B
{
　　typedef A atype;
};

int main()
{
　　typedef B::atype<char> atype;
　　return 0;
}

> 具体的にはstruct Bをテンプレートにしないで
> 以下のようなものをコンパイルしたいです
とりあえずそれだけなら。

template<class T> struct A{};
struct B
{
　　template<typename T> struct A { typedef ::A<T> type; };
};
typedef B::A<char>::type atype;

で、これで「テンプレートの実体化を遅らせる」ことになるの？

>>369
言っていることはよくわからんが、これでいいか?

template<class T> struct A {};
struct B
{
　template<class T> struct atype {typedef A<T> type;};
};
int main()
{
　typedef B::atype<char>::type atype;
　return 0;
}

>>370 かぶったね

ありがとうございました

template<class T>
struct A
{
　typedef typename T type;
};

template<class T>
struct B: boost::mpl::if_< typename boost::is_base_and_derived<B,T>,typename A<T>,typename A<B> >::type
{
};

struct C: B<C>
{
};

struct D
{
};

int main()
{
　cout << typeid(C::type).name() << endl;
　cout << typeid(B<D>).name() << endl;
}
実行結果:
struct B<struct C>
struct B<struct D>
一行目はstruct Cとだけ表示されるべきなのですがうまくいきません
is_base_and_derivedがうまくいってない感じなのですが、何か間違っているところとかありますか？
環境はboost1.31.0でVC7.1です

>>374
> struct C: B<C>
このB<C>のインスタンス化の時点でCが不完全なんだろう。
後は、前スレの145,169-172あたり見れ。

boost::shared_ptrで質問なんですがこいつをvectorで使用してみたく
定義してiteratorを使用しての参照ができないんですが
どのようにしたらいいのですか？

typedef struct
{
int nNumber
}hoge;

int main()
{
std::vector<shared_ptr<hoge> > vspHoge;
shared_ptr<hoge> spHoge(new hoge);
spHoge->nNumber = 1;
vspHoge.push_back(spHoge)
for(std::vector<shared_ptr<hoge> >::iterator it = vspHoge.begin(); it<vspHoge.end(); it++)
{
cout << it->nNumber <<, endl; //これでエラー
}
for(int i = 0; i <vspHoge.size(); i++ )
{
cout << vspHoge[i]->nNumber <<, endl; //これならうまくいく・・
}
}

>>376
(*it)->nNumber

>>377
あっさり通りました・・・
ありがとうです。

Lokiのファクトリーでshared_ptr 欲しかったから

template<
　　class AbstractProduct,
　　typename IdentifierType,
　　typename ProductCreator = boost::shared_ptr<AbstractProduct>(*)(),
　　　　class FactoryErrorPolicy = Loki::DefaultFactoryError >
class SharedFactory
　　: public FactoryErrorPolicy
{
　　//略
　
　　boost::shared_ptr<AbstractProduct> CreateObject(const IdentifierType& id)
　　{
　　　　typename IdToProductMap::iterator i = associations_.find(id);
　　　　if (i != associations_.end())
　　　　{
　　　　　　return (i->second)();
　　　　}
　　　　　　return OnUnknownType(id, Loki::Type2Type<AbstractProduct>());
　　　}
　　//略
};

こんなんしてみたけど、もっといかしたファクトリーないんかいな？

365です。
>366
レスThx！
手を抜いてると幾つか問題が出ちゃうね。
精進します。

あと、質問はすれ立てるまでもないすれに移動します。
ありがとうございました。

>>380
bool CStack<T>::Push(T in)でif((alloced*maxlen)<=used)って言うのがあるけど
usedはコンストラクタで0にした後、Createでも何もされていないから絶対に条件は成立するんじゃないか？

なんかスレに沿わない気がしますが、boostスレは別になかったようなので。

VC++7.0+STLport-4.6.2+boost-1.31.0でregexのビルドに失敗します。

・STLportの構築
　stlport/stl_user_config.hは特に変更せずにsrcでnmake -f vc7.mak

・boostの構築
　libs/regex/buildでnmake -f vc7-stlport.mak STLPORT_PATH=STLportのパス

以上の方法でやると、boost_regex-vc7-mt-p-1_31.dllのリンク中に
winstances.obj : error LNK2019: 未解決の外部シンボル (長すぎて書き込めないので略)
のようなエラーが大量に出てリンクに失敗します。
エラーメッセージ内に全部wchar_tが出てるようなので
/Zc:wchar_tのオプションが怪しいと考えています。

どなたか原因のわかる方はいますか？

vc7.1というかvc7.0にVCtoolkit2003を入れたやつで漏れもはまったけど
スタティックリンク版はコンパイルできてもダイナミックリンク版は
通らないみたい。ので、スタティックリンク版を使ってます。。。

> winstances.obj : error LNK2019: 未解決の外部シンボル (長すぎて書き込めないので略)

そこ、いちばん省略しちゃいけないとこだと思うんだけど。

> /Zc:wchar_tのオプションが怪しいと考えています。

とりあえず、STLportのビルドboostのビルドで食い違ってたら駄目だろうな。

素直に7.1に乗り換えたらどう？

>>382
それを解決するには(長すぎて書き込めないので略)

boost::lambdaを使ってみたのですが、stringのbindで「C2780引数が必要です」
のエラーが大量に出ます。自前のクラスなら大丈夫なんですが、原因が分かりません。
使い方が間違っているのでしょうか。環境はVC7.1+boost1.31.0です。

#include<string>
#include<vector>
#include<boost/lambda/lambda.hpp>
#include<boost/lambda/bind.hpp>

struct TEST{
int hoge(int i){
return i;
}
};

int main(int argc, char **argv){
using namespace std;
using namespace boost::lambda;

vector<TEST> vt(10);
vector<string> vs(10);

//自前のクラスなら、大丈夫
remove_if(vt.begin(), vt.end(), bind(&TEST::hoge, _1, 2) == 1);

//'a'が含まれてる要素を削除 ここで大量のエラー
remove_if(vs.begin(), vs.end(), bind(&string::find, _1, "a") != string::npos);
return 0;
}

>>387
std::string::find はオーバーロードされたバージョンがあるから。
メンバ関数の型を明示して、一回関数ポインタを取ってから、そいつを
bindに渡せば行ける…はず。
std::string がテンプレートバキバキだからメンドイから試してないけど。
# しかも find って第二引数が実はデフォルトで 0 だし。

他に何か解決策あるんかな？あるなら俺も知りたい。

>>388
レスthanks。確かにオーバーロードされてると、どのfindか分からないね。
で、findのポインタを取ってみようと思ったんだけど、これがなぜか通らず。
string::size_type (string::*p_find)(const string&, string::size_type);

まあいいか。こういう場合は素直に関数オブジェクトにした方がいいな。

通らないのはこっちだった。変換できないそうだ。
string::size_type (string::*p_find)(const string&, string::size_type) = &string::find;

const が抜けてないか？
string::size_type (string::*p_find)(const string&, string::size_type) const = &string::find;

>>391
あ！通った。ありがとう。
typedef展開したり小一時間いじくってた・・・

これでいける。
string::size_type (string::*p_find)(const string&, string::size_type) const = &string::find;
remove_if(vs.begin(), vs.end(), bind(p_find, _1, "a", 0) == string::npos);

今日本屋にいったらboost本が出てたよ
http://www.amazon.co.jp/exec/obidos/ASIN/4798007862/249-0609019-0421111
みんな読んだ？

次はboostの実装技術の本お願いします、Modern C++ Designを超える奴をぜひ＞稲葉先生

情報遅すぎ

>379
遅いかもだけと、Traitsにしちゃうってのはどうでしょうか
template <typename T>
struct Product
{
typedef T* type;
};

template <typename T>
struct Product<boost::shared_ptr<T> >
{
typedef boost::shared_ptr<T> type;
};

Product<AbstractProduct>::type CreateObject(const IdentifierType& id)
{
//
}

これがいやならAbstractProduct::ProductReturnTypeとか
AbstractProduct自身をTraitsに。

ちなみに
typename ProductCreator = boost::shared_ptr<AbstractProduct>(*)(),
の部分は
typename ProductCreator = boost::function<Product<AbstractProduct> ()>
ってやっとけば何でも入っていいかも。遅いかもしれんけど

ああ、typeぬけてた。。
連書きすまそ。
typename ProductCreator = boost::function<Product<AbstractProduct>::type ()>

>>395-397
いえいえ、どうもありがとうございますです。
なるほど、boost::functionはいいっすねぇ。

そういえば、デフォルトのままだと、AssocVectorを動的確保すると落ちるから
std::mapに変えるはめになったよ・・・。

>>393
よく調べずにamazonで買ったが、かなりがっかりする内容だね。
もうちょっと深さを期待してたんだが。学生が書いたらこの程度だろな。
こんな本の執筆で金儲けする前にもうちょっと学業に精出せよ。ったく。
大体ライブラリを作ったわけでもないのに、exampleとこの程度の解説するだけで
これを人のふんどしで相撲を取る典型だな。
人のふんどしで相撲を取る==boostの糞解説本書いて金もうける

次は、上っ面なぞったような他人のふんどし本じゃなくて、
blitz++ か ublas の式テンプレートのディープなところの解説本でも書いてくれよ。
-->稲葉大先生

>>399
そんなことはないぞ、纏まったペーパーベースのリファレンスは現在これしか無いだろ。
boostはまだ現状ごった煮ライブラリだから、しっかりしたドキュメントは無いわけで貴重だと思うけどね。

>>401
おおっと！ご本人さんのご登場です。

俺もboost本はありがたかったけどなぁ。
まぁ確かに深さは無かったかもしれんが、イキナリそんなにディープだったら
そっちの方がむしろビックリかと。

ペーパーベースでなくとも
ホームページに行けば、ちゃんとexampleを載せた解説が出来上がってまんがな。
稲葉はこの印税を100%自分の懐にしまいこむつもりじゃねぇだろうな？
ふんどしだけ人のを使っても、相撲をとるなら立派なもんだが、
相撲を取ってるわけじゃないからな。
行事が懸賞金わたすときにどこからか現われて掠め取るに近いだろ？

>>404
boost作った奴らがあがりよこせと言ってきたらどうするんだろね。

他人が金儲けするのがとても気に食わないらしい

同じC++プログラマとして恥ずかしいから、
そんな方向で盛り上がるなよ。

こういうので文句言う奴って本が出るたびに「自分で作ったわけじゃないのに他人のふんどしで・・・」ってウジウジ言ってるのかな

>>404
ｱﾌｫか。んなこというとC++の解説書書いてるやつらもみんな同罪だろ。

C++の解説は規格の解説だ。
boost本は特定の処理系に関する解説に近いな。
gccの解説とかな。

GCC の解説本書いた奴は普通 GNU に寄付する罠。

boostな人達とAlexandrescuっていまいち仲良くなさそうだよね。

>>406
気に入らないね。直接努力してるboost クリエイタに一銭も行かないのは大問題だ。

一般的に言ってコード書きよりドキュメント書きのほうが面倒だから、人の嫌がることをやる奴が利益を得るという点では問題ないと思うが。

Boost本の内容の薄さは別として。

>Boost本の内容の薄さは別として。
それが問題なんだよね。内容が濃ければ人のふんどしとは誰も言わない。

>>413,414
そういうライセンスで作者が公開しているから問題は皆無。
413の「気に入らない」という気持は分からんでもないが、同意は全くできない。

>>416
おおっと。ご本人さん。
ご自分の利権主張にはご熱心で抜け目ないね。

>>416
別にお前に同意いただかなくとも全く結構だから、安心しな。

つか、言っちゃ悪いがあの程度の本を買ってしまったおまいらが悪い。
Amazonでかった？だったら返品すればいいだろ。

>>417,418
内容の論評だけにしとけ。見苦しい。

書籍って未開封とか乱丁、落丁本以外返品できるの？

>>416,420
自己弁護は自分のホームページだけにしとけ。見苦しい。

はぁ、IDあればあぼーん出来るのにな・・・

>>421
無理。

(；´Д｀)　だから、お前ら恥ずかしいからそんな話はやめれっちゅーに。

あの本の内容があまりにしょーもないというのがなんで恥ずかしいんだ？

内容がしょーもないと言うのが恥かしいのではなく、金儲けするのが嫌だというのが恥かしい。金儲けしたかったら自分で売れる本書けよ。

他の本でこんなくだらんことで盛り上がってるの見たこと無いな。
あの本の著者に個人的な恨みがある奴が今いるのか？

というか単なる負け犬の遠吠えにしか聞こえん。
とか言うと本人扱いされそうな悪寒

・boost 本買ってショーもなかったと思う人の数-->
・よかったと思う人の数-->

・そもそも買ってない人→1

>金儲けするのが嫌だというのが恥かしい
お前脳のMRIでも撮影してもらえ、そんなことは誰も言ってない。

>>420
>とか言うと本人扱いされそうな悪寒
と言えばごまかせると思ってる時点でﾏﾇｹなんだよ。

あげて厨さそおっと。エイッ

きっとboost本が一冊しか無いからこんなことで盛り上がれるんだろうな…

まぁ事の発端は>>399がよく調べもせずに買ったのが悪いんだけどな。
愚痴なら自分の日記にでも書いとけ。

>>399がいつ買ったのかは知らんが
amazonの一ヶ月も前に書かれたレビューにも
>また、本書の内容はBoostで提供されている機能説明であり、Boostの実装方法を説明しているわけではない。
>その為、Boostの概要を知りたい人には役立つだろうが、Boostの実装を紐解く為には利用できない。
って書いてあるのにな。

ここで金儲けだなんだと文句言ってるのはオープンソース厨房？
じゃあお前が書けよって感じだな（ぷっ

なんでこんな嫉妬丸出しのスレになってんの？

内容が薄いことに金儲けを絡めて書いた馬鹿が悪い。

自分で書く能力もないのに、どうしてこんなに偉そうなんだろう。

>>440
ライブラリも本も書けない奴らが自尊心を保つ為に仕方が無い事なのです。
せめてここでは愚痴を聞いてあげましょう。

おまいらシュッシュのやばさを（ｒ

久しぶりに伸びてるなと思ったら…案の定こんな展開かよ。

俺もｵﾓﾀ

所詮　2chねる＝下痢便　だから

個人的にはリファレンスと解説書は別になっていた方がよいので稲葉本はこれで良いと思う
ただでさえ分厚いのに、これ以上分厚くなったら読みにくくてかなわん、実装についての解説書は別途欲しいよ。

けど、アマゾンで在庫切れだし、ラオックスいったら山積みなってたよ
機能と、サンプルソースとかぐぐるより早くたどりつくと考えれば
結構いいんじゃね？　漏れも買ったし・・・　orz

>>436
バーカ。
それは俺が書いたんだよ。

>>446
それならBoost C++ library referenceにしろってんだよ。
Boost C++ library programming なんていう内容の深さを匂わせるような
名称はやめろってこった。

稲葉は叩かれると防戦に必死だな

もっと荒れろ

>>449
おまえが内容を確認しないで買うってのはもうわかったから駄々こねるな。

>>399が騒げば騒ぐほど、自身の買い物の下手さを宣伝することになる。
だから恥かしいんだよな。

週間ポストのヘアヌード掲載号は10年後プレミアムがつくが
Boost 本は1年でゴ(ry

結局この本は買う価値があるのか無いのかどっちだ？

C++の本は駄本と良本の区別がハッキリしてるからな。
駄本掴まされたやしがむしろバカ。

じゃ、買うのは馬鹿といえる本なのか？

普通の人はソース読んで使うから今まで本が出る必要がなかったつーか
本にするほどのもんでもないと思ってたな

ソース読んで理解してから使うのは大変だろ。そんなことするなら自分で書いた方が早いかもな。
でも、そんなことせずとも、ここでちゃんと解説されてる。
http://boost.cppll.jp/HEAD/libs/libraries.htm

>>459
正規表現のドキュメント古すぎ

とびっきりのスーパーテクニックが載ってる本も楽しいだろうけど、
単純に学習時間を短縮できるような本だってあってもいいはず。

>>460
日本語訳プロジェクトに参加した事もない癖に、つべこべ文句を言う資格は無し。

>>462
べつに文句は言ってないと思うぞ。本当のことを言っているだけで。

つーか買う必要があるかどうかくらい自分で確認して自分で判断しろ。
誰もてめーの欲しがる本のレベルや内容なんて知らねーんだよ。
そして駄本だと思ったらいつまでもぐだぐだ言うな。
紹介したけりゃ良書の紹介しろ。

>>463
そういうのを文句って言うんだ。頭冷やして出直せ。

だから日本語訳が古いと思えば、英語のドキュメント読めよ。
誰かさんと違ってボランティアで翻訳やってるんだからよ。
フリーウェアに対しては文句言うな。
文句言えるのは有償のものだけ。

>フリーウェアに対しては文句言うな。
なぜだ？別に改善を要求してるわけじゃないだろ？

稲葉 vs http://boost.cppll.jp/HEAD/libs/libraries.htmの訳者
ってことですかね。
メールでやれ

>>465-446
…。フリーウェアに対して文句が言えなくなったら、
その時点でそれ以上の発展は望めないよ。
あ、「ここはこうしたほうがいい」って言えば文句にはならないのかな…

翻訳者の皆様、いつもご苦労様です。
正規表現のドキュメントが古いようです。新しいモノに対応してくれると助かります。

って言い直す。
ちなみに、Boost本の正規表現の項目は新しいほうのもの。
これはすごい助かった。INABAさんありがと。

>>399を叩いている奴がいるが、
>>399のアマゾンでの評価は納得できるから、
>>399は身銭を切って本の評価をしてくれたと考えることもできる。

まぁその程度の評価なら立ち読みでわかるけどな。

これ以上は書籍スレでやれよな

だよな。

書籍スレは「推薦図書」だから罵倒したいだけならあっちでもやるなよ。

>>468
この一連のレスをみれは、どうみても違うって、
稲葉叩いているのはboostを触った事も無いようなタコだろ
微妙におかしな論点になってるじゃん

おまえ才能もセンスも無いんだからプログラマは諦めろ >399

>>469の馬鹿へ
オリジナルの英語の外仕読んで使い方のわからんカスがboost なんか使うな。
お前みたいなアフォが居ると周りのものが迷惑するんだよ。

>>470
というか俺には>>399が書いたって言うのは嘘だとしか思えんのだが？

>>476
はいはい、気がすんだら首つって死んでろ

>>478
お前は5階から中学生に突き落としてもらえ。

>>479
わかったから、age んな

頼むから>>399
http://pc5.2ch.net/test/read.cgi/tech/1085915001/
この辺でやってくれ。お似合いだから

>>476みたいな英語談義に持ってく奴も毎度お馴染みだな。

>>469
普通、邦訳ドキュメントが古いと思ったら英語であればオンラインの原文読むだろ。
それを本が出版されるまで待ってること自体、お話にならんな。どんな仕事してるんだ？

>>467
フリーウェアに対して許されるのは依頼だけ。
文句は許されない。嫌なら使うな。読むな。
文句言う奴がアフォ

　　　ただいまスレ違い甚だしいレスが続いておりますがご了承ください。

↑　お　前　も　な

>>483
阿呆やなぁ。
Boost の裾野を広げるには日本語で十分な Document があることは必須やろ。
あと、
> それを本が出版されるまで待ってること自体、お話にならんな。
って、>>469 のどこをどう読めばそういう解釈になるのやら。

つーか、ここは /. の出張所ですか？

>Boost の裾野を広げるには
何勘違いしてるか知らんが、boostの裾野なんか広げる必要は全くないね。
使いたい奴が自分の能力に合わせて使えばいい。くだらんライブラリも実際あるしな。
布教活動でもしたいのかい？

>>469=487
>って、>>469 のどこをどう読めばそういう解釈になるのやら。
他人のふりするな。

ユーザーが多ければ有用な情報や良書がでる確率が増えるだろうな。

C++スレでも暴れ足りず、今度はtemplateスレを荒らしているC厨がいるという
スレはここですか？

>>489
変な解釈したことは否定しないんだな

諸悪の根源は>>399

　　　　　　　まもなくここは　乂1000取り合戦場乂　となります。

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　boost本で1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　 　 　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　 （　　　　）　　　 （　　　　 ）　　　（　　　　）　　　 ）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）

393の導火線があるな。

>>494
もうかよ?!

たしかに>>393もアレだな

結局、3000円弱を出費する価値があるのかないのかどっちよ？

>>498
だからてめーにとって価値があるかどうかが何で俺らにわかるんだタコ。

>>499 糞レスわざわざ書き込むな

>>484
なぜだ？と聞いてるのに主張を繰り返されても…

なぜフリーと商用を区別するのかわからない（サポートの話ならともかく、「文句」に関して）。
好きでやっているか金を取っているかの違いしかないだろ。
それともお前は「フリーウェアを好意に甘えて使わしてもらう」という
態度が正しいと思うのか？

>>500
せっかくの500がおまえのような糞レスでがっかりだ！

>>501
馬鹿か？お前？

フリーソフトの話にまで広がったか・・・

フリーに対して文句言ってもそれは文句言う側の勝手だろうが、俺がフリーの
開発者だったら文句言う奴は叩き潰す。

俺は放置する。相手すんのめんどくさいもん。

>>501
>フリーと商用を区別するのかわからない
わからなければ死ねよ。

>馬鹿か？お前？
ﾜﾗﾀ

それはともかく皆さんお風呂の時間ですよ。

もう馬鹿とか死ねとかしか出てこないスレになりました

いや、俺はこれから飯だ

手淫はまだ早いかな。

>>501
自分で金稼げるようになってからゴタク並べな。ガクセイちゃん。

文句や依頼をするのは勝手だが、作者がそれに対応するかどうかも作者の勝手だ。それでいいじゃないか。

いや、文句言うこと自体マナー違反だ。負担にならないように依頼、お願いすべきもの。

>>514
DQNにマナー要求しても、無駄。行動で示すしかない。

そうそう、>>514は正論だがDQNユーザーがいるのが現実。

>行動で示すしかない。
どうするんだ？

IDがでなくても連鎖あぼ〜ん

さらしあげ

>>517
具体的に書いたら通報されるので、書けない。

つまりぬっこｒ

つまりぬっころs

ぬっころ？ピッコロじゃないのか？

なんじゃこのスレ

ちょっと見ないうちに掃き溜めに鶴になってるな

>>524
意味わかってるよな？

Aransk先生がC/C++に興味をもたれたようです。
http://homepage3.nifty.com/Aransk/contents4.html

>>526
絶妙なタイミングで変なネタもってくるんじゃねーよこの、チョンマゲ

>>527
へんなネタって何です?Genericクラスに関するＨＰですよ

>>526=528=Aransk

死　ね

>>528
はいはい反応した俺が悪かったですよAransk大先生。
とりあえず氏んでください。


俺も吊ってきます。反応してﾜﾙｶﾀ。

(´-`).｡ｏO(相談室からとびひしてるのかな?この雰囲気)

夏厨が湧く次期だからな。高校は休みに入ってる所があるし。

おいおい、6月からマジかよ

>>532
嘘コケ!お前が個人的に休暇とってる引きこもり高校生だろが。

むしろヒキコモリオヤジなよかん

>>534
私立の高校ならもう期末テスト終わって休みに入ってる所があるよ。
>>535
( ﾟДﾟ)ﾊｧ?オヤジはお前だろヴォケ。

なんだこのスレ

まだやってんのかよ('A`)

初心者本があるお陰で、boostの裾野が広がる
メリットが開発人にはあるから、ここでｳｻﾞｲ連中よりましかと思いますた。

そうですね。

　終　了

>>539
自書の宣伝ごくろーさん

そんなこんなでシツモンデス

boost::funcitonとかboost::shared_ptrなんかはoperator boolじゃなしに
なんかメンバへのポインタを返すキャスト演算子をつかって

function<void ()> f;

//チェック
if(f){
f();
}

のようなことをやりますが、なんでoperator boolじゃないの？
safe bool idiomとかでいろいろ調べたがわからなかった・・・

ちなみにfuncitonの場合だとboost/function/funciton_template.hpp４００行目くらいの
operator safe_bool () constの周辺のやつね。
shared_ptrはoperator unspecified_bool_type() constのへん。

boolは整数型に暗黙の変換が成立してしまうから

>>542
struct Hoge {
  struct dummy { void nonnull() {}; };
  typedef void (dummy::*safe_bool)();
  operator safe_bool () const { return (this->empty()) ? 0 : &dummy::nonnull; }
  //operator bool () const { return !(this->empty()); }
  bool empty() const { return false; }
};
int main()
{
  Hoge hoge;
  int a = aho +1;
}
でbool の場合と safe_boolの時とでコンパイルしてみれば分かると思うけど、
後者だとintに暗黙の変換がされないからコンパイル時にエラーになってくれる、と。

ぐは、激しく遅くしかも冗長だった…スマン。

しかもミスまで…逝ってくる…
s/aho/hoge/

>>542
boost 本に載ってるよ。

boost本をばかにした者はboost本に泣く。

著者さんよ。嘘も休み休み言え、もうさんざん濡れ手に粟を味わったんだから被害者増やすな。

>>549
悔しかったら君も本を書いて売ってみたまえ。

次にお前は「誰が悔しいなんて言ったよｗ」という！

呼び水あげ

しかしよくネタにマジレスできるもんだな

ネタにネタレスであることがわからんかねチミ

病人を相手にしないように>ALL

なるほど。分かりやすい説明ありがとうございます。

int a = aho +1;
というのは気づかなかったです。

>>544
typedef void (dummy::*safe_bool)();
はprivateじゃなくていいの？

shared_ptr,scoped_ptrはpublicになってる(バグか？)が、
functionはprivateになってた。

void test(bool b)
{std::cout << "bool" << std::endl;}
//そもそもこれをやるやつはいないだろうが...
void test( Hoge::safe_bool f )
{std::cout << typeid(f).name() << std::endl;}

test(hoge);//だと後者が呼ばれる。

>>557
いや、別にpublicとかprivateとか書くと行が増えるから、とりあえず例として
struct にしただけなんで…

>>558
ああ、543のわかりやすい例としてね。修正するとこんな感じか。
struct Hoge {
private: struct dummy { void nonnull() {}; };
typedef void (dummy::*safe_bool)();
public: operator safe_bool () const { return (this->empty()) ? 0 : &dummy::nonnull; }
//operator bool () const { return !(this->empty()); }
bool empty() const { return false; }
};

boostの該当箇所はここかな。
boost::shared_ptr<int>::unspecified_bool_type a;//public
boost::scoped_ptr<int>::unspecified_bool_type b;//public
//boost::function1<void,int>::safe_bool d; //private

失礼します。

C++で正規表現したいなと思ってboostのregexを使っているのですが、
マルチバイト対応で組もうとするとコンパイルが通りません。

環境はVC++6.0です。

std::wstring source =L"アルファベットを含むShift_JIS文字列";
boost::reg_expression<wchar_t> regex = L"[a-zA-Z].*[a-zA-Z]";
boost::match_results<std::wstring::const_iterator> results;
if ( boost::regex_search(source, results, regex) ) {
wcout << results.str(0) << endl;
}

上記のboost::regex_search(source, results, regex)のsourceの型が不正だと言われます。
何かここ以外で記述が足らないのでしょうか？
宜しくお願いします。

>>560
質問の趣旨は別にして、
それはマルチバイトじゃなくてワイド文字列ですな

あ、そうなのですか。
ご指摘ありがとうございます。

VC++6.0で

std::wstring s(L"hoge");
boost::wregex e(L".+");
boost::wsmatch m;
boost::regex_search(s, m, e);
boost::regex_match(s, m, e);

とやったらregex_matchでエラーが出るってのなら経験したが。
んで、
boost::match_results<std::basic_string<wchar_t>::const_iterator, boost::wregex::allocator_type> m;
だとregex_matchは通るが今度はregex_searchが通らない。

>>560
VCのサービスパックは入ってる？
うちでは動いたよ。

レスありがとうございます。

今までサービスパック入ってなかったので入れました。
でも、結果は同じでした。

: error C2665: 'regex_search' : 10 のｵｰﾊﾞｰﾛｰﾄﾞは 1 番目の引数を
'class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,
class std::allocator<unsigned short> >'
から要求の型に変換できません。(新しい機能 ; ﾍﾙﾌﾟを参照)

プロジェクトを作り直してみます・・・。
他に何かヒントがあったら、またお願いします。

つーか、boostのバージョンとSTLの種類ぐらいかいとけ

>>560,565
boost::wregex

If you are building your application with /Zc:wchar_t then you will need to
modify the makefile to add /Zc:wchar_t before building the library.

>>563
これならVC6とVC71で通るはず。

std::wstring s(L"hoge");
boost::wregex e(L".+");
boost::wsmatch m;
#ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING
boost::wsmatch m2;
#else
boost::match_results<std::basic_string<wchar_t>::const_iterator,
boost::wregex::allocator_type> m2;
#endif
boost::regex_search(s, m, e);
boost::regex_match(s, m2, e);

おはようございます。

566>>
ご指摘ありがとうございます、BOOSTのバージョンはboost_1_31_0です。
STLの種類というのは使用しているnamespaceの事なのでしょうか？
それならばstdのみを使用しています。

>>567,568
ヒントありがとうございます。

>>569
動きました！！ありがとうございました！！
何がいけなかったのか自分なりに考えてみます。
ホントに助かりました、ありがとうございました。

STLの種類ってのはVC++だとVC++付属のものかSTLportかってこと。

何が悪いってそりゃバグだらけのVC++6.0が悪いんだが。
それをboost/regexがフォローしきれてないだけ。

>>571
ありがとうございます。
なるほどぉ・・・。

>>570
たぶんバグくさいな。(VC++6Sp6,Boost1.31+公式regexPatch)
[boost/regex/v4/regex_match.hpp]に以下の
関数を追加してしまえば、563でも動くようになる。
//追加関数Patch
inline bool regex_match(const std::basic_string<wchar_t>& s,
wsmatch& m,
const wregex& e,
match_flag_type flags = match_default)
{
return regex_match(s.begin(), s.end(), m, e, flags);
}

ソースのこの関数の定義の上に上記の関数を追加。
inline bool regex_match(const std::basic_string<wchar_t>& s,
match_results<std::basic_string<wchar_t>::const_iterator, wregex::allocator_type>& m,
const wregex& e,
match_flag_type flags = match_default)

教えてください。
ループのアンロールで速くなるっていうのはLoop処理のオーバーヘッド(ループカウンタのデクリメント
、条件分岐)と比較して、繰り返し処理の内容が小さいときに限られると思うんだがどう？
処理内容が数命令なら効果は絶大。でも大きい処理内容の場合はほとんど効果なしだと思うんだけどな？
実際、アセンブラでプログラムする場合はアンロール(というよりべた書きと言ってる)は
常套手段で、べた書き部分を吐くperlを書いたりしてたんだけど。。。
ループのアンロールっていうのは速くなる以外になんかメリットってある？
むしろデメリットの方が多いような？

高速化の手法に速くなる以上の意味が必要か？

ループのアンロールに関してはループ処理のコストがどうこうよりも、
条件分岐がなくなることで分岐予測が不要になる、ってのが最近のCPUに
とっては重要だと思うが。

タイトなループでなければ不用ってのは当然スギ

>>574
その考えで合ってるんじゃないの？
条件分岐のペナルティは大きかったから、それを減らしたかった。
また、アンロールすることでイタレーションに跨る最適化が行えるようにもなる。

最近のCPUはペナルティを小さくできてるし、コードサイズが大きくなることでキャッシュ
ミスをし易くなるのでアンロールした方が速いとは限らない。

実際に計って速い方を選ぶべき。

>>574
templateと何の関係が？

>>577
下のようにtemplateをunrollに使う話もありますよ．574さんは言及してませんけど．

template<size_t N>
double in_prod(double *a, double *b)
{ return a * b + in_prod<N - 1>(a + 1, b + 1); }

template<>
double in_prod<0>(double *a, double *b)
{ return 0.0; }

double a[3], b[3];
double x = 0;

x = in_prod<3>(a, b);

// 以下のコードに相当
//for(int i = 0; i < 3; ++i){ x += a[i] * b[i]; }

>>575
>ループ処理のコストがどうこうよりも、条件分岐がなくなることで分岐予測が不要になる

高速処理が必要な場合にループ内部に条件分岐を紛れ込ませること自体ご法度だろ。

ループの終了判定自体が条件分岐だヴォケ

>>579

>>578
無茶な話だな。どれくらい無茶かと言うと、
Cスレで「教えてください。ミサイルの弾道計算なんですが・・・」と始めて、
「Cと関係ないだろ。ぼけ」と突っ込まれて、
「弾道計算にCを使う話もありますよ」というくらいに無茶だ。

ほんと例え話好きだよなぁ

「どれくらい無茶か」の説明をするのに
無茶さを10倍に増やした例を持ち出されても、
ああ、この人必死なんだな、としか思えませんね :-P

>>580
ループの処理内容に条件分岐さえなければ、カウンタの終了判定でパイプラインが乱れることはない。
それと君はハードウェアループは知らんだろな？

>>582
578の例のどこが無茶な話なんだ？

アンロールした結果をC++ソースとして確認できないのがあれだな。

>>585
ループの条件分岐にペナルティがあるからこそ、ハードウェアループという
発想になるのだが…。

>>585
なんか、一部のアーキテクチャのプロセッサを想定してないか？　一般論として、
カウンタの終了判定でパイプラインが乱れないとは言えんでしょ。

>>585
> それと君はハードウェアループは知らんだろな？
ハードウェアループを使うとループ終了判定のペナルティはなくなるが、
ループのネスト数に制約がつくし、ループスタックを深くすると、今度は
コンテクストスイッチのオーバーヘッドが大きくなる。

DSP には適してるが、汎用言語・汎用 OS 向きの仕組みじゃないと思う
けどなぁ。そのへんどううよ？

も一つ追加。ハードウェアループを使うと、ループ末尾付近での分岐命令の
利用にも厳しい制約がつくよね。

ループの条件分岐のペナルティというのはループカウンタのデクリメント、
条件判断に要するオーバーヘッドのことであって、あらかじめ確定した
繰り返し処理でパイプラインが乱れることはないよ。終了判定が処理を実行
しないと決まらないような場合は別だけど。
で、ループ内部に条件判断がなくて、ループ処理のオーバーヘッドが問題に
なる場合っていうのは、極めて簡単な処理に限られると思うんだが？

>>588
パイプラインを自分で作ってみればわかると思うよ。簡単にできるからやってみれば？

>>592
サクッと参考文献なりソースなり示してもらえると話が早いかと。

>>591
小さな、たとえば 4x4 程度の行列を操作するようなケースでは、
ループ展開できると効く。もっとも、最近のプロセッサだと SIMD
命令使って計算することになるから、あまり関係ないが。

>>590
当然、ハードウェアループは処理内容だけじゃなくそれに収まる命令サイズ
も制限を受けるよ。そうであっても効果があるから使う。
しかもループのネストできるアーキテクチャなんてあるのかな？
調べたことないので知らない。

>DSP には適してるが、汎用言語・汎用 OS 向きの仕組みじゃないと思う
>けどなぁ。そのへんどううよ？
それもわからない。けど、シビアにクロックを削減したい用途であることは
間違いないと思う。そこまでシビアなクロック数を要求するアプリケーションが
汎用CPUにあるかということだね。
ただ、数値計算が主体でもないのにマッチドフィルタ/ベクトルプロセッサ
を載せてるCPUもあるぐらいだからね。まぁこっちの方が載せる価値があると思う。

いずれにせよ C++ template 統合スレ向きのネタではない気がしてきた。

>>596
どういうときにtemplate でunrollするのが得かって話だろ？
ジェネリックプログラムにぴったりなんじゃないの？

>>593
マジ？HDL書きたい？
確かに、
アプリのローカライズやったり、
営業まがいのSEやるよりやりがいはあると思うし、
人手不足で引く手あまたの業界ではあるが。

>>588
>カウンタの終了判定でパイプラインが乱れないとは言えんでしょ。
パイプラインに乱れはないが、そんなことを考える君の脳みその乱れが心配だ。

Modern C++ design の訳本を遅ればせながら読んでみた。
寝転びながら斜め読み。15ページぐらいですっかりわからなくなった。
気合入れなおして行きつ戻りつしつつ2度程読み直してようやく納得できた。ひぇー。
これめちゃ注意しながら読まないとわけわからなくなるじゃん。
内容が難しいのかそれとも笑福亭鶴瓶やあのねのねの後輩にあたる訳者のせいなのか
一番問題はおれのおつむか？
これ原書はどうよ？
C++ templates の方が読みやすいじゃん。Modernの方が簡単だとばっかり思ってた。

errataにも目を通す事をお勧めする。

fedra core 2にはBoostは最初から入ってますでしょうか？
グラフクラスを使いたいんすけど

STLport-4.6.2
make allでiostreamのコンパイルはできんだけど
make installできないYO… なんで( ;´Д｀)？

あ、コンパイラはVC7.1のです

nmake -f vc7.mak
じゃないのか？

自己解決しました… スレ汚しｽﾏｿ

>>599
だからソースだそうよ

ｽﾚ汚しついでに…
コマンドラインでcl.exe(VC7.1付属)を使って直接コンパイルしてます

(1) STLPort static lib
#define _STLP_DEBUG 1
#define _STLP_USE_STATIC_LIB 1
#include <iostream>
の順に記述してるのにLIBCMT.libで定義されてるからリンクできないって出てしまいます…
LIBCMT.libを使わなくするにはどうすれば良いんでしょうか？

(2) 標準iostream使う時
#define _STLP_NO_OWN_IOSTREAMS 1
#include <iostream>
にすると、
C++例外処理を使っていますが、ｱﾝﾜｲﾝﾄﾞ ｾﾏﾝﾃｨｸｽが有効にはなりません。-GXを指定てください。
と言われます… たしかに-GX使うとコンパイル通りますけど、そういうもんなんでしょうか？

また、(2)のケースではstrportディレクトリをinclude pathに入れてはいけないのでしょうか？


(1)(2)いずれもmain関数のみで、内容は以下です
int main(int argc, char* argv[])
{
　　std::cout << "Hello World." << std::endl;
　　return 0;
}

1 -MD =MTd等
2 マニュアル読め

>>607
ホレ
http://www.bulldog.co.jp/news/image/030820_yourb_02.jpg

>>40-41
boost::pool_allocatorは開放して再確保する時に速いからその方法じゃ比較になってないと超亀レス

#include <string>
using namespace std;
string work="hoge";
char array[10];
strcpy(array,work.c_str());

上のコードで３行目のstrcpyで
error C2668: 'strcpy' : ｵｰﾊﾞｰﾛｰﾄﾞ関数の呼び出しを解決することができません。(新機能 ; ﾍﾙﾌﾟを参照)
と怒られてしまいます。
本等を見てもこれで通るはずなのですが・・。
解決策があったら教えてください。

VC++6.0でサービスパック６です。

#include <cstdio>

あｄｇつぁひゃｓｄｆは

× #include <string>
○ #include <string.h>

その前にスレ違いじゃないか？次からはCスレにGO!

>615・・・

よく見てなかった。std::stringクラスも使ってるのか

#include <string> //std::stringクラスなどを使う時にインクルード

#include <cstring> //string.hの代わり、strcpyのなどを使う時にインクルード

わかりました。
レスどもでした。

std::setをこんな感じで定義しておいて、

set<int, less<int> > myset;

後でCompareオブジェクトを降順用のに切り替えることってできませんか？

boost1.31をコンパイルしたらこんな種類のエラーがいっぱい出たよ…
無視していいのでしょうか？

posix_api.obj : error LNK2001: 外部シンボル ""private: unsigned int __fastcall b
oost::cpp_regex_traits<wchar_t>::do_syntax_type(unsigned int)const " (?do_syntax
_type@?$cpp_regex_traits@_W@boost@@ABIII@Z)" は未解決です。
bin\boost\libs\regex\build\boost_regex.dll\vc7.1-stlport\release\threading-multi
\boost_regex-vc71-mt-p-1_31.dll : fatal error LNK1120: 外部参照 1 が未解決です。

実行したコマンドは
bjam -sTOOLS=vc7.1-stlport --prefix="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7" install
です

>>619
そのままじゃ無理なんで、昇順降順を切り替えられるファンクタを用意して渡す

>>621
その前にsetの実装を調べた方がいいよ。
Compareを使っている場合があるから。

>>619
比較関数が途中で変わったら内部が混乱して思ったとおりに動かなくなるよ

まあ動いたとしても標準範囲外の動作だわな。
>>619は何をやりたいのか書いてみれば?

ところで、boost::spirit による各言語の
実装のリンク集はどこかご存知だろうか？

以前どこかで見かけたんだが、今探したら見つからず。

>>625
これ？
http://spirit.sourceforge.net/repository/applications/show_contents.php

他にもあるなら俺もキボン

設計を考え直したほうがいいかと・・・
普通に内部ぶっ壊れるし、壊れなかったとしても実装依存じゃないかな。

つか、templeteなんて必要なることある？

>>628
PCなんて必要になることある?
(=使ったことがない人には実感がわかない)

>>628
yes. 使い始めると止まらない止められない終わらない

c++はtempleteが無ければstringさえ使えないぞ

C++はtemplateが無ければcoutさえ使えないぞ

それはない

ICUってどうよ。

集中治療室？

>633
cout の型は ostream
ostream は basic_ostream<char, char_traits<char> > のtypedef

basic_stringとかbasic_*streamはSTLができてから
あと付けでstringとstreamを対応させただけ

>>637
んなことは誰でも知ってる。
昔話は他でやってくれ。

つーことで、coutが使えないということではない。

>>639
すぐに便利な例というと、むしろ st::auto_ptr とか std::vector とかかねぇ。

そういうことを言いたいわけではない。
俺が言いたいのはtemplateを使って実用に耐えれるようなクラスを
書けるか？ということ。
俺は職業上ながいことC++やってるがまともにtemplateクラスを
かける奴見たことないぞ。std::stringですらお遊びプログラマでは
かけないとおもう。

テンプレートは汎用データクラスで使うもんだから、自作って必要ない気がする
過去ログ読んでないからずれた事言ってたらスマソ。

クリエイティブな仕事をしない限りは必要ない

>>643
採算性がないってこと？

>>628 自身は、自分でtemplateを使う/使えるのか？
使うのだとしたら、周りのレベルの低さを愚痴っているだけじゃないのか？

少なくとも、スマートポインタ周りはtemplateを使ったほうが楽なんじゃないかと思うが。
（自作するにしろ、拾ってくるにしろ）

単に、>>641もその周りのプログラマも能無しぞろいってだけのことじゃん。

必要ないならいらねーわな

>>642
10年前からきた人でつか？

＞俺は職業上ながいことC++やってるが

ﾌﾟｹﾞﾗ
まぁC++の歴史を考えると、長いもクソもないだろう。

型を問わない処理を書こうとすると、templateが欲しくなる。

なんでもかんでもtemplate化していくと
それはそれで美しくないことに気づくジレンマ

あれでしょ？関数のオーバーロードが面倒なときに書くんでしょ？

それはタイプセーフという利点を捨ててるだけだよな。
それを回避しようとtraitsなんかを導入してどんどん複雑化するし。

志は低いけど、間違ったアプローチではない罠。

C++にタイプセーフを期待しちゃいかんよ
仕様に読み勝ってこそのC++、ちゃんとOOPやりたきゃJava行く

質問です。
テンプレートの特殊化を行うとき、同じ型のものを別々に特殊化したいときは
どのように実装するのがスマートなのでしょうか？
例としては、こんなかんじに扱いたいのです。
----
template <typename T> class X
{
const T PI;
// some method ...
};
typedef float Degree;
typedef float Radian;
template <> const Degree X<Degree>::PI = 180.0f;
template <> const Radian X<Radian>::PI = 3.14f;
----
現在は、
----
template <typename T, int UNIQ> class XCore
{
public:
XCore(const T& t) : m_t(t) {}
const T& operator() const { return m_t; }
private:
T m_t;
};
typedef XCore<float, 0> Degree;
typedef XCore<float, 1> Radian;
----
とやっているのですが、いまいちその場しのぎなかんじがしてます。
そもそもの設計がまずいのでしょうか？

あのさー、うどん食いたいならうどん屋行こうよ
なんで態々ラーメン屋いって、無理やりうどん
つくらせるかな〜？

boostのarrayってちょっと便利だな。

boostって次回の改定で標準になるの？

template < typename TYPE, typename UNIQ >
class XCore {
const TYPE PI;
};

class Degree {};
class Radian {};

template <>
const XCore< float, Degree >::PI = 180.0f;
template <>
const XCore< float, Radian >::PI = 3.14f;

enumの方がいいですかね？

なんでPIに度を入れるの？
どちらかがどちらかを継承して必要な部分をオーバーライドでいいじゃん

>>656
どちらかがどちらかを継承するというのは、具体的にどういうコードになるのでしょうか？

補足すると、class X はそれぞれで定義された PI の値を使用してメソッドを組み立て、
最適化が効くものだけ特殊化しようと考えていました。
0 <= angle < 2*PI に正規化するメソッドであれば、
template <typename T> class X
{
public:
const T PI;
void normalize(){
while(m_angle < 0) { m_angle += PI * 2; }
while(m_angle >= PI * 2) { m_angle -= PI * 2; }
}
private:
T m_angle;
};
template <> const s32 X<s32>::PI = 0x8000;
template <> void X<s32>::normalize()
{
m_angle &= 0x0000ffff;
}

いやテンプレート使うようなものじゃないし
ラジアンクラスを継承した度クラスでいいのでは？
PIはPIだよｗ

>>663
継承を使う場合は、float や int といった実際の型に縛られると思ったので
template にしたのですが、何か勘違いしていたでしょうか？

>>660
たしかに PI の値は X ではなく、Radian/Degree の型のほうにもたせたほうが
意味的にもすっきりしますね。というわけで書き直してみました。
前より意味がとおりやすく、すっきりしたコードになった気がします。
ご意見ありがとうございました。
----
template <typename T> class X {
public:
X() {}
X(const typename T::ANGLE& angle) : m_angle(angle) {}
}
private:
typename T::ANGLE m_angle;
};
template <typename T, typename UNIQ> class AngleCore {
public:
typedef T ANGLE;
static const T PI;
};
class Angle32Tag {};
class DegreeTag {};
class RadianTag {};
typedef AngleCore<int, Angle32Tag> Angle32;
typedef AngleCore<float, DegreeTag> Degree;
typedef AngleCore<float, RadianTag> Radian;
const int Angle32::PI = 0x8000;
const float Degree::PI = 180.0f;
const float Radian::PI = 3.14f;

class Angle32 : public AngleCore<int, Angle32>{};
const int AngleCore<int, Angle32>::PI = 0x8000;

あれ？ template<> っているんだっけ？
なくてもコンパイルできるんだけど一応。
教えてエロい人。

floatなんて使うな。

>>628
Modern C++ Design 嫁。
template クラスのスパゲッティに笑える。

templateは友達

>>663 PIとは半周期の事だとおもわれ。

PIとはピだろ

プチインターネッツです

ぷちこInterface

何か視点がちがくね？
Degree::PI +Radian::PI が計算できちゃうし。しかも意味のない数字になっちゃう。
クラステンプレートにする意味が・・・

float degree_pi : Degree;
float radian_pi : Radian;
みたいにセマンティクスで拘束できたら楽なのにな。

C++だとこんな感じで書けるようにすればいいんでないかな。
semantic_numeric<float,Degree> degree_pi;
semantic_numeric<float,Radian> radian_pi;

どうでもいいけど、πは3.14（ｒｙの定数のことで、
半周の角度の事ではないと思うんだが。

おまいら、そんなにコンパイラいじめて楽しいか？

>>676
ha?

コンパイラにいじめられてる訳ですが…
いや、自分が悪いんだけどさ…

>>675
なんとなく思うんだけど、これって単位の問題だから
基底ベクトルクラスと直積・直和を考えた方がもっとスッキリしそうな気がする。
Modern C++ Design の一番最初に出ている例みたいな感じとかとか・・・

僕ぁ使わないと思うけど・・・(あんま気にならないクチなので)

>Modern C++ Design の一番最初に出ている例
って？

前ｽﾚの895参照。

最近VC7買ってboost.spiritを勉強し始めたんですが
いきなりlexeme_dとかでつまづいてしまいました･･･

日本語のサイトとかBoost本とかは見てるんですが、
この際英語でもよいのでどっか詳しい解説ページとかないですかね？

>>683
公式ドキュメントはどうした？

>>684
書き忘れましたが公式ドキュメントもちゃんと読みました。

せっかく(？)だから直面した問題も書いておきます。

Cプリプロセッサみたいなのを作ってみようと
こんなParserクラスを作ってみました。

Parserクラス(すごい簡略化してますが)
{
　rule<ScannerT> ident, filename, include, value, translation_unit;
　ident = +((alnum_p) | '.');
　filename = '\"' >> ident >> '\"';
　include = "include" >> filename;
　value = int_p;
　translation_unit = +(include | value) >> end_p;
}
Parser parser;
parse(first, last, parser, space_p);

上のだとコンパイルも通るんですが、これだとfilenameルールのところで
”(ダブルクォーテーション)とファイル名(identルール)の間にスペースを入れることが出来てしまいます。
そこでこれを回避するためにlexeme_dディレクティブを使って、
　filename = lexeme_d[ '\"' >> ident >> '\"' ];
としたところ、
error C2664: 'boost::spirit::rule<ScannerT>::parse' : 1 番目の引数を 'const boost::spirit::scanner<IteratorT,PoliciesT>' から 'const scanner_t &' に変換できません。
というエラーが出てしまいます。

たぶんlexeme_dの使い方に問題があるのかと思うんですが、
なにぶんspiritに関する情報が少ないもので･･･

>>685
lexeme_dの外部のscannerと内部のscannerで型が変わるので，
directive内部のruleの型を変えないとならないです．
その例ではidentを
rule<typename lexeme_scaner<ScannerT>::type> ident;
（その書き方だと多分typename必要ですよね？）と宣言しなければなりません．
詳しくはhttp://www.boost.org/libs/spirit/doc/faq.html#lexeme_and_rulesか
http://www.boost.org/libs/spirit/doc/scanner.html#lexeme_scannerを参照してみてください．

後，蛇足になるとは思いますけれど，複数のscannerをサポートしたruleを作る
scanner_listなる機構も用意されています．
http://www.boost.org/libs/spirit/doc/rule.html#multiple_scanner_support

>>686, 687
回答ありがとうございます。

identルールのみ↓のようにしたところ、
コンパイルも通り、期待の動作をするようになりました。

Parserクラス(すごい簡略化してますが)
{
　rule<ScannerT> filename, include, value, translation_unit;
　rule<typename lexeme_scanner<ScannerT>::type> ident;
　ident = +((alnum_p) | '.');
　filename = lexeme_d[ '\"' >> ident >> '\"' ];
　include = "include" >> filename;
　value = int_p;
　translation_unit = +(include | value) >> end_p;
}

しかし公式ドキュメントちゃんと読んだとか言ってて全然読めてませんね。
もうしわけない･･･

Modern C++ design 難しすぎ。もっと簡単なコードサンプルから順に掲載してよ。

>>689
そんなあなたに C++ Templates。本が厚い分だけ丁寧に解説してるぞ。

>>690
それ邦書で出ないかなぁ

>>689
http://mulberryl001.ddo.jp/~paserry/

>>691
C++ Templates の英語は義務教育終わってるなら絶対読める。
Modern の方は訳本しか持ってないんだけど、これ訳の程度はどんなもん？
難しくしてるのは訳のせい？それとももともと難しいの？

あれは難しいんじゃない。
説明の仕方が糞なんだ。
邦訳しか読んだことはないが、
訳者がよっぽど変な訳し方してない限り、原文も糞だと思われ。

>>694
ん？
各章の話題の振り方とかその引っ張り方とか見ると、
そんなに説明下手とは思わんが？

あれはやっぱり翻訳に難ありと見た。
もっともオレも原書見てないから確実なことは言えんが。

プログラムのセンスがなくて読めないんだよ
どこがどのように糞なのか書けなさそうだしね

>>696
こんにちは、訳者さん。
どう糞なのか説明してあげるから全ページｷｬﾌﾟしてｳpしてね。

なんでオレが訳者になるんだよ、頭病気じゃねぇの

人が分からないものを分かったつもりになって相手を見下すのは
厨の常套手段だからな。

>>696
俺は訳本しか持ってないんだけど、
サンプルコードの解説文がわけわからないこと多数。特にカタカナ表記の単語
が数多くあって、それがあんまり日本語になじみなくて、言ってることがわから
なくなったりする。俺だけかな？適した訳を考えるのが面倒なのでえーいそのまま
カタカナにしてしまえって感じかな？コンピュータ関連本はだいたい似たり寄ったり
だけどこれはちょっと度が過ぎてるように思うんだけどね。
それと、これはたぶん原著がそうなんだろうけどプログラムのセンスというより
前後の断片化されたコードを忍耐強くつないでいくような読み方を要求される。
どうせならLokiの解説に徹したほうがよかったんじゃないのかね？
あといきなり面食らったのは
1.8節にはいっていきなり
だいぶんよくなってきました。
ってかいてあるんだけど、これ何？何が良くなってきたの？
C++ Templatesの方が間違いなく読みやすいと思うけどね。

この場合、そんな妄想は必要ないですよ。
実際、分からない奴が人並み外れて馬鹿なだけですから ;-)

読んでわかるかよりも、自分のコードの適所で応用できるかが大事だからね。
Modernのサンプルコードですんなりそれができる人は神だな。
言語仕様として初めからこういう使い方想定してたらもうちょっと違った形になるんと違うか？
と思うんだけど、どう？

理由をみている限りサンプルコードとかそういう問題以前に問題がありそうな気が・・・

わかる奴は偉い。素晴らしい。
でも
わかった気で実はなーんもわかってないというのは恥ずかしい罠

>サンプルコードとかそういう問題以前に問題がありそうな気が・・・
いや、サンプルコートも実に複雑だと思うが。

ｳpﾏﾀﾞｰ? ﾁﾝﾁﾝ

>>702
Modern C++ Design が行った問題提起は、普通は詰まらない物として考えない
小さな部品を組み合わせてできる物の全体像を再度認識させた所にあると思う。
この点について、この本以前の言語の利用ノウハウ書では見た事がないです。
ちなみに応用ならライブラリーの解説書と言う事なると思うがどうか？
それが目的なら、ちょっと上にあるboost本こそが読むべき本だと思う。
この本は解説本ではなくノウハウ本だと感じるので。

boost本ってあの最近日本で出た奴のこと？
あれは読んでどうこういう本じゃないでしょ。単なるboostの外仕

これだけ引用の多いModern や C++ Templatesの話をしてるときにあんな駄本が引き合いに出されるとは思わんかった。

おまえにその駄本が書けるのか？
boost本と Modern C++ Design とは使用目的も違うだろ
そもそも、読んでないか読めてないだろ、お前
バカなんだから諦めろ

>>710
おおっとboost本の原作者さんのご降臨です。
宣伝ご苦労さん。

ちがうってよ、おりゃ生まれてこの方本なんぞ書いた事ネェ

>>711
「原作者」ねえｗ

>>710
使用目的も異なるし、計算機の書籍としての重要性も比較にならないboost駄本などを>>707が持ち出したから言ったまで。

>>713
それが何か？

キチガイはどっか逝け

喧嘩するなよ

有意義な議論したいなら人格攻撃とか駄本とか刺のあるような言葉使っちゃダメ

駄本は駄本だろ。

>>718
あんた精神病んでるよ

良著と駄本を分類することが精神病になるのか？

低脳信者共、乙であります。
Modern本はtemplateの活用を、
書籍の形にして広く紹介したことに意味があるんだよ。
だから、もはや役割を終えたんだよ。
そうなれば説明が糞なのが目に付くのは当たり前。
今となれば、あんな説明なら概説＋UML＋コード＋αだけの方がまだいい。

>>720
ならないよ、でも間違いなく頭イカレテルね
なんだろうね、この違いは
普通は分るね

↓普通って何ですかとか言うな

>>722
お前にはその程度の説明するのが関の山なんだろうな。
知　障　さ　ん

boost 本みたいな議論する価値もない本を引き合いに出すな。鬱陶しい。

商売には中身よりタイミングが必要だと教えてくれた貴重な書物だろ？

　　　　|┃三　　　　　　　　 　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　|┃　　　　 　　 　　　 　　／
　　　　|┃　≡　 　∧＿∧　　＜　議論と聞いちゃぁ黙っちゃいられねえ！
＿＿__.|ミ＼＿＿_（ ﾟ ε　。 ） _　＼
　　　　|┃=＿＿＿　　　　＼　　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　|┃　≡　　　）　　　人 ＼ ガラッ

いやいや中身は大切だよ。

一番売れるのは初心者向けだからね。それを教えてくれたよ。

なーんの関係もないboostのちゃちゃが入ってModernの議論は終わりか・・・
ちゃちゃ入れるな->稲葉君

Modernの原著はどうよ。--->読んだ人

伸びてると思いきやまたboostか。皆あの本好きだねぇ。

やっぱIDが出ないとだめだな

>>132
>やっぱIDが出ないとだめだな
お前のような自作自演が居るからな

　　　　　　　　　　　　
　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　_人
　 　　　　∩　　　　∧＿∧　　　　　　　　　　　　ノ⌒　丿
　　　　　　 ＼ヽ＿（　　　　） 　　　　　　　　＿／　　 ::（
　　　　　　　　　＼＿　　 ノ　　　　　　　　/　　　　　:::::::＼
　∩＿　　　＿／　　　 ／　　　　　　　　 （　　　　　:::::::;;;;;;;）
　Ｌ＿　`ー　/　/　　　/　　　　　　　　　　　＼＿――￣￣::::::::::＼
　　　　　ヽ　 |　|＿＿/ |　　 　　　　　　　　ﾉ￣　　　　　::::::::::::::::::::::）
　　|￣￣￣＼　　　　　ﾉ　えっと　　　　　（　　　　　::::::::::::::;;;;;;;;;;;;ノ
　　|　|￣「~|￣（ ､ Ａ ， ）とりあえず　／￣―――――￣￣::::::::＼
　　|　|　 |　|　　∨￣∨　　　　　　　　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　し'　　し'　　　　　　　　　　　　　　　　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　__
　　　　　　　　　　　　　　　　　　　　　　　　　>>1　 ｌ￣／.　 ＿__
　　　　　　　　　　　　　　　　　　　　　　　　　↓　/　/.　　/ ___ﾉ 　
　　　　　　　　　　　　　　　　　　　　　　　　＿＿/　/＿／　/　
　　　　　　なげときますね！　　　　　　Y人,　'　',人⌒ヽ､,　'
　　　　　　　　　　　　　　　　　　　　　　Y⌒ヽ）⌒ヽ､　人,ヽ）人'､,　'
　　　　　　　 へ, --- ､　　　　　　　　　ﾉ￣　　　　　::::::::::::::::::::::）
　 　 　/￣￣￣　 ､____＼　　　　　　　（　　　　　::::::::::::::;;;;;;;;;;;;ノ
　 　 / _/￣「~|＼　＿＿ ＼　　　　　／￣―――――￣￣::::::::＼
　　　|　|　　|　|　（ ､ Ａ , ＼ミｿ　　　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　　し'　　 し' と∨￣∨　　　　　　　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ

boost本が糞であることは地球ができたときから決まっていることなのに
なんで未だにこの本の話題が出るのか、俺はそれが不思議だ。

>>730
日本語訳は原著の文章の雰囲気をうまくつかんで訳せてると俺は思った。
少なくともCUJの記事とか色んなMLのログを見ればAlexandrescu氏の文の
書き方がどんなかはわかると思うんで、MC++Dの原文もそんな雰囲気。

>>735
> なんで未だにこの本の話題が出るのか
おまえが引っ張るからじゃないのか？

自分の英語力が相当ぁゃιぃのであれですけれど，
彼の英文って結構ユニークな書き方ですよね？（そう感じているのは私だけ？）

このスレではboost本に関してちょっとでもネガティブな批評があると
必ずスレの流れをぶち壊す方が居ますね。
なんか、ちょっと他の話題と異なる違和感を覚えるのは考えすぎでしょうか？

boost本は
やさしいBoostに改名すればいいんじゃないのかな。
初心者向けの本だし。

仰々しい名前をもった初心者本なんていくらでもあるのに
なんでboost本だけは叩かれてるんだろうか。
やっぱり期待が大きすぎただけじゃないか？

もういいよboost本なんて語るべきことなんもないじゃん。とっとと終わってくれ。

boost本で盛り上がってるとこ申し訳ないですが…

VC++7.1にSTLport-4.6.2をインストールした後、
boost1.31.0をビルド(bjam3.1.10使用)すると、cpp_regex_traits.cppの所で

disabling support for class cpp_regex_traits<wchar_t>
- rebuild with /Zc:wchar_t if you really need this

と出てしまい、その後regexのコンパイルが失敗してしまうんですが…
どなたか同じ現象に会って回避した方いらっしゃいますか？

>>743
Rebuild with /Zc:wchar_t if you really need this.

>>744
/Zc:wchar_tならregexのmakefile(vc71-stlport.mak)に最初から付いてるんだけど、
そうじゃなくてSTLportの方に付けてリビルドしろってことかいな？

でもSTLportを/Zc:wchar_t付きでリビルドして再挑戦したけど結果は変わらなかったよ…

error LNK2001: 外部シンボル ""private: unsigned int __cdecl
boost::cpp_regex_traits<wchar_t>::do_syntax_type(unsigned int)const"
(?do_syntax_type@?$cpp_regex_traits@_W@boost@@ABAII@Z)" は未解決です。

ってのが出て .lib の作成に失敗してしまう… orz

テンプレートクラスのメンバー関数に対してenable_ifって使えない？
MinGWでもVC7.1でもコンパイルエラーが・・・
とりあえず
１：クラスへのテンプレート引数をenable_if,disable_ifに渡したところコンパイルエラーが。
２：テンプレートクラス内のテンプレートメンバー関数は、関数の引数に依存している型をenable_ifに渡す場合は問題なく動作(MINGW,VC7.1共に)。

>>745
結果変わってんじゃないの？
それに、外部シンボルが未解決でも .lib の作成ならできるはずでは？

ん？何だこの名無し。

てｓｔ

ひろゆこUZEEEEEEEEEEEEE!!!!!!!!!!!!!!

>>747
STLportをリビルドする前と後でエラーの内容変わってないです
743と745のメッセージは前後で2種類両方とも出てました

STLportを使わずに bjam -sTOOLS=vc7.1 でビルドすると
これらのエラーが全く出ないのでおかしいと思って…

うーーん、まいった… ワカラン orz

C++の最後の砦であったtemplateも
C#がgenericsサポートした以上崩壊してしまったな。
あとはC#の下請けとしてがんばってくれや。

Javaもサポートしたけど、
CLIのgenericサポートは話題としては面白そうだね。

けど基本的にC#だけって事になるんだと思うけども…

bjam使うとダメっぽいけど、regexを単体でビルドしたら成功したので報告しときます。

(1) STLport-4.6.2を/Zc:wchar_tでリビルドして再インストール。
(2) bjam -sTOOLS=vc7.1-stlportでフルコンパイル、インストール。regexのリンク失敗は無視。
(3) boost_1_31_0/libs/regex/build/の下でvc71-stlport.makを使って単体ビルド。
(4) (3)で出来たregexの.libと.dllを(2)に上書きする。
(5) 実際にregexを使ってアプリを作る時も/Zc:wchar_tを使う。
　　(プロジェクトのプロパティ→C/C++→言語→wchar_tをビルトイン型として扱う)

以上。
ふぅ… 疲れますた。

>>752
C# 2.0の処理系ってもうあるの？

C#のジェネリックってやっぱり再帰のオンパレードで実装するしかないの？
言語設計当初から念頭にあるならC++よりずっと使いやすくて洗練されてるのかな？

>>757
Monoがかなりの部分サポートしてるよ。

>>75
やっぱり再帰のオンパレードか･･･

C#にせよJavaにせよGenerativeってサポートしてるといえるレベルなのか？

C# 2.0 の仕様を日本語解説してるとこあったら教えて？M$かなやっぱし。

英語だけどコード見りゃ分かるだろ
http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/SpecificationVer2.doc

C++ Templates なんだけど、これって単語の数は少なくて慣れてしまえば読みやすいんだけど、
単語の使われ方が変わっているし、なんか微妙に文法も変な気がする。
主語が吹っ飛ぶことが多いというか。・・・これ書いたのネイティブの人だよね？
俺の英語力がだめなだけなのか・・・

>>761
わざわざ教えてくれてありがと。
こんな詳しい解説書がすでにできてたのか・・・
ざっと見ただけなんだけど。
書式としてはC++のようにtemplateと明示しなくていいみたいね。
template template パラメータはどう指定するんだろ？

>>762
俺はModernの日本語訳読んでるよりC++ templatesの英語のほうが
よっぽどわかりやすいとオモタ。
実際、後者の方がよっぽど早く読めた英語が決して得意じゃない俺。
あと、見渡せるコードの長さがちょうど良くて後戻りする頻度も
少ないとオモチャ。
印象としてはModernの方はテクの披露、C++ temp.の方はわかりやすく
解説することを心がけてるようにヲモタ

プログラミングの書籍なんて文章とコードのセットで理解するもんで、
訳がどうこう言ってるような椰子はプログラミング言語に対する基本的な
技能が足りてないと思われ。Modernの日本語訳でおれは普通に理解出来たけど。

"Modern"の場合は特にプログラム読解の比重が大きいからねえ。

多分翻訳がどうこうとか言ってる奴は、受験時代に大して変わらないような
参考書を山ほど買いこんでた口だろうな。C++に関しても書籍かって、出版
産業に貢献してやれやｗ

>>764
俺も同じ感じだ。
ただ、読みやすいけど、文章が頭悪い感じがするのは気のせいなのかなあと。
Modernのほうの翻訳はよくできてるっぽい。
comp.lang.c++.moderatedのAlexの文章を見ているとそのまんまだ。
>>765
そうなんだけど、翻訳どうのでなくて、内容に関してだけ言えば
もう少しわかりやすく書けるのではないかと。理解できない人もいると思う。

>>765
>Modernの日本語訳でおれは普通に理解出来たけど。

ハイハイ。ここでは何とでもいえる。もっともなんで本を読むかといえば
技能が足りないからこそ読むんだ。技能が十分あるなら本なんかわざわざ買わず
Lokiをダウンロードしてそれをそのまま読め。

>受験時代に大して変わらないような参考書を山ほど買いこんでた口だろうな。
それをしなかったお前は大学にもいけず専門学校->人材派遣でゴミのように
ただこき使われる日々過ごしてるわけだ。ｹﾞﾗｹﾞﾗ

>>769
お前は精神科逝ったほうがいいぞ。俺と同じ臭いがする。

つまりくせえんだよ、激臭。ヘタレはさっさと首吊って死ね。

死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

>>765
どうやら図星だったようだな。エンジニアなら院ぐらいは修了しとこうな。
といっても、君の人生もう手遅れだと思う。

喧嘩するなって言ってるだろう。

なんでtemplateスレはこんな奴らばかりなんだろう？
他人を見下さないと生きていけないのかい？

燃料注入
boost本は実にいい本だった。歴史に残る名著だ

>>773
そろそろ新しい C++ Template 本に飢えてるんじゃないの？

>>775
Let's Boostのニュースにこんなのが出てた。
http://boost-consulting.com/mplbook/

やっべー。気になる。

こ・・・これは(;´Д｀)ﾊｧﾊｧ過ぎるだろう・・・
著者がDave AbrahamsとAleksey Gurtovoyなんて，
まさにTMPについて書くならこの人！って感じの2人じゃねーかYO!!

もう疲れた。手段に過ぎない言語の解説本でこれ以上時間を浪費できない。
目的あるいは準目的に近い人はとっとと読んでわかりやすく解説してくれ。
もうC++自体午後6時って感じなのに・・・

しかしかっぱえびせんのようにやめられない…

こんなの読もうって人は、ある意味知的好奇心と頭の体操的な意味で(趣味的に)
読むんであって、仕事に必須ってことじゃないでしょ？

俺らが普段何気なくつかってるものにはtemplateなんかよりも
もっと複雑な仕組みが組みこまれてるんだよ。

>>781
> 仕事に必須ってことじゃないでしょ？

こういう視点だと職場ごとに違うしねえ。
ある種の人々は、例えば組み込み屋、iostreamさえ必要ないし。

>>783
前の仕事でＩＰルータやってましたけどもとのアーキテクトがＴｅｍｐｌａｔｅ
おたくでがんがん使ってました。　ＳＴＬは使わないで全部彼自家製
でしたが。　クラッシュしたシステムの死体解剖は時々つらかった
ですね。　何層にも重なったテンプレートの奥深くで死なれると
ｇｄｂがどうしても理解できない場合がいくつかありました。

template設計を効率よくこなすための、Effective C++みたいなというか、
べからず集みたいなのが欲しい。modern にしろC++ templatesにしろ
"こんなこともできます集"であったんで、やるとデバッグが大変になるとか、
再利用が困難になるとか・・・etc ノウハウはもうかなり集積してるんじゃないの？
それを紹介して欲しいな。

templateを有効利用するためのデザパタとか

>>785
785自身はどんなこと気をつけて使ってます？

漏れが気をつけてるのは、型毎の特殊化が必要ない部分が多くなるように設計して、
特殊化が不要なメソッド・変数がある程度あるなら、それを集めた基底クラスを作って
使うようにしてるくらいかなー。コード生成量が減るし、必要なら子クラスのメソッドを
仮想関数にしとけば普通のポリモ系のデザインのコードとも親和性高いし。

プリミティブタイプのための特殊化で、TypeListを良く使うので、
>>781の意見にはちょっと賛成しかねるところがあります。
けど確かにもっとシンプルなのだけ集めた本があると便利だし、
template書きも迫害(wされなくなるかも…

>>787
C++ Templatesはシンプルなもの満載でしょ。
でも、nontype テンプレート引数の制限事項があるのでどうも気力が失せる。

VCにSTLport入れた後、ウィザードで新規プロジェクト作った時は
stdafx.hに毎回

#ifdef NDEBUG
#undef _STLP_DEBUG
#else
#define _STLP_DEBUG 1
#endif

とかを書かないといかんのが面倒…
みんなどうしてんの？ VCのテンプレート書き換えてる？

コピペするだけやん

>>789
stl_user_config.hにかいてる
>>790
それはめちゃくちゃめんどくさいとおもいます

VC7.1ならSTLPortなんていらないやん。

なじぇに

ギャップバッファのテンプレートありますか

>>794
http://www.jah.ne.jp/~naoyuki/Programs/Programs.html

>>791
> stl_user_config.hにかいてる
なるほどぉ。
毎回includeされるんだからここに書くのが一番ってわけか。

でも、
#define _STLP_NO_OWN_IOSTREAMS 1
とか
#deine _STLP_USE_DYNAMIC_LIB 1
を定義したい場合などは、そのプロジェクト毎にstdafx.hに書いた方が良さそうだね。


ん？そう言えば…
よう考えたらstl_user_config.hってどっからincludeされてんだろ？
単にinclude pathの先頭にあるだけで読み込まれてるんだが…

STLPortの4.6.2 (April 10, 2004)なんですが
srcディレクトリにあるvc6.makとvc6-unicode.makに違いが見られないんですが
vc6-unicode.makは何のためにあるんでしょうか?

>>793
付属のSTLでboost100%だから

付属のSTLとまったく同じだと思ってるんだ。ふーん。

STLPort使うとBoost100%にならないし

>>799
小学生並の読解力を晒しちゃったねｗ

MFCのCGdiObject派生クラス
例えば、CFontクラスなどを以下の様にvectorクラスで使用すると
コンパイルが通りません… どういう事なんでしょうか？

vector<CFont> font;
font.clear();

コンパイラとかエラーメッセージも書けねーのか池沼

>>803
すみませんでした。コンパイラはVC++6.0です。

以下がエラーメッセージです。
c:\program files\microsoft visual studio\vc98\include\xutility(19) : error C2582: 'CFont' : 代入演算子 'operator =' が、指定されたｸﾗｽに定義されていません。
c:\program files\microsoft visual studio\vc98\include\vector(207) : ｺﾝﾊﾟｲﾙされたｸﾗｽのﾃﾝﾌﾟﾚｰﾄのｲﾝｽﾀﾝｽ化 'class CFont *__cdecl std::copy(class CFont *,class CFont *,class CFont *)' の参照を確認してください

>>804
CFont a, b;
a = b;
ができないから。

>>805
解決方法は、自分でCFontなりの派生作って
演算子定義するしかないですか？

CFont*を入れる

>>807
ああ、なるほど。
ちょっと後始末が面倒そうですが…

>>808
std::vector<boost::shared_ptr<CFont> >

CFont*だろ

>>810
ハァ?

auto_arrayってなんで標準にないの？

無い物は無いから

auto_ptr自体いらんし

std::vector使えばいいやん

ttp://www.research.att.com/~bs/bs_faq2.html#auto_ptr

ということは所有権の移動がある配列には
auto_ptr<vector<T> >を使えということですか？

>>817
それでいいんじゃないの？
vector::swap() を使っても、似たようなことができるかもしれない。
boostを使えば選択肢はもっと広がるだろう。

配列自体の所有権を移動させる方法なんてどうせ実装の詳細だから、好きに選べばいい。

テンプレートの特殊化?っていうんでしたっけ。

template<class T>
class A
{
public:
void foo() {}
};

template<>
class A<char>
{
public:
void foo() { /* charの処理 */ }
};

こんな感じでいくつか特殊化しているのですが
特殊化した型以外の場合
上の例だとA<int>などとしたらコンパイルエラーになるようにするには
どうしたらいいでしょうか?

template<> class A<int> { A(); } ;

宣言だけして実装しない。

template <typename T>
struct A {
  void foo();
};

template <>
struct A<char> {
  void foo() { /* 処理 */ }
};

↓で十分では？

template <typename T>
class A;

template <>
class A<char> {
  void foo() { /* ... */ }
};

>>821
ああなるほど。
コピー禁止クラスを作るときの、コピーコンストラクタとoperator=を宣言だけして実装しないのと
同じような感じなんですね。
ありがとうございました。

>>822
うお、こんなこともできるんですね。
これだと
A<int> a;
としただけでもエラーになってくれていいですね。
こっちを採用したいと思います。

ちょいと気になることがあるんですけど
template<class ??>
template<typename ??>
この2つは等価ですが、classとtypenameどちらを使ってますか?
自分としてはclassで統一してますけど
場合によって使い分けたりする人もいるんでしょうか?

そこにくるのがclassだけならclassでいいかもしれんが
classに限らないならtypenameのほうがいいと思う

補足
class以外==組込み型(int等）

>>825
一時期使い分けてたが、大して意味内んでもうしてない。

>>826
趣味趣味。template template パラメタの場合には typename 使えないって
微妙な仕様もあるので、俺は class で通してる。

しかしながらauto_ptrはそのまま使うのではなく例外安全のためにあくまで初期化のみにつかう。

>>830
その「しかしながら」は、どのレスからつなげればいいんだ？

>>831
たぶんここの誤爆だと思割れ目
http://pc5.2ch.net/test/read.cgi/tech/1090180012/

>>832 時間を見るに、おそらくそれは違う。

>>833
名探偵認定

すまん。最近ずっとアク禁に巻き込まれてて書き込めると思わんだって
適当に書いたら投稿できて。
814がauto_ptrいらんといってるがこれはauto_ptrの本当の有効な使い方を知らんからだと
思う。たとえば複数のオブジェクトを確保したいとき
HOGE * a = new HOGE();
HOGE * b = new HOGE();
とするとbの初期化に失敗したときaはリークする。これをtry/catchでカバーするのは難しい。
そこで
auto_ptr<HOGE> tmp_a(new HOGE());
auto_ptr<HOGE> tmp_b(new HOGE());
HOGE* a = tmp_a.release();
HOGE* b = tmp_b.release();
としてやる。
常時オブジェクトを保存しておくための変数としてではなく、例外安全のための一時変数として
auto_ptrは意味がある。

追加
もちろん確保したらdeleteしなきゃだめね。ただしdeleteは例外を出さないことを
前提できるし、そうでなくてはいけない。

>>835
std::auto_ptrは場合にもよるがdeleteしなくてもいいのじゃないか？

>>837
830では無いが、もうちょっとよく読め

めんどくさいな

>>839
そして人は shared_ptr に流れ着くわけだ。

>>835
下の例で、
auto_ptr<HOGE> a(new HOGE());
auto_ptr<HOGE> b(new HOGE());
↑こうしない意図は何？

>835
>HOGE* a = tmp_a.release();
>HOGE* b = tmp_b.release();

なんでわざわざ生ポインタ取り出すの？そのまま使えばいいと思うけど。

あと、auto_ptrは引数、戻り値に使うと便利だと思う。
auto_ptrを知らないひとが使うと火傷するけど……

Hoge* f()
{
    auto_ptr<Hoge> tmp(new Hoge);
    //...//
    return tmp.release();
}
みたいなのはよくやるな。

>>840
オブジェクトのコンテナとして使うのであれば確かにauto_ptrよりshared_ptrをお勧めする。
しかしそもそもauto_ptrの本質はrelease()にある。コンテナではない。

>>842
確かにそうだし、出来ることならそうすればいいと思う。
しかし843のように生ポがほしいときや、多少なりともオーバーヘッドが気になるとき
は取り出してかまわない。
なぜなら先の例はとあるクラスのコンストラクタでの処理だとする（ポインタa,bがメンバとする）。
そのうえでデストラクタに"delete a;delete b;"とすれば例外安全は保障される
これはコンストラクタが完了していれば必ずデストラクタも呼ばれるため。
>auto_ptrは引数、戻り値に
そうだね。おれも使えるときは使っている。ただインターフェース的には一般的でないというか・・・

>844
>auto_ptrの本質はrelease()にある。

そこがわからん。auto_ptrは、その名の通りリソースの自動管理がキモなんじゃないの？
その他にも管理権限の委譲の明確化とかあるけどさ。

>845
>しかし843のように生ポがほしいときや、多少なりともオーバーヘッドが気になるとき
>は取り出してかまわない。

いや、確かに生ポインタが欲しければ取り出してもかまわないけど……
オーバーヘッドってそんなにペナルティ大きかったっけ？
間接参照１〜２コ分ぐらいじゃないの？

>>845
auto_ptrにオーバーヘッドがあるなんて考えるのはどうかしてる。
例外安全を考慮するなら、メンバにauto_ptr持ったほうがもっと確実。

正直、830は「本当の有効な使い方」を語れるほど知らないように思う。

auto_ptrのオーバーヘッドなんて最近のコンパイラなら最適化で消滅しそうだし

オナニー脳内最適化

オーバーヘッドを理由に出したのがまずかったかな？実際に俺もほとんどauto_ptrをそのまま使ってるし・・・。
ただ取り出してもかまわない条件を示したかっただけ。

auto_ptr< HOGE > const p( new HOGE );

これでもう、scoped_ptr はいらんね…といいたいが…

>>851
で、「取り出してもかまわない条件」はひとつも示せてないよな？
それでも「auto_ptrの本質はrelease()にある」と思うの？

>「auto_ptrの本質はrelease()にある」
？

>>830じゃないのが、お前が勝手に異次元的解釈をしてるだけと違うか？

>>854
だれに向かって「お前」っていってるのかわからない。

>>855
>>853へ

漏れかよ。

>>854
auto_ptrの本質はデストラクタにあり、release()はただのサービスだと思ってるんで、
>>844(=830)の言う「auto_ptrの本質はrelease()にある」なんてちっとも賛同できないわけよ。

読んだままの意味にしかとらえてないから、「異次元的解釈」なんてしてないつもりだよ。

あー、ちょっと俺は異次元的になにかを勘違いしてた。
>>854は無視してください。ごめんなしゃい。

夏だな。

C++なんだからrelease()も必要不可欠な要素の一つだろ
ところで本質って何？

>>860
数牌は一色で、後は字牌。

>830, 860

もういいよ。取りあえず
C++標準ライブラリ チュートリアル&リファレンス
(The C++ Standard Library: A Tutorial and Reference)
読んどけ。な

>>859
お前、夏休みの間の出来事はみんな夏のせいにしてるだろ？

>>863
夏厨指定厨というのが存在するのだよ
2chも、もう長いからな

悪かった。ただ俺はauto_ptrをコンテナ的な使い方しか見れないやつに強調するつもりで言ったんだが。
俺が言い過ぎた。こんなムキになって噛み付かれるとは思わんかったし。
>>853
一応示したんだが。release()なんて一生使えなくていいもんな。

>>865
やっぱりわからん。
コンテナ的な使い方って、ふつうにauto_ptrを保持することだよな？
そういう使い方しか見れないって、ほかにどう見るというんだろう。

>>835なんかtryでいいじゃん

>>867 tryﾏﾝﾄﾞｸｾ

(ry

boost::shared_ptr遅いしメモリ喰いすぎ。

>>870 詳しく

ふつうに計数型スマートポインタを書いたらああいう風にはならないよな。
weak_ptrなんてもんに対応させるため構造が複雑になってる。

smart_ptr が利用している shared_count クラスを見れば分かるが、
smart_ptr< void > みたいに書かれた場合や、smart_ptr< HOGE > のときの
HOGE に 仮想デストラクタがない場合でも、正しくデストラクタが呼ばれるように、
boost::any みたいな仕組みを用意している。

smart_ptr → shared_ptr

>>872
必要ないならお前は簡略化されたの使えばええやん

俺は intrusive_ptr が好きだ。

COM扱うときは大活躍なだ

ptrの部分はどう発音すればいいのかね

ポインタ

ポタラ

ポニーテール

ぴーてぃーあーる

ﾌﾟﾀｰ

ピートル

>>875
どこにあるか？

>>885 intrusive_ptr

ピョートル大帝

質問です．
boostのtupleで要素の型が欲しいのですが，アクセッサ(?)はないでしょうか?
例えば，
typedef boost::tuples::tuple <short, float> Tuple;
のようにTupleをtypedefしたとき，
typedef hoge <Tuple, 0> First_Type;
typedef hoge <Tuple, 1> Second_Type;
のような形でFirst_Type，Second_Typeを定義するのにhogeみたいなものがあれば嬉しいのですが．

蛇足でしょうが，念のため
上記でFirst_TypeはshortにSecond_Typeはfloatにtypedefされて欲しいです．

自己レスです．昔書いてたコード漁ってたら出て来た．(笑)
#include <iostream>
#include <boost/tuple/tuple.hpp>
using namespace std;
typedef boost::tuples::tuple <short, float> Tuple;
typedef boost::tuples::access_traits <boost::tuples::element <0, Tuple>::type>::non_const_type First;
typedef boost::tuples::access_traits <boost::tuples::element <0, Tuple>::type>::const_type const_First;
typedef boost::tuples::access_traits <boost::tuples::element <1, Tuple>::type>::non_const_type Second;
typedef boost::tuples::access_traits <boost::tuples::element <1, Tuple>::type>::const_type const_Second;
int main () {
cout << (typeid (short) == typeid (First)) << endl;
cout << (typeid (short) == typeid (const_First)) << endl;
cout << (typeid (float) == typeid (Second)) << endl;
cout << (typeid (float) == typeid (const_Second)) << endl;
return 0;
}
過去に調べたかどうかですら忘れてしまうとは．orz

何度もすみません．890のaccess_traitsはいらないかったです．
結局，888で欲したhogeはelementでした．
typedef boost::tuples::tuple <short, float> Tuple;
typedef boost::tuples::element <0, Tuple>::type First;
typedef boost::tuples::element <1, Tuple>::type Second;
失礼致しました．

>>33
> >>32
> Modern C++ Designを読みましょう。
> 第４章「小規模オブジェクトの割り当て」当たりがお勧め。

あのメモリアロケータってデフォルトのnewより遅いゴミアロケータ。
Modern C++は昔すごいと思っていたけど、今思うとあまりにもマニアック過ぎると思う。
さしあたり、STLやboostの便利なライブラリを使っていれば十分と思った。

Effective STLはそういう意味で良い本だと思う。　boostについてもEffectiveみたいな
ノリで書いた本があれば重宝すると思う。

>>892
> > 第４章「小規模オブジェクトの割り当て」当たりがお勧め。
>
> あのメモリアロケータってデフォルトのnewより遅いゴミアロケータ。

普通、遅くても良いからメモリ効率の良いを目指すんじゃないのか?
小さいオブジェクトのアロケータは。

>>893
ほんよんでねーだろ

>>893
Modernでは速いのを目指してなかったっけ?

>>893
本読んでないだろ、っつーのはともかくとして
> 普通、遅くても良いからメモリ効率の良いを目指すんじゃないのか?
STLport の node allocator なんかは、逆だね。メモリ効率を犠牲にして
速度を稼いでる。

STL コンテナには基本的にデカいオブジェクトを格納しない (たいてい shared_ptr
とか小さいオブジェクトを入れる) から、それで良いんだけど。

>>895
空間効率、速度効率、どちらにも良いのを目指してたと思う。

この辺のロジックって、ある程度解答が出てるものかとばっかり思ってたんだが、
そういうわけでもないのかね？？

>>898
Reconsidering Custom Memory Allocation
http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

>>892
ModernはSTLやboostみたいなものを作る側の人が読めばいいよねえ。
boost::lambda級の大物を作るときは確かに役に立ちそう。