'uint32_t'未命名类型

77

我正在尝试编译2007年编写的C ++软件包，但出现此错误：

error: ‘uint32_t’ does not name a type

这在使用g ++ 4.5.2的64位Ubuntu中发生。使用g ++ 4.1.2在64位CentOS上可以很好地编译。

#include我是否缺少一个或编译器标志？或者，我应该使用typedef分配uint32_t给asize_t还是也许unsigned int？

c++ uint32-t cstdint

— 罗马教廷
source

5

查找stdint.h或<cstdint>标头。该类型（据我所知）是C99的一部分，但并未将其纳入C ++。

— Mike C

3

是#include <stdint.h>吗看起来可能是64位Ubuntu上的错误。另外，您是否有-std=c++98gcc的命令行选项？如果是这样，是否可以检查是否可以正常使用-std=gnu++98？

— 2012年

@dirkgently，我检查了Makefile，没有任何std选择。

— rmtheis 2012年

@ user667810：因此默认为GNU扩展和C ++ 98模式。

— 奇怪的是，2012年

153

您需要包含stdint.h

 #include <stdint.h>

— 塞尔比
source

58

“适当的” C ++标头为cstdint。

— paxdiablo 2012年

1

注意，在我的情况下，问题实际上boost/cstdint.hpp是找不到包含。yum install boost-devel解决了我的问题。

— snooze92 2014年

@paxdiablo是否不应该将cstdint.h包含在extern“ C” {}块中？

— StarShine

@ paxdiablo，'proper'头给了我“ #error，该文件需要对ISO C ++ 2011标准的编译器和库支持。该支持目前处于实验阶段……”是的，应该进行升级，但这是一个巨大的旧应用，几乎无法使用使其进入了64位世界。

— brewmanz '18

怎么样C用GCC？

— 罗伊

33

您需要#include <cstdint>，但这可能并不总是有效。

问题在于，某些编译器通常会在这些标准到位之前自动导出在各种标头或提供的类型中定义的名称。

现在，我说“可能并不总是有效”。这是因为cstdint标头是C ++ 11标准的一部分，并不总是在当前C ++编译器上可用（但经常是）。stdint.h标头与C等效，并且是C99的一部分。

为了获得最佳的可移植性，boost/cstdint.hpp如果您愿意使用boost ，我建议您使用Boost的标头。否则，您可能可以摆脱＃include'ing <cstdint>。

— 等离子体
source

这给了我

#error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

— rmtheis 2012年

1

正确，正如它所说，cstdint是新C ++标准的一部分（被称为C ++ 0x，但正式不是C ++ 11。因此，要使用该标头，必须在g ++中启用新标准。我说，最好的便携式的方式来获得这些类型是使用升压或其他一些等价头，而不是依赖于编译器的支持。

— 血浆

9

我在Mac OSX 10.6.8上也遇到了相同的问题，不幸的是，将其添加#include <stdint.h>或添加<cstdint.h>到相应的文件并不能解决我的问题。但是，经过更多搜索，我发现建议添加此解决方案#include <sys/types.h>对我而言效果很好！

— patti_jane
source

6

其他答案假定您的编译器符合C ++ 11。如果可以，那就很好。但是，如果您使用的是较旧的编译器，该怎么办？

我在网上某处捡到了以下黑客。它对我来说足够好：

  #if defined __UINT32_MAX__ or UINT32_MAX
  #include <inttypes.h>
  #else
  typedef unsigned char uint8_t;
  typedef unsigned short uint16_t;
  typedef unsigned long uint32_t;
  typedef unsigned long long uint64_t;
  #endif

当然，它不是便携式的。但是它可能对您的编译器有效。

— 丹尼尔·莱米尔
source

内核驱动程序（C）需要这些，它可以编译！谢谢

— DreTaX

1

在base.mk文件中添加以下内容。第三行很重要 -include $(TOP)/defs.mk

CFLAGS=$(DEBUG) -Wall -W -Wwrite-strings 
CFLAGS_C=-Wmissing-prototypes
CFLAGS_CXX=-std=c++0x
LDFLAGS=
LIBS=

为了避免#error，此文件需要编译器和库支持即将推出的ISO C ++标准C ++ 0x。该支持目前处于试验阶段，必须使用-std = c ++ 0x或-std = gnu ++ 0x编译器选项启用

— 古里加尼什
source

1

问题并没有说明是否正在使用Make。一个更可移植的答案就是说要传递给编译器的标志（假设您使用的是哪个编译器）。

— Toby Speight

1

如果包含opencv标头时发生。

我建议更改标题的顺序。

将opencv标头放在标准C ++标头的正下方。

像这样：

#include<iostream>
#include<opencv2/core/core.hpp>
#include<opencv2/highgui/highgui.hpp>

— 用户名
source

这与opencv有什么关系？这是在许多情况下都会发生的非常普遍的错误。

— EntangledLoops

1

我在尝试编译从互联网下载的库时遇到了同样的问题。就我而言，#include <cstdint>代码中已经有一个。我解决了添加：

using std::uint32_t;

— 丹尼尔
source

1

@Daniel#include在访问类型之前，您仍然需要正确的标题。

— cbr 2016年

是的，这#include是必需的。我没有说不是。但由于在我的情况下是a #include <cstdint>，而没有using namespace std，编译器无法解析该名称uint32_t。这就是我不得不添加using std::uint32_t;

— Daniel

0

只需导航至/ usr / include / x86_64-linux-gnu / bits打开stdint-uintn.h并添加以下行

typedef __uint8_t uint8_t;
typedef __uint16_t uint16_t;
typedef __uint32_t uint32_t;
typedef __uint64_t uint64_t;

再次打开stdint-intn.h并添加

typedef __int8_t int8_t;
typedef __int16_t int16_t;
typedef __int32_t int32_t;
typedef __int64_t int64_t;

请注意，这些行已经存在，只需复制并添加缺少的行即可。

— 拉尼什·夏尔马
source

-2

您需要包括iostream

#include <iostream>
using namespace std;

— 萨米拉小姐
source