我正在尝试编译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
分配给size_t
还是unsigned int
?
答案 0 :(得分:125)
您需要包含stdint.h
#include <stdint.h>
答案 1 :(得分:31)
您需要#include <cstdint>
,但这可能并不总是有效。
问题是某些编译器经常会在这些标准出现之前自动导出各种标题或提供类型中定义的名称。
现在,我说“可能并不总是有效”。那是因为cstdint标头是C ++ 11标准的一部分,并不总是在当前的C ++编译器上可用(但通常是)。 stdint.h头是C等价物,是C99的一部分。
为了获得最佳的可移植性,如果您愿意使用boost,我建议您使用Boost的boost/cstdint.hpp
标头。否则,你可能能够逃脱#include'ing <cstdint>
。
答案 2 :(得分:9)
我在Mac OSX 10.6.8上也遇到了同样的问题,遗憾的是将#include <stdint.h>
或<cstdint.h>
添加到相应的文件并没有解决我的问题。但是,经过更多的搜索,我发现这个解决方案建议添加#include <sys/types.h>
,这对我来说效果很好!
答案 3 :(得分:5)
其他答案假设您的编译器符合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
当然不是便携式的。但它可能适用于您的编译器。
答案 4 :(得分:1)
在base.mk文件中添加以下内容。以下第3行很重要
-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编译器选项启用
答案 5 :(得分:1)
如果包含opencv标题时发生。
我建议更改标题的顺序。
将opencv标头放在标准C ++标头下方。
像这样:#include<iostream>
#include<opencv2/core/core.hpp>
#include<opencv2/highgui/highgui.hpp>
答案 6 :(得分:1)
我有同样的问题试图编译我从互联网上下载的lib。就我而言,代码中已经有#include <cstdint>
。我解决了它添加:
using std::uint32_t;
答案 7 :(得分: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;
请注意,这些行已经存在,只需复制并添加缺少的行即可。
答案 8 :(得分:-1)
您需要包括iostream
#include <iostream>
using namespace std;