Looks like there's quadratic behavior.

Total instantiations: 45697 Location count cum. -----------------------------------------------------------------------------------------------------------------------

..\trunk\boost/variant/variant.hpp(666) 9604 9604 ..\trunk\boost/variant/variant.hpp(627) 9604 19208 ..\trunk\boost/variant/detail/visitation_impl.hpp(163) 4949 24157 ..\trunk\boost/variant/detail/visitation_impl.hpp(140) 4949 29106

In Christ, Steven Watanabe

Hi Steven, I'm really impressed with the amount of detail you have been able to produce in your analysis in such short time. How did (can) you count the number of instantiations? This type of analysis is really helpful in our compile-time reduction/analysis. I will try several suggestions; including suggested fix this evening and respond on the thread with the results. Paul

"Steven Watanabe" wrote in message news:4D289EAB.6000403@providere-consulting.com...

The tool I wrote is available through Subversion http://svn.boost.org/svn/boost/sandbox/tools/profile_templates

thanks for this!

AMDG On 1/9/2011 5:12 PM, Peter Foelsche wrote:

"Steven Watanabe" wrote in message news:4D289EAB.6000403@providere-consulting.com...

...

The tool I wrote is available through Subversion http://svn.boost.org/svn/boost/sandbox/tools/profile_templates

basic question: How do I compile this?

Don't. It's designed to be used with Boost.Build. (Actually running it requires 3 separate tools and the compiler.). The documentation should explain what you need to do. In Christ, Steven Watanabe

AMDG On 1/23/2011 4:57 PM, Peter Foelsche wrote:

First I figured I had to install boost book. This was a nightmare! I gave up on this.

So I just started reading the .qbk with a texteditor. But it still does not work.

C:\Users\Peter\sources7\diode>set BOOST_BUILD_PATH BOOST_BUILD_PATH=c:\Users\Peter\Sources\boost_1_45_0

C:\Users\Peter\sources7\diode>type *.jam

jamroot.jam

import template-profile ; template-profile diode : main.cpp ;

C:\Users\Peter\sources7\diode>type ..\..\user-config.jam using msvc : 10.0 : "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\cl.exe" : address-model=64 ;

modules.load template-profile : c:/users/peter/Sources/profile_templates/template-profile.jam ;

C:\Users\Peter\sources7\diode>bjam address-model=64 error: Unable to find file or target named error: '/boost//regex' error: referred from project at error: '/c:/Users/Peter/Sources/profile_templates/src'

Add use-project boost : c:\Users\Peter\Sources\boost_1_45_0 ; to your user-config.jam or to jamroot.jam. (I will fix this eventually...) In Christ, Steven Watanabe

Steven, I got it to work! Had to make some change to the jamfiles however to get it going on my workarea (non sandbox). How should i interpret the callgraphs? See sample below. Is the part below Parents the call(stack)? Need some help in doing analysis using this nice tool. Paul Call Graph I:\fcm3prod\BuildSet\repository\Boost\boost\boost/mpl/aux_/preprocessed/plain/fold_impl.hpp(131) (48) Parents: I:\fcm3prod\BuildSet\repository\Boost\boost\boost/mpl/fold.hpp(32) (48) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/mpl/transform.hpp(138) (24) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/variant/variant.hpp(114) (24) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/variant/variant.hpp(216) (24) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/variant/variant.hpp(908) (48) b.cpp(25) (48) Children: I:\fcm3prod\BuildSet\repository\Boost\boost\boost/detail/reference_content.hpp(115) (336/50) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/detail/reference_content.hpp(85) (336/50) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/mpl

AMDG On 1/11/2011 1:27 PM, Paul wrote:

Op 11-1-2011 21:48, Paul schreef:

...

I got it to work! Had to make some change to the jamfiles however to get it going on my workarea (non sandbox).

I can try to improve this. I know that it needs a Jamroot and there needs to be a use-project boost : path/to/boost ; somewhere. Is there anything else?

...

I:\fcm3prod\BuildSet\repository\Boost\boost\boost/variant/variant.hpp(908)

(48) b.cpp(25) (48) Children:

I:\fcm3prod\BuildSet\repository\Boost\boost\boost/detail/reference_content.hpp(115)

(336/50)

More specifically what does (336/50) mean here?

I don't think it really means anything. I've had a lot of trouble with the call graph, and I've never managed to get the numbers to come out to something meaningful.

...

I:\fcm3prod\BuildSet\repository\Boost\boost\boost/detail/reference_content.hpp(85)

(336/50) I:\fcm3prod\BuildSet\repository\Boost\boost\boost/mpl

Question: What should be an acceptable number of cum-instantiations for a cpp file?

I don't advise using this metric to determine what's acceptable. If it compiles in a reasonable amount of time using a reasonable amount of resources, then it's acceptable--reasonable being defined by what your willing to pay. The number of template instantiations doesn't translate directly into compiler resource usage. The tool is more designed to help you figure out what to look at, given that you already want to improve compilation time.

Of course i could break it down into several cpp's (however needing explicit instantiations since inclusion-model cannot be used in such case). I'm having doubts whether its wise to do so!?

In Christ, Steven Watanabe

AMDG On 1/8/2011 11:56 AM, Paul wrote:

I've done some testing based on the suggestions:

Adding a destructor to the 'dummy' types doesn't seem to make a difference.

Now that I've looked through the code, it's the copy constructor and default constructor that matter.

Adding boost::blank as the first type however makes a hugh difference: <snip>

Drawback of this approach seems to be that each visitor needs to have an operator()() receiving a boost::blank&; not a big problem anyway.

I failed to apply the patch-file on the 1.38 revision; either there is a problem with the patch.exe that i downloaded (for win32) or the patch-file doesn't match this revision. When you can send me a modified variant.hpp based on the file attached, then i will be happy to run some tests.

I was able to apply the patch. I've attached it. (zipped since it's rather large.)

I was wondering whether the found behavior is a bug or not; after all it seems to be functionally correct but it just doesn't scale very well. When this problem can be fixed in the variant.hpp then i guess that's preferred but what are the consequences at functional level and/or runtime performance?

The functionality should be unaffected. The runtime cost is one call through a function pointer. In Christ, Steven Watanabe

Variant type: v2    Foo logic:C Obj size: 80.6MB Exe size: 356KB Pdb size: 13.6MB Build time: 8:46 Peak commit: 1.4GB

Variant type: v2    Foo logic:C         Add boost::blank as first type Obj size: 2.6MB Exe size: 348KB Pdb size: 11.6MB Build time: 1:03 Peak commit: 600MB

Variant type: v2    Foo logic:C         Test with patch <==== Obj size: 4.6MB Exe size: 352KB Pdb size: 11.8MB Build time: 1:10 Peak commit: 600MB

Does the last one include both boost::blank and the patch, or the patch only?

AMDG On 1/8/2011 1:19 PM, Paul wrote:

Thanks for the modified header.

I've tested and it seems to work, see results below.

Cool.

Would this be a change that is candidate for a future boost release? And are you able to do just that?

I've committed it to the trunk. https://svn.boost.org/trac/boost/changeset/67798 In Christ, Steven Watanabe

AMDG On 1/9/2011 5:37 AM, Mathias Gaunard wrote:

On 08/01/2011 23:47, Steven Watanabe wrote:

...

...

Would this be a change that is candidate for a future boost release? And are you able to do just that?

I've committed it to the trunk. https://svn.boost.org/trac/boost/changeset/67798

What if I don't care that much about compile times and I don't want unnecessary runtime overhead?

This is in the code path that's executed when 1) The source type doesn't have a nothrow copy constructor, 2) The source type doesn't have a nothrow move constructor, and 3) None of the variant types has a nothrow default constructor. The cost is already 2 switch statements (more if there are a large number of types), 1 new/delete pair, 1 call to the copy constructor of the type that the variant already holds, 2 calls to its destructor, and 1 call to the copy constructor of the new type. a) If the small extra overhead actually matters to you, you should probably be avoiding this branch to begin with. b) There's no guarantee that it actually makes the code slower, since it significantly reduces the code size. (The O(n^2) is function templates that are doing real work.) In Christ, Steven Watanabe

AMDG On 1/8/2011 2:48 PM, Paul wrote:

I guess as was to fast there in being optimistic ;)

It seems there is another performance issue when i extend the number of types further to 75 (on the project we expect to grow to +/- 60 types).

typedef boost::mpl::vector75< boost::shared_ptr<C1>, boost::shared_ptr<C2>, boost::shared_ptr<C3>, ...

My machine simply runs out of memory (commit 3.0GB) while the compiler keeps consuming 100% for minutes...

From what i can see now is that no combination (adding boost::blank or not, patching variant.hpp or not) seems to succeed to compile and link <1min and <1GB or ram.

A test using boost::blank + the patched variant just finished on 4:00min.

Does the cost increase continuously, with the number of elements?

Steven, can you maybe invest with your tool where the load/instantiations are coming from?

Maybe in a few days. boost::mpl::vector75 doesn't exist without some extra work.

PS: I have downloaded your tool with svn, i intend to test/use it for myself as well. ;)

In Christ, Steven Watanabe

On 01/08/11 20:51, Larry Evans wrote:

On 01/08/11 18:32, Steven Watanabe wrote: [snip]

...

...

Steven, can you maybe invest with your tool where the load/instantiations are coming from?

Maybe in a few days. boost::mpl::vector75 doesn't exist without some extra work.

Why not just use variadic mpl:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/

which has no limit on mpl::vector size? It would simply involve adding another -I to the compile flags. [snip]

Or even try the attachment to see how one_of_maybe alternative to boost::variant: http://svn.boost.org/svn/boost/sandbox/variadic_templates/ boost/composite_storage/pack/container_one_of_maybe.hpp compares. -regards, Larry

On 01/09/11 02:29, Steven Watanabe wrote:

AMDG

On 1/8/2011 6:51 PM, Larry Evans wrote:

...

Why not just use variadic mpl:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/

which has no limit on mpl::vector size? It would simply involve adding another -I to the compile flags. [snip]

How exactly would that work with a compiler that doesn't support variadic templates?

Hmmm. Very good point. Sorry for noise.

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(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 as first template arg to the one_of_maybe template and then all the E_i's would be unsigned values. TIA. Larry

Dave, Another alternative would be to pass shared/base-ptr's and use double-dispatching to provide functions on concrete types. This however bothers the model-objects with visitation code; which is fine for 1 or 2 things but very disturbing on >10 functions. With the variant you can move the visitation logic completely to the client/caller code, Hopefully its not to vague...? Your option requires dynacasting and it doesn't allow the goodies such as enable-if on subsets of the variant types; which is al optimized at compiletime. I however agree that it's much simpler and in-fact we might had to explore this option more back then... ;) Thanks for thinking along. Paul Op 8-1-2011 21:53, Dave Abrahams schreef:

At Sat, 08 Jan 2011 02:17:36 -0500, Dave Abrahams wrote:

...

At Fri, 07 Jan 2011 23:45:04 +0100, Paul wrote:

...

In a project we are using variants holding shared_ptr's. These variants are typically 20 items large but are growing as the project progresses.

If it's really just shared_ptr's in the variant, I would seriously consider replacing it with shared_ptr<void> (with a type tag if necessary). Just a thought.

Seriously, could be a big simplification and speedup vs. using using variant.

not-going-to-mention-it-again-ly y'rs, Dave

...

If it's really just shared_ptr's in the variant, I would seriously consider replacing it with shared_ptr<void> (with a type tag if necessary).  Just a thought.

Seriously, could be a big simplification and speedup vs. using using variant.

Could you please elaborate a bit on this? How to replace variant with shared_ptr<void> and a tag? Wouldn't the tags be wrapped in a variant anyway? Thanks.

On 08/01/2011 23:34, Dave Abrahams wrote:

At Sat, 8 Jan 2011 23:34:47 +0200, Igor R wrote:

...

...

...

If it's really just shared_ptr's in the variant, I would seriously consider replacing it with shared_ptr<void> (with a type tag if necessary). Just a thought.

Seriously, could be a big simplification and speedup vs. using using variant.

Could you please elaborate a bit on this? How to replace variant with shared_ptr<void> and a tag? Wouldn't the tags be wrapped in a variant anyway?

No, tags could be an enum or a type_info*, for example

An enum (or an integer) is a much better idea than a type_info*, since it can be used in a switch statement, and can be mapped naturally to a type in a list of types as an index. Writing a variant replacement is actually quite easy, and doing so would greatly reduce your compile times. Variant is old, full of quirks, and doesn't scale well. Why it even requires its MPL input sequence to be Front Extensible (which it doesn't even state in its documentation) is beyond me. This is a very annoying limitation that makes it impractical to use with a large amount of types, since compatibility with joint_view would be very nice in that situation. The best option is probably to declare your variant-like type using a PP list of types. This way you can directly generate the matching switch statement with minimal overhead. If you need to take a MPL list as input, the best advice is probably to use Steven Watanabe's switch library, as it can generate a switch statement that converts runtime integers into compile-time ones.

Op 9-1-2011 17:29, Steven Watanabe schreef:

AMDG

On 1/9/2011 6:03 AM, Mathias Gaunard wrote:

...

Writing a variant replacement is actually quite easy, and doing so would greatly reduce your compile times. Variant is old, full of quirks, and doesn't scale well. Why it even requires its MPL input sequence to be Front Extensible (which it doesn't even state in its documentation) is beyond me. This is a very annoying limitation that makes it impractical to use with a large amount of types, since compatibility with joint_view would be very nice in that situation.

So, why not fix Boost.Variant instead of having everyone roll his own?

In Christ, Steven Watanabe

Fully agree on that Steven. Would help though to also mention its limitations + rationale in the documentation. It is mentioned to set /Zm on out of memory errors but the root-cause why you got the out-of-memory problem in the first place is not addressed. Paul

I'm not sure which platform you're on, but Christophe Henry found that, IIRC, /Gm switch one MSVC was the culprit for large compile/link times and memory usage with mpl::vectors with his msm library.

Jeff

Jeff, I'm on win32 msvc 2005, however i just checked and minimal rebuild is switched off :( Paul

On 1/10/2011 7:35 AM, Mathias Gaunard wrote:

On 09/01/2011 17:29, Steven Watanabe wrote:

...

AMDG

On 1/9/2011 6:03 AM, Mathias Gaunard wrote:

...

Writing a variant replacement is actually quite easy, and doing so would greatly reduce your compile times. Variant is old, full of quirks, and doesn't scale well. Why it even requires its MPL input sequence to be Front Extensible (which it doesn't even state in its documentation) is beyond me. This is a very annoying limitation that makes it impractical to use with a large amount of types, since compatibility with joint_view would be very nice in that situation.

So, why not fix Boost.Variant instead of having everyone roll his own?

Because, as I said, it's full of quirks. Writing your own implementation that fits your needs, compiles fast and runs fast is way less effort than trying to get fixes into variant.

Agreed. Perhaps it's time for V2 that does not necessarily have to be fully backward compatible. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

On 1/10/2011 12:22 PM, Steven Watanabe wrote:

AMDG

On 1/9/2011 7:57 PM, Joel de Guzman wrote:

...

On 1/10/2011 7:35 AM, Mathias Gaunard wrote:

...

On 09/01/2011 17:29, Steven Watanabe wrote:

...

On 1/9/2011 6:03 AM, Mathias Gaunard wrote:

...

Writing a variant replacement is actually quite easy, and doing so would greatly reduce your compile times. Variant is old, full of quirks, and doesn't scale well. Why it even requires its MPL input sequence to be Front Extensible (which it doesn't even state in its documentation) is beyond me. This is a very annoying limitation that makes it impractical to use with a large amount of types, since compatibility with joint_view would be very nice in that situation.

Agreed. Perhaps it's time for V2 that does not necessarily have to be fully backward compatible.

Why exactly would we need to break backwards compatibility? Eliminating the Front Extensible requirement shouldn't break anything. I don't know of anything in the interface of variant that would seriously interfere with a better implementation. I know that assignment is a mess, but there's a good reason it works the way it does.

Indeed! :-) Also, the Front Extensible quirk is easy to fix. I have code for it. In fact, I mentioned that Eric Friedman about it at BoostCon. Compile time? I think that too can be improved without having to rewrite again from scratch. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Op 9-1-2011 15:03, Mathias Gaunard schreef:

On 08/01/2011 23:34, Dave Abrahams wrote:

...

At Sat, 8 Jan 2011 23:34:47 +0200, Igor R wrote:

...

...

...

If it's really just shared_ptr's in the variant, I would seriously consider replacing it with shared_ptr<void> (with a type tag if necessary). Just a thought.

Seriously, could be a big simplification and speedup vs. using using variant.

Could you please elaborate a bit on this? How to replace variant with shared_ptr<void> and a tag? Wouldn't the tags be wrapped in a variant anyway?

No, tags could be an enum or a type_info*, for example

An enum (or an integer) is a much better idea than a type_info*, since it can be used in a switch statement, and can be mapped naturally to a type in a list of types as an index.

Writing a variant replacement is actually quite easy, and doing so would greatly reduce your compile times. Variant is old, full of quirks, and doesn't scale well. Why it even requires its MPL input sequence to be Front Extensible (which it doesn't even state in its documentation) is beyond me. This is a very annoying limitation that makes it impractical to use with a large amount of types, since compatibility with joint_view would be very nice in that situation.

We use following logic to work with subsets: //Join the two mpl sequences typedef boost::mpl::joint_view::type Mplv_t; typedef boost::make_variant_over< boost::mpl::copy< //make_variant_over requires an 'extensible sequence' while joint_view creates a forward sequence Mplv_t, boost::mpl::back_inserter > >::type

::type v_t;

This solution probably takes quite some compile-time as well but since the sequences only hold 5 or 6 types its sufficient. It does allow to use enable_if(contains) in the static-visitor functor which gives some really nice code; meaning efficient and easy to understand. Paul

The best option is probably to declare your variant-like type using a PP list of types. This way you can directly generate the matching switch statement with minimal overhead. If you need to take a MPL list as input, the best advice is probably to use Steven Watanabe's switch library, as it can generate a switch statement that converts runtime integers into compile-time ones.

On 01/15/11 08:54, Paul wrote:

It looks like we are heading for an alternative approach (again). Based on the boost::variant i'm writing my own variant that is optimized to only hold shared_ptr's.

First test seem promising i can finally create variants with 200 types in 2 sec compilation :) However binary invokation is even here quickly a problem, its generating 'paths' quadratically, 50 bounded types produce 2500 paths....

[snip] I think maybe that should be expected. After all, the number of binary signatures, where the first is from set, S1, and the second is from set, S2, and the sizes of S1 and S2 anr N1 and N2, then there has to be N1*N2 different signatures; hence, if N1=50 and N2=50, then there's 2500 different signatures. IOW, the binary visitor would have to have member functions something like: template < typename... S1 , typename... S2

struct bin_viz { void operator()(S1_0& s1, S2_0& s2); void operator()(S1_0& s1, S2_1& s2); void operator()(S1_0& s1, S2_2& s2); ... void operator()(S1_0& s1, S2_n& s2); void operator()(S1_1& s1, S2_0& s2); void operator()(S1_1& s1, S2_1& s2); void operator()(S1_1& s1, S2_2& s2); ... void operator()(S1_1& s1, S2_n& s2); void operator()(S1_2& s1, S2_0& s2); void operator()(S1_2& s1, S2_1& s2); void operator()(S1_2& s1, S2_2& s2); ... void operator()(S1_2& s1, S2_n& s2); . . . void operator()(S1_m& s1, S2_0& s2); void operator()(S1_m& s1, S2_1& s2); void operator()(S1_m& s1, S2_2& s2); ... void operator()(S1_m& s1, S2_n& s2); }; where S1 is a typelist with members S1_0, S1_1, ..., S1_m S2 is a typelist with members S2_0, S2_1, ..., S2_m IOW, there would be m*n member functions; hence, the quadratic compile times. However, I'm just guessing now, I've not actually measured it or tried to actually show this is the reason, but it would be the first place I'd look. HTH. -regards, Larry };

On 01/15/11 08:54, Paul wrote:

It looks like we are heading for an alternative approach (again). Based on the boost::variant i'm writing my own variant that is optimized to only hold shared_ptr's.

First test seem promising i can finally create variants with 200 types in 2 sec compilation :) However binary invokation is even here quickly a problem, its generating 'paths' quadratically, 50 bounded types produce 2500 paths....

[snip] Could you post a test driver showing the problem. I'd like to see how: http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_st... performs on the same or similar problem. TIA. Larry

On 01/17/11 14:18, Paul wrote:

la> [snip]

...

Could you post a test driver showing the problem. I'd like to see how:

In rough (but working) code:

class CVisitBinary : public static_visitor<bool> Is this the variant static_visitor or the one from your

However, it appears to need, at least, the #includes: #include #include #include #include #include Anything else? previous post: http://article.gmane.org/gmane.comp.lib.boost.user/65156 ? [snip]

template void TestVariantBinary() { typedef Layout::make_variant_over<Typelist>::type variant_t;

Is Layout a new namespace? I don't see it in this post or the previous one? [snip] Thanks for any help, Paul. -regards, Larry

On 01/17/11 18:35, Larry Evans wrote: [snip]

However, I'm still getting a compile error with gcc4.5.1. A partial list of the compilation output is also attached.

Any ideas what's going wrong?

[snip] Apparently gcc4.5.1 is more stringent about converting value types to reference types. Changing: template < typename VisitorType , typename IndexType > inline typename VisitorType::result_type apply_visitor_impl ( VisitorType& rVisitor , boost::mpl::true_ /*is_unrolled_t*/ ) const { typedef typename boost::mpl::at::type type_t; return rVisitor ( boost::static_pointer_cast<typename type_t::value_type> ( m_spSelect ) ); } to: template < typename VisitorType , typename IndexType > inline typename VisitorType::result_type apply_visitor_impl ( VisitorType& rVisitor , boost::mpl::true_ /*is_unrolled_t*/ ) const { typedef typename boost::mpl::at::type::value_type value_t; boost::shared_ptr spc(boost::static_pointer_cast(m_spSelect)); return rVisitor(spc); } at around line 163 of CLoPtrVariant.hpp solved problem.

On 01/27/11 13:26, Paul wrote:

...

[snip] The two attached files get me closer to a compilation. Two significant changes to the originals:

1) in assign_variant(,true), I had to disable the BOOST_STATIC_ASSERT because if was always causing a compiler error.

This might also indicate your are trying to assign a type to the variant that is not one of the bounded types. See your callstack.

After changing the code to: BOOST_MPL_ASSERT((boost::mpl::false_)); //Compiler error here indicates that (one of) the variants bounded types is no to allow the compilation to proceed a little further, the g++ compiler just prints: CLoPtrVariant.hpp: In member function 'void Layout::CConvertVariant<Typelist>::assign_variant(boost::shared_ptr<Type>&, mpl_::true_)': CLoPtrVariant.hpp:315:7: error: no matching function for call to 'assertion_failed(mpl_::failed************ mpl_::bool_<false>::************&)' So, there's no callstack available. BTW, if the BOOST_STATIC_ASSERT (or in the above modification, the BOOST_MPL_ASSERT) always fails, as it always must since it is passed the compile time constant, boost::mpl::false_, then the following assignment statement: m_rVariant = rValue; can never execute; so, why is it there? OTOH, why bother with assign_variant at all since the assert can take place in the calling routine.

...

2) I had to forward declare:

CLoPtrVariant(const CLoPtrVariant<Typelist2>& rOperand)

because the body used CConvertVariant which hadn't been declared yet.

Odd, since its a template/argument-naming dependant function and the poi is way down it should give you no problems!?

Does poi mean "point of instantiation"? If so, then I don't see how that's relevant. AFAICT, the problem is that there's no declaration of CConvertVariant before it's used and the g++ compiler, understandably, issues the diagnostic. Now if CConvertVariant were declared after the CTOR, but *within* the CLoPtrVariant class, then I think it would work; however, since CConvertVariant is declared outside of CLoPtrCVariant, there's a problem. Maybe visual c++ allows this freedom; however, I don't think that is portable.

Larry, Sorry about not having complete compiling testcode; i don't have a gcc environment available so it's difficult for me to get thing right. In the meanwhile i had to make some fixes as well, maybe you could try with attached code? Yuo will probably need to make the same changes/fixes as before, but it does have an important improvement to reduce number of instantiations. It's working on win platform vs2005; solution compilation reduced drastically with about 50%, also total heap usage dropped about 1.5GB. In your testapp, please also try with higher number of types, like to 100 or even 200, just to see where the limits actually are. Best regards, Paul

On 01/24/11 18:17, Larry Evans wrote:

On 01/24/11 14:30, Paul wrote:

...

Larry,

Sorry about not having complete compiling testcode; i don't have a gcc environment available so it's difficult for me to get thing right.

I'm pretty sure if you just started your improvements with my patches to your original code instead of starting your improvements starting from your original code, it would compile with g++.

Please try that and see if it doesn't compile with vs2005.

OTOH, if you'd like to plot the results yourself, you might find the attached .py file useful. Of course you'll need python installed as well as the python libraries described here: http://docs.scipy.org/doc/ http://matplotlib.sourceforge.net/contents.html The attached .py takes 1 argument, a filename. The contents of such a file name is: line1: a plot title line2: a list of space delimited column names. lines3-...: a table of x values vs y values. x values are in column1, y values are in the remaining columns. the result plot contains n curves where n is the number of columns -1. An example input file is also attached. HTH. -Larry

On 01/27/11 13:19, Paul wrote:

Hopefully attached header will pass your test? Since i heave no gcc or python environment currently available it will be more difficult for me to test this. I'm curious whether you find the same improvement between '''our''' variant compared to the boost::variant as we have seen on our project. Paul

Paul, it still does not compile with gcc. My code attached to earlier post forward declared: template<typename Typelist2> CLoPtrVariant(const CLoPtrVariant<Typelist2>& rOperand) ; this was necessary because the body used: CConvertVariant<Typelist> convert(*this); which had not been declare yet. Only after CConvertVariant was declared could g++ compile the body of: template<typename Typelist2> CLoPtrVariant(const CLoPtrVariant<Typelist2>& rOperand) Please, start from the code I provided earler which *does* separate the declaration of: template<typename Typelist2> CLoPtrVariant(const CLoPtrVariant<Typelist2>& rOperand) from it's defintiion, which occurs *after* the declaraion of: template<typename Typelist> CConvertVariant The code you recently posted does *not* sepearte the declaration from the definition of: template<typename Typelist2> CLoPtrVariant(const CLoPtrVariant<Typelist2>& rOperand) the same applies to another class, I think that class has wrapper in it's name. Also, use typename within templates typedef, as shown in my earlier post. Then I may be able to eompile the code with g++ *and* the code will be more portable. Since g++ is freely available, I'm wondering why you just can't install it on your machine and compilee your code with g++ to make sure your code is portable to g++. Is there come company which you work for that has some policy which forbids that? To summarize, why haven't you started your modification from the code I provided earlier which did sepearte the declaration from the definition of: template<typename Typelist2> CLoPtrVariant(const CLoPtrVariant<Typelist2>& rOperand) and which did provide the needed typename prefixes to the several typdefs where that was required by g++ (and I assume) by the c++ standard). -regards Larry