[Variant] Documentation Questions/Notes
- What does this mean? Full value semantics, including adherence to standard overload resolution rules for conversion operations. Seems to me that it's impossible *not* to adhere to any standard rules. Is the part after the comma vacuous? - The "temporary heap backup" technique seems to have a hole: 1. Copy-construct the content of the left-hand side to the heap; call the pointer to this data backup. 2. Destroy the content of the left-hand side. 3. Copy-construct the content of the right-hand side in the (now-empty) storage of the left-hand side. 4. In the event of failure, copy backup to the left-hand side storage. 5. In the event of success, deallocate the data pointed to by backup. What happens in the event of a failure in step 4? - I note the section on motivation doesn't mention the new capabilities of C++11 unions. Now some of the constructs are possible... *if* you do all the bookeeping yourself. - I note that the implementation has at least some support for move semantics and yet the docs require all elements to be "bounded types", which in turn are required to be CopyConstructible. Is that accurate, or outdated? - "completeness at the point of template instantiation" is a rather odd thing to put in a concept. I suggest that that should be just part of the requirements on the variant template rather than on BoundedType. - Do the semantics for are_strict_equals at http://www.boost.org/doc/libs/1_51_0/doc/html/variant/tutorial.html differ from those of the built-in equality operator? - it might be worth making the point that recursive variants offer the ability to define complex linked data structures *as value types* in a type- and memory-safe manner. I.e. no explicit handling of pointers; copy construction and assignment "just work," etc. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
AMDG On 10/27/2012 10:50 AM, Dave Abrahams wrote:
<snip>
- The "temporary heap backup" technique seems to have a hole:
1. Copy-construct the content of the left-hand side to the heap; call the pointer to this data backup. 2. Destroy the content of the left-hand side. 3. Copy-construct the content of the right-hand side in the (now-empty) storage of the left-hand side. 4. In the event of failure, copy backup to the left-hand side storage. 5. In the event of success, deallocate the data pointed to by backup.
What happens in the event of a failure in step 4?
backup is a pointer. Copying it can't fail.
<snip>
In Christ, Steven Watanabe
on Sat Oct 27 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
On 10/27/2012 10:50 AM, Dave Abrahams wrote:
<snip>
- The "temporary heap backup" technique seems to have a hole:
1. Copy-construct the content of the left-hand side to the heap; call the pointer to this data backup. 2. Destroy the content of the left-hand side. 3. Copy-construct the content of the right-hand side in the (now-empty) storage of the left-hand side. 4. In the event of failure, copy backup to the left-hand side storage. 5. In the event of success, deallocate the data pointed to by backup.
What happens in the event of a failure in step 4?
backup is a pointer. Copying it can't fail.
Ah, thanks. I guess the docs could make that clearer. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Dave Abrahams <dave <at> boostpro.com> writes:
<snip>
- I note that the implementation has at least some support for move semantics and yet the docs require all elements to be "bounded types", which in turn are required to be CopyConstructible. Is that accurate, or outdated?
I think that furthest the requirement can be relaxed is to require bounded types to be either CopyConstructible or "VariantMoveConstructEnabled", where the latter involves whatever is required to allow variant to "move construct" the type (I haven't studied that code so I don't know precisely what is required).
<snip>
Dave Abrahams <dave <at> boostpro.com> writes:
<snip>
- Do the semantics for are_strict_equals at http://www.boost.org/doc/libs/1_51_0/doc/html/variant/tutorial.html differ from those of the built-in equality operator?
The built-in equality operator compares two instances of identically-typed variant. As a binary visitor, however, are_strict_equals can compare non-identically-typed variants. boost::variant<int, std::string> v1("hello"); boost::variant<int, std::string> v2("g'bye"); boost::variant<double, std::string> v3("hello"); assert(!(v1 == v2)); assert(v1 == v3);//compile error assert(boost::apply_visitor(are_strict_equals(), v1, v3)); Interestingly, it looks as if variant goes the extra mile to "prevent comparison with foreign types" (that's a comment from variant.hpp). I wonder why.
<snip>
on Fri Nov 02 2012, Brian Simpson <wheber-AT-hotmail.com> wrote:
Dave Abrahams <dave <at> boostpro.com> writes:
<snip>
- Do the semantics for are_strict_equals at http://www.boost.org/doc/libs/1_51_0/doc/html/variant/tutorial.html differ from those of the built-in equality operator?
The built-in equality operator compares two instances of identically-typed variant. As a binary visitor, however, are_strict_equals can compare non-identically-typed variants.
Interesting. hard to think of that as "strict," though.
boost::variant<int, std::string> v1("hello"); boost::variant<int, std::string> v2("g'bye"); boost::variant<double, std::string> v3("hello"); assert(!(v1 == v2)); assert(v1 == v3);//compile error assert(boost::apply_visitor(are_strict_equals(), v1, v3));
Interestingly, it looks as if variant goes the extra mile to "prevent comparison with foreign types" (that's a comment from variant.hpp). I wonder why.
Yeah. FWIW, while I do appreciate the answers, my *main* intention in posting these comments was to get the maintainer to fix the documentation. Hint, hint :-) -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
participants (3)
-
Brian Simpson -
Dave Abrahams -
Steven Watanabe