在 // C++ 注釋中使用 \\ 是否合法？ （C++ 注釋中的 LaTeX 方程）

Question

出於文檔目的，我需要在我的 C++ 注釋中添加一些 LaTeX 方程，例如：

//
// \begin{eqnarray*}
//   y_1 &=& x_1 \\
//   y_2 &=& x_2 
// \end{eqnarray*}
//
int main() {}

使用 clang++（版本 9.0.1-10）我可以毫無問題地編譯我的代碼：

clang++ -Wall prog.cpp 

但使用 g++（版本 9.2.1）

g++ -Wall prog.cpp 

我收到這個警告：

 prog.cpp:3:1: warning: multi-line comment [-Wcomment] 3 | // y_1 &=& x_1 \\ | ^

我的問題：哪個編譯器是正確的？ 我可以在 C++ 中合法地使用\\ //注釋嗎？

Answer 1

合法嗎？ 是的。 容易出錯嗎？ 是的。 這就是你收到警告的原因。

C/C++ 標准首先有一個標記（首先處理）： \

此標記刪除換行符。 考慮以下代碼：

1.  // the below code is commented out \
2.  despite not having a comment at the beginning of the line
3.  
4.  // it's important to be careful because \\
5.  int not_compiled_code = 0;
6.  // the above code is not compiled.

盡管 stackoverflow 的語法高亮顯示，第 2 行和第 5 行沒有被編譯。

如果您想知道，下一個標記是//和/* 。

// /* incomplete block comment
int compiled_code = 0;

/*
// this entire line isn't commented */ int compiled_code_2 = 0;

哪個編譯器是對的？

兩者都是，因為警告與標准無關。 他們編譯成功，這才是最重要的——他們都正確地符合標准。

Answer 2

這樣的評論是合法的，但它們可能會產生意想不到的影響，因此發出警告。 在末尾帶有反斜杠的行之后的下一行是注釋的延續，與開頭的//無關。 所以這

// \\
Hey dude!
int main () {}

是一個有效的 C++ 程序。 不，最后一個反斜杠之前的反斜杠不能作為轉義符。

如果要避免警告，請在行尾添加 LaTeX 注釋：

// y_1 &=& x_1 \\ % look ma, no warning

請注意，反斜杠和換行符之間的簡單空格不一定能解決問題。 GCC 文檔說：

如果反斜杠和行尾之間有空格，那仍然是續行。 但是，由於這通常是編輯錯誤的結果，並且許多編譯器不會接受它作為續行，因此 GCC 會警告您。

Answer 3

根據cpp參考

C++ 風格的注釋告訴編譯器忽略 // 和新行之間的所有內容。

所以你的評論應該是合法的。 請注意，g++ 僅給出警告，而不是錯誤。

g++ 警告轉義換行符

每當注釋開始序列 '/ ' 出現在 '/ ' 注釋中，或每當反斜杠換行符出現在 '//' 注釋中時都會發出警告。 此警告由 -Wall 啟用

Answer 4

哪個編譯器是對的？

兩個都。 警告不是關於“ \的合法使用”，警告是關於多行注釋。

在 C 中，行尾的\字符表示忽略換行符。 所以這兩行：

// blabla\
abcabc

和：

// blabalabcbc

完全等價。 雙反斜杠\\只是一個由\轉義的反斜杠\ ，因此它首先被反斜杠替換，然后預處理器檢測到后跟換行符的反斜杠並刪除換行符。 這就是為什么它很危險。

int a = 1;
// increase a \\
a++;
printf("%d\n", a); // will print `1`

Answer 5

一個實用的解決方案是使用/*多行注釋。 所以代碼

/***
 \begin{eqnarray*}
   y_1 &=& x_1 \\
   y_2 &=& x_2 
 \end{eqnarray*}
***/

您應該對文學編程技術和Doxygen等工具感興趣。

我的建議是嘗試Nuweb （至少如果您在 Linux 上編寫代碼），尤其是對於您的公共（以及 LaTeX 文檔）header 文件。 您將編寫一個 Nuweb 源文件（一些*.nw文件），一方面會生成 LaTeX，另一方面會生成 C 代碼（例如，一些 header 文件）。

請注意，使用識字編程技術需要花費大量時間。 我個人但有限的經驗是，與實現細節和整個翻譯單元相比，它們更值得在公共 header 文件上使用。

當然，您需要了解有關構建自動化工具（例如GNU make或ninja ）的更多信息，並明確配置它們以適當地運行您的nuweb或doxygen可執行文件。