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