我正在编写一个由几个“包”组成的实用程序库。每个包中的类都包含在各种名称空间中。我知道如何通过在类声明结束时自动声明使用语句来简化情况(见下文),这样可以避免程序员在cpp文件中执行此操作。
namespace Utility
{
class String
{
// Class Implementation
};
}
using Utility::String;
我的理解是,如果用户包含头String.h并且String在Utility中,那么程序员将希望使用String。显然,如果有外部类链包括一堆污染命名空间的文件,那么这可能会很糟糕,所以我想到了如何将它变成#define。
namespace Utility
{
class String
{
// Class Implementation
};
}
#ifdef AUTO_DECLARE_NAMESPACE
using Utility::String;
#endif
这样,想要这种扩展功能的程序员可以得到它。
这是一个好主意还是有些东西我会忽略?
答案 0 :(得分:6)
如果您只是为命名空间中声明的每个名称添加using声明,那么使用命名空间是没有意义的。
让您的头文件的用户决定他们如何使用标头。如果有人想使用using声明,请让他直接在.cpp文件中执行;这将使.cpp文件中的代码更加清晰,因为名称的来源显而易见。
答案 1 :(得分:2)
这似乎毫无意义,最糟糕的是烦人。
让开发人员决定使用哪些名称空间以及完全符合条件的内容有什么问题?
答案 2 :(得分:0)
老实说,我相信这是using namespace
指令的用途。考虑到using namespace
指令就是这样,你不需要添加这个预处理器机制。
答案 3 :(得分:0)
难道你没有另外的.h文件包含my_lib_import_names.h之类的所有使用文件而只是#include可以获得你想要的东西吗?
你可能会遇到没有被声明的类的问题,但是你可以通过使用类似的东西来绕过它:
#ifdef UTILITY_STRING_H_
using Utility::String;
#endif
..
#ifdef UTILITY_SOMETHING_ELSE_H
using Utility::SomethingElse;
#endif
..
您怎么看?
这样你就可以在你的库中保留“预期”的行为。但你也可以按自己喜欢的方式行事。您还可以在类上保留命名空间的好处(代价是必须维护新的.h文件)。