Re: [boost] variant2 never empty guarantees

Subject: Re: [boost] variant2 never empty guarantees
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-06-12 00:41:20

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.

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

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.

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.

The exception (pun somewhat intended) to that is if some type explicitly 
provides additional reasons for assignment to fail -- eg. perhaps a 
one-time-assignable type or one that can be write-locked at runtime or 
something like that; but such a type should also clearly advertise what 
guarantees it provides in that case.

The question is then whether something like variant should try to 
provide those same guarantees or whether (like struct) it doesn't.