Re: [boost] variant2 never empty guarantees (was: Re: Outcome/expected/etc/etc/etc)

Subject: Re: [boost] variant2 never empty guarantees (was: Re: Outcome/expected/etc/etc/etc)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-13 16:56:23

On Tue, Jun 13, 2017 at 11:48 AM, Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
> 2017-06-13 17:22 GMT+02:00 Gottlob Frege via Boost <boost_at_[hidden]>:
>
>> First theoretical, then more real-ish:
>>
>
> Thank you. It is easier to think about real problems.
>
>
>>
>> I have a drawing program that draws rectangles, circles, triangles.  I
>> want to change a circle to a triangle.  The user expects it to work,
>> or a reason why it failed.  They don't want the circle to become a
>> rectangle.
>>
>> More realistic, but exactly the same:
>>
>> In my codebase of projection mapping (multiple projectors projecting a
>> seamless image onto a surface) we have different screen types - flat,
>> cylinder, spherical, and custom (mesh file).  Each type comes with a
>> bunch of settings, so it isn't just a enum, each is a separate type.
>> The user can select which they want from a drop-down.
>>
>
> Does any of this types throw upon move construction?
>
>
>>
>> This is currently _not_ using a variant, but I think it should.
>> However, when the user switches from cylinder to "custom" and the mesh
>> is invalid
>
>
> At which point is it determined that the mesh is invalid? My point with
> this is that in the assignment of the form:
>
> variant<types...> = Mesh{params...};
>
> If constructing a mesh fails (because it would be invalid), no assignment
> is even attempted.
>

Probably true.

>
>> or out of memory,
>
>
> But what does it mean that you get out-of-memory situation when a user
> tries to change the projection? Will you be able to recover from it other
> than resetting everything?
>

Well, I find there tends to be two kinds of "out of memory":
1. large allocations - Images, etc. - can't open giant image file
because you need gigs of memory
2. small allocations - C++ objects - can't allocate ~ 100s of bytes.

The first is "normal" and a program needs to handle that.
The second means you are screwed.

A Mesh actually falls into the 1st category.
Of course that also means that you tend not to copy Mesh objects, you move them.
But unless Mesh was made move-only, someone will likely inadvertently
copy instead of moving.
(I do tend to make things like this move-only, then add an explicit
copy() function, but that doesn't always happen.)

This is basically why I'm satisfied with std::variant - move should
never throw.  If it does, it was a tiny allocation, and you were
screwed anyhow.  No one should have a move that does a large
allocation.

So in my world, std::variant already has the never-empty (and never
valueless_by_exception) guarantee.

So std::variant made some pragmatic choices, and my code makes some
pragmatic choices, but if we want "perfection", that would be nice,
and the examples above are as realistic as I can give.

Tony

>
>> etc, I don't want the cylinder to turn
>> into a flat screen.
>>
>
> Agreed.
>
> Regards,
> &rzej;
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost