プリプロセッサについて熱く語るスレ。

さぁ語れ。

プリプロセッサ嫌い。

LISP最強

プリプロセッサって何か中途半端感があるなぁ。Lisp みたいに言語機能として不可欠な物にも
なってないし、Java みたいに全く使わないって訳にもいかないし。

いっその事言語の外に出しちゃえば潔いのに。

多少の脱線は見逃してやるからCスレでやれ

#define DELEGATE(x,y) inline x() { return y::x; }
class File {
    stream str;
public:
    DELEGATE(open,str)
    DELEGATE(close,str)
};
ん-。返り血がなぁ。

>>4
> いっその事言語の外に出しちゃえば潔いのに。
何の「言語のの外」といいたいのか知らんが、一応CPPはC言語とは別。

本気で？

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

元々Cコンパイラ用に作られたのは名前が示す通りだが、言語的には別物。
たとえば#ifでsizeofを使えないのはそのため。

実際xmkmfとかxrdbはコンパイラではないけどcppを使ってる。

とりあえず、boost/preprocessor を。多分 C でも使えるだろ(適当
公式ドキュメント
　http://boost.org/libs/preprocessor/doc/

↓氏ね

プリプロセッサといえば、林晴比古の本！

↑氏ね

#define A 0
#ifdef A
...
ということがやりたいのですが、
...の部分の評価へと入ってきてしまいます。
#ifdef (A==0)
などと書かなくてはいけないんですか？

#undef A

拡張性の高い外部マクロプロセッサを教えてやろう。




Perl

m4…いや、何でもない。

もういい加減、プリプロセッサ捨てて
Scheme取り入れてもいいんじゃねえの？
boost/preprocessor/*を見てると涙が出てくる。

>>15
#if A
...

HOGE が定義されていない場合に関数 foo() を無効にする場合は

#ifndef HOGE
#define foo(x)
#endif

でいいのでしょうか？
一応動作しているようなのですが、どうするのが一般的ですか？
C、C++（共にVC++）での使用を考えています。

http://www.tv-asahi.co.jp/best/updating_dex/toppage/index.html

【田代まさしに仕事をやろう！！】
盗撮･覚醒剤所持などの理由で現在執行猶予中の田代まさし氏を
テレビ出演させて仕事をやろう！という主旨です。
『あの人は今？』の『投票する』項目を選べば投票フォームに入れます。
皆さんのご協力があれば、田代氏のテレビ出演は夢ではありません。

＊他スレにコピペをお願いします

#ifdef HOGE
#define FOO(x) foo(x);
#else
#define FOO(x)
#endif

>>21
okだと思います。

>>21
C++ならプロトタイプ宣言を#ifdefで囲めばいいけど、Cだとそうはいかないんだよな・・・

あー、無効ってそういう意味か。
NDEBUGが定義されている時のassertの挙動みたいなものか。

関数のプロトタイプがint Foo(int,int);だとしたら、
#ifdef HOGE
#define foo(x,y) Foo(x,y)
#else
#define foo(x,y) 0
#endif
こんな感じにしないといけないな。
消してしまうと、HOGEが定義されていなくてa=foo(a,5);こんなことするとエラーになる。
戻り値の型がvoidならそもそも受けようとするのが間違いだから消してもいいかもしれないけど。

ああ、俺の待ち望んだスレがある

>>26
void式でもカンマ演算子でつながれることを考えると、
消したら通らなくなるソースがあるかもしれない。
よって、
((void)0)

>>23-26
レスありがとうございました。

>>23
なるほど、間接的に指定するわけですね。
それを使わせて貰います。

>>24-26 >>28
そういった状況では気を付けます。

おまいら、プリプロセッサでやっちゃったバグを晒してください。

#ifdef HOGE

#endif
:
:
#define HOGE
:
:

もうアホかと。バカかと。

>>28
ああそうか。なるほど。

>>31
それと#include絡みの不具合はたまにやるな・

>>30
５０行くらいのでっかいマクロを\でつないで作った。
コンパイルエラーが全部同じ行で出るから作った本人以外原因がわからなかった。

テンプレートのエラーメッセージが分かりにくいって言っても、
これよりはやっぱりマシだと思った。

>コンパイルエラーが全部同じ行で出るから作った本人以外原因がわからなかった。

漏れの職場ならこの程度で原因分からない社員は派遣扱い、だな。ｗ

そういう意味ではELとかやばくね？

> コンパイルエラーが全部同じ行で出るから
デバッガ使えYO!! ていうか、50 行ぐらいデバッグできると思われ。

>>37
コンパイルエラーをデバッグで追えるのか。凄い人だなぁ。

コンパイラをトレースするんだYO!!

うへ。でもコンパイラ通らないエラーなら目で見て分かると思うんだけど…。

いいものを教えてやろう。-Eオプションというんだ。

(´-`).｡oO(…それは gcc だけなんじゃ…)

UNIX系のccはほとんど受け付けるよ。

由緒正しいccってのはどこのものなの？
UnixWareに入ってるやつ？

可児飯謹製

立地ーだろ。
可児飯はCコンパイラは作ってない。

pccって立地ーだっけ。

日本人の癖にヤンキー言うなヴォケが。

pccはJohnson

C99のPPってどうよ。

http://seclan.dll.jp/c99d/c99d02.htm

// any comment \
printf("hoge");

↑の２行をプリプロセスすると (1)一行目だけ消える (2)二行とも消える
のどっちが言語仕様的に正当なんでしょう？
つまり行継続の結合処理とコメント除去処理の順番は決まっているのかということです。

まず結合だと思った。

Cコンパイラに日本語通らなかった時代、日本語コメントの最後の文字の
二バイト目が\だと・・・というエラーで苦しんだことを思い出した。
「表」とかだな。

ヌヒ達よ。プリプロセッサと言えば、10年くらい前に林晴比古の書いたCプリプロセッサパワーだろ。
これぞ最強のプリプロセッサ本だ。もまえらも読め！

禿同。一部の人間はこの話題振ると、盛り上がったり
盛り下がったり・・・若さ故の過ちというかな。

坊やだからさ。

Cのマクロは色んな意味で危険なのだ。
マクロに関する障害報告は、少なくない。

（＾＾）

>>54の本を読んでみた。
誰でも思いつく以上のことは書かれていないような気がする。
##演算子を駆使したトリッキーなコードを期待していたせいもあって
つまらないと感じたし、実用性もイマイチだと思う。（もしかして##演算子が規定される以前の本？）
何か、もっといい教科書はないかね。

>>59
boost/libs/preprocessor/doc/index.html

>>60
thx!
あなたはどちらかというと神だ。

>>60-61
>>11
激しく基本。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

BOOST_PP_IDENTITY("保守")()

こんなのがあった。
ttp://www.m17n.org/mcpp/

>>7
ANSI-CではマクロもCの言語仕様の一部として
取り込まれているはずだが、、、

要するに
#includeや#defineの使えない環境はANSI-C対応とは
言えない。

逆にもしCPPとCを一体化して#〜のマクロも含めて
１つの言語仕様とみなして処理するようなコンパイラがあれば
それはANSI仕様に則っている。

つーか得られるバイナリが一緒ならコンパイラが何パスで実装されていようが
どうでもいい話ではある。

定義時ではなく使用時の選択によってON/OFできるassert
切り替えがちょっと面倒だが、なかなか便利ではないかな？

#include <boost/preprocessor/control/iif.hpp>

#define MY_ASSERT(xpr) BOOST_PP_IIF(ENABLE_MY_ASSERT, assert(xpr), (void)0)

#define ENABLE_MY_ASSERT 1
void f1(int i)
{
    MY_ASSERT(i > 0);/* 有効 */
}

#undef ENABLE_MY_ASSERT
#define ENABLE_MY_ASSERT 0
void f2(int i)
{
    MY_ASSERT(i > 0);/* 無効 */
}

ASSERT無効にする必要ないだろ。

assert より、むしろデバッグ出力の enable/disable とかに使えそうかな。

確かに。何か応用できそうだが。

名前空間付きのdefineがほしいとおもった今日この頃です。

名前空間って接頭辞に比べてどういう利点があるの？

>>72
不必要に繰り返さなくていい。

語ろうzw！

boost::order@sandbox なんかどーよ？

sandboxが見つからない…

一年ぶりぐらいにboost/preprocessorを触ったら
シーケンス型なんて出来てるじゃん。
・アレイ　(3, (a, b, c))
・リスト　(a, (b, (c, BOOST_PP_NIL)))
・タプル　(a, b, c)
・シーケンス　(a)(b)(c)

他にはどんなのがありえると思う？

・二分木　(a, ((b, (c, d)), e))

#define TMP BOOST_PP_CAT(BOOST_PP_, CAT)
#define TMP2 BOOST_PP_CAT(TMP,(in, t))
TMP2 i;

-> BOOST_PP_CAT(in, t)　までしか展開されない。

こんなふうにboostのマクロ名を生成したいんだけど
どうにかなりませんかね。

>>79
規格により、マクロの再帰は禁止されているので、あるマクロの展開中に
そのマクロが再び現れたとき、それは展開されない。だから、
BOOST_PP_CATが展開された結果にBOOST_PP_CATが含まれていても、
そのまま据え置かれる。
まったく別の問題だが、トークン'BOOST_PP_CAT'とトークン'('の連結は不定なので、
避けたほうが良い。この場合は単に並べておくだけで展開される。
以上を踏まえた、
#define TMP BOOST_PP_CAT(BOOST_PP_, TUPLE_ELEM) /* BOOST_PP_CAT以外のものを試してみる */
#define TMP2 TMP (2, 1, (void, int)) /* BOOST_PP_CAT を使わずに単にマクロと引数リストを並べる*/
TMP2 i;
はうまく int i; に展開された。

>>80
即レスどうもありがとうございます。

>規格により、マクロの再帰は禁止されているので、
となると、逆にCAT以外のマクロはCATを使って生成可能って
ことなんでしょうかね。

/* CATと名のつくマクロでBOOST_PP_CAT()を生成できるかテスト */
#define SEQ (BOOST_)(PP_)(CAT)
#define LIST (BOOST_, (PP_, (CAT, BOOST_PP_NIL)))
#define TMP BOOST_PP_SEQ_CAT(SEQ) (in, t)
#define TMP2 BOOST_PP_LIST_CAT(LIST) (in, t)
TMP iii;
TMP2 iiii;

->int iii;
->BOOST_PP_CAT (in, t) iiii;
詳しくは分りませんが、LIST_CAT()ではCATを内部で
使っているのかもしれません。

>トークン'BOOST_PP_CAT'とトークン'('の連結は不定なので、
>避けたほうが良い。この場合は単に並べておくだけで展開される。
そうなんですか。実際マクロを生成するときはマクロ名と
パラメータ部分は別々に生成することが多いと思うので、ここで
CATを消費しなくていいのは助かりますね。

C99非対応のプリプロセッサでマクロの可変個引数をエミュレートする
方法を思いついたが、この余白はそれを書くには狭すぎる。。。

>>82
書いて書いて！

つか、可変個引数のマクロって誰が入れたのか知らんけど
あんまりありがたくないような。。。
それにC99が使われるのってあと5年は先なんじゃ。

はっきりいってマクロさえあれば、テンプレートなんて要らないね。
C++の多くの機能も要らない。プリプロセッサマンセー

そうか、C99では可変個引数のマクロが使用できるのか。
いい事聞いた。

>>76
ttp://groups.yahoo.com/group/boost/files/Order/

>>87
すげー。としか言いようがない。
いい物を教えてくれてありがとう。
関数型言語ﾏﾝｾｰ
プリプロセッサ ﾏﾝｾｰ
Church(誰？)ﾏﾝｾｰ

ところで実装は手に入らないの？
禿しく気になるのだが。
名前空間つきマクロに応用できないかな。

ちょっと冷静になってみる。

標準入力に当たるものが無いようだから
使いまわしのできるコードジェネレータは作れないだろうが、
たいていのものは表現できるだろう。
何にしても、BOOST_PP_*の特異な文法や
長ったらしいマクロ名にうんざんりしてる人には朗報かも知れぬ。
GCC依存なのが気になるところだが。

もう少し本気で作られたプリプロセッサが欲しい所
プログラムを作るのにも繰り返しの多いものはあるのだから、プログラムを作るプログラムの存在は不可欠だと思うんですがね。
今のプロプロセッサはあまりにもおまけ的要素過ぎる。

>>90
m4マクロみたいなのをデフォルトスタンダードに
してしまうとか？boost/preprocessorみたいに
プリプロセッサ用にヘッダファイルライブラリを
インクルードするよりは、マクロ定義ファイルは
別でインクルードした方がいいような気がするけど。
まあこれはあんまり関係ないか。

GNU m4, version 1.4
http://homepage1.nifty.com/bmonkey/doc/m4-ja.html

>>83
#include <boost/preprocessor.hpp>
#define CHECK(test, operand) CHECK_1(BOOST_PP_CAT(CHECK_RESULT_, test operand))
#define CHECK_1(comp) CHECK_2(comp)
#define CHECK_2(res, _) res
#define CHECK_RESULT_1 1, BOOST_PP_NIL
#define IS_N_ARY(n, operand) CHECK(BOOST_PP_CAT(IS_N_ARY_CHECK_, n), operand)
#define IS_N_ARY_CHECK_0() 1
#define IS_N_ARY_CHECK_1(_1) 1
#define IS_N_ARY_CHECK_2(_1, _2) 1
#define IS_N_ARY_CHECK_3(_1, _2, _3) 1
#define IS_N_ARY_CHECK_4(_1, _2, _3, _4) 1
#define IS_N_ARY_CHECK_5(_1, _2, _3, _4, _5) 1
#define IS_N_ARY_CHECK_6(_1, _2, _3, _4, _5, _6) 1
#define IS_N_ARY_CHECK_7(_1, _2, _3, _4, _5, _6, _7) 1
#define IS_N_ARY_CHECK_8(_1, _2, _3, _4, _5, _6, _7, _8) 1
#define TEST_FAIL 0, BOOST_PP_NIL
#define CHECK_RESULT_IS_N_ARY_CHECK_0 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_1 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_2 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_3 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_4 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_5 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_6 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_7 TEST_FAIL
#define CHECK_RESULT_IS_N_ARY_CHECK_8 TEST_FAIL
#define COUNT_TUPLE_SIZE(tuple) BOOST_PP_TUPLE_ELEM(2, 0, BOOST_PP_WHILE(COUNT_TUPLE_SIZE_PRED, COUNT_TUPLE_SIZE_OP, (0, tuple)))
#define COUNT_TUPLE_SIZE_OP(d, data) (BOOST_PP_INC(BOOST_PP_TUPLE_ELEM(2, 0, data)), BOOST_PP_TUPLE_ELEM(2, 1, data))
#define COUNT_TUPLE_SIZE_PRED(d, data) BOOST_PP_NOT(IS_N_ARY(BOOST_PP_TUPLE_ELEM(2, 0, data), BOOST_PP_TUPLE_ELEM(2, 1, data)))

可変個引数をエミュレート、とはいっても
単にタプルの要素数を数えるマクロだが。
CHECKのアイディアはboost/preprocessor/detail/check.hpp
からいただいた。暇なﾔｼは参照してみるといい。
ちなみにGCC以外だとまともに動かん。GCCでも山のように警告が出る。

>>93みたいなのを見るともっとまともなPPがあればと思うよ。

「フェーズ・エラーが発生しました。」って見たことある人いないですか？

>>93にも関連するんだけど、

#define EXPECT_ONE_ARG(_) ok
EXPECT_ONE_ARG(1, 2)

は、どう展開されるのが規格にのっとってるの？
ちなみに、GCC(MinGW)だとプリプロセスエラー、
VC7だと警告つきでokに展開される。
展開されずにそのまま残るのが正しい気もするんだけど。

age忘れ

引数１つを期待してるなら
EXPECT_ONE_ARG((1, 2))
とすべき。
あとは知らん。
つーか参考書買え。

読み返してみると、質問する態度じゃなかったですね。改めます。

聞きたかったのは、定義時に指定する引数の数と
呼び出し時に使われた引数の数が一致しない場合についてです。
プリプロセッサの性格から考えると展開されないで放置されるのが
自然な気もするんですが、実際にはそうなっていないので、
規格上はどうなのか知りたかったのです
宜しくお願いします。

＞考えると展開されないで放置されるのが
＞自然な気もするんですが

とっても不自然ですはい。

#define ADD_STD_NAMESPACE(in) std:: #in

としてみたのですが、::に#で結合することができないとエラーがでます。
こういうときのどうしたらよいでしょうか？

マクロ定義内の#は文字列に変換するだけですが・・。

間違いました。

#define ADD_STD_NAMESPACE(in) std:: ##in

よろしくお願いします。

ごめんなさい。
ものすごいかんちがいしてました。

#define ADD_STD_NAMESPACE(in) std::in
でよかったんですね。あらしてごめんなさい

>>91
m4があとちょっと、あとちょっとまともなら、世界を
制覇できたと思うんだが。さすがに今更作っても需要
無いと思うけど。

>>97
>>93はGCCで通ると書いたが、間違いだった。
申し訳ない。

#define CAT(a,b) a##b
#define COMMENT CAT(/,/)

↑俺が考案したサイキョウマクロ


使い方

COMMENT a++;

でa++;はコメントアウトされる。

#define COMMENT

とすればコメントアウトされなくなるという非常に便利な一品。オマイラ使え。俺は使わん。

>>108
つ、突っ込んでほしいのか？

もう一個考えたサイキョウマクロ

#define CAT(a,b) a##b
#define COMMENT_BEGIN CAT(/,*)


COMMENT_BEGIN

ここに書いたものがコメントアウトされる

/**/


どうよ？

#ifdefでいいじゃん、とか思うだろ？ちゃうねん
COMMENT_BEGINはマクロの中に入れれるっていう利点があんのよ。オマイラ使え。

晒しアゲ

110を見て思いついた。
/*
...
/*/
...
/**/

コメントのif-else-endif

>>108
VC++とg++でプリプロセスで処理される順番ちがうんだよね。
そのテのマクロってg++だと通らないんじゃないかなぁ？

この順番って規格で定まってたっけ？

いまいち盛り上がらないね、だれかマクロメタプログラミングとか語らないかな・・・

LISPみたいなマクロ

C++ならOpenC++
JavaならEPP

他にある？

>>115
EPPに興味あるんだが、作り方がわからん・・・
参考になるスレかサイトありますか？

afe

プリプリしてるのは最高だね！

#if defined( _MSC_VER )
// value compiler
//　1200 VC++6.0
#if defined( _WIN64 )
// Windows XP 64-bit
#elif defined( _WIN32 )
// Windows9x/ME/NT3.x/NT4.0/2000/XP 32-bit
#elif defined( _WIN16 )
// Windows3.x
#endif
#if defined( _M_IX86 )
// Intel, NEC
#elif defined( _M_ALPHA )
// Alpha
#endif
#if defined( _WINDOWS )
// gui
#elif defined( _CONSOLE )
// console
#endif
#if defined( _USRDLL )
// dll
#endif
#endif //_MSC_VER

というわけで環境判別に便利な定義済みマクロ教えてくださいな。

環境判別をマクロでやるのはどうもなあ。

>>114
それってこういうののことかい？
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/mac.h.html

CPPを使った面白いのっていうと、IOCCCぐらいしか
思いつかないな
http://ioccc.org/1988/westley.c
↑こういうのとか

別に面白くないけど

メタプログラミングってのは>>87みたいなのじゃないの？

#define FIB(n) ((n==1 || n==2)?1:FIB(n-1)+FIB(n-2))

>>125
もしやと思ったがGCC3.2.3のcppではだめだった．残念．

#define BOOST_ORDER_DEF_linear_fib(n)   \
8DERIVED,                               \
  linear_fib_3(n,0,1)

#define BOOST_ORDER_DEF_linear_fib_3    \
8OP_N,(N,I,J),                          \
  if(is_0(N),                           \
     I,                                 \
     linear_fib_3(dec(N),J,add(I,J))),

#define FIB(x) BOOST_ORDER_EVAL(liner_fib(x))

全く理解できんな。

>>126
マクロの再帰ができないのは有名な話。
やるとすればこのあたりかな？
http://www.boost.org/libs/preprocessor/doc/examples/linear_fib.c

hsh

保守

相互再帰でも駄目

#define FIB_L(n) ((n==1 || n==2)?1:FIB_R(n-1)+FIB_R(n-2))
#define FIB_R(n) ((n==1 || n==2)?1:FIB_L(n-1)+FIB_L(n-2))
main() { printf("%d\n",FIB_L(32));}
エラー：未解決の外部シンボル _FIB_R が関数 _main で参照されました。

仕様決めた奴頭悪い。
#define内で#defineが使えない時点で頭の程度はわかってたが。

>>131
再帰ができたとして、終了条件はどうするつもりだ？

cppは必ず展開するから、再帰可能にしたら止まらなくなる。

中途半端に展開されるよりはマシの様な

>>132
あ、そっか（ｗ
結局nとかもただの置き換えなんだよな。
マクロ展開時にn==1とかを解釈する仕様じゃないと駄目だ。

頭の悪い131がいるスレはここですか？
と煽ってみる。

>>121
じゃあ環境判別はどうやってやるの？

>>137
>>121 の考えてることと違うかもしれないしちょっと補完気味だけども。
例えば UNIX 文化圏では「定義済み」マクロで環境判別するよりも、
それぞれのライブラリ、関数が利用可能か不可能かを判別するほうが望ましいとされる。
んで、大抵の場合、これをやるのが configure スクリプト。

まぁ、実際には、結局 HAVE_HOGEHOGE みたいなマクロで判別するんだけどね(w

>>138
> それぞれのライブラリ、関数が利用可能か不可能かを判別するほうが望ましいとされる。
それができるようになったのは、autoconf以降なわけだが。

>>139
無論 Autoconf を念頭において書いている。
っていうか、
> それぞれのライブラリ、関数が利用可能か不可能かを判別するほうが望ましいとされる。
に該当する部分が Autobook の中にないかなーと、ちょっと探しちゃった。

ttp://sources.redhat.com/autobook/autobook/autobook_8.html#SEC8
によると、Autoconf は 1992年までに開発が開始されたみたいだけど。
最近すぎるぞ、ｺﾞﾙｧってことなの？

>>140
「UNIX 文化圏では」というにはちょっと新しいかな、と。

#defineだけでプログラム書ける

#define INCLUDE #include<stdio.h>
#define MAIN int main() {
#define MAIN_END }
#define RETURN return 0

INCLUDE MAIN RETURN MAIN_END

ばーか

#define define int main(){}
define

激しく保守

#define begin {
#define end }

フツーに日本語の文章なんかをプリプロセスするってできないですか？

#define SYOUSAI_1 ○○機能の詳細

例:
…あーだこーだ、オプションについてはSHOUSAI_1を参照。

とか。

#define SYOSAI_1 "○○機能の詳細"
"…あーだこーだ、オプションについては" SHOUSAI_1 "を参照。"

…読みにくいですね

>>148
やっぱだめですかそうですか。

海外掲示板用オフラインリーダーを作るスレ
http://pc2.2ch.net/test/read.cgi/tech/1072883528/

海外でよく使われていうる掲示板スクリプト
専用のオフラインリーダー作って下さい。

必要な条件はID、PASSを管理できること、
OpenJaneみたいな三面型の見た目。
簡単にローカライズできるように言語ファイルを採用

#演算子のオペランドが展開されないことを利用してBBOOST_PP_IFやら何やらの遅延評価を
目指してるんだが、下のコードで、IGNORE(CAUSE_ERROR)はエラーにならないのに
IGNORE_X(CAUSE_ERROR)がエラーになるのはなぜだ？わかる人がいたら教えてくれ。

#define THREE_ARG_MACRO(x, y, z)
#define CAUSE_ERROR THREE_ARG_MACRO(foo) /* 展開されたらエラー */

#define EAT(_)
#define IGNORE(x) EAT(#x) /* 引数xを展開せずに飲み込む */
#define IGNORE_X(x) IGNORE(x) EAT(#x) /* 間接的にIGNOREを呼ぶ */

IGNORE(CAUSE_ERROR) /* ok */
IGNORE_X(CAUSE_ERROR) /* macro "THREE_ARG_MACRO" requires 3 arguments, but only 1 given */

>>151
IGNORE_X→IGNOREでxを評価してCAUSE_ERROR以降を評価するから。
かなあ？
function-like macroの繰り返し展開は泥沼なのでよくわからん。

>>152
レスサンクス。お陰で理解できた。
>IGNORE_X→IGNOREでxを評価してCAUSE_ERROR以降を評価するから。
どうもこの通りみたいで、仮引数実引数置換のときにxを展開するらしい。
ちなみに、IFに関してはちょっとしたトリックでこの問題を回避できるようだ。

#include ">>151"

#define CAT(a, b) a ## b
#define LAZY_IF(c) CAT(LAZY_IF_, c)
#define LAZY_IF_0(x, y) y EAT(#x)
#define LAZY_IF_1(x, y) x EAT(#y)

#define RESULT ok
#define COND 1

LAZY_IF(COND)(RESULT, CAUSE_ERROR) /* エラーを起こすことなくokに展開される */

昔からモトローラのアドレシングモード表記が大嫌いで、
Ｈ８使う羽目になったときザイログ式で表記するために
プリプロセッサ作ったなぁ。

保守上げ

遅レスだが、
>>151
C99が使えるなら、
#define IGNORE_X(x, pm) IGNORE(pm ## x)
IGNORE_X(CAUSE_ERROR,)
でいけるぞ。

///*
hogehoge();
hoge();
foo();
//*/

こんな感じで、CのコメントをC++のコメントでコメントアウトして使っている。
先頭の「///*」を「/*」に変えると、一気にコメントアウトされて便利。
VC++でしか動作確認とってないから、他だとどうなるか知らんけど

>>157
#if 0
hogehoge();
hoge();
foo();
#endif

にして、0 と

途中で書き込んでもた。

>>158 訂正

#if 0
hogehoge();
hoge();
foo();
#endif

にして、0 と 1 を書き換えれば環境依存もないはずだが。

CのマクロはLISPの様にインライン関数にも使えないし、
評価の制御も無理で、常にシンボルの衝突の危険を強いられる。
解決したとしてもexpression中にcompound-statementは書けない。
せめてこれぐらいの自由度が欲しい。

#define macro_double(x) \
　#let y = gensym() in \
　{ int y = x; return y * y; }

f(x){printf("f(%d\n)\n",x);return x;}
main() { printf("%d\n", macro_double(f(1))); }

↓macro-expand

main() {
　printf("%d\n", {int g1 = f(1); return g1 * g1; }); // error
}

>>160
Cでは内側の名前は外側の名前を隠すから、シンボルの衝突は問題ないと思われる。
どちらにしてもインライン関数としてマクロを使うのは無理があるだろうが。
標準にもinlineが導入されたし、GCCにはマクロから値を返すための独自拡張があるくらいだからな。

ところでお前ら、Cプリプロセッサで直接的に再帰を行うscan recursionてどうよ。
ttp://aspn.activestate.com/ASPN/Mail/Message/boost/1609570
古い話題スマソ

アホかと

>>161
>Cでは内側の名前は外側の名前を隠すから、シンボルの衝突は問題ないと思われる
# define swap_int(a, b) do{int temp = a; a = b; b = temp;}while(0)
int x, temp;
swap_int(temp, x);
こんなのは悲惨なことになるぞ。

>>163
ｃでは

int foo = foo;

なんて訳の分からない書き方が許されてしまう罠。
GCC は昔これを許さない構文を導入したい、とか言ってたけど。

間違ってあげてしまいました。
吊って来ます。

>>157
//* ←のスラッシュは2つでもいい。
hogehoge();
hoge();
foo();
//*/

// による /* の無効化は C99、C++98 のいずれでも有効みたい

別にC99コメントに頼らなくても
/*
hogehoge();
hoge();
foo();
/**/
でいいんじゃないか？

>>168
確かにそうやってるソースを見たことがある。
…でもネストが崩れてるので落ち着かないんだよな。
つか、ソースのコメントアウトには #if を使えと言いたい。

こんなの見つけた
http://www.pp.iij4u.or.jp/~nabe/c/c_lang/clang07.html

ていうか
http://www.sun-inet.or.jp/%7Eyaneurao/intensive/tips2.html
ここのTips67ではダメなのか？
#if 0 〜 #endifよりも/* */の色分けに対応しているエディタの方が多いから
C++とか // 形式のコメントが使えるならこっちの方が見やすいかと思ってるけど。

ところでコメントってプリプロセッサの仕事だっけ？
コンパイラの仕事じゃなくて？

>>171
>ところでコメントってプリプロセッサの仕事だっけ？
コメントはマクロ展開よりも前に処理されることになっている。
コメント全体を一種の空白とみなせばプリプロセス後まで残すこともできるだろうが。

どっちにしても、コメントの話題がすれ違いならこのスレは終わりだな。

あ、いや済まん。純粋に疑問だっただけだ。
そうかコメントはマクロ展開より前に処理なんだな。
まあ別にプリプロセッサとコンパイラと明確に分ける必要もないんだろうが…

とりあえずgccで-Eオプションをつけた出力だとコメントはすでに消えていた。
詳しくはわからんけど、コメントの話題がスレ違いということはなさげ。

>>171
確かに色分け考えると見やすいかもしれんが、個人的にはすっきりしない。
通常の注釈は //、ブロックの無効化は /*, */ という形ではっきり分かれてるならいいんだけど、
必ずしもそうではないし。新しい記号だと思えばいいのかもしれんが。
注釈は //, /*, */、 ブロックの無効化は #if, #endif という規約だと、意味づけと表記を対応した形で
分けられるんでこっちの方が好きなのよ。

#define BIN(x) ( \
(((x) / 1 & 1) << 0) + \
(((x) / 10 & 1) << 1) + \
(((x) / 100 & 1) << 2) + \
(((x) / 1000 & 1) << 3) + \
(((x) / 10000 & 1) << 4) + \
(((x) / 100000 & 1) << 5) + \
(((x) / 1000000 & 1) << 6) + \
(((x) / 10000000 & 1) << 7))
こんなのだめ？

>>175
すまない。意図かあるいは使用例あたりを示してはくれまいか。

>>176 おそらく二進定数だろう

なるほどこういうことか
printf("%d\n", BIN(1111)); // 15
printf("%d\n", BIN(1110)); // 14
printf("%d\n", BIN(1101)); // 13
printf("%d\n", BIN(1100)); // 12
printf("%d\n", BIN(1011)); // 11
printf("%d\n", BIN(1010)); // 10
printf("%d\n", BIN(1001)); // 9
printf("%d\n", BIN(1000)); // 8

だがこの調子で行くと7以下は微妙だな…
printf("%d\n", BIN(0111)); // 3
printf("%d\n", BIN(0110)); // 2
printf("%d\n", BIN(0101)); // 1
printf("%d\n", BIN(0100)); // 0
printf("%d\n", BIN(0011)); // 1
printf("%d\n", BIN(0010)); // 0
printf("%d\n", BIN(0001)); // 1
printf("%d\n", BIN(0000)); // 0

Prefix 0 はCの仕様として8進定数になってしまうから
桁を揃えようとすると上手くいかなくなる…
もちろんBIN( 111)とやればうまく7になるんだが、
二進で定数書きたいときは普通桁そろえたいよな…

こんなの見た事が。
enum {
b0, b1
};
enum {
b00, b01, b10, b11
};
以下似たような奴の羅列。

強引に8進定数にすればいいじゃないか
#define BIN(x) BIN_I(0 ## x ## u) /* uは気休め */
#define BIN_I(x) ( \
(x >> 0 & 1) << 0 | \
(x >> 3 & 1) << 1 | \
(x >> 6 & 1) << 2 | \
(x >> 9 & 1) << 3)

int i[BIN(1111)]; /* 15 */
int j[BIN(0010)]; /* 2 */

>>178,180
�dクス
授業中に考えたんで8進定数の存在忘れてました。
180の使わせてもらいます。

ageっと

#define NUM 100
#NANNTOKA (perl -e "printf('%x', (NUM))")

とかしたらNANNTOKAがperlからの標準出力を
ソースに埋め込むみたいな、そんな機能は
ありませんか？

そんな機能はありません。

>>183
#if 0
#!/usr/bin/perl
while <__DATA__> {
s/hogehoge/mosamosa/
}

__DATA__
#endif

perlはよく知らんけど、やろうと思えばこんな感じではできるんじゃない？
コンパイルする前にper;に読ませる必要があるだろうけど。

プログラムの標準出力をファイルにマップするようなファイルシステムがあれば良いんだが、
unixの「名前つきパイプ」って使えたっけ？

>>186
http://forum.nifty.com/fdelphi/samples/01273.html

183からちょっと発想を拝借して

#include "|perl code.pl"

こんな感じでスクリプトの実行結果を取り込めないかなー。
cygwinではだめですた。

erbでも使えば

>183,188
makeで十分ですよ。分かって下さいよ。

>>190
make でどうやんのか教えろ！

こんな感じ？

(Makefile)
all: dynamic.c dynamic.h
　　gcc dynamic.c
dynamic.h: code.pl
　　perl code.pl > dynamic.h

(code.pl)
print <<"CODE";
#include <stdio.h>
int do_dynamic() { return puts(":)"); }
CODE

(dynamic.c)
#include "dynamic.h" /* for do_dynamic() */
int main(int ac, char *av[]) { return do_dynamic(); }

>>192
ヘッダ中に
#define NUM 100
とあって、コード中でNUMを外部コマンドに
食わせて何か出力を得たいような場合はどうやんの？
基本的にパラメータはヘッダで定義。これは譲れない。

>>193
cpp -dMの結果でも解析汁

>193
sed

つーかそういうdefineは、コマンドラインから与えるのが良識的だと思うが。

プリプロセッサのすれなんだからプリプロセッサでコード生成しろよ

メンバ変数のメンバ関数を外側のクラスメンバにエクスポートするような
マクロを以下のように定義しましたが、コンパイルがとおりません。何処が問題でしょうか？

#define GET_FUNCTION(func,type,obj) type Get##func(){return obj##.Get##func();}
#define SET_FUNCTION(func,type,obj) void Set##func( type newVal ){ obj##.Set##func( newVal ); }
#define DEF_FUNCTION(func,type,obj) GET_FUNCTION(func,type,obj)\
SET_FUNCTION(func,type,obj)

例)
DEF_FUNCTION( TransitionType, int, m_aaa )

もちろんm_aaaには、GetTransitionTypeというメンバ関数があります

開発環境 VC++6.0 sp6
エラー
error C2061: 構文ｴﾗｰ : 識別子 'TransitionType' がｼﾝﾀｯｸｽｴﾗｰを起こしました。

age

>>197
'\'が行末にないからじゃね？
同じvc6sp6で通ったよ？
シンボルの未定義エラーはでたけど、構文エラーにはならなかった。

それとさ、/Pオプションでマクロの展開内容が*.iファイルに出力されるから
覚えとけ。

##はトークン結合。
.は独立したトークンだから、結合してはいけない。

#define GET_FUNCTION(func,type,obj) type Get##func(){return obj.Get##func();}
#define SET_FUNCTION(func,type,obj) void Set##func( type newVal ){ obj.Set##func( newVal ); }
#define DEF_FUNCTION(func,type,obj) GET_FUNCTION(func,type,obj)\
SET_FUNCTION(func,type,obj)

>>197
obj##. の ## は要らなさそう。

ついでに、/Pオプションでの出力結果

int GetTransitionType(){return m_aaa.GetTransitionType();}void SetTransitionType( int newVal ){ m_aaa.SetTransitionType( newVal ); }

>>198-203
色々有難う御座いました
全然違うところでミスってましたTT

/P
は試してみたんですが、展開されていなかったので???と思ったんです。
そうしたら

#ifndef ... #endif

で見事に、定義がとばされていましたw

ｼﾈ

特定の言語に依存しないPP
ってありませんか？

m4とか

というか、gccではc++からしてPP扱い。

VisualStudioで、下に示す感じで
#include "stdafx.h" を制御してやろうと思ったのに
"fatal error C1020: 予期しない #endif です。"
というメッセージが出てコンパイルが通りません。なぜでしょう。

目的は、VC とそれ以外のコンパイラで動くソースを作りたいです。

#ifdef WIN32
#include "stdafx.h"
#endif

#include <stdio.h>

int _tmain(int argc, _TCHAR* argv[])
{
printf( "hello, world\n" );
getchar();
return 0;
}

//-----stdafx.h-----------------
// #pragma once
//
// #define WIN32_LEAN_AND_MEAN
// #include <stdio.h>
// #include <tchar.h>
//--------------------------------

>>209
ほんとだ、プリコンパイル済みヘッダの場合だけエラーになるね。
VC のバグじゃないかな。
対策としては、stdafx.h 内で #ifdef WIN32 したらどうかな。

>>163
> # define swap_int(a, b) do{int temp = a; a = b; b = temp;}while(0)

こういうのって、

# define swap_int(a, b) { int temp = a; a = b; b = temp; }

だけじゃだめなの？
なんでわざわざ do 文にするの？

>>209
VCは #include "stdafx.h" を発見するまで読み飛ばすようになってる。
たとえば
#include "hoge"
#include "stdafx.h"
と書いても、 "hoge" は無視される。

730 は名前消し忘れ

>>211
if (mememe) swap_int(a,b);
else momomo;

>>213
ありがとう！そういうことでしたか。

#define STRDUP_HEADER <string.h>
#include STRDUP_HEADER

↑こんな使い方って問題あります？
VC ではとおりますけど、実際にこういう使われ方を見たことがない。

>>215
問題ない。Boost.Preprocessorでは多用されている。

>>215
問題ない。少なくとも C++ では、規格中の 16.2 -4- に記述がある。
STLport のコンフィグで使われてるのを見たことがある。

__LINE__とかの展開ってプリプロセッサじゃなくてコンパイラが行うっていう理解でいいんでしょうか？
VC6++のASSERTマクロの実装みたら中で__LINE__してあったもので

>>218
いや、プリプロセッサだろ。
「__LINE__してある」って何？それが__LINE__の展開をコンパイラが行っている根拠になるの？

>>218
'#define' の右側に現れたトークン列はその場では展開されない。たとえば、
# define A result
# define X A
# undef A

X /* 'result' ではなく 'A'に展開される。 */

__LINE__の扱いは通常のマクロと同じ。
/* hoge.h line 7 */
# define MACRO __LINE__

/* hoge.c line 133 */
MACRO
このとき、MACROは次のように展開される。
MACRO
-> __LINE__
-> 133

>>220
218じゃないけど、勉強になった

>>219
VCにプリプロセッサ展開オプションをつけたことはないのですか？
荒れるげいいんになるので、解らないなら書き込まないでください。

プリプロセッサの展開をトレース実行してくれるツールってないでしょうかねぇ。
VC のデバッガみたいに、ブレークポイントを設定したり、ステップ展開したり
できるといいと思わないですか？

>>223
トレース実行じゃないけど、waveなら、
#pragma wave trace(enable)
すれば、マクロ展開の様子をトレースして結果をファイルに出力できる。

waveは
ttp://spirit.sourceforge.net/index.php?doc=docs/wave_v1_0/index.html
ね。

>>210 >>212
209です.

そういうことでしたか、どうもありがとうございました。
今はMacintoshから書き込んでいるので、
プリコンパイルヘッダの件については後でやってみます。それではBYE!

>>222
ごめん。意味わからない。

お前ら！おもしろそうなものができてますよ

Chaos Preprocessor
http://sourceforge.net/projects/chaos-pp/

>>228
これどんなことできるの？
誰か分かりやすく教えて君。

>>229
chaos-ppとorder-ppがあって、どっちも基本的には
プリプロセッサを使ってコード生成をするためのライブラリ。

chaos-ppの方はboost::preprocessorの方向性を推し進めたもので、
無限精度整数とか文字列とかラムダ式とかが扱えるらしい。

order-ppは、プリプロセッサの上で動く関数型言語のインタプリタの実装で、
ユーザーはこの言語を使ってコードジェネレータを書く。たとえば
http://cvs.sourceforge.net/viewcvs.py/chaos-pp/order-pp/example/average.h?view=markup
には、この言語（8がたくさん出て来る奴）を使って実装された
平均を計算するコードを生成するマクロがある。

ありがとう。
だけどあんまり便利そうじゃないねぇ。。。

出力コードが想像できないと
デバッグ大変そうだな

面白ければそれでよし。実用性なんて2の次

あ、でもプリプロセッサであんまり沢山処理するよりは、
BOOST_PPみたいにリストの基本的な操作に限定して、
テンプレートメタプログラミングの方であれこれ
やるのが今風のような。
BOOST_PPは今から新たに機能拡張していくつもりあるのかな？

>>235
C99に対応したBOOST_PPなんかあったら面白いかも

プリプロセッサという考え方は、
未成熟な言語を補助するための苦肉の策にすぎない。

>>235
boost::preprocessorの作者は二人で、その二人が
orderとchaosを一つずつ開発してるっぽい。
もうboost::preprocessorは飽きたんじゃないかな。

PHPとかePerlとか、埋め込み型スクリプトをプリプロセッサ代わりに使うのって面白そうな気もするんだが、おまいらどうおもう?

ほしゅさげ

age

waveのpragmaに>>183みたいなのがあるな。

#define AAA 999
が定義してあって

int a = AAA.AAA
が置き換えられるとする。
結果がコンパイラによって違うんだけど、どっちが規格に準拠してるのかな？

・cl.exe(MSのC/C++コンパイラ)の場合
int a = 100.AAA

・gccの場合
int a = 100 . 100

>>243
トークンの生成（tokenization）はマクロ置換の前だから、gccが正しい。
VCのプリプロセッサはうんこ。

よく見てなかった。どっちもだめだな。

>>243 なんで展開結果に999が現れないんだ？

>>246
すいません間違えてました。正しくはこうです。

#define AAA 999
int a = AAA.AAA

・cl.exe(MSのC/C++コンパイラ)の場合
int a = 999.AAA

・gccの場合
int a = 999 . 999

死んじゃうよ

マクロ内部でランダムなシンボルをどうにかして
使用する方法はないでしょうか？

#define HOGE int <ランダムなシンボル>

みたいな。

ついでに保守

なんに使うんだよ。
他のスクリプトで自動生成すれば？

>>251
おなじブロックで2度呼ばれたり、ネストして呼ばれたりすると
シンボルがかぶってしまうからです。

>>252 それはランダムじゃ解決しないだろ。

>>253
たしかに^^;
行番号とかファイル名とかで生成できたらよいのですが。。。

__LINE__ や __FILE__ を使え。

>>255
それだけではシンボルを作れません

#define HOGE int HOGEX(XXX, __LINE__)
#define HOGEX(A,B) A##B

回答ありがとうございます。でも
同じ行で2回使われると対応できないですね。。。

gcc 限定とかなら XXX を __function__ に置き換えたりする手もある。

プリプロセッサでやろうという考えが間違い

プリプリプロセッサでも作れば？

>82
フェルマー乙

まあここの連中はLISPでも覚えなさい

>>263
トークンレベルでいじれるからこそ楽しいわけで。

大いに関係ないが、lisp系はcppで構文解析できる稀な言語だと思う。
誰かschemeインタプリタでも書かないか？

age