[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
762: デフォルトの名無しさん [sage] 2020/10/29(木) 21:05:36.10 ID:K8k/YFeK(1) AAS
>>760760(1): デフォルトの名無しさん [] 2020/10/28(水) 12:47:58.74 ID:Mf8tEr2f(2/2) AAS
>>758
解決しようとした人は *ｂｙ や python や D を造ってしまいましたね
既存の C/C++ そのものに手を入れるのは中の人以外には無駄な努力に感じます
再帰マクロ専用の ぷりぷりプロセッサを書くのは手かも知れません
あと #include __FILE__ でループしてる人はいるようです
外部ﾘﾝｸ:qiita.com
スレ違いだが通りすがりに言っておくと、
マクロにそこまでの機能を求めるのなら、
自前でスクリプト言語(AWK/Perl/Python/Ruby)等でソースの事前処理をmakefileに書いた方がいい。
それだと無限に機能拡張出来る。
だからC++というかmakefileシステムでそれをやる意味はない。
よってまともな奴は誰もマクロの拡張なんかしようとは思わない。
「言語」にそれを持たせる意味がないから。
(言語による垂直統合ではなく、makefileによる水平分業で全く問題ないし、融通も利く）
ただしGoはそれを標準機能で付けてる。
これがどう役に立っているのかは知らん。
(Go generate、AST木が参照出来るので上記のマクロ拡張とは次元が違うが)
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s