C++中的内部typedef - 好风格还是坏风格？

Question

我最近发现自己经常做的事情是声明与该类中的特定类相关的typedef,即

class Lorem
{
    typedef boost::shared_ptr<Lorem> ptr;
    typedef std::vector<Lorem::ptr>  vector;

//
// ...
//
};

然后在代码中的其他地方使用这些类型:

Lorem::vector lorems;
Lorem::ptr    lorem( new Lorem() );

lorems.push_back( lorem );

我喜欢它的原因:

它减少了类模板引入的噪音,std::vector<Lorem>变成了Lorem::vector等等.
它用作意图陈述 - 在上面的示例中,Lorem类旨在通过boost::shared_ptr向量计数并存储在向量中.
它允许实现改变 - 即如果Lorem需要boost::intrusive_ptr在稍后阶段被改变为侵入式引用计数(via ),那么这将对代码产生最小的影响.
我认为它看起来"更漂亮",可以说更容易阅读.

我不喜欢它的原因:

有时依赖性问题 - 如果你想Lorem::vector在另一个类中嵌入,但只需要(或想要)转发声明Lorem(而不是引入对其头文件的依赖),那么你最终必须使用显式类型(例如boost::shared_ptr<Lorem>而不是Lorem::ptr),这有点不一致.
它可能不是很常见,因此难以理解？

我试着对我的编码风格保持客观,所以最好能得到一些其他意见,这样我就可以稍微剖析一下我的想法.

Answer 1

我认为这是很好的风格,我自己用它.最好尽可能地限制名称的范围,使用类是在C++中执行此操作的最佳方法.例如,C++标准库在类中大量使用typedef.

Answer 2

它用作意图声明 - 在上面的示例中,Lorem类旨在通过boost :: shared_ptr进行引用计数并存储在向量中.

这正是它没有做到的.

如果我在代码中看到'Foo :: Ptr',我完全不知道它是一个shared_ptr还是一个Foo*(STL有::指针typedef是T*,记得)或者其他什么.ESP.如果它是一个共享指针,我根本不提供typedef,但保持shared_ptr在代码中显式使用.

实际上,我几乎没有在Template Metaprogramming之外使用typedef.

STL一直都在做这类事情

具有根据成员函数和嵌套typedef定义的概念的STL设计是历史的死胡同,现代模板库使用自由函数和特征类(参见Boost.Graph),因为它们不排除内置类型对概念进行建模,因为它使得使用给定模板库的概念设计的类型变得更容易.

不要使用STL作为犯同样错误的理由.

Answer 3

Typedef是基于策略的设计和特性在C++中构建的,因此C++中的泛型编程的强大源于typedef本身.

Answer 4

Typdef绝对是好风格.你所有"我喜欢的理由"都是好的和正确的.

关于你遇到的问题.那么,前瞻宣言不是圣杯.您可以简单地设计代码以避免多级依赖.

你可以在类之外移动typedef,但Class :: ptr比ClassPtr更漂亮,我不这样做.就像命名空间一样 - 事物在范围内保持联系.

有时候我做了

Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map

它可以是所有域类的默认值,也可以是某些特定类.