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
