在IT技术领域中，隐藏shared_ptr背后的typedef是否是一个好的编码风格？

Question

我希望能够减少代码中的一些视觉噪音，并使用typedef来隐藏shared_ptr，类似于这样：

typedef boost::shared_ptr<SomeLongClass> SomeLongClassPtr;

所以这样：

void foo(const boost::shared_ptr<SomeLongClass>& a,
         boost::shared_ptr<SomeLongClass>& b);

变成了这样：

void foo(const SomeLongClassPtr& a, SomeLongClassPtr& b);

另一方面，我担心我会降低代码的明确性。

哪种风格更好呢？

- Alex B

---

这有点类似于你的typedef shared_ptr的约定是什么？的重复。 - James McNellis

@James，谢谢，我自己找不到这个问题。 - Alex B

请使用下划线代替大写首字母，因为这样很难阅读。 - Inverse

@Inverse：你加入了“风格圣战”。这是一场永远没有赢家的战争，将会持续到永远，或者说只要我们还有人类程序员......即使那时候谁也不知道。我想象甚至机器人之间也会为此而战。 :-) - JustBoo

没问题，我记得那部阿诺德·施瓦辛格主演的电影。他被派回过去刺杀下划线反抗军的领袖。 - Tom

@Tom，我真的笑出声了。好的。 - JustBoo

Answer 1

鉴于std :: string本身是一个typedef，我认为你没有问题。我自己这样做。

即使是Scott Meyers在类似情况下也建议使用typedef来方便阅读代码。

---

编辑： Effective C ++，第二版，第120页，第28项，第四段。“…提供typedefs以消除需要…”

更有效的C ++，第7次印刷，第237页，第31项第一段。

更有效的C ++，第7次印刷，第238页，代码示例后的第一段。

---

本质上，不用担心。 :-)

- JustBoo

---

我很想拥有一本Scott Meyers的参考书，但与此同时，我会相信你的话。 - Alex B

Answer 2

我们在代码中使用TypePtr typedefs表示shared_ptr<Type>对象。同时，也很有用地定义一个TypeConstPtr来表示shared_ptr<const Type>。

- James McNellis

---

同上。如果它提高了可读性和可维护性，那肯定不是坏事。 - Jon Purdy

Answer 3

我有点反对使用typedef来隐藏指针（或引用）的真实性，因为我看到了太多不可读的C代码。但是如果采用一些诡辩，我想shared_ptrs不是真正的指针，所以typedef是可以接受的。但是你会失去信息-你不能仅仅通过查看函数声明（或定义！）来确定其语义。

- anon

---

让我猜猜，你绝对不赞成在它前面加上一个“p”。那会让人想起匈牙利命名法，我们当然不能有任何这样的东西！我更喜欢实用主义而非从众心态。并且，我不使用或支持匈牙利命名法。不过，有时我会在指针名称前面加上一个“p”。 - JustBoo

@JustBoo 我以前从未被指责过跟随群众，但我想万事开头难。而且我自己也使用一种非常有限的匈牙利命名法——所有成员变量都以“m”为前缀。 - anon

@Neil：好的，那就这样吧。:-D 我也是。http://stackoverflow.com/questions/3461697/cstring-variable-name-prefix/3461766#3461766 偶尔加上一个“p”，就这样了。 - JustBoo

Answer 4

你可以将typedef命名为“SomeLongClassSharedPtr”，这既明确又易于输入。

这种做法的一个负面后果是，一些自动完成实现（例如Eclipse CDT中的）无法跟随它。但这并没有阻止我个人使用它。

- Onestone