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