I may not have time for review, but just one simple question: what are the advantages/disadvantages/differences in usage with stl_container<boost::variant>? Gennadiy
Gennadiy Rozental wrote:
I may not have time for review, but just one simple question: what are the advantages/disadvantages/differences in usage with stl_container<boost::variant>?
Disclaimer: I'm not a regular user of boost::variant. I believe the key differences is what information is available / fixed at compile time rather than run time. So considering an example from the variant docs: std::vector< boost::variant<int, std::string> > vec; vec.push_back( 21 ); vec.push_back( "hello " );Here the actual types of the elements of vec would have to be tested at run time, and the length of vec can be varied at run time by pushing back more elements. Iterating over the sequence in algorithms will require runtime overhead to manipulate the iterators, compare them for equality etc. Compare this with: boost::fusion::vector<int, std::string> vec2(0, "hello world"); Here the types of vec2 are fixed and available at compile time. In fact boost::fusion::vector<int, std::string> is an MPL sequence. The length of vec2 is also fixed at compile time, pushing back another element on to a fusion sequence will actually result in a sequence of a different type. Iterating over vec2 using the fusion algorithms should not incur significant runtime cost (assuming sufficient inlining from the compiler used). Having the type and length information available to the compiler may help to automatically pick up certain classes of bugs that may only show up at runtime with the container of variants strategy. I hope that helps discriminate between the 2 approaches. Thanks Dan
"dan marsden" <danmarsden@yahoo.co.uk> wrote in message news:20060506075932.96933.qmail@web25106.mail.ukl.yahoo.com...
Gennadiy Rozental wrote:
I may not have time for review, but just one simple question: what are the advantages/disadvantages/differences in usage with stl_container<boost::variant>?
Disclaimer: I'm not a regular user of boost::variant.
I believe the key differences is what information is available / fixed at compile time rather than run time.
Ok. But I would be more interrested in pratiacal approach. So my questions would be: 1. Which tasks require fusion::vector and does not accept vector<variant>? 2. Which tasks require vector<variant> and does not accept fusion::vector? 3. Which tasks I could prefer fusion::vector for? What practical reasons? And if this is performance what is a performance advantage 1%, 10%, 50%? 4. Could you compare from usdabiltiy standpoing all the operation shared by this two approaches? Gennadiy
Gennadiy Rozental wrote:
"dan marsden" <danmarsden@yahoo.co.uk> wrote in message news:20060506075932.96933.qmail@web25106.mail.ukl.yahoo.com...
Gennadiy Rozental wrote:
I may not have time for review, but just one simple question: what are the advantages/disadvantages/differences in usage with stl_container<boost::variant>?
Disclaimer: I'm not a regular user of boost::variant.
I believe the key differences is what information is available / fixed at compile time rather than run time.
Ok. But I would be more interrested in pratiacal approach. So my questions would be:
1. Which tasks require fusion::vector and does not accept vector<variant>?
Tasks where compile time access to the types of the sequence elements. Code that uses expression templates such as spirit, lambda libraries etc. would benefit from the ability to manipulate unnamed collections of types. Code where testing the types of the elements at runtime is inappropriate or too expensive in terms of runtime or footprint size (see below).
2. Which tasks require vector<variant> and does not accept fusion::vector?
If the number of elements to be inserted into the sequence cannot be decided until runtime, then the fixed size nature of fusion sequences will not be suitable for your programming task.
3. Which tasks I could prefer fusion::vector for? What practical reasons?
Well anything where you require hetrogenous containers and algorithms to manipulate them. A few examples of where this would be useful: *Expression template heavy libraries - such as spirit, phoenix etc. *Libraries such as bind that may need to bundle up collections of arguments, and manipulate those collections, this is a natural operation for a tuple lib. *An iterator adaptor such as a zip iterator would benefit from the ability to return tuples (fusion sequences) of references to the members of the zipped sequences. *Anywhere you find yourself needing std::pair, but 2 elements really isn't enough, std::pairs are really just a tuple type with 2 elements. Contrasting with using containers of variants, you wouldn't expect to use a 2 element container of variants to insert into a std::map.
And if this is performance what is a performance advantage 1%, 10%, 50%?
I've attached a simple performance test to compare using fusion versus a container of variants, to contrast the 2 approaches. Output below: VC8.0 Short test ... 80 80 Fusion vector size : 12 Variant vector size (includes vector size + data) : 48 Fusion vector time : 5.11855e-009 Variant time : 1.11818e-007 Long test ... 480 480 Fusion vector time : 1.76728e-008 Variant time : 5.51224e-007 ////////////////////////////////// VC7.1 Short test ... 80 80 Fusion vector size : 12 Variant vector size (includes vector size + data) : 48 Fusion vector time : 1.86265e-008 Variant time : 1.33991e-007 Long test ... 480 480 Fusion vector time : 9.67979e-008 Variant time : 6.55174e-007 ////////////////////////////////// g++3.4 Short test ... 80 80 Fusion vector size : 16 Variant vector size (includes vector size + data) : 44 Fusion vector time : 5.49555e-08 Variant time : 4.74453e-08 Long test ... 480 480 Fusion vector time : 2.90394e-07 Variant time : 2.08855e-07 /////////////////////////////////// Icl 9.0:---------------------------------------------- icl -Ox -Qipo -EHsc -IC:\CVS\fusion-2\spirit -IC:\CVS\Boost fusion_vs_variant.cpp Short test ... 80 80 Fusion vector size : 12 Variant vector size (includes vector size + data) : 48 Fusion vector time : 1.16378e-008 Variant time : 4.09484e-008 Long test ... 480 480 Fusion vector time : 6.52075e-008 Variant time : 1.52826e-007 As you can see, footprint size is consistently about 4x smaller for Fusion versus the variant approach. Performance is signicantly faster in all cases, except the gcc test, where variant actually outperforms. We've not traced why gcc is failing to optimize the test case as well as the other compilers. Of course a benchmark and may not reflect the usage patterns in a specific application...
4. Could you compare from usdabiltiy standpoing all the operation shared by this two approaches?
That is an extremely broad question, did you have any specific concern in mind? Hope that was helpful Cheers Dan
Gennadiy Rozental wrote:
I may not have time for review, but just one simple question: what are the advantages/disadvantages/differences in usage with stl_container<boost::variant>?
Hi, Here's another compelling reason why you'd use tuples: Try to implement Boost.Parameter or Boost.Bind or Boost.Lambda using std::vector<variant>. You can't! The types are unbounded. Variant can only deal with bounded types. From the variant docs: ''' A discriminated union container on some set of types is defined by instantiating the boost::variant class template with the desired types. These types are called *bounded types* ''' emphasis mine. But really, is this a review of tuples again? I think we are comparing apples and oranges again. tuples and variants are different tools for different tasks. Sure you can use a hammer to drive a screw, but I'd rather use a screwdriver. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (3)
-
dan marsden -
Gennadiy Rozental -
Joel de Guzman