Boost logo

Boost :

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
> 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.



"*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend,
Schmerzen aus Schwäche stillend.*" - Novalis 1798

Boost list run by bdawes at, gregod at, cpdaniel at, john at