On Mon, Oct 18, 2010 at 1:43 AM, Joel de Guzman <joel@boost-consulting.com> 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.