什么情况下最合适使用std::nothrow
?
我只会在需要立即捕获std::bad_alloc
时,将其用作优化(或代码简化)。这种情况相当罕见,因为通常情况下,能够有用地处理内存不足的位置都不在调用点,而是在更高层次的代码中。通过将空指针传回到调用链中直到某个人可以处理问题的代码并不是 C++ 的惯用写法。
但也有可能在此处确实可以立即处理错误。例如,您可能处于这样的情况:如果有足够的工作空间,您将使用一种算法或技术,否则您将使用不同的、较慢的算法或技术。然而,您会直接使用new
来分配这样的工作空间吗?通常情况下不会。而且,您有时必须小心这种方法,因为如果您的操作系统过度承诺,那么通常情况下您无法在应用程序级别上优雅地处理内存不足问题。
请注意,涉及std::nothrow的表达式仍然可能抛出异常(特别是从正在分配对象的任何构造函数中),因此,如果您希望避免抛出异常,只有一个 thing 是不够的。您还必须确保构造函数不会抛出异常。
就我而言,不再有不使用异常的C++程序。我想,如果它们恢复了,可能是由于某种特定的样式指南,那么这也是需要 nothrow new 的另一个可能原因。
将C程序移植到C ++。您的C程序在每个malloc之后都有所有这些检查,而且没有异常的概念。因此,将每个malloc更改为new(nothrow)要比将每个malloc包装在try块中简单得多。
malloc
里不是更简单吗?即使在C++中,malloc
也不会抛出异常。 - Steve Jessopmalloc
和free
能够保证配合使用吗?如果不能,最简单的方法可能是进行转换,以便您可以保持一致性。 - Mark Ransommalloc
函数分配内存并将其留给调用者进行free
,那么C++版本的客户端可能更喜欢单纯地使用delete
,但是通过这种方式更改接口,您必须对已经使用旧C版本的任何C++代码进行更改。我认为如果不存在这样的现有C++代码,出于这个原因我可能会同意进行更改。然而,这种接口不太友好,改进C++版本的方法可能会更好。 - Steve Jessopmalloc
和free
不能一起使用的情况?根据§20.4.6,它们几乎必须一起使用。 - coniodelete
来代替malloc
,而不是用free
。 - Mark Ransommalloc
和delete
不会一起工作的保证。 - Steve Jessopnothrow
。我知道旧版本的C++(特别是微软的)在无法分配内存时不会抛出异常,而是返回NULL。这是一种与旧代码兼容的简单方法,而不是改变所有逻辑。
http://www.cplusplus.com/reference/std/new/nothrow/
这种构造很少使用,因为我怀疑它并不真正影响内存分配性能,而是可以用于方便。
尽管如此,通常更喜欢使用通用变量。
我可以想象这可以作为使用自定义分配器的快速路径优化 - 比如,在某个稍后/空闲时间失败当前请求并增加池。这几乎是一个边角情况。
new
永远不会返回null或抛出异常。因此,根本没有必要检查new/malloc的返回值。只需保持内存占用率较低,并让内存不足终结者关闭其他进程!