Subject: Re: [boost] variant2 never empty guarantees
From: degski (degski_at_[hidden])
Date: 2017-06-12 05:13:24
On 12 June 2017 at 03:41, Gavin Lambert via Boost <boost_at_[hidden]>
> 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
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.
-- "*Ihre sogenannte Religion wirkt bloÃ wie ein Opiat reizend, betÃ¤ubend, Schmerzen aus SchwÃ¤che stillend.*" - Novalis 1798
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk