C++ 在 Ubuntu 8.1 上无法通过 g++-4.1 或其他人找到 size_t
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1107940/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
size_t can not be found by g++-4.1 or others on Ubuntu 8.1
提问by EdH
This has happened before to me, but I can't remember how I fixed it.
这在我身上发生过，但我不记得我是如何解决它的。
I can't compile some programs here on a new Ubuntu install... Something is awry with my headers.
我无法在新的 Ubuntu 安装中编译某些程序……我的头文件有问题。
I have tried g++-4.1 and 4.3 to no avail.
我试过 g++-4.1 和 4.3 无济于事。
g++ -g -frepo -DIZ_LINUX -I/usr/include/linux -I/usr/include -I/include -c qlisttest.cpp
/usr/include/libio.h:332: error: ‘size_t' does not name a type
/usr/include/libio.h:336: error: ‘size_t' was not declared in this scope
/usr/include/libio.h:364: error: ‘size_t' has not been declared
/usr/include/libio.h:373: error: ‘size_t' has not been declared
/usr/include/libio.h:493: error: ‘size_t' does not name a type
/usr/include/stdio.h:294: error: ‘size_t' has not been declared
...
the file...
文件...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
...
@ubuntu:~/work/zpk/src$ cat /usr/include/linux/types.h | grep size_t
typedef __kernel_size_t size_t;
typedef __kernel_ssize_t ssize_t;
types.h is definitely in the path, and is getting picked up. I verified by changing the file name and get an error its missing...
types.h 肯定在路径中，并且正在被接收。我通过更改文件名进行了验证，但出现了丢失的错误...
Does anyone have any ideas...? I would really appreciate the help...
有没有人有任何想法......？我真的很感激你的帮助...
采纳答案by Vladimir Prus
Start by removing -I/usr/include/linux and -I/usr/include. Adding system directories to include paths manually either has no effect, or breaks things. Also, remove -frepo for extra safety.
首先删除 -I/usr/include/linux 和 -I/usr/include。添加系统目录以手动包含路径要么无效，要么破坏。此外，删除 -frepo 以提高安全性。
回答by slacy
It's hard to say what the issue is without seeing your complete source. The best way to debug issues like this is to use g++'s "-E" parameter to produce pre-processor output, and then look at that to figure out what's going on in your includes. Here's what the g++ info page says about "-E":
如果没有看到您的完整来源，很难说出问题是什么。调试此类问题的最佳方法是使用 g++ 的“-E”参数来生成预处理器输出，然后查看它以找出包含中发生了什么。以下是 g++ 信息页面关于“-E”的说明：
-E Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which is sent to the standard output.
-E 预处理阶段后停止；不要正确运行编译器。输出采用预处理源代码的形式，发送到标准输出。
Also, why not just include sys/types.h at the top of the file?
另外，为什么不只在文件顶部包含 sys/types.h 呢？
Addendum:
附录：
On my system, I've created a short file called foo.cc that contains only:
在我的系统上，我创建了一个名为 foo.cc 的短文件，其中仅包含：
#include <time.h>
And then I've run:
然后我跑了：
g++ -E /tmp/foo.cc > /tmp/foo.pp
g++ -E /tmp/foo.cc > /tmp/foo.pp
Looking at this output in much detail is very important. For example, I learned that /usr/include/bits/types.h has a typedef for __time_t, and that /usr/include/types.h then uses that typedef to say "typedef __time_t time_t". But, there are interesting other macros surrounding that definiton. Pay special attention to things like the macro "__BEGIN_NAMESPACE_STD" in /usr/include/time.h, which on my system seems to be an empty define. But, I can imagine that some other systems may have a different value for this macro, forcing the definition of time_t into some other namespace.
详细查看此输出非常重要。例如，我了解到 /usr/include/bits/types.h 有一个 __time_t 的 typedef，然后 /usr/include/types.h 使用该 typedef 表示“typedef __time_t time_t”。但是，围绕该定义还有其他有趣的宏。特别注意 /usr/include/time.h 中的宏“__BEGIN_NAMESPACE_STD”之类的东西，它在我的系统上似乎是一个空定义。但是，我可以想象其他一些系统可能对这个宏有不同的值，迫使 time_t 的定义进入其他一些命名空间。
Read the Cpp info page, section "9 Preprocessor Output" that defines the format of the lines of the file. Of particular note is the section on:
阅读 Cpp 信息页面的“9 预处理器输出”部分，该部分定义了文件行的格式。特别值得注意的是以下部分：
Source file name and line number information is conveyed by lines of the form
# LINENUM FILENAME FLAGS
源文件名和行号信息由表单的行传达
# LINENUM 文件名标志
And then goes on to describe "FLAGS" which are of interest for this level of debugging.
然后继续描述对这个级别的调试感兴趣的“标志”。
回答by Samat Jain
Generally, you shouldn't be using C .h files for C++. While you may find an easy way to get away with it, and while a lot of this was allowed in previous versions of g++ and in other compilers, the C++ standard defines size_t to be in cstddef (see section 18.2/table 17). g++ has been only getting more strict.
通常，您不应将 C .h 文件用于 C++。虽然您可能会找到一种简单的方法来摆脱它，虽然在以前版本的 g++ 和其他编译器中允许很多这种情况，但 C++ 标准将 size_t 定义为 cstddef（参见第 18.2 节/表 17）。g++ 变得越来越严格。
Remove all the includes paths you've added to your command (they are redundant), and add to the top of your source code if not included:
删除您添加到命令中的所有包含路径（它们是多余的），如果不包含，则添加到源代码的顶部：
#include <cstddef>
using namespace std;
回答by kalleh
Have you installed the build-essential package?
您是否安装了 build-essential 软件包？
sudo apt-get install build-essential
回答by EdH
Forgot to follow up on this. It turns out that /usr/includecannot be included with /usr/include/linuxon this particular distro. size_tseems to be get wiped out by the second includes.
忘记跟进这个了。事实证明，/usr/include不能包含/usr/include/linux在这个特定的发行版中。size_t似乎被第二个包含消灭了。
My includes are now merely /usr/includeand it works great.
我的包含现在仅仅是/usr/include，它工作得很好。
-I/usr/include -I/usr/include/ace -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0...
Pulling out all the includes and playing with them fixed it.
拉出所有包含并使用它们修复它。
回答by David Thornley
It should be in stddef.h or cstddef. types.h is not a standard library, and I believe it refers to types the OS needs.
它应该在 stddef.h 或 cstddef 中。types.h 不是标准库，我相信它指的是操作系统需要的类型。
