使用宏来缩短长卷增强模板名称是一种不好的做法吗？

Question

我厌倦了编写shared_ptr＆lt;＆gt;，它极大地延长了代码行。有什么理由不这样做吗？

Answer 1

为什么要使用宏？这种机制已经存在：

typedef boost::shared_ptr<some_longer_name_omg_help> pointer_type;

pointer_type p; // phew

---

如果您在评论中询问史蒂夫的建议，可以尝试：

template <typename T>
struct sp
{
    typedef boost::shared_ptr<T> type;
};

typedef sp<some_longer_name_omg_help>::type pointer_type;

但我不知道它是否会短得多。

我认为你的宏观使用是一种懒惰的表现，老实说。 boost::shared_ptr几乎是任何“冗长”的合理尺度，根本不是冗长的。你所做的只是破坏了可读性。

Answer 2

我有一个更简单的建议：使用更少的shared_ptr。如果你如此使用它们，听起来就像是盲目地依赖它们而不是垃圾收集器。 C ++要求您考虑对象所有权，但如果这样做，大多数智能指针都可以用简单的引用替换，这些引用不啰嗦。

你真的需要共享所有权吗？如果你停下来思考几分钟，我相信你可以确定一个对象的所有者，以及它的许多用户，它们只会在用户的生命周期内使用它。因此，只需将其作为所有者的本地/成员对象，并将引用传递给需要使用它的人。

不可否认，这并没有解决一般案例中的问题（还有许多其他冗长的模板名称），但在这种特殊情况下，我认为这是最好的解决方案。

Answer 3

不这样做的一个原因是新开发人员的工作效率。如果您雇用一名新员工，他可能会因为您了解如何更改标准增强API的复杂性而感到困惑。

当然，你可能会说，“但我们只会为这种类型做这件事”......我说，“注意那个滑坡”; - ）