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

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

Generic Programming with C++ Template

1 :デフォルトの名無しさん:01/12/17 21:45
C++ による Generic Programming の話をしよう。

参考図書:
Modern C++ Design
Andrei Alexandrescu, Addison-Wesley, ISBN:0-201-70431-5
(訳書: ピアソン・エデュケーション, ISBN:4-89471-435-3)
http://cseng.aw.com/book/0,,0201704315,00.html

Generic Programming - STL による汎用プログラミング
Matthew H. Austern, ASCII, ISBN:4-7561-3441-6

関連スレッド:
C++相談室 Part3
http://pc.2ch.net/test/read.cgi/tech/1003832761/

STL スレッド
http://pc.2ch.net/test/read.cgi/tech/1004287394/

2 :デフォルトの名無しさん:01/12/17 21:58
じぇねりっく

3 :デフォルトの名無しさん:01/12/17 23:22
とりあえずネタふり。

1で挙げた Modern… は、3章まで読んだ。いままでのところ、ムズいと
感じたのは 1章かな。ポリシーというのになじみがなかったもので。
正直、ポリシーと特性 (traits) の違いがよくわかっていない。

3章はテクニックの話なので、むしろ分かりやすかった。LISP という
よりは prolog とかの単一化のイメージに近いね。こんなことが
template でできるということには驚いたが。でも、タイプリスト
なるものの使い方については、まだ、まったくわからん。

4 :デフォルトの名無しさん:01/12/18 00:25
何ができるのか具体的に書いてくれよ。

5 :デフォルトの名無しさん:01/12/18 00:30
一個のタイプミスで百行ぐらいエラーを出せる。

6 :デフォルトの名無しさん:01/12/18 00:52
>>3
> でも、タイプリストなるものの使い方については、まだ、まったくわからん。
型によってコンパイル時に関数を選択させる場合に使える。STL で似たようなことをやってるのは、
iterator によってアルゴリズムを選択してるヤツかな。たとえば advance() は

  randome access iterator なら iter += n
  forward iterator なら ++iter を n 回

で処理するようになってる。(あれの魔法の種は iterator_traits なんで、ちょっと違うけど)

7 :デフォルトの名無しさん:01/12/18 00:59
具体例: 1の本の「推薦の言葉」から。

// コンパイル時にチェックできる assert
template<bool> struct CTAssert;
template<> struct CTAssert<true> {};

で、たとえば CTAssert<sizeof(int) == 0> とかやるとコンパイルエラーを
出してくれる。ぜんぜん generic ってな感じはしないけどね。

8 :デフォルトの名無しさん:01/12/18 01:04
STLスレでやれよ。

9 :デフォルトの名無しさん:01/12/19 02:52
>>8
意味わかってる?
Generic Programingとは違う。
この本に載っている技法は「Generative Programming」生成的プログラミング
といわれるだぜ?

俺は「Generative Programming」萌えだ。
C++のtemplate特性を逆手に、とった巧妙な技法だ

ちなみにC++に依存してるわけじゃない。
たぶんPerlでもASPでもできる。

10 :デフォルトの名無しさん:01/12/19 03:02
漏れも Modern ... 読んでる YO!
楽しい NE!

デモチョトボクニハムズカシイヨ…

11 :高校生:01/12/19 03:03
いったいどういうものなんですかね?>Generative Programming
いわゆるGoFのPrototypeパターンとは別物?
それともLISPのマクロみたいに実行時にクラスを
生成するのか?(C++では絶対無理だと思うが。。。)

#例外が実装される前は良く使ったけどなぁ>C++

12 :デフォルトの名無しさん:01/12/19 03:27
>>11
>それともLISPのマクロみたいに実行時にクラスを
>生成するのか?(C++では絶対無理だと思うが。。。)

もちろんLISPのようなクラスを生成というのは無理だ。
ある意味、LISPの様にC++でも生成できる様にしている。
templateを使いクラスを生成するためパーツを作ってるんだ。

13 :高校生:01/12/19 03:42
なんか面白そうだなぁ。。。GoFの23パターンとは
違う新手のアーキテクチャーなんだろうか?
訳書で4800円か。。。まずは立ち読みから(;;

14 :12:01/12/19 03:43
上のものは誤解を招きそうなので補足する。
(まあ俺は消防だから話半分ぐらいで聞いてくれ)

Generative Programmingとオブジェクト指向は直行している
Generative ProgrammingとSTLを使うとHaskell的プログラミングができそうだ。

「Modern C++ Design」のHP
ttp://cseng.aw.com/book/0,,0201704315,00.html
にLokiといライブラリが公開されている。
見てみてはどうかな?
(サンプルコードが無いから本を読まないと使えんか)

15 :デフォルトの名無しさん:01/12/19 04:17
>>11
Generative じゃなくて Generic の方だが、俺は次のように理解している。

手続き型のプログラミングでは「手続き」を定義することで、
オブジェクト指向プログラミングでは「インターフェース」を定義することで、
ソフトウェアの抽象化を進めた。

それでも抽象化できてないものの一つに「ループ」なんてのがある。たとえば整数の配列や
文字列をコピーするコードは、効率を考えなければどれも

for (i = 最初; i < 最後; ++i)
  dst[i] = src[i];
みたいなものだが、これは手続き型でも OO でも、汎用的には書けないわけだ。コピーする
「手続き」、たとえば memcpy とかあるだろと反論するかもしれないが、あれは

 特定の型やデータ構造に縛られる

という点で、汎用的ではない。たとえば C++ のオブジェクトなんかは、単純にメモリをコピー
して済ますわけには行かない。参照カウンタつきのクラスなんかは、そんなことしたら確実
に壊れるし。

そこで「一連の要件」を定義することで、汎用的で再利用可能なアルゴリズムを定義できる
ようにしたのが Generic プログラミング(C++ の規格書読んでると Assinable Type とか出
てくるけど、あれが要件)。ただ「一連の要件」というのが曲者で、手続きや型と比べると把
握しづらいんだよな。

C++ でうまくテンプレートを使ったコードを読むと「このループ何」みたいなことが少ない。
ループや比較に名前がついていて、コードを読んで意図が汲みやすいようになってる。
いまどき変数を使わずアドレス直書きなプログラムなんざ

 「たとえ正しく動いていようが、こんなプログラムメンテナンスできん」

と思うように、将来は名前の無いループや比較演算を直接埋めたプログラムは

 「読めるか、こんな抽象度の低いコード」

とか言われるのかも知れず。

16 :デフォルトの名無しさん:01/12/19 04:17
直行ってなんですかー?

17 :デフォルトの名無しさん:01/12/19 04:21
情報提供:三省堂
■[直行]の大辞林第二版からの検索結果 

ちょっこう ちよくかう 【直行】

(名)スル

(1)途中どこにも寄らず、目的地へまっすぐ行くこと。「出張先から会社に―する」
(2)人の思惑などを考えず思うとおりに行うこと。「直言―」「―の士」
(3)正しいおこない。

18 :デフォルトの名無しさん:01/12/19 04:30
>>16
まじれす
各概念が独立していること
単独でも使えるし、組み合わせることも可

(元ねた、XYグラフはX軸とY軸は直行している)

19 :高校生:01/12/19 04:43
>>15
一種のTemplate methodと考えるのはまずいですかね?
>>18
一次結合のヴェクトルが一次独立なら「直交」が正しいと思う。

20 :デフォルトの名無しさん:01/12/19 05:07
>>18
ちゃいます。
正直、ム・マ板では「直交」はNGワードですな(藁

>>19
正解(漢字が)

21 :デフォルトの名無しさん:01/12/19 07:47
>>19
> 一種のTemplate methodと考えるのはまずいですかね?
それはあくまで「手法」の一つであって、背景にある「概念」とは異なると思う。オブジェクト指向って
関数ポインタですよね、というのと同じぐらいには外してると思うぞ。

(Generic プログラミングをサポートするのは C++ に限らないわけだし)

22 :デフォルトの名無しさん:01/12/29 20:01
age

23 :デフォルトの名無しさん:02/01/12 09:41
Builderつかってるんだけど、
テンプレート使ってると時々コンパイラがFatalErrorを吐く。
自分が間違っているのか、コンパイラの問題なのか分からなくて悩む。
ま、VC6よりはましだけど。

#とりあえずage

24 :デフォルトの名無しさん:02/01/12 09:54
>>23
Templateだけ展開するコマンド無かったっけ?

25 :デフォルトの名無しさん:02/01/13 15:50
>>23
どんなコードでFatalErrorになるの?

ちなみにBCC5.5はANSI C++には対応していません。
うそ書くなBorland

26 :デフォルトの名無しさん:02/01/13 15:58
>>25
23 じゃないけど、たとえばこんなコード。

vector<vector<int> > vv;
for_each(vv.begin(), vv.end(), boost::bind(&vector<int>::resize, _1, 1));

致命的エラー F1004 vv.cpp 14: コンパイラ内部のエラー(関数 main() )

27 :23:02/01/13 17:45
たしかね、
template <template class<> class C, typename T>
C<T> function() {return C<T>();}
みたいなの。
コードの方が間違ってる気もするんだけど…。
BCC5.5はISO C++と違う部分もいくつかあるけど
(temlate <typename T> friend function<T>();がだめなのは参ったけど)
まあ比較的頑張ってるんじゃないかな。
Windows用コンパイラでもっといいのある?

28 :デフォルトの名無しさん:02/01/13 18:05
>>27
Modern C++ Design の著者は、サンプルコードを

 Comeau C++ 4.2.38
 CodeWarrier Pro 6.0

で動作確認した、と書いてある。あとは gcc 3.x 系列じゃないかな。

(妥協して VC7 ってのも現実的な選択肢だと思うけど)

29 :デフォルトの名無しさん:02/01/13 18:52
>28
Loki の readme.txt に
> Also, Loki has been ported to gcc 2.95.3 by Nick Thurn.
ってあるよ.

30 :デフォルトの名無しさん:02/01/13 19:01
generic programmingというのは、
objectを中心とするような王道OOとは違って、
generic functionを基本とするprogrammingのことね。

C++だと、template、operator/method/function overloadを使う。

31 :デフォルトの名無しさん:02/01/14 00:49
Modern C++ Designは、CUJのExpert ForumとかGotWとか好んで見てる人に
とっては必読の1冊ですよね。意外に早く翻訳されたのでよかった。
スマートポインタとかFactoryの話が出たので、ProxyとかFlyweightの例も
欲しかった気がしますが。

メインの開発環境がVisual C++ 6なんですが、Loki全部は通らないみたい。
Windows環境でコンパイル通そうと思ったら、CodeWarriorのWin版か
Cygwin+α的なのに頼ることになりそうですかね?

Lokiのうち、templateのパラメータにtemplate使ってるやつとか、
部分的な特殊化の入ってる部分以外は通ると思ったんで、そいつらを使わない
書きかたで置きかえられるかな、とおもってチャレンジしてみたんですけど
全て敗北しました。「あぁ、こりゃしかたないか」みたいに感じたんですけど、
単に、実力が足りんような気もするし。

部分的に汎用性を捨てて、固定のポリシーで書きなおしてやれば、
それはそれで、それなりに使えるような気もします。

Lokiを使いたいところだけ、通せるコンパイラでライブラリ化してやって
そいつをVC6で使うのはどうだろうかと思ったんですが、それはそれで
ライブラリの名前マングリングの話があって面倒なのでは、とか。
(試してみた人いません?)

いや、、単なる感想で特に言いたいこともないんですが。。。

32 :デフォルトの名無しさん:02/01/14 10:16
templateだとexportできないとライブラリ化できないと思う...。

33 :31:02/01/14 14:06
う、、コンパイル不可なものは所詮をexportするわけにはいかん、と
そういう指摘でしょうか。lokiをコンパイル可能なコンパイラに
templateインスタンスをexportする機能がついているのか、という
お話でしょうか。。

VC++なDLLの場合、templateインスタンスなクラスはexportできるみたいで。
ライブラリ側でポリシーの選択までやっちゃって必要なインスタンスクラスだけ
exportする、という使い方はどうかと。export側とimport側でコンパイラとか
標準ライブラリのバージョンが違って出来上がるバイナリが変わってしまったら
コケるかもしれませんが。

lokiそのものをライブラリ化しよう、というわけではないので、PImplな部分を
lokiで作ってやって、dll exportなインターフェイスをつけてやれば、よいか
と思ったんですが、実行時のパフォーマンスは落ちそうですね。

ライブラリ化してる時点でありがたみ半減には違いないです。

34 :デフォルトの名無しさん:02/01/14 17:06
32 の言っているのは、template の前に付ける export キーワードのこと
でしょう。私は、これをサポートしているコンパイラ (というかリンカか?)
って見たことないです。
でも、33 の言うようにテンプレートを個々にインスタンス化したものは、
DLL の意味で export 可能だろうとは思います。

35 :デフォルトの名無しさん:02/01/14 18:18
あぁ、exportですか。
なんかで見た記憶があります。プログラミング言語C++第3版だったと思うけど。。
正直いって、どういうしくみになってるのか想像できなかったんですよ、あれは。
テンプレートパラメータが残ってるから。

翻訳単位が違うってことは、テンプレートパラメータが何になってもいいよ、
っていうオブジェクトがあって、それが外部から参照できます、ってこと
ですよね。それってどういう風に実装できるんでしょう、リンカ的に。
なんかいろいろ制約がつきそうですが。
(厨房に解説してやろうというかたお待ちしております)

コンパイル済みオブジェクトにgenericな動作がさせられるっていうのは
なにやら凄そうですが。

36 :デフォルトの名無しさん:02/01/14 20:26
勝手な想像ですが、すなおに考えると、export を見た時点ではコンパイラは
たんに export があったということを覚えているだけ。リンク時に未定義な
テンプレートインスタンスが発見されるので、そこで初めてインスタンス生成を
開始。つまりリンカの協力のもとに遅延コンパイルをするという感じかなぁ。

37 :デフォルトの名無しさん:02/01/16 04:52
http://research.microsoft.com/projects/clrgen/
に面白い話が載ってるよ。CLRに言語共通なgenericsを導入しようと言う話。
Lazy dictionary creation, JIT, Specialization and Sharingなど、
これまでのlinkerをかなり逸脱する話が含まれてる。(つーか実行時…)

38 :デフォルトの名無しさん:02/01/17 00:21
>>37
そのページのタイトル、「COM+ 2.0 Generics」...

39 :デフォルトの名無しさん:02/01/23 18:43
>>27
typoがあるYO。

template <template <class> class C, typename T>
C<T> function()
{
  return C<T>();
}

40 :デフォルトの名無しさん:02/01/24 10:44
>>39
失礼。書き間違えちゃった。
でも、39のでもダメなんだよね...。これって規格上だめなのかな。

41 :デフォルトの名無しさん:02/01/25 03:11
>>40
functio < C < T > >();
じゃだめ?

>>27
>(temlate <typename T> friend function<T>();がだめなのは参ったけど)
これは言語の設計上できないようにしているだけ。
friend classは限定的につかおうってこと

42 :デフォルトの名無しさん:02/01/25 07:48
>>41
27 が書きたかったのは、
template<typename T> class Hoge {
frind T function<T>();
};
ということだと思うけど。これは規格上 OK です。つか、function の後の
<T> の有無で意味が変わる。g++ は標準規格に合ってるけど、VC++ なんかは
合っていませんね。


43 :デフォルトの名無しさん:02/01/26 01:01
>>27,>>39
うーん、メタテンプレートみたいのを使いたいということ?
これのテンプレート引数の C って、それ自身がテンプレートになってるような
書き方だけど。
でも、そもそもどうやったらテンプレートそのものを引数として渡せるのやら。



44 :27:02/01/26 11:26
>>42
それは、あのあと確かめたらBCC5.5.1はgccと同じ(規格と同じ)でした。ごめん。
関連することでは、今ISOの規格書読みながらいろいろ試してるんだけど、
template <typename T>
class SampleClass
{
//...
};
の定義の中で、
template <typename T, typename U>
void TestFunction(const TestClass<T> &, const TestClass<U> &);
をfriendにするにはどうしたらいいんでしょう。
BCC5.5.1だとどうやってもエラーになってしまう。
(「宣言が間違ってる」みたいなエラーだから、単なるコーディングミスかも知れない)

あの時書きたかったのは、
template <typename T>
class Hoge {
template <typename U>
friend class Hoge<U>;
};
みたいなのなんです。
(今回も手元にソース持ってきてないので適当に書いてますが...。)
サポートされてない、ってエラーが出ちゃうんだよね。
Effective C++の付録のsmart pointer実装例では使っているので、
規格決定直前に変更になってなければ規格上OKだと思うんだけど。

>>43
template引数にtemplateを使うのは問題ないはずなんだけど...

45 :27:02/01/26 11:30
ごめん。
class SampleClass
じゃなくて、
class TestClass
です。

コンパイラ通してから書かなきゃだめだね、こりゃ。


46 :43:02/01/26 15:56
うたがってすまんかった。たしかにテンプレート引数としてテンプレートを
取ることはできるね。でも、その有効な使い道というのがよくイメージできないなあ。


47 :デフォルトの名無しさん:02/01/26 20:04
>>46
そのクラスがつかうコンテナを選ぶとか?

cls<vector>
cls<list>

48 :デフォルトの名無しさん:02/01/26 21:08
>>44
規格によれば、
template <typename T, typename U>
friend void TestFunction(const TestClass<T> &, const TestClass<U> &);
でよいみたいだけど。でも、クラステンプレートの引数と T がかぶっているのは
まずいかもしれませんね。

friend クラスのほうは、
template <typename T>
class Hoge {
template <typename U>
friend class Foo;
};
でよいみたい。(foo の後の <U> がいらない)) >>44 だと、どちらも Hoge に
なってるけど、それは単なる typo?



49 :デフォルトの名無しさん:02/01/27 01:01
>>44
VCではコンパイル通ったよーん。

50 :デフォルトの名無しさん:02/02/04 11:32
今読んでる。
普通のC++プログラミングを実数軸の話とすれば、
テンプレートを使った繰り返しや再帰は虚数軸の話だと思った。
抽象度が高すぎるたとえですまぬ。

51 : :02/02/04 14:15
>50
をぃをぃ,それだけじゃ何を読んでるのか分からん人も出て来るだろ.
まぁ Modern C++ Design なんだろうなぁとは思うが.

52 :デフォルトの名無しさん:02/02/04 17:55
ごめん、この本専用のスレだと思ってた。
Googleで"Modern C++ design"検索してたまたまこのスレにたどり着いたので。
Functor萌え。

53 :デフォルトの名無しさん:02/02/13 06:07
//from "C++ Template as Partial Evaluation"

template<int N>
class Pow
{
public:
 static const int result = Pow<N-1>::result * N;
};

class Pow<1>
{
public:
 static const int result = 1;
};

//...
 const int a = Pow<5>::result;
//...

54 :デフォルトの名無しさん:02/02/13 06:15
Factorial じゃないのか??

55 :デフォルトの名無しさん:02/02/13 06:32
Functorはやはり関手と訳すのでしょうか?

56 :デフォルトの名無しさん:02/02/13 06:53
>>53
>template<int N> class Pow {
>public:
> static const int result = Pow<N-1>::result * N;
こういう場合はstruct Powにしましょう。
非公開メンバー&メソッド無いんですから。

でもGenerativeプログラムの基本やね
汎化と特化のいい関係。

57 :53:02/02/13 11:11
>>54
そう。スマソ。階乗とべき乗のどっち書くかぼんやり迷ってたから混ざった……。

58 :53:02/02/13 11:13
>>55
classを類とは訳してないからいいんじゃない?(w

59 :デフォルトの名無しさん:02/02/13 12:31
Generic Programmingってさあ、
C/C++のマクロのパワーアップ版って言ったらダメかなぁ。
オブジェクト指向マクロとか。

60 :デフォルトの名無しさん:02/02/13 13:39
>>59
結果的にそうなってるだけ。

61 :53:02/02/13 15:56
>>59
ダメ。機能限定版でもあるから(w。

・マクロはトークンならなんでも置き換えてくれる(予約語さえ)けど、
 templateは型か特定の型の定数しか置き換えてくれない。

・マクロはパラメタのないトークンを置き換えられるが、
 関数テンプレートは関数しか置き換えられないし、
 クラステンプレートを使うには型宣言のときにパラメタ指定が必要。

・マクロ展開の際に引数は文字列として結合ができる
 templateは与えられた引数を文字列として加工する能力はない。

・マクロはプログラムのごく一部にだけ選択的に作用させることもできるが、
 テンプレートはグローバルに影響を及ぼす。

・・・・・・だからマクロとテンプレートには似た性質
(コンパイル時までに処理される)もあるけど、
別のものと思ったほうがいい。

62 :デフォルトの名無しさん:02/02/14 02:50
//from "Expression Template Technique"
//(1) Exp<T> and BinOp<T1,T2>

template<typename T>
struct Exp
{
typedef ContType T;
virtual ContType eval(int i) = 0;
};

template<typename T1, typename T2>
struct BinOp : public Exp<T1::ContType>
{
 T1 a1;
 T2 a2;

 BinOp(T1 arg1, T2 arg2)
  :a1(arg1), a2(arg2), op(operation)
  {;}

virtual ContType operation (ContType, ContType) = 0;

 ContType eval(int i)
  {return (operation(a1.eval(i), a2.eval(i)));}
};

63 :デフォルトの名無しさん:02/02/14 02:50
//from "Expression Template Technique"
//(2) operators : AddOp<T1,T2> and operator "+" overloading

template<typename T1, typename T2>
struct AddOp : public BinOp<T1,T2>
{
 ContType operation (ContType a1, ContType a2)
  {return (a1 + a2);}
}

template<typename T1, typename T2>
AddOp<T1,T2> operator+ (T1 a1, T2 a2)
{return (AddOp(a1, a2));}

64 :デフォルトの名無しさん:02/02/14 02:51
//from "Expression Template Technique"
//(3) Vector<T>

template<typename T>
struct Vect : public Exp<T>
{
 typedef ContType T;
//...
 T* cont;
 int n;

 Vector(int size)
  : n(size), cont(new T[size])
  {;}

 ContType eval(int i)
  {return (cont[i])}

 operator= (Exp<ContType> exp)
  {
  for(int i=0; i<n; i++)
   {cont[i]=exp.eval(i);}
  }
};

65 :デフォルトの名無しさん:02/02/14 02:51
//from "Expression Template Technique"
//(4) sample expression

//...
Vector<double> v1;
Vector<double> v2;
Vector<double> v3;
Vector<double> v_res;
//...
v_res = v1 + v2 + v3;

66 :デフォルトの名無しさん:02/02/14 02:56
//>>63 訂正
//from "Expression Template Technique"
//(2) operators : AddOp<T1,T2> and operator "+" overloading

template<typename T1, typename T2>
struct AddOp : public BinOp<T1,T2>
{
 AddOp(T1 a1, T2 a2)
  : BinOp(a1, a2)
 {;}

 ContType operation (ContType a1, ContType a2)
  {return (a1 + a2);}
};

template<typename T1, typename T2>
AddOp<T1,T2> operator+ (T1 a1, T2 a2)
{return (AddOp(a1, a2));}

67 :53:02/02/14 04:13
//>>54 こんどこそPowだと思う(弱気sage)

template<int N, int X>
class Pow
{
public:
 static const int reult =
  (N%2==1)?X:1)*(Pow<(N>>1)>::result)*(Pow<(N>>1)>::result);
};

template<int X>
class Pow<0, X>
{
public:
 static const int result = 1;
};

//...
 const int pow5_5 = Pow<5,5>::result;
//...

68 :デフォルトの名無しさん:02/02/14 06:50
>>67
static使うのはまずくない?リンカは削除できるのか?
あとコンパイル時に計算するのにN%2をやるのはなんかけなげ。
コンパイル時間を短縮するための効率的な構造とかてできそうで
怖い。SchemeをコンパイルタイムにやるC++は異常。

69 :デフォルトの名無しさん:02/02/14 07:43
>>67
いやいやちょっとまて。static const intが
コンパイル時評価であることは保証されているのか?
てか?文は実行時だろう。とするとこれは
数字を保持したstatic intオブジェクトを
実行時の静的オブジェクト初期化時に順に掛けていくという
クレイジーなプログラムになるんじゃないか?

70 :デフォルトの名無しさん:02/02/14 15:59
>>67
static const int じゃなくて enum にすれ。

71 :71?:02/02/14 16:43
>>67
template<int I,int P>struct Pow{
  enum{R = I * Pow<I,P-1>::R};
};

template<int I>struct Pow<I,0>{
  enum{R = 1};
};

72 :53:02/02/14 19:43
>>68
テンプレートから展開されるクラス定義の数を減らす効果があるっす。>N%2とPow<(N>>1)>
クラス内のstaticはクラス1つに1個の意味だからそんなに仮に領域が割り当てられていたとしても、
クラス定義を処理する以上には悩ましくはないかと。>static

>>69
プログラミング言語C++第3版 A.5によれば
constant expressionにconditional expression(?: && ||)は含まれるらしいすよ。
ということは評価時に定数になるならば立派に定数式っす。
で、定数式ならコンパイル時に計算され、constに領域は割り当てられない筈。

73 :53:02/02/14 20:08
具体的には
N=5
ならば
5%2=1 5>>1=2
2%2=0 2>>1=1
1%2=1 1>>1=0
が順に計算できるから
クラス定義の参照関係
Pow<5,X>→Pow<2,X>→Pow<1,X>→Pow<0,X>
という順序に従ってクラス定義が
Pow<5,X>←Pow<2,X>←Pow<1,X>←Pow<0,X>
と展開されていくので
Pow<0,X>::result=1、
Pow<1,X>::result=X*(Pow<0>::result)*(Pow<0>::result)=X、
Pow<2,X>::result=1*(Pow<1>::result)*(Pow<1>::result)=X*X、
Pow<5,X>::result=X*(Pow<2>::result)*(Pow<2>::result)=X*X*X*X*X
の順で初期値が確定する。

74 :53:02/02/14 20:27
//>>67を一般の引数用に改良、多分展開されるはず。

template<typename T, int N>
class Pow
{
public:
 T operator() (T x)
  {
  T pw = Pow<(N>>1)>(x);
  return (((N%2==1)?x:1)*pw*pw);
  }
};

template<typename T>
class Pow<T,0>
{
public:
 T operator() (T)
  {return (1);}
};

//...
 double pow5_5 = Pow<double,5>(5);
//...

75 :デフォルトの名無しさん:02/02/14 20:37
>>74
> 多分展開されるはず。
試してみ。

76 :53:02/02/14 20:49
>>75
お家にはC++コンパイラ置いてないの(しくり)。今、容量に余裕がなくって。

77 :53:02/02/14 20:53
とはいえ、
類似のコードは昔論文を読んだときに
g++で試したので、書き損じが無ければ>>74も動作はする筈。
inline展開と定数伝播の程度・能力に関してはコンパイラによるけど。

78 :デフォルトの名無しさん:02/02/15 08:11
>>72-74
staticは意味が大きすぎてリンカは削除できないと思う。
5乗の計算に20バイト使う可能性がある!
constもinlineも保証はないので結局残るのはenumだけなんじゃないか?と。
運が悪いと普通のpowになっちゃいますよ的な。
そうして74のintの部分特別化にenumを使えるかなとかなんとか考えると疲れた寝る。

79 :デフォルトの名無しさん:02/02/15 14:59
>>78
「意味が大きい」って?
あと20バイトくらいを問題にするなら展開されたコードの方が全然大きいかもよ?(w

大体enumの初期値として処理できる定数式なら
constの初期値として処理できない筈がない。
思うに、展開されたクラスのstatic constについて誰かがアドレス取らない限り
リンカまでも行かないで領域はないと思われる。

ちなみに、
Pow<N,X>::resultは定数式として定数の初期化に使えるところが利点。
Pow<T,N>(x)はNに関しては、
コンパイラが一般の部分特化のアルゴリズムを備えていなくても
テンプレートと定数伝播、inline展開の常識的な実装を備えてさえいれば
確実に部分特化の意図が伝わるのが利点。

初期のcfrontでトランスレートしてた時代ならイザ知らず、
constもinlineもここで出てる例くらいならば、今の最適化技術では
可能不可能の問題でなくやるかやらないかの問題だから、
一般用途のまっとうなコンパイラでは十分できる範囲だと思う。

80 :デフォルトの名無しさん:02/02/15 15:23
>>79
だから、とりあえず手元の処理系で試してみろって。

81 :71?:02/02/15 16:42
>>74
BCCでためしたで
ASM見たけど思惑道理なってるで


82 :デフォルトの名無しさん:02/02/15 16:55
>>81
よって問題なし、と。

規格について一通り調べがついた後は、「思う」と書いてあーだこーだ議論するより
実際処理系での結果を出した方が話が早いっしょ。

83 :53:02/02/15 18:02
>>81-82
どうもです。
今、ようやく試せる環境(研究室の自分の机)にたどり着きました(w。
もう話は終わってるみたいですが。


84 :デフォルトの名無しさん:02/02/15 18:07
>>79
20バイトというより1バイトさえも使っては意味がないし
コードが展開されてはそもそもいけない。
コンパイル時評価になることが保証されてこその新しいPow。
Pow<N,X>::resultは、コンパイル時評価は保証されないし
計算ごとに生まれる多くのstatic intが削除されることが
保証されないので恐ろしくて使えない。
Pow<T,N>(x)は、やはりインラインが保証されない上、
インライン展開されてもコンパイル時評価になることが
保証されないので駄目。
いままで標準準拠のコードを書くためにがんばってきたのに
ここでenumを裏切るのはなぜか。
あとcfrontがどうとか言い出すのが好感度下げる。ワラ

85 :71?:02/02/15 18:35
>>84
いいたいことはわかるが、templateでやる以上、
pow( 2.0 , 3.5 )とかやりたいね。

86 :デフォルトの名無しさん:02/02/15 23:28
>>84
完璧確実を求めるならちゃんとPartial Evaluationなり、
2-level Languageなり使うしかないんでは?
元々C++の機能の有り合わせで実現してるんだから。

とりあえず両者とも(仮に最適化されなくても)規格的には最低限動作することになっていて、
少なくとも普及している処理系の一つで意図どおり動作するコードではあるのは確か。

ちなみに実行時にtemplateの展開処理をする珍しいコンパイラでない限り
Pow<N,X>::resultはコンパイル時に定数になっていなければならない。
当然定数式の必要なところでは定数として利用できる。
このコードの本来の目的はそれ。
領域が割り当てられて残るかどうかは副次的なことに過ぎない。
仮に、アドレスを取ったりできるように領域が割り当てられたとしても、
定数伝播の最適化とはまた別の側面の話なので問題はない。
(せいぜいメモリ使用量が増えるだけ。実行速度に悪影響はない。
元々展開テクニックではメモリ使用量ではなくて実行速度に重点が置かれる。)

それに標準準拠って言うけどstatic const intではダメでenumに拘る理由も結局不明。
初期化がコンパイル時に実行できないかどうかは、初期化式の側の問題であって
初期化される変数・定数の側の問題ではない。

裏切るも何も、列挙しない単一の定数の宣言にenumを使うほうこそ
考え様によっては病的だと思うがどうか?
(領域がないことを保証させるための抜け道だということは知っているが、
病的なことに変わりはない。)

あと、>>84君の好感度などはこの際限りなくどうでもよいこと。

もう一つ言えば、
これは標準数学ライブラリのpowを置き換えることを意図したものではない。
Pow<N,X>::resultは定数式の必要なところ(固定長配列の長さとか)で
べき乗の計算を行うために必要なだけのもので、
Pow<T,N>(x)は整数Nを固定したべき乗演算が繰り返される場合に有効なコード。
そういう特殊な用途以外の一般の場合には標準的なライブラリのpow()を使えばよい。

さらに言えば、これはGenerativeなコードをC++の有り合わせで書く場合に利用できる
テクニックを紹介するためのサンプルかつ部品である。
powだけ計算して満足しているわけではない。

>>85
残念ながらx^nのnは整数でないと特化できない。

87 :デフォルトの名無しさん:02/02/16 02:38
>85
@sin( 1.46 )とかを展開するような
独自プリプロセサを書けや。


88 :デフォルトの名無しさん:02/02/16 02:51
>>87
そんなことせんでもsin(1460000) // =1.46*1000000とかして
1000000で割ればいいじゃん。
古典的手法


89 :デフォルトの名無しさん:02/02/16 03:40
>sin(1460000)
sinをテンプレートで実用的にかけると仰る?

90 :デフォルトの名無しさん:02/02/16 09:08
>>86
>少なくとも普及している処理系の一つで意図どおり動作するコード
それが駄目だとあれほど。

コンパイル時評価が保証されないので
全くGenerativeではない。君は

賢いコンパイラは仮想呼び出しを実呼び出しに最適化できるので
templateはいらない、仮想関数で十分。
領域が割り当てられて残るかどうかは副次的なことに過ぎない。
せいぜいメモリ使用量が増えるだけ。実行速度に悪影響はない。
多態性にtemplateを使うのは病的。

と思っている。確かにこれは正しい。ワラ
ここでSTLが大好きな君が裏切るのはなぜか。

91 :デフォルトの名無しさん:02/02/16 09:17
つまりさあ、87とかの話題ってfixed演算なわけだよね。
そういうことしたいならLISPでプリプロでも書いたほうが自由度高いし簡単。

(defconst var `(,(sin 1.46))) ;;;リストvarにsin(1.46)の結果を埋め込み。

C++もコンパイル時に関数を実行できる仕様だったら便利なのにね。


92 :デフォルトの名無しさん:02/02/16 09:19
べつにLISPじゃなくてもいいんだけどね。perlやRubyとかでも。
関係ないけどVBでこういうことができないのは不思議。

93 :デフォルトの名無しさん:02/02/16 10:06
>そんなことせんでもsin(1460000) // =1.46*1000000とかして
>1000000で割ればいいじゃん。
まさか・・・

94 :デフォルトの名無しさん:02/02/16 18:05
>>91
C++で実装される言語がなにやらほざいているな

95 :デフォルトの名無しさん:02/02/16 20:57
STLいいんだけどさぁ、
コンパイルエラー等ででてくる、エラーをどうにかしてほしい。


96 :デフォルトの名無しさん:02/02/16 21:21
>>95
『STL Error Decryptor』
 http://www.bdsoft.com/tools/stlfilt.html
みたいなものを使ってみるとか。

97 : :02/02/16 21:51
>96
をぉ!それは便利そうだ!!!!
と思ったら VC 用かよ・・・
残念sage

98 :デフォルトの名無しさん:02/02/16 23:09
>>90
もう、その話題は良いって。

使えると思うヤツは自分のコンパイラで試した上で使えば良いし、汎用性が
必要なプログラムを書いてる場合には、それなりの対処しろ。

99 :デフォルトの名無しさん:02/02/17 09:15
>>98
Genericが汎用って意味なのだが

100 :デフォルトの名無しさん:02/02/17 12:52
>>99
言葉遊びは、技術系の板の外でな。

Generic Programming を Win32 API と組み合わせてプログラミングしたって
良いじゃない。

101 :デフォルトの名無しさん:02/02/17 13:12
「入門C言語」とか銘打っておいて、なかみをみると
いきなりWinMainからはじまったりすると激しく萎える。

102 :デフォルトの名無しさん:02/02/17 13:51
>>101
そんな本があるのかーΣ(゚д゚lll)
禿げしくスレ違いだが書名キボンヌ

103 :デフォルトの名無しさん:02/02/18 02:01
94は煽りのつもりだろうか

104 :デフォルトの名無しさん:02/02/21 23:00
良スレage

105 :デフォルトの名無しさん:02/02/22 03:19
>>100
話のすり替えは、技術系の板の外でな。

enumを置き換えられると思いこんだんだな。

106 :デフォルトの名無しさん:02/02/22 03:57
>>105
言語の仕様上はこの場合でもenumはstatic const intに置き換えられるのでは?
置き換えられないというなら実例をキボンヌ

107 :デフォルトの名無しさん:02/02/22 13:40
>>106
もう相手にしないで、放っておいてやるのが良いと思われ。

108 :デフォルトの名無しさん:02/02/22 20:59
>>91
この例の意義はC++が既に持っている機能でこういうことが書けると言うところに意味がある。

・実用的なGenerativeアプリケーションの開発
・Generativeを正式にサポートする言語の研究開発への動機付け

他の言語に替えてよければ、それこそLISPもそうだが'CとかMetaMLとか色々ある。

109 :デフォルトの名無しさん:02/02/22 21:01
それにこの例はGeneric ProgrammingとGenerative Programmingの近しい関係を端的に示している。


110 :デフォルトの名無しさん:02/02/22 21:08
かくしてtemplateによってC++は2レベル(コンパイル時/実行時)言語になってしまっているいるわけだが、
元々そういう用途を意図して設計しているわけではないので、
この2レベルで激しく構文が違ってしまっているという問題はある。

例えば……:
template引数にはクラス・オブジェクトはおろか整数定数しか渡せない。
書きなれた命令型ではなく関数型プログラミングのスタイルで書かなければならない。
コンパイル時関数を表現するのにtemplateクラスを定義するのはやっぱ無理がある。

というわけでプログラミング言語学的には今後の研究が待たれるところであるっす。

111 :デフォルトの名無しさん:02/02/22 22:31
>プログラミング言語学的



112 :デフォルトの名無しさん:02/02/22 22:34
>111



113 :デフォルトの名無しさん:02/02/22 22:57
C++Builder6の案内が着たけど
3ユーザーとしては買いでしょうか?

114 :デフォルトの名無しさん:02/02/22 23:02
>>110
煽りはともかくとして、昔のCでマクロレベルでどうにかする、
ってのと基本的に変わらないね。
処理系がえらく大きくなった割には対効果が低いのが気になる。
>>108
'Cってなんですか?
quote-C?

115 :デフォルトの名無しさん:02/02/22 23:13
>>114
今回の Pow() あたりだと、
> 処理系がえらく大きくなった割には対効果が低い
のは確かだが、STL の関数オブジェクトやアルゴリズムまで行くと、そう
捨てたものじゃないぞ。

116 :デフォルトの名無しさん:02/02/22 23:25
templateあたりはもうちょっと洗練して縮小とかしてくれないと
あんまり使う気になれないんですが。オブジェクト指向とか以前に。
LISPのマクロなんかは最小限の労力で物凄い効果を期待できますけど、
あんな感じになって欲しいな。

117 :デフォルトの名無しさん:02/02/22 23:27
現状のC++って複数の言語使ってる感じなんだよね・・・

118 :デフォルトの名無しさん:02/02/22 23:32
みんなC++なんて止めてほかの言語を使おう(笑

119 :デフォルトの名無しさん:02/02/22 23:32
C#ですかあ?

120 :デフォルトの名無しさん:02/02/22 23:34
AllegroCLでも使いますか?(笑

121 :デフォルトの名無しさん:02/02/22 23:39
実行時型やtemplateあたりの登場からC++では「おや?」と
思うようになったな。
javaもgenericを搭載するらしいが、はたしてどうなることやら。
なんつーか、ポリシーを持って作ってほしいね。


122 :デフォルトの名無しさん:02/02/22 23:40
C++ではなくObjectiveCが普及すべきであった、せめて。

123 :デフォルトの名無しさん:02/02/22 23:46
Objective-Cが普及しないのは名前長いから?
コミュニティが弱小だから?
ともかくObjective-CをC++という名前にして、
今までのC++は無かったことにするとか。
ストラウストラップは始めからいなかった事に(w
BorlandもDelphiと統合できなくて困ってるみたいだし。

124 :デフォルトの名無しさん:02/02/22 23:52
MacOSXもC++で開発できるようには出来なかったらしい。
OSの設計に言語の汚さがついて行けなったらしく。
ObjectiveCがメインで、Javaでもなんとかなるとかならないとか。

C#登場で一気に滅亡しそうな予感もしてるんだな。

125 :デフォルトの名無しさん:02/02/23 00:05
>>117
それは言えてる。

手続き、OO、汎用プログラミングなんでもアリなのはメリットだとは思うが、各々の
親和性がもうちょっと上がると嬉しい気がする。template がらみのエラーメッセー
ジとか。

126 :デフォルトの名無しさん:02/02/23 00:13
C#はガベコレあるから、もはや別の次元でしょう。>124

127 :デフォルトの名無しさん:02/02/23 02:27
最初の方で generative generative って言ってた人もう来ないのかな?
generic なアプローチと generative な方法との違いが知りたいんだけど。

128 :デフォルトの名無しさん:02/02/23 02:38
>>127
俺は最初の方の人とは違うけど、

generic
 型に依存しない操作

generative
 コンパイル時にポリシーを与えて、コードを動的に生成する

ってイメージがあるな。STL だと algorithm は generic だけど、container なんか
は generative っぽい気がする。

129 :デフォルトの名無しさん:02/02/23 21:13
>>106
置き換えられないことを説明するのに疲れたよ
>>84あたり読んでくれ
>>107
自分で言うのがまさに再起的でこのスレにぴったりだな。思われ君よ。

130 :デフォルトの名無しさん:02/02/23 21:26
>>129
> 置き換えられないことを説明するのに疲れたよ
もう説明しなくていいって。書くことは一通り書いたんだから、後は読んだやつが
各自で判断すればいいだろ?

131 :デフォルトの名無しさん:02/02/23 21:31
>>130
レス早くて怖いよ!
あと>>86長すぎだよ!
もっと話そうよ友達になれそうだ

132 :デフォルトの名無しさん:02/02/23 21:33
>>131
構って欲しければ、馴れ合い系の板に逝けよ(w

133 :デフォルトの名無しさん:02/02/23 21:35
>>132
そういった時点で呉越同舟だよ!!ワラ

134 :デフォルトの名無しさん:02/02/23 21:43
scheme読んでて思ったんだが
(自分はgenerativeプログラミングは
staticプログラミングとでも呼んだ方がいいと思う)
factorialとかsumとかpowとか書いてると
これらをさらにgeneralizeして
マクロにする。Modern..本のTYPELISTみたく。
こんなことやってるライブラリはないんだろうかね。
intのリストは全部staticに処理できるのではないかと。
あまり役には立たないだろうけれども。

135 :デフォルトの名無しさん:02/02/24 12:55
>>129
ヲイヲイ、>>84のいったいどこが実例なんだYO!

136 :107 (!= 106):02/02/24 14:36
>>135
だから、放っておいてあげなよ。アレで本人は満足なんだから。

137 :デフォルトの名無しさん:02/02/25 18:15
VC.NETのtemplateはまじでどうなったのかな。
たのむよ!

138 :デフォルトの名無しさん:02/02/26 13:15
>>114
tick-C
実行時にコード生成できるように拡張したC。
処理を実行時まで遅らせるようにコードをマークする記法と、
遅らせた中の一部をコンパイル時に実行できるようにマークする記法を組み込んだ
2レベル言語になっている。

http://www.pdos.lcs.mit.edu/tickc/

テンプレート方式のコード生成と呼ばれる技法で実装されている。

139 :デフォルトの名無しさん:02/02/26 13:20
>>128
genericな関数の定義を効率よく実装する方法の一つが
パラメータ毎に展開してコード生成すること。
templateを利用したgenerativeテクニックはそのコード生成機能を逆手に取って
実現されている。

ちなみにJavaに導入されるtemplateは実行時に処理されるらしいので、
ここで話題になったようなコード生成テクニックには利用できない。

まぁ、Javaの場合、
コード生成素直にダイナミック・ロードでなんとかしろってことなんでしょうか?

140 :デフォルトの名無しさん:02/03/03 00:22
 保守age

141 :デフォルトの名無しさん:02/03/03 22:31
Modern C++ Design買ったはいいけどまだぜんぜん読んでない。

142 : :02/03/03 23:43
>141


143 :デフォルトの名無しさん:02/03/12 04:36
久しぶりにあげてみる

144 :デフォルトの名無しさん:02/03/12 04:49
Modern C++ Design
amazon注文age

145 :デフォルトの名無しさん:02/03/12 06:19
スレタイが際立ってるな。

146 :デフォルトの名無しさん:02/03/12 19:07
age

147 :デフォルトの名無しさん:02/03/12 19:08
>>146
ageてばかりだと、そのうち
ageばっかりになるぞ
なんかしゃべれ

148 :(ΦωΦ)フフフ・・・:02/03/13 03:05
(ΦωΦ)フフフ・・・

149 :(Φ∀Φ)フフフ・・・ :02/03/13 03:16
(Φ∀Φ)フフフ・・・

150 :デフォルトの名無しさんk:02/03/18 23:39
買ってきた。明日の朝9時までに3章までは毒派する予定。

151 :デフォルトの名無しさん:02/03/18 23:41
この本、期待してたほどにはカルチャーショック受けなかった。
なんつーか、何かにつけてめんどくさいね。

152 :デフォルトの名無しさん:02/03/18 23:52
>>151
それが C++ の限界。
もうパズルだよな。

このスレは generic programing と generative programming が
混じってるので混乱する。
URL 紹介
http://www.generative-programming.org/


153 :デフォルトの名無しさんk:02/03/19 00:05
これに書かれてる内容のようなことはMLやHaskellだったら
もっとスマートに出来るの?

154 :デフォルトの名無しさん:02/03/19 03:20
>>151
haskellはともかく、MLはこういうことに関してはすんごいよ

155 :デフォルトの名無しさん:02/03/19 04:00
>>154
Haskell はダメなの?

156 :デフォルトの名無しさん:02/03/19 05:49
>>154
HaskellやMLで出来ない技が多いよ。

たしかに、この本の中に出てくるFunctorは
関数型言語では高階関数(カリー化)というものと、とても似ています。

しかしC++のテンプレートは、ソースを実際にマクロのように展開しています。
こういうマクロのように展開することを関数型言語ではα簡約といっているらしいですが。
こういう機能はLispとSchemaにはありますが、MLやHaskellでは無いです。

本質を見極めた上で書きましょう。

157 :デフォルトの名無しさん:02/03/19 11:32
マクロ展開できることは本質的なことなんですか?

158 :デフォルトの名無しさん:02/03/19 16:08
>>157
C++にとっては本質的

159 :デフォルトの名無しさん:02/03/19 16:33
正直、Cのマクロを多少強化すれば解決する問題が多い気がするんだけど

160 :デフォルトの名無しさん:02/03/19 18:23
>>159
「多少強化」がやろうとすると多少の強化では済まないことも多いからなぁ。
タイプ・チェックも計算能力も。

161 :デフォルトの名無しさん:02/03/19 21:04
Lispに追いつこうと頑張るのは凄いけど、
> > >と最後の閉じカッコがなんともまぬけでイイ(w

162 :156:02/03/19 22:15
<<157
何時、評価&簡約されるかということ。
α変換(C++で言えばプリプロセッサによるマクロの展開、テンプレートの展開)はコンパイルされるとき展開、簡約されますね。
β変換(実行時に引数を渡すこと)は、実行時に評価、簡約されます。
何時評価されるかって結構だよね。

訂正:α簡約なんていう言葉は無いです。α変換の間違いです。
漏れも逝きます。

163 :λ中将:02/03/20 08:46
# α簡約と言わないことも無いと思う。。。

164 :デフォルトの名無しさん:02/03/20 17:14
誰か下の二冊を読んだ人がいたら感想聞かせてほすぃ

【Generative and Component-based Software Engineering】
http://www.amazon.co.jp/exec/obidos/ASIN/3540411720/

【Generative Programming: Methods, Tools, and Applications】
http://www.amazon.co.jp/exec/obidos/ASIN/0201309777/

165 :デフォルトの名無しさん:02/03/20 21:49
http://www.moderncppdesign.com/

166 :デフォルトの名無しさん:02/03/20 23:17
>> 【Generative and Component-based Software Engineering】
かなり抽象度高くて眠くなる。 C++ で Lisp ごっこをやる章は楽しかったけど。
学術的な雰囲気の強い本なので、そういう素養がないとつらいとおもう。
(OOPSLA の論文読んで理解できるレベルなら十分。)

167 :デフォルトの名無しさん:02/03/21 01:11
age

168 :デフォルトの名無しさん:02/03/21 01:17
これからlokiみたいなライブラリが増産されていくのかと思うと、
楽しみと思う反面、地獄の予感もしたりする、、

169 :デフォルトの名無しさん:02/03/21 01:46
だれか、>>53みたいなやつで、LOG書いてくれ。


170 :デフォルトの名無しさん:02/03/21 02:20
>>162-163
β変換がβ簡約とも言われるのは適用されるたびにλ項が解消されて減っていくから。

(ある種のλ式ではβ変換を有限回適用することで簡約順序に関わらずそれ以上簡約できない
「標準形」になることがわかっている。無限回簡約できるようなλ式、
またその中でも評価順序によっては有限回でそれ以上簡約できなくなるようなλ式もある。)

α変換は名前の付け替え変換だから式の形自身は変わらないので、
無限回繰り返すこともできるが、
同一視することによって無視する(α合同関係)ことが多い。

というわけで、α簡約とはやっぱりあまり言わないかも。

まー、マクロ展開にせよテンプレートの展開にせよ
単純なλ計算そのものではない。

例えば、プリプロセサマクロの名前付け替えは、
付け替え後の名前が付け替え対象の名前になるような関係による
循環を避ければ有限回で終了する。

それでも敢えて喩えて言えば、
プリプロセッサのマクロ展開だからα変換とも限らず、
引数つきマクロなどはβ変換といってもいいかもしれない。

171 :170:02/03/21 02:33
肝心なことを書き忘れた。
>>170
つまり標準形のあるλ式(計算が終了する)であるならば、
λ項はβ変換適用ごとに減っていくので「簡約」なわけです。
通常、計算は終了することに意味があるとされるので、逆に
β変換が「簡約」であるようなλ式を「正しい」プログラムの表現
と見るわけです。

ついでに言えば、現実のプログラムでは評価順序も決まってるから、
その評価順序において簡約し切れるような式であれば良いわけで、
標準形のあるλ式以外にも、特定の簡約順序によって
有限回で簡約不能な式(値)になるような式も
条件付で認めるが立場あり、実はプログラムの基礎理論としては主流です。

172 :デフォルトの名無しさん:02/03/21 04:24
>>171=170
わかったから。
そいうことは関数型言語板かLispShcema板でやって
お願い


173 :デフォルトの名無しさん:02/03/21 04:30
>>172
ModernC++Design読むと逆にSchemeとかMLやってみたくならねぇ?
これから10年後のC++のプログラムとか、今のクラスライブラリの
惨状から想像するとぞっとするんだけど。

174 :デフォルトの名無しさん:02/03/21 13:50
>>172
この本のやってることってtemplateでどこまでconst演算できるか?
ってのもあるからあながち無駄でもないかも。

175 :172:02/03/21 19:04
>>173
もちろん無駄だといってる訳ではない。
ModernC++Designを読んでる最中にHaskellに出会って
今、はまりまくってるよ。
そのせいか、STLもパラメータ化クラス(型?)を使いまくってる性で
関数言語風味たっぷりに感じてるよ。
どれくらい嵌ってるかというと、関数プログラミングからホーアCSP理論まで読んで
「ほー、Eiffelの表明の元ネタは仕様記述言語Zから来てたのは知ってるけど
そのZ言語の元ネタはCSP理論なんかー。おもしれーなー。
表明の推論もできそうだなー」とか訳のわからんことを考えるくらい嵌ってる。

ただ、この手のネタは、この板の主旨から結構ズレてしまったのでは?
と思うわけよ。

>>174
これも面白いと思う。
非正格言語でtemplateみたいなコンパイル時簡約?みたいなことが
出来たら実行速度が手続き型言語に勝てる関数型言語も夢では無いかもしれない
と俺は創造してしまう。
(CleanやMLは代入使って実行速度を上げてるようだが、そんなセコイことせずにな)

でも、なーtemplateは形検査してくれないからなー。
ModernC++Designの技はやり過ぎだと思う。
ハッタリには使えると漏れも思う。
(研究する価値が無いというつもりは無い。そこは酌んでほしい)

176 :デフォルトの名無しさん:02/03/21 19:37
>>172
やっぱり実践的なプログラムにあれは使うものじゃないよね。
Cの変なテクニックを積み重ねたようなプログラムなんて物凄く
読みにくいけど、それの上を逝ってるよ。

177 :デフォルトの名無しさん:02/03/21 19:51
あれは「上には上がいるもんだが、ここまでやっちゃあいかん」という見本だ。
頭の体操には悪くないが。


178 :デフォルトの名無しさん:02/03/21 21:10
COBOLでオブジェクト指向、みたいな話になってる気がする

179 :デフォルトの名無しさん:02/03/21 21:17
まぁでも実際に使ってみないことにはなんとも言えないね。

180 :デフォルトの名無しさん:02/03/22 00:00
テンプレートの特殊化に対する適合アルゴリズムについて詳しく解説してる
サイト、キボーン!(懐)

181 :デフォルトの名無しさん:02/03/22 14:42
gcc3.0でLOKIは動きますか?

182 :デフォルトの名無しさん:02/03/22 23:17
>>181
動くらしい。(LokiのReadMeに書いてなかったけ?)
Lokiがコンパイルできる珍しい処理系


183 :デフォルトの名無しさん:02/03/23 03:59
VCじゃできないのか??

184 :デフォルトの名無しさん:02/03/23 04:41
BCCでもだめなのにVCで動くかー


185 :デフォルトの名無しさん:02/03/23 08:19
>>183
じゃ、駄目じゃん、、、
いったいなんでgccでは動くのか、その理由が知りたいな。
実際、ここまで互換性がないとテンプレート怖くて使えないんだけど。

186 :デフォルトの名無しさん:02/03/23 08:20
>>185
あるSTLの本の第一章に。

「互換性が低いことを怖がってSTLに対して保守的にならないで下さい。
時代はstanderd C++に向かっているのです。」

187 :デフォルトの名無しさん:02/03/23 08:23
>>186
・・・で?

188 :デフォルトの名無しさん:02/03/23 08:54
>>185
VC++ だと部分特殊化もメンバ関数テンプレートもサポートしてないから…
つーかもう4年近く前のコンパイラだよ?<VC6

VC.NETだとどの程度templateに対応してるんだろ。

189 :デフォルトの名無しさん:02/03/23 12:31
VC.NETでLokiコンパイルしてみたひといる?


190 :デフォルトの名無しさん:02/03/23 13:57
一応MSDN MagazineにはBoostやLokiがちゃんとコンパイルできる、
って書いてあったが<VC.NET

191 :デフォルトの名無しさん:02/03/23 14:18
>>185
gccが開発バージョン2.9から最新ANSI C++規格を実装したからさ
それと.NETでLokiは使いたくないなー。VC.NETはやめとけ。
氏ぬぞ。

192 :デフォルトの名無しさん :02/03/23 14:27
gccマンセー

193 :デフォルトの名無しさん:02/03/23 14:34
Lokiってどこにあるの??
サイトがでかすぎて分からないヨ

194 :デフォルトの名無しさん:02/03/23 14:47
http://www.awl.com/cseng/titles/0-201-70431-5/loki.zip

195 :デフォルトの名無しさん:02/03/23 14:49
サンクス〜〜♪

196 :デフォルトの名無しさん:02/03/23 15:04
Loki初めてみた。
凄ぇ・・・まさに天才。

197 :デフォルトの名無しさん:02/03/23 15:19
みんなあれを最後まで理解した?
おれは3章であっぷあっぷだよ。
あんまりテンプレート自体を使いこなして内省かも。

198 :デフォルトの名無しさん:02/03/23 15:25
色々とお褒めの言葉をならべてもLokiを使ったサンプルコードが
出てこないところをみると皆自分の中で消化吸収してる最中なのかな?

おれはあと3ヶ月ぐらいはかかるだろうな。

199 :デフォルトの名無しさん:02/03/24 01:38
あげ!

200 :デフォルトの名無しさん:02/03/24 01:44
Lokiすごいけどさ、やっぱりすごいだけで泥臭いと思うよ。

201 :デフォルトの名無しさん:02/03/24 01:58
つーかおれはそもそもテンプレートの構文が嫌いだ。

202 :デフォルトの名無しさん:02/03/24 15:19
こらこらtemplateあってのC++だ。

203 :デフォルトの名無しさん:02/03/24 17:12
漏れもそうだ。
C++使う理由の大半はテンプレートがあることだからね。
STL なーんて素晴らしい。

204 :デフォルトの名無しさん:02/03/24 18:22
じゃ、templateのないC++はなんなんだyo!

205 :デフォルトの名無しさん:02/03/24 18:26
非互換C

206 :デフォルトの名無しさん:02/03/24 18:26
>>204
Java

207 :デフォルトの名無しさん:02/03/24 18:43
あんな糞言語と一緒にするなよ

208 :デフォルトの名無しさん:02/03/24 18:53
やばい。ちんこ勃ってきた。

209 :デフォルトの名無しさん:02/03/24 18:58
>>204
D言語

210 :デフォルトの名無しさん:02/03/25 06:47
C#にはテンプレートに該当する物はあるのか?

211 :デフォルトの名無しさん:02/03/25 07:06
つーかeval相当はないの?

212 :デフォルトの名無しさん:02/03/25 09:09
>>211
evalはやめてー
究極すぎる

213 :デフォルトの名無しさん:02/03/25 09:58
Ruby以外の言語は使い物になりません。以上。

214 :デフォルトの名無しさん:02/03/25 11:11
>>213 激しく同意

215 :デフォルトの名無しさん:02/03/25 11:14
えっへん!

216 :デフォルトの名無しさん:02/03/25 12:52
あの本の一章に書いてあるポリシーパターンだけでも
結構使えるよな。テンプレートパラメータからホストクラスを
派生させるってのカッコいいから使ってるよ。

217 :デフォルトの名無しさん:02/03/25 12:56
Int2TypeとかType2Typeもね

218 :デフォルトの名無しさん:02/03/25 13:26
VS.NETを購入された方へ質問があるのですが、C#にはC++でいうところの
STLに該当する機能はあるのでしょうか。購入検討の資料としたいのです。

219 :デフォルトの名無しさん:02/03/25 13:40
>>218
よく知らないけど、System.Collectionsのコンテナを
使うんじゃないかな?だからSTLは無いと思うけど。

220 :デフォルトの名無しさん:02/03/25 14:39
タイプリストはなんか凄そうなんだけどあれをどう活用するのか
分からない。だれか簡単に説明してくれないかな?

221 :デフォルトの名無しさん:02/03/25 20:04
なんでもλ
ttp://www.shiro.dreamhost.com/scheme/docs/lambda-j.html

STLといい最近のC++は関数型プログラミングの匂いがー
関数プログラミングのすばらしさはまだまだあるぜーいえー。
なんでも再帰
ttp://www.shiro.dreamhost.com/scheme/docs/tailcall-j.html
なぜ関数プログラミングは重要か
ttp://www.sampou.org/haskell/article/whyfp.html

222 :デフォルトの名無しさん:02/03/26 00:06
>>220
Functorと組み合わせて高階関数ができるからかな?
ttp://www-6.ibm.com/jp/developerworks/linux/010921/j_l-prog3.html
ttp://www.teu.ac.jp/kougi/koshida/Prog6/Text08/index.html
ttp://a414s1.it.nanzan-u.ac.jp/smlbook/smlwww/node10.html

TypeListと補助するtemplateだけでも役にたつところもあるかな?
ttp://www.google.com/search?q=cache:5o9J68CC7oMC:www.tama.or.jp/~o-mikita/phantasien/memo/p0108.html+C%2B%2B+TypeList&hl=ja&lr=lang_ja


223 :デフォルトの名無しさんk:02/03/26 00:37
今タイプリストの使い方を色々と本読みながら考えてるんですが、

class Cls
{
public:
 //このクラスにおいて関係するタイプのリストを作成する
 //(全てのアプリケーションコードにあるクラス内において必須)
 typedef TYPELIST_3(Cls1, Cls2, Cls3) MyClsList;
 ・・・
private:
 //必要なインスタンスを作成する
 Loki::TL::TypeAt<MYClsList, 0> cls1;
 Loki::TL::TypeAt<MYClsList, 2> cls3;
};

とかって感じにタイプリストからの型選択テンプレートクラスに
リストを渡して選ばせる感じに使うんでしょうか?
なんか頭が固くていい使い方が思い浮かばないなw
クラス間の関係が明確になるメリットは大きいかな。

224 :デフォルトの名無しさん:02/03/26 01:04
アプリケーションコードにおいてもテンプレートパラメータの
諸関係だけを記述するようなプログラムを作るのってかなり頭痛いよね。
上の奴もCls自体をいくつかのテンプレートパラメータ(タイプリスト)を
もらうように直したら、かなり自由度は上がるけどもう何がなんだか
分からんものになりそうな・・・
アプリケーションプログラマにそこまで要求するんか!の世界。
この本読んで任意の処理に対するタイプリストの設計を勉強しないと
全然ダメだな。

こういうのはもっと若いうちにやりたかったよ。。。(遠い目

Lispハカーは、こういったやり方でいつもプログラミングしてるんですか?

225 :デフォルトの名無しさん:02/03/26 01:28
>>223
その設計は良くないのでは?
(タイプリストの引数の数が変わったとき作りなおさなやね)
今手元に本が無いので上手く掛けないけど・・・
TypeListのクラスを単一継承するという活用法が載ってた
と思うけど、そってで攻めてみては?

あっ。Cls2,Cls3,Cls4見たいにしたらいいんか

226 :223=224:02/03/26 01:36
>>225
今まではOO的なプログラミングということでインターフェイスを
規定してそれに対して実装するってやり方だったけど、これは
全然違うね。

最初にタイプリストありき。それの関係を記述するようなプログラミング。
あたま痛くなってくる。でもこれがホントの再利用性なのかも。

227 :223=224:02/03/26 02:11
ダメだ、、、
馬ファ輪飲んで今日はもう寝る

228 :225:02/03/26 02:18
>>223=224
個人的にはType2Typeぐらいしか使いたくないなー
実際の開発に使えそうなものって何かな?

229 :デフォルトの名無しさん:02/03/26 02:37
結論
天才が書いたコードは天才しか再利用できない

230 :223=224:02/03/26 02:44
>>228
んー、自分でも色々と考えてるんだけど、これをつかった効果を
なんとなく想像するので精一杯。

イメージとしては、既存の開発において
ライブラリコード:アプリケーションコード=1:10
ぐらいの比率だったとして、Alexandrescu方式のプログラミングを
導入したことで
ライブラリコード:アプリケーションコード=8:2
みたいなところまで比率に上げる。というか外部のライブラリやシステムに
依存したものを極力排除する。そうして全体のステップ数を減らす。
こんな世界(w)を期待してるのは分かるんだけど、
いかにライブラリコードを設計するかは一筋には逝かないね。

システムの全体を理解してパターンを適用し、それらの関係を
リストで表現する。こんな天才的能力がある人だけが使うものかもね。
リストをデータ構造としか考えてこなかった俺みたいなヘタレには
そもそも無関係かも(w

STLで上がった生産性がアプリケーション全体に適応されたら
天才とヘタレの能率の差なんて目も当てられないだろな。

231 :223=224:02/03/26 03:43
>>229
天才の書いたコードは天才しか再利用できないかもしれないけど、
ModernC++Designで言われているのは「自分の書いたコードぐらい
再利用しようぜ」ってことだと思う。

天才がこういったプログラム設計をあっという間に理解して
抽象度の高いプログラミングをしてると思うとカナーリ鬱なんだけど、
ヘタレもお遊び程度にはやっておかないと。

今日はショックで眠れないYO、トホホ

232 :デフォルトの名無しさん:02/03/26 22:32
Haskellマンセー!!!

233 :デフォルトの名無しさん:02/03/26 22:40
>>223=224
クラス同士の機能が独立したものになるように
設計すればいいかも。
そのクラス同士を組み合わせるところにGenerativ Programming
を使えばよいと考えている。

しかし完全に機能が独立したクラスまで上手く機能を分割できないと・・・・
俺にはむりっす

234 :デフォルトの名無しさん:02/03/26 22:53
おみゃーら、Haskellやれ。
C++のきったねー構文に関する知識は後から詰め込めばよし。
まずはプログラミングが何なのかを学ぶためにHaskellをやれ。

235 :デフォルトの名無しさん:02/03/26 23:09
>>234
スレ違い。

236 :デフォルトの名無しさん:02/03/26 23:13
>>234
板違い

http://cheese.2ch.net/test/read.cgi/math/1015420115/
あっちの板では認知度が低いです。がんばって宣伝してきてね

237 :デフォルトの名無しさん:02/03/26 23:32
>>234
HaskellはIOとのやり取りが弱いので実用的ではない。
まあ、これは言語ではなく処理系の問題だが。

あとHaskellはマクロが無いね。
コンパイル時でないと知りえない情報(__FILE__とか__LINE__)が
かけない。すこし残念。

238 :デフォルトの名無しさん:02/03/27 00:56
ああいったプログラミングテクニックってどこに書いてあるの?
C++Report?DDJ?

239 :デフォルトの名無しさん:02/03/27 01:07
単にLoki::SingletonHolderを使ってみるだけでも苦労した。鬱だ…


240 :デフォルトの名無しさん:02/03/27 02:24
Loliは凄いけどタイプリストのマクロ定義にがっかりした人も多いはず!
もっと柔軟なものをここでなんとしてでも作りませう!

241 :デフォルトの名無しさんk:02/03/27 02:37
無理

242 :デフォルトの名無しさん:02/03/27 02:54
俺には無理


243 :241:02/03/27 03:05
静的型付け言語としてあれが精一杯だと思うけどどうだろ。
マクロの部分ならなんとかなるかもしれないけど。

244 :デフォルトの名無しさん:02/03/27 03:15
(´・ω・`)ショボーン

245 :デフォルトの名無しさん:02/03/27 04:11
>>242
Andrei Alexandrescu にも無理(だった)

>>240
どうでもいいが Loli じゃなくて Loki な。

246 :デフォルトの名無しさん:02/03/27 14:22
Lokiは標準に準拠したコンパイラなら通らなければいけないコードなんですか?

247 :デフォルトの名無しさん:02/03/27 14:23
C++がRubyにまさっている天安か有る?

248 :デフォルトの名無しさん:02/03/27 14:24
>>247
ありません、ごめんなさい

249 :デフォルトの名無しさん:02/03/27 14:30
やたああああああああああああああああああああああああああああああああ
Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C++


250 :デフォルトの名無しさん:02/03/27 14:37
Ruby!!!!!!!!!!!

251 :Rubyは好きだけど、比べることは不毛だ。:02/03/27 20:19
無いと > なのか?
= って可能性は無いわけ?


252 :デフォルトの名無しさん:02/03/27 20:45
ロリ>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Loki


253 :デフォルトの名無しさん:02/03/27 20:50
>>251
たぶん operator>>>>>>>>...() だから stream から入力してるんだと思うが。

254 :デフォルトの名無しさん:02/03/27 20:57
頼むからレス付けないでくれ。
別スレが丁度あるじゃん。

255 :デフォルトの名無しさん:02/03/27 21:06
>>253
いや、激しくビットシフトしてるんだと思うぞ。

256 :デフォルトの名無しさん:02/03/27 21:27
シフトしてる数は少ないけど、ビットシフトの勢いは激しいのかも。
はしっこのビットがはみ出すくらいに・・・


257 :デフォルトの名無しさん:02/03/27 23:25
STLはインライン展開しまくってくれるのがどうも。。。。
確かに画期的だとは思うのだけど。

インラインしてくれる分、それだけコードは早くなるんだけどね。

258 :デフォルトの名無しさん:02/03/27 23:33
>>257
コンパイラのオプションをいじって、最適化を「速度優先」から「サイズ優先」
に変更しましょう。インライン展開が、かなりの程度まで抑制されます。

259 :デフォルトの名無しさん:02/03/28 00:33
>>257
全く変化なしでしたよ。

260 :デフォルトの名無しさん:02/03/28 00:33
>>259
ちがった。
>>258
全く変化なしでしたよ。

261 :デフォルトの名無しさん:02/03/28 00:45
>>257
最近のCPUではインラインしすぎはかえって遅くなることが
あるんで、よろしく。STLに限った話じゃないけども。

262 :デフォルトの名無しさん:02/03/28 00:50
STL

263 :デフォルトの名無しさん:02/03/28 00:55
WTLで、メッセージハンドラがマクロ内に
インライン展開されてたのにはびっくりした。

264 :デフォルトの名無しさん:02/03/28 01:26
>>263
そりゃマクロだからインライン展開するわな。
つうかマクロをインライン展開というのかは微妙
# あれにびっくりしたのには同意。

265 :263:02/03/28 01:53
class Hoge : public CWindowImpl<Hoge>{
BEGIN_MSG_HANDLER(Hoge)
MESSAGE_HANDLER( WM_HOGE ,OnHoge ) 
//OnHogeがここにinline展開される
MESSAGE_HANDLER( WM_HOGE2 ,OnHoge2 ) 
//OnHoge2はここにinline展開される
END_MSG_HANDLER()
LRESULT OnHoge(){...} //ここではbpかけられない
LRESULT OnHoge2(){...}
};

266 :デフォルトの名無しさん:02/03/28 02:51
>>265
そんなあなたに

__asm { int 3 }

(っつー話じゃないか)

267 :デフォルトの名無しさん:02/03/28 16:36
Alexandrescuってさなんかデザパタの著者とかEffectiveやExceptionalの
著者に遠慮して本書いてないか?modern~はとても実践的な本だけど、もっとTypelistに
特化した馬鹿みたいなオタク本を書いて欲しいところだな。

268 :デフォルトの名無しさん:02/03/28 23:13
もっと色んな実例を集めて紹介してほしかったりする。>Alexandrescu
彼のWebページは何だかな。

269 :デフォルトの名無しさん:02/03/28 23:16
>>268
いやWebで公開するには惜しいアイディアがあるんだろ。
more modernが出るのをひたすら待つのみ

270 :デフォルトの名無しさん:02/03/28 23:17
んなもん読む暇あったらChristopher Alexanderの著作嫁
Alexandrescuは彼のパクリ

271 :デフォルトの名無しさん:02/03/28 23:20
>>270
知ったかしてます?
なんか具体的なこと語ってみてよ

272 :デフォルトの名無しさん:02/03/28 23:24
Alexandrescuのテクニックはパターンの実装においても
使えるけど、それ以外のことにも可能性がある点が面白いわけで
270のような奴はそもそも勘違いしてるんだろな。

273 :デフォルトの名無しさん:02/03/29 01:10
Functorのサンプルコード、g++3.0で動いた人いますか?
なんかローダーがエラー返してくる。。

274 :デフォルトの名無しさん:02/03/29 02:54
ああ、すまそ。SmallObj.cppをコンパイルするの忘れてた。失礼!

275 :デフォルトの名無しさん:02/03/29 17:01
>>164
下の本注文しますた!

276 :デフォルトの名無しさん:02/04/02 00:20
テンプレートあげ!

277 :デフォルトの名無しさん:02/04/02 00:29
VCのtemplateの限界がわからん。
何処まで許されているのだ?

278 :デフォルトの名無しさん:02/04/02 00:32
VCなんて捨て捨て。
これからはC++コンパイラといえばG++を指します。

279 :デフォルトの名無しさん:02/04/02 00:35
G++って何ですか?
VC、BCB、gccしか知らないものですから・・・。

280 :デフォルトの名無しさん:02/04/02 00:57
gccのC++コンパイラがg++。

281 :デフォルトの名無しさん:02/04/02 00:58
>>280
しかし g++ と G++ は、かなり違う気がするが。(特に UNIX だと)

282 :デフォルトの名無しさん:02/04/02 01:02
g++はいいんだけど、autoconf,automakeの使い方覚えるのが
偉い大変だよな。みんなあれをすんなり覚えられた?

283 :仕様書無しさん:02/04/02 01:35
CppTestつかいながら覚えるとよい。


284 :デフォルトの名無しさん:02/04/02 09:32
最近のg++は、単にC++用のオプションをつけてgccを呼び出すスクリプトです。

285 :デフォルトの名無しさん:02/04/02 17:43
あげ

286 :デフォルトの名無しさん:02/04/02 21:17
>>284
(゚Д゚)ハァ?

287 :284:02/04/02 21:53
>>286
>>280に言ってるんだけど、なにか?

288 :デフォルトの名無しさん:02/04/02 22:15
スクリプトじゃなくてバイナリの実行ファイルになってるけど

289 :デフォルトの名無しさん:02/04/02 22:45
$ man g++

G++(1) GNU Tools G++(1)

名称
g++ - GNU プロジェクト C++ コンパイラ (v2.4)

書式
g++ [option | filename ]...

解説
C コンパイラおよび C++ コンパイラは統合されました。 g++ は
gcc に C++ を解釈するようにするオプションをつけてコール す
るスクリプトです。詳細は英語版のオンラインマニュアルおよび
gcc(1) を参照して下さい。


290 : :02/04/03 00:19
>>289
情報が古いと思われ。っつーか基本的にスレ違いだよな、この話題。

291 :デフォルトの名無しさん:02/04/06 10:40
でも現実的に今、Lokiが使えるC++コンパイラといえば
gccかCodeWarriorぐらい。
しかたがないね。

CodeWarriorかおか?

292 :デフォルトの名無しさん:02/04/13 11:01
ついでにこっちもあげ

293 :デフォルトの名無しさん:02/04/16 11:53
VC6でBCCで使える様にLokiを修正できないの?

294 :デフォルトの名無しさん:02/04/16 11:56
そんな糞は捨て捨て
gcc使いなさい。

295 :デフォルトの名無しさん:02/04/16 16:37
糞クソ言わないでヨ!
(`ε’)プンプン

296 :デフォルトの名無しさん:02/04/16 18:04
>>293
できん。
特にVCでは不可能。

BCCでも機能が足りん。
テンプレートクラスの中でテンプレートクラスが宣言できない。
T1 < T2 < T3, T4 >, T5 >みたいな複雑なテンプレートの特殊化ができない。
これじゃねー。

297 :デフォルトの名無しさん:02/04/16 18:15
面白さと革新さは認めるけどVCで使えないんじゃ
はっきり言ってただのオナニーコードじゃん
GCCだけで閉じられてる商用プロジェクトなんてあんまり
ないんじゃないかと思うがどうよ?
結局現時点では実践向きじゃないって事?

298 :デフォルトの名無しさん:02/04/16 18:41
>>296
それができるとどんな利点があるの?

299 :デフォルトの名無しさん:02/04/16 19:07
>特にVCでは不可能。
>BCCでも機能が足りん。
これってテンプレートの限界を表わしてるよね。
これじゃ実用にならない。

300 :デフォルトの名無しさん :02/04/16 19:50
300get!

>>298
テンプレートパラメータとしてタイプリストを
作りそのリスト値から任意の型を取り出せる。

>>299
vs7のコンパイラならいけるらしい。
それにlokiはansic++準拠だよ
テンプレートの限界じゃなくて
コンパイラメーカーの限界

301 :デフォルトの名無しさん:02/04/16 19:51
理解できない→「んなもん、実用にならんわい」といいたくなる罠。

と、マンネリな煽りはさておいてvcも7.1で対応させるとか、させないとか。

302 :デフォルトの名無しさん:02/04/16 20:09
>GCCだけで閉じられてる商用プロジェクトなんてあんまり
うふ♪

303 :デフォルトの名無しさん:02/04/16 20:12
p.210で、
素のC++だと、"Deriverd" という文字列からDeriverd型のオブジェクトを作成できなくて
云々とあるけど、この本のどのへんのコードを見れば文字列からオブジェクト生成するのが楽に
汎用的にできるのかがさっぱりわかんない俺はガス管くわえて死んだ方が世の中の為ですか?


304 :デフォルトの名無しさん:02/04/16 20:30
>>303
コンパイラの内部表現としての型と
コードに記された型名の違いということではなくて?

305 :デフォルトの名無しさん:02/04/16 20:32
name mangling の話…? は余り関係ないように思われ


306 :296:02/04/16 20:40
>>298
本を読んでから、返事をください。
先の例より複雑なテンプレートがいっぱい出てきます。

>>303
本の例とは逆に
template < class T > class GetClassNameAble{
char* getClassname() { return T; }
}
みたいなことができても面白いと思われ。


307 :デフォルトの名無しさん:02/04/16 20:43
>>306
そんなのいみねー
文字列からクラスを生成(Reflection)できると便利だが(構造上&仕様上不可能なのは承知)
>>306の例だとほとんど使う意味がない

308 :デフォルトの名無しさん:02/04/16 20:44
>>306
> 本を読んでから、返事をください。
> 先の例より複雑なテンプレートがいっぱい出てきます。

了解しますた。もっと勉強します。

309 :デフォルトの名無しさん:02/04/16 20:49
>>299
「実用」の定義によるな。gcc で仕事してる人間には実用レベルだし、Win32
アプリケーションを VC6 で書いてる人間には使い物にならん。

ただ、VC も BCC もいずれ ANSI C++ 準拠してくるだろうから、そのときに
使える選択肢が一つ増えるって事で。

(そういや Boost に Loki 入れようという話、どうなってる?)

310 :デフォルトの名無しさん:02/04/16 20:54
SHをターゲットとしたプログラムにタイプリストが使われまくり、
Windows上のプログラムでは未だに従来のデザパタのサンプルコード
みたいなのが使われてるなんて、、、なんか違和感あるなw

311 :デフォルトの名無しさん:02/04/16 20:55
>>306
クラス名を文字列化するのは typeid(T).name() で出来るし。別に面白くもなんとも。

312 :303:02/04/16 21:15
で…どんなかんじ?
神。


313 :296=306:02/04/16 21:16
>>311
この例、面白くなーい?
残念だなー。

>>307
const char*なら、いけるんじゃない?
もしくはコンパイラが自動的にFactoryを作ってくれるというのも
面白いかも。
というかTypeListで作れるか。あはははは。

314 :デフォルトの名無しさん:02/04/16 21:27
>>313
つくって。


315 : :02/04/16 21:29
>>309
>(そういや Boost に Loki 入れようという話、どうなってる?)
って初耳なんだけど、本当なの?
誰か情報キボンヌ

316 :デフォルトの名無しさん:02/04/16 23:27
ちょっと考えてみましたけども、sizeof(クラス)と、
そのクラスのコンストラクタのアドレスがわかれば、
実行時にダイナミックにクラスの作成できるかな?

実装依存(コンパイラ依存)なら書けるでしょうか?

317 :デフォルトの名無しさん:02/04/16 23:32
LLが入りそうってのはどっかで見聞きしたなぁ。


318 :デフォルトの名無しさん:02/04/16 23:49
>>315
Boost の開発者 ML で議論してる。スレッド長いから追ってないけど
Andrei Alexandrescu も話に参加してる模様。

(メールアドレスが @hotmail.com だけど)

319 :デフォルトの名無しさん:02/04/17 00:07
>>316
実装依存って言ったらそれこそなんでもありやん

320 :デフォルトの名無しさん:02/04/17 00:13
>>319
そそ、ダイナミックにソース作って、コンパイラ起動して、できたプログ
ラムに制御渡しゃどんなクラスでもできるぞ。

321 :315:02/04/17 00:27
>>318
boost-dev(?) の ML 読んでんの?すげー。
所詮俺は厨房である事を再確認した・・・
cppmlぐらいなら分かるんだけどさすがにそんなところ
まで手は伸ばせんわ・・・

独り言sage

322 :デフォルトの名無しさん:02/04/17 01:13
>>321
> boost-dev(?) の ML 読んでんの?すげー。
全部は追ってないし、開発にも参加してない。必要そうなヤツだけ斜め読み
だよ。(C++ は仕事道具だし)

Boost -- Boost mailing list
http://lists.boost.org/mailman/listinfo.cgi/boost

> cppmlぐらいなら分かるんだけどさすがにそんなところ
cppml ではなくて cppll かしらん?

俺は cppll は最初は読んでたんだが、エピスが検定試験云々言い始めた頃に
S/N 比が許容値を下回ったので切った。最近はどうなん?>読んでる人

323 :デフォルトの名無しさん:02/04/17 01:19
>>322
cppIIは今も取ってるが未読が1253通(藁
全然読んでないよ。
エピス氏はコード出して技術的な話をしているうちはいいが、
取り巻きも含めて雑談モードに入るとうるさいからな。

重鎮扱いで誰もつっこめないし。

324 :デフォルトの名無しさん:02/04/17 01:28
>>323
俺も彼の言語感覚についていけないクチだね…
自動で s/ぢ/じ/g してから読めば少しはマシになるかな(w


325 :デフォルトの名無しさん:02/04/17 01:33
うむ。
10代、せめて20代前半ならまだ許せるが、
某本で素顔の写真見ちゃったからなぁ・・・

326 :デフォルトの名無しさん:02/04/17 01:34
あの写真はショックだったという人
わりといますね。典型的な(略)


327 :デフォルトの名無しさん:02/04/17 02:01
だれかvcppかcppIIでエピス当てにうざいってレス付けてくれないか。
漏れは怖くてできない

電柱○家
Tit○w
あ○る

あたりが突っ込んできそうだな。
「いきなり出てきてあんたの方が役に立ってない」とかいいながら。

328 :デフォルトの名無しさん:02/04/17 14:10
すとーるまんみたいな感じ?

329 :デフォルトの名無しさん:02/04/17 15:34
全然。


330 :デフォルトの名無しさん:02/04/17 15:39
テンプレートと
http://www.csg.is.titech.ac.jp/~chiba/opencxx/html/index.html
これとの組合せでたのしいことになったりしませんか?


331 :デフォルトの名無しさん:02/04/17 15:45
>>330
なにこれ?

332 :デフォルトの名無しさん:02/04/17 15:48
C++でリフレクションが使えるようになる(前)処理系


333 :デフォルトの名無しさん:02/04/17 21:10
>>322
あのMLでは「低いS/Nの中からいかに情報を取り出すか」というのも重要なテーマです(藁
うまいフィルタ作れないかな。もちろんcppで。

334 :デフォルトの名無しさん:02/04/17 21:45
C++ Builderってバージョンあがってもう少し使えるようになるかと思ったら
テンプレート周辺にバグがあるんでしょ?がっかり。
しっかりしてくれよ、Borland。期待してるんだから。Pascal以外の言語もがんばってくれよ。

335 :デフォルトの名無しさん:02/04/17 21:47
>>334
えっ?初耳。ソースはどこかにありますか?教えて下さい

336 :デフォルトの名無しさん:02/04/18 01:57
>>333
struct pr : public std::binary_function< string, string, bool>{
bool operator()(const string& x, const string& y)const{
return search(x.begin(), x.end(), y.begin(), y.end()) != x.end();
}
};

vector<string> articles;
・・・

articles.erase(remove_if(articles.begin(), articles.end(), bind2nd(pr(), "ぢ")), articles.end());
articles.erase(remove_if(articles.begin(), articles.end(), bind2nd(pr(), "ちう")), articles.end());

337 :デフォルトの名無しさん:02/04/18 02:12
いっそのこと、
articles.erase(remove_if(articles.begin(), articles.end(), bind2nd(pr(), "FUKUDA Fumiki")), articles.end());
で。



338 :デフォルトの名無しさん:02/04/19 13:43
>>334
えっ?猫耳。


339 :デフォルトの名無しさん:02/04/21 22:28
>>338
えっ?愛猫。

340 :デフォルトの名無しさん:02/04/21 22:50
>338-339
つまんねーよきみら

341 :デフォルトの名無しさん:02/04/22 00:15
http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html

すごい!!

342 :デフォルトの名無しさん:02/04/22 01:04
VC7へぼい・・

template<class T> void swap(T& x, T& y) {}
template<class T> void swap(vector<T>& x, vector<T>& y) {}

これコンパイル通らないんだよね・・
プログラミング言語C++ではこういう書き方してるのに。

343 :デフォルトの名無しさん:02/04/22 10:24
>>342
using namespace std; を外して、std::vector にしてごらん。

344 :デフォルトの名無しさん:02/04/22 15:47
あげげ

345 :デフォルトの名無しさん:02/04/22 16:04
おまえらに質問。

最近関数オブジェクトがおもしろくてしょうがないんだけど、
引数がいっぱいあるメンバ関数をもつクラス T があるとして、
std::vector<T> t(100);
std::for_each(t.begin(), t.end(), &T:func);
みたいなのを引数渡ししつつぐるぐるやる方法はないかな。
mem_funcだとうまく引数が渡せないので、引数をなんとかする
関数オブジェクトをいっこつくってぐるぐるするしかないと思うんだけど、
いざコードを書こうとするとかっこわるくていかんのです。



346 :デフォルトの名無しさん:02/04/22 16:08
どっちかというとSTLスレで聞くべきだった。
sage鬱



347 :デフォルトの名無しさん:02/04/22 16:18
>>345
boost::bindとboost::mem_funとかで出来るんじゃないか?

348 :デフォルトの名無しさん:02/04/22 17:27
>>347
たとえば引数が三つあるメンバ関数を考えたとき、
すべての引数に値を渡せるかな?



349 :デフォルトの名無しさん:02/04/22 17:35
>>348
3つのうち2つが固定なら出来るんじゃないか?

350 :デフォルトの名無しさん:02/04/22 19:48
>>349
ふむ。ちと試してみるよ。
ありがとん



351 :デフォルトの名無しさん:02/04/22 23:34
>>343

template<T> void swap(T& x, T& y) {}
template<T> void swap(Class<T>& x, Class<T>& y) {}

2個のオーバーロード関数があいまいで最適な変換ができません。

STLソースではこうなってる模様
template<class T> Class {
public:
friend void swap(Class& x, Class& y) {}
};

でもこれでは既に他の名前空間にあるswapを特殊化できない罠。
なんかおかしくない?
おかしいのは漏れ?

352 :デフォルトの名無しさん:02/04/23 00:12
>>351
たぶん、キミがおかしい。
VC7 のことはよくわからんけど、ふつう swap は <algorithm> の中で
次のように定義されているはず:
namespace std{
template<class T> inline void swap(T& x, T& y) { … }
}
で、何か標準ヘッダーをインクルードして、using namespace std;
してるでしょ? それで、1行目の swap とバッティングしてるんだと
思うけど。
ちなみに、2行目の swap は関係ない。それを外してもエラーが出るん
じゃない?

353 :デフォルトの名無しさん:02/04/23 00:19
お手軽だからって
using namespace std はやめよーよ。


354 :デフォルトの名無しさん:02/04/23 01:08
>>352
例が悪かった・・
swapじゃなくてなんでもいいです。
とにかくテンプレート関数をクラステンプレートで特殊化しようとすると
特殊化優先順位で弾かれる。
名前空間とは関係ない問題です。(これが後々関係してくるが)

355 :デフォルトの名無しさん:02/04/23 01:18
具体例を書くよ

template<class T> class Class {};
template<class T> void func(T& x, T& y) {}
template<class T> void func(Class<T>& x, Class<T>& y) {}

void main() {
Class<int> x, y;
func(x, y);
}

error C2667: 'func' : 2 個のオーバーロード関数があいまいで最適な変換ができません。

で、

template<class T> class Class {
public:
friend void func(Class& x, Class& y) {}
};
template<class T> void func(T& x, T& y) {}

これならOK。VC7のSTLもこのパターンで実装されてる。
でも例えばfuncとClassが違う名前空間にあると
このパターンは成り立たない。色々試したがダメだった。
具体的にはstd::swapなんかを
自作のテンプレートクラスで特殊化しようとした場合なんかに
困るわけなんだな、これが。

356 :デフォルトの名無しさん:02/04/23 02:09
なんか、テンプレートでいくらがんばっても
あんまり実りが無い感じ。

357 :デフォルトの名無しさん:02/04/23 02:39
>>355
前半部分、13.5.1(p.404) によって後者が選ばれなきゃいけない話?
gcc 2.95ではちゃんと選ばれたよ。

358 :デフォルトの名無しさん:02/04/23 10:39
>>357
C++の本を見る限りではそのgccの動作が正しいと思うんだけど。
VC7では選ばれる以前にコンパイルエラーになる。
多分、テンプレート関数とクラステンプレートで特殊化したテンプレート関数の
特殊化優先順位が等しいからこんなことになる。
これだったらすぐ直りそうなもんだからSPで直してほしい・・

359 :デフォルトの名無しさん:02/04/23 12:34
メーカーの製品がこの程度の品質って、
C++のテンプレートの仕様を把握するのが一苦労って事なのかな?

360 :デフォルトの名無しさん:02/04/23 13:12
上記の話、VC6でも確認。前からああみたいだ。

違う名前空間の関数を特殊化するなという意味だろうか。
Javaみたく階層的に名前空間分けてたら
同一プロジェクトでも同じ問題が発生するが・・
共通関数を使わずメンバ関数を使えという話になるんだろうけど
それだとSTLのうまみも半減だわな

ところでクラステンプレートをクラステンプレートで特殊化って
C++的に可能なの?VCではダメだった。

361 :デフォルトの名無しさん:02/04/23 13:36
gccは3.0になってからその辺の構文的な要素は完全対応してるのかな?

362 :デフォルトの名無しさん:02/04/23 14:44
>>355
Borland-C++ 5.6では正しくコンパイルできますた。

363 :デフォルトの名無しさん:02/04/24 18:46
SDLがブレーク? フン、しねーよ。少なくともあなたには必要ないと思われ。


364 :デフォルトの名無しさん:02/04/26 15:16
age



365 :デフォルトの名無しさん:02/04/29 13:56
Lokiマンセー!!!
でDLしたらVC.NETじゃコンパイルできねージャン!!
氏ねMS!IDEばっか凝ってねーでコンパイラ改良しる!

366 :デフォルトの名無しさん:02/04/29 19:08

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄」
―――――――――――――‐┬┘
                        |
       ____.____    |
     |        |        |   |
     |        | ∧_∧ |   | C++を窓から投げ捨てろ
     |        |( ´∀`)つ ミ | 
     |        |/ ⊃  ノ |   | C++
        ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄    |    




--------------------------------------------

367 :デフォルトの名無しさん :02/04/30 06:09
>>365
そもそもMSがcl.exeをANSIに完全対応させる気がないのだとしたら
どういう事態になるんだろう。

368 :デフォルトの名無しさん:02/04/30 06:24
ANSIが規格をねじ曲げれば一件落着。

369 :デフォルトの名無しさん:02/04/30 22:06
関数ポインタの配列とenumの関係で質問です。

enum {HOGE,MOGE,MONA,SAGE};
void hoge(void);
void moge(void);
void mona(void);
void sage(void);

typedef void (*FUNC)(void);
FUNC func[] = {hoge,moge,mona,sage};

こんな感じで、HOGEのときはhogeを呼ぶ、みたいに対応させてます。
このとき、enumの順番を変えたら、それに応じてfunc内の関数順番を
手動で変えるのがわずらわしいのです(enumとfuncは別ファイルです。
includeして、見えるようにはなってますけど)。
enumの順番に沿って、対応する関数がfunc内で自働的に並んでいて欲しいのです。
コンパイル時点では順番は確定しているんですから、テンプレートを
ごりごり使いこなせる人間ならできるんじゃないかと淡い期待を
持ってるんですが、どうにかして出来ませんでしょうか?

370 :デフォルトの名無しさん:02/04/30 22:12
無理
不可能

371 :デフォルトの名無しさん:02/04/30 22:12
>>369
なぜ順番を変えようとする?

372 :デフォルトの名無しさん:02/04/30 22:14
数が多いなら、excelのシートに関数名とenum識別子をかいといて
VBAかなにかでボタン一個でソース吐くようにしとけば?

俺だけかもしらんが、よくやってるよ。

その場限りならセルに文字列適当に連結する式かいてコピペ、とかもやるし。


373 :デフォルトの名無しさん:02/04/30 22:16
なぜ順番を変えるのかは突っ込まないで置こう。
見栄えが気にくわなくてあっち入れ替えたりこっち動かしたりする時期があるもんさ。


374 :デフォルトの名無しさん:02/04/30 22:21
perlスクリプトで自動で吐くようにすればいいやん

375 :デフォルトの名無しさん:02/04/30 22:32
ちょっと面倒だけど、こんなん駄目?

#include "stdafx.h"

template< int > struct Function{};
#define DEF_FUNC( index, func ) template<> struct Function<index>{ \
static void call(void){ func(); } }

enum {HOGE,HAGE,};
void hoge(){puts("hoge");}
void hage(){puts("hage");}

DEF_FUNC( HOGE, hoge );
DEF_FUNC( HAGE, hage );

int main(int argc, char* argv[])
{
Function<HOGE>::call();
Function<HAGE>::call();
return 0;
}


376 :375:02/04/30 22:35
ガーン!
今頃気づいたけど、呼び出し時のインデックスはコンパイル時には確定してないのか・・・じゃ駄目だ。

377 :375:02/04/30 22:45
上のを修正。
ちょっとオーバーヘッドがあるけど、
(テンプレートクラス内のcallをfuncへのポインタに出来ればいいんだろうけど、俺はやり方知らない。)

void (*funcs[])(void) = {
Function<HOGE>::call,
Function<HAGE>::call
};

int main(int argc, char* argv[])
{
for( int index = HOGE; index<=HAGE; ++index )
{
funcs[index]();
}
return 0;
}

378 :デフォルトの名無しさん:02/04/30 22:51
> void (*funcs[])(void) = {
> Function<HOGE>::call,
> Function<HAGE>::call
> };

それだと結局、enumを
 enum {HAGE,HOGE,};
に変えられたときにマズーではないか?

379 :375:02/04/30 22:51
ぐわぁ!
やっちまった(藁

380 :デフォルトの名無しさん:02/04/30 22:51
>>375-377
ちょっとなぁ、という気がする。
自分が書くにはいいが、人には見せられない。

そもそも、見栄えを気にする(順番を入れ替える)んだから、
その書き方はいいとは思えない

381 :375:02/04/30 22:52
>>380
つーか普通はこんなことしねぇって。

382 :375:02/04/30 22:57
こら待て、今気づいたんだが、375でいいじゃねぇかよ。
enum値と対応させるってことは配列のインデックスは手打ちでenumの値を書くってことだろ?
インデックスが実行時に決まるならenumに対応させる意味もないし。

383 :デフォルトの名無しさん:02/04/30 23:00
enum {
 HAGE,
 HOGE,
};

template<int i>
void f();

template<>
void f<HAGE>()
{
 return;
}

void f<HOGE>()
{
 return;
}

void (*func[])() = {
 f<HAGE>,
 f<HOGE>,
};



384 :デフォルトの名無しさん:02/04/30 23:00
あ、ダメやん・・・(鬱

385 :369:02/04/30 23:02
Modern C++ のInt2Typeとかをみてると、なーんかできそうな気がしてくるんですよねー。
どうやればいいのかはさっぱり分かりませんけど。

>>382
いや、呼び出すときは (*func[n])() ですが…。
対応させる意味がない…? えーと。考えます。

386 :デフォルトの名無しさん:02/04/30 23:04
おいおい、じつはCOMだから関数の順序が....とかなんとか理由つけてくれよ

387 :デフォルトの名無しさん:02/04/30 23:05
>>385
テーブルを動的に作るのはだめなん?

388 :デフォルトの名無しさん:02/04/30 23:07
>>387
俺もそう思う。

389 :369:02/04/30 23:15
えーとですね。ふたつの実行ファイルが、enum値に依存してるわけなんです。
エンコーダとデコーダを作ってまして。
エンコーダは、テキストの文字列 "hoge" "hage"を読み込んで、
バイナリでenum値「HOGE,HAGE」を吐きます。んで、
デコーダは、バイナリでHOGE,HAGEをみて、関数hoge(),hage()を呼ぶ、と。
そういう状況です。

>>テーブルを動的に
いや、いいんですけど。でも、静的に解決できることじゃないですか。
出来たらかっこいいじゃないですか。そういうスレじゃないですか、ここは。

390 :デフォルトの名無しさん:02/04/30 23:19
>>389
もし出来たとしても決してかっこよくはならないと思うぞ。

391 :デフォルトの名無しさん:02/04/30 23:27
#include <iostream>
using std::cout;
using std::endl;

enum {SAGE,MONA,MOGE,HOGE, END}; // ←ここ順番変えてよし!
typedef void (*FUNC)();
void hoge() { cout<<"hoge"<<endl; }
void moge() { cout<<"moge"<<endl; }
void mona() { cout<<"mona"<<endl; }
void sage() { cout<<"sage"<<endl; }

template<int> inline void f() {}
#define ASSOC_FUNC(E,F) template<> inline void f<E>() { F(); }
ASSOC_FUNC(HOGE,hoge)
ASSOC_FUNC(MOGE,moge)
ASSOC_FUNC(MONA,mona)
ASSOC_FUNC(SAGE,sage)
FUNC func[] = { f<0>, f<1>, f<2>, f<3> };

int main()
{
for( int i=0; i<END; ++i )
func[i]();
return 0;
}

…と思ったんだけど、関数ポインタ経由だからinline展開されないよなぁ、これ…。

392 :デフォルトの名無しさん:02/04/30 23:39
文字列からenum値に変換するのか?
それだったら、
std::map<std::string, void(*)()> m;
m["hoge"] = hoge;
これでいいじゃん。

393 :デフォルトの名無しさん:02/04/30 23:44
文字列->定数で解決したいんだろう

試みとしてはおもしろいかな。
でも、おれの知識じゃまだ無理だなあ。
Modern もっとよむか

394 :デフォルトの名無しさん:02/04/30 23:49
なんかみんな無理してるよね(w
それがもの凄く伝わってくるスレ

395 :デフォルトの名無しさん:02/04/30 23:50
>>391
改造してみた、本末転倒?

#include <iostream>
using std::cout;
using std::endl;

enum {SAGE,MONA,MOGE,HOGE, END}; // ←ここ順番変えてよし!
#define sage f<SAGE>
#define mona f<MONA>
#define moge f<MOGE>
#define hoge f<HOGE>

typedef void (*FUNC)();
template<int> void f() {}
template<> void sage(){cout<<"sage"<<endl;}
template<> void mona(){cout<<"mona"<<endl;}
template<> void moge(){cout<<"moge"<<endl;}
template<> void hoge(){cout<<"hoge"<<endl;}

FUNC func[] = { f<0>, f<1>, f<2>, f<3> };

int main()
{
for( int i=0; i<END; ++i )
func[i]();
return 0;
}

396 :デフォルトの名無しさん:02/04/30 23:53
>>395
全然かっこよくないぞ

397 :デフォルトの名無しさん:02/04/30 23:54
もはやかっこよさなんてどうでもいい罠

398 :369:02/05/01 00:01
かっこよさ以前に、ちゃんと動作してくれないんですが…。VCのせい?

399 :デフォルトの名無しさん:02/05/01 00:01
>>396
Modern(の前半)読んでかっこいいと思ったか?
俺は、すげぇとは思ったがかっこいいとは思わなかったよ(むしろ汚い)。
このスレで今やってることも同じようなもんさ。
おとなしく動的作成にしない389が悪い。

400 :デフォルトの名無しさん:02/05/01 00:03
>>398
#include "stdafx.h"
をソースファイルの先頭に入れ忘れてるとか。

401 :デフォルトの名無しさん:02/05/01 00:07
関数テンプレートのテンプレートパラメータに定数を使うのは、
VCだとバグのせいでうまくいかなかったはず。
たしか、すべて同一の実体を指すようになってたような。

402 :デフォルトの名無しさん:02/05/01 00:09
そういえばそうだったな。
他のに乗り換えれ。

403 :デフォルトの名無しさん:02/05/01 00:10
#include <iostream>

template <int i> void func()
{
 std::cout << i << std::endl;
}

int main()
{
 func<0>();
 func<1>();
 return 0;
}

これをコンパイルしてみればわかる

404 :デフォルトの名無しさん:02/05/01 00:12
結局、VC(6以下)使ってる限りは無理って結論でよろしいか?

405 :369:02/05/01 00:15
両方とも 1 が出力されました…。 (T_T)

406 :デフォルトの名無しさん:02/05/01 00:16
関数テンプレートにせずに、クラステンプレートにすればいいやん。

template<int i> class func {
public:
 func() {
  std::cout << i << std::endl;
 }
};

407 :デフォルトの名無しさん:02/05/01 00:17
すげー見にくくなってきたな・・・

408 :369:02/05/01 00:24
たしかにクラステンプレートならVCでもいける…。
で、あとは391と組み合わせれば…?

409 :369:02/05/01 00:33
コンパイルが通らない…。(T_T)
どうすれば…。

410 :デフォルトの名無しさん:02/05/01 00:41
>>409
ヒント

enum {
 HAGE,
 HOGE,
};

class FuncBase {
public:
 virtual void operator()() { }
};

template<int i> class FuncObj;

template<>
class FuncObj<HAGE> : public FuncBase {
public: void operator()() {
   std::cout << "hage" << std::endl;
  }
} hage;

template<>
class FuncObj<HOGE> : public FuncBase {
public: void operator()() {
   std::cout << "hoge" << std::endl;
  }
} hoge;

FuncBase* func[] = {
 &hage,
 &hoge,
};

int main()
{
 (*func[HOGE])();
 (*func[HAGE])();
 return 0;
}

テーブルに登録するところをいじってくれ

411 :デフォルトの名無しさん:02/05/01 00:41
正直、>>410みたいにしてまでコンパイル時に決定したいとは思わないが。

412 :デフォルトの名無しさん:02/05/01 00:44
とりあえずなんでもかんでも関数オブジェクトにしちまうか....
最悪だな

413 :デフォルトの名無しさん:02/05/01 00:45
はっきりいって、ここまでしてやることじゃないと思う

414 :デフォルトの名無しさん:02/05/01 00:47
やっぱり、動的にテーブルを作るのが一番って事で、

********************** 終了 ************************

415 :369:02/05/01 12:24
出来ました!
>>395にはかないませんけど、>>391より効率よく、なおかつVC6でも動きます。

#include <iostream>
using namespace std;

enum{HOGE,MOGE,HAGE,SAGE};// ←順番は任意に入れ替え可能
void hoge(void){cout<<"hoge"<<endl;}
void sage(void){cout<<"sage"<<endl;}
void moge(void){cout<<"moge"<<endl;}
void hage(void){cout<<"hage"<<endl;}

typedef void (*FUNC)(void);

template<int v>
struct f{
static FUNC f_;
};
#define ASSOC_FUNC(A,B) template<> FUNC f<A>::f_ = B;
ASSOC_FUNC(HOGE,hoge)
ASSOC_FUNC(HAGE,hage)
ASSOC_FUNC(SAGE,sage)
ASSOC_FUNC(MOGE,moge)
#undef ASSOC_FUNC

FUNC funcTable[4] = {f<0>::f_ ,f<1>::f_ ,f<2>::f_ ,f<3>::f_ };

int main(int argc, char* argv[])
{
for (int i=0;i<4;++i)
(funcTable[i])();
return 0;
}


416 :デフォルトの名無しさん:02/05/01 12:51
初期状態よりも何倍も汚くなっている罠

417 :デフォルトの名無しさん:02/05/01 13:05
まさに自己満足以外の何者でもない

418 :デフォルトの名無しさん:02/05/01 14:26
プログラムの半分は自己満足で出来ています。

419 :デフォルトの名無しさん:02/05/01 16:19
自己満足っつーか、ひとりよがり、って感じ。

420 :369:02/05/01 19:36
うえーん、一生懸命考えたのに、ボロクソ言われてるよー
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
            ∧_∧
          ( ´Д⊂ヽ
          ⊂    ノ
           人  Y
          し (_)


(´-`).。oO(っていうか、考えついたのが満足であって、>>415を使ったりはしないけどね…)
(´-`).。oO(.NETなら>>395を使えるのかしら?)

421 :デフォルトの名無しさん:02/05/01 20:44
とりあえず、よくやった。
でも誰も使うことはないだろう。


422 :デフォルトの名無しさん:02/05/01 22:15
筋トレと同じ。
これが実戦と同じだと勘違いしたら問題だが、
こういう鍛え方でしか鍛えられないことはある。
どんどんやるべきだと思うよ。

423 :デフォルトの名無しさん:02/05/01 22:28
見せるため、自己満足のための筋トレと
運動するための筋トレはまったく別物。

鍛え方を間違っちゃいかん。


424 :デフォルトの名無しさん:02/05/02 09:52
八頭身の予感 age



425 :369:02/05/02 14:25
ポリシーやらファンクタやらを勉強ししてて、ふとこんな構文が
通ることに気付いてしまいました。

#include <iostream>
using namespace std;

class Hoge
{
public:
void operator()(void){cout<<"hoge"<<endl;}
};

int main(){
Hoge()();// ←なんと奇怪な構文!
return 0;
}

…うわー。これ、ホントに通っていいんですか? まあ、理屈には合ってますけど…。
(最初のカッコでHogeのデフォルトコンストラクタでテンポラリインスタンスを生成。
次のカッコでHogeのoperator()を呼び出す)

VCだけじゃないことを祈りまふ…。

ちとスレ違いかな。sage.


426 :デフォルトの名無しさん:02/05/02 14:31
>>425
それ、普通だが?
文が完了するまで一時オブジェクトの寿命が続くはず。
Hoge(), foo(), bar();
こうすると、bar()の後にHogeのデストラクタが呼ばれる


427 :369:02/05/02 19:36
いや、奇怪だっつーてるのは、カッコが連続してることです。
コンストラクタやoperator()の引数次第で、関数宣言だとか
関数ポインタだとか、そのあたりと間違えてしまいそうな構文だなーと。

428 :デフォルトの名無しさん:02/05/02 20:18
関数オブジェクトを作り始めれば、別に不思議に思わなくなるよ。


429 :デフォルトの名無しさん:02/05/02 20:49
>>425
struct Hoge { Hoge& operator()(void){return *this;} };
int main() {
  Hoge()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()();
}
…はともかくとして、何の変哲もないふつうの構文だと思うよ。

> 関数宣言だとか関数ポインタだとか、そのあたりと間違えてしまいそうな構文
引数付きのコンストラクタを呼び出したりする時に、
下手すると関数宣言扱いになっちまうことはあり。
Effective STLとか参照。

430 :デフォルトの名無しさん:02/05/03 03:37
>>425
それ、Cでも通らん?

#include<stdio.h>

typedef void (*fp)(void);
typedef fp (*fpp)(void);

void hogegege(void)
{
printf("\nhogegege\n");
return;
}

fp hogege(void)
{
printf("\nhogege\n");
return(hogegege);
}

fpp hoge(void)
{
printf("\nhoge\n");
return(hogege);
}

int main (int argc, char argv[])
{
hoge()()();
return(0);
}

----
/tmp>gcc hoge.c
/tmp>./a.out

hoge

hogege

hogegege
/tmp>


431 :デフォルトの名無しさん:02/05/03 03:50
>>430の登場によって、>>425のささやかな期待は、崩れ去ろうとしている。
しかしそれはC++信望崩壊への、ほんの序曲でしかなかった──────。

425「げ、良く考えたらどれもこれも、Cで作れるじゃん!」
430「それ、Cでも通らん?」
413「はっきりいって、ここまでしてやることじゃないと思う」
426「それ、普通だが?」
425「し、Cマンセー!C++なんてクソ。これ定説!」

だれかprojクトX風に仕立ててくれ。

432 :デフォルトの名無しさん:02/05/03 07:59
                 ( ̄ ̄<     / ̄>
                  \  ヽ   / /ソ
        プ ロ ジ ェ ク ト\  ヽ P r o j e c t X
   ─────────────────────
         Generatorたち /|_/ /\Generators
                 |   /   \   丶
                 \/       \__ノ
Genericスレッド。
このスレで425は一人で悩んでいた。なぜこんな構文が許されるのかと。
「いや、関数オブジェクトでは当たり前だ。」
「こんな物は普通だ。」
次々とヤジが飛ぶ。へこんだ。
万策尽き果てたとき、ふと430が現れる。
「Cでも出来るんじゃないか?」
これは、C++に翻弄された男たちの物語である。

風の中のスバル〜♪

433 :デフォルトの名無しさん:02/05/03 10:01
まぁ変な書き方とかは狙えばいくらでもできるからね

1+-+-+-+-+-+-+-+1 とか

434 :デフォルトの名無しさん:02/05/03 17:44
ぜんぜんgenericじゃない。


435 :425:02/05/04 23:29
>>431
一応、マジフォロー。

 Hoge()()()

がCでも関数ポインタを使えば構文上は通るとは言っても、
もちろん単なる関数ポインタと関数オブジェクトでは意味合いは大分違う。

たとえば、ベキ級数アルゴリズムを抽象化したクラスを考える:

class PowerSeries {
private:
int n;
double* coef;

public:
PowerSeries(double* coefficients, int number_of_coefficients)
n(number_of_coefficients), coef(coefficients){;}

double operator(double x){
double rst = coef[n];
for(int i = n - 1; n >= 0; i--){
rst *= x;
rst += coef[i];
}

return (rst);
}

};

このように関数オブジェクトではコード(級数計算アルゴリズム)に対して
それをカスタマイズするようなデータ(係数データ)を付加することができるが、
関数ポインタではできない。

この例は一種のCurry化であるが、一般にこのようなことを記述するには
「データを付加できる関数ポインタのようなもの」が必要になる。
もし高階関数型言語ならば、関数を返り値として関数クロージャーを利用すれば、
クロージャーにこのようなデータを記録できるが、C/C++には
高階関数がないので関数オブジェクトが必要となる。
Genericプログラムにおける関数オブジェクトの効用もそこにある。

436 :430:02/05/04 23:31
>>435
スマン。名前間違えた。425じゃなくて430でした。
その上、間違えてageてるし・・・・・・。

437 :430:02/05/04 23:33
さらにミスが。やっぱコンパイラ通すのサボっちゃだめスカねぇ。

誤>double operator(double x){
正>double operator() (double x){

438 :デフォルトの名無しさん:02/05/04 23:35
でも、たとえばSTLのalgorithmに関数オブジェクトを渡すと、
コピーを渡すことになるのでクロージャのデータは破棄されることになる。

439 :430:02/05/04 23:38
うげ、さらにミスが。

誤>ベキ級数アルゴリズムを抽象化したクラス
正>ベキ級数を抽象化したクラス(評価にホーナーのアルゴリズムを使う)


440 :430:02/05/04 23:42
>>438
C/C++のオブジェクトの代入セマンティクスでは
デフォは参照じゃなくてコピーざんすからねぇ。
受け渡したいデータの性質と意味に応じてコピー・コンストラクタあたりで
なんとか頑張るしかないでしょうなぁ。

441 :430:02/05/04 23:44
>>440
参照カウントやGCライブラリを使うという選択もあるかもしれないけど。

442 :デフォルトの名無しさん:02/05/05 00:22
悩める愚者より識者にしつもーん

std::transformに渡す関数オブジェクトって副作用があっちゃダメってことですけど、
これの具体的な根拠ってどこにあって、
実際どういう不具合が考えられるのかわかりますか?

状態変数のようなものを内部に持てるのが関数オブジェクトのいいところだと
思っていたのですが、これはつまり、副作用を期待して呼び出す std::for_eachと
はちがって操作対象の変換(のみ)を純粋に扱うstd::transformが呼ぶ関数オブジェクト
は副作用があってはいけない、といういみでしょうか。

たとえば、
呼び出されるたびに内部カウンタをインクリメントした値を加算する変態加算関数オブジェクト
struct addinc : std::unary_function<int, int> {
addinc(int serial = 0) : serial_(serial) {}
int operator()(int n) { return n + serial++_; }
private:
int serial_;
};
みたいなのは、transformに対して使用するには不適切、ということでしょうか?

それとも関数オブジェクト呼び出しがconstかどうかが問題であって、
int operator()(intn)をconstメンバに、int serial_をmutableとかにしちゃえば
セマンティクス的にもOKというわけなんでしょうか?


443 :デフォルトの名無しさん:02/05/05 00:28
age

444 :デフォルトの名無しさん:02/05/05 00:44
>>442
> std::transformに渡す関数オブジェクトって副作用があっちゃダメってことですけど、
これ初耳なのだがどこに書いてあったん?

445 :デフォルトの名無しさん:02/05/05 01:04
標準テンプレートライブラリによるC++プログラミングの二版の22.16.3の最後に書いてあるんです。

今SGIのSTLのドキュメントを読みましたが、そんなことは書いてないですね。

446 :デフォルトの名無しさん:02/05/05 01:10
仕方なく英文のサイトを必死扱いて探してみたところ、

ttp://www.cuj.com/experts/1902/langer.htm?topic=experts
には
Requires: op shall not have any side effects
みたいなことが書いてありますね。

Effective STLかなにかにもtransformに渡すのは述語でなきゃいかん、みたいな
ことがあった気がします。(今手元にないので確認できません。)

447 :デフォルトの名無しさん:02/05/05 01:20
>>442
Effective STL 39項がそのものズバリの解説になっている気がする

448 :デフォルトの名無しさん:02/05/05 01:47
はうう、後で読み直してみます。
ありがとーございましし。

449 :430:02/05/05 03:24
手元にあるC++標準テンプレートライブラリをざっと読む限りだと:
この場合言われてる「副作用」は厳密な参照透明性
(、内部状態変数やグローバル変数への代入、入出力禁止とかを含む)
とかじゃなくて、与えられた引数(イテレータ)の指すオブジェクトを
書き換えてはイカンということなんじゃ?

450 :430:02/05/05 03:27
>>449
C++標準テンプレートライブラリ

The C++ Standard Template Library
(P.J.Plauger他著、)の邦訳(ピアソン・エデュケーション刊)ね。


451 :430:02/05/05 03:32
>>449
transformがじゃなくてオペレーターがね。>書き換え禁止

452 :デフォルトの名無しさん:02/05/05 15:05
>>449
そんな気がする。

Effective STL で取り上げられてたのは Item 37 の std::for_each と
std::accumerate の話じゃない? >>447

453 :447:02/05/05 23:36
>>452

チェックしてみたらご指摘の通りでした。すんません。

454 :442:02/05/06 00:26
ありがとうございましし。
>>449=430さんのおっしゃるような意味だと解釈しましし。


455 :デフォルトの名無しさん:02/05/07 04:41

Lokiの存在を知って以来VCでの開発が苦痛だ・・・

456 :デフォルトの名無しさん:02/05/07 04:50
>>455
マジで?
実際にLokiなんか使う場面あるか?

457 :デフォルトの名無しさん:02/05/07 04:55
>>456
俺様ライブラリを作るときとか。
Lokiのすべてとは言わないが、カスタマイズ可能なスマートポインタ(他)はホスィ・・・

458 :デフォルトの名無しさん:02/05/07 04:59
LokiはA.Alex.の壮大なネタだ

459 :デフォルトの名無しさん:02/05/07 05:08
Lokiって実用ライブラリじゃなくてストレステストでしょ
といってみるテスツ

460 :デフォルトの名無しさん:02/05/07 12:05
>456
SingletonHolderは使ってますが何か?


461 :デフォルトの名無しさん:02/05/09 22:44
誰か話題振れよう。 || (>>303 漏れにも教えて)



462 :デフォルトの名無しさん:02/05/09 22:54
どなたかallocator<>の使い方教えて下さい。難しすぎる・・・・・

463 :デフォルトの名無しさん:02/05/09 23:18
T型オブジェクトの配列のためのメモリ管理用テンプレート?
がんばれー

464 :デフォルトの名無しさん:02/05/09 23:19
T型オブジェクトの配列のためのメモリ管理用テンプレート?
がんばれー

465 :デフォルトの名無しさん:02/05/09 23:22
>>455
C#のテンプレートに期待しよう。

466 :デフォルトの名無しさん:02/05/09 23:23
>>465
あるの?テンプレート??

467 :デフォルトの名無しさん:02/05/09 23:26
>>458は名言だと思う。
というかほんとにそんな気がしてならない。死のう・・・


468 :デフォルトの名無しさん:02/05/10 00:00
あの人、コンパイラメーカーで働いてるの?

469 :デフォルトの名無しさん:02/05/10 01:30
学生ちゃうん?


470 :デフォルトの名無しさん:02/05/10 06:20
>>469
まじ?

471 :デフォルトの名無しさん:02/05/10 10:08
各コンパイラメーカーのテンプレートサポートが落ち着いてくれば
Lokiで使われているテクニックが次のスタンダードに導入されるだろう事は
まず間違い無いと思われ。

472 :デフォルトの名無しさん:02/05/10 10:12
>>471
一部は使われると思うが、使わないネタも多いんじゃないかなぁ……。

473 :デフォルトの名無しさん:02/05/10 10:39
TypeListは必須だな

474 :デフォルトの名無しさん:02/05/10 14:18
それはない

475 :デフォルトの名無しさん:02/05/10 15:18
>>474
あれ無しでどうしろと?

476 :デフォルトの名無しさん:02/05/10 15:32
どう考えても浸透しそうなのはポリシーのみ。
それ以外は実務で役立つかというと(?)

477 :デフォルトの名無しさん:02/05/10 16:32
a

478 :デフォルトの名無しさん:02/05/10 16:33
aa

479 :仕様書無しさん:02/05/10 16:50
aaa

480 :デフォルトの名無しさん:02/05/10 17:52
Typelistのとこで、58ページの下に、「コードに繰り返しを
含める事なく、配列を初期化することもできます」ってあるん
ですけど。これって、どうやるんですか?


481 :age:02/05/10 21:13
age.

482 :デフォルトの名無しさん:02/05/10 23:13
>>480
読んだ事ないけどstd::fill使うとか?

483 :デフォルトの名無しさん:02/05/10 23:30
>>482
fillじゃ無理っしょ。
単なるforループなんだから

484 :デフォルトの名無しさん:02/05/10 23:58
試しに繰り返しを使わず配列の初期化をやってみよう。
template <int i>
class A{
public:
template<typename T>
static inline void foo(T* p){ *p = 0; A<i-1>::foo(p+1); }
};

int x[10];
A<10>::foo(x);
これでどうだ。・・・あんまり意味なさげ。

485 :デフォルトの名無しさん:02/05/11 00:17
凄いソースだな、そう思うだろ?>>484

486 :485:02/05/11 00:22
>>485
お前、頭大丈夫か?

もうだめぽ・・・(-_- )

487 :デフォルトの名無しさん:02/05/11 00:41
>>484
最高だ!応用すればループがインライン展開されるfor_eachとか書けそう!


488 :デフォルトの名無しさん:02/05/11 00:48
>>487
http://www2.tky.3web.ne.jp/~bandai/24net/prog2/tips1.html

489 :デフォルトの名無しさん:02/05/11 01:38
>>487
だめだよ。大抵のコンパイラはtemplateの展開可能レベルが浅い。

490 :デフォルトの名無しさん:02/05/11 02:28
最近のコンパイラは最低限のunrollは行ってくれる
最近のCPUはunrollするとキャッシュのミスヒットでパフォーマンスが低下する

491 :デフォルトの名無しさん:02/05/11 05:44
>>490
unrollする量でチューニング。
テンプレートを利用した行列計算でメモリ階層を意識して
ブロック化、ループ展開などの最適化を施した例としてMTLがある。

492 :480:02/05/11 09:55
>>484
いや、Typelistのとこでの話なんですから、コンパイル時に初期化が
終わるんじゃないかと。
このやり方だと、実行時に初期化してますよね。

493 :480:02/05/11 10:21
この58ページの雰囲気的には、

std::type_info* intsRtti[Length<SignedIntegrals>::value] =
{
 TypeAt<SignedIntegrals,0>::Result,
 TypeAt<SignedIntegrals,1>::Result,
 TypeAt<SignedIntegrals,2>::Result,
 TypeAt<SignedIntegrals,3>::Result,
 // Lengthの示す長さ分だけ続ける…
}

これを、コンパイル時に自働的に解決するための汎用性のある書き方が存在する、
ってことだと思うんですよ。

…どうすりゃいいんでしょうね。

494 :デフォルトの名無しさん:02/05/11 12:20
配列の要素が静的に初期化できる構文といえば

double a[3] = {1.0 ,2.0 ,3.0};

だが。テンプレートから生成できるとは思えんしなー。
まさか、

template<class T, int N>
struct A
{
T d = T(N)/*constant expression of N*/;
A<T, N-1> succ;
};

template<class T>
struct A<T,1>
{
T d = T(1)/* constant expression */;
};

template<class T, int N>
const T* getArray(const Struct<T,N> s)
{
return((T*)(&s))
}

なんてこたないよな。
仮想メンバ関数もなく継承とかもしてないstructはCの構造体と互換だが……。
移植性あるか?(alignment調整のpackingとか。)

495 :494:02/05/11 12:21
>>494
今、手元にコンパイラがないんで未テスト。スマソ。

496 :494:02/05/11 12:23
>>494
ごめん。packing -> padding

497 :494:02/05/11 21:04
//さすがに動かなかったよ。

#include<iostream.h>

template<int N>
struct Init
{
static const double data = Init<N-1>::data * double(N);
static const Init<N-1> succ;
};

template<>
struct Init<1>
{
static const double data = 1.0;
};

template<int N>
inline const double* getArray(const Init<N> a)
{
return((double*)(&(a)));
}

Init<5> init;
const double* a = getArray(init);

int main(int Argc, char* Argv[])
{
cout << "\n";

for(int i = 0; i < 5; i++)
{
cout << " " << a[i];
}

cout << "\n";

cout << init.data << " ";
cout << init.succ.data << " ";
cout << init.succ.succ.data << " ";
cout << init.succ.succ.succ.data << " ";
cout << init.succ.succ.succ.succ.data << " ";

cout << "\n";

return(0);
}


498 :494:02/05/11 21:07
>>497↑はコンパイルは通るけど結果は思ったようにならない。
結果:

4.85246e-270 2.96439e-323 5.08888e-322 1.58101e-322 4.85634e-270
120 24 6 2 1

ある意味ホっとした。

499 :デフォルトの名無しさん:02/05/11 22:12
>>497
・・・えーとさぁ。突っ込んでいいかなあ?

> return((double*)(&(a)));
ここでアドレス取ってるけど、これって getArray の引数 a のアドレスだよなぁ?
getArray の引数 a は getArray の終了時にスタックから消滅してるから、
そのアドレスを戻り値として返すのは不正なんじゃなかろうか。

それと、Init<5> の非スタティックメンバって何もないから、
sizeof(Init<5>) = 0 (あるいは 1)のはずで、
それを double にキャストして逆参照してもゴミ値なんじゃないの?

500 :494:02/05/11 23:41
>>499
そうすね。頭寝てました。

501 :デフォルトの名無しさん:02/05/12 15:31
std::iterator_traits<int*>::value_type val;

C++スレに書かれてたやつだけど、なんかこっちのほうがふさわしそうなんでこっち持ってきた。
VC++6でコンパイルエラーだそうです。

VC++.NETでコンパイルしたら

> xutility(98): error C2825: '_Iter::iterator_category': 限定名を形成できません。
> xutility(98): error C2039: 'iterator_category' : 'operator``global namespace''' のメンバではありません。
> xutility(98): fatal error C1507: エラーが多すぎてコンパイルを継続できません。

って言われた。
ツールチップの型ヒントではちゃんとintのtypedefになってるんだけど、
なぜコンパイルできないんでしょう?

502 :デフォルトの名無しさん:02/05/14 06:09
>>501
そのソース、g++とかだと通るの?

503 :デフォルトの名無しさん:02/05/14 10:08
>>502
501じゃないけど、g++ならふつうに通るみたいだよ。

504 :501:02/05/15 10:32
調べてみました、VC++のコンパイラの能力ではiterator_traitsをポインタに対して特殊化することが出来ないんですね。
そのため特殊化されていない形式のiterator_traitsを構築しようとしてコンパイルエラーが出ているようでした。
STLのソースの中でもiterator_traitsはほとんど使用されていませんでした。
Genericの中に書かれている古いタイプの方法に近い形で実装されているようです。

505 :デフォルトの名無しさん:02/05/15 12:07
ああ、まだ上には上がいるんだな。
勉強が足りなかった。

506 :デフォルトの名無しさん:02/05/15 15:37
>>303
これってどういう意味? 8章を読んだけど全く理解できなかったってこと?
それとも、全部理解したけど期待した程じゃねーぞゴルァ、ってこと?

507 :デフォルトの名無しさん:02/05/15 19:30
>>506
一ヶ月前のレスだぞ?

508 :たんなる雑談:02/05/16 10:17
画像の描画処理にPoplicyを使うことにしました
描画処理は
・速度が要求される
・透過、拡大、反転など組み合わせ次第で処理の量が膨大になる
ということでPolicyの考え方にまさにベストマッチですが、
どこをPolicyクラスにしてどこをtemplateクラスにするのかの判断はやっぱり難しいですねぇ。
Policyの境界を越えた最適化が出来ないというのもちょっとネックになりそうです。

509 :デフォルトの名無しさん:02/05/16 10:49
>Policyの境界を越えた最適化が出来ないというのもちょっと
これは層化の設計の問題でしょ。
下層で問題になるなら上層のPolicyをごっそり入れ替えればよし。

余談:Policyテクニック自体はSTLが存在するころから存在してるよね。
   STL自身が使ってるから。

510 :508:02/05/16 11:07
う〜〜ん使いこなせるようにはまだしばし時間が必要(^^;

511 :デフォルトの名無しさん:02/05/16 21:03
http://pc.2ch.net/test/read.cgi/tech/1021548960/3
>書籍中で紹介、また使用されているライブラリLokiはVC++ではコンパイルできません(;_;)サイアク・・・
これって、ちょっとした手直しとかのレベルでは、
使える様にはならないのかな。

512 :デフォルトの名無しさん:02/05/16 21:15
>>511
誰か手直ししたら漏れにも下さい

513 :デフォルトの名無しさん:02/05/16 21:29
>>511
ほんの一部なら動くがほとんどはダメです。
LokiのキモであるところのTypeListは
テンプレートの部分的な特殊化を前提に組まれてます。
再帰的な処理、その終端の特殊化もその機能に依存してます。
そしてVCでは部分的な特殊化はサポートされません。
これはヘルプにはっきり書いてあります。

514 :デフォルトの名無しさん:02/05/16 21:38
じゃあだめじゃん。
クリティカルな問題が無くならないね。
もうちょっと単純な仕様にすればいいのに。>テンプレート

515 :デフォルトの名無しさん:02/05/16 21:45
↓これどうなん?

Q: 他のC++ ツールで、より標準に適合しているものはありますか?

JON CAVES: はい、Visual C++よりも標準に適合するC++ コンパイラはあります。
1つの例は、私が100%適合していると信じるEdison Design Group (EDG)によるコンパイラです。
ただし、このコンパイラはWindows プラットホームではあまり利用できませんが。
Windows プラットホームではやはり、Visual C++が最も標準に適合するコンパイラの1つです。

516 :デフォルトの名無しさん:02/05/16 22:12
>>515
一長一短ではあるけど、
gcc3 、CodeWarrior7、 bcc5.6 (C++Builder) 辺りは
VC6よりは遙かに標準に近い気がする。VC.NETだとどうなんだろ?
それに、EDGのフロントエンドも100%とは思えないが…。

517 :デフォルトの名無しさん:02/05/16 22:15
VC.NETのテンプレート機能はVC6と大差ないです。
テンプレートパラメータがサポートされた程度。
てゆうかLokiコンパイルできません。

518 :デフォルトの名無しさん:02/05/16 22:17
>>517

>テンプレートの部分的な特殊化

はどうなの?

519 :デフォルトの名無しさん:02/05/16 22:18
VC6と変わりません。つまりダメ。
>>513 はVC.NETでの話。

520 :デフォルトの名無しさん:02/05/16 22:22
テンプレートの部分的な特殊化は実装がなかなか複雑なようで
その優先順位の判断にパターンマッチングやらなんやらが必要らしいです。
しかしModernC++によって部分的な特殊化がほぼ別物といっても良いくらい
飛躍的な表現力の向上につながることが明らかにされたわけなので
今後積極的にサポートされていく可能性は高いでしょう。

521 :369:02/05/16 22:25
>>519
だ、ダメなんすかー!? がーん。

522 :デフォルトの名無しさん:02/05/16 22:53
ModernC++はほんとパラダイムシフトだよね。
あれでコンパイラメーカーの奮起を期待したいところだね。
VC++に関してはどうなんだろう。MSやる気あんのかなぁ。。

個人的には.netでのアクロバットなテンプレートサポートに
期待してるけどね。

523 :デフォルトの名無しさん:02/05/16 22:56
>>522
Adobe Acrobat.NET(テンプレート付き)

524 :デフォルトの名無しさん:02/05/16 23:09
ワロタ

525 :名無しさん:02/05/16 23:14
gcc 3.1 でてるね。

526 :デフォルトの名無しさん:02/05/17 08:58
C++じゃ無くても良いんじゃないのかな。


527 :508:02/05/17 12:44
デキタ━━(゜∀゜)━( ゜∀)━(  ゜)━(  )━(゜  )━(∀゜ )━(゜∀゜)━━!!!!!

拡大反転透過楕円半透明コピーが出来たときには感動した!!
馬鹿正直に書いてたら数千〜数万行のコードがたったの500行ですんだ、すごいYO!!

528 :デフォルトの名無しさん:02/05/17 19:32
『Moder C++ Design』を読んでいるのですが、
公式サイトからダウンロードしたソースに、バグらしきものを発見しました。

該当個所は、第四章で紹介されているFixedAllocatorのVicinityメソッドです。
SmallObj.cpp の中で以下のようになっていますが(左は行番号)、

271: Chunk* lo = deallocChunk_;
272: Chunk* hi = deallocChunk_ + 1;
273: Chunk* loBound = &chunks_.front();
274: Chunk* hiBound = &chunks_.back() + 1;

もし deallocChunk_ が &chunks_.back() と同じ値であった場合、

290: if (p >= hi->pData_ && p < hi->pData_ + chunkLength)

この hi が指しているのは範囲外の要素となってしまいます。
これは既知のバグなのでしょうか。
参考までに VicinityFind メソッドを全文引用しておきます。



264:FixedAllocator::Chunk* FixedAllocator::VicinityFind(void* p)
265:{
266: assert(!chunks_.empty());
267: assert(deallocChunk_);
268:
269: const std::size_t chunkLength = numBlocks_ * blockSize_;
270:
271: Chunk* lo = deallocChunk_;
272: Chunk* hi = deallocChunk_ + 1;
273: Chunk* loBound = &chunks_.front();
274: Chunk* hiBound = &chunks_.back() + 1;
275:
276: for (;;)
277: {
278: if (lo)
279: {
280: if (p >= lo->pData_ && p < lo->pData_ + chunkLength)
281: {
282: return lo;
283: }
284: if (lo == loBound) lo = 0;
285: else --lo;
286: }
287:
288: if (hi)
289: {
290: if (p >= hi->pData_ && p < hi->pData_ + chunkLength)
291: {
292: return hi;
293: }
294: if (++hi == hiBound) hi = 0;
295: }
296: }
297: assert(false);
298: return 0;
299:}


529 :直してみた:02/05/17 21:12
264:FixedAllocator::Chunk* FixedAllocator::VicinityFind(void* p)
265:{
266: assert(!chunks_.empty());
267: assert(deallocChunk_);
268:
269: const std::size_t chunkLength = numBlocks_ * blockSize_;
270:
271: Chunk* lo = deallocChunk_;
272: Chunk* hi = deallocChunk_; // ココ
273: Chunk* loBound = &chunks_.front();
274: Chunk* hiBound = &chunks_.back() + 1;
275:
276: for (;;)
277: {
278: if (lo)
279: {
280: if (p >= lo->pData_ && p < lo->pData_ + chunkLength)
281: {
282: return lo;
283: }
284: if (lo == loBound) lo = 0;
285: else --lo;
286: }
287:
294: if (++hi == hiBound) hi = 0; // ココ
288: if (hi)
289: {
290: if (p >= hi->pData_ && p < hi->pData_ + chunkLength)
291: {
292: return hi;
293: }
295: }
296: }
297: assert(false);
298: return 0;
299:}


530 :デフォルトの名無しさん:02/05/17 22:11
行番号ウザイ

531 :デフォルトの名無しさん:02/05/17 22:12
return 0 は0行目に戻れな罠。

532 :528:02/05/17 23:35
>>529
おー、これだとたしかになおってそうですね。
つうか、オレもなおしちゃったけど。
もし未知のバグなら、報告したほうがいいんですかね。英語わかんねえけど。

>>530
がんばって行番号つけたのにッ! BASICを使ってた思い出に浸っていたのにッ!
オレの思い出をこわさないでー!

>>531
んなわけねえだろ。だいたい0行目なんて存在しねえんだよ。
テメエはCのやりすぎだ。一日二回くらいにしといたほうがいいぞ。


533 :デフォルトの名無しさん:02/05/18 00:15
>>532
なんか、ギャップにワラタ

534 :デフォルトの名無しさん:02/05/18 00:31
>>532
訳者のページに行ってみてはどうか。
オンラインで直ってないなら未知と思われるので。

535 :デフォルトの名無しさん:02/05/18 02:02
>>532
me fix bug. this patch
とか書いてdiff結果張り付けてメールとか。

536 :528:02/05/18 09:44
とりあえずいろいろ検索してみたら、同じようなことを書いているようなページ発見。
でも英語なので、あいかわらずよくわかりませんです。
http://www.kuro5hin.org/story/2002/4/5/82022/76326

>>533
ギャップってアレか。テキストエディタつくるときに使うとか聞いたことあるやつ。
それはギャップバッファだー! ちゅどーん!

>>534
訳者の方のページは見てみましたが、誤植の情報しかないようでした。残念賞。

>>535
出会い系サイトじゃないと、知らない人にメールなんて出せませんよ。怖すぎ。
しかも外人さんだし。やけに深呼吸ばかりしてそうだし(洋モノビデオの見すぎ)。


537 :デフォルトの名無しさん:02/05/18 10:16
>>529
ワロタ。

538 :デフォルトの名無しさん:02/05/18 13:20
528が常駐してからスレの雰囲気が悪くなったな

539 :デフォルトの名無しさん:02/05/18 13:26
うむ

540 :528:02/05/18 13:49
>>538-539
あら、雰囲気悪くなっちゃった? ユーモアってやつをわかってねえなあ。
ほれ、良書って言われる類の書籍には、たいていアメリカンジョークが書いてあるじゃん。
それもすっげーつまんないやつ。立派なプログラマなら、それで笑えるようになろうぜ。

理想としては、>>537の人みたいにソースコードを見ただけで
笑いがこみ上げてくるレベルを目指すべし。


541 :デフォルトの名無しさん:02/05/18 13:55
>>540 面白くもないモノに笑えるほど出来た人間じゃないんでね。
キエロ

542 :デフォルトの名無しさん:02/05/18 14:00
541<<<<<<<<<<<540

543 :デフォルトの名無しさん:02/05/18 14:06
>たいていアメリカンジョークが書いてあるじゃん。
528のはそれ未満なので笑えません。

544 :デフォルトの名無しさん:02/05/18 14:07
>>542
それはあり得ない。
常に541>540である

545 :デフォルトの名無しさん:02/05/18 14:24
いやホント、>>528って救いようがないよ。

546 :デフォルトの名無しさん:02/05/18 17:25
せめてIQが平均気温より高ければなぁ。

547 :デフォルトの名無しさん:02/05/18 18:12
>>546
単位は?

(ケルビンじゃないよな)

548 :デフォルトの名無しさん:02/05/19 13:24
528って自分に自信のないデヴオタヒッキーなんだろうなぁ…
なんか、某駄スレのJohnに酷似しているし。



549 :デフォルトの名無しさん:02/05/19 17:16
Johnの方が小賢しいな

550 :デフォルトの名無しさん:02/05/20 14:14
テンプレート使いまくりのコード書いたら
コンパイル速度激しく遅くなったんですが(;´Д`)
PCHにいれても入れなくても変わらず
自業自得ですけど・・・死ねるほどおそひ・・・VC.NET・・・

551 :デフォルトの名無しさん:02/05/20 14:28
PCH使って死ぬほど遅いのは、9割方使い方がおかしいだけ。


552 :デフォルトの名無しさん:02/05/24 11:05
ちょっとした短いコード(10行以内?)以外は
インライン実装するべきじゃない。
デメリットのほうが大きい。
素直にテンプレートの具体的な特殊化か
ポリモフィズムを使用するべし。

553 :デフォルトの名無しさん:02/05/24 12:21
>>552
昔の実装と違ってinlineはregisterと同じくもはやヒントでしかないし……。
そうカリカリせんでもいいんじゃない?
(暗黙のstticの意味を除けば。)

554 :デフォルトの名無しさん:02/05/24 16:12
ほっしゅほっしゅ


555 :デフォルトの名無しさん:02/05/27 10:15
>>552
VC++の場合ちょっとでも大きいとインライン展開してくれないようです
3行くらいでもわりと複雑な計算してると展開されません
チョー速度が要求されるところだったから__forceinline使いましたが

556 :デフォルトの名無しさん:02/05/27 18:44
差分コンパイルができない。=
依存関係のある全てのソースにリコンパイルがかかる。
また、インライン展開されなくとも複数の実体が生成される可能性もある。
そもそもインライン展開の判断自体、処理系依存である。
ちっこいプロジェクトなら問題ないかもしれんが
大規模ではちょっとした手抜きの割に被害はでかい。
テンプレートの使い方とその設計手法をまともに考えれば
クソでかい関数はできないはず。

557 :デフォルトの名無しさん:02/05/27 19:55
テンプレートだけ変換することってできない?

558 :デフォルトの名無しさん:02/05/28 23:32
>>552 が言っていることがよくわからなんだけど、
inlineとexportしてない(できない)templateとtemplateの明示的特化って
別物じゃないの?

559 :デフォルトの名無しさん:02/05/28 23:47
ああまだ上には上がいたんだな(´Д`)
出直そう

560 :552:02/05/31 12:55
>ちょっとした短いコード(10行以内?)以外は
>インライン実装するべきじゃない。
>デメリットのほうが大きい。
ここは一般論でその理由は>>556

>素直にテンプレートの具体的な特殊化か
>ポリモフィズムを使用するべし。
こっちは>>550に対してアドヴァイスしたつもりだった。
言葉足らずスマン。
テンプレート関数をexportできる処理系はまだ見たこと無いので
無いものとして話してる。

補足:
>テンプレートの具体的な特殊化
具体的な特殊化でテンプレート引数がすべて決まれば
普通のクラスと同じように非インライン関数として書ける。
テンプレートの用途からするとほとんど使えないテクだが・・

561 :デフォルトの名無しさん:02/05/31 23:02
以下のようなテンプレートの特殊化がVC++(ver6)では通らないんですが
何が問題なのでしょうか?g++ならば通るんですが・・・。

template<typename T, typename U> struct test {};
template<class T> struct test<int,T> {};


562 :デフォルトの名無しさん:02/05/31 23:04
>>561
VC++は諦めてください

563 :561:02/05/31 23:06
マジですか?>>562
いやほんとに頼みます。

564 :デフォルトの名無しさん:02/05/31 23:07
>>563
マジです

565 :561:02/05/31 23:10
>>564
ありがとうございます。ショックでかいです。
で質問なんですが.NETなら大丈夫とかないですか?
スレとずれて恐縮なんですが。

566 :デフォルトの名無しさん:02/05/31 23:11
>>565
.NETでもダメです。
正直がっかりでしたがVC8に期待しましょう。

567 :561:02/05/31 23:12
>>566
ありがとうございました(TДT)

568 :デフォルトの名無しさん:02/05/31 23:21
VCっていう前提が取れないところが素晴らしい

569 :デフォルトの名無しさん:02/05/31 23:27
いまさらVC使う意味は無いと思うんだが。


570 :デフォルトの名無しさん:02/06/01 00:05
VitaminC

571 :デフォルトの名無しさん:02/06/01 00:37
お金が無いんだよ!!無職なんだから

572 :デフォルトの名無しさん:02/06/01 00:56
お金がないならそれこそどうしてVC++?

573 :デフォルトの名無しさん:02/06/01 01:15
VSのIDEでコンパイルだけgcc使えればいいのに・・・。

574 :デフォルトの名無しさん:02/06/01 01:18
デバッグできないから意味無いじゃん

575 :デフォルトの名無しさん:02/06/01 01:44
IDEというのはこれとなんか関係してますか?

http://www.objectcentral.com/

576 :VC6に乗せたい:02/06/03 02:06
VS.NETが買えない貧乏人の私としては、VC6で何とか動かしてみたい。

template <class TList>
struct Length
{
  enum { value = 1 + Length<TList::Tail>::value };
};
template <> struct Length<NullType>
{
  enum { value = 0 };
};

template <class TList, unsigned int i>
struct TypeAt
{
  template<int cnt>
  struct isEnd
  {
    typedef typename TypeAt<TList::Tail, cnt-1>::Result type;
  };
  template<> struct isEnd<0>
  {
    typedef typename TList::Head type;
  };
  typedef typename isEnd<i>::type Result;
};

こういう風に書き換えればTypeListを使うことができるようになった。
既出ならスマソ

577 :デフォルトの名無しさん:02/06/03 02:08
>>576
なんだかわからんけど、よくやった!
次もこの調子でたのむ。

578 :デフォルトの名無しさん:02/06/03 02:31
>>576は神!!

579 :デフォルトの名無しさん:02/06/03 09:45
>>576
よくやった!

ただ、
不明な型が厳密にひとつしかないクラステンプレートなら
部分的な特殊化を使わずに実装できるんだが
TypeListにはそうでない機能がいくつかあるんだよね。

580 :デフォルトの名無しさん:02/06/03 10:37
VC++で無理やりSingletonHolderを動くようにしたんです。
って言ってもtemplateなstatic変数が作れないだけですから、
マクロ作って個々にインスタンスを作ってやっただけですけど。
で、ためしにLoki::SingletonWithLongevity使ってみたら
GetLongevityの戻り値が大きいほうから先に削除されちゃうんです。
ここでまたぶち切れですよ。
ModernにはGetLongevityの戻り値が小さいほうから削除されるように書かれているのに。
これはどう解釈したら言いのでしょう。

581 :デフォルトの名無しさん:02/06/03 10:52
>>576
VC++でSelectをなんとか出来ませんか?

582 :VC6に乗せたい:02/06/03 17:07
昼頃出先で書き込もうとしたら、串が2ch鯖に知られてて書き込めず、激しく鬱。
それはさておき。

VC++6.0は、ご承知のようにクラステンプレートの部分的な特殊化を
サポートしていません。
しかし、クラステンプレートの完全な特殊化はサポートされています。

[VC6で使えない例]
template <class TA, class TB>
struct baa{};

template <class TA>
struct baa<TA, int> ← すでに定義されているというエラーが出る
{};

[VC6で通る例]
template <class T>
struct baa{};
template <> struct baa<double> {};

あるいは、
template <class TA, class TB>
struct tee{};
template <> struct tee<double, int> {};

これだけなら大したことはできないのですが、
これをTypeAtのように、クラス内クラスで使うことで、
事実上の部分特殊化を掛けることができるようになります。

現在、手元でIndexOf まで仕上げました。
私はファンクタとダブルディスパッチを使いたいと思っているので、
それらの実装を目指すことにします。

583 :デフォルトの名無しさん:02/06/03 17:21
>>582
おぉぉ!

template< A, B, C >

Aだけ特殊化は出来ないから
template< A > class{ template< B, C > }
にしてAを特殊化するんですね!
Select行ってみます!

584 :583:02/06/03 17:56
Selectはできたけんども
TypeAtNonStrictで見事に撃沈・・・
完成したら作者に報告とともにどっかにウプしてくれ・・・>>583

585 :583:02/06/03 17:59
583を訂正

template< A, B, C > struct
{
 template< A > struct
 { //↑ここを特殊化するんですね
 }
}

586 :584(´д`;:02/06/03 18:01
584を訂正
ポインタが・・・>>583じゃ無くて>>582だ。
・・・鬱だ・・・氏んでくる

587 :VC6に乗せたい:02/06/03 18:43
>>583殿。>>582で示したガイドラインに沿ってTypeAtNonStrictを書いてみました。

あのように作り方を明記すると、考えが整理できるものですね。
>>576で載せたテンプレートも、ガイドラインに沿った命名に書き換えました。

template <class TList, unsigned int index,
typename DefaultType = NullType>
struct TypeAtNonStrict
{
  template <class tmpTList>
  struct tmp2TypeAt
  {
    template <unsigned int cnt>
    struct tmp1TypeAt
    {
      typedef TypeAtNonStrict<tmpTList::Tail, cnt-1, DefaultType>::Result Result;
    };
    template <> struct tmp1TypeAt<0>
    {
      typedef tmpTList::Head Result;
    };
    typedef tmp1TypeAt<index>::Result Result;
  };
  template <> struct tmp2TypeAt<DefaultType>
  {
    typedef DefaultType Result;
  };
typedef tmp2TypeAt<TList>::Result Result;
};

このコードで、コンパイル、テスト動作ができることは確認しております。
願わくば、この勢いで TypeList.h で定義されている
テンプレート群をVC6仕様に書き換える作業にご協力願いたい。
正直、一人ではきついので。


588 :デフォルトの名無しさん:02/06/03 19:10
>>587
で、今どこまで出来てるの?
協力しようにも何が出来てて何がまだなのか分からんと。

ただ、漏れ VC++ 持ってねぇんだよなぁ・・・

589 :デフォルトの名無しさん:02/06/03 19:18
強力はおしまんですよ、TypeAtNonStrictすらできなかった漏れが役に立てるかどうかはわからんですけど、
>>587
下から6行目
> template <> struct tmp2TypeAt<DefaultType>

> template <> struct tmp2TypeAt<NullType>
だと思います。


590 :VC6に乗せたい:02/06/03 19:52
>>588殿。恥ずかしながら、まだ IndexOf を実装しただけです。
本業もあるため、平日は遅々とした進度になるかと思われます。
できそうなところからどんどん発表していくつもりです。

あと、>>589の指摘ですが、原著の作者の実装をそのまま置き換えたため、
そのようになっております。元ソースと比較してみてください。
なお、先日から取り組んでいる Typlist 型関数は、
数値関数に置き換えれば、このようになります。

Result TypeAtNonStrict(class TList, int index,
class DefaultType = NullType)
{
if(TList != DefaultType)
{
if(index != 0)
{
return TypeAtNonStrict(TList.Tail, index-1, DefaultType);
}
else
{
return TList.Head;
}
}
else
{
return DefaultType;
}
};

元ソースよりもいくらか手続きっぽくなってるのかも。


591 :デフォルトの名無しさん:02/06/03 19:53
age

592 :VC6に乗せたい:02/06/03 19:54
しまった。タブの置き換えを忘れていました。スマソ

Result TypeAtNonStrict(class TList, int index,
      class DefaultType = NullType)
{
  if(TList != DefaultType)
  {
    if(index != 0)
    {
      return TypeAtNonStrict(TList.Tail, index-1, DefaultType);
    }
    else
    {
      return TList.Head;
    }
  }
  else
  {
    return DefaultType;
  }
};


593 :583:02/06/03 20:05
とりあえず私はtypelist.hの下から行きます。
今MostDerived終わりました。後でどっかでマージしませう

あとtmpじゃ分かりにくいので名前付け方法を決めたほうがいいと思います。
私は

template <class TList, unsigned int index,
 typename DefaultType = NullType> struct TypeAtNonStrict
{
 template <class tmpTList> struct SelectTList
 {
  template <unsigned int cnt> struct SelectIndex
  {
    hogehoge...
  };
 };

 typedef SelectTList<TList>::SelectIndex<index>::Result Result;
};

のようにしました

594 :デフォルトの名無しさん:02/06/03 20:22
す、すげー。あんたら、すげーよ。完成したら、ぜひ使わせてもらうよ! がんばってっ!

595 :583:02/06/03 20:28
ReplaceとReplaceAll終わりました
つーか使っててすげーです、Lokiマンセー!!!

596 :デフォルトの名無しさん:02/06/03 20:46
目から鱗すぎます。
素晴らしい。
第二版に日本人の名を連ねられるか??
期待して待つ!

597 :デフォルトの名無しさん:02/06/03 20:48
あー
漏れ私的に使いたかったTypeTraitsの移植に挑戦してみようかな・・・

598 :583:02/06/03 20:51
Erase以降全て終わりますた
>>597
人が作ったものは作り直したくないので、終わったらここに報告してね。

599 :583:02/06/03 20:52
漏れがLokiと格闘してる間にイタリア1点取ってるし・・・(´д`;

600 :583:02/06/03 20:54
うぉ!
もしかしてtypelist.h終わったじゃん。
どっかにウプしよーぜ!

601 :デフォルトの名無しさん:02/06/03 20:57
sourceforge.comだと世界中から見つかりやすげ

602 :デフォルトの名無しさん:02/06/03 20:58
>>601
sourceforge.netだ

603 :583:02/06/03 21:22
>>601-602
使い方分からん・・・(´д`;

編集済みtypelist.hとtypemanip.h、
VC++用に改造したsingleton.hが入ってます。
http://www68.dns.ne.jp/~bbs2/upload3/helen/OB00011454.zip
VC++.NETで作ったので、VC++6.0で動かなかったらゴメソ

なにぶん以前は動いてなかったので、typelist.hとtypemanip.hが元と同じように動作するかは確認できてません。
特にtypemanip.hのConversionが、exists2Wayが元と違う方法を使ってるので、その辺でばぐるかも。

編集後のSingletonHolderは残念ながら元と全く同じように使うことは出来ません、
これを使うときは、
プロジェクト内のCPPファイル内でImplementLokiSingletonマクロを使って
SingletonHolderのstaticメンバ変数の実体を作ってちょ

とにかく576は間違いなく神だな・・・
神の啓示を受けた気分だ。

604 :583(゚ Д ゚ ;)・・・・:02/06/03 22:08
もしかして・・・車輪の再発明でしたか?

http://www.geocities.com/rani_sharoni/LokiPort.html

605 :VC6に乗せたい:02/06/03 22:09
おおおっ! ちょっと離席していた間にもう終わったのですか。すげー!
>>603は早速ダウンロードして、すべてチェックしました。
今のところ、VC6でも正常に動作しているようです。

typename とはこういうものだったのですか。
これを知らずにAppendの実装がうまくいかず、一時中断していたのですが。
知らぬではどうにもならぬですね。まだまだ修行が足りないです。
勉強になります。

606 :583:02/06/03 22:13
LokiPortよりも漏れらのやつのほうが美しいようだ、良かった良かった。

607 :583:02/06/03 22:23
おりょ?
やっぱりやってることはほとんど同じか・・・(鬱
(汚いと見えた)MakeTypeListやis_TypelistはLokiのバージョンアップで追加されたものかな?

608 :VC6に乗せたい:02/06/03 22:51
>>583その「is_Typelist」が、VC6ではコンパイラに通らないです。
結局、VC6にはtypename 指定をしないと、
template<typename Head, typename Tail>
Typelist<Head, Tail>

NullType の区別がつかないようなのです。

VC.NET用はともかく、VC6用は、ここで新規開発しないといけないかも。

609 :597:02/06/03 23:14
>>598
ダメですた。
ポインタの特殊化がどーーーしてもできまへん。
と思ったら>>604 で見事に実装されてますた。
悔しいやら嬉しいやら。

ともかく念願のTypeTraitsが手に入りますた。
ありがとうございます。

610 :597:02/06/03 23:17
そういえばVCは
なぜか前から関数テンプレートのポインタ等の特殊化を
サポートしてるんだよな・・。
その調子でクラステンプレートも実装してホスィ

611 :583:02/06/03 23:29
>>608
漏れはVC.NETなのでLokiPortに満足してしまいますた。
続きはがんばってください。
何かあれば協力しますし。

612 :デフォルトの名無しさん:02/06/04 11:22
MakeTypeList age
これがあるとがぜん使う気が起きるね!

613 :VC6に乗せたい:02/06/04 12:40
>>608まあ今時VC6でなにかしようというのが、もう時代遅れなのかもしれないですが。
>>609 LokiPort の MakeTypeList は単体で動作するようです。
>>583氏のヘッダに移植できました。

あと、うっかりサンプルソースでReverseを呼び出すのを忘れていたのですが、
こいつがエラーが出てコンパイラにとおりません。(VC6)
ガイドライン通りにちゃんと書かれているようなのですが。原因はまだ不明です。

614 :デフォルトの名無しさん:02/06/04 16:01
このスレの前のほう見るとLokiをVCで通るようにするのは絶対無理って書かれてるな。
>>613はその発想力を大切にするといい。

615 :デフォルトの名無しさん:02/06/04 16:29
ModernC++のページでもセンセーショナルだと書かれてるね>604
出てきたのが今年の3月だから、タッチの差は僅かだ。

MakeTypeList も上のほうで無理言われてたけどあっさり実装されちゃってる
まるで魔法だ。
C++って奥深すぎる。鬱だ。

616 :デフォルトの名無しさん:02/06/05 16:21
テンプレート乱用しすぎますた(´д`;)
1翻訳単位のコンパイルにジャスト3分(あんまり長いので測った
まだ(やってることは)小さなプログラムなのにビルド後のファイルサイズは1MB突破・・・

テンプレート依存は一箇所に局所化して他の翻訳単位は高速化したけどそれでもつらいっす・・・

617 :デフォルトの名無しさん:02/06/05 16:36
嘘くせー


618 :616:02/06/05 16:39
ヽ(`Д´)ノナンダト!!

619 :デフォルトの名無しさん:02/06/05 18:12
>>616
ひょっとしてポインタ型各種について展開してないか?

620 :デフォルトの名無しさん:02/06/05 18:14
早速Lokiを酷使してるとか?

621 :616:02/06/05 18:45
書き始めたころ(>>508くらい)はまだVCでLokiが動かせるとは夢にも思って無かったです。

画像の描画処理を転送・フィルター・形状・スケーリングの4つのポリシーに分けらああなりますた。
特に2つの転送ポリシーを合成するポリシーを作ったらコードサイズも時間も爆発。(まぁ当然か

622 :デフォルトの名無しさん:02/06/05 18:47
転送をポリシーととらえるのはどうか。
ピクセルの特性をポリシーとするなら分かるが。

623 :616:02/06/05 18:49
>>622
エフェクト、といえばよかったかも。
単純描画や飽和加算など

624 :デフォルトの名無しさん:02/06/05 19:48
なるほど
某otakuのGTLの発展したような物ですね、
かっこよさそうです。

625 :デフォルトの名無しさん:02/06/06 11:14
demo otaku はどこいっちゃったんでしょうか?

626 :613:02/06/06 17:03
>>621 Effective C++で、void* で受けることで
テンプレートによって生成されるコード量を大幅に
減らすアイデアが載っていましたが、いかがか?

>>604からスレの流れが変わったので、コテハンやめるっす。



627 :デフォルトの名無しさん:02/06/07 00:59
>>626
Effectiveもってないっす、詳細きぼん

628 :デフォルトの名無しさん:02/06/07 01:52
STLスレって倉庫落ち?

629 :デフォルトの名無しさん:02/06/07 01:54
>>628
ageたよ
http://pc.2ch.net/test/read.cgi/tech/1004287394/

630 :デフォルトの名無しさん:02/06/07 01:59
あぐ
http://pc.2ch.net/test/read.cgi/tech/1021787032/556
に書いてしまった…。サンクスコ>>629


631 :613:02/06/07 10:18
>>627
Modern C++ Designは Effective C++に書いてあることが前提になっているので、
先に読んでおいたほうがいいですぞ。買っても後悔しないです。

要は、コンテナに入れるものをvoid*として格納するコンテナを用意しておき、
要素に対する操作を定義しておきます。(ソートだとか何とか)
で、void*として放り込む作成・破壊クラスを別に定義します。
確かこんな感じだったはず。詳細は当該書籍を読まれよ。

632 :デフォルトの名無しさん:02/06/07 13:37
既出の質問かもしれませんが、教えて下さい。
メンバー関数の有無によってコードを書き分けるにはどうしたら良いのでしょうか。

例えば、次のようなテンプレートクラスがあるとします。
template <class A>
class X {
 void func() {
  if (/* A::foo() があるかどうかの判定*/) }
   /*CODE1: A::foo()を使う処理 */
  } else {
   /*CODE2: A::foo()を使わない処理、もしくはA::foo()の処理を肩代りする処理*/
  }
 }
};

ここでクラスA1にはメンバー関数foo()があり、
クラスA2にはメンバー関数foo()がないとします。

このとき、X<A1>::func()とX<A2>::func()は
それぞれCODE1とCODE2の部分だけ実行するようにしたいのです。
できれば、判定をコンパイル時に行ない、コンパイルされたオブジェクト
にはコードが最適化されてCODE1とCODE2のどちらかしかしか
存在しないようにしたいと思っています。

こういうことは可能でしょうか?
可能だとするとどのようにしたら良いでしょうか?


633 :デフォルトの名無しさん:02/06/07 13:48
>>632
タグディスパッチ

634 :632:02/06/07 15:14
>>633
さっそくどうもありがとうございました。

Googleで検索してみたら、次のURLがヒットしました。
http://www.issei.org/programming/boost/more/generic_programming.htm
ここで言われているのがそれですか?

なかなか凝ったやり方に感じましたが、勉強になりました。


635 :デフォルトの名無しさん:02/06/07 15:22
>>632
C++にはリフレクション機能が無いので
特定メンバあるかどうかの判断はできない。(・・よね?)
だから他の条件が必要。

渡されるクラス全てにタグを定義とかの制限をつけてもよいならタグディスパッチ
だめならlokiのTypeTraitsで使えそうな特性をみつけるとか。
私的には特定のクラスのサブクラスかどうかで分けるのが良いと思うが。

636 :626:02/06/07 22:07
>>613 なんだかよく分からないのですが、
>>583氏のヘッダに適宜 LokiPortのコードを移植することで、
LokiPortのTest_Typelist.cpp がコンパイルできてしまいました。
ということは、Typelistに関してはVC6でも動作可能ということですよね。
ううむ。



637 :デフォルトの名無しさん:02/06/07 23:16
移植完了品をパッチかアーカイブの形式で全部UPしてください

638 :デフォルトの名無しさん:02/06/08 18:05
>>636
VC6ってテンプレートパラーメータサポートしてなかったと思うけど
どうやってるの?

639 :デフォルトの名無しさん:02/06/08 18:18
>>638
ん? できないのは部分特殊化でしょ?
テンプレートパラメータサポートしてないってどういうこと?
文字通り取るとtemplate自体使えないような。

640 :デフォルトの名無しさん:02/06/08 18:42
>>639
テンプレートテンプレートパラメータのことでしょ。わざわざ揚げ足取らんでも。
template< class A, template<class> B > class C { ... };

ってゆーかしかし、LokiのTypeListって部分特殊化さえあれば動くと思ったが。

641 :デフォルトの名無しさん:02/06/08 20:34
>>640
どういうときに使うの?

642 :デフォルトの名無しさん:02/06/08 20:54
>>641
http://www.comeaucomputing.com/techtalk/templates/#ttp

643 :デフォルトの名無しさん:02/06/09 21:52
LokiPortのTypeTraits::isConstがうまく動かない・・
参照型が問答無用でconstと判断されてしまう。
まぁあんまり使い道の無い機能ではあるが
ザンネン。

644 :デフォルトの名無しさん:02/06/09 22:17
・・・よくよく考えると
参照そのものは変更できないからconstという判断でいいのかな。
そういうことにしよう!

645 :デフォルトの名無しさん:02/06/09 22:29
ん?
isPointerの実装おかしいような??
これconstの判別できないだろ?

646 :デフォルトの名無しさん:02/06/09 23:10
>>644-645
仮にVC++の話であるなら
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrf14552partialorderingoffunctiontemplates.asp
なのでそこんとこ注意。

647 :デフォルトの名無しさん:02/06/09 23:37
>>646
そうなんだよね・・
それなのになんで動くのかちと不思議。
保障されない動作なんだろうか。

とりあえずisPointerはポイント先の修飾された奴を全部消して
コンストポインタの判定を追加したらうまく動いた。

648 :デフォルトの名無しさん:02/06/09 23:42
template<typename U>
static yes is_pointer1(Type2Type<U *>);
static no is_pointer1(...);
template<typename U>
static yes is_pointer2(Type2Type<U * const>);
static no is_pointer2(...);

enum {
isPointer =
sizeof(is_pointer1(Type2Type<T>())) == sizeof(yes) ||
sizeof(is_pointer2(Type2Type<T>())) == sizeof(yes) ||
};

これで動いた。
これって単に動作確認してなかったのかな。
それともSPあてる・あてないで動作変わったのかな・・

649 :デフォルトの名無しさん:02/06/16 11:18
>>632
激しく遅レスだが
VC++には__if_exists/__if_not_existsなるキーワードがあって
関数や変数の有無で処理を分けられる
移植性を考えれば使えないが

650 :デフォルトの名無しさん:02/06/16 17:18
>>649
それどうやって使うの?
解説キボンヌ

651 :デフォルトの名無しさん:02/06/16 17:28
>>649
それって.NET専用?

652 :デフォルトの名無しさん:02/06/16 17:38
>>650

#include <iostream>

int main(void)
{
int a;
__if_exists( a ){ std::cout << "a ハケーン" << std::endl; }
__if_not_exists( a ){ std::cout << "そんな変数無いです" << std::endl; }
}

こんな感じ
このままだと "a ハケーン" が表示される
int a;をコメントアウトすると "そんな変数無いです" が表示される

( ) 括弧の中は変数だけじゃなくて、任意のシンボルが入れられる。
もちろんメンバ関数も。

653 :デフォルトの名無しさん:02/06/16 17:39
>>651
ネイティブにも使えるけど、もしかしたらVC++.NETから新しく追加された機能かも

654 :デフォルトの名無しさん:02/06/16 17:49
6.0には無かった。

655 :名無しさん:02/06/16 19:11
>>649
メンバー、メソッドでもOKなの?


656 :デフォルトの名無しさん:02/06/16 19:14
このスレに巣食ってる型はハイレベルですね・・・。

657 :デフォルトの名無しさん:02/06/16 22:27
こういうのぜひ 規格 にフィードバックして欲しい
(識別子をどうするかは、考えないといけないが)

658 :デフォルトの名無しさん:02/06/16 23:46
>>657
コンパイラによるリフレクション? 規格はさすがに無理ぽそうだけど...

659 :名無しさん:02/06/17 02:06
つーか、どういう時に効くのかな?
ウヒャ─、これは便利、って例ある?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrfthe__if_existsstatement.asp
memberもOKなのね。しかし、なんじゃこりゃ? って感じ。


660 :デフォルトの名無しさん:02/06/17 02:14
std::advanceのようなアルゴリズムを記述するのに、
タグディスパッチがいらなくなるんじゃない

661 :名無しさん:02/06/17 08:21
template <class _Iterator, class _Distance>
inline void advance(_Iterator& __i, _Distance __n) {
 __if_exists( _Iterator::operator[]){ __i += __n; } // random
 __if_exists( _Iterator::operator--){ if (__n >= 0) while (__n--) ++__i; else while (__n++) --__i; } // bi
 // elseがないからtag抜きでforward iterator書きにくい。
}
こんな感じ?


 


662 :デフォルトの名無しさん:02/06/17 11:36
Templateを初心者にも分かりやすく教えてください。

663 :デフォルトの名無しさん:02/06/17 11:39
>>662
コンパイラがコンパイルの前に置換をしてくれるんだよ。
プリプロセッサがやる単純な置換と違い、コンパイラが型チェックに
責任を持ってくれる。



664 :デフォルトの名無しさん:02/06/17 11:41
>>633
Templateはどういうときに使うのですか?

665 :デフォルトの名無しさん:02/06/17 12:08
>>664
リストって知ってるよね?単方向でも双方向でも。

例えば、構造体Aと言う値を保持するリストのクラスを作ったとする。
これがなかなか便利で他のプログラムにも使いたい。

しかし、構造体Aは前のプログラム独自の物なので汎用性を持たせたい。
そこで、構造体Aの代わりにvoid *を持たせることにした。

しかし、これでは型キャストの嵐になるし、新しいノードを作るとき、自動的にデータ格納用の
メモリ領域を確保したり開放したりすることが困難になる。

next = new nextnode();
next.data = new ここを使う型が変わるたびに変更しなくてはならない。


そこでテンプレート。これは特定の抽象型を具体的な型に置換できる。
例えば、データ用の型をDATAとし、それをintと具体化すれば、
int型を扱うリストが出来るし、struct aaaと具体化すればaaa構造体のリストとなる。


666 :デフォルトの名無しさん:02/06/17 16:17
あれ、完全に置換はしないってあったような気がするけど

667 :デフォルトの名無しさん:02/06/17 23:10
>>664
抽象化する時
(メソッドとか関数とか)

668 :613:02/06/18 12:49
>>663 >>665

激しくスレ違いに真面目にレス。2ちゃんねらーの鑑です。
私も見習わないと。

ということで真面目レスを追加しておきますと、
テンプレート(template)の萌芽はMFCのコンテナにも見られます。
(CMap、CListなど)

でもやはり、STLは一通り勉強しましょう。
ttp://www.wakhok.ac.jp/~sumi/stl/index.html
それから、Effective C++、More Effective C++を一通り読んで、
>>1 のModern C++ Design を買えば、
晴れてこのスレの住人に仲間入りです。
頑張りなされ。


669 :デフォルトの名無しさん:02/06/18 21:12
Effective C++、More Effective C++、Modern C++ Design
いくらかかると思ってんのYO(`Д´)

670 :デフォルトの名無しさん:02/06/18 21:23
>>669
全部持ってるYO!高かったけど仕方ないYO!

671 :デフォルトの名無しさん:02/06/18 23:20
>>669
書籍にかけた金は、すぐに仕事実績で取り返せる(ちゃんと読めば)。惜しむな。

672 :デフォルトの名無しさん:02/06/18 23:21
> 書籍にかけた金は、すぐに仕事実績で取り返せる(ちゃんと読めば)。惜しむな。
そう思いこみたいんですね :)

673 :デフォルトの名無しさん:02/06/18 23:42
>>672
怖がりすぎー。

674 :デフォルトの名無しさん:02/06/19 08:14
「primitiveな変数をいちいちconstructorで
初期化するのはめんどくせー」ってことで、
WithInit< int , 600 > m_intvalue;
ちゅーよーなのを書いた。
ひょっとして、車輪を再発名した……?

675 : ◆4COMPILE :02/06/19 11:57
>>674
勝手に600に初期化されるint ってこと?

676 :age:02/06/19 12:17
VC++.NETにて下記のコードで InnerInStrict がコンパイルエラー
"error C2516: 'Inner' : は正しい基本クラスではありません。"
を吐きます。
InnerInFunc は問題なく通ります。
これはC++の仕様?それともVC++の問題?
InnerInStruct も使えるように出来ないのでしょうか?

struct Base{ struct Inner{};};
template< typename T > struct Mid: public T{};

template< typename T > struct Sub
{
 struct InnerInStruct: public Mid< T >::Inner{};
 Sub()
 {
  struct InnerInFunc: public Mid< T >::Inner{};
 }
};

int main(void)
{
 Sub< Base > sub;
}



677 :デフォルトの名無しさん:02/06/19 15:33
>>674
整数型でしか使えないじゃん。

678 :デフォルトの名無しさん:02/06/19 15:38
>>676
g++3.1やbcc5.5.1では何ごともなく通ったよん

679 :676:02/06/19 15:55
>>678
鬱・・・

680 :デフォルトの名無しさん:02/06/19 16:39
>677
bool, int ,char , short, long , float, doubleと使えれば
充分じゃねーんすか?

681 :デフォルトの名無しさん:02/06/19 19:16
Genericプログラミングマニアのみなさま。汎用シーケンスコンテナを作れませんか。

Effective STLの第2項、「コンテナに依存しないコードという幻想に注意しよう」を
読んだ上で言ってます。
vector,deque,listってのは、しょせん実装の詳細なわけですから、最初っから
「汎用シーケンスコンテナ」ってのがあって、その実装を、vector,deque,listなどの中から
ポリシーで選べたら便利なんじゃないかと思うわけですが。
Effective STLには、たとえば「vectorをサポートしようとすると、push_frontとpop_frontを
使用できない」とか書いてあります。要するに、「全部に共通するメンバ関数がないから、無理」
ってなことに過ぎないわけでして。全部ラップして作り直せば問題解決なんでは、と思った
わけです。どうでしょう?

// ポリシークラスその1。vectorによる実装。
template<class T>
class ImplVector
{
public:
  typedef std::vector<T> cont_t;
  typedef cont_t::iterator Iter;
  typedef cont_t::size_type SizeType;
private:
  cont_t c_;
public:
  void PushFront(T val){
    c_.insert(c_.begin(),T);
  }
  void PushBack(T val){
    c_.push_back(T);
  }
  void Erase(T val){
    // eraseとremoveの慣用的用法ってやつ。
    c_.erase(remove(c_.begin(),c_.end(),val),c_.end());
  }
  T& operator[](SizeType n){
    return c_[n];
  }
};

682 :681:02/06/19 19:16
// ポリシークラスその2。listによる実装。
template<class T>
class ImplList
{
public:
  typedef std::list<T> cont_t;
  typedef cont_t::iterator Iter;
  typedef cont_t::size_type SizeType;
private:
  cont_t c_;
public:
  void PushFront(T val){
    c_.push_front(T);
  }
  void PushBack(T val){
    c_.push_back(T);
  }
  void Erase(T val){
    c_.remove(T);
  }
  T& operator[](SizeType n){
    Iter it = c_.begin();
    for (int i=0;i<n;++i){
      ++it;
    }
    return *it;
  }
}

// Generic Sequence Container
template
  <
    class T,
    template <class> class ImplContainer = ImplVector
  >
class GSC : public ImplContainer<T>
{
};

GSC<int> gsc;
gsc.PushBack(3);
gsc.PushFront(5);
gsc.Erase(3);
int a = gsc[0];

こんな感じで、効率の良し悪しは無視して、思いつく限りのメンバ関数を
用意しておけばいいんじゃないかなと。後で「vector実装でOKだと思ってたけど、
list実装の方がよかったな〜」ってときは、GSC<int>って定義をGSC<int,ImplList>に
変えるだけです。使ってる部分のコードは全く変更しなくていい、ってのが当然の目標。

……とかいって、どっかですでに開発されてましたー、じゃ虚しいんで、
存在を知ってる人がいたら、さっさとツッコミ入れてくださいね。

683 :デフォルトの名無しさん:02/06/19 19:29
>>674
初期値を変更したくなったときに依存してるソース全部で
再婚パイルが必要なのって面倒い。

>>682
「vectorでOKだと思って operator[] を使って色々実装していたけど
やっぱりlistの方が良かったなー」なんてことは起こり得んと思うがどうか。

例えば std::queue のコンテナにはほとんどの実装だと list/deque は取れても
vectorは使えないけれど、それはvectorを使う意味が全くないからであって、
そこにあえてvectorを渡せるように汎用性を持たせる…みたいなことって
やってもしょうがないのでは。

684 :デフォルトの名無しさん:02/06/19 19:45
>>680
> bool, int ,char , short, long , float, doubleと使えれば
> 充分じゃねーんすか?

いや、template に float や double (char もか?) の即値はつっこめないのではないかと。。。

685 :681:02/06/19 22:08
>>683
いや、それは単にそういうありえなさそうな状況を挙げてるだけでは。(^^;
operator[]を使うって事は最初っからlistが考慮の外なのは明らかですから、
そういう状況を持ってきて否定されても。std::queueのほうも、目的が
はっきりしているなら、汎用シーケンスコンテナなんて必要ないのは
あたりまえです。

とりあえず、俺がこれを欲しいと思った動機を。vectorでもlistでもいいような、
曖昧な状況で『とりあえずvector』で開発をはじめたけど、あとで『げ、中間への
データ挿入が出てきた。やっぱlist』って切り替えたくなったんです。そのとき、
データ削除部分の形がvectorとlistでは全然違うやん、ってので参ったんです。

要するに、『どのシーケンスコンテナが最適なのか、不透明な状況』に対して
最適な回答をもたらすために、汎用シーケンスコンテナがあればいいなぁ、と。

どのコンテナが最適なのかわかんないうちから開発を始めてんじゃねーぞ、
って言われたら、「はい、ごめんなさい」と凹むしかないですが……。

686 :デフォルトの名無しさん:02/06/19 22:39
Effective STLに書いてあったかどうかしらんが、必ずtypedefをするようにしとくだけで
いいんでないの?

いちおう、
どういうコンテナを使うべきかの分析無しで作りはじめてんじゃねーゾ。


687 :デフォルトの名無しさん:02/06/19 23:31
age

688 :668:02/06/20 00:00
>>685
私の場合は、テキストエディタを作るときに1行のテキストを
stringに入れて、listに入れて使いました。
stringはコピーにコストがかかるので、

vector::[] + insert よりは、
list::advance + insert の方がパフォーマンスがよかったです。
(advance 10万回で0.04秒程度)

しかしそれはコンテナの性質と設計上の要請を勘案すれば
事前に分かることで、わざわざポリシーにするほどのことではないと思うのですが。

689 :デフォルトの名無しさん:02/06/20 00:04
テキストエディタはlist+キャッシュと言うのが常套手段だよな。
もう常識中の常識。

それより、1行に持てるデータの構造をどう記述するかの方が問題。

690 :681:02/06/20 00:26
>>686
typedefは必ずやってます。>>681で書いてるみたいなやつを。
でも、typedefじゃ『削除』はどうにもならないんですよね。

とりあえず逝ってきます……。

691 :デフォルトの名無しさん:02/06/20 07:16
listっておい、まともなやつはgapped bufferだろ..


692 :デフォルトの名無しさん:02/06/20 08:30
>>691
listとギャップバッファは用途違うと思うが?
それから、ギャップバッファも1行に保持するデータが長くなってくると
パフォーマンスががた落ちするよ、所詮2セグメントのデータだからね。


693 :デフォルトの名無しさん:02/06/20 08:41
>684
VC++6で、double即値、char即値ともつっこめますた。

694 :648:02/06/20 17:30
Boostにごっついtype_traitsの実装があることに今ごろ気付きますた・・・!!
死のう。

695 :デフォルトの名無しさん:02/06/20 23:48
>>691は何行になるかわからんのにいちいち行ごとに
オブジェクト作るなって言いたいんじゃないのか?

そういう点でみれば>>692のは激しく的はずれ



696 :デフォルトの名無しさん:02/06/21 04:30
gapped bufferってn行へジャンプとかが苦手じゃないの?

697 :デフォルトの名無しさん:02/06/21 07:08
苦手といえば苦手だが克服は簡単だよ
最近のPCは速いし。


698 :デフォルトの名無しさん:02/06/21 08:04
listと違ってn行へのジャンプが定数時間で終わるのがgapbufferじゃないのか?

699 :デフォルトの名無しさん:02/06/21 10:07
>>698
gapped buffer って、バッファの内容をカーソル位置で分割して管理する方法だよね。
それだと、コストはこうじゃないかな。

gapped buffer
 一文字追加、削除 O(1)
 指定行の移動 O(バッファの総文字数)

リスト
 一文字追加、削除 O(一行の文字数)
 指定行への移動 O(ファイルの行数)

gapped buffer は「普段よく使うのは一文字単位の追加・削除だから、こっちを
早くしたほうが快適だ」という信念に基づくデータ構造だと思うよ。ついでに、今
時の PC を前提とするなら、どっちでも早すぎて変わらん。

700 :デフォルトの名無しさん:02/06/21 21:35
>gapped buffer って、バッファの内容をカーソル位置で分割して管理する方法だよね。

これだと先頭から終端までジャンプするのに、バッファのコピーが発生するよね?
めちゃくちゃ遅くならない?

701 :デフォルトの名無しさん:02/06/22 01:21
>>700
挿入・削除のタイミングでバッファ内の整理をすればよいので
全然そんなことない。

極端にでかいファイルもストレスなく開けるようにするのに便利。


702 :デフォルトの名無しさん:02/06/22 01:24
VZは行編集バッファを別に持って、
何か書き換え始めたら行編集バッファにコピーしてきて編集し、
カーソルがその行から出たりするタイミングで書き戻してたっけ。

703 :デフォルトの名無しさん:02/06/22 03:10
ちょっと質問 gapped bufferってデータを
head part  cursor    tail part
|-----------| + |------------|
こんな感じで持つ構造と考えて良いのでしょうか?

それとも、下の様にいくつかのフラグメントに分けて保存して、
編集時のコピー量を少なく納める構造なのでしょうか?
|-----| |-----| |----+-| |------|

日本語のサイトをいくつか検索しても、
どっちとも取れるようなどっちも違うような記述でよく分かりません

704 :名無しさん:02/06/22 03:16
後者は変形の一つ。

>>700
正直、editorならほとんど変りがない。今や一番重いのはGUIの描画。

705 :デフォルトの名無しさん:02/06/22 10:18
>>703
カーソル位置とギャップ位置は関係ない
ギャップは普通エディットしている部分に作られる

706 :デフォルトの名無しさん:02/06/22 13:35
どうでもいいけど話題がスレ違い

707 :デフォルトの名無しさん:02/06/22 18:08
ではだれかgapped bufferをgenericに実装した例をキボンヌ

708 :デフォルトの名無しさん:02/06/22 18:30
>>707
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=utf8&oe=utf8&q=%E3%82%AE%E3%83%A3%E3%83%83%E3%83%97%E3%83%90%E3%83%83%E3%83%95%E3%82%A1

709 :デフォルトの名無しさん:02/06/22 18:33
gapped bufferのメリットがぜんぜんわからぬ・・・

710 :デフォルトの名無しさん:02/06/22 21:00
http://www.jah.ne.jp/~naoyuki/Programs/Programs.html
ここにあるな

711 :デフォルトの名無しさん:02/06/23 12:31
STLPortとLokiPort(のSmallObj)同時に使えないっすね。
STLPortのlower_boundに不具合があるんですけど、
どうにもならないですかね。

712 :デフォルトの名無しさん:02/06/23 12:55
>>711
lower_boundにどんな不具合がありますか?

713 :デフォルトの名無しさん:02/06/23 14:27
>>712
ぉ!
Generic Programing and the STL見てみたら、
STLPortの動作のほうが正しいですね。
// MSDNには書いてない新たな条件が・・・
LokiPortのほうの使い方に問題があるみたいですね

714 :デフォルトの名無しさん:02/06/23 21:09
boostのTypeTraitsのコード読んでたんだが
ちょっと前、Lokiの移植で話題になってたVCで
テンプレートの部分的な特殊化をエミュレーションしてる部分に
こんなコメントかいてあるんだけどあれのどこが not legal なの?
ーー以下引用ーーー

// the following VC6 specific implementation is *NOT* legal
// C++, but has the advantage that it works for incomplete
template<class T1>
struct is_same_part_1 {
template<class T2> struct part_2 { enum { value = false }; };
template<> struct part_2<T1> { enum { value = true }; };
};

ーー引用ココまでーー
他のコンパイラでは動かないのかな?

715 :デフォルトの名無しさん:02/06/24 02:26
.NET Framework SDKについてるC++のコマンドラインコンパイラでは
Lokiを使えますか?

716 :デフォルトの名無しさん:02/06/24 03:19
>>715
過去ログよめ

717 :デフォルトの名無しさん:02/06/24 03:48
>>716
過去ログにはVC++.NETとあるだけなので、VisualStudioなのか
.NET Framework SDKだけでも大丈夫なのかわかりませんが。


718 :デフォルトの名無しさん:02/06/24 03:57
>>717
一応、最適化のオプションが使えなくなってるだけで、
あとは普通にManagedも吐ければ、通常コンパイルもできる

まずは使ってから質問しろ。
lokiが使いたいだけならgccにしろ。

719 :デフォルトの名無しさん:02/06/24 04:01
>>718
使うかどうかまだ決めてないんで。
情報どうも。

720 :デフォルトの名無しさん:02/06/24 04:07
>>719
LokiPortを使えば?
http://www.geocities.com/rani_sharoni/LokiPort.html

721 :デフォルトの名無しさん:02/06/24 08:57
VC7.0のコンパイラって何処で落とせますか??

722 :デフォルトの名無しさん:02/06/24 09:28
>>721
http://msdn.microsoft.com/netframework/

723 :デフォルトの名無しさん :02/06/26 10:36
VC7.0はtypeof演算子は使える?
g++だといけるんだけど。

724 :デフォルトの名無しさん:02/06/26 14:57
>>723
それがGeneric Programmingと何の以下略

725 :デフォルトの名無しさん:02/06/26 15:44
>>724
コンパイラへのプログラミングにおいて
限られた道具が増えることは、かなり重要なことだと思うけど・・・

今のところ、どう使うか考えてるところではあるんだけどね:)

726 :デフォルトの名無しさん:02/06/26 17:23
処理系依存の話は、できれば余所でお願いしたいところだが。

(まぁ C++ の template 自体、完全実装してる処理系はほとんどないから、
処理系依存に近いのが現状だけどさ)

727 :デフォルトの名無しさん:02/06/26 18:07
http://www-cdserver.fnal.gov/cd_public/sag/J16/J16.htm
http://www-cdserver.fnal.gov/cd_public/sag/J16/J16_files/slide0042.htm

• typedef templates:
template< class T >
typedef std::map< std::string, T > Dictionary;
Dictionary<double> d;
Dictionary<PhoneNumber> phonebook;

• typeof() compile-time operator:
template< class T >
void foo( T t ) {
  typeof( f(t) ) y = f(t);
… ;
}

こりゃ凄いと思うがどうよ。

728 :デフォルトの名無しさん:02/06/26 18:09
あ、凄いのはtypedef templateの方ね(笑

729 :デフォルトの名無しさん:02/06/26 18:58
どっちもホスィ・・・

730 :デフォルトの名無しさん:02/06/26 19:26
typeofって拡張だろ?

731 :デフォルトの名無しさん:02/06/26 19:30
>>730
標準に含めて欲しいっていう提案はされてるみたい

732 :デフォルトの名無しさん:02/06/27 00:38
なるほど、スレ違いってうまい言葉だなあ

733 :標準化委員会:02/06/27 00:38
typeofはもうすぐ導入予定です

734 :デフォルトの名無しさん:02/06/27 00:52
typeofはいいから早くANSIに対応してくれよ>VC++

g++ってあれだけがんばってるのに、ユーザーは
相変わらずCでゴリゴリ書くのが好きな人ばっかりで、
なんか哀れだよね。

735 :デフォルトの名無しさん:02/06/27 18:04
typeof萌え、標準にすぐ入れるべし、

736 :デフォルトの名無しさん:02/06/27 18:28
typeofはテンプレートのないCに取り入れられた方が
劇的にコーディングスタイルが変わりそう。

737 :デフォルトの名無しさん:02/06/27 18:31
>>736
マクロプログラミングですか?
イヤだなぁ

738 :デフォルトの名無しさん:02/06/27 18:32

#define foreach( itr, cont ) for( typeof( (cont).begin() ) itr = (cont).begin(); itr!=(cont).end(); ++itr )

739 :デフォルトの名無しさん:02/06/28 04:25
template<typename T>struct SA{
   template<typename A,typename B>struct TSA{TSA(){cout<<"A"<<endl;}};
   template<>struct TSA<T,int>{TSA<T,int>(){cout<<"B"<<endl;}};
   template<>struct TSA<T,double>{TSA(){cout<<"C"<<endl;}};←これが警告になって、しかも無視されるのがわからない。なんで?
};

740 :名無しさん@カラアゲうまうま:02/06/28 10:39
オーバーロードの曖昧さ?

741 :デフォルトの名無しさん:02/06/29 18:05
Cスタイルの文字列を受け取れるテンプレートで、
const char* を受け取れるようにしとけば動作するけど、
template< unsigned N > f( const char (&x)[N] );
にバージョンを用意しとけば、文字列リテラルを受け取ったときに、
N で文字列長を受け取れる分、より効率的に処理できるようです。
ですが、↑みたいなテンプレートを使ってるのをほかで見たことがありません。
なにか問題があるからなのでしょうか?
それとも、見つけれて無いだけで、めずらしくもない方法なんでしょうか?

742 :デフォルトの名無しさん:02/06/29 18:52
>>741
boos::type_traits::is_array

743 :デフォルトの名無しさん:02/06/29 18:53
^boos^boost

744 :741:02/06/29 20:06
>>742
配列型の判別はできても、boostのやつには N が取れないように見えますが、
同じことができるってことですか?

745 :デフォルトの名無しさん:02/06/29 21:30
LokiPortのis_arrayにも似たような記述があるが
環境依存な部分も少なからずあるみたい。
ただ単にサイズを自動的に取得したいという目的ならば不要かと。
const char* との共存ができないようだし。(VC7)
普通にstring(literal, sizeof(literal))で問題無いかと。

746 :デフォルトの名無しさん:02/06/29 23:40
もうtemplateは疲れた。

747 :デフォルトの名無しさん:02/06/30 00:41
正直、Lokiの延長みたいのが仕事で使われるようになったら、
この業界辞める。もっとらくちんなの希望。

748 :デフォルトの名無しさん:02/06/30 02:51
>>747
ライブラリ作るのとそれ使うのとでは全然違うと思われ

749 :デフォルトの名無しさん:02/06/30 15:43
>>747
激しく同意。
STLのように使うだけのライブラリとはちょっと違う。
プログラム設計において根本から変わってしまうような
ものだと思う。
というかそろそろ言語の機能をフル活用しなければならない
っていう呪縛から逃れたいところだね。C++使ってるひとには
自分も含めて、この傾向が強いから。

750 :デフォルトの名無しさん:02/06/30 17:07
自分が便利だと思う機能をしっかりと使えればいーんじゃネーノ?


……と思ったが、そうすると他人のプログラムの保守ができんな。

751 :デフォルトの名無しさん:02/06/30 20:38
機能は、必要を感じた時に初めてその使用の検討をするべき。
templateなんて特にそうだと思うぞ。
俺は無いと困るみたいな状況に陥ったことがないので、
使ったことは無いが。w

752 :デフォルトの名無しさん:02/06/30 22:18
>>751
> 機能は、必要を感じた時に初めてその使用の検討をするべき。
とはいえ、全く知らないと

 これを使えば簡単に済むのに

っつーことに気づかぬ罠。

753 :デフォルトの名無しさん:02/07/01 01:43
templateで一番威力を発揮するのはコンテナでしょ。
その辺だけ使えればいいんじゃないの?
構文汚いけど。

754 :デフォルトの名無しさん:02/07/01 07:51
関数オブジェクトもなかなか


755 :デフォルトの名無しさん:02/07/01 09:06
GenScatterHierarchyとGenLinearHierarchy最高。
さてこれをどう使ったらいいものやら。。

756 :デフォルトの名無しさん:02/07/01 09:54
>>755

クラスのメモリレイアウトをコントロールできない。
というわけでスクリプトでプログラムを書くときのように
手軽に、巨大なシステムを構築してしまいたいが型は
大切にしたいとき(どんなときだ?)に使う。

757 :名無しさん:02/07/01 11:40
>>749
「プログラム設計において根本から変わってしまう」ことと、
「言語の機能をフル活用しなければならない」は相関性弱いと思うが…
後者は実装の話でしょ。

俺はcompilerのerror messageさえなんとかなれば、Lokiくらいは容認。

758 :デフォルトの名無しさん:02/07/01 11:55
プライベートなコーディングにおいては
Loki使いまくり。正直、もう昔のGoF本に載ってる
ような野暮ったいコーディングには戻れない。
Typelistは最初は違和感あるけど、我慢して一ヶ月ぐらい
使いつづければ誰でも慣れる。typelistの新たな
使い方を考えるのはかなり厳しいが、MCDの
本に載ってるようなDPへの適用を真似る程度であれば
大したことはない。

759 :デフォルトの名無しさん:02/07/01 11:57
MCDってなに?


760 :デフォルトの名無しさん:02/07/01 11:58
ModernC++Designのことね。勝手に省略ゴメソ

761 :デフォルトの名無しさん:02/07/01 17:33
「ふーん、そんなこと言える身分なの?」
「恥ずかしいことしてるのばれちゃってるのに・・」
3人はイチゴの顔をじっくりみつめる。
そしてその中の1人がそっと言った。
「しかたないわ、あ私たちめくるのやめるわ。」
イチゴはほっとした。
『許してくれるんだ・・・・』
「ありがとうございます・・・・」

762 :デフォルトの名無しさん:02/07/01 22:23
>>761
ほえ?

763 :デフォルトの名無しさん:02/07/01 22:33
型のコレクションをマクロ無しで扱う機能を次のC++標準に入れて欲しい。

764 :デフォルトの名無しさん:02/07/01 22:45
>>763
現在の ANSI C++ 決めるまでにかかった時間から考えて、次の ANSI C++ 規格
が出るのは

 話し合いが始まる 2005年
 リリース目標    2008年
 実際に決まる    2010年

ぐらい?

765 :デフォルトの名無しさん:02/07/01 22:56
コンパイラベンダの実装完了目標 2015年
実際に実装される 前に次の標準の話し合いが始まる
無限ループ?

766 :デフォルトの名無しさん:02/07/01 23:03
つーか今の規格でもういいよ。
SQL99みたいになっても意味無し男

767 :デフォルトの名無しさん:02/07/02 04:41
>>765
VC++はそのころになっても現在の規格にすら準拠できてなさそうだな・・・(鬱

768 :デフォルトの名無しさん:02/07/02 07:55
LokiからBasicFastDispatcherってどうして取り除かれたの?
致命的なバグでも見つかったとか?
一番実用的なアイディアだと思っただけに残念。。

769 :デフォルトの名無しさん:02/07/02 08:30
ポストC++を開発する良い機会だと思うけど。


770 :763:02/07/02 14:43
もう、始まってるのさ...
http://std.dkuug.dk/jtc1/sc22/wg21/
0xだそうだからあと7年以内になんとか。

771 :デフォルトの名無しさん:02/07/02 15:12
>>770
あと7年・・・それまでにパソコン業界はどうなっているのだろうか?
ハードディスク1TB超、CPU10GHz、メモリ10GBなんてのは当たり前に
なってそうだ。いや、これくらいなら4年もあれば実現する。

(C++)++ってのは文法違反か?

772 :デフォルトの名無しさん:02/07/02 19:57
CPU4台くらい積むのが当たり前になってるかもね。
基本は省電力モードで休眠状態。
いわゆる論理区画みたいなもんかね。

そうなっているとすれば、そのころのOSの役割は
本来の資源管理にのみ特化しててもよさそうだね。

773 :デフォルトの名無しさん:02/07/02 20:59
> (C++)++ってのは文法違反か?

Cの型(というか多重定義演算子の定義のされ方)による。>>771

774 :デフォルトの名無しさん:02/07/03 01:03
10年後はC++の次ができてそうだね

775 :デフォルトの名無しさん:02/07/03 02:09
>>773
なるほど。基本型はエラーになるようだ。

>>774
Cを拡張したのがC++だけど、もうこれ以上小手先だけで拡張できない
ほどメチャクチャになっているので、新しい言語を作った方がいいような
気がする。
CPUで言うと丁度x86みたいな様相を呈しているからな・・・・・

776 :デフォルトの名無しさん:02/07/03 07:00
とりあえずC互換部分を(全部とはいわないけど)なるべく消して欲しい。
"..."とかも。(そうなるとModern C++ Designが困るのだが)
あとグローバル変数も要らん。

777 :デフォルトの名無しさん:02/07/03 11:15
>>776
つまらん。

778 :デフォルトの名無しさん:02/07/03 13:41
>>776
C++ - C ってことは、言語名は ++ ですか?

>>775
確かに template がらみだと、

「たしかに template 使えばできるけど、あまりに直感的じゃない。言語の方で
 直にサポートしてくれよ」

という機能も多いよな。でも template がこんなに強力な代物だとは、出てきた
当時は思いもよらなかったよ。

779 :デフォルトの名無しさん:02/07/03 16:58
クラスつきのCとしてのC++からC互換の危ない部分を取り除いて
それをベースに型推論を導入してテンプレート宣言はやめる。
代わりに仕様として部分評価を導入して生成的プログラミングスタイルをサポート。
(つまり関数はデフォルトで暗黙のうちにテンプレート関数なわけ。値による特化は部分評価技術で。)

ただクラス・テンプレートの宣言をどうするかはちょっと迷うところだ。
関数型言語のように構築子を強化してクラス宣言を特殊な関数宣言とみなして
構造体アクセスのパターンマッチング機能と組み合わせてと言う路もあるが、
あまりにもCらしさからかけ離れてしまう気がするし。
(命令型C風MLみたいになってしまう。)

780 :デフォルトの名無しさん:02/07/03 19:48
静的型付け言語の現状C++マンセー!!!

781 :デフォルトの名無しさん:02/07/03 19:54
>>780
型推論は、強い型付けと矛盾しないけど。

782 :デフォルトの名無しさん:02/07/03 19:59
>>781
あ、そなの?MLとか知らないからよく分からんけど。。
その辺は他の言語もやってみないとダメだね。

783 :デフォルトの名無しさん:02/07/03 20:00
Cの怨念部分を取り払う時期がくるか

784 :デフォルトの名無しさん:02/07/03 20:02
ちなみにAlexandrescuはMLやHaskellなどの関数型言語も、
自著で名前を何回も出すぐらいだからかなり知ってるのかもね。

785 :デフォルトの名無しさん:02/07/03 21:10
つーか、プログラミング言語ネタで本を出すようなヤシでML知らないのはモグリ。

786 :デフォルトの名無しさん:02/07/03 21:19
MLやHaskellにいかずとも、空リストや特殊定義でlispを思い出
す以前に、リストにアルゴリズムを施したりファンクタ
つくらせてカリーイングやったりという近年のC++の傾向そのもの
がオブジェクト指向と別方向の関数型言語指向なわけで。
lispと違って、それなりのパフォーマンスを維持しつつそういう
遊びがあるところに近時のC++の長所があると。
ただ実用から行くと、Java + generics + メモリ直接操作 くらいが
受けのいいところでしょ。
どうせ次期標準C++なんていってもせいぜい確率高い順に

hash_map他のSGI拡張、boost等のスマートポインタ、正規表現、数学等のライブラリが入るかどうか
サイズ規定のプリミティブ型が入るかどうか
typeofやらclosure/delegateやらの言語拡張が入るかどうか
マルチスレッドやネットワークのサポートが入るかどうか

とかだろ? しかも付け加えてばかりでは実装上文句が出るはず
だけど具体的にどこってのは全然見えない。そもそもVC++8のリリ
ース時期に合わせないと誰も使わないだろうな。
C99と互換性無いと駄目とかそっちの方がむしろ主流ではないの。

787 :デフォルトの名無しさん:02/07/03 21:29
>>786
同じ文章をどこかで見たことがある気がする(デ・ジャ・ヴ?)

長所禿同
C++には多少手を加えるにしても全体としては今のままを維持してホスィ・・・
OOPらしいOOPがやりたい人はJavaでもC#でもやってりゃいいんで

788 :デフォルトの名無しさん:02/07/04 00:05
性能と手軽さのトレードオフのある今のOO/GenericなC++でだいたい足りるわ。
今ある規格には準拠して欲しいとも思うがね。

それよりコンパイラのバグ減らせ!

789 :デフォルトの名無しさん:02/07/05 06:42
gcc3.1+boost1.23でlambdaを使ってます。
下の結果が3ではなく、4になってしまうのですが、
どうしてでしょうか?

int i = 1;
std::cout << (_1 + i)(i = 2) << std::endl;


790 :デフォルトの名無しさん:02/07/05 08:51
_1 って?
それにスレ違い

791 :デフォルトの名無しさん:02/07/05 09:35
>>790
別にスレ違いじゃないだろ。genericsがらみだし。
>>789
boost 1.23??

792 :デフォルトの名無しさん:02/07/05 10:02
>>789
一つ言えることは _1 + i と i = 2 のどちらが先に実行されるかわからないのだから
そういう書き方をしてはダメってことだ

793 :デフォルトの名無しさん:02/07/05 10:32
>>791
あ、1.28です。
最新版の配布パッケージです。
boost::lambdaのドキュメントには

>int i = 1;
>(_1 + i)(i = 2);
>The value of the expression in the last line is 3, not 4. In other words, the lambda expression _1 + i creates a lambda function lambda x.x+1 rather than lambda x.x+i.

このように書いてあるのですが…

794 :デフォルトの名無しさん:02/07/05 12:15
>>793
今回のとは無関係だとは思うけど一応
http://www.catnet.ne.jp/kouno/c_faq/c3.html#9
こういうのがあった。

_1 + i が内部で i の値を利用しようがしまいが未定義になっているのかもしれない。

795 :デフォルトの名無しさん:02/07/05 12:34
未定義じゃないはず。
((int(*)(int))operator+(_1, i))(i = 2);
たしか、こんな感じになるはずだし。

796 :デフォルトの名無しさん:02/07/05 12:39
_1

そっか、各種名前としては成立するな・・・。クソ迷惑だけど。

797 :デフォルトの名無しさん:02/07/05 12:51
普通にx/y/z等を占有されるよりも_1/_2/_3の方がいいじゃん

798 :デフォルトの名無しさん:02/07/05 14:01
検索してもユーザーサイトがこれぐらいしかみつからない。
http://user.ecc.u-tokyo.ac.jp/~g940455/wp/loki/
他の皆はLoki使いこなしてる?
未だにSmartPtrやFuntorを実験してる・・・

799 :デフォルトの名無しさん:02/07/05 17:11
>>798
残念ながら使いこなすほど成熟したライブラリではないと思う。
Alexandrescu本人も実際に使ってるかはなはだ疑問。

800 :デフォルトの名無しさん:02/07/05 17:27
ACEはLoki的な書き方をすればコードはかなり小さくなりそうな予感。
完成したライブラリではないが、それてきなものをテクニックの一つと
捉えて、どんどんコードを書いていくことは大事なことな気がする。

801 :名無しさん@Emacs:02/07/15 00:35
お前らちゃっとTypelist使ってますか?

802 :デフォルトの名無しさん:02/07/15 00:36
ちゃっと使ってます

803 :名無しさん@Emacs:02/07/15 00:45
>>802
どうつかってるの?
本にのってるやつ真似てるだけ?
それとも自分で新たに技作ってやってるとか?

804 :デフォルトの名無しさん:02/07/15 04:02
>>803
意味解析すると>>801による、

>お前らちゃっとTypelist使ってますか?

という誤文(正しくは「ちゃんと」であろう)に対して、>>802は同じ調子で、

>ちゃっと使ってます

と応答した。
これは恐らく「ちゃんと」と「チャット(chat)」を掛けている可能性が高い。
よって、>>802が本当に「ちゃんとTypelistを使いこなせているよ」
という意味で返答したのかどうかは、このレスでは判断できない。

また、これを踏まえると>>802に対しての>>803の応答は、
抽象的すぎるきらいがある。
>>802への適切な応答としては、

1)s/ちゃっと/ちゃんと/

などとし、話の流れを元に戻すか、

2)チャットは何のソフト使ってるの?

が考えられる。

805 :デフォルトの名無しさん:02/07/15 13:07
Typelistはべつに新たに使い方を発明する必要はないな。
そういうのは一部の天才たちに任せよう:)
それよりもデザインパターンを適用したソフトウェア設計が
できるかどうかの方がよっぽど大切。これが出来ないことには
Alexandrescuの本に書いてあることの多くが使えない。

おれはよく知らないけど、Typelist自体についてもっと
勉強するには他の型付関数型言語のコーディングテクニックとかを
勉強する方がよいんじゃないの?

806 :デフォルトの名無しさん:02/07/15 15:27
>>801-804
名古屋弁で「ちゃっと」といえば「さっと(すばやく)」くらいの意味だ。

ちゃっとやっとかんとかんわ。=さっとやっておかななければならない

807 :デフォルトの名無しさん:02/07/16 03:49
Effective C++読み終えたよ。
大体は知ってたけどいろいろと役に立った。
次はMore Effectiveでも読むかな。

808 : ◆4COMPILE :02/07/16 11:48
>>807
Moreは訳がくそなので読むのに想像力と忍耐力が必要だぞ。
(ここでいうことでもないのでsage)

809 :デフォルトの名無しさん:02/07/16 15:47
頭の中で英語に訳しながら理解すべし。(ワラ

810 :名無しさん@カラアゲうまうま:02/07/16 16:34
bk1 で More 注文したけど入荷できずにキャンセルされちゃったよ。
思い切って洋書を注文したよ。がんがろ。

811 :デフォルトの名無しさん:02/07/16 18:07
More Modern C++ Design

812 :デフォルトの名無しさん:02/07/16 18:26
effective C++って第2版でどう変わったの?


813 :デフォルトの名無しさん:02/07/16 18:27
>>808
普通に読めたよ。


814 :デフォルトの名無しさん:02/07/16 19:01
D&E
ARM
(;´Д`)

815 :デフォルトの名無しさん:02/07/16 19:53
>>812
標準C++の文法に準拠した新しい機能を使っている。

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)