On 01/09/11 12:55, Paul wrote:
Op 9-1-2011 1:32, Steven Watanabe schreef:
Does the cost increase continuously, with the number of elements?
Some more testresults, i've measured compile + link times for 10,20,30,40,... number of elements.
typedef boost::mpl::vector75< boost::shared_ptr<C1>, boost::shared_ptr<C2>, boost::shared_ptr<C3>, ...
No boost::blank added to the sequence, variant.hpp not patched (so original version). Also i removed the copy/assignment so its only construction of the variant, and 1 static-visit.
size: 10 = 0:09 size: 20 = 0:12 size: 30 = 0:19 size: 40 = 0:34 size: 50 = 1:02 size: 60 = 1:51 size: 70 = 3:09 size: 80 = 5:07 cl.exe working set = 1.7GB size: 90 = 9:58 compiler out of heap space (commit 3.2GB)
Maybe in a few days. boost::mpl::vector75 doesn't exist without some extra work.
Sizes beyond 50 (if i remember correct) are not supported by default with the boost distribution, but there is a script somewhere to generate the headers (such as boost/mpl/vector/vector100.hpp, 150, 200, ...).
It looks to me that the variant may not be that feasible for >50 types. Ofcourse it may be larger or smaller depending on the hardware and your patience ;) and ofcourse also to what extend the variant is used. We use for instance a simple struct to wrap the variant (fwd decl the struct) so the load is not exposed that much.
Paul
Paul, Can you post your test driver and whatever make-like file (Maybe, a .jam or CMake or plain Makefile) used to produce and report these results. I'd like to try it on the variadic templates one_of_maybe template mentioned in my other posts to this thread. BTW, there is a non-variadic version of one_of_maybe sitting in the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=composite_tagged_seq.zip&directory=Data%20Structures&PHPSESSID=13e034cbcc2d4c0a4c6e0b779540ef00 In case you want to try that. However, I have not tested that in a while and it requires explicit specification, via an enumerator , of what you're "injecting" into the variant. I.e. T_i t_i; v.inject<E_i>(t_i; where v is the variant with component types, T_1, T_2,..., T_n, and E_i is the corresponding enumerator. For example: enum E_I { e_1 , e_2 ... , e_n }; Or, you could just use mpl::integral_c<unsigned,0> as first template arg to the one_of_maybe template and then all the E_i's would be unsigned values. TIA. Larry