Re: [boost] Re: variant questions
On Friday 29 August 2003 10:53 pm, Eric Friedman wrote: P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? (This of course does not solve the problem of offline access though...) There has been no progress, though it is much more likely now that I'm back at home base. Perhaps I can get something up and running at Sourceforge (if we have enough space!). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: variant questions
On Saturday 30 August 2003 08:00 am, David Abrahams wrote: Misha Bergal [EMAIL PROTECTED] writes: Eric Friedman wrote: P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? We can do that. Is there any info on how to use Boost.Build v2 to build BoostBook? I missed Misha's reply somehow. There is information on using BBv2 and BoostBook here: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it g. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Douglas Gregor [EMAIL PROTECTED] writes: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it Thanks. It worked. We will be publishing HTML docs starting with this night's run. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: variant questions
On Tuesday 02 September 2003 04:58 pm, Misha Bergal wrote: Douglas Gregor [EMAIL PROTECTED] writes: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it Thanks. It worked. We will be publishing HTML docs starting with this night's run. That's great, thank you! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Eric Friedman wrote: But suppose I have a variant v3, with content of a different type (call it T3). Then the assignment v1 = v3 is far more complicated (we can't use T1::operator=) and, without double storage, far more dangerous. The single storage implementation behaves as follows: destroy v1 content copy v3 content into v1 Assuming that memcpy to new location followed by memcpy back to original allocation is safe, you would do it using two additional storages local to operator= function. Let's call them local1 and local2. memcpy variant storage containing value1 into local1 initialize variant storage with copy of value3 content (may throw) memcpy variant storage containing value3 into local2 memcpy local1 back to variant storage destroy the content of variant storage (value1) memcpy local2 back to variant storage If second line of the algorithm above throws then: memcpy variant storage containing value1 into local1 initialize variant storage with copy of value3 content (throws!) memcpy local1 back to variant storage Too complicated? may be ... -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Alexander Nasonov Eric Friedman wrote: But suppose I have a variant v3, with content of a different type (call it T3). Then the assignment v1 = v3 is far more complicated (we can't use T1::operator=) and, without double storage, far more dangerous. The single storage implementation behaves as follows: destroy v1 content copy v3 content into v1 Assuming that memcpy to new location followed by memcpy back to original allocation is safe, you would do it using two additional storages local to operator= function. Let's call them local1 and local2. [snip] If I understand you correctly, earlier versions of variant did precisely what you describe. Unfortunately, the assumption you make is false in general. See http://aspn.activestate.com/ASPN/Mail/Message/boost/1311813. Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Eric Friedman wrote: If I understand you correctly, earlier versions of variant did precisely what you describe. Unfortunately, the assumption you make is false in general. See http://aspn.activestate.com/ASPN/Mail/Message/boost/1311813. Eric Well, is_polymorphicT based on compiler properties beyond the standrad. Why not optimize variant for compilers which safely memcpy forth and back? -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Alexander Nasonov wrote: Eric Friedman wrote: If I understand you correctly, earlier versions of variant did precisely what you describe. Unfortunately, the assumption you make is false in general. See http://aspn.activestate.com/ASPN/Mail/Message/boost/1311813. Eric Well, is_polymorphicT based on compiler properties beyond the standrad. Why not optimize variant for compilers which safely memcpy forth and back? I'm not sure how we would know... It seems to be a very bad idea to simply guess. Plus, for compilers where it is in fact not allowed, we still need a workable, defined solution. Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Eric Friedman [EMAIL PROTECTED] writes: David Abrahams wrote: Eric Friedman [EMAIL PROTECTED] writes: Dave, Please see the BoostBook reference documentation for variant. The HTML is quite out of sync with the current implementation. I haven't removed it from CVS yet though because I am still in the process of porting the examples, etc. to BoostBook. which is... where? The sources are all the *.xml files in the libs/variant/doc tree. If you'd like to see relatively recently-generated HTML, check out http://www.cs.rpi.edu/~gregod/boost/doc/html/variant.html. Suggestion: check an index page into the CVS which redirects to this page. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
BTW, after looking at the implementation I was a bit disappointed to see two copies of the storage. It seems to nullify one important reason for using variants (space savings), and it generates more code than a single-storage version. I know you had some rationale for that but I don't remember what it is; I hope it's in the docs along with some explanation of the expected size of the resulting object. Regards, Dave Double storage is needed to ensure strong guaraty for variant. I argued need for it before and I still believe we not nesseserily need to do that (I remember your post on the topic, that strong guaranty is a incorrect goal to pursue for the variant). Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Gennadiy Rozental wrote: BTW, after looking at the implementation I was a bit disappointed to see two copies of the storage. It seems to nullify one important reason for using variants (space savings), and it generates more code than a single-storage version. I know you had some rationale for that but I don't remember what it is; I hope it's in the docs along with some explanation of the expected size of the resulting object. Regards, Dave Double storage is needed to ensure strong guaraty for variant. I argued need for it before and I still believe we not nesseserily need to do that (I remember your post on the topic, that strong guaranty is a incorrect goal to pursue for the variant). Yes, it is true that double storage provides strong guarantee for variant. But that is not the point: double storage is needed to ensure even the basic guarantee! First let me acknowledge that the above rests on certain technical assumptions about variant's invariants (sorry about the tongue twister). Namely, it assumes that never empty is an invariant. Thus, for instance, boost::variantint, std::string *always* contains either an int or a std::string, and that these types maintain their own invariants. There are important reasons I have built variant on this assumption. Suppose I have a variant v1, with content of type T1, and a variant v2, also with content of type T1. Then the assignment v1 = v2 is perfectly straightforward: use T1::operator=. Obviously no double storage is needed for this case. But suppose I have a variant v3, with content of a different type (call it T3). Then the assignment v1 = v3 is far more complicated (we can't use T1::operator=) and, without double storage, far more dangerous. The single storage implementation behaves as follows: destroy v1 content copy v3 content into v1 The destruction will of course always occur because variant requires nothrow destructors from all of its bounded types. But what if the copy fails? Then the variant has no meaningful content whatsoever, since there is no guarantee we can restore the original content or, worse still, even construct new content of one of variant's bounded types. To see why this is a problem, we need to look back at the motivation for variant. Apart from efficiency, one of the significant advantages of using variant instead of boost::any is improved type safety, specifically at compile-time. Indeed, the visitation mechanism forces the user to handle every possible type of content. If we then go ahead and allow the possibility of the above empty state (to be distinguished from boost::empty content), we greatly complicate these semantics. Are we to say that anytime a variant is involved in a failed assign/swap operation, visitation will subsequently fail -- but only at runtime? Some may find this behavior acceptable. Personally, I'm not totally opposed, as there are alternative (albeit less elegant) options. But I think before throwing away double storage, we need to fully understand what else will leave with it. I invite (and would appreciate) feedback, as this is an important issue. Thanks, Eric P.S. Any type with a nothrow move constructor (which includes all types with a nothrow copy constructor) is not included in the double storage. Of course, except for types with nothrow copy constructors, this optimization is largely useless until the advent of a Boost.Move library. I do plan to submit one for inclusion in the Boost 1.32 release, but that presumably will not be for some months from now. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Dave, David Abrahams wrote: [snip] If you'd like to see relatively recently-generated HTML, check out http://www.cs.rpi.edu/~gregod/boost/doc/html/variant.html. Suggestion: check an index page into the CVS which redirects to this page. The link I provided above will not be home to the final documentation. As with the several other libraries using BoostBook, variant's documentation will need to be generated before release, at which point it will live in BOOST_ROOT/doc/html. To prevent further confusion before the release, I've added an out-of-date notice to the top of index.html with a link to the above HTML pages and directions to the XML sources. Eric P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? (This of course does not solve the problem of offline access though...) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Eric Friedman [EMAIL PROTECTED] writes: David Abrahams wrote: Eric Friedman [EMAIL PROTECTED] writes: Dave, Please see the BoostBook reference documentation for variant. The HTML is quite out of sync with the current implementation. I haven't removed it from CVS yet though because I am still in the process of porting the examples, etc. to BoostBook. which is... where? The sources are all the *.xml files in the libs/variant/doc tree. If you'd like to see relatively recently-generated HTML, check out http://www.cs.rpi.edu/~gregod/boost/doc/html/variant.html. What does Minimum strong exception-safety guarantee with respect to container state for all operations. with respect to container state mean? What does Efficient, stack-based implementation. ^^^ This mean? I can guess that it means variant doesn't use dynamic allocation, but that's not always true is it? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Dave, Please see the BoostBook reference documentation for variant. The HTML is quite out of sync with the current implementation. I haven't removed it from CVS yet though because I am still in the process of porting the examples, etc. to BoostBook. Sorry for the confusion. Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
David Abrahams wrote: [snip] 2. All members of variant satisfy the strong guarantee of exception-safety. Seriously? What if an underlying type's assignment operator gives only the basic guarantee? Surely, if you in fact use the underlying type's assignment operator you can't give the strong guarantee? I guess I should address this one a little more since I'm not exactly sure if even the updated documentation describes variant correctly in this regard. Given a variant type with bounded types T1,...,Ti,...,Tj...,Tn and variant objects vi (with content of type Ti) and vj (with content of type Tj), the exception safety guarantee for variant is as follows: Assignment: vi = Ti(...) // guarantee equal to Ti::operator= vi = vi // guarantee equal to Ti::operator= vi = vj // strong guarantee Swap: swap(vi, vi) // guarantee equal to swap( Ti, Ti ) swap(vi, vj) // strong guarantee Please let me know if the BoostBook documentation clearly describes what I present here. Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Eric Friedman [EMAIL PROTECTED] writes: Dave, Please see the BoostBook reference documentation for variant. The HTML is quite out of sync with the current implementation. I haven't removed it from CVS yet though because I am still in the process of porting the examples, etc. to BoostBook. which is... where? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
Eric Friedman [EMAIL PROTECTED] writes: David Abrahams wrote: [snip] 2. All members of variant satisfy the strong guarantee of exception-safety. Seriously? What if an underlying type's assignment operator gives only the basic guarantee? Surely, if you in fact use the underlying type's assignment operator you can't give the strong guarantee? I guess I should address this one a little more since I'm not exactly sure if even the updated documentation describes variant correctly in this regard. Given a variant type with bounded types T1,...,Ti,...,Tj...,Tn and variant objects vi (with content of type Ti) and vj (with content of type Tj), the exception safety guarantee for variant is as follows: Assignment: vi = Ti(...) // guarantee equal to Ti::operator= vi = vi // guarantee equal to Ti::operator= vi = vj // strong guarantee Swap: swap(vi, vi) // guarantee equal to swap( Ti, Ti ) swap(vi, vj) // strong guarantee Please let me know if the BoostBook documentation clearly describes what I present here. I will when I find out where it is. BTW, after looking at the implementation I was a bit disappointed to see two copies of the storage. It seems to nullify one important reason for using variants (space savings), and it generates more code than a single-storage version. I know you had some rationale for that but I don't remember what it is; I hope it's in the docs along with some explanation of the expected size of the resulting object. Regards, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: variant questions
David Abrahams wrote: Eric Friedman [EMAIL PROTECTED] writes: Dave, Please see the BoostBook reference documentation for variant. The HTML is quite out of sync with the current implementation. I haven't removed it from CVS yet though because I am still in the process of porting the examples, etc. to BoostBook. which is... where? The sources are all the *.xml files in the libs/variant/doc tree. If you'd like to see relatively recently-generated HTML, check out http://www.cs.rpi.edu/~gregod/boost/doc/html/variant.html. Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
