c++ - 有什么理由使用原始指针来进行RAII吗？ C++ 11/14

Question

有什么理由在C++ 11/14中仍然使用原始指针(用于托管资源)吗？

是否应该将类中的资源成员变量保存在自己的智能指针中以进行自动RAII，而无需在析构函数中进行清理？

智能指针的实现是否内联，这样做没有开销？

Answer 1

Are there any reasons to still use raw pointers (for managed resources) in C++11/14?

我假设“托管资源”是指“拥有的资源”。

是的，原因如下:

在推断问题时，有时您想引用一个对象或不引用任何对象，并且该对象可能随时间而变化。在这种情况下，您必须使用原始指针，因为在这种特定情况下，现在没有其他选择。稍后可能会有关于添加“哑”非所有者指针的提议，该建议只是阐明了指针的作用(观察/引用，不是自己的)。同时，建议您尽量避免使用new / delete，并且仅将原始指针用作“无主引用”可重新分配的引用。

您仍需要原始指针来实现非原始指针和任何低级RAII构造。并非每个人都需要使用基础库，但是如果您这样做，那么当然需要使用基本结构。例如，在我的域中，我经常不得不以不同的方式构建自定义的“对象池”系统。在实现过程中的某个时刻，您必须操纵不是对象的原始内存，因此您需要使用原始指针进行处理。

与C接口(interface)通信时，除了将原始指针传递给使用它们的函数外，您别无选择。许多C++开发人员必须执行此操作，因此只有在代码的某些特定区域中才能使用它们。

大多数使用C++的公司都没有C++的“现代C++”经验，并且在实际上不必要的地方使用使用很多指针的代码。因此，在大多数情况下，将代码添加到其代码库中时，公司的代码环境，政治，同伴压力和惯例可能会迫使您使用指针，而在更“现代c++”用法的公司中，它将使用没有通过同行评审。因此，在选择技术时，还应考虑同事的政治/历史/社会/知识基础。或者确保您工作的公司/项目与您的工作方式相匹配(这可能会更难)。

Should resource member variables in a class be held in their own smart pointers for automatic RAII without need for cleanup in destructor?

在最佳情况下，资源成员变量应该只是没有明显指针的成员，甚至不是智能指针。智能指针是操纵原始指针和纯RAII样式的代码之间的“桥梁”。如果您完全控制某些代码，并且是新代码，则可以完全避免在界面中使用智能指针。也许您会在实现中需要它们。请记住，没有实际的规则，只有关于您可能会得到的结果的建议

Is the implementation of smart pointers inlined that there is no overhead in doing so?

标准智能指针的实现尽可能高效，因此可以内联大多数代码。但是，他们并不总是免费的，这取决于他们的实际工作。例如，在几乎所有情况下，unique_ptr都是一个原始指针，仅在其使用位置周围进行其他检查。因此它是“免费的”。另一方面，shared_ptr必须维护一个计数器，该计数器可以知道有多少其他shared_ptr引用同一对象。可以在做shared_ptr副本的多个线程上更改该计数器，因此它必须是原子的。更改原子计数器的值并非总是免费的，并且应始终假定与复制原始指针相比，成本更高。

因此，“取决于”。

只是:

尽可能多地使用RAII，而无需在接口(interface)中暴露任何类型的指针(无论是否智能)；

如果必须使用拥有的指针，

在实现中使用标准的智能指针。

仅在需要引用对象，空值或随时间变化的其他对象而不拥有它们时才使用原始指针。

避免在接口(interface)中使用原始指针，除非允许传递可选对象(当nullptr是正确的参数时)；

从用户的 Angular 来看，您最终将获得似乎不操纵指针的代码。如果您有遵循这些规则的几层代码，那么这些代码将更易于遵循和高度可维护。

有关的注释来自: When to use references vs. pointers

Avoid pointers until you can't.

还要注意，肖恩·帕恩斯(Sean Parents)在最近的演讲中也将智能指针视为原始指针。实际上，可以将它们封装为与所操纵的实际概念相对应的值语义类型的实现细节。另外，在实现中使用类型擦除技术，但不要将其暴露给用户，有助于某些库结构的可扩展性。