5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:04/05/03 11:14
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 あたりに。

2 :デフォルトの名無しさん:04/05/03 11:15
関連スレ
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/

3 :デフォルトの名無しさん:04/05/03 11:16
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/

4 :デフォルトの名無しさん:04/05/03 11:17
またやってしもた。Part5立てる時は直してね。

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

5 :デフォルトの名無しさん:04/05/03 11:19
参考図書

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

6 :ヽ(`Д´)ゞ乙っ!!:04/05/03 11:58
今のうちに参考図書追加して宣伝してやるぜ!!ヒヒヒヒヒ・・・

・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/

7 :デフォルトの名無しさん:04/05/03 12:09
こんにゃのも。

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

8 :デフォルトの名無しさん:04/05/03 23:43
ネタ無しage

9 :デフォルトの名無しさん:04/05/04 17:20
教えてください。

class B;

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

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



10 :デフォルトの名無しさん:04/05/04 17:24
>>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 {}
};


11 :デフォルトの名無しさん:04/05/04 17:28
>>10
ありがとうございます。

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


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

13 :デフォルトの名無しさん:04/05/04 17:39
>>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);}};


14 :デフォルトの名無しさん:04/05/04 17:44
>>6
> ・テンプレートによるデザイン
> Modern C++ Design
個人的に凄く良書だとおもう

15 :デフォルトの名無しさん:04/05/04 17:46
>>14
何をいまさら・・・
ところでboost本ってもう書店に並んでるの?


16 :デフォルトの名無しさん:04/05/04 17:51
>>15
タダの宣伝だろ。
クソが。

17 :デフォルトの名無しさん:04/05/04 17:51
>>12
なるほど(・∀・)!
ありがとうございました。


18 :デフォルトの名無しさん:04/05/04 17:52
都内で売ってるトコあるならフツーに欲しいが。


19 :デフォルトの名無しさん:04/05/04 17:57
5/10発売って書いてあるようだけど。
cbook24もamazonもまだヒットすらしないな

20 :デフォルトの名無しさん:04/05/04 23:40
部屋にModern C++ Designがあるので読み返して見ている。
いや正直俺には難し過ぎ・・・orz

21 :デフォルトの名無しさん:04/05/05 05:52
struct A
{
 template<int I,typename T> A& operator=(const T& t)
 {
  return *this;
 }
};

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

22 :デフォルトの名無しさん:04/05/05 06:20
>>21
a.operator=<100,int>(1);

23 :デフォルトの名無しさん:04/05/05 06:25
>>19
だよねー。
ISBNで検索しても引っかかってくれない。

24 :デフォルトの名無しさん:04/05/05 10:44
dj


25 :デフォルトの名無しさん:04/05/05 16:13
結局 static const int と enum はどっちがベターなの?
規格上および実際のところ。



26 :デフォルトの名無しさん:04/05/05 16:29
↓Blitzの質問

27 :デフォルトの名無しさん:04/05/05 16:40
今2chで話題のA何とかの中の人のMFC講座!
みんないっちゃだめだよ〜wwww
http://www.geocities.jp/aransk88/contents4.html


28 :デフォルトの名無しさん:04/05/05 16:50
>>25
static const int の替わりに enum を使うのは
実装の遅れたコンパイラに対応するためのハック。

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

29 :デフォルトの名無しさん:04/05/05 17:00
>>28
> static const int の替わりに enum を使うのは
> 実装の遅れたコンパイラに対応するためのハック。
factorial<>とかpow<>とか、よくあるcompile time computationに適したのはどっちでしょう?


30 :デフォルトの名無しさん:04/05/05 17:27
>>29
enum はとり得る値が列挙された型を定義するので、意味が適しているとは思えない。
static const int のほうが意味が適していると思う。

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

31 :デフォルトの名無しさん:04/05/05 17:31
>>30
ありがとうございます。過去スレ(Generic Programming with C++ Template)で議論になって
結論なしだったんで気になってて。

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


32 :デフォルトの名無しさん:04/05/05 23:52
テンプレートはものの30分くらいで理解できたけど
アロケータってのが理解できないんですが
どうしたら良いのでしょうか?

33 :デフォルトの名無しさん:04/05/05 23:54
>>32
Modern C++ Designを読みましょう。
第4章「小規模オブジェクトの割り当て」当たりがお勧め。

34 :デフォルトの名無しさん:04/05/06 00:17
ネット上の資料で十分だろうから、
本なんか買う前にgoogleに聞いておくべきだな。

35 :デフォルトの名無しさん:04/05/06 00:21
>>34
そうかもしれん。
取り敢えずアロケータを知るために最小限学習すべき要件。

1.メンバ関数
allocate()
construct()
destroy()
deallocate()
2.STLの提供する関数
std::uninitialized_fill()
std::uninitialized_fill_n()
std::uninitialized_fill_copy()
3.STLの提供するイテレータ
std::raw_storage_iterator

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


36 :デフォルトの名無しさん:04/05/06 00:35
そしてrebindの仕様に絶望するようになれば一人前。

37 :デフォルトの名無しさん:04/05/06 01:13
>>36
typedefテンプレートか・・・・

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

38 :デフォルトの名無しさん:04/05/06 01:19
>>36
確かに(w

39 :デフォルトの名無しさん:04/05/07 10:37
>>37
pool_allocatorって便利やね
boostを惚れ直しマスタ


40 :デフォルトの名無しさん:04/05/07 11:13
>>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が自分のアロケータ用に最適化されていると
言うべきか。どなたか追試ヨロ。

41 :デフォルトの名無しさん:04/05/07 11:23
ソースはここに置いておいた。「間違っとるぞ!」「こう書けば速いのに」
等レス希望。
ttp://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1076074304&res=9&fi=no

42 :デフォルトの名無しさん:04/05/07 13:47
>>41
どのコンテナでも、内側のループ(j)を1,000や10,000じゃなくて、10^6くらいに
して比較したらどうなるかな?
それから、内側を十分回せば外側(i)は10,000も回さなくてもいいんじゃない?


43 :デフォルトの名無しさん:04/05/07 14:12
アロケータの使い方を見ていたら、std::vectorの要素にコンストラクタで失敗するオブジェクト
を用いてはいけないことに気がついた。

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


45 :デフォルトの名無しさん:04/05/07 15:38
>>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()は速いんだけどねえ。

46 :デフォルトの名無しさん:04/05/07 17:55
--end()がエラーになるのはポインタを返す実装の場合だな。
確かboostにそのためのラッパがあったような。

47 :デフォルトの名無しさん:04/05/07 20:05
template を使っていると、エラー処理をうまく書けなくなる
ことが多くならないですか?

48 :デフォルトの名無しさん:04/05/07 21:43
>>46
boost::prior だね。

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

49 :デフォルトの名無しさん:04/05/08 00:57
>>43
> std::vectorの要素にコンストラクタで失敗するオブジェクトを用いてはいけない

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

50 :デフォルトの名無しさん:04/05/08 11:49
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.


51 :デフォルトの名無しさん:04/05/08 12:24
>>15
でも出てるけど、boost本が並んでる都内の本屋無い?
月曜発売なんだろうけど土日に読みたいんだよね、やっぱ。

52 :デフォルトの名無しさん:04/05/08 20:36
>>49
俺もわからん
教えて>>43

53 :デフォルトの名無しさん:04/05/09 02:37
なんでこれはコンパイルできないですか?
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 ]

54 :デフォルトの名無しさん:04/05/09 02:48
>>53
試してみたけど、Cygwin + gcc 3.2 ではコンパイル通るな。
でも、標準C++準拠率が高いといわれる VC7.1 の cl でコンパイル通らなかったけど。


55 :デフォルトの名無しさん:04/05/09 02:50
というか、

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

template<class T,typename U>

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

56 :デフォルトの名無しさん:04/05/09 02:57
>>55
ん?X<Y,T>だぞ。X<T,T>じゃない。
よくみてみ。



57 :デフォルトの名無しさん:04/05/09 02:59
>>53
> struct Y: X<Y,T>{};
ここで X に渡してる Y が、 template 引数を受け取った後に実体化される型 Y<T> と解釈されてしまうらしい。
解決法はわかんないけど。

58 :デフォルトの名無しさん:04/05/09 03:01
珍しいワナにひっかかてますねw
以下が正しい書き方になります.

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


59 :デフォルトの名無しさん:04/05/09 03:06
>>58
> struct Y: X< ::Y,T>{};
へー。gcc3.2.2でも通った。はじめて見た。


60 :53:04/05/09 03:07
北ーーーwwヘ√レvv〜(゚∀゚)─wwヘ√レvv〜─ !!
罠だったのか。。。。。。。
レスしてくださった皆様ありがとうございました!!!!

61 :デフォルトの名無しさん:04/05/09 03:11
>>58
どういう罠?


62 :58:04/05/09 03:11
一応補足をば.class templateの内部でクラス名だけを書くと
実体化された型を指すことになります.

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

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

63 :デフォルトの名無しさん:04/05/09 03:16
template<typename T, typename S<T> >

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

64 :デフォルトの名無しさん:04/05/09 03:19
>>63
まずは日本語で表現できるかどうかやってみれ。

65 :デフォルトの名無しさん:04/05/09 03:29
>>53-62
gccのバグで、3.4で修正が入ってる。
http://gcc.gnu.org/gcc-3.4/changes.html
ここで
"Inside the scope of a template class"を検索。

66 :デフォルトの名無しさん:04/05/09 04:09
規格を交えた考察を。

規格の対応する項目は 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でも漁るか・・・。

67 :デフォルトの名無しさん:04/05/09 05:38
こういうの見るとtemplateなんてC++のダメさを隠してる
だけなんだと痛感する

68 :デフォルトの名無しさん:04/05/09 06:00
struct Y: X< Y,T>{};
struct xxx::Y : X< xxx::Y , T > {};
って自分で自分を定義してからだめな気がするんだが、
違うのかな?


69 :デフォルトの名無しさん:04/05/09 08:59
>>67
新しい世界を開拓しているフロンティアなわけだが。

70 :デフォルトの名無しさん:04/05/09 16:16
>>68 チガウヨ

71 :デフォルトの名無しさん:04/05/09 17:17
Expression Template についてわかりやすく解説してる書籍ありませんか?
それか、解説してくれるとありがたいんですが
目的は一応わかりました。

72 :デフォルトの名無しさん:04/05/09 17:34
>>71
C++ Templates - the complete guide

73 :66:04/05/09 18:15
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 > {};
これは通らなくなり、2行目を
template< typename T > struct B : A< B< T > > {};
とする必要がありそうだ。
実際にやってみると、VC(Toolkit 2003)では両方OKで、gcc(3.3.1)では上だけエラーになる。
これはこれでまた一悶着起こりそうな予感が・・・。

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

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

75 :デフォルトの名無しさん:04/05/09 18:43
>>74
pdfでDL(ry

76 :デフォルトの名無しさん:04/05/09 18:44
>>75
いや寧ろCHM版の方が(ry

77 :デフォルトの名無しさん:04/05/09 18:51
>>75
> pdfでDL(ry
あるの?


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


79 :デフォルトの名無しさん:04/05/09 19:04
>>77
ある所にはあるがここにはとても書けない。hint : google

80 :デフォルトの名無しさん:04/05/09 19:44
>>79
いや、売ってるの?という意味。
書籍は持っているんだが重くてな。


81 :デフォルトの名無しさん:04/05/09 20:06
アマゾヌでプレミア価格ついてるんだが・・・
絶版??


82 :デフォルトの名無しさん:04/05/09 20:49
>>81
amazon.comとか紀伊国屋書店BookWebでなら注文できるみたいだよ。

83 :デフォルトの名無しさん:04/05/10 00:12
>>73
ピンポイントなドキュメントで(゚д゚)ウマーです.

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

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

84 :デフォルトの名無しさん:04/05/10 00:33
>>83
末恐ろしいというか単に
template って枠組みをそれまでの C++ に押し込むために
無理矢理やってるだけだよ。

85 :デフォルトの名無しさん:04/05/10 00:53
何かコンピューター界って不便な所で我慢する癖が続くなあ。
6502にしろ8088にしろ、なぜかメインストリームになっているし、
C++も文法的にすごく汚いのに山ほど本が出ているし。

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

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

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

87 :デフォルトの名無しさん:04/05/10 01:39
なんのメリットも無い、ただただ苦行の一つとしてのみ残ってる泥臭さが
こんなに幅を利かせているわけはないわなw

88 :デフォルトの名無しさん:04/05/10 03:14
C++は取り去るとか整理するとかオートにするとかしないと単に追加したらさらにページ数が
増えることは間違いない。

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

89 :デフォルトの名無しさん:04/05/10 03:29
C++はともかくx86はPCのソフトウェア互換性以外幅を利かせる理由あるか?
今じゃ組み込みには絶対使わんしな。

90 :デフォルトの名無しさん:04/05/10 03:32
>>89
C3は普通に組み込みに用いられてますが?

91 :デフォルトの名無しさん:04/05/10 03:41
>>89
サーバ向けCPUだと圧倒的なコストパフォーマンスがある。

92 :デフォルトの名無しさん:04/05/10 04:06
>>91
はぁ?

93 :デフォルトの名無しさん:04/05/10 04:16
ゲラゲラ。
C3を、組み込みね。それを普通という感覚。

94 :デフォルトの名無しさん:04/05/10 04:23
なんでtemplateスレでCPU談義が始まってんの?誤爆?

95 :デフォルトの名無しさん:04/05/10 04:28
テンプレートを直接実行可能なCPUができるんだってよ。

96 :デフォルトの名無しさん:04/05/10 04:48
>>95
はぁ?

97 :デフォルトの名無しさん:04/05/10 04:49
な、なんだってー

98 :デフォルトの名無しさん:04/05/10 05:03
>>96
ここにスペックの詳細があるよ。でも、このCPUじゃ使い物にならんとおもふ。
http://www.arabtimes.com/mixed3/2.jpg

99 :デフォルトの名無しさん:04/05/10 05:21
>>93
「絶対」使われないはずなのに、使用例があるのはどういったことで?

100 :デフォルトの名無しさん:04/05/10 05:25
>>98
真面目に教えてくれないか?ぐぐっても見つからんのだが。

101 :デフォルトの名無しさん:04/05/10 05:28
>>99
>>93(=>>89)が知らなかっただけじゃないのか?


102 :デフォルトの名無しさん:04/05/10 09:34
組み込み屋ってあちこちで頓珍漢な話でレス汚してるな。
世界が狭いからだろうな。

103 :デフォルトの名無しさん:04/05/10 10:28
組み込み屋はtemplateスレに来るなよー。

104 :デフォルトの名無しさん:04/05/10 13:53
C3を乗せられるようなものは組み込みとは言わんな。あれはPCそのもの。

105 :デフォルトの名無しさん:04/05/10 14:03
専用にハードから起こしたら中身がなんであれ組み込みでいいんじゃないか?

106 :デフォルトの名無しさん:04/05/10 14:21
ダントツでARM、次いでSHでしょ。

107 :デフォルトの名無しさん:04/05/10 15:46
>>105-106
話が繋がってないよな。
>>106シェアに何の意味があるの?

108 :デフォルトの名無しさん:04/05/10 16:12
C3が組み込みにふつーというレベルで使われてるかどうかってことだろ?

109 :デフォルトの名無しさん:04/05/10 16:19
組み込み話はもうええやろ。

110 :デフォルトの名無しさん:04/05/10 16:30
絶対に使われていないかどうかってことだろ?

111 :デフォルトの名無しさん:04/05/10 16:54
製品になってる限り100%使用してないことはありえない。だが、そんなものをチョイスした時点で設計の恥さらし。

112 :デフォルトの名無しさん:04/05/10 17:14
それが89の言い訳?

113 :デフォルトの名無しさん:04/05/10 19:19
しょぼい言い訳だよね。

114 :デフォルトの名無しさん:04/05/10 20:17
boost 本感想キボン

115 :デフォルトの名無しさん:04/05/10 21:00
予想外に分厚かった。
読むのはこれから。

116 :デフォルトの名無しさん:04/05/11 00:44
boost本ってもう売ってんの?10日発売らしいけどウチの近くの
本屋はともかくとしても紀伊国屋とかにも無かったんだけど…

117 :デフォルトの名無しさん:04/05/11 01:06
uBlas使った逆行列計算の実装方法教えてください

118 :デフォルトの名無しさん:04/05/11 01:20
>>116
売ってる。
かなり大量に平積みだったよ。

119 :デフォルトの名無しさん:04/05/11 01:51
大阪は田舎だからね

120 :デフォルトの名無しさん:04/05/11 04:16
激しく本依存なのですが、ちょっとばっかり教えてください。
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>にキャストすればいいんじゃないの?と思うのですが、コンパイラで弾かれます。
なぜ参照で無ければダメなのでしょうか・・・

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


122 :デフォルトの名無しさん:04/05/11 14:22
>>121
コンストラクト失敗に出食わすまでに,
成功した要素についてはきちんとデストラクトされるのでは?

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

ってのじゃないの?


123 :122:04/05/11 14:57
なんか句読点の打ち方がおかしかった.すんません.
ついでにageとこう.

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

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


124 :43:04/05/11 16:14
>>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の途中たとえば5個目で失敗(例外を送出)したとするとどうなるか。
多分コンストラクタ5回デストラクタ11回(このうち1回ずつはデフォルトのコピーのためのテンポラリ)
となるだろう。ようは余計にデストラクタが呼ばれる。少なくとも組み込み配列とは挙動が違う。
決して改良するのは難しくないはずなんだが・・・


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


126 :デフォルトの名無しさん:04/05/11 16:30
>>124
gcc3.4.0とVC7.1で試して見たがコンストラクタがどちらも
1度しか呼ばれなかったよ?

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

127 :デフォルトの名無しさん:04/05/11 16:30
やってみた。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));
}

128 :デフォルトの名無しさん:04/05/11 16:32
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()の後始末(デストラクタ部)にて
アクセスエラーが生じていると読める。

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

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


130 :122:04/05/11 16:57
私もやってみた.(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;
}


131 :122:04/05/11 16:57
結果,
$ ./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!
ちゃんとディストラクトできてるような.....


132 :122:04/05/11 17:02
>>126が気になる.
dequeも同様の結果に.
コンストラクタは呼ばんのか....


133 :122:04/05/11 17:08
ああ分かった.
$ 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;
}


134 :122:04/05/11 17:10
結果
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個はコンストラクタを呼んであとは,
それをコピーみたい.


135 :126:04/05/11 17:20
>>130
VC7.1でもOKですた。

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

136 :デフォルトの名無しさん:04/05/11 17:35
>>134
コピー元として一次オブジェクトを構築し
すべての要素はそのコピーコンストラクトだよ。

137 :デフォルトの名無しさん:04/05/11 17:56
>>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;
 }
}

138 :デフォルトの名無しさん:04/05/11 17:57
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)

139 :デフォルトの名無しさん:04/05/11 18:04
コピーコンストラクタ忘れてた。逝ってくる...orz...

140 :43:04/05/11 20:30
ああ俺もコピーコンストラクタ忘れてた。
スレ汚しした。ああしゃれになんねえorz

141 :71:04/05/12 00:07
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
と格闘してみます。ちょっと理解の手助けとしてアドバイスいただけるとありがたいんですが

142 :49:04/05/12 00:11
えー、つまり、>>43はデマということでよろしいか?

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

144 :71:04/05/12 04:51
>まず,(1)の"template<class Op>"の位置がおかしいと思います.
あ!なるほど。
あと、
特殊化というのは
template<typename X>
のXに具体的な型を設定することなんでしょうか?
特殊化というのは一般的な名称なんでしょうか?

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

145 :デフォルトの名無しさん:04/05/12 09:28
特殊化=specialization
e.g. http://www.gotw.ca/gotw/049.htm
def: http://www.kuzbass.ru:8086/docs/isocpp/template.html

146 :143:04/05/12 10:02
あ,143に書いてあるのはspecializationとは言えないですね.
ただのオーバーロードですね.間違えました.申し訳ない.

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


148 :デフォルトの名無しさん:04/05/12 14:39
>>147
それは ((abc)?) とどう違うの?

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

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

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

152 :デフォルトの名無しさん:04/05/13 02:11
templateの型パラメータを限定するにはどうしたらいいんでしょうか

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

153 :デフォルトの名無しさん:04/05/13 02:31
>>152 boost::type_traits + ( boost::concept_check | BOOST_STATIC_ASSERT )

154 :デフォルトの名無しさん:04/05/13 02:32
>>152

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

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

155 :デフォルトの名無しさん:04/05/13 02:37
超初歩質問なんですが、
template<> って<>が空なのはどういう意味なんでしょう?

156 :デフォルトの名無しさん:04/05/13 02:47
explicit specialization(明示的な特殊化)を行う場合の書き方.
154の場合では,Tがintという具体的な特定の型の場合のfooの定義を特殊化している.
templateなんだけれど,テンプレート引数の具体的な型が明示されるので
テンプレート引数が不要になり,結果template<>という書き方になると思えばよろしいかと.

157 :デフォルトの名無しさん:04/05/13 03:33
template<int> class foo{
};
とはどう意味が違うんですか?


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

159 :デフォルトの名無しさん:04/05/13 10:37
不完全な宣言て、Effective C++に出てくる
 コピーコンストラクタと代入演算子はprivateに宣言だけして定義はしない。
ってのに似てるな。

160 :デフォルトの名無しさん:04/05/13 17:08
テンプレート引数のクラスを関数内で知ることって出来ますか?

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

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

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

161 :デフォルトの名無しさん:04/05/13 17:16
特殊化しれ。

162 :デフォルトの名無しさん:04/05/13 17:24
特殊化するぐらいならテンプレート使う意味ないじゃーんって思うのだが?

163 :デフォルトの名無しさん:04/05/13 17:28
じゃぁ if (typeid(T) == typeid(double)) とかで。

164 :デフォルトの名無しさん:04/05/13 17:49
極めて簡単な処理ならともかく、
特別バージョン作らなくてすむ場合の方が少ないような希ガス。

165 :デフォルトの名無しさん:04/05/13 18:01
>>164
なんかピンと来ないな。
なるべく簡単な(無理を言って済まんが)例を出してくれないか?

166 :デフォルトの名無しさん:04/05/13 18:13
>>165
164じゃないけど。
特殊化がわからないって意味?それとも特別バージョンを作る理由がわからないってこと?

167 :デフォルトの名無しさん:04/05/13 18:25
>>166
作る理由の方。曖昧な言い方でスマソ
特殊化を使う場面はTypeTraits系、メタプログラミング、最適化くらいしか思いつかない。
実際にもあまり書いた記憶がないので、例を見せてほしいなと。

168 :デフォルトの名無しさん:04/05/13 19:22
>最適化くらいしか思いつかない。
これって重要ではないかと?
complex<zzz>/double/float をテンプレート引数に想定してるときで、
conjをたくさん使うようなところ。typeid だと実行時判定

169 :デフォルトの名無しさん:04/05/13 19:29
>>167
そんだけ理由があれば十分かと。
160の要望を解決するためには(設計が悪いのかもしれないけどこれだけだとわからない)しないわけにはいかない。

170 :デフォルトの名無しさん:04/05/13 20:07
typeidは使うなって教科書には書いてあるけど。数多くの特別バージョンが必要な場合に、実に有効だと思うのだが?
オーバーヘッドをネグれる場合、積極的につかっちゃ駄目なの?

171 :167:04/05/13 20:19
確かに最適化は重要だと思うけど、多くの場合カプセル化できるような…
例えば、
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)を呼び出していろいろする */
}

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

172 :デフォルトの名無しさん:04/05/13 20:36
>inline double conj(double d) {return d;}
>inline float conj(float f) {return f;}
特殊化せずに局所的に型に応じたconjを自前で用意したわけで、結局、同じことじゃないかと。

173 :167:04/05/13 20:48
つまり、fを特殊化する代わりにconjを特殊化(オーバーロードだけど)するようなスタイルなら、
fのような関数を書くたびに特殊化をする必要はない、ということ。
>>168はconjではなくfを特殊化するといっているように読めたので。
読み違えてたらスマソ

174 :デフォルトの名無しさん:04/05/13 20:57
一箇所だけオーバーロードすればいいなら、特殊化するよりコードはグンと少なくてすむ罠

175 :デフォルトの名無しさん:04/05/14 00:27
組み込み型のための特殊化、愛してるよ!

176 :デフォルトの名無しさん:04/05/14 00:27
もう俺はお前がいなけりゃダメなんだ。

177 :デフォルトの名無しさん:04/05/14 00:41
特別バージョンは人気ないな。

178 :デフォルトの名無しさん:04/05/14 00:46
若干スレ違いですが、
プラウガさん、C magazineに翻訳連載始まりましたね。

179 :デフォルトの名無しさん:04/05/14 01:02
>>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経由で
};


180 :デフォルトの名無しさん:04/05/15 01:57
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;
}




181 :デフォルトの名無しさん:04/05/15 01:59
>>180
>  cout << (*i).data << endl;
cout << i->second.data << endl;


182 :以後は質問スレへ:04/05/15 10:46
イタレータは、
for (p = &a[first]; p < &a[last] ; p++) { (略)
の汎化だよ。集合データをなめるポインタ。
ってこれスレ違いなんじゃあ…


183 :デフォルトの名無しさん:04/05/15 15:48
イタタタタ

184 :デフォルトの名無しさん:04/05/16 03:02
厨質問ですんませんが、STLportって具体的に何がSTLと違うんでしょうか?

185 :デフォルトの名無しさん:04/05/16 03:09
>184
STLは規格で、STLportはSTLの実装の1つ

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

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

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

187 :デフォルトの名無しさん:04/05/16 05:24
>186
VC6に付属しているSTLはンコだったので、STLportを入れる人が多かった
VC7のSTLはだいぶマシになってる

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


188 :184,186:04/05/16 15:59
>>187
なるほど、入れるメリットがありますね。切替もできるみたいだし。
説明どうもありがとうです。

189 :デフォルトの名無しさん:04/05/16 21:52
>>187
> ただし、STLportにはSTLで規定されていないコンテナクラスも含まれていたり、
VS.NET 2003 だと hash ベースの連想コンテナも用意されてるよ。
STLport とはちょっとインターフェース違うけど。

190 :デフォルトの名無しさん:04/05/16 22:04
ropeとか。まぁ使いどころが無いが。

191 :デフォルトの名無しさん:04/05/17 00:24
LokiのSingletonを見て思うことがあるんですがみなさんの意見をお聞かせ願いたいのです。
Lokiのシングルトンは
class A
{
...実装...
};
typedef Loki::SingletonHolder<A> SingleA;

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

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

192 :デフォルトの名無しさん:04/05/17 00:33
>>191
> A自体をシングルトンっぽく書いて
なんのこっちゃ?
コンストラクタをprivateにするだけやん。


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

194 :デフォルトの名無しさん:04/05/17 00:43
>>193
> コピーコンストラクタ、代入演算子を
ここはboost::noncopyableのアイディアを借りると楽になる。


195 :デフォルトの名無しさん:04/05/17 02:03
楽に書けるだけじゃなくて仕組みも知りたいから自分で書いてるの!

196 :デフォルトの名無しさん:04/05/17 02:27
>191
ある意味C++の哲学を表していますなぁ
『SingleA経由でアクセスするなら面倒を見てやるけど、わざわざAのオブジェクト作って
 アクセスしようとするんだったら面倒みないよ。勝手にすれば?』
つうことですかね。


197 :デフォルトの名無しさん:04/05/17 08:00
>>195
ハァ?
ソース公開されてんだから読めよ。アホか。


198 :デフォルトの名無しさん:04/05/17 14:41
>>197
ソースも読めない糞ガキがほざいてろ。カスが。

199 :デフォルトの名無しさん:04/05/17 21:01
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 + を消すとコンパイルできません。なんでですか?

200 :デフォルトの名無しさん:04/05/17 21:10
さぁ?

201 :デフォルトの名無しさん:04/05/17 21:14
>>199
VC++7.1だと 0 + なしでもコンパイルできたよ。コンパイラのバグじゃない?
それより、なんでそれがフィボナッチ数列を計算できてるのかわからんので教えてくれると嬉しいのだが…

202 :199:04/05/17 22:53
ごめんなさい。コンパイルできてました。ただすごいたくさんの 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乗を考えればいいですよね。ずれてたらすいません。

203 :デフォルトの名無しさん:04/05/17 23:59
>>202
enum は暗黙のうちに整数型に変換できる。したがって 0 + をつけると
0 + enum値 が整数型となって、value の定義は

enum { value = 整数型 };

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

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

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

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

204 :199:04/05/18 00:24
>>203
例えばこんなコードは warningでません。

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

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

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

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

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

207 :デフォルトの名無しさん:04/05/18 06:20
(゚Д゚)ハァ?

208 :デフォルトの名無しさん:04/05/18 07:29
>>206
何故?

209 :デフォルトの名無しさん:04/05/18 07:39
テンプレートでforループのアンローリングみたいなことやったら
コンパイル時にメモリ足りなくなった

210 :デフォルトの名無しさん:04/05/18 23:55
>>209
オレもなった時あるなぁ。

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

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

211 :デフォルトの名無しさん:04/05/19 15:32
遊んでるだけなら面白いし、学生のコンパイラ研究なら楽しいけど、
売り物にしようとするとなぁ。
俺はそんなコード書いてもアセンブル結果を全く想像できないしな。


212 :デフォルトの名無しさん:04/05/19 16:01
テンプレートでループの展開ってどうやってやるの?
inlineに頼って再帰?

213 :デフォルトの名無しさん:04/05/19 18:30
>>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;
}


214 :デフォルトの名無しさん:04/05/19 22:51
STLコンテナの
コピーコンストラクタはアロケータオブジェクトをコピーしてくれるものの
operator=は、アロケータオブジェクトをコピーしてくれないようなんですが
なぜ?


215 :デフォルトの名無しさん:04/05/19 23:19
>>214
20.1.5 -4- かな?

216 :デフォルトの名無しさん:04/05/20 01:02
>>213
iterがキモイ

217 :デフォルトの名無しさん:04/05/20 01:03
メタプログラムなんて実務で使ってる椰子いるの?

218 :デフォルトの名無しさん:04/05/20 22:47
>217
程度問題が、それなりには。

219 :デフォルトの名無しさん:04/05/21 20:23
>>213
さんくす。
こういうのにはテンプレートよりプリプロセッサなのかな。

220 :デフォルトの名無しさん:04/05/22 03:50
ふつーのプログラムでいいんじゃないの?
ループ回数引数にしてさ。

221 :デフォルトの名無しさん:04/05/22 11:04
>>220
それだと展開できないだろ!

222 :デフォルトの名無しさん:04/05/22 13:35
>>219
C/C++のマクロは再帰的に展開できないよ。
m4だったら出来るけどね。

223 :デフォルトの名無しさん:04/05/22 13:53
>222
そこで Boost の preprocessor ライブラリですよ。

224 :デフォルトの名無しさん:04/05/22 14:09
結局template頼りかよ(w

225 :デフォルトの名無しさん:04/05/22 14:26
BoostのPPは普通にCでも使えるけど?

226 :デフォルトの名無しさん:04/05/22 17:28
っていうか、
そこまでして無理やりtemplateなんて使う意味あるの?
メタプログラムならbison++使うとか。

227 :デフォルトの名無しさん:04/05/22 20:08
そんなこと言ったらLokiやboostの立場が

228 :デフォルトの名無しさん:04/05/22 20:12
boostでmpl使ってるところなんてごく一部じゃない?
preprocessorは多用されてるけど、ほとんど可変個引数のエミュレート用だし。

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

230 :デフォルトの名無しさん:04/05/22 20:37
自分だけが使うものとか、ライブラリの内部実装だけで使われるなら使いまくってもいいんだろうけど。
みんなで見るような部分に入るようになると困るよな。わかってもらえるか心配だし。

231 :デフォルトの名無しさん:04/05/22 21:10
>>229
同意・・・templateを応用する本読んでいると頭痛くなってくる。
特に他人と共有するコードの場合、そこまでして使う価値があると
思えない。

232 :デフォルトの名無しさん:04/05/22 23:17
「書き込み専用コードは避けよう」ってやつか
プロジェクトの人間が皆templateを深く理解してるわけもないしな



オレモナー

233 :デフォルトの名無しさん:04/05/23 00:36
つか、こんなもん理解したくないってヤツが大半かと

234 :デフォルトの名無しさん:04/05/23 01:00
自分で書く分には便利だが保守させられる身になるとな。

235 :デフォルトの名無しさん:04/05/23 02:21
自分ですらすら書ける椰子へ。
頼むから、メタプログラム、式テンプレートあたりをわかりやすくレクチャしてくれい。
ってかして下さい mOm

236 :デフォルトの名無しさん:04/05/23 02:23
わかって、自分でもすらすら書いて、あんなもんは云々ってのはかっこいいけど。
理解する前にあんなもんっていうのは負け惜しみみたいで嫌ジャン。

237 :デフォルトの名無しさん:04/05/23 02:30
MPは代替手段があるけどETはこれしか手段がないからな。
もっと簡単に、わかりやすくならないもんかね。

238 :デフォルトの名無しさん:04/05/23 09:05
>>236
まあそれはそうだけど、仕事となると保守可能要員が減る
ことをわかってて書くほうがタチ悪いわな・・・

239 :デフォルトの名無しさん:04/05/23 09:41
>>237
ETの特別版
http://www.amazon.co.jp/exec/obidos/ASIN/B00005R22Y

240 :デフォルトの名無しさん:04/05/23 09:47
warata

241 :デフォルトの名無しさん:04/05/23 09:59
>>237
> MPは代替手段がある

あるの?

242 :デフォルトの名無しさん:04/05/23 10:37
MPとかETとかは、他の開発者に見えないように、内部の実装だけに使うのが良いんじゃないの?
「テンプレートとかわかんないし〜」とか言う馬鹿を相手にしなくて済むし。

243 :デフォルトの名無しさん:04/05/23 10:56
テンプレートが解かってても、読むのめんどくさい。
関数を大きくしないとか、そんなレベル。

244 :デフォルトの名無しさん:04/05/23 11:01
MPとかETって何?

245 :デフォルトの名無しさん:04/05/23 11:16
MP: Metha Programming
ET: Expression Template

246 :デフォルトの名無しさん:04/05/23 11:16
前者はホイミとかを唱えるのに必要なリソース。
後者は自転車で空を飛べるようになるライブラリ。

247 :デフォルトの名無しさん:04/05/23 11:17
スマソ
× Metha
○ Meta

248 :デフォルトの名無しさん:04/05/23 11:53
スマソ
× Metha
○ Metya

249 :デフォルトの名無しさん:04/05/23 12:56
なんかギャグセンスがオヤジな香具師がいるな

250 :デフォルトの名無しさん:04/05/23 13:27
いません

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

252 :デフォルトの名無しさん:04/05/24 01:44
>>251
なぁ、あんた>>237か?

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

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

253 :デフォルトの名無しさん:04/05/24 01:46
>252
251 じゃないが、プロプロセッサメタプログラミング、ならびにコードジェネレータ
(bison++ とか) を使ってのメタプログラミングがあるね。

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

254 :デフォルトの名無しさん:04/05/24 05:04
filesystemスタティックリンクしたら、
バイナリ200KBも大きくなった。
いや便利なんだけど。

255 :デフォルトの名無しさん:04/05/24 05:58
#define MYTYPE double

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

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

256 :デフォルトの名無しさん:04/05/24 09:17
>>254
環境によるだろ。
オプションを変更して、極力ランタイムを使用するようにすれば
使っても使わない時と比べ10octetほどしか増えない。

257 :デフォルトの名無しさん:04/05/24 09:32
>>252
251 じゃないが、C++でなくていいならCLOSとか。
Adaのpackage、MLのmoduleなんかも。
しかしC++のはCLOSに続いて強力だねえ。
コンパイル時ということになれば、研究用の言語は除いて最強か。

258 :デフォルトの名無しさん:04/05/24 10:09
>>256
(略

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

260 :デフォルトの名無しさん:04/05/24 10:38
メタプログラミング用に中間コード(生のソースじゃなくて、
パース後のデータ構造もツリーでもいいけど。)が見れるといいな。
Cで言えば、定数演算とインライン関数の展開された後のソースが
見れるような感じというか。

261 :デフォルトの名無しさん:04/05/24 11:17
用途は何?
OpenC++ってのがあるけど。
http://www.csg.is.titech.ac.jp/~chiba/openc++.html

262 :デフォルトの名無しさん:04/05/24 11:51
filesystemってunicode使えないの?

263 :デフォルトの名無しさん:04/05/24 15:04
>コンパイル時ということになれば、
コンパイル時ですべてが決定するわけだから、型部分をエディタでちょいちょいと置換
するのと大差ないって説も・・・

264 :デフォルトの名無しさん:04/05/24 15:59
それで済む以上のことをやっていない人間にとっては大差ないだろうな。

265 :デフォルトの名無しさん:04/05/24 23:09
>>263
君はC/C++でプログラムする時にマクロを利用することを禁止する。
ちょいちょいと置換したまえ。痴漢じゃないよ(欝

266 :デフォルトの名無しさん:04/05/24 23:22
>>263
結局実行ファイルが欲しいだけなんだから、実行ファイルをバイナリエディタでちょいちょいと
書くのと大差ないって説も・・・


267 :デフォルトの名無しさん:04/05/25 00:25
最初から設計が簡単にできて仕様の変更もないなら
コードジェネレーターでもいいんだろうけどね

268 :デフォルトの名無しさん:04/05/25 03:07
複雑なテンプレートをうれしそうに書くのは

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

269 :デフォルトの名無しさん:04/05/25 03:39
そ、それは複雑なのか?

270 :デフォルトの名無しさん:04/05/25 04:32
{}
と書く代わりに
begin end
で4倍複雑だ。

271 :デフォルトの名無しさん:04/05/25 05:41
そ、そうか。
これから変数は一文字にしよう…

272 :デフォルトの名無しさん:04/05/25 07:39
>>271
KVMじゃないんだから……

273 :デフォルトの名無しさん:04/05/25 08:47
複雑であることはC++のテンプレートとは何の関係もないんだよね
本来は複雑なものをシンプルに実装するための仕組みだし。
複雑なものを実装することも出来るけど、それはテンプレートとはまた別の話。


274 :デフォルトの名無しさん:04/05/28 19:22
vectorを配列ポインタとして、関数に使っているのですが、
いいのでしょうか?

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

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


現在うまく行ってるけど

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

275 :デフォルトの名無しさん:04/05/28 19:29
一度配列にコピー汁

276 :デフォルトの名無しさん:04/05/28 19:30
new[]/delete[]、malloc/free
書くのまんどくさいから、vector使ってるんですが
駄目ですか?

277 :デフォルトの名無しさん:04/05/28 19:32
>>274
保証されてる

278 :デフォルトの名無しさん:04/05/28 19:35
オーバーヘッドが気にならなくて
例外安全性とかまで考えるとそういう理由もいいんでないの

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

279 :デフォルトの名無しさん:04/05/28 19:44
>>277
23.1.1にも23.2.4にもそんな事書いてないけど?

280 :デフォルトの名無しさん:04/05/28 19:51
http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-defects.html#69

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

281 :デフォルトの名無しさん:04/05/28 20:19
>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().

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

282 :デフォルトの名無しさん:04/05/28 20:49
まぁ、basic_string<T>にすれば無問題だな。

283 :デフォルトの名無しさん:04/05/28 21:03
↑・・・・・↓

284 :デフォルトの名無しさん:04/05/28 21:13
ttp://www.s34.co.jp/cpptechdoc/article/vectorastemp/
ttp://www.tietew.jp/cppll/archive/9693
このあたり嫁。

285 :デフォルトの名無しさん:04/05/28 21:13
ttp://www.s34.co.jp/cpptechdoc/article/vectorastemp/
ttp://www.tietew.jp/cppll/archive/9693
このあたり嫁。

286 :デフォルトの名無しさん:04/05/28 23:18
vectorなんか使わず素直に配列使えよ。
そんなに記述量かわるわけでもあるまいし。

287 :デフォルトの名無しさん:04/05/28 23:22
俺のばやい。
ポインタで要素に自在にアクセスしたい場合や
速度がほしい場合はvectorは避けるようにしてるかな。

288 :デフォルトの名無しさん:04/05/28 23:25
俺のばやい。
ポインタで要素に自在にアクセスしたい場合や
速度がほしい場合はvectorは避けるようにしてるかな。

289 :デフォルトの名無しさん:04/05/28 23:39
別にiteratorでも使い勝手は同じだし、速度的にも全く差はないと思うが。
強いて言うならリサイズの必要が全くなければboost::*_arrayを検討する程度。

290 :デフォルトの名無しさん:04/05/28 23:39
>>287
vectorを避ける理由にまったくなっていない。

291 :デフォルトの名無しさん:04/05/28 23:55
EffectiveSTL読んで無い人はこのスレに書き込んじゃいけないんだよね?
>>1にもそう書いてあるはず。

292 :デフォルトの名無しさん:04/05/28 23:58
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;
}


293 :デフォルトの名無しさん:04/05/29 00:43
>>287
別にvectorを採用しなければならない理由はまったくない。

294 :デフォルトの名無しさん:04/05/29 00:58
物理メモリに直接アクセスするのが怖い奴ははじめからC#でもいじってろ。

295 :デフォルトの名無しさん:04/05/29 01:18
stringは確かに便利、listもbitsetもまぁ存在意義は認めよう。自分で書いて雛形持ってない奴にとっては便利だろう。
ただし、配列ごときでvectorなんていうまどろっこしいtemplate使う奴は、単なる馬鹿。


296 :デフォルトの名無しさん:04/05/29 01:47
>>295
なんでこのスレを読んでるのかと……
別に 295 が template 使わないのは構わんが、それを布教するなら
他でやった方が良いと思うぞ

297 :デフォルトの名無しさん:04/05/29 02:01
>>295
可変長配列でもvector使わないの?

298 :デフォルトの名無しさん:04/05/29 02:55
>stringは確かに便利、listもbitsetもまぁ存在意義は認めよう
この時点でSTL分からない奴なんだなーというのがバレバレなんですが


299 :デフォルトの名無しさん:04/05/29 03:25
>可変長配列でもvector使わないの?
realloc使え

300 :デフォルトの名無しさん:04/05/29 03:40
結局、resizeはrealloc使ってるんだよな。

301 :デフォルトの名無しさん:04/05/29 04:25
>>299
可変長配列ごときでreallocなんていうまどろっこしい関数使う奴は、単なる馬鹿。


302 :デフォルトの名無しさん:04/05/29 07:25
>>298
決め付け厨登場

303 :デフォルトの名無しさん:04/05/29 09:49
>>295
>ただし、配列ごときでvectorなんていうまどろっこしいtemplate使う奴は、単なる馬鹿。
禿げしく同意

304 :デフォルトの名無しさん:04/05/29 10:40
自分が思いつく動的配列に対するvectorの利点
・割り当てたメモリを(1回だけ,正しいサイズで)開放しなければならない,
 という責任を負わなくて良い
・配列のサイズに対する一貫性の責任を負わなくて良い
・例外安全性に対する負担が大幅に少ない(一般に例外安全性に対する
 認知度が低いので,このことが(゚д゚)ウマーに思われないことが多い.残念)
・アルゴリズムとの親和性が高い(一般にアルゴリズムの認知度が低いので,
 このことが(゚д゚)ウマーに思われないことが多い.残念)

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

305 :デフォルトの名無しさん:04/05/29 10:58
割り込みすまん!
MPのループ展開についてなんだが、
あれってなんのメリットあるの?
コンパイル時でなく実行時にループするんだから
結局なんのメリットもないような気がするんだが。

306 :デフォルトの名無しさん:04/05/29 11:21
実行時に効率がいいってくらい?

307 :デフォルトの名無しさん:04/05/29 11:33
>>305
コンパイル時にループを展開してしまえば、実行時に

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

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

308 :デフォルトの名無しさん:04/05/29 11:41
>>292
- Loki::TL::TypeAt< X, 0 >::Result a;
+ typename Loki::TL::TypeAt< X, 0 >::Result a;
3.3.3ではこれで通る.


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

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


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

311 :デフォルトの名無しさん:04/05/29 13:57
動的配列なんか少なくとも俺は必要ない。

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

312 :デフォルトの名無しさん:04/05/29 13:59
STLのアルゴリズムだろ。
まあ、あれは配列にも適用できるんだが。

313 :デフォルトの名無しさん:04/05/29 14:01
なぁーんだ。
ソートしたりカウントしたりといった。FFTも理解できん9図ガキでもわかるC++のアルゴリズムのことか


314 :デフォルトの名無しさん:04/05/29 14:12
>>311
カルマンフィルタってアルゴリズムか?

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

316 :デフォルトの名無しさん:04/05/29 14:32
>>314
mean square error を最小にするように Kalman gain を決定する算法そのものを
Kalman filter algorithmと言うんだよ。
大体、algorithm っていうのは算法、解法とか、手順のことを言うの。
STLのalgorithmなんて解法には値しない低レベルなもの。

317 :デフォルトの名無しさん:04/05/29 14:40
別にアルゴリズムかどうかとレベルは関係ないだろ。
それにソートなんて単純に見えて相当奥が深いぜ。

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

319 :デフォルトの名無しさん:04/05/29 14:50
>>317
>それにソートなんて単純に見えて相当奥が深いぜ。
そんなに奥が深くて、評価や実装が難しいものなら標準化なんかしない。
簡単で、皆がよく使うものだから。標準化して用意してるんだよ。

320 :デフォルトの名無しさん:04/05/29 14:50
>>313
お前はいまFFTを理解していない人間全てを敵に回した!

321 :デフォルトの名無しさん:04/05/29 14:52
アフォ敵に回しても痛くも痒くもないんだが。

322 :デフォルトの名無しさん:04/05/29 14:52
FFTごとき馬鹿でも理解できるだろ。
理解できなきゃ人間やめろ。

323 :デフォルトの名無しさん:04/05/29 14:55
>>320
FFTぐらい理解してても何の自慢にもならないが、理解できなきゃ恥だな。
っていうより、理解できないことをここでわざわざ主張しなくてもいいってば。

324 :デフォルトの名無しさん:04/05/29 15:02
なんだこりゃ、定番のジョークにそんなに必死になられても、どう反応すればいいのやら。

325 :デフォルトの名無しさん:04/05/29 15:04
別に必死になってるわけでなくて暇ですることないから書き込んでるだけなのだが。

326 :デフォルトの名無しさん:04/05/29 15:06
スレと関係ないこと書いて、誰かが
"スレ違い!"
と叫ぶのを待ってるわけなのだが。

327 :デフォルトの名無しさん:04/05/29 15:11
スレ違い!↓

328 :317:04/05/29 15:16
>>319
STLに限らずアルゴリズム一般の話をしてたんだが。

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

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

329 :デフォルトの名無しさん:04/05/29 15:16
わかった。
溜まってるのでソープにでも行ってくるわ。

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

331 :デフォルトの名無しさん:04/05/29 15:19
char が unsigned でなければコンパイルエラーにするテンプレートを教えて
ください。charは型的にはsigned charでもunsigned charでもないので下のやつ
では駄目でした。

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

CharTest<char> ctc;


332 :デフォルトの名無しさん:04/05/29 15:23
>>328
>簡単だからというのは同意しない。
使い手の手の加えようのないぐらいすでに評価が定まってるから標準化してるんだよ君。


333 :331:04/05/29 15:30
できた

334 :デフォルトの名無しさん:04/05/29 15:31
ここは見下し厨の多いインターネッツですね

335 :デフォルトの名無しさん:04/05/29 15:42
また、録音か!

336 :デフォルトの名無しさん:04/05/29 15:45
見下し厨、そんな態度で会社とかで大丈夫なんかね・・・
周りの人から見放されてないか心配だ・・・2chだから吠えてるだけですよね・・・

337 :デフォルトの名無しさん:04/05/29 16:27
>>331
BOOST_STATIC_ASSERT(!std::numeric_limits<char>::is_signed);

こんな感じでどう?

338 :デフォルトの名無しさん:04/05/29 16:27
>>332
外部仕様がシンプルなのと、実装がシンプルなのは話が全く違うわけだが。
UNIX なんかシステムコール 100 のオーダーしかなくて見た目はシンプルだが、
効率の良い実装を提供しようと思ったら大変だろ。

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

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

339 :デフォルトの名無しさん:04/05/29 16:39
>>336
彼は人間関係が築けなくても生きていける学生か研究者
ではないかと思われるわけだが

340 :デフォルトの名無しさん:04/05/29 17:02
>>339
単なる無職ひきこもりだろ

341 :デフォルトの名無しさん:04/05/29 17:24
STLport, boost, Lokiをインスコしようと思ってるですが
インスコの順番はこの順が良いってのあります?

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

環境はWinXP pro + VS.NET2003です

342 :デフォルトの名無しさん:04/05/29 17:28
STLPortが先、以下順不同

343 :341:04/05/29 20:08
>>342
dクスコ

344 :デフォルトの名無しさん:04/05/29 23:30
STL的なFFT実装、pFFT++
http://www.mit.edu/people/zhzhu/pfft.html

345 :デフォルトの名無しさん:04/05/30 03:33
>>308 遅レスですが、有難うございます。
気づきませんでした。何処を見たら気づけたのでしょうか?

346 :デフォルトの名無しさん:04/05/30 10:09
>>345
ttp://tt.sakura.ne.jp/~suzu/template/typename.html

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

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


348 :デフォルトの名無しさん:04/05/30 14:40
boostの導入を考えてるんですが、
FAQをみるとboostは下位互換性がいつも保たれてるわけじゃないので、
プロジェクトごとにboostのバージョンを固定して使うようにとあります。

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

こんな感じですか?

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

方法2:
(゚ε゚)キニシナイ!!

349 :デフォルトの名無しさん:04/05/30 15:16
>>348
> プロジェクトごとにどのboostバージョンを使っているかコメントに書いておき、
コメントではなく Makefile に書いてる。インクルードパスとライブラリの検索パスを
プロジェクト毎に設定すれば良いだけ。

350 :デフォルトの名無しさん:04/05/30 16:53
>>347
逆にVC7.1は頭が良すぎてtypenameを付けなくてもエラーが発生しない場合が
多いので、VC7.1を多用されている時は気をつけよう。

351 :デフォルトの名無しさん:04/05/30 20:52
>>350
VC7.0 は、の間違い。VC7.1 は typename でエラー出すようになってるよ。

352 :デフォルトの名無しさん:04/05/30 23:16
>>351
いや、VC7.1の場合だ。間違いではない。もうしょっちゅう経験している。

353 :デフォルトの名無しさん:04/05/31 11:43
単にlevel設定が違うだけじゃ

354 :デフォルトの名無しさん:04/06/04 00:18
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");
  }
 };
}]

355 :デフォルトの名無しさん:04/06/04 00:41
ServicePack6なんて出たの?

356 :デフォルトの名無しさん:04/06/04 01:32
VC++でLokiを使いたい時って
sourceforgeのLokiとLokiPortのどっちか片方だけで良いの?
それとも両方?

357 :デフォルトの名無しさん:04/06/04 07:13
>>356
VC は、6, 7.0, 7.1 でまったく別モノだから、バージョンも書け。
たぶん sourceforge 版に取り込まれているとは思うけどな。

358 :354:04/06/04 09:05
>>355
http://www.microsoft.com/japan/msdn/vstudio/downloads/sp/VS6SP6.asp

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

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

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

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

360 :デフォルトの名無しさん:04/06/05 00:31
>>359
Thrower("Dead Reference Detected");

Loki::Thrower("Dead Reference Detected");

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

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

362 :359:04/06/05 09:01
>>360
ありがとうございます!
>>360の方法は俺もやってましたが、
>>361は知らんかったなぁ。
てか、複数回定義でなくて良かった・・・。
でてたら憤死してたかも。

363 :356:04/06/05 12:50
>>357
> VC は、6, 7.0, 7.1 でまったく別モノだから、バージョンも書け。
これは失礼した
6, 7.0, 7.1全部インスコしてあるけど使ってるのは7.1

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

ソースホゲとポートVC7の両方落としてみたんだけど
片方にあって片方にないファイルがあったんで
どうなんだろうと思って

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

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


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

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

367 :デフォルトの名無しさん:04/06/09 17:27
>・if forの後に空白がない
>・「 { 」の前にも空白や改行がない
これはどうでも良くないか?

368 :デフォルトの名無しさん:04/06/09 18:42
俺もそう思った。問題を大杉に見せたかっただけちゃうんかと。

369 :デフォルトの名無しさん:04/06/10 04:10
テンプレートの実体化を遅らせるにはどうすればいいですか
具体的にはstruct Bをテンプレートにしないで
以下のようなものをコンパイルしたいです

template<class T> struct A{};

struct B
{
  typedef A atype;
};

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

370 :デフォルトの名無しさん:04/06/10 04:58
> 具体的にはstruct Bをテンプレートにしないで
> 以下のようなものをコンパイルしたいです
とりあえずそれだけなら。

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

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

371 :デフォルトの名無しさん:04/06/10 05:02
>>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;
}


372 :デフォルトの名無しさん:04/06/10 05:04
>>370 かぶったね

373 :369:04/06/10 06:51
ありがとうございました

374 :デフォルトの名無しさん:04/06/10 07:23
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です


375 :デフォルトの名無しさん:04/06/10 10:02
>>374
> struct C: B<C>
このB<C>のインスタンス化の時点でCが不完全なんだろう。
後は、前スレの145,169-172あたり見れ。

376 :デフォルトの名無しさん:04/06/10 15:35
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; //これならうまくいく・・
}
}


377 :デフォルトの名無しさん:04/06/10 15:43
>>376
(*it)->nNumber

378 :デフォルトの名無しさん:04/06/10 16:29
>>377
あっさり通りました・・・
ありがとうです。

379 :デフォルトの名無しさん:04/06/10 18:55
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>());
   }
  //略
};

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

380 :365:04/06/16 00:24
365です。
>366
レスThx!
手を抜いてると幾つか問題が出ちゃうね。
精進します。

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


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

382 :デフォルトの名無しさん:04/06/17 14:29
なんかスレに沿わない気がしますが、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のオプションが怪しいと考えています。

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

383 :デフォルトの名無しさん:04/06/17 20:13
vc7.1というかvc7.0にVCtoolkit2003を入れたやつで漏れもはまったけど
スタティックリンク版はコンパイルできてもダイナミックリンク版は
通らないみたい。ので、スタティックリンク版を使ってます。。。

384 :デフォルトの名無しさん:04/06/18 06:12
> winstances.obj : error LNK2019: 未解決の外部シンボル (長すぎて書き込めないので略)

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

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

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

385 :デフォルトの名無しさん:04/06/18 13:47
素直に7.1に乗り換えたらどう?

386 :デフォルトの名無しさん:04/06/18 23:49
>>382
それを解決するには(長すぎて書き込めないので略)


387 :デフォルトの名無しさん:04/06/19 00:52
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;
}

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

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

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

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

390 :デフォルトの名無しさん:04/06/19 05:33
通らないのはこっちだった。変換できないそうだ。
string::size_type (string::*p_find)(const string&, string::size_type) = &string::find;

391 :デフォルトの名無しさん:04/06/19 06:34
const が抜けてないか?
string::size_type (string::*p_find)(const string&, string::size_type) const = &string::find;

392 :デフォルトの名無しさん:04/06/19 06:57
>>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);


393 :デフォルトの名無しさん:04/06/19 23:33
今日本屋にいったらboost本が出てたよ
http://www.amazon.co.jp/exec/obidos/ASIN/4798007862/249-0609019-0421111
みんな読んだ?

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


394 :デフォルトの名無しさん:04/06/20 00:14
情報遅すぎ

395 :デフォルトの名無しさん:04/06/21 20:50
>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に。

396 :デフォルトの名無しさん:04/06/21 20:55
ちなみに
typename ProductCreator = boost::shared_ptr<AbstractProduct>(*)(),
の部分は
typename ProductCreator = boost::function<Product<AbstractProduct> ()>
ってやっとけば何でも入っていいかも。遅いかもしれんけど

397 :デフォルトの名無しさん:04/06/21 20:57
ああ、typeぬけてた。。
連書きすまそ。
typename ProductCreator = boost::function<Product<AbstractProduct>::type ()>


398 :379:04/06/21 22:19
>>395-397
いえいえ、どうもありがとうございますです。
なるほど、boost::functionはいいっすねぇ。

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

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

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

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


402 :デフォルトの名無しさん:04/06/23 00:11
>>401
おおっと!ご本人さんのご登場です。

403 :デフォルトの名無しさん:04/06/23 00:13
俺もboost本はありがたかったけどなぁ。
まぁ確かに深さは無かったかもしれんが、イキナリそんなにディープだったら
そっちの方がむしろビックリかと。

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


405 :デフォルトの名無しさん:04/06/23 00:25
>>404
boost作った奴らがあがりよこせと言ってきたらどうするんだろね。

406 :デフォルトの名無しさん:04/06/23 00:32
他人が金儲けするのがとても気に食わないらしい

407 :デフォルトの名無しさん:04/06/23 00:33
同じC++プログラマとして恥ずかしいから、
そんな方向で盛り上がるなよ。

408 :デフォルトの名無しさん:04/06/23 00:35
こういうので文句言う奴って本が出るたびに「自分で作ったわけじゃないのに他人のふんどしで・・・」ってウジウジ言ってるのかな

409 :デフォルトの名無しさん:04/06/23 00:36
>>404
アフォか。んなこというとC++の解説書書いてるやつらもみんな同罪だろ。

410 :デフォルトの名無しさん:04/06/23 00:45
C++の解説は規格の解説だ。
boost本は特定の処理系に関する解説に近いな。
gccの解説とかな。

411 :デフォルトの名無しさん:04/06/23 00:46
GCC の解説本書いた奴は普通 GNU に寄付する罠。

412 :デフォルトの名無しさん:04/06/23 00:50
boostな人達とAlexandrescuっていまいち仲良くなさそうだよね。

413 :デフォルトの名無しさん:04/06/23 00:55
>>406
気に入らないね。直接努力してるboost クリエイタに一銭も行かないのは大問題だ。

414 :デフォルトの名無しさん:04/06/23 01:02
一般的に言ってコード書きよりドキュメント書きのほうが面倒だから、人の嫌がることをやる奴が利益を得るという点では問題ないと思うが。

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

415 :デフォルトの名無しさん:04/06/23 01:17
>Boost本の内容の薄さは別として。
それが問題なんだよね。内容が濃ければ人のふんどしとは誰も言わない。

416 :デフォルトの名無しさん:04/06/23 01:20
>>413,414
そういうライセンスで作者が公開しているから問題は皆無。
413の「気に入らない」という気持は分からんでもないが、同意は全くできない。


417 :デフォルトの名無しさん:04/06/23 01:24
>>416
おおっと。ご本人さん。
ご自分の利権主張にはご熱心で抜け目ないね。

418 :デフォルトの名無しさん:04/06/23 01:26
>>416
別にお前に同意いただかなくとも全く結構だから、安心しな。

419 :デフォルトの名無しさん:04/06/23 01:30
つか、言っちゃ悪いがあの程度の本を買ってしまったおまいらが悪い。
Amazonでかった?だったら返品すればいいだろ。

420 :デフォルトの名無しさん:04/06/23 01:33
>>417,418
内容の論評だけにしとけ。見苦しい。


421 :デフォルトの名無しさん:04/06/23 01:34
書籍って未開封とか乱丁、落丁本以外返品できるの?

422 :デフォルトの名無しさん:04/06/23 01:36
>>416,420
自己弁護は自分のホームページだけにしとけ。見苦しい。

423 :デフォルトの名無しさん:04/06/23 01:42
はぁ、IDあればあぼーん出来るのにな・・・

>>421
無理。

424 :デフォルトの名無しさん:04/06/23 01:46
(;´Д`) だから、お前ら恥ずかしいからそんな話はやめれっちゅーに。

425 :デフォルトの名無しさん:04/06/23 01:51
あの本の内容があまりにしょーもないというのがなんで恥ずかしいんだ?

426 :デフォルトの名無しさん:04/06/23 02:04
内容がしょーもないと言うのが恥かしいのではなく、金儲けするのが嫌だというのが恥かしい。金儲けしたかったら自分で売れる本書けよ。

427 :デフォルトの名無しさん:04/06/23 02:06
他の本でこんなくだらんことで盛り上がってるの見たこと無いな。
あの本の著者に個人的な恨みがある奴が今いるのか?

428 :デフォルトの名無しさん:04/06/23 02:44
というか単なる負け犬の遠吠えにしか聞こえん。
とか言うと本人扱いされそうな悪寒

429 :アンケート:04/06/23 03:04
・boost 本買ってショーもなかったと思う人の数-->
・よかったと思う人の数-->


430 :デフォルトの名無しさん:04/06/23 03:07
・そもそも買ってない人→1

431 :デフォルトの名無しさん:04/06/23 03:07
>金儲けするのが嫌だというのが恥かしい
お前脳のMRIでも撮影してもらえ、そんなことは誰も言ってない。

432 :デフォルトの名無しさん:04/06/23 03:13
>>420
>とか言うと本人扱いされそうな悪寒
と言えばごまかせると思ってる時点でマヌケなんだよ。

433 :デフォルトの名無しさん:04/06/23 03:14
あげて厨さそおっと。エイッ

434 :デフォルトの名無しさん:04/06/23 03:28
きっとboost本が一冊しか無いからこんなことで盛り上がれるんだろうな…

435 :デフォルトの名無しさん:04/06/23 03:36
まぁ事の発端は>>399がよく調べもせずに買ったのが悪いんだけどな。
愚痴なら自分の日記にでも書いとけ。


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

437 :デフォルトの名無しさん:04/06/23 08:03
ここで金儲けだなんだと文句言ってるのはオープンソース厨房?
じゃあお前が書けよって感じだな(ぷっ

438 :デフォルトの名無しさん:04/06/23 08:32
なんでこんな嫉妬丸出しのスレになってんの?

439 :デフォルトの名無しさん:04/06/23 08:44
内容が薄いことに金儲けを絡めて書いた馬鹿が悪い。

440 :デフォルトの名無しさん:04/06/23 08:57
自分で書く能力もないのに、どうしてこんなに偉そうなんだろう。

441 :デフォルトの名無しさん:04/06/23 09:25
>>440
ライブラリも本も書けない奴らが自尊心を保つ為に仕方が無い事なのです。
せめてここでは愚痴を聞いてあげましょう。

442 :デフォルトの名無しさん:04/06/23 09:32
おまいらシュッシュのやばさを(r

443 :デフォルトの名無しさん:04/06/23 10:22
久しぶりに伸びてるなと思ったら…案の定こんな展開かよ。

444 :デフォルトの名無しさん:04/06/23 10:28
俺もオモタ

445 :デフォルトの名無しさん:04/06/23 10:55
所詮 2chねる=下痢便 だから

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


447 :デフォルトの名無しさん:04/06/23 14:10
けど、アマゾンで在庫切れだし、ラオックスいったら山積みなってたよ
機能と、サンプルソースとかぐぐるより早くたどりつくと考えれば
結構いいんじゃね? 漏れも買ったし・・・ orz

448 :399:04/06/23 14:43
>>436
バーカ。
それは俺が書いたんだよ。

449 :デフォルトの名無しさん:04/06/23 14:48
>>446
それならBoost C++ library referenceにしろってんだよ。
Boost C++ library programming なんていう内容の深さを匂わせるような
名称はやめろってこった。

450 :デフォルトの名無しさん:04/06/23 14:51
稲葉は叩かれると防戦に必死だな

451 :デフォルトの名無しさん:04/06/23 15:02
もっと荒れろ

452 :デフォルトの名無しさん:04/06/23 15:15
>>449
おまえが内容を確認しないで買うってのはもうわかったから駄々こねるな。

453 :デフォルトの名無しさん:04/06/23 15:19
>>399が騒げば騒ぐほど、自身の買い物の下手さを宣伝することになる。
だから恥かしいんだよな。

454 :デフォルトの名無しさん:04/06/23 16:54
週間ポストのヘアヌード掲載号は10年後プレミアムがつくが
Boost 本は1年でゴ(ry

455 :デフォルトの名無しさん:04/06/23 16:55
結局この本は買う価値があるのか無いのかどっちだ?

456 :デフォルトの名無しさん:04/06/23 16:55
C++の本は駄本と良本の区別がハッキリしてるからな。
駄本掴まされたやしがむしろバカ。

457 :デフォルトの名無しさん:04/06/23 17:04
じゃ、買うのは馬鹿といえる本なのか?

458 :デフォルトの名無しさん:04/06/23 17:05
普通の人はソース読んで使うから今まで本が出る必要がなかったつーか
本にするほどのもんでもないと思ってたな

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


460 :デフォルトの名無しさん:04/06/23 17:40
>>459
正規表現のドキュメント古すぎ

461 :デフォルトの名無しさん:04/06/23 17:42
とびっきりのスーパーテクニックが載ってる本も楽しいだろうけど、
単純に学習時間を短縮できるような本だってあってもいいはず。

462 :デフォルトの名無しさん:04/06/23 17:48
>>460
日本語訳プロジェクトに参加した事もない癖に、つべこべ文句を言う資格は無し。

463 :デフォルトの名無しさん:04/06/23 17:54
>>462
べつに文句は言ってないと思うぞ。本当のことを言っているだけで。

464 :デフォルトの名無しさん:04/06/23 18:00
つーか買う必要があるかどうかくらい自分で確認して自分で判断しろ。
誰もてめーの欲しがる本のレベルや内容なんて知らねーんだよ。
そして駄本だと思ったらいつまでもぐだぐだ言うな。
紹介したけりゃ良書の紹介しろ。

465 :デフォルトの名無しさん:04/06/23 18:01
>>463
そういうのを文句って言うんだ。頭冷やして出直せ。

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

467 :デフォルトの名無しさん:04/06/23 18:28
>フリーウェアに対しては文句言うな。
なぜだ?別に改善を要求してるわけじゃないだろ?

468 :デフォルトの名無しさん:04/06/23 18:30
稲葉 vs http://boost.cppll.jp/HEAD/libs/libraries.htmの訳者
ってことですかね。
メールでやれ

469 :デフォルトの名無しさん:04/06/23 18:31
>>465-446
…。フリーウェアに対して文句が言えなくなったら、
その時点でそれ以上の発展は望めないよ。
あ、「ここはこうしたほうがいい」って言えば文句にはならないのかな…

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

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


470 :デフォルトの名無しさん:04/06/23 18:46
>>399を叩いている奴がいるが、
>>399のアマゾンでの評価は納得できるから、
>>399は身銭を切って本の評価をしてくれたと考えることもできる。


471 :デフォルトの名無しさん:04/06/23 18:52
まぁその程度の評価なら立ち読みでわかるけどな。

472 :デフォルトの名無しさん:04/06/23 19:00
これ以上は書籍スレでやれよな

473 :デフォルトの名無しさん:04/06/23 19:00
だよな。

474 :デフォルトの名無しさん:04/06/23 19:01
書籍スレは「推薦図書」だから罵倒したいだけならあっちでもやるなよ。

475 :デフォルトの名無しさん:04/06/23 19:03
>>468
この一連のレスをみれは、どうみても違うって、
稲葉叩いているのはboostを触った事も無いようなタコだろ
微妙におかしな論点になってるじゃん

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

476 :デフォルトの名無しさん:04/06/23 19:05
>>469の馬鹿へ
オリジナルの英語の外仕読んで使い方のわからんカスがboost なんか使うな。
お前みたいなアフォが居ると周りのものが迷惑するんだよ。

477 :デフォルトの名無しさん:04/06/23 19:05
>>470
というか俺には>>399が書いたって言うのは嘘だとしか思えんのだが?

478 :デフォルトの名無しさん:04/06/23 19:07
>>476
はいはい、気がすんだら首つって死んでろ

479 :デフォルトの名無しさん:04/06/23 19:09
>>478
お前は5階から中学生に突き落としてもらえ。

480 :デフォルトの名無しさん:04/06/23 19:10
>>479
わかったから、age んな

481 :デフォルトの名無しさん:04/06/23 19:11
頼むから>>399
http://pc5.2ch.net/test/read.cgi/tech/1085915001/
この辺でやってくれ。お似合いだから

482 :デフォルトの名無しさん:04/06/23 19:14
>>476みたいな英語談義に持ってく奴も毎度お馴染みだな。

483 :デフォルトの名無しさん:04/06/23 19:26
>>469
普通、邦訳ドキュメントが古いと思ったら英語であればオンラインの原文読むだろ。
それを本が出版されるまで待ってること自体、お話にならんな。どんな仕事してるんだ?

484 :デフォルトの名無しさん:04/06/23 19:35
>>467
フリーウェアに対して許されるのは依頼だけ。
文句は許されない。嫌なら使うな。読むな。
文句言う奴がアフォ

485 :デフォルトの名無しさん:04/06/23 19:44

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


486 :デフォルトの名無しさん:04/06/23 19:46
↑ お 前 も な

487 :デフォルトの名無しさん:04/06/23 19:47
>>483
阿呆やなぁ。
Boost の裾野を広げるには日本語で十分な Document があることは必須やろ。
あと、
> それを本が出版されるまで待ってること自体、お話にならんな。
って、>>469 のどこをどう読めばそういう解釈になるのやら。

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

488 :デフォルトの名無しさん:04/06/23 19:53
>Boost の裾野を広げるには
何勘違いしてるか知らんが、boostの裾野なんか広げる必要は全くないね。
使いたい奴が自分の能力に合わせて使えばいい。くだらんライブラリも実際あるしな。
布教活動でもしたいのかい?

489 :デフォルトの名無しさん:04/06/23 19:55
>>469=487
>って、>>469 のどこをどう読めばそういう解釈になるのやら。
他人のふりするな。

490 :デフォルトの名無しさん:04/06/23 19:56
ユーザーが多ければ有用な情報や良書がでる確率が増えるだろうな。

491 :デフォルトの名無しさん:04/06/23 19:56
C++スレでも暴れ足りず、今度はtemplateスレを荒らしているC厨がいるという
スレはここですか?

492 :デフォルトの名無しさん:04/06/23 19:56
>>489
変な解釈したことは否定しないんだな

493 :デフォルトの名無しさん:04/06/23 19:57
諸悪の根源は>>399

494 :デフォルトの名無しさん:04/06/23 19:58
       まもなくここは 乂1000取り合戦場乂 となります。

      \∧_ヘ     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ,,、,、,,, / \〇ノゝ∩ < boost本で1000取り合戦、いくぞゴルァ!!     ,,、,、,,,
    /三√ ゚Д゚) /   \____________  ,,、,、,,,
     /三/| ゚U゚|\      ,,、,、,,,                       ,,、,、,,,
 ,,、,、,,, U (:::::::::::)  ,,、,、,,,         \オーーーーーーーッ!!/
      //三/|三|\     ∧_∧∧_∧ ∧_∧∧_∧∧_∧∧_∧
      ∪  ∪       (    )    (     )   (    )    )
 ,,、,、,,,       ,,、,、,,,  ∧_∧∧_∧∧_∧ ∧_∧∧_∧∧_∧∧_∧
      ,,、,、,,,       (    )    (    )    (    )    (    )


495 :デフォルトの名無しさん:04/06/23 20:00
393の導火線があるな。

496 :デフォルトの名無しさん:04/06/23 20:00
>>494
もうかよ?!


497 :デフォルトの名無しさん:04/06/23 20:00
たしかに>>393もアレだな

498 :デフォルトの名無しさん:04/06/23 20:01
結局、3000円弱を出費する価値があるのかないのかどっちよ?

499 :デフォルトの名無しさん:04/06/23 20:03
>>498
だからてめーにとって価値があるかどうかが何で俺らにわかるんだタコ。

500 :デフォルトの名無しさん:04/06/23 20:05
>>499 糞レスわざわざ書き込むな

501 :デフォルトの名無しさん:04/06/23 20:05
>>484
なぜだ?と聞いてるのに主張を繰り返されても…

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

502 :デフォルトの名無しさん:04/06/23 20:07
>>500
せっかくの500がおまえのような糞レスでがっかりだ!

503 :デフォルトの名無しさん:04/06/23 20:08
>>501
馬鹿か?お前?

504 :デフォルトの名無しさん:04/06/23 20:08
フリーソフトの話にまで広がったか・・・

505 :デフォルトの名無しさん:04/06/23 20:09
フリーに対して文句言ってもそれは文句言う側の勝手だろうが、俺がフリーの
開発者だったら文句言う奴は叩き潰す。

506 :デフォルトの名無しさん:04/06/23 20:09
俺は放置する。相手すんのめんどくさいもん。

507 :デフォルトの名無しさん:04/06/23 20:10
>>501
>フリーと商用を区別するのかわからない
わからなければ死ねよ。

508 :デフォルトの名無しさん:04/06/23 20:11
>馬鹿か?お前?
ワラタ

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

509 :デフォルトの名無しさん:04/06/23 20:15
もう馬鹿とか死ねとかしか出てこないスレになりました

510 :デフォルトの名無しさん:04/06/23 20:16
いや、俺はこれから飯だ

511 :デフォルトの名無しさん:04/06/23 20:18
手淫はまだ早いかな。

512 :デフォルトの名無しさん:04/06/23 20:19
>>501
自分で金稼げるようになってからゴタク並べな。ガクセイちゃん。

513 :デフォルトの名無しさん:04/06/23 20:20
文句や依頼をするのは勝手だが、作者がそれに対応するかどうかも作者の勝手だ。それでいいじゃないか。

514 :デフォルトの名無しさん:04/06/23 20:21
いや、文句言うこと自体マナー違反だ。負担にならないように依頼、お願いすべきもの。

515 :デフォルトの名無しさん:04/06/23 20:23
>>514
DQNにマナー要求しても、無駄。行動で示すしかない。

516 :デフォルトの名無しさん:04/06/23 20:24
そうそう、>>514は正論だがDQNユーザーがいるのが現実。

517 :デフォルトの名無しさん:04/06/23 20:31
>行動で示すしかない。
どうするんだ?

518 :デフォルトの名無しさん:04/06/23 20:39
IDがでなくても連鎖あぼ〜ん

519 :デフォルトの名無しさん:04/06/23 20:48
さらしあげ

520 :デフォルトの名無しさん:04/06/23 20:59
>>517
具体的に書いたら通報されるので、書けない。

521 :デフォルトの名無しさん:04/06/23 21:02
つまりぬっこr

522 :デフォルトの名無しさん:04/06/23 21:10
つまりぬっころs

523 :デフォルトの名無しさん:04/06/23 21:16
ぬっころ?ピッコロじゃないのか?

524 :デフォルトの名無しさん:04/06/23 21:20
なんじゃこのスレ

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

525 :デフォルトの名無しさん:04/06/23 21:30
>>524
意味わかってるよな?

526 :デフォルトの名無しさん:04/06/23 21:35
Aransk先生がC/C++に興味をもたれたようです。
http://homepage3.nifty.com/Aransk/contents4.html

527 :デフォルトの名無しさん:04/06/23 21:40
>>526
絶妙なタイミングで変なネタもってくるんじゃねーよこの、チョンマゲ

528 :デフォルトの名無しさん:04/06/23 21:46
>>527
へんなネタって何です?Genericクラスに関するHPですよ

529 :デフォルトの名無しさん:04/06/23 21:49
>>526=528=Aransk

死 ね

530 :527:04/06/23 21:50
>>528
はいはい反応した俺が悪かったですよAransk大先生。
とりあえず氏んでください。


俺も吊ってきます。反応してワルカタ。

531 :デフォルトの名無しさん:04/06/23 22:06
(´-`).。oO(相談室からとびひしてるのかな?この雰囲気)


532 :デフォルトの名無しさん:04/06/23 22:09
夏厨が湧く次期だからな。高校は休みに入ってる所があるし。

533 :デフォルトの名無しさん:04/06/23 22:16
おいおい、6月からマジかよ

534 :デフォルトの名無しさん:04/06/23 22:17
>>532
嘘コケ!お前が個人的に休暇とってる引きこもり高校生だろが。

535 :デフォルトの名無しさん:04/06/23 22:19
むしろヒキコモリオヤジなよかん

536 :デフォルトの名無しさん:04/06/23 22:24
>>534
私立の高校ならもう期末テスト終わって休みに入ってる所があるよ。
>>535
( ゚Д゚)ハァ?オヤジはお前だろヴォケ。

537 :デフォルトの名無しさん:04/06/23 22:28
なんだこのスレ

538 :デフォルトの名無しさん:04/06/23 22:44
まだやってんのかよ('A`)

539 :デフォルトの名無しさん:04/06/23 23:03
初心者本があるお陰で、boostの裾野が広がる
メリットが開発人にはあるから、ここでウザイ連中よりましかと思いますた。

540 :デフォルトの名無しさん:04/06/23 23:10
そうですね。

 終 了

541 :デフォルトの名無しさん:04/06/23 23:10
>>539
自書の宣伝ごくろーさん

542 :デフォルトの名無しさん:04/06/23 23:31
そんなこんなでシツモンデス

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

function<void ()> f;

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

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

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

543 :デフォルトの名無しさん:04/06/23 23:51
boolは整数型に暗黙の変換が成立してしまうから

544 :名無しさん@Vim%Chalice:04/06/24 00:01
>>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に暗黙の変換がされないからコンパイル時にエラーになってくれる、と。

545 :544:04/06/24 00:01
ぐは、激しく遅くしかも冗長だった…スマン。

546 :544:04/06/24 00:02
しかもミスまで…逝ってくる…
s/aho/hoge/

547 :デフォルトの名無しさん:04/06/24 00:12
>>542
boost 本に載ってるよ。

548 :デフォルトの名無しさん:04/06/24 00:26
boost本をばかにした者はboost本に泣く。

549 :デフォルトの名無しさん:04/06/24 00:38
著者さんよ。嘘も休み休み言え、もうさんざん濡れ手に粟を味わったんだから被害者増やすな。

550 :デフォルトの名無しさん:04/06/24 00:51
>>549
悔しかったら君も本を書いて売ってみたまえ。

551 :デフォルトの名無しさん:04/06/24 00:56
次にお前は「誰が悔しいなんて言ったよw」という!

552 :デフォルトの名無しさん:04/06/24 01:07
呼び水あげ

553 :デフォルトの名無しさん:04/06/24 01:07
しかしよくネタにマジレスできるもんだな

554 :デフォルトの名無しさん:04/06/24 01:12
ネタにネタレスであることがわからんかねチミ

555 :デフォルトの名無しさん:04/06/24 01:14
病人を相手にしないように>ALL

556 :542:04/06/24 01:23
なるほど。分かりやすい説明ありがとうございます。

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

557 :デフォルトの名無しさん:04/06/24 01:30
>>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);//だと後者が呼ばれる。



558 :544:04/06/24 10:57
>>557
いや、別にpublicとかprivateとか書くと行が増えるから、とりあえず例として
struct にしただけなんで…

559 :デフォルトの名無しさん:04/06/24 13:20
>>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


560 :デフォルトの名無しさん:04/06/24 20:11
失礼します。

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の型が不正だと言われます。
何かここ以外で記述が足らないのでしょうか?
宜しくお願いします。


561 :デフォルトの名無しさん:04/06/24 20:48
>>560
質問の趣旨は別にして、
それはマルチバイトじゃなくてワイド文字列ですな

562 :デフォルトの名無しさん:04/06/24 21:02
あ、そうなのですか。
ご指摘ありがとうございます。


563 :デフォルトの名無しさん:04/06/24 21:13
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が通らない。


564 :デフォルトの名無しさん:04/06/24 21:14
>>560
VCのサービスパックは入ってる?
うちでは動いたよ。

565 :デフォルトの名無しさん:04/06/24 21:50
レスありがとうございます。

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

: error C2665: 'regex_search' : 10 のオーバーロードは 1 番目の引数を
'class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,
class std::allocator<unsigned short> >'
から要求の型に変換できません。(新しい機能 ; ヘルプを参照)

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


566 :デフォルトの名無しさん:04/06/24 21:56
つーか、boostのバージョンとSTLの種類ぐらいかいとけ

567 :デフォルトの名無しさん:04/06/25 02:29
>>560,565
boost::wregex

568 :デフォルトの名無しさん:04/06/25 08:11
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.

569 :デフォルトの名無しさん:04/06/25 09:52
>>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);


570 :560:04/06/25 10:29
おはようございます。

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

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

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



571 :デフォルトの名無しさん:04/06/25 10:45
STLの種類ってのはVC++だとVC++付属のものかSTLportかってこと。

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

572 :560:04/06/25 10:49
>>571
ありがとうございます。
なるほどぉ・・・。


573 :569:04/06/25 11:11
>>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)

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

575 :デフォルトの名無しさん:04/06/26 14:42
高速化の手法に速くなる以上の意味が必要か?

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

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

576 :デフォルトの名無しさん:04/06/26 14:44
>>574
その考えで合ってるんじゃないの?
条件分岐のペナルティは大きかったから、それを減らしたかった。
また、アンロールすることでイタレーションに跨る最適化が行えるようにもなる。

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

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

577 :デフォルトの名無しさん:04/06/26 14:46
>>574
templateと何の関係が?

578 :デフォルトの名無しさん:04/06/26 15:36
>>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]; }


579 :デフォルトの名無しさん:04/06/26 15:57
>>575
>ループ処理のコストがどうこうよりも、条件分岐がなくなることで分岐予測が不要になる

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

580 :デフォルトの名無しさん:04/06/26 16:05
ループの終了判定自体が条件分岐だヴォケ

581 :デフォルトの名無しさん:04/06/26 16:07
>>579


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

583 :デフォルトの名無しさん:04/06/26 16:15
ほんと例え話好きだよなぁ

584 :デフォルトの名無しさん:04/06/26 16:25
「どれくらい無茶か」の説明をするのに
無茶さを10倍に増やした例を持ち出されても、
ああ、この人必死なんだな、としか思えませんね :-P

585 :デフォルトの名無しさん:04/06/26 16:52
>>580
ループの処理内容に条件分岐さえなければ、カウンタの終了判定でパイプラインが乱れることはない。
それと君はハードウェアループは知らんだろな?

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

586 :デフォルトの名無しさん:04/06/26 16:55
アンロールした結果をC++ソースとして確認できないのがあれだな。


587 :デフォルトの名無しさん:04/06/26 17:14
>>585
ループの条件分岐にペナルティがあるからこそ、ハードウェアループという
発想になるのだが…。


588 :デフォルトの名無しさん:04/06/26 17:19
>>585
なんか、一部のアーキテクチャのプロセッサを想定してないか? 一般論として、
カウンタの終了判定でパイプラインが乱れないとは言えんでしょ。

589 :デフォルトの名無しさん:04/06/26 17:24
>>585
> それと君はハードウェアループは知らんだろな?
ハードウェアループを使うとループ終了判定のペナルティはなくなるが、
ループのネスト数に制約がつくし、ループスタックを深くすると、今度は
コンテクストスイッチのオーバーヘッドが大きくなる。

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


590 :デフォルトの名無しさん:04/06/26 17:26
も一つ追加。ハードウェアループを使うと、ループ末尾付近での分岐命令の
利用にも厳しい制約がつくよね。

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

592 :デフォルトの名無しさん:04/06/26 17:38
>>588
パイプラインを自分で作ってみればわかると思うよ。簡単にできるからやってみれば?

593 :デフォルトの名無しさん:04/06/26 17:46
>>592
サクッと参考文献なりソースなり示してもらえると話が早いかと。

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

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

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

596 :デフォルトの名無しさん:04/06/26 18:01
いずれにせよ C++ template 統合スレ向きのネタではない気がしてきた。

597 :デフォルトの名無しさん:04/06/26 18:06
>>596
どういうときにtemplate でunrollするのが得かって話だろ?
ジェネリックプログラムにぴったりなんじゃないの?

598 :デフォルトの名無しさん:04/06/26 18:11
>>593
マジ?HDL書きたい?
確かに、
アプリのローカライズやったり、
営業まがいのSEやるよりやりがいはあると思うし、
人手不足で引く手あまたの業界ではあるが。

599 :デフォルトの名無しさん:04/06/26 21:22
>>588
>カウンタの終了判定でパイプラインが乱れないとは言えんでしょ。
パイプラインに乱れはないが、そんなことを考える君の脳みその乱れが心配だ。

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

601 :デフォルトの名無しさん:04/06/26 21:53
errataにも目を通す事をお勧めする。

602 :デフォルトの名無しさん:04/06/26 22:11
fedra core 2にはBoostは最初から入ってますでしょうか?
グラフクラスを使いたいんすけど

603 :デフォルトの名無しさん:04/06/26 23:49
STLport-4.6.2
make allでiostreamのコンパイルはできんだけど
make installできないYO… なんで( ;´Д`)?

604 :603:04/06/26 23:50
あ、コンパイラはVC7.1のです

605 :デフォルトの名無しさん:04/06/26 23:54
nmake -f vc7.mak
じゃないのか?

606 :603:04/06/27 00:19
自己解決しました… スレ汚しスマソ

607 :デフォルトの名無しさん:04/06/27 00:51
>>599
だからソースだそうよ

608 :603:04/06/27 02:06
スレ汚しついでに…
コマンドラインで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;
}

609 :デフォルトの名無しさん:04/06/27 02:14
1 -MD =MTd等
2 マニュアル読め

610 :デフォルトの名無しさん:04/06/27 02:55
>>607
ホレ
http://www.bulldog.co.jp/news/image/030820_yourb_02.jpg

611 :デフォルトの名無しさん:04/06/27 11:33
>>40-41
boost::pool_allocatorは開放して再確保する時に速いからその方法じゃ比較になってないと超亀レス

612 :デフォルトの名無しさん:04/06/27 16:16
#include <string>
using namespace std;
string work="hoge";
char array[10];
strcpy(array,work.c_str());

上のコードで3行目のstrcpyで
error C2668: 'strcpy' : オーバーロード関数の呼び出しを解決することができません。(新機能 ; ヘルプを参照)
と怒られてしまいます。
本等を見てもこれで通るはずなのですが・・。
解決策があったら教えてください。

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


613 :デフォルトの名無しさん:04/06/27 16:18
#include <cstdio>

614 :デフォルトの名無しさん:04/06/27 16:19
あdgつぁひゃsdfは

615 :デフォルトの名無しさん:04/06/27 16:20
× #include <string>
○ #include <string.h>

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

616 :デフォルトの名無しさん:04/06/27 16:23
>615・・・

617 :デフォルトの名無しさん:04/06/27 16:24
よく見てなかった。std::stringクラスも使ってるのか

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

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

618 :デフォルトの名無しさん:04/06/27 16:26
わかりました。
レスどもでした。


619 :デフォルトの名無しさん:04/06/28 00:10
std::setをこんな感じで定義しておいて、

set<int, less<int> > myset;

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

620 :デフォルトの名無しさん:04/06/28 00:13
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
です

621 :デフォルトの名無しさん:04/06/28 00:54
>>619
そのままじゃ無理なんで、昇順降順を切り替えられるファンクタを用意して渡す

622 :デフォルトの名無しさん:04/06/28 00:57
>>621
その前にsetの実装を調べた方がいいよ。
Compareを使っている場合があるから。

623 :デフォルトの名無しさん:04/06/28 07:33
>>619
比較関数が途中で変わったら内部が混乱して思ったとおりに動かなくなるよ

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

625 :デフォルトの名無しさん:04/06/28 15:52
ところで、boost::spirit による各言語の
実装のリンク集はどこかご存知だろうか?

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

626 :デフォルトの名無しさん:04/06/28 17:46
>>625
これ?
http://spirit.sourceforge.net/repository/applications/show_contents.php

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

627 :デフォルトの名無しさん:04/06/28 19:49
設計を考え直したほうがいいかと・・・
普通に内部ぶっ壊れるし、壊れなかったとしても実装依存じゃないかな。

628 :デフォルトの名無しさん:04/07/01 06:43
つか、templeteなんて必要なることある?

629 :デフォルトの名無しさん:04/07/01 10:16
>>628
PCなんて必要になることある?
(=使ったことがない人には実感がわかない)

630 :デフォルトの名無しさん:04/07/01 17:38
>>628
yes. 使い始めると止まらない止められない終わらない

631 :デフォルトの名無しさん:04/07/01 17:43
c++はtempleteが無ければstringさえ使えないぞ

632 :デフォルトの名無しさん:04/07/01 18:17
C++はtemplateが無ければcoutさえ使えないぞ

633 :デフォルトの名無しさん:04/07/01 18:20
それはない

634 :デフォルトの名無しさん:04/07/01 19:38
ICUってどうよ。


635 :デフォルトの名無しさん:04/07/01 20:05
集中治療室?

636 :デフォルトの名無しさん:04/07/01 21:44
>633
cout の型は ostream
ostream は basic_ostream<char, char_traits<char> > のtypedef

637 :デフォルトの名無しさん:04/07/01 21:56
basic_stringとかbasic_*streamはSTLができてから
あと付けでstringとstreamを対応させただけ

638 :デフォルトの名無しさん:04/07/01 22:01
>>637
んなことは誰でも知ってる。
昔話は他でやってくれ。

639 :デフォルトの名無しさん:04/07/01 22:06
つーことで、coutが使えないということではない。

640 :デフォルトの名無しさん:04/07/01 23:20
>>639
すぐに便利な例というと、むしろ st::auto_ptr とか std::vector とかかねぇ。


641 :628:04/07/01 23:45
そういうことを言いたいわけではない。
俺が言いたいのはtemplateを使って実用に耐えれるようなクラスを
書けるか?ということ。
俺は職業上ながいことC++やってるがまともにtemplateクラスを
かける奴見たことないぞ。std::stringですらお遊びプログラマでは
かけないとおもう。

642 :デフォルトの名無しさん:04/07/01 23:52
テンプレートは汎用データクラスで使うもんだから、自作って必要ない気がする
過去ログ読んでないからずれた事言ってたらスマソ。

643 :デフォルトの名無しさん:04/07/01 23:54
クリエイティブな仕事をしない限りは必要ない

644 :デフォルトの名無しさん:04/07/01 23:55
>>643
採算性がないってこと?

645 :デフォルトの名無しさん:04/07/02 00:03
>>628 自身は、自分でtemplateを使う/使えるのか?
使うのだとしたら、周りのレベルの低さを愚痴っているだけじゃないのか?

少なくとも、スマートポインタ周りはtemplateを使ったほうが楽なんじゃないかと思うが。
(自作するにしろ、拾ってくるにしろ)

646 :デフォルトの名無しさん:04/07/02 00:12
単に、>>641もその周りのプログラマも能無しぞろいってだけのことじゃん。

647 :デフォルトの名無しさん:04/07/02 00:13
必要ないならいらねーわな

648 :デフォルトの名無しさん:04/07/02 00:17
>>642
10年前からきた人でつか?

649 :デフォルトの名無しさん:04/07/02 00:25
>俺は職業上ながいことC++やってるが

プゲラ
まぁC++の歴史を考えると、長いもクソもないだろう。

650 :デフォルトの名無しさん:04/07/02 00:52
型を問わない処理を書こうとすると、templateが欲しくなる。

651 :デフォルトの名無しさん:04/07/02 01:12
なんでもかんでもtemplate化していくと
それはそれで美しくないことに気づくジレンマ

652 :デフォルトの名無しさん:04/07/02 01:13
あれでしょ?関数のオーバーロードが面倒なときに書くんでしょ?


653 :デフォルトの名無しさん:04/07/02 01:21
それはタイプセーフという利点を捨ててるだけだよな。
それを回避しようとtraitsなんかを導入してどんどん複雑化するし。

654 :デフォルトの名無しさん:04/07/02 01:24
志は低いけど、間違ったアプローチではない罠。

655 :デフォルトの名無しさん:04/07/02 01:28
C++にタイプセーフを期待しちゃいかんよ
仕様に読み勝ってこそのC++、ちゃんとOOPやりたきゃJava行く

656 :デフォルトの名無しさん:04/07/02 01:41
質問です。
テンプレートの特殊化を行うとき、同じ型のものを別々に特殊化したいときは
どのように実装するのがスマートなのでしょうか?
例としては、こんなかんじに扱いたいのです。
----
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;
----
とやっているのですが、いまいちその場しのぎなかんじがしてます。
そもそもの設計がまずいのでしょうか?


657 :628:04/07/02 01:49
あのさー、うどん食いたいならうどん屋行こうよ
なんで態々ラーメン屋いって、無理やりうどん
つくらせるかな〜?

658 :デフォルトの名無しさん:04/07/02 02:27
boostのarrayってちょっと便利だな。


659 :デフォルトの名無しさん:04/07/02 02:28
boostって次回の改定で標準になるの?

660 :デフォルトの名無しさん:04/07/02 02:38
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の方がいいですかね?

661 :デフォルトの名無しさん:04/07/02 02:44
なんでPIに度を入れるの?
どちらかがどちらかを継承して必要な部分をオーバーライドでいいじゃん


662 :656:04/07/02 03:26
>>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;
}


663 :デフォルトの名無しさん:04/07/02 03:38
いやテンプレート使うようなものじゃないし
ラジアンクラスを継承した度クラスでいいのでは?
PIはPIだよw

664 :656:04/07/02 05:40
>>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;

665 :デフォルトの名無しさん:04/07/02 08:40
class Angle32 : public AngleCore<int, Angle32>{};
const int AngleCore<int, Angle32>::PI = 0x8000;

666 :665:04/07/02 08:47
あれ? template<> っているんだっけ?
なくてもコンパイルできるんだけど一応。
教えてエロい人。

667 :デフォルトの名無しさん:04/07/02 08:50
floatなんて使うな。

668 :デフォルトの名無しさん:04/07/03 03:41
>>628
Modern C++ Design 嫁。
template クラスのスパゲッティに笑える。

669 :デフォルトの名無しさん:04/07/03 07:54
templateは友達

670 :デフォルトの名無しさん:04/07/03 13:16
>>663 PIとは半周期の事だとおもわれ。

671 :デフォルトの名無しさん:04/07/03 14:50
PIとはピだろ

672 :デフォルトの名無しさん:04/07/03 15:11
プチインターネッツです

673 :デフォルトの名無しさん:04/07/03 17:35
ぷちこInterface

674 :デフォルトの名無しさん:04/07/03 18:38
何か視点がちがくね?
Degree::PI +Radian::PI が計算できちゃうし。しかも意味のない数字になっちゃう。
クラステンプレートにする意味が・・・



675 :デフォルトの名無しさん:04/07/03 19:51
float degree_pi : Degree;
float radian_pi : Radian;
みたいにセマンティクスで拘束できたら楽なのにな。

C++だとこんな感じで書けるようにすればいいんでないかな。
semantic_numeric<float,Degree> degree_pi;
semantic_numeric<float,Radian> radian_pi;


676 :デフォルトの名無しさん:04/07/03 20:03
どうでもいいけど、πは3.14(ryの定数のことで、
半周の角度の事ではないと思うんだが。

677 :デフォルトの名無しさん:04/07/03 20:21
おまいら、そんなにコンパイラいじめて楽しいか?

678 :デフォルトの名無しさん:04/07/03 21:34
>>676
ha?

679 :デフォルトの名無しさん:04/07/03 23:39
コンパイラにいじめられてる訳ですが…
いや、自分が悪いんだけどさ…

680 :デフォルトの名無しさん:04/07/04 05:54
>>675
なんとなく思うんだけど、これって単位の問題だから
基底ベクトルクラスと直積・直和を考えた方がもっとスッキリしそうな気がする。
Modern C++ Design の一番最初に出ている例みたいな感じとかとか・・・

僕ぁ使わないと思うけど・・・(あんま気にならないクチなので)

681 :デフォルトの名無しさん:04/07/05 00:19
>Modern C++ Design の一番最初に出ている例
って?

682 :デフォルトの名無しさん:04/07/05 01:14
前スレの895参照。

683 :デフォルトの名無しさん:04/07/06 00:20
最近VC7買ってboost.spiritを勉強し始めたんですが
いきなりlexeme_dとかでつまづいてしまいました・・・

日本語のサイトとかBoost本とかは見てるんですが、
この際英語でもよいのでどっか詳しい解説ページとかないですかね?


684 :デフォルトの名無しさん:04/07/06 00:35
>>683
公式ドキュメントはどうした?

685 :683:04/07/06 00:42
>>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に関する情報が少ないもので・・・


686 :デフォルトの名無しさん:04/07/06 05:01
>>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を参照してみてください.

687 :デフォルトの名無しさん:04/07/06 05:05
後,蛇足になるとは思いますけれど,複数のscannerをサポートしたruleを作る
scanner_listなる機構も用意されています.
http://www.boost.org/libs/spirit/doc/rule.html#multiple_scanner_support

688 :683:04/07/06 21:33
>>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;
}

しかし公式ドキュメントちゃんと読んだとか言ってて全然読めてませんね。
もうしわけない・・・



689 :デフォルトの名無しさん:04/07/09 15:47
Modern C++ design 難しすぎ。もっと簡単なコードサンプルから順に掲載してよ。

690 :デフォルトの名無しさん:04/07/09 22:52
>>689
そんなあなたに C++ Templates。本が厚い分だけ丁寧に解説してるぞ。

691 :デフォルトの名無しさん:04/07/09 23:33
>>690
それ邦書で出ないかなぁ

692 :デフォルトの名無しさん:04/07/10 00:36
>>689
http://mulberryl001.ddo.jp/~paserry/

693 :デフォルトの名無しさん:04/07/10 02:04
>>691
C++ Templates の英語は義務教育終わってるなら絶対読める。
Modern の方は訳本しか持ってないんだけど、これ訳の程度はどんなもん?
難しくしてるのは訳のせい?それとももともと難しいの?

694 :デフォルトの名無しさん:04/07/10 02:44
あれは難しいんじゃない。
説明の仕方が糞なんだ。
邦訳しか読んだことはないが、
訳者がよっぽど変な訳し方してない限り、原文も糞だと思われ。

695 :デフォルトの名無しさん:04/07/10 18:06
>>694
ん?
各章の話題の振り方とかその引っ張り方とか見ると、
そんなに説明下手とは思わんが?

あれはやっぱり翻訳に難ありと見た。
もっともオレも原書見てないから確実なことは言えんが。


696 :デフォルトの名無しさん:04/07/10 18:12
プログラムのセンスがなくて読めないんだよ
どこがどのように糞なのか書けなさそうだしね

697 :デフォルトの名無しさん:04/07/10 18:26
>>696
こんにちは、訳者さん。
どう糞なのか説明してあげるから全ページキャプしてウpしてね。

698 :デフォルトの名無しさん:04/07/10 18:37
なんでオレが訳者になるんだよ、頭病気じゃねぇの

699 :デフォルトの名無しさん:04/07/10 18:39
人が分からないものを分かったつもりになって相手を見下すのは
厨の常套手段だからな。

700 :デフォルトの名無しさん:04/07/10 18:40
>>696
俺は訳本しか持ってないんだけど、
サンプルコードの解説文がわけわからないこと多数。特にカタカナ表記の単語
が数多くあって、それがあんまり日本語になじみなくて、言ってることがわから
なくなったりする。俺だけかな?適した訳を考えるのが面倒なのでえーいそのまま
カタカナにしてしまえって感じかな?コンピュータ関連本はだいたい似たり寄ったり
だけどこれはちょっと度が過ぎてるように思うんだけどね。
それと、これはたぶん原著がそうなんだろうけどプログラムのセンスというより
前後の断片化されたコードを忍耐強くつないでいくような読み方を要求される。
どうせならLokiの解説に徹したほうがよかったんじゃないのかね?
あといきなり面食らったのは
1.8節にはいっていきなり
だいぶんよくなってきました。
ってかいてあるんだけど、これ何?何が良くなってきたの?
C++ Templatesの方が間違いなく読みやすいと思うけどね。

701 :デフォルトの名無しさん:04/07/10 18:41
この場合、そんな妄想は必要ないですよ。
実際、分からない奴が人並み外れて馬鹿なだけですから ;-)

702 :デフォルトの名無しさん:04/07/10 18:45
読んでわかるかよりも、自分のコードの適所で応用できるかが大事だからね。
Modernのサンプルコードですんなりそれができる人は神だな。
言語仕様として初めからこういう使い方想定してたらもうちょっと違った形になるんと違うか?
と思うんだけど、どう?

703 :デフォルトの名無しさん:04/07/10 18:48
理由をみている限りサンプルコードとかそういう問題以前に問題がありそうな気が・・・

704 :デフォルトの名無しさん:04/07/10 18:48
わかる奴は偉い。素晴らしい。
でも
わかった気で実はなーんもわかってないというのは恥ずかしい罠

705 :デフォルトの名無しさん:04/07/10 18:52
>サンプルコードとかそういう問題以前に問題がありそうな気が・・・
いや、サンプルコートも実に複雑だと思うが。

706 :デフォルトの名無しさん:04/07/10 18:54
ウpマダー? チンチン


707 :デフォルトの名無しさん:04/07/10 19:00
>>702
Modern C++ Design が行った問題提起は、普通は詰まらない物として考えない
小さな部品を組み合わせてできる物の全体像を再度認識させた所にあると思う。
この点について、この本以前の言語の利用ノウハウ書では見た事がないです。
ちなみに応用ならライブラリーの解説書と言う事なると思うがどうか?
それが目的なら、ちょっと上にあるboost本こそが読むべき本だと思う。
この本は解説本ではなくノウハウ本だと感じるので。

708 :デフォルトの名無しさん:04/07/10 19:04
boost本ってあの最近日本で出た奴のこと?
あれは読んでどうこういう本じゃないでしょ。単なるboostの外仕


709 :デフォルトの名無しさん:04/07/10 19:08
これだけ引用の多いModern や C++ Templatesの話をしてるときにあんな駄本が引き合いに出されるとは思わんかった。

710 :デフォルトの名無しさん:04/07/10 19:14
おまえにその駄本が書けるのか?
boost本と Modern C++ Design とは使用目的も違うだろ
そもそも、読んでないか読めてないだろ、お前
バカなんだから諦めろ

711 :デフォルトの名無しさん:04/07/10 19:16
>>710
おおっとboost本の原作者さんのご降臨です。
宣伝ご苦労さん。

712 :デフォルトの名無しさん:04/07/10 19:17
ちがうってよ、おりゃ生まれてこの方本なんぞ書いた事ネェ

713 :デフォルトの名無しさん:04/07/10 19:19
>>711
「原作者」ねえw

714 :デフォルトの名無しさん:04/07/10 19:22
>>710
使用目的も異なるし、計算機の書籍としての重要性も比較にならないboost駄本などを>>707が持ち出したから言ったまで。


715 :デフォルトの名無しさん:04/07/10 19:23
>>713
それが何か?

716 :デフォルトの名無しさん:04/07/10 19:24
キチガイはどっか逝け

717 :デフォルトの名無しさん:04/07/10 19:24
喧嘩するなよ

有意義な議論したいなら人格攻撃とか駄本とか刺のあるような言葉使っちゃダメ

718 :デフォルトの名無しさん:04/07/10 19:25
駄本は駄本だろ。

719 :デフォルトの名無しさん:04/07/10 19:27
>>718
あんた精神病んでるよ

720 :デフォルトの名無しさん:04/07/10 19:29
良著と駄本を分類することが精神病になるのか?

721 :デフォルトの名無しさん:04/07/10 19:31
低脳信者共、乙であります。
Modern本はtemplateの活用を、
書籍の形にして広く紹介したことに意味があるんだよ。
だから、もはや役割を終えたんだよ。
そうなれば説明が糞なのが目に付くのは当たり前。
今となれば、あんな説明なら概説+UML+コード+αだけの方がまだいい。

722 :デフォルトの名無しさん:04/07/10 19:32
>>720
ならないよ、でも間違いなく頭イカレテルね
なんだろうね、この違いは
普通は分るね

723 :デフォルトの名無しさん:04/07/10 19:35
↓普通って何ですかとか言うな

724 :デフォルトの名無しさん:04/07/10 19:35
>>722
お前にはその程度の説明するのが関の山なんだろうな。
知 障 さ ん


725 :デフォルトの名無しさん:04/07/10 19:37
boost 本みたいな議論する価値もない本を引き合いに出すな。鬱陶しい。

726 :デフォルトの名無しさん:04/07/10 19:40
商売には中身よりタイミングが必要だと教えてくれた貴重な書物だろ?

727 :デフォルトの名無しさん:04/07/10 19:42

    |┃三             ________________
    |┃              /
    |┃ ≡   ∧_∧  < 議論と聞いちゃぁ黙っちゃいられねえ!
____.|ミ\___( ゚ ε 。 ) _ \
    |┃=___    \    ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    |┃ ≡   )   人 \ ガラッ



728 :デフォルトの名無しさん:04/07/10 19:44
いやいや中身は大切だよ。

一番売れるのは初心者向けだからね。それを教えてくれたよ。

729 :デフォルトの名無しさん:04/07/10 20:01
なーんの関係もないboostのちゃちゃが入ってModernの議論は終わりか・・・
ちゃちゃ入れるな->稲葉君

730 :デフォルトの名無しさん:04/07/10 20:08
Modernの原著はどうよ。--->読んだ人

731 :デフォルトの名無しさん:04/07/10 20:16
伸びてると思いきやまたboostか。皆あの本好きだねぇ。

732 :デフォルトの名無しさん:04/07/10 20:42
やっぱIDが出ないとだめだな

733 :デフォルトの名無しさん:04/07/10 20:49
>>132
>やっぱIDが出ないとだめだな
お前のような自作自演が居るからな

734 :デフォルトの名無しさん:04/07/10 20:55

            
                              _人
      ∩    ∧_∧            ノ⌒ 丿
       \ヽ_(    )         _/   ::(
         \_   ノ        /     :::::::\
 ∩_   _/    /         (     :::::::;;;;;;;)
 L_ `ー / /   /           \_―― ̄ ̄::::::::::\
     ヽ  | |__/ |           ノ ̄     ::::::::::::::::::::::)
  | ̄ ̄ ̄\     ノ えっと     (     ::::::::::::::;;;;;;;;;;;;ノ
  | | ̄「~| ̄( 、 A , )とりあえず / ̄――――― ̄ ̄::::::::\
  | |  | |  ∨ ̄∨        (        :::::::::::::::::::::::::::::::::)
  し'  し'                \__::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ



                               __
                         >>1  l ̄/.  ___
                         ↓ / /.  / ___ノ  
                        __/ /_/ / 
      なげときますね!      Y人, ' ',人⌒ヽ、, '
                      Y⌒ヽ)⌒ヽ、 人,ヽ)人'、, '
        へ, --- 、         ノ ̄     ::::::::::::::::::::::)
     / ̄ ̄ ̄  、____\       (     ::::::::::::::;;;;;;;;;;;;ノ
    / _/ ̄「~|\ __ \     / ̄――――― ̄ ̄::::::::\
   | |  | | ( 、 A , \ミソ   (        :::::::::::::::::::::::::::::::::)
   し'   し' と∨ ̄∨       \__::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ


735 :デフォルトの名無しさん:04/07/10 22:56
boost本が糞であることは地球ができたときから決まっていることなのに
なんで未だにこの本の話題が出るのか、俺はそれが不思議だ。

736 :デフォルトの名無しさん:04/07/10 23:44
>>730
日本語訳は原著の文章の雰囲気をうまくつかんで訳せてると俺は思った。
少なくともCUJの記事とか色んなMLのログを見ればAlexandrescu氏の文の
書き方がどんなかはわかると思うんで、MC++Dの原文もそんな雰囲気。

737 :デフォルトの名無しさん:04/07/11 00:03
>>735
> なんで未だにこの本の話題が出るのか
おまえが引っ張るからじゃないのか?

738 :デフォルトの名無しさん:04/07/11 00:03
自分の英語力が相当ぁゃιぃのであれですけれど,
彼の英文って結構ユニークな書き方ですよね?(そう感じているのは私だけ?)

739 :デフォルトの名無しさん:04/07/11 01:19
このスレではboost本に関してちょっとでもネガティブな批評があると
必ずスレの流れをぶち壊す方が居ますね。
なんか、ちょっと他の話題と異なる違和感を覚えるのは考えすぎでしょうか?

740 :デフォルトの名無しさん:04/07/11 01:29
boost本は
やさしいBoostに改名すればいいんじゃないのかな。
初心者向けの本だし。

741 :デフォルトの名無しさん:04/07/11 01:31
仰々しい名前をもった初心者本なんていくらでもあるのに
なんでboost本だけは叩かれてるんだろうか。
やっぱり期待が大きすぎただけじゃないか?

742 :デフォルトの名無しさん:04/07/11 01:33
もういいよboost本なんて語るべきことなんもないじゃん。とっとと終わってくれ。

743 :デフォルトの名無しさん:04/07/11 01:38
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のコンパイルが失敗してしまうんですが…
どなたか同じ現象に会って回避した方いらっしゃいますか?

744 :デフォルトの名無しさん:04/07/11 01:43
>>743
Rebuild with /Zc:wchar_t if you really need this.

745 :743:04/07/11 02:48
>>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

746 :デフォルトの名無しさん:04/07/11 04:55
テンプレートクラスのメンバー関数に対してenable_ifって使えない?
MinGWでもVC7.1でもコンパイルエラーが・・・
とりあえず
1:クラスへのテンプレート引数をenable_if,disable_ifに渡したところコンパイルエラーが。
2:テンプレートクラス内のテンプレートメンバー関数は、関数の引数に依存している型をenable_ifに渡す場合は問題なく動作(MINGW,VC7.1共に)。


747 :名無しさん@そうだ選挙に行こう:04/07/11 09:17
>>745
結果変わってんじゃないの?
それに、外部シンボルが未解決でも .lib の作成ならできるはずでは?

748 :747:04/07/11 09:17
ん?何だこの名無し。

749 :名無しさん@そうだ選挙に行こう:04/07/11 10:09
てst

750 :名無しさん@そうだ選挙に行こう:04/07/11 10:10
ひろゆこUZEEEEEEEEEEEEE!!!!!!!!!!!!!!

751 :743:04/07/11 12:46
>>747
STLportをリビルドする前と後でエラーの内容変わってないです
743と745のメッセージは前後で2種類両方とも出てました

STLportを使わずに bjam -sTOOLS=vc7.1 でビルドすると
これらのエラーが全く出ないのでおかしいと思って…

うーーん、まいった… ワカラン orz

752 :名無しさん@そうだ選挙に行こう:04/07/11 16:35
C++の最後の砦であったtemplateも
C#がgenericsサポートした以上崩壊してしまったな。
あとはC#の下請けとしてがんばってくれや。

753 :名無しさん@そうだ選挙に行こう:04/07/11 16:56
Javaもサポートしたけど、
CLIのgenericサポートは話題としては面白そうだね。

けど基本的にC#だけって事になるんだと思うけども…

754 :743:04/07/11 19:03
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をビルトイン型として扱う)

以上。
ふぅ… 疲れますた。

755 :名無しさん@そうだ選挙に行こう:04/07/11 20:18
>>752
C# 2.0の処理系ってもうあるの?

756 :デフォルトの名無しさん:04/07/11 20:21
C#のジェネリックってやっぱり再帰のオンパレードで実装するしかないの?
言語設計当初から念頭にあるならC++よりずっと使いやすくて洗練されてるのかな?

757 :デフォルトの名無しさん:04/07/11 20:26
>>757
Monoがかなりの部分サポートしてるよ。

758 :デフォルトの名無しさん:04/07/11 20:47
>>75
やっぱり再帰のオンパレードか・・・

759 :デフォルトの名無しさん:04/07/11 20:56
C#にせよJavaにせよGenerativeってサポートしてるといえるレベルなのか?

760 :デフォルトの名無しさん:04/07/11 22:27
C# 2.0 の仕様を日本語解説してるとこあったら教えて?M$かなやっぱし。

761 :デフォルトの名無しさん:04/07/13 12:37
英語だけどコード見りゃ分かるだろ
http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/SpecificationVer2.doc

762 :デフォルトの名無しさん:04/07/13 14:17
C++ Templates なんだけど、これって単語の数は少なくて慣れてしまえば読みやすいんだけど、
単語の使われ方が変わっているし、なんか微妙に文法も変な気がする。
主語が吹っ飛ぶことが多いというか。・・・これ書いたのネイティブの人だよね?
俺の英語力がだめなだけなのか・・・

763 :デフォルトの名無しさん:04/07/13 15:08
>>761
わざわざ教えてくれてありがと。
こんな詳しい解説書がすでにできてたのか・・・
ざっと見ただけなんだけど。
書式としてはC++のようにtemplateと明示しなくていいみたいね。
template template パラメータはどう指定するんだろ?

764 :デフォルトの名無しさん:04/07/13 16:17
>>762
俺はModernの日本語訳読んでるよりC++ templatesの英語のほうが
よっぽどわかりやすいとオモタ。
実際、後者の方がよっぽど早く読めた英語が決して得意じゃない俺。
あと、見渡せるコードの長さがちょうど良くて後戻りする頻度も
少ないとオモチャ。
印象としてはModernの方はテクの披露、C++ temp.の方はわかりやすく
解説することを心がけてるようにヲモタ

765 :デフォルトの名無しさん:04/07/13 16:35
プログラミングの書籍なんて文章とコードのセットで理解するもんで、
訳がどうこう言ってるような椰子はプログラミング言語に対する基本的な
技能が足りてないと思われ。Modernの日本語訳でおれは普通に理解出来たけど。

766 :デフォルトの名無しさん:04/07/13 16:45
"Modern"の場合は特にプログラム読解の比重が大きいからねえ。

767 :デフォルトの名無しさん:04/07/13 16:50
多分翻訳がどうこうとか言ってる奴は、受験時代に大して変わらないような
参考書を山ほど買いこんでた口だろうな。C++に関しても書籍かって、出版
産業に貢献してやれやw

768 :762:04/07/13 17:07
>>764
俺も同じ感じだ。
ただ、読みやすいけど、文章が頭悪い感じがするのは気のせいなのかなあと。
Modernのほうの翻訳はよくできてるっぽい。
comp.lang.c++.moderatedのAlexの文章を見ているとそのまんまだ。
>>765
そうなんだけど、翻訳どうのでなくて、内容に関してだけ言えば
もう少しわかりやすく書けるのではないかと。理解できない人もいると思う。



769 :デフォルトの名無しさん:04/07/13 18:28
>>765
>Modernの日本語訳でおれは普通に理解出来たけど。

ハイハイ。ここでは何とでもいえる。もっともなんで本を読むかといえば
技能が足りないからこそ読むんだ。技能が十分あるなら本なんかわざわざ買わず
Lokiをダウンロードしてそれをそのまま読め。

>受験時代に大して変わらないような参考書を山ほど買いこんでた口だろうな。
それをしなかったお前は大学にもいけず専門学校->人材派遣でゴミのように
ただこき使われる日々過ごしてるわけだ。ゲラゲラ

770 :デフォルトの名無しさん:04/07/13 19:30
>>769
お前は精神科逝ったほうがいいぞ。俺と同じ臭いがする。

771 :デフォルトの名無しさん:04/07/13 19:32
つまりくせえんだよ、激臭。ヘタレはさっさと首吊って死ね。

死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

772 :デフォルトの名無しさん:04/07/13 20:03
>>765
どうやら図星だったようだな。エンジニアなら院ぐらいは修了しとこうな。
といっても、君の人生もう手遅れだと思う。

773 :デフォルトの名無しさん:04/07/13 20:25
喧嘩するなって言ってるだろう。

なんでtemplateスレはこんな奴らばかりなんだろう?
他人を見下さないと生きていけないのかい?

774 :デフォルトの名無しさん:04/07/13 20:41
燃料注入
boost本は実にいい本だった。歴史に残る名著だ

775 :デフォルトの名無しさん:04/07/13 21:33
>>773
そろそろ新しい C++ Template 本に飢えてるんじゃないの?

776 :燃料注入:04/07/13 21:46
>>775
Let's Boostのニュースにこんなのが出てた。
http://boost-consulting.com/mplbook/

777 :デフォルトの名無しさん:04/07/13 21:51
やっべー。気になる。

778 :デフォルトの名無しさん:04/07/13 22:09
こ・・・これは(;´Д`)ハァハァ過ぎるだろう・・・
著者がDave AbrahamsとAleksey Gurtovoyなんて,
まさにTMPについて書くならこの人!って感じの2人じゃねーかYO!!

779 :デフォルトの名無しさん:04/07/13 22:23
もう疲れた。手段に過ぎない言語の解説本でこれ以上時間を浪費できない。
目的あるいは準目的に近い人はとっとと読んでわかりやすく解説してくれ。
もうC++自体午後6時って感じなのに・・・

780 :デフォルトの名無しさん:04/07/13 22:25
しかしかっぱえびせんのようにやめられない…

781 :デフォルトの名無しさん:04/07/13 23:45
こんなの読もうって人は、ある意味知的好奇心と頭の体操的な意味で(趣味的に)
読むんであって、仕事に必須ってことじゃないでしょ?

782 :デフォルトの名無しさん:04/07/14 00:54
俺らが普段何気なくつかってるものにはtemplateなんかよりも
もっと複雑な仕組みが組みこまれてるんだよ。

783 :デフォルトの名無しさん:04/07/14 01:56
>>781
> 仕事に必須ってことじゃないでしょ?

こういう視点だと職場ごとに違うしねえ。
ある種の人々は、例えば組み込み屋、iostreamさえ必要ないし。


784 :デフォルトの名無しさん:04/07/14 02:24
>>783
前の仕事でIPルータやってましたけどもとのアーキテクトがTemplate
おたくでがんがん使ってました。 STLは使わないで全部彼自家製
でしたが。 クラッシュしたシステムの死体解剖は時々つらかった
ですね。 何層にも重なったテンプレートの奥深くで死なれると
gdbがどうしても理解できない場合がいくつかありました。

785 :デフォルトの名無しさん:04/07/14 03:43
template設計を効率よくこなすための、Effective C++みたいなというか、
べからず集みたいなのが欲しい。modern にしろC++ templatesにしろ
"こんなこともできます集"であったんで、やるとデバッグが大変になるとか、
再利用が困難になるとか・・・etc ノウハウはもうかなり集積してるんじゃないの?
それを紹介して欲しいな。

templateを有効利用するためのデザパタとか

786 :デフォルトの名無しさん:04/07/14 12:42
>>785
785自身はどんなこと気をつけて使ってます?

漏れが気をつけてるのは、型毎の特殊化が必要ない部分が多くなるように設計して、
特殊化が不要なメソッド・変数がある程度あるなら、それを集めた基底クラスを作って
使うようにしてるくらいかなー。コード生成量が減るし、必要なら子クラスのメソッドを
仮想関数にしとけば普通のポリモ系のデザインのコードとも親和性高いし。

787 :デフォルトの名無しさん:04/07/14 19:52
プリミティブタイプのための特殊化で、TypeListを良く使うので、
>>781の意見にはちょっと賛成しかねるところがあります。
けど確かにもっとシンプルなのだけ集めた本があると便利だし、
template書きも迫害(wされなくなるかも…

788 :デフォルトの名無しさん:04/07/14 21:11
>>787
C++ Templatesはシンプルなもの満載でしょ。
でも、nontype テンプレート引数の制限事項があるのでどうも気力が失せる。

789 :デフォルトの名無しさん:04/07/15 11:16
VCにSTLport入れた後、ウィザードで新規プロジェクト作った時は
stdafx.hに毎回

#ifdef NDEBUG
#undef _STLP_DEBUG
#else
#define _STLP_DEBUG 1
#endif

とかを書かないといかんのが面倒…
みんなどうしてんの? VCのテンプレート書き換えてる?

790 :デフォルトの名無しさん:04/07/15 11:22
コピペするだけやん

791 :デフォルトの名無しさん:04/07/15 11:58
>>789
stl_user_config.hにかいてる
>>790
それはめちゃくちゃめんどくさいとおもいます

792 :デフォルトの名無しさん:04/07/15 14:49
VC7.1ならSTLPortなんていらないやん。

793 :デフォルトの名無しさん:04/07/15 17:48
なじぇに

794 :デフォルトの名無しさん:04/07/15 22:15
ギャップバッファのテンプレートありますか

795 :デフォルトの名無しさん:04/07/15 22:56
>>794
http://www.jah.ne.jp/~naoyuki/Programs/Programs.html

796 :789:04/07/16 00:50
>>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の先頭にあるだけで読み込まれてるんだが…

797 :デフォルトの名無しさん:04/07/19 14:00
STLPortの4.6.2 (April 10, 2004)なんですが
srcディレクトリにあるvc6.makとvc6-unicode.makに違いが見られないんですが
vc6-unicode.makは何のためにあるんでしょうか?

798 :デフォルトの名無しさん:04/07/19 15:34
>>793
付属のSTLでboost100%だから

799 :デフォルトの名無しさん:04/07/19 16:19
付属のSTLとまったく同じだと思ってるんだ。ふーん。

800 :デフォルトの名無しさん:04/07/19 16:21
STLPort使うとBoost100%にならないし

801 :デフォルトの名無しさん:04/07/20 02:46
>>799
小学生並の読解力を晒しちゃったねw

802 :デフォルトの名無しさん:04/07/20 09:04
MFCのCGdiObject派生クラス
例えば、CFontクラスなどを以下の様にvectorクラスで使用すると
コンパイルが通りません… どういう事なんでしょうか?

vector<CFont> font;
font.clear();

803 :デフォルトの名無しさん:04/07/20 09:16
コンパイラとかエラーメッセージも書けねーのか池沼

804 :802:04/07/20 09:57
>>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 *)' の参照を確認してください

805 :デフォルトの名無しさん:04/07/20 10:58
>>804
CFont a, b;
a = b;
ができないから。

806 :デフォルトの名無しさん:04/07/20 11:29
>>805
解決方法は、自分でCFontなりの派生作って
演算子定義するしかないですか?

807 :デフォルトの名無しさん:04/07/20 12:06
CFont*を入れる

808 :デフォルトの名無しさん:04/07/20 12:11
>>807
ああ、なるほど。
ちょっと後始末が面倒そうですが…


809 :デフォルトの名無しさん:04/07/20 12:30
>>808
std::vector<boost::shared_ptr<CFont> >

810 :デフォルトの名無しさん:04/07/20 13:04
CFont*だろ

811 :デフォルトの名無しさん:04/07/20 13:17
>>810
ハァ?

812 :デフォルトの名無しさん:04/07/20 13:41
auto_arrayってなんで標準にないの?

813 :デフォルトの名無しさん:04/07/20 15:08
無い物は無いから

814 :デフォルトの名無しさん:04/07/20 17:21
auto_ptr自体いらんし

815 :デフォルトの名無しさん:04/07/20 17:33
std::vector使えばいいやん

816 :デフォルトの名無しさん:04/07/20 23:31
ttp://www.research.att.com/~bs/bs_faq2.html#auto_ptr

817 :デフォルトの名無しさん:04/07/21 02:02
ということは所有権の移動がある配列には
auto_ptr<vector<T> >を使えということですか?

818 :デフォルトの名無しさん:04/07/21 08:40
>>817
それでいいんじゃないの?
vector::swap() を使っても、似たようなことができるかもしれない。
boostを使えば選択肢はもっと広がるだろう。

配列自体の所有権を移動させる方法なんてどうせ実装の詳細だから、好きに選べばいい。

819 :デフォルトの名無しさん:04/07/21 16:53
テンプレートの特殊化?っていうんでしたっけ。

template<class T>
class A
{
public:
void foo() {}
};

template<>
class A<char>
{
public:
void foo() { /* charの処理 */ }
};

こんな感じでいくつか特殊化しているのですが
特殊化した型以外の場合
上の例だとA<int>などとしたらコンパイルエラーになるようにするには
どうしたらいいでしょうか?


820 :デフォルトの名無しさん:04/07/21 17:00
template<> class A<int> { A(); } ;

821 :デフォルトの名無しさん:04/07/21 17:00
宣言だけして実装しない。

template <typename T>
struct A {
  void foo();
};

template <>
struct A<char> {
  void foo() { /* 処理 */ }
};

822 :デフォルトの名無しさん:04/07/21 17:08
↓で十分では?

template <typename T>
class A;

template <>
class A<char> {
  void foo() { /* ... */ }
};


823 :819:04/07/21 17:09
>>821
ああなるほど。
コピー禁止クラスを作るときの、コピーコンストラクタとoperator=を宣言だけして実装しないのと
同じような感じなんですね。
ありがとうございました。

824 :819:04/07/21 17:14
>>822
うお、こんなこともできるんですね。
これだと
A<int> a;
としただけでもエラーになってくれていいですね。
こっちを採用したいと思います。

825 :デフォルトの名無しさん:04/07/21 21:51
ちょいと気になることがあるんですけど
template<class ??>
template<typename ??>
この2つは等価ですが、classとtypenameどちらを使ってますか?
自分としてはclassで統一してますけど
場合によって使い分けたりする人もいるんでしょうか?

826 :デフォルトの名無しさん:04/07/21 22:54
そこにくるのがclassだけならclassでいいかもしれんが
classに限らないならtypenameのほうがいいと思う

827 :デフォルトの名無しさん:04/07/21 23:28
補足
class以外==組込み型(int等)

828 :デフォルトの名無しさん:04/07/21 23:30
>>825
一時期使い分けてたが、大して意味内んでもうしてない。

829 :デフォルトの名無しさん:04/07/22 00:00
>>826
趣味趣味。template template パラメタの場合には typename 使えないって
微妙な仕様もあるので、俺は class で通してる。

830 :デフォルトの名無しさん:04/07/22 00:33
しかしながらauto_ptrはそのまま使うのではなく例外安全のためにあくまで初期化のみにつかう。

831 :デフォルトの名無しさん:04/07/22 01:09
>>830
その「しかしながら」は、どのレスからつなげればいいんだ?

832 :デフォルトの名無しさん:04/07/22 02:24
>>831
たぶんここの誤爆だと思割れ目
http://pc5.2ch.net/test/read.cgi/tech/1090180012/

833 :デフォルトの名無しさん:04/07/22 02:31
>>832 時間を見るに、おそらくそれは違う。

834 :デフォルトの名無しさん:04/07/22 09:10
>>833
名探偵認定

835 :830:04/07/22 16:35
すまん。最近ずっとアク禁に巻き込まれてて書き込めると思わんだって
適当に書いたら投稿できて。
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は意味がある。

836 :830:04/07/22 16:42
追加
もちろん確保したらdeleteしなきゃだめね。ただしdeleteは例外を出さないことを
前提できるし、そうでなくてはいけない。

837 :デフォルトの名無しさん:04/07/22 18:08
>>835
std::auto_ptrは場合にもよるがdeleteしなくてもいいのじゃないか?

838 :デフォルトの名無しさん:04/07/22 19:58
>>837
830では無いが、もうちょっとよく読め

839 :デフォルトの名無しさん:04/07/22 20:18
めんどくさいな

840 :デフォルトの名無しさん:04/07/23 00:00
>>839
そして人は shared_ptr に流れ着くわけだ。

841 :デフォルトの名無しさん:04/07/23 00:34
>>835
下の例で、
auto_ptr<HOGE> a(new HOGE());
auto_ptr<HOGE> b(new HOGE());
↑こうしない意図は何?

842 :デフォルトの名無しさん:04/07/23 00:40
>835
>HOGE* a = tmp_a.release();
>HOGE* b = tmp_b.release();

なんでわざわざ生ポインタ取り出すの?そのまま使えばいいと思うけど。

あと、auto_ptrは引数、戻り値に使うと便利だと思う。
auto_ptrを知らないひとが使うと火傷するけど……

843 :デフォルトの名無しさん:04/07/23 00:47
Hoge* f()
{
    auto_ptr<Hoge> tmp(new Hoge);
    //...//
    return tmp.release();
}
みたいなのはよくやるな。

844 :830:04/07/23 00:49
>>840
オブジェクトのコンテナとして使うのであれば確かにauto_ptrよりshared_ptrをお勧めする。
しかしそもそもauto_ptrの本質はrelease()にある。コンテナではない。

845 :830:04/07/23 01:18
>>842
確かにそうだし、出来ることならそうすればいいと思う。
しかし843のように生ポがほしいときや、多少なりともオーバーヘッドが気になるとき
は取り出してかまわない。
なぜなら先の例はとあるクラスのコンストラクタでの処理だとする(ポインタa,bがメンバとする)。
そのうえでデストラクタに"delete a;delete b;"とすれば例外安全は保障される
これはコンストラクタが完了していれば必ずデストラクタも呼ばれるため。
>auto_ptrは引数、戻り値に
そうだね。おれも使えるときは使っている。ただインターフェース的には一般的でないというか・・・


846 :デフォルトの名無しさん:04/07/23 01:21
>844
>auto_ptrの本質はrelease()にある。

そこがわからん。auto_ptrは、その名の通りリソースの自動管理がキモなんじゃないの?
その他にも管理権限の委譲の明確化とかあるけどさ。

847 :842:04/07/23 01:28
>845
>しかし843のように生ポがほしいときや、多少なりともオーバーヘッドが気になるとき
>は取り出してかまわない。

いや、確かに生ポインタが欲しければ取り出してもかまわないけど……
オーバーヘッドってそんなにペナルティ大きかったっけ?
間接参照1〜2コ分ぐらいじゃないの?


848 :デフォルトの名無しさん:04/07/23 01:40
>>845
auto_ptrにオーバーヘッドがあるなんて考えるのはどうかしてる。
例外安全を考慮するなら、メンバにauto_ptr持ったほうがもっと確実。

正直、830は「本当の有効な使い方」を語れるほど知らないように思う。

849 :デフォルトの名無しさん:04/07/23 01:53
auto_ptrのオーバーヘッドなんて最近のコンパイラなら最適化で消滅しそうだし

850 :デフォルトの名無しさん:04/07/23 10:17
オナニー脳内最適化

851 :830:04/07/23 12:07
オーバーヘッドを理由に出したのがまずかったかな?実際に俺もほとんどauto_ptrをそのまま使ってるし・・・。
ただ取り出してもかまわない条件を示したかっただけ。

852 :デフォルトの名無しさん:04/07/23 12:22

auto_ptr< HOGE > const p( new HOGE );

これでもう、scoped_ptr はいらんね…といいたいが…



853 :デフォルトの名無しさん:04/07/23 23:37
>>851
で、「取り出してもかまわない条件」はひとつも示せてないよな?
それでも「auto_ptrの本質はrelease()にある」と思うの?

854 :デフォルトの名無しさん:04/07/23 23:56
>「auto_ptrの本質はrelease()にある」


>>830じゃないのが、お前が勝手に異次元的解釈をしてるだけと違うか?

855 :デフォルトの名無しさん:04/07/24 00:49
>>854
だれに向かって「お前」っていってるのかわからない。

856 :デフォルトの名無しさん:04/07/24 01:01
>>855
>>853

857 :853:04/07/24 01:08
漏れかよ。

>>854
auto_ptrの本質はデストラクタにあり、release()はただのサービスだと思ってるんで、
>>844(=830)の言う「auto_ptrの本質はrelease()にある」なんてちっとも賛同できないわけよ。

読んだままの意味にしかとらえてないから、「異次元的解釈」なんてしてないつもりだよ。

858 :デフォルトの名無しさん:04/07/24 01:41
あー、ちょっと俺は異次元的になにかを勘違いしてた。
>>854は無視してください。ごめんなしゃい。

859 :デフォルトの名無しさん:04/07/24 02:08
夏だな。

860 :デフォルトの名無しさん:04/07/24 11:26
C++なんだからrelease()も必要不可欠な要素の一つだろ
ところで本質って何?

861 :デフォルトの名無しさん:04/07/24 11:33
>>860
数牌は一色で、後は字牌。


862 :デフォルトの名無しさん:04/07/24 13:15
>830, 860

もういいよ。取りあえず
C++標準ライブラリ チュートリアル&リファレンス
(The C++ Standard Library: A Tutorial and Reference)
読んどけ。な

863 :デフォルトの名無しさん:04/07/24 13:24
>>859
お前、夏休みの間の出来事はみんな夏のせいにしてるだろ?

864 :デフォルトの名無しさん:04/07/24 19:25
>>863
夏厨指定厨というのが存在するのだよ
2chも、もう長いからな

865 :830 これで最後にしとく:04/07/24 19:56
悪かった。ただ俺はauto_ptrをコンテナ的な使い方しか見れないやつに強調するつもりで言ったんだが。
俺が言い過ぎた。こんなムキになって噛み付かれるとは思わんかったし。
>>853
一応示したんだが。release()なんて一生使えなくていいもんな。

866 :デフォルトの名無しさん:04/07/24 20:06
>>865
やっぱりわからん。
コンテナ的な使い方って、ふつうにauto_ptrを保持することだよな?
そういう使い方しか見れないって、ほかにどう見るというんだろう。

867 :デフォルトの名無しさん:04/07/24 23:16
>>835なんかtryでいいじゃん

868 :デフォルトの名無しさん:04/07/24 23:25
>>867 tryマンドクセ

869 :デフォルトの名無しさん:04/07/25 01:34
(ry

870 :デフォルトの名無しさん:04/07/25 22:02
boost::shared_ptr遅いしメモリ喰いすぎ。

871 :デフォルトの名無しさん:04/07/25 22:10
>>870 詳しく

872 :デフォルトの名無しさん:04/07/26 08:54
ふつうに計数型スマートポインタを書いたらああいう風にはならないよな。
weak_ptrなんてもんに対応させるため構造が複雑になってる。

873 :デフォルトの名無しさん:04/07/26 09:20
smart_ptr が利用している shared_count クラスを見れば分かるが、
smart_ptr< void > みたいに書かれた場合や、smart_ptr< HOGE > のときの
HOGE に 仮想デストラクタがない場合でも、正しくデストラクタが呼ばれるように、
boost::any みたいな仕組みを用意している。

874 :873:04/07/26 09:21
smart_ptr → shared_ptr

875 :デフォルトの名無しさん:04/07/26 23:42
>>872
必要ないならお前は簡略化されたの使えばええやん

876 :デフォルトの名無しさん:04/07/27 23:46
俺は intrusive_ptr が好きだ。

877 :デフォルトの名無しさん:04/07/28 00:58
COM扱うときは大活躍なだ

878 :デフォルトの名無しさん:04/07/28 07:57
ptrの部分はどう発音すればいいのかね

879 :デフォルトの名無しさん:04/07/28 08:00
ポインタ

880 :デフォルトの名無しさん:04/07/28 08:50
ポタラ

881 :デフォルトの名無しさん:04/07/28 09:37
ポニーテール

882 :デフォルトの名無しさん:04/07/28 10:00
ぴーてぃーあーる

883 :デフォルトの名無しさん:04/07/28 10:28
プター

884 :デフォルトの名無しさん:04/07/28 10:28
ピートル

885 :デフォルトの名無しさん:04/07/28 10:44
>>875
どこにあるか?

886 :デフォルトの名無しさん:04/07/28 11:17
>>885 intrusive_ptr

887 :デフォルトの名無しさん:04/07/28 11:28
ピョートル大帝

888 :デフォルトの名無しさん:04/07/28 12:57
質問です.
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みたいなものがあれば嬉しいのですが.


889 :888:04/07/28 12:59
蛇足でしょうが,念のため
上記でFirst_TypeはshortにSecond_Typeはfloatにtypedefされて欲しいです.


890 :888:04/07/28 13:50
自己レスです.昔書いてたコード漁ってたら出て来た.(笑)
#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


891 :888:04/07/28 13:56
何度もすみません.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;
失礼致しました.


892 :デフォルトの名無しさん:04/07/30 21:09
>>33
> >>32
> Modern C++ Designを読みましょう。
> 第4章「小規模オブジェクトの割り当て」当たりがお勧め。

あのメモリアロケータってデフォルトのnewより遅いゴミアロケータ。
Modern C++は昔すごいと思っていたけど、今思うとあまりにもマニアック過ぎると思う。
さしあたり、STLやboostの便利なライブラリを使っていれば十分と思った。

Effective STLはそういう意味で良い本だと思う。 boostについてもEffectiveみたいな
ノリで書いた本があれば重宝すると思う。

893 :デフォルトの名無しさん:04/07/30 21:49
>>892
> > 第4章「小規模オブジェクトの割り当て」当たりがお勧め。
>
> あのメモリアロケータってデフォルトのnewより遅いゴミアロケータ。

普通、遅くても良いからメモリ効率の良いを目指すんじゃないのか?
小さいオブジェクトのアロケータは。

894 :デフォルトの名無しさん:04/07/30 22:12
>>893
ほんよんでねーだろ

895 :デフォルトの名無しさん:04/07/30 22:13
>>893
Modernでは速いのを目指してなかったっけ?


896 :デフォルトの名無しさん:04/07/30 23:49
>>893
本読んでないだろ、っつーのはともかくとして
> 普通、遅くても良いからメモリ効率の良いを目指すんじゃないのか?
STLport の node allocator なんかは、逆だね。メモリ効率を犠牲にして
速度を稼いでる。

STL コンテナには基本的にデカいオブジェクトを格納しない (たいてい shared_ptr
とか小さいオブジェクトを入れる) から、それで良いんだけど。

897 :デフォルトの名無しさん:04/07/31 12:16
>>895
空間効率、速度効率、どちらにも良いのを目指してたと思う。

898 :デフォルトの名無しさん:04/07/31 13:15
この辺のロジックって、ある程度解答が出てるものかとばっかり思ってたんだが、
そういうわけでもないのかね??

899 :デフォルトの名無しさん:04/07/31 13:22
>>898
Reconsidering Custom Memory Allocation
http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

900 :デフォルトの名無しさん:04/08/01 08:10
>>892
ModernはSTLやboostみたいなものを作る側の人が読めばいいよねえ。
boost::lambda級の大物を作るときは確かに役に立ちそう。

901 :デフォルトの名無しさん:04/08/01 11:06
>>892
遠回しに日本で書かれたboost本があまりにもショボすぎると言っているわけですね

902 :デフォルトの名無しさん:04/08/01 11:33
>>901
なんでそんなに粘着なん?

903 :デフォルトの名無しさん:04/08/01 11:37
今後話題性だけで適当に本書いて儲ける輩を増やさないために

904 :デフォルトの名無しさん:04/08/01 11:38
>>903
本なんてそんなもんだよ。
萌え単だってそうだろ。

905 :デフォルトの名無しさん:04/08/01 11:38
腐ったものに蛆がわくのは自然の摂理なんだよ

906 :デフォルトの名無しさん:04/08/01 11:40
だったらてめえで本書けよって感じだな

907 :デフォルトの名無しさん:04/08/01 11:44
蛆虫乙

908 :デフォルトの名無しさん:04/08/01 11:44
夏全開

909 :デフォルトの名無しさん:04/08/01 13:59
>>903
別に人が何で儲けても良いじゃん。こっちの取り分が減るわけじゃなし。

910 :デフォルトの名無しさん:04/08/01 14:23
他人が儲けるのが気に食わないって子供かよ。
実生活で自分より儲けてない奴としか付き合わないとか?

911 :デフォルトの名無しさん:04/08/01 14:46
Modern C++ Design が難しすぎて読むのに半年かかりそうなんですがどうすればいいですか?

912 :デフォルトの名無しさん:04/08/01 15:31
>>911
適当な時期が到来するまで、積んでおけ。まだ読むべきタイミングでは
なかったということだ。

913 :デフォルトの名無しさん:04/08/01 15:35
むしろ自分より儲けてる香具師と付き合って奢って貰う

914 :デフォルトの名無しさん:04/08/01 15:36
>>911
Modern C++ Design を半年 ROM しろ

915 :デフォルトの名無しさん:04/08/01 19:52
>>886
却下。intrusive_ptrは簡略化されたshared_ptrではない。
すでに参照回数を保持しているオブジェクトに対し使うものだ。
もう一度聞く。どこにあるか?



916 :デフォルトの名無しさん:04/08/01 19:55
自分で参照回数保時すりゃいいやん

917 :デフォルトの名無しさん:04/08/01 19:57
>>915
> もう一度聞く。どこにあるか?

必死だな。


918 :デフォルトの名無しさん:04/08/01 19:59
>もう一度聞く。どこにあるか?

なんか中国人っぽいある

919 :デフォルトの名無しさん:04/08/01 20:02
> もう一度聞く。どこにあるか?

ぬるぽ

920 :デフォルトの名無しさん:04/08/01 20:08
結局私は自分でshared_ptrの代わりを作ったことがある。
余計な仕様を除いたら生成速度が2倍近くになった。
標準に近いものがあるなら教えてほしい。
>>916
それをしたくないからintrusive_ptrでなくshared_ptrをつかう。論外。
>>916
煽ったつもりか?夏だから暇なのかもしれないが。

921 :920:04/08/01 20:13
生成というかコピーだ。すまない。

922 :デフォルトの名無しさん:04/08/01 20:15
たった二倍か・・・
ならshared_ptrを使った方がいいんじゃない?

まぁプロファイル等とって、スマートポインタ生成の部分が
どうしてもボトルネックになってるってなら自作もしょうがないかもしれんけど

923 :デフォルトの名無しさん:04/08/01 20:18
shared_ptrは消費メモリは生ポインタの最低6〜9倍以上
アクセス速度は生ポインタの10倍以上
生成速度は生ポインタの数十倍〜100倍以上

924 :デフォルトの名無しさん:04/08/01 20:22
>923
ついでに環境も教えてくれ

925 :デフォルトの名無しさん:04/08/01 20:50
>アクセス速度は生ポインタの10倍以上

デバッグ版でプロファイルしてるだろ

926 :920:04/08/01 20:58
私の記憶が正しいかわからなかったので実験してみた。
http://www.boost.org/libs/smart_ptr/test/smart_ptr_test.cpp
を改変したもの。私の環境はCPUがAthronXP-M1800+ 224MB コンパイラはgcc version 3.3.3 (mingw special)
SL:シングルリスト型スマートポインタ, DL:ダブルリスト型〜, IC:非直接計数型〜, DC:直接計数型〜, SH:boost::shared_ptr, Raw:生
・・・これはアクセス速度とコピーを見る。あんま変わらないかも。
sets, objects, operates:( SL, DL, IC, DC, SH, Raw )
1, 10000000, 20000000:( 2.863, 2.433, 6.578, 5.828, 6.520, 1.442 )
2, 5000000, 20000000:( 2.574, 1.994, 4.016, 3.034, 3.885, 0.681 )
4, 2500000, 20000000:( 2.244, 1.392, 2.733, 2.133, 2.514, 0.340 )
6, 1670000, 20040000:( 2.282, 1.323, 2.151, 1.713, 1.984, 0.281 )
8, 1250000, 20000000:( 2.384, 1.082, 1.783, 1.592, 1.763, 0.281 )
10, 1000000, 20000000:( 2.634, 1.091, 1.592, 1.332, 1.572, 0.170 )
15, 670000, 20100000:( 2.924, 1.082, 1.562, 1.161, 1.391, 0.150 )
30, 335000, 20100000:( 4.136, 0.981, 1.292, 1.012, 1.262, 0.140 )
50, 200000, 20000000:( 6.079, 0.901, 1.302, 0.982, 1.170, 0.111 )
100, 100000, 20000000:( 10.284, 0.922, 1.191, 0.962, 1.292, 0.110 )

927 :デフォルトの名無しさん:04/08/01 21:04
http://66.102.7.104/search?q=cache:VFFCHnVYs0sJ:hp.vector.co.jp/authors/VA022575/coding/e/smtptr2.html+quick_allocator&hl=ja&lr=lang_ja&inlang=ja
ぃょぅ

928 :デフォルトの名無しさん:04/08/01 21:05
http://hp.vector.co.jp/authors/VA022575/c/e/smtptr2.html
こっちだろ

929 :デフォルトの名無しさん:04/08/01 21:08
1.292, 0.110
やっぱ生ポインタの10倍は遅いか。

930 :デフォルトの名無しさん:04/08/01 21:18
だからといってshard_ptrが糞ということにはならないけどね

931 :デフォルトの名無しさん:04/08/01 21:20
lokiに付いてる変なのよりはマシだな

932 :デフォルトの名無しさん:04/08/01 23:39
stringでNULLを扱う場合、皆さんどうしてますか?
教えてあもーれ

933 :デフォルトの名無しさん:04/08/01 23:40
vector<char>使ったら?

934 :デフォルトの名無しさん:04/08/01 23:42
>933
文字列配列を使いたい場合はどうしてますか?

935 :デフォルトの名無しさん:04/08/01 23:48
vector<vector<char> >を使ったら?

936 :デフォルトの名無しさん:04/08/01 23:51
「stringでNULLを扱う」で会話が成立してるのか?

937 :デフォルトの名無しさん:04/08/01 23:56
ひょっとして string::c_str() が知りたいのだろうか?

938 :デフォルトの名無しさん:04/08/01 23:59
std::stringのデータが未定義な状態を表現したいんだろ

939 :デフォルトの名無しさん:04/08/02 00:02
>>932
空文字列とは別に無効値を定義したい? それなら boost::optional の
出番じゃないかね。あるいは

string getString() { return error ? 無効な値 : 有効な値; }

みたいな関数を作ろうとして困ってるなら、そもそも文字列を戻り値にしない。
必ず bool を戻り値にして、設定する文字列は関数引数に参照渡しするか、
エラー発生時点で例外投げちゃう。

940 :デフォルトの名無しさん:04/08/02 00:04
--__NULL__--とかそのソフトで仕様的に有り得なさそうな文字列を入れておくのもいいよ

941 :デフォルトの名無しさん:04/08/02 00:05
"test\0test\0tetest"
みたいなNULL文字が混じった文字列が使いたいって事じゃないの?

942 :デフォルトの名無しさん:04/08/02 00:05
>>932
std::string(NULL) 見た目で最も「stringでNULLを扱う」にマッチする。これ最狂。

943 :デフォルトの名無しさん:04/08/02 00:05
>>940
その手もアリだが、個人的にはお勧めしない。エラーチェックのコードが
そこら中に散らばって煩雑になりがちだから。

944 :デフォルトの名無しさん:04/08/02 00:07
頭の悪いやつは書き込むな

945 :デフォルトの名無しさん:04/08/02 00:08
結局stringでNULLを扱うの意味は決定してるのか?

946 :デフォルトの名無しさん:04/08/02 00:09
>>940
典型的なセキュリティホールの生成過程


947 :932:04/08/02 00:12
こんなレスあって感動した、、よくやった。(TωT)ウルウル

std::vector<std::string> &array
array.push_back(strtok(NULL, " "));
とした時NULLが入ってきてエラーになってしまうんです、、

単純に
char ch = NULL;
array.push_back(ch);
ということはできないんですよね?




948 :デフォルトの名無しさん:04/08/02 00:13
>>942
ひぎぃっ!

>>945
んなもん、誰も判らんわ。

949 :デフォルトの名無しさん:04/08/02 00:14
>>947
> std::vector<std::string> &array
> array.push_back(strtok(NULL, " "));
> とした時NULLが入ってきてエラーになってしまうんです、、

strtokなんて標準C規格の癌みたいな関数使うなYO!

> char ch = NULL;
変数がポインタじゃありませんが?


950 :デフォルトの名無しさん:04/08/02 00:15
>>947
> char ch = NULL;
おい待て。そもそも NULL は「何も指してないポインタ」のことで、文字列の
終端は '\0' だぞ。

C++ だと様々な都合から、大抵の処理系で #define NULL 0 されてるから
うっかり char ch = NULL; もコンパイル通るが、意味的にはコンパイルエラーに
されても文句言えん。

951 :デフォルトの名無しさん:04/08/02 00:16
>>947
そんなもん、NULLかどうかpush_backの前にチェックしろよ。

952 :デフォルトの名無しさん:04/08/02 00:17
932はCからお勉強しなおしなさいってことでFA?


953 :デフォルトの名無しさん:04/08/02 00:17
そのまえに日本語勉強しろって事でFA

954 :デフォルトの名無しさん:04/08/02 00:20
C++ では普通は strtok って使わないの?

955 :932:04/08/02 00:20
典型的なVBプログラマにはきついって事でFAです。はい。(。´Д⊂)


956 :デフォルトの名無しさん:04/08/02 00:21
>>954
Cでも使わないよ。バグってるんだもん。
A,B,,Dみたいなレコードがうまく拾えなかったり。

957 :デフォルトの名無しさん:04/08/02 00:24
つーかtemplate何の関係もないじゃん…

958 :デフォルトの名無しさん:04/08/02 00:26
>>954
そうだな、CだろうがC++だろうが使わない。

まず関数のシグネチャが腐っていて(関数内にstatic変数で状態を抱える)
マルチスレッド環境で使えないのは誰の目にも自明。

それと、「パース処理」をあーいう関数でおこなうこと自体がbad idea。

パーサは、1文字づつ読んで状態遷移するように書くのが定石。それを分
かった上でstrtok_r()で手抜きするのは、使い捨てコードなら止めないが
932は使っちゃダメ、絶対。



959 :デフォルトの名無しさん:04/08/02 00:28
>>957
ムリヤリつなげてみよう。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466

こんなこと言い出したらキリが無いだろうに。

960 :デフォルトの名無しさん:04/08/02 00:30
>>959
へぇ〜
勉強になりますた。


961 :デフォルトの名無しさん:04/08/02 00:38
strtok は使わず基本的に自作ってことですか?
スレ違いながら勉強になりました

962 :932:04/08/02 00:40
CStringArray.add見たいにNULLが入っても気軽にできないかなと思っただけ
なんですけどね、、


963 :デフォルトの名無しさん:04/08/02 00:42
そういうのがあるのならCStringArrayとやらを使ったらどうですか?

964 :932:04/08/02 00:49
>963
MFCは使いたくないと思ってしまいまして、、STLを勉強しようかと思いまして。

965 :デフォルトの名無しさん:04/08/02 00:52
>>963
むかつくのは解かるが、そういう返答は的外れだと思う。
>>964
書き込む前に、質問の内容を自分以外が理解できるか、推敲とか反芻とかしましょう。

966 :932:04/08/02 00:55
>964,965
そうしまつ。みなさんアリガトウ(。´Д⊂)



967 :デフォルトの名無しさん:04/08/02 00:57
最後の最後までわけわからんw

968 :デフォルトの名無しさん:04/08/02 01:30
>>947くらいなら、
istringstream + skipwsで十分。

969 :932:04/08/02 01:41
> >964,965
> そうしまつ。みなさんアリガトウ(。´Д⊂)
>>963,965の間違えでした。
STLと日本語勉強して出直します。。

>>968 何ですかそれ?


970 :デフォルトの名無しさん:04/08/02 01:45
>>969
調べてから聞け
脊髄反射するな
スレを汚すな

971 :デフォルトの名無しさん:04/08/02 01:48
> STLと日本語勉強して出直します。。
>
> >>968 何ですかそれ?

インターネットの常識も勉強したほうが良いですね。
この書き込みを見ると、何だか某M女史の「どうやったら退会できますか」を思い出します。

972 :デフォルトの名無しさん:04/08/02 01:50
そろそろ次スレが必要だな

973 :932:04/08/02 01:54
>>970,971
全くでつ。失礼しました。

974 :デフォルトの名無しさん:04/08/02 08:32
次スレ
http://pc6.2ch.net/test/read.cgi/pc/1055413887/

975 :デフォルトの名無しさん:04/08/02 08:35
>>974
次スレ<typename iTa>は放置の方向で。


976 :デフォルトの名無しさん:04/08/02 14:12
ifstreamで一行ずつ読み出すには>>演算子の後にstringをやっていました
string str; ifstream fi(file);
if >> str;

これをistream_iterator<string>でも同様に動くことを期待して
vector<string> v;
copy(istream_iterator<string>(fi), istream_iterator<string>(), back_inserter(v));

としてみたのですが、強制終了されてしまいます。
上のようにvectorに一行ずつコピーするにはどのようにすれば
思い通りの結果となるのでしょうか?

どうかよろしくお願いいたします

977 :デフォルトの名無しさん:04/08/02 14:21
>>976
環境は?

fi がすでにファイル末端だったりはしないの?

978 :デフォルトの名無しさん:04/08/02 14:36
細かいことだが、back_inserter 使うときは insert が使えるかどうか良く見た方がいい

979 :デフォルトの名無しさん:04/08/02 15:13
>>978
使えるかどうかってどういう意味?

980 :デフォルトの名無しさん:04/08/02 15:17
v.insert(v.end(),istream_iterator<string>(fi),istream_iterator<string>());

981 :976:04/08/02 15:26
>>977
環境はVisualStudio.NET 2002をそのまま使っています
ifstreamを作ってからすぐにやっているので先頭だと思うのですが
これで出来るということは自分のプログラムにおかしな部分が
ありそうなのでもう一度確認したいと思います

>>978
今のところはvectorに保存しようと思っております

982 :976:04/08/02 15:27
>>980
ありがとうございます
それで試しています

983 :デフォルトの名無しさん:04/08/02 20:15
17

984 :デフォルトの名無しさん:04/08/02 20:16
16

985 :デフォルトの名無しさん:04/08/02 20:18
F

986 :デフォルトの名無しさん:04/08/02 20:18
E

987 :デフォルトの名無しさん:04/08/02 20:19
D

988 :デフォルトの名無しさん:04/08/02 20:20
C

989 :デフォルトの名無しさん:04/08/02 20:21
B

990 :デフォルトの名無しさん:04/08/02 20:26
A

991 :デフォルトの名無しさん:04/08/02 20:26
@

992 :デフォルトの名無しさん:04/08/03 11:39
8

993 :デフォルトの名無しさん:04/08/03 12:02
7

994 :デフォルトの名無しさん:04/08/03 12:15
6

995 :デフォルトの名無しさん:04/08/03 12:34
5

996 :デフォルトの名無しさん:04/08/03 12:44
よん?


997 :デフォルトの名無しさん:04/08/03 12:52
three

998 :デフォルトの名無しさん:04/08/03 13:03
two

999 :デフォルトの名無しさん:04/08/03 13:36
壱ですよ。

1000 :デフォルトの名無しさん:04/08/03 13:37
orz

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

233 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)