為什么新的C書不符合C99標准？

Question

幾乎所有關於c編程的（相對）新書似乎都沒有遵循C99標准，或者他們在一個額外的章節中介紹它。 從Java背景來看，C99標准使我的遷移（嗯，仍在遷移^^）變得更加容易，這也可能適用於其他語言。

似乎C99尚未到達大多數C開發人員。 但為什么？

Answer 1

簡短回答：編譯器支持安裝速度慢，c程序員是保守的，他們慢慢改變行為。

Answer 2

我強烈懷疑這主要是因為MSVC不會嘗試支持C99，而且很可能永遠不會。 在同一條船上有一些嵌入式編譯器，但它們幾乎沒有足夠的共同之處。 AFAIK其他人至少都試圖盡可能地實施C99。

在實踐中沒有太多理由不使用C99的選定功能，但如果你要學習並寫入一個C標准，只有一個，那么它必須是C89。

此外，編寫介紹性的C文本可能會非常困難和令人困惑，首先說“好吧，有兩種不同的標准，我將使用三種不同顏色的文本：一種用於C89，一種用於C99，以及一個兩個“。 也可能更難寫一本關於整本書的C99，然后“收回”你在C89的附錄中所說的很多，而不是寫關於C89然后在關於C99的附錄中添加它。

盡管如此，所有的猜測。 真的，你不得不問作者你正在閱讀的書籍（或者在某些情況下可能違背你所有的編程本能，並閱讀前言 ;-)）

Answer 3

在現有代碼庫上切換到新編譯器的風險通常是未知的，但它可能非常痛苦，只有在您有數月的時間來消除任何錯誤/更改時才切換它是最明智的。 對於真正古老的代碼庫，有時最根本就是永不切換。

我願意打賭，大多數使用C的項目根本不願意轉向C99，因為現有的大量代碼庫幾乎沒有任何優勢，而且存在相當大的潛在缺點。 我曾在一家大型軟件公司工作過，它將編譯器檢查到代碼旁邊的源代碼樹中，並且永遠不會為產品切換編譯器。