3

好的,所以我知道我应该将我的代码嵌入命名空间来处理名称冲突。例如

My-Header-Only-Library.hpp

    namespace AG {
    namespace My_Header_Only_Library {

    class Foo {
        ...
    };

    }
    }

所以我有 AG::My_Header_Only_Library::Foo。

是的,我经常使用两个级别 - 第一个级别,不同的是 AG、AFG、libAG 等 - 用于“我的”东西(我已经维护了其中的一些库几十年,例如Valid<T>)。

而且我经常有各种模块的子命名空间。

问题 #1:命名空间名称有时会发生冲突。

是的:我发现所有名称空间名称 AG、AFG、libAG 的冲突。是的,我遇到过与我姓名首字母相同的公司。

(有一段时间我用GLEW,觉得这是一个比较独特的姓氏。当时我是互联网上唯一的Glew,也是ARPAnet上第48个名字缩写为AG的人。(AG48)。但从那以后,OpenGL Extensions Wrangler 几乎已经从我这里拿走了它。)

我想“命名空间 AG_some_random_stuff_675567”不太可能发生冲突。人是这样的吗?使用一些长命名空间名称,然后使用

using AG_lib = AG_some_random_stuff_675567

或者你有没有尝试过像#defining 命名空间的名字这样的把戏。

例如

#define AG something_more_unique

问题2:我有时会给予、借出、允许公司使用我的图书馆。位我要求他们回馈更改,即他们不分叉。

它们的编码约定可能不一样。

我不希望他们更改命名空间名称,因为这会使他们的更改更难撤回。

问:怎么办?让他们做

using Their_Name = AG_some_random_stuff_675567
4

3 回答 3

1

我通常从命名空间包含的内容、我的全名和创建日期开始——理论上这也不是 100% 不受冲突影响,但它非常接近1。如果您真的想要更接近免疫的东西,您可以生成一个 GUID 并改用它。

然后,当然是的,对于大多数正常使用来说,有一个更短的别名。不幸的是,您不能总是使用别名来代替完整的命名空间名称,但这就是生活。


  1. 至少对我来说它非常接近——一个更常见的名字会提供更少的保护。
于 2013-01-11T02:31:55.473 回答
0

您处于损坏控制模式。在与其内部名称冲突的状态下接收您的库的公司将需要修改其客户端代码以消除冲突库的歧义。

AG_some_random_stuff_675567显然是矫枉过正并且AG显然(也许只是回想起来)太可能发生碰撞。选择一些相当独特的东西,以便未来的客户可以在没有using别名的情况下使用它。例如all_good. (虽然,如果要求客户添加自己的using别名不会导致营销或支持问题,那么命名空间random_stuff将是完全安全的。)

然后,您可以using namespace AG = all_good;在自己的代码中添加代码,并指示旧客户端执行相同的操作,以实现向后兼容。

或许可以使用预处理器标志通过选择谁在全局命名空间中获取指令来帮助迁移客户端using,但绝不应该使用预处理器宏来重命名命名空间!像AG这样的名字已经被证明会发生冲突。

于 2013-01-11T02:34:32.827 回答
0

不要使用缩写,使用已经分配的命名空间。例如,反转您的完全限定域名的 Java 实践非常有效。使用我的代码,我可以安全地使用

namespace com {
    namespace benvoigt {
    }
}

并且知道它不会与外部实体发生冲突,因为其他任何人都不可能拥有该域的所有权benvoigt.com

于 2013-01-11T02:47:03.280 回答