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

On Tue, Jun 13, 2017 at 11:48 AM, Andrzej Krzemienski via Boost wrote:

2017-06-13 17:22 GMT+02:00 Gottlob Frege via Boost :

...

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