Re: [boost] [phoenix] request for a mini-review. (Re: Phoenix as a Boost library)

Subject: Re: [boost] [phoenix] request for a mini-review. (Re: Phoenix as a Boost library)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-10-18 01:40:21

On Mon, Oct 18, 2010 at 1:43 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 10/17/10 7:17 PM, Mathias Gaunard wrote:
>>
>> On 17/10/2010 06:01, Joel de Guzman wrote:
>>
>>> Yeah, that's what we do for 03. Let's call it less-than-perfect
>>> forwarding.
>>> It's the best we can do. Right now we have a PP constant for that. Mind
>>> you,
>>> even 3 args is still quite expensive!
>>
>> What's expensive? The generation of all these overloads with the
>> preprocessor or the actual lookup with that many overloads?
>>
>> If it's the former, I don't think that's very relevant. If you want to
>> use a tool like Phoenix, you probably should use a PCH version of it.
>
> I'm not sure. We'll need formalized tests to be sure. Perhaps
> Thomas knows better.

Preprocessor code generation takes time, and the time it takes is significant.
The most annoying fact is that even if we took care about not instantiating
templates if the user doesn't want them, the user pays for these preprocessor
iterations. Think about it, in the case of perfect forward emulation
the number of
overload created is O(N!). Even if N is large, the search for the
right overload shouldn't
be a problem (searching is in O(log(N))).

>> As a side note, more and more Boost libraries are making compilation
>> very slow, and it would be nice to integrate standardized PCH headers as
>> part of the Boost distribution, which would be automatically generated
>> at installation time.
>
> Agreed.

Instead of providing PCH headers, we could just preprocess our headers with some
kind of boost.wave driver, like MPL already does.