在Windows和Linux中寫入C會導致編譯問題嗎？

Question

我從2個不同的機器工作。一個是Windows，另一個是Linux。如果我交替地在同一個項目上工作，但在兩個操作系統之間切換，我最終是否會遇到編譯錯誤？我問，因爲也許有一個標準支持，而另一個不支持。

Answer 1

該問題相當廣泛，嚴格來說，取決於您的工具鏈。如果您要使用相同的工具鏈（例如GCC/MinGW或Clang），則可以最大限度地減少此類錯誤的機率。如果您要在Windows上使用Visual Studio，在Linux上使用GCC或Clang，則由於某些標頭不同，您可能會單獨遇到更多問題。所以一旦你的程序離開嚴格的ANSI C（C89）的領域，你就會自己做。

但是，如果您不小心，可能會遇到很多其他更褻瀆的錯誤，例如，如果您沒有告訴Windows端的編輯器使用這些錯誤，則Linux上的編譯器會扼殺行結尾。

啊，還要記住，如果你想實際交叉編譯，GCC可能是最好的選擇，因此我在回答中提到的第一部分成爲一個有爭議的問題。 GCC在兩端都是經過驗證的選擇。考慮到你的問題，你不太可能試圖編寫類似於內核模式驅動程序的東西 - 這會有根本的不同。

Answer 2

這可能只有當您的應用程序使用某些特定的API。

Answer 3

直到您在各自的操作系統中重新編譯源代碼之後，它纔會產生問題。如果你想運行由windows（.exe或.obj）生成的編譯文件，進入linux或反之亦然，那麼它肯定會產生一個問題，並不會成爲可能。但是你可以將你的源代碼（擴展名爲.c/.C++的文件）移動到任何os中。有時候它也會產生不同頭文件的問題，所以請注意這一點。最佳做法是爲整個項目使用單個操作系統，避免多個操作系統，直到它非常必要。

Answer 4

完全可以編寫適用於兩種平臺的代碼，無需編譯代碼。但是，這並非沒有一些困難。編譯器允許您在編譯器中使用非標準功能，並且通常很難做更多花哨的用戶界面（即使它仍然只是文本），因爲只要您開始想要做的不僅僅是「讀取一行文本進入一個殼「，它進入」非標準「的土地。

如果你發現自己需要做的比標準C庫能做的更多，請確保將代碼的這些部分分離成單獨的文件（或者一些文件，一個用於Linux/Unix風格的系統和一個用於Windows系統）。

使用相同的編譯器（gcc）將有助於避免「編譯器B無法編譯在編譯器A中正常工作的代碼」的問題。

但絕對不是絕對必要 - 只要確保在兩個平臺上編譯代碼，並且所有「支持」編譯器都足夠經常編譯代碼，以至於您沒有挖掘到很深的難以擺脫困境的代碼然後再發現「這不適用於其他系統」。如果您（至少）有一臺運行其他操作系統的虛擬機，它肯定會有所幫助，因此您可以輕鬆地嘗試這兩種變體。

理想情況下，您希望設置一個自動化系統，以便當您更改代碼[並且感覺這些更改是「完整的」]時，它會自動構建在您要使用的平臺和所有編譯器上。如果可能的話，也會自動測試！

我也會認真考慮使用版本控制 - 這樣，當某個或某個方面發生斷斷續續的事情時，您可以回頭查看代碼在停止工作之前的樣子，並且（希望）找到原因它比「嗯，我認爲這是我對foo.c所做的改變，讓我們拿出來......不，不是那個，好吧，改變如何...」 - 至少在版本控制方面，你可以說：「好的，所以1234版本不工作，讓我們試試版本1220 - 確定，這是可行的，現在嘗試1228，仍然有效 - 所以在1229和1234之間改變 - 嘗試1232，啊，它壞了...」編輯文件，你仍然可以去任何你喜歡的任何其他版本，很難。我已經使用了Mercurial很多，有點混亂，有些顛覆，並且在Perforce的一個項目上工作了幾年。所有這些都很好 - 我個人認爲我更喜歡水銀。

作爲一個副作用：大多數版本控制系統也以比手動方式處理文件名和行結尾的方式。

如果您將您的版本控制系統與「自動化構建和測試系統」（如Jenkins）結合使用，您可以使一切都變得非常自動化。 Jenkins是免費的，可以在Windows和Linux上運行，並且可以在您將代碼提交給版本控制系統時自動構建和測試代碼。