Subject: Re: [boost] [static_if] Is there interest in a `static if` emulation library?
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2014-09-01 14:26:27
On Mon, Sep 1, 2014 at 8:00 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> The compile-times argument doesn't impress me much though. Using
> a much more complex syntax or new library to shave a tiny bit of
time of the compilation isn't a good trade off for me.
The problem is that it can be far from tiny in practice. Compile-times are
often proportional to the amount of template instantiations you make, and
so when one branch makes a lot of them (I.E. one line of code instantiates
a ton of templates indirectly), it's horrible. Have you ever made a Spirit
grammar that takes minutes to compile? Now imagine that each branch of an
if at the top level creates a slightly different grammar or that uses it in
a different way. Even if your condition is known through a compile-time
constant bool, If you don't add a level of indirection to prevent both from
being instantiated, either manually or by way of a higher-level facility
like a static if, your compile time for that translation unit can possibly
double, or worse.
It does raise an interesting question though. Wouldn't it be a good thing
> for the compiler to totally skip syntax checking for branches known to
> be false at compile time - perhaps as a release mode option?
While it would be nice to more easily write code that's more lazy about
instantiation like this, I don't think it's quite so simple to add to the
language quite like that, and especially not as something that changes
based on a compiler option. We have one language and that language doesn't
actually have a notion of "release" mode, even though your compiler might.
It's also scary because in C++, whether or not a template gets instantiated
can affect things unrelated and at a high level, like overload resolution
in seemingly disconnected parts of code (such as if the template being
instantiated has a friend function in it). That said, compilers can and do
have options that make them noncompliant, so if one compiler vendor wanted
to, there's nothing stopping them from creating such an option, but I would
be very afraid of it.
-- -Matt Calabrese
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk