Boost logo

Proto :

Subject: Re: [proto] Refining the Proto concepts
From: Eric Niebler (eric_at_[hidden])
Date: 2012-07-18 19:09:59

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

Proto list run by eric at