C++/TemplateMetaProgramming

1 ：2008/02/16 〜 最終レス ：2012/10/12

・ここはC++のテンプレートメタプログラミング専用スレです。
・なかったので立てました。
・前にもあったような気がするけど気にしない。
・次期C++（0x） boost STLの話題も、TMPに関係するならここにどうぞ。
仲良く使ってね。

2 ：

とりあえずTMP始めてだから優しくしてね＞＜って人には
p_stabeのとこのブログのログを最初から読んだりしてみる事から始めるといい。

3 ：

すいません、やっぱり、該当スレでお願いします。
申し訳ありませんでした。

4 ：

おい>>1、メタだけあってもしょうがないだろ
何を話題にすりゃいいんだ

5 ：

>>1 乙

6 ：

>>4
いくらでも話題はあるさね

7 ：

>>4
template<fugafuga>を使った機能とか、
必要であればプリプロセッサも絡めてもらうとありがたいです。

8 ：

>>7
だったらテンプレートスレにしておけば良かったのでは・・・
なぜメタ限定？

9 ：

>>8
テンプレートスレならNTPとかMOJOばっかりで
Lispみたいなメタプログラミングは話題にし辛いだろう。
ここはそういうのを扱うスレ。コンパイル時点での、コードに対するプログラミングに関するスレ。

10 ：

>>8
激しく同意だな
でも、テンプレートスレじゃboost、STL、C++スレでカバーで良いんじゃね

11 ：

とりあえずPreprocessor Metaprogramming万歳

12 ：

メタプロと普通のテンプレート使ったプログラムは全然違うだろう。

13 ：

STLスレやboostスレとか何度も統廃合の話題が出てその度に荒れていたな

14 ：

スレが立った初っ端からいろいろ文句つけてる奴は何だ？
現在、板の各所に散らばっている“テンプレートスレ”で満足しているならこんな所覗く必要はないだろう。
“メタプログラミング”を話題にしたい奴がここを必要としているんだ。興味がないなら来るな。

15 ：

そうだそうだ

16 ：

いや、興味あるとかないとかそういう問題じゃねぇーだろw

17 ：

別にMetaProgrammingであればTemplateは必要なかったのでは？
誤解を招くだけだし。
あと、
>>1
>仲良く使ってね。

18 ：

メタプロが理解できない奴が嫉妬してクレーム付けてるだけだろ

19 ：

勢いが1234もある。
過疎ったVIPスレ並みに速い流れだな。その割には糞なレス多いけど。

20 ：

{
std::ofstream f( "tmp.cpp" ) ;
f << いろいろいろいろいろいろ ;
}
system( "cc tmp.cpp" );
system( "a.out" );
では、このあたりからw

21 ：

クラックしがいがありそうだなw

22 ：

>>20
テンプレート(ライブラリ)を使ったメタプログラミングだwww

23 ：

だいたい、>>1がアホだからいけないんだ
Templateなんて入れるないで、素直にC++/メタプログラミングすればよかった

24 ：

>8
Boost, STLとの統合の話題が出てくるからじゃね？
あっちは使い方、こっちは実装テクニックと使い分けできるといいね。
そういやポリシーってみんなどんぐらい使ってる？
template<class T> class M : public T {};
struct T1 { void t1() {}; };
struct T2 { void t2() {}; };
M<T1>().t1();
M<T2>().t2();
とか、インターフェースの差し替えが出来てけっこう便利な気がするんだけど。

25 ：

単純にテンプレートテクニックスレで良かったんじゃね、とか

26 ：

とりあえず同名の本の解答集
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CPP_Template_Metaprogramming_Book_-_Answers_Page
例えば演習2-3で型を文字列で出力するテンプレートを作りなさいなんて問題あるけど、
std::cout << type_descriptor<long const*&>();
これ、C++だと volatile, const, ポインタ、参照でそれぞれ specialization で場合分け
し、さらに基本型の int, long, char, double とかでさらに場合分け
とかなって、なんだか力業だなぁとか感じる(答参照)。

27 ：

>>24
スーパークラスに直接Tをいれるのはコンパイルが異様に重くなるので最近は避けているな。

28 ：

>27
エエエ(ry
コンパイルなんて昔に比べると激早だから、あんまり気にしないなあ。
どちらかというと使う側でpimplとかの工夫してるし。

29 ：

そおか、C++以外の言語を使ったあとだと余りの遅さにかなりショックを受けるんだが。

30 ：

100ファイル程度あると、C++は自作オーバークロックの最強マシンをもってして三十分や一時間かかりかねないけれど
これがC#だとヘナチョコマシンでも一分掛かるか掛からないかといった所。

31 ：

コンパイル時間のほとんどは
プリプロセスなんだろうなあ。

32 ：

>>30
どう考えてもそれは長すぎる
せいぜいかかっても1ファイルに2〜3秒ってところじゃないの？

33 ：

Boost.Lambdaのヘッダをプリコンパイルドヘッダに入れようとすると、
pchがぶくぶく膨らんでいく。
後のコンパイルでは、プリコンパイルドヘッダの読込も
ボトルネックになっているのではという気がしてならない。

34 ：

>>31
よほど凝ったことしなきゃそれはないだろ

35 ：

プリコンパイルでどれだけの時間が短縮されるか考えたら
そんなもんだと思う

36 ：

プリコンパイルは一応コンパイルもしてるわけで

37 ：

>33
ヘッダを重くするとそうなるけど、それこそpimplで隠したら？
Boost.Lambdaをヘッダに突っ込もうとする時点で何か設計で失敗している気がするけど。
＃ライブラリを設計しているのならしょうがないけど

38 ：

$ cat test.cpp
# include <boost/lambda/lambda.hpp>
int main()
{
using namespace boost::lambda;
int i = 4;
return (_1 + _1 + 1)(i);
}
$ time g++ test.cpp
real 0m1.175s
user 0m0.900s
sys 0m0.068s
$ time cpp test.cpp >/dev/null
real 0m0.249s
user 0m0.160s
sys 0m0.024s

39 ：

>>37
たしかにLambda自体は特定のcppファイルでしか使っていない。
こういうときはプリコンパイルドヘッダから外すべきなのか？

40 ：

そらそうだな。

41 ：

>39
ヘッダは基本的にインターフェイスなんだから、インターフェイスに不要な実装は隠すのが望ましい。
テンプレート使ってるとそんなことも言ってらんないけど。

42 ：

そろそろC++という言語自体を見直すのが望ましいという気もしないでもない
問題累積しすぎだろ

43 ：

>>41
stdafx.hで何もかもインクルードしていたよ。

44 ：

以前のスレを探してきた。
【C++】template 統合スレ -- Part6
http://pc8.2ch.net/test/read.cgi/tech/1101384692/

45 ：

ある程度確定したクラス他は専用libに放り込んでるので無問題

46 ：

・クラス単体のみの宣言だけ
　class A;
・クラスのインターフェイスを含めた宣言だけ
　class A{ void f(); };
2種類のヘッダを用意すれば(ry

47 ：

>41
C++狂Herb Sutterの本を読んだほうが良いと思う。
ヘッダファイル：　インターフェイスに関係するファイルを最低限
ソースファイル：　できるだけこっちでインクルードする
が基本だよ。

48 ：

コンパイル時間の節約は分かるんだが、
いざヘッダファイルをインクルードして何か使おうとすると
実装が無いとか文句言われることがあるのが困るんだよな。

49 ：

実装じゃねえや。定義だ。

50 ：

>>48
ただの誤用にしか聞こえんのだが、どういう状況の話？

51 ：

不完全型のみで十分な状況では
その型を定義してあるヘッダをインクルードせず、
不完全型の宣言のみを書く。
そして、その型を使ってるソースファイルでのみ、
そのヘッダファイルをインクルードする。

52 ：

なんかC++の基本もまともに出来ないような人が居ますね。

53 ：

TMPやるにはHaskell勉強した方が良いって本当ですか？

54 ：

>>53
変数への代入ができないという制約の下でどうやって問題を解決するかを学ぶ、
という点で本当だと思う。

55 ：

SICP読んだらModern C++ Designが分かった

56 ：

Scheme勉強したらModern C++ Designが分かった

57 ：

あれって別の関数型言語を勉強してからじゃないと理解できないほど難しいか？

58 ：

ムチャクチャな書き方をしないといけないからわかりにくいんだよ。
すっきりした表記の関数型言語を勉強した後だと
どういうトリックなのかがすんなり理解できる。

59 ：

別に無茶苦茶ではないと思うが。

60 ：

再帰に継承が絡んでくると難しく感じる。

61 ：

慣れてないだけだな。それにあんなもの別にC++以外のものを触ったって慣れやしない。

62 ：

ところで>>2のp_stabeには誰もつっこまないの？
p_stadeじゃないかって

63 ：

q_stabe

64 ：

>>61
それは違うと思う。関数型言語のほうが記法が簡便だが抽象度が高く
センスが必要。LispでもSchemeでも自在に扱えればC++のメタなんて少し
の時間でマスターできる。templateなんて少しの時間でマスターできる。
経験上確信してる。逆は成立しない。

65 ：

千差万別、十人十色
自論に固執すること愚か也

66 ：

言語に組み込まれてるってのは重要だよな。
C++だとマクロとかでちょっと文法の解釈を脳内変換すれば
いいんだけど手間が増大するのと
初学者に扱える代物ではなくなってしまうんだよね。

67 ：

>>65
関数型言語の経験ないだろ？

68 ：

>>65
SICPは読んだ？

69 ：

負けへん、負けへん
山ちゃんは負けへんでええ

70 ：

誰か質問しろよ。
スレ落ちるの時間の問題だな。

71 ：

C++0xではmplは入らなくてTypeTraitsどまりってことは
mplはまだ重視されてないってこと？メイヤーズの本では
TMPがC++の中心に来ることはないなんて書いてあったけど
どうなんだろ？

72 ：

そうなんでしょう。
だって頭の体操にはなるけど、あんまり実用性ないじゃん。

73 ：

type_traitsはフレームワークであって、
みんなが自分のクラスのtraitsを提供しないと真価を発揮しないけど、
mplは使いたい人が使えばいいだけだから標準化しなくても困らない。

74 ：

C++0x において提案されている <type_traits> で提供される機能の中には
コンパイラが持っている独自の情報を吐いてくれないと実装できないものも多いので
そういう意味で TypeTraits は優先的に規格として明示してくれないと困るかと

75 ：

call_traits は追加されるの？

76 ：

MP専用の構文を入れる気はもうないのかね
Templateでできたのはたまたまであって、
いつまでもあんなハックみたいな書き方したくないなぁ

77 ：

バッドノウハウ

78 ：

完全体のC++かどうかを判断するために
compiler_traits
が必要な気がする。

79 ：

そうなるとまず has_compiler_traits が必要だな。

80 ：

>>76
D言語の出番ですね、分かります

81 ：

いやあ、すべってるねえ　このスレ

82 ：

昔ProgramingJemsにメタプログラミングでsinテーブルを生成するっていうネタがあった
当時メタプログラミングなんて知らなくて、
「すげぇぇぇぇ」と感動して自分でも作ってみた
しかし当時のオレのショボマシンではコンパイル時のサインテーブルの生成に結構な時間がかかり
最終的に、
Perlでテーブル書いたソースジェネレートした方が早くね？
という結論に

83 ：

メタプログラミングとは？
テンプレート、型、typedef、コンパイル時定数、再帰を
駆使したコンパイル時プログラミングで合ってる？

84 ：

テンプレートメタプログラミングならそれでまあ合ってる。

85 ：

>>83
それはテンプレートメタプログラミングの説明だな
メタプログラミング自体はもっと広く、プログラムを操作するプログラム全般をいう
プリプロセッサを使うのもメタプログラミングだし、コードジェネレータを書くのも含む

86 ：

テンプレート抜けてた。

87 ：

そういう意味では82のPerlでソース生成と言うのも立派なメタプログラミング。

88 ：

>>82
そんなあなたに constexpr@C++0x

89 ：

一方D言語はsinを定数として畳み込んだ。

90 ：

静的に実行できる関数は静的に実行してしまう。
D は中々のものだ。

91 ：

D言語って誰が生みの親なの？

92 ：

昔borlandで働いてた人

93 ：

をるたん

94 ：

>>92
じゃあ流行らないな

95 ：

ボーランドはちがくね？

96 ：

>>82
まあC++のテンプレートはメタプログラミングのために設計されてないからねえ。
マクロらしいマクロを持った言語なら、かなり高度なメタプログラミングをやってても
普通のコードの２倍やそこらの時間でコンパイルできる。
Lispの世界じゃ40年前からメタプログラミングが当たり前だし、
DOSの世界ではMASMのマクロで構造化なんてのが流行った。

97 ：

ライブラリ作るときは主流になりそうだけどな。
てか、もうなってるか。
でもschemeのほうが言語機能としてcons listとか
があるから、より簡潔でストレス感じない。
C++のTMPはいかんせん表現がキモ過ぎる。

98 ：

そこで constexpr ですよ

99 ：

こんなの作ってみた。
自分のプログラムでは活用できてるからいいんだけど、意外と汎用性ないな……
struct UniqueNumber {
   template<class type_t>
   static unsigned int number() { static unsigned int n(count()); return n; };
private:
   static unsigned int count() { static unsigned int c(0); return c++; };
}

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

HelloWorld集めようぜ (228)
エスパーが質問に答えるスレ (309)
【GPGPU】くだすれCUDAスレ part6【NVIDIA】 (279)
【肥大化】C++ を見捨てたヤシ 2人目【複雑化】 (926)
C++は難しすぎ 難易度:4 (419)
【コボル】COBOL不要論【ただのDSLだよね?】 (350)
--log9.info------------------
【新潟】　上越新幹線　part39　【東京】 (580)
名鉄のパワハラについて語るスレ　2 (279)
駅間距離が異常に長いので新駅を作って欲しい区間 (666)
【せとでん】名鉄瀬戸線14駅目【印場】 (767)
E233系 Vol.32 (388)
俺の大佐倉 6 (508)
駅名しりとり【新ルール Part12】 (350)
【浜松】東海道線静岡口スレ70【熱海】 (553)
【直通大増発】九州新幹線U111【春臨！】 (380)
東武伊勢崎･日光線/東京メトロ日比谷･半蔵門線 106 (335)
おおさか東線3 (435)
JR東日本 211系転属 その4 (492)
■全国共通 女性専用車両 Part30■ (617)
鉄道しりとりしようぜ　part51 (908)
新潟県の鉄道 Part68 (879)
京王電鉄車両スレ　2013.02.16 (280)
--log55.com------------------
郵便局のアルバイト
【祝合併】日本郵便株式会社 Part2【お先真っ暗】
【クレーマー】要注意のお客様【DQN】
ブラック企業!世界ランクＮＯ１!日本郵政!
郵政民営化の見直しって　また国営化にするのか？
愚痴スレ
恐怖！！もう外国から国際郵便で日本へ送るな！！
JPU 日本郵政グループ労働組合 JPUその2