が有効なC/C++ファイル

Question

プリプロセッサの出力ファイルである私はg++ -E qwe.cpp > op4 は、次の出力に

を与えるとしてのみプリプロセッサを実行qwe.h

#ifndef QWE_H 
#define QWE_H 
//#include <iostream> 
int asd(); 
#endif 

qwe.cc

#include "qwe.h" 
int asd() 
{ 
std::cout<<"asdasd"; 
} 

として2つのファイルを持っています

# 1 "qwe.cpp" 
# 1 "<built-in>" 
# 1 "<command line>" 
# 1 "qwe.cpp" 
# 1 "qwe.h" 1 




int asd(); 
# 2 "qwe.cpp" 2 
int asd() 
{ 
std::cout<<"asdasd"; 
} 

プリプロセッサの出力を有効にしないでください。C/C++ファイル？ ステートメント "＃int string int"の意味は何ですか？

Answer 1

GCCは、プリプロセッサ出力ダンプを有効なソースコードにするために妥当な努力をしています。しかし、一般的な答えはいいえ、それはその目的のためではありません。

と一緒に-Pオプションを渡すと、より機械可読で人間が読めるようにすることもできます。より多くの空白が削除され、# 234 "blah.h"のマーカーは表示されません。

出力を有効なc/C++ファイルにするべきではありませんか？

プリプロセッサが行うことの大部分は、レキシング、またはソースのトークンへの分割です。次に、特定の規則に従ってトークンと空白を生成するマクロを展開します。マクロが空白で区切られていないトークンを生成する可能性があります。標準によれば、テキストとして直接レンダリングされたプリプロセッサの出力は、通常、正しいトークンに分割することはできません。

GCCは、余分な空白を導入することで、プリプロセッサの出力をテキストとして表現することができると期待していますが、他のコンパイラに移植することはできません。

Answer 2

これらは、ファイルが他のファイルに含まれる場所を追跡するために使用される行番号です。コンパイラの警告とエラーを生成するときに便利です。

ウィキペディアのthis articleを参照してください。

Answer 3

プリプロセッサの出力が有効なC++になるための言語要件はありません。プリプロセッサの出力が有効な場合でも、プリプロセッサの出力が有効な場合は、言語要件はありません。しかし、g ++が通常使う（おそらくは？）プリプロセッサは、それ自身がC++としてコンパイルできる出力を生成します。

の意味は？

#で始まる行は、プリプロセッサディレクティブあります。 #に続くトークンが認識されない場合、#の後の行の部分は、の非指示語です。 （名前にもかかわらず、の非指示語は前処理指令です。）非指令は通常無視されます。

通常、ディレクティブ以外のすべての前処理ディレクティブを処理するプリプロセッサですが、この場合は#で始まる行が無視されるコンパイラに渡されます。

あなたはコンパイラにプリプロセッサ出力を供給することによってこれを実証することができます

g++ -E foo.cpp > foo_preprocessed.cpp 
g++ -c foo_preprocessed.cpp 

foo.cppはプリプロセッサディレクティブ、特に#includeディレクティブを持っている場合は、foo-preprocessed.cppはおそらくずっと大きくなります - しかし、コンパイラはまだだろうそれを処理することができます。

言語標準では、texではなくトークンの観点からプリプロセッサ出力を定義していますが、必要なトークンシーケンスを表すのにテキストが有効なように十分な柔軟性があります。

（このすべてがCに同様にC++に適用される。）