本文介绍了nothrow或异常?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是一个学生,我有关于C ++的小知识,我试图扩大。这更像是一个哲学问题。我不是想实现某些东西。



  #include< new> 
// ...
T * t = new(std :: nothrow)T();
if(t)
{
// ...
}
// ...

将隐藏异常,因为与简单的 if(t)相比,处理异常更重不是正常的新的T()不是不太好的做法,考虑到我们必须使用 try-catch()检查一个简单的分配是否成功(如果我们不,只是看程序死)?



与使用新分配的优点(如果有) > nothrow new ?在这种情况下,异常的开销是微不足道的。



此外,假设分配失败(例如,系统中没有内存)。在这种情况下,程序可以做什么,或者只是失败。



有一个分配失败,一个 std: :bad_alloc throw n,我们如何假设,因为没有足够的内存来分配一个对象(例如a new int ),会有足够的内存来存储异常?



感谢您的时间。

解决方案

使用异常的惩罚确实很重,但是(在一个巧妙调整的实现中),惩罚只有在发生异常时才被支付 - 所以主线情况保持非常快,并且在你的示例中两者之间不可能有任何可测量的性能。 / p>

异常的优点是你的代码更简单:如果分配几个对象,你不必做allocate A; if(A){allocate B; if B)等...。清除和终止 - 在异常和主线情况下,最好由RAII自动处理(而如果你手动检查,你还必须手动释放,这使得它太容易泄漏内存)。

有很多事情,它可以做,最好的事情将取决于正在编写的程序。失败和退出(优雅或其他)肯定是一个选择。另一个是预先保留足够的存储器,使得程序可以继续其功能(可能具有降低的功能或性能)。它可以释放自己的一些内存(例如,如果它维护可以在需要时重建的缓存)。或者(在服务器进程的情况下),服务器可以拒绝处理当前请求(或拒绝接受新的连接),但保持运行,使得客户端不丢弃它们的连接,并且事情可以开始再次工作一次存储器返回。或者在交互/ GUI应用程序的情况下,它可能向用户显示错误并继续(允许他们修复内存问题,然后重试 - 或至少保存他们的工作!)。

不,通常标准库通常通过提前分配少量内存来确保在内存耗尽的情况下有足够的内存用于抛出异常。


I am a student and I have small knowledge on C++, which I try to expand. This is more of a philosophical question.. I am not trying to implement something.

Since

#include <new>
//...
T * t = new (std::nothrow) T();
if(t)
{
    //...
}
//...

Will hide the Exception, and since dealing with Exceptions is heavier compared to a simple if(t), why isn't the normal new T() not considered less good practice, considering we will have to use try-catch() to check if a simple allocation succeeded (and if we don't, just watch the program die)??

What are the benefits (if any) of the normal new allocation compared to using a nothrow new? Exception's overhead in that case is insignificant ?

Also, Assume that an allocation fails (eg. no memory exists in the system). Is there anything the program can do in that situation, or just fail gracefully. There is no way to find free memory on the heap, when all is reserved, is there?

Incase an allocation fails, and an std::bad_alloc is thrown, how can we assume that since there is not enough memory to allocate an object (Eg. a new int), there will be enough memory to store an exception ??

Thanks for your time. I hope the question is in line with the rules.

解决方案

The penalty for using exceptions is indeed very heavy, but (in a decently tuned implementation) the penalty is only paid when an exception is thrown - so the mainline case stays very fast, and there is unlikely to be any measurable performance between the two in your example.

The advantage of exceptions is that your code is simpler: if allocating several objects you don't have to do "allocate A; if (A) { allocate B; if (B) etc...". The cleanup and termination - in both the exception and mainline case - is best handled automatically by RAII (whereas if you're checking manually you will also have to free manually, which makes it all too easy to leak memory).

There are many things that it can do, and the best thing to do will depend on the program being written. Failing and exiting (gracefully or otherwise) is certainly one option. Another is to reserve sufficient memory in advance, so that the program can carry on with its functions (perhaps with reduced functionality or performance). It may be able to free up some of its own memory (e.g. if it maintains caches that can be rebuilt when needed). Or (in the case of a server process), the server may refuse to process the current request (or refuse to accept new connections), but stay running so that clients don't drop their connections, and things can start working again once memory returns. Or in the case of an interactive/GUI application, it might display an error to the user and carry on (allowing them to fix the memory problem and try again - or at least save their work!).

No, usually the standard libraries will ensure, usually by allocating a small amount of memory in advance, that there will be enough memory for an exception to be raised in the event that memory is exhausted.

这篇关于nothrow或异常?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-05 09:02
查看更多