定制std :: shared_ptr或boost :: shared_ptr在NULL解引用上抛出异常 [英] Customising std::shared_ptr or boost::shared_ptr to throw an exception on NULL dereference

问题描述

我有一些项目使用 boost :: shared_ptr 或 std :: shared_ptr 要么执行得很快，如果有一个很好的答案这个问题，但不是其他）。 Boost实现使用Boost.Assert避免在 operator * 或 operator-> 中遇到空（NULL） code>在运行时;而libc ++实现似乎没有任何检查。

当然，应该先检查 shared_ptr 的有效性使用，一个大的，混合范式的代码库导致我想尝试一个异常抛出变化;因为大多数代码是相对异常感知的，并且最多会失败到高级但可恢复的状态，而不是 std :: terminate（）或segfault。 p>

我应该如何最好地定制这些访问器，同时保持 shared_ptr 的健壮性？看起来在 throwing_shared_ptr 中封装 shared_ptr 可能是最好的选择，但我很想打破魔法。最好是复制Boost源，只需将 ASSERT 更改为适当的 throw 语句即可？

---

对于适当的 smart_ptr< T> 类型，从宏扩展的typedef; ForwardDeclarePtr（Class）扩展为类似：

  
 typedef boost :: smart_ptr< Class> ClassPtr; 
  

一切都传递，接受或存储 ClassPtr - 所以我可以很容易地替换底层类型; 。

解决方案

里面真的没有魔法 std :: shared_ptr< T> 如果将其包装在自定义类中会被删除，该自定义类在解除引用 NULL 共享指针时会抛出异常。所以我不明白为什么这种方法不会工作，只要你的新的包装类遵循 std :: shared_ptr< T> 类型的所有语义。

BTW，你也可以采取稍微不同的方法，那就是创建一个封装类，它不会允许其他人通过 NULL 指向第一个包装的 std :: shared_ptr< T> 数据成员的指针。基本上，它将是一个在其构造函数中强制执行 std :: make_shared< T> idiom的类。我不知道，基于你的代码的工作，如果这是可能的，但它是另一种方式来规避问题使用RAII方法，而不是抛出异常。

I have a few projects that use boost::shared_ptr or std::shared_ptr extensively (I can convert to either implementation soon enough, if there is a good answer to this question for one, but not the other). The Boost implementation uses Boost.Assert to avoid returning in the case of encountering an empty (NULL) pointer in operator* or operator-> at runtime; while the libc++ implementation seems to lack any check.

While of course the validity of a shared_ptr should be checked before use, a large, mixed-paradigm codebase leads me to want to try an exception-throwing variation; as most of the code is relatively exception-aware and will at most fail to a high-level but resumable state, rather than std::terminate() or segfault.

How should I best customise these accessors while maintaining the robustness of shared_ptr? It seems that encapsulating shared_ptr in a throwing_shared_ptr may be the best option, but I'm wary of breaking the magic. Am I best off copying the Boost source and just changing the ASSERTs to an appropriate throw statement?

---

The actual type name used everywhere for the appropriate smart_ptr<T> type is a typedef expanded from a macro; i.e. ForwardDeclarePtr(Class) expands to something like:

class Class;
typedef boost::smart_ptr<Class> ClassPtr;

Everything passes, takes, or stores a ClassPtr - so I can replace the underlying type pretty freely; and I suspect this alleviates the potential slicing/hiding issue.

解决方案

There's really no "magic" in std::shared_ptr<T> that would be removed if you wrapped it inside a custom class that would throw an exception when dereferencing a NULL shared pointer. So I don't see why that approach wouldn't work, as long as your new wrapper-class follows all the semantics of the std::shared_ptr<T> type.

BTW, you could also take a slightly different approach, and that is create a wrapper-class that simply won't allow others to pass NULL pointers to the wrapped std::shared_ptr<T> data-member in the first-place. Basically it would be a class that would enforce the std::make_shared<T> idiom in its constructor. I'm not sure, based on the workings of your code if this is possible, but it's another way to circumvent the problem using a RAII approach rather than throwing exceptions.

这篇关于定制std :: shared_ptr或boost :: shared_ptr在NULL解引用上抛出异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！