Subject: Re: [boost] [static_if] Is there interest in a `static if` emulation library?
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-09-01 11:00:13
Matt Calabrese wrote
> On Sun, Aug 31, 2014 at 10:09 PM, Robert Ramey <
> > wrote:
>> pfultz2 wrote
>> >> since the condition is known at compile time, can't the optimizer be
>> >> counted on to
>> >> compile only the corresponding code? Why doesn't this give the same
>> >> effect as
>> >> the proposal?
>> > Both branches still have to compile even if the compiler determines it
>> > dead code.
>> > Paul
>> So what, the final executables would be equivalent if not identical.
> If both branches are able to compile, then yes, probably. The problem is
> that when you use this kind of branching, it's often the case that when
> condition is false, the true branch would have a compilation failure (or
> vice versa). Regardless of which branch is taken, even when the condition
> is a compile-time constant, both branches need to be compiled and any
> templates involved need to be instantiated, so using a regular if either
> could fail compilation or greatly increase compile-times, neither of which
> is desirable.
OK I see this now. I've used my method on a regular basis with good
results - but it seems that I never had a case where the compile
would fail on the false branch so it never came up for me.
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.
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?
-- View this message in context: http://boost.2283326.n4.nabble.com/static-if-Is-there-interest-in-a-static-if-emulation-library-tp4667118p4667140.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk