On 12 June 2017 at 03:41, Gavin Lambert via Boost
On 9/06/2017 22:39, degski wrote:
It's also not uncommon for applications to have memory leaks that
inevitably end in out of memory errors if left long enough.
As a former C99-guy, I would consider fixing ones' leaky applications with exceptions to be SB (Suspect Behaviour) by the developer.
There's no "fixing" involved. The simple fact is that copy-assignment will most likely throw std::bad_alloc if memory allocation is required but the available space is exhausted.
Do you mean running out of swap-space?
And this can happen much sooner than 2GB application memory due to heap fragmentation. (In fact on average it seems to occur closer to 1.2GB, although that depends a bit on your typical object size and allocation pattern.)
Unless it's other application(s) doing the fragmenting, I still argue it's programmer error. If and when doing many allocations/deallocations, the use of (a) memory-pool(s) will avoid this particular problem and willl be faster as well. Most developers don't do anything to defend against this because there
typically isn't any way to do so -- out of memory is usually application-fatal. As it should be.
See above. And one could also swap to disk oneself (mmap).
The point being that since std::bad_alloc is usually the only expected way for operator= to fail (assuming you weren't already in UB territory with a bad pointer or something), I can't think why anyone would have any expectation of exception guarantees for it in general.
Agree. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798