将C / C ++标准库拉入你的项目命名空间，好主意？ [英] Pulling C/C++ standard library into your project namespace, good idea?

问题描述

我正在移植一些开源代码，以便它可以构建在另一个c ++编译器上。

I'm porting some open source code so that it can build on another c++ compiler. One of the difficulties and themes that seem to keep cropping up are implementation differences of the provided standard library by the compiler.

例如，其中一个源文件，我的' m编译包括< sys / types.h> 。但是，它给我以下错误：

For example, one of the source files that I'm compiling includes <sys/types.h>. However, it gives me the following errors:

Error E2316 g:\Borland\BCC593\Include\sys/types.h 45: 'time_t' is not a member of 'std'
Error E2272 g:\Borland\BCC593\Include\sys/types.h 45: Identifier expected

看到这个问题的根本原因后，我发现项目的主要include头之一包括< sys / types.h> ：

After looking at the root cause of this I found that one of the main include headers of the project is including <sys/types.h> in this pattern:

project_source1.cpp：

project_source1.cpp:

#include "../TargetPlatform.h"
#include "project_config.h"
#include <windows.h>

namespace project_namespace {
#include "project_component/all.h"
// more project includes down here
// ...
}

project_component / all.h：

project_component/all.h:

#ifndef INCLUDE_GUARDS
#define INCLUDE_GUARDS

#include <sys/types.h>
#include "project_header1.h"
#include "project_header2.h"
// and other headers etc..
// followed with class definitions and what not.

#endif

这一切都很好，除了一个问题， < sys / types.h> 实现类似这样的编译器我移植到：

This is all well and good except for one problem, the <sys/types.h> is implemented something like this for the compiler I'm porting to:

< sys / types.h> 修剪为精华：

namespace std {

typedef long time_t;
typedef short dev_t;
typedef short ino_t;
typedef short mode_t;
typedef short nlink_t;
typedef int   uid_t;
typedef int   gid_t;
typedef long  off_t;

} // std

using std::time_t;
using std::dev_t;
using std::ino_t;
using std::mode_t;
using std::nlink_t;
using std::uid_t;
using std::gid_t;
using std::off_t;

这是我看到的编译错误的原因。因为项目在其自己的命名空间中包含< sys / types.h> ，所以像time_t，off_t，dev_t等东西被放入范围 project_namespace :: std :: 这显然不是想要的。

And this is the cause of the compile error I'm seeing. Because the project is including <sys/types.h> inside its own namespace, things like time_t, off_t, dev_t etc get put into the scope project_namespace::std:: which is obviously not what's intended.

最好的办法是什么？请记住，可能有类似方式定义的其他标准库头文件，而不只是 sys / types.h 。有没有任何C ++成语与这个问题相关或半关联（或者可能甚至与它的错误，由于实现的方式）？

What's the best way to handle this? Keep in mind there could be other standard library headers defined in a similar fashion and not just sys/types.h. Are there any C++ idioms that's relevant or semi-related to this issue(or possibly even at odds with it due to the way this is implemented)? If so, how can it be reconciled?

感谢

推荐答案

这是一个坏主意。不要这样做。将命名空间声明放在每个头文件中。从不在命名空间范围内有 #include 指令。

This is a bad idea. Do not do things this way. Put the namespace declarations inside each header file. Never have a #include directive inside the scope of a namespace.

从不是一个强有力的词，非常罕见的情况下，你可能想这样做。如果你 #include ing的文件也有 #include 指令，你几乎肯定不想做

Never is a strong word, and there are very rare cases in which you might want to do this. If the file you're #includeing also has #include directives, you almost certainly do not want to be doing this, even more so than if they didn't.

如果您需要能够轻松地重命名命名空间或使用相同的标头来声明几个相同的符号不同的命名空间取决于上下文，使用预处理器来改变命名空间名称。这是非常丑的事，但比你目前做的更好。

If you need to be able to easily rename your namespace or use the same header to declare the same symbols in several different namespaces depending on context, use the preprocessor to change the namespace name instead. That's extremely ugly to do, but much better than what you're currently doing.

你可以做一个快速和肮脏的解决方案， #include< sys / types.h> 以及在命名空间声明之前包含的任何其他系统标题。这将导致系统头文件中的双重包含保护引入，并避免在命名空间内声明内容。

One thing you can do as a quick and dirty solution to this is #include <sys/types.h> and any other system header that's included before the namespace declaration. This will cause the double-inclusion guards in the system header files to kick in and avoid declaring stuff inside the namespace.

这篇关于将C / C ++标准库拉入你的项目命名空间，好主意？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！