C++嵌入式應用程序應該使用帶有typedefs的通用標頭用於內置C++類型嗎？

這是我工作的地方，以避免直接使用常見的做法內置類型，而是包括有一個像項standardtypes.h：C++嵌入式應用程序應該使用帶有typedefs的通用標頭用於內置C++類型嗎？

// \Common\standardtypes.h 
typedef double    Float64_T; 
typedef int    SInt32_T;

幾乎所有的組件和源文件變得依賴於這個頭，但有些人認爲它需要抽象類型的大小（實際上這不需要）。

這是一個很好的做法（特別是在大型元件化系統中）？有更好的選擇嗎？或者應該直接使用內置類型？

來源

2010-08-18 Brandon Leiran

請引用誰在爭論是否需要「抽象類型的大小」。標準的原因是要鞏固類型的大小。一個'int32_t'（stdint.h）總是32位，而'long'或者'int'不一定是這樣。 – 2010-08-18 20:59:47

不幸的是，這樣的頭文件非常常見，並且源於C和C++編譯器沒有根據符號和位大小定義類型的時間。使用最近編譯器的代碼應該使用更新的表單。遺產代碼應該使用商店的形式。 – 2010-08-18 21:40:27

這種方法的最大問題是，如此多的開發人員這樣做，如果您使用第三方庫，您可能最終會遇到符號名稱衝突或相同類型的多個名稱。如果需要堅持C99的stdint.h提供的標準實現，那將是明智之舉。

如果你的編譯器不提供這個頭（例如VC++），那麼創建一個符合該標準的頭。一個用於VC++的例子可以在http://msinttypes.googlecode.com/svn/trunk/stdint.h

在你的例子中，我可以看到定義大小特定的浮點類型的一點點，因爲它們通常緊密耦合到目標的FP硬件和使用的表示。另外，浮點值的範圍和精度由指數寬度和顯着寬度的組合決定，因此單獨的總寬度不會告訴您太多，或者保證跨平臺的兼容性。就單精度和雙精度而言，跨平臺的可變性要小得多，其中大多數採用IEEE-754表示。在一些8位編譯器中，float和double都是32位，而x86 GCC上的long double是80位，但在VC++中只有64位。x86 FPU在硬件(2)中支持80位。

來源

2010-08-18 22:42:17 Clifford

我認爲這不是一個好習慣。好的做法是使用類似uint32_t的地方，你真的需要32位無符號整數，如果你不需要特定的範圍，只需使用無符號的。

來源

2010-08-18 20:40:30 pmod

ITYM 32 * bits *？ – 2010-08-18 20:42:04

您可以使用頭文件在現代C提供的標準版本和C++實現：stdint.h

它的類型等：uint8_t，int32_t和等

一般來說，這是保護代碼免受平臺依賴的好方法。即使你迄今還沒有經歷它的需要，它肯定會使代碼更易於解釋，因爲不需要像'int'或'long'那樣猜測存儲大小，這會隨着大小的變化而變化平臺。

來源

2010-08-18 20:41:26

使用在stdint.h 等中定義的標準POSIX類型可能更好，例如， uint8_t,int32_t等。我不確定是否有C++的一部分，但他們在C99。

來源

2010-08-18 20:41:36

他們將在下一個標準，這將在200B左右。同時，實現者可能會包含它們。 – 2010-08-18 21:04:36

如果您正在創建跨平臺代碼，其中本地類型的大小因系統而異可能會有所不同。例如，取決於系統，wchar_t類型可以從8位變化到32位。

但是，我個人並不認爲你描述的方法與其支持者的建議一樣實際。我不會使用這種方法，即使是跨平臺系統。例如，我寧願讓我的系統直接使用wchar_t，只需編寫代碼，知道wchar_t的大小會因平臺而異。我相信這是FAR更有價值。

來源

2010-08-18 20:42:34

對於大量的開發，我同意你的看法。但是，這是針對嵌入式的，這通常意味着需要對生成的內容進行更多的控制，並且通常意味着與定義大小的字段進行接口。在處理內存映射的16位硬件寄存器時，將其稱爲像'volatile uint16_t'這樣的工作比希望'short'或'wchar_t'可以工作更好。 – 2010-08-18 21:03:38

@David Thornley：對於像68000這樣的東西尤其如此，即使在同一個硬件平臺上，每個編譯器的'int'大小也可能不同。 – supercat 2010-08-18 22:24:18

@supercat：告訴我這件事。我一次在Macintosh上使用的一個C編譯器提供了16位或32位int的編譯器選項。相同的電腦，相同的編譯器，不同的選項集。 – 2010-08-19 14:23:17

因爲它沒有說出來呢，而且即使你已經接受了答案：

僅用於具體尺寸的類型，當你需要具體大小類型。大多數情況下，這意味着當你保存數據時，如果你直接與硬件交互，或者使用其他代碼（例如網絡堆棧），這些代碼需要具體的大小類型。大多數情況下，應該只使用抽象大小的類型，以便編譯器可以更智能地進行優化，以便未來的代碼讀者不會受到無用細節（如循環計數器的大小和符號）的影響。

（其他幾個迴應說，使用stdint.h，不是自制軟件，編寫新的代碼，而不是與舊的接口時。）

來源

2010-08-23 21:50:07 pkh

正如其他人說，在stdint定義，使用標準的類型。H。我不同意那些說只在某些地方使用它們的人。當您使用單個處理器時，這可以正常工作。但是當你有一個使用多種處理器類型（例如ARM，PIC，8051，DSP）的項目（這在嵌入式項目中並不少見）時，它會跟蹤int的含義或能夠將代碼從一個處理器複製到另一個處理器要求您使用固定大小的類型定義。

至少對我來說是必需的，因爲在過去的六個月中，我爲各種項目開發了8051，PIC18，PIC32，ARM和x86代碼，並且我無法跟蹤所有的差異而不會在某個地方搞砸。

來源

2010-08-27 19:03:16 sbass

C++嵌入式應用程序應該使用帶有typedefs的通用標頭用於內置C++類型嗎？

回答

相關問題