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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-13 15:48:30

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.

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

> etc, I don't want the cylinder to turn
> into a flat screen.
>

Agreed.

Regards,
&rzej;