C ++ 11では、標準は2.2.3で次のように述べています。
各コメントは1つのスペース文字に置き換えられます。改行文字は保持されます。
そのフレーズはシーケンシャルですか?つまり、コメントの改行を保持し、改行で終了しますか?
(1)が真の場合、なぜVisual C ++、gcc、およびclangは、マルチコメントの各行に対して空の行を保持します。
私はc++プリプロセッサを書いているので、この質問は重要です。
C ++ 11では、標準は2.2.3で次のように述べています。
各コメントは1つのスペース文字に置き換えられます。改行文字は保持されます。
そのフレーズはシーケンシャルですか?つまり、コメントの改行を保持し、改行で終了しますか?
(1)が真の場合、なぜVisual C ++、gcc、およびclangは、マルチコメントの各行に対して空の行を保持します。
私はc++プリプロセッサを書いているので、この質問は重要です。
それが話している新しい行は、コメントが単一のスペース文字に置き換えられた後もまだ存在している行です。これは、スニペットが含まれている段落のより大きなコンテキストで表示される場合に、より明確になります。
したがって、具体的には、複数行コメントの新しい行は保持されず、前処理ディレクティブを終了しません。
AC / C ++プリプロセッサはすべてのコメントを削除しますが、プリプロセッサの出力を見ると、通常、ソース行は同じ行番号に保たれます。
これは、プリプロセッサ出力を読み取るコンパイラがエラーメッセージと警告の正しい行番号を出力できるようにするためです。
プリプロセッサは通常、すべての空の行をそのまま保持します。
また、ソースから削除される複数行マクロと、それらが展開されるタイミングを厳密に区別する必要があります。すべての改行を保持しながら、それらは常に削除されます。それらは常にすべてのラインフィードが削除されて置き換えられます。どちらも完全に独立した操作であり、互いに関係はありません。
昔は、Cプリプロセッサは常にstdoutで出力を生成し、Cコンパイラはそれをstdinから読み取りました。プリプロセッサは#<N> "<FILE>"
、Cコンパイラが「行番号Nが続く」と解釈する内部ステートメントを発行します。したがって、理論的には、プリプロセッサは出力に空の行を出力せずに実行できます。ただし、実際には、この機能はステートメント#<N> "<FILE>"
に続く行にのみ使用されます。#include
現在、プリプロセッサはパフォーマンスのためにCコンパイラに組み込まれていますが、明示的に要求された場合でも中間結果を確認できます。
注:以下の適切なコメントも参照してください。標準では、プリプロセッサのテキスト出力が空白の観点からどのように見えるかは実際には指定されていません。テキスト出力は実装固有です。かなりの解釈の余地があります。定義されているのは、少なくとも1つのスペース文字が必要であり、エラーメッセージが意味をなすように、すべてのトークが元の行にとどまる(または元の行でタグ付けされる)ことです。