Re: [boost] variant2 never empty guarantees

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]>
wrote:

> 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