On 7/18/2012 3:59 PM, Mathias Gaunard wrote: > On 18/07/2012 18:29, Eric Niebler wrote: > >> Is there some code in Proto that is forcing the instantiation of those >> specializations? Probably, and that would unintended. One approach would >> be to replace these normalized forms with an equivalent incomplete type >> and fix all places where the code breaks. > > Doesn't > > template<class T> > struct foo > { > typedef bar<T> baz; > }; > > foo<int> f = {}; > > instantiate bar<T>?
No, that merely mentions the specialization bar<T>, but it doesn't instantiate it. Nothing about that typedef requires bar<T> to be complete. You can try it yourself. If you make bar<T> incomplete, the above code still compiles. Also, matching against the partial specializations of detail::matches_ in matches.hpp also doesn't require the basic_expr specialization to be complete. But like I said, if there is some sloppy code in there that requires that nested typedef to be complete, it *will* get instantiated. Replacing it with an incomplete type will change it from a compile-time perf bug to a hard error, and those are easy to find and fix. > The problem I see is that for a regular Proto expression, the whole tree > gets instantiated twice for expr and basic_expr. If this is indeed happening, cleaning it up would be a nice perf win. Want to give it a shot? -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto