How to abuse a C++ compiler?
mysticalprogramming.wordpress.com
mysticalprogramming.wordpress.com
constexpr functions where quite restrictive in C++11. They could pretty much only contain a single expression and a return. C++14 significantly relaxes these restrictions.
http://en.wikipedia.org/wiki/C%2B%2B14#Relaxed_constexpr_res...
Type-level meta programming is still confined to using templates though...
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/m...
it calls a function at compile time to expand placeholders, and then compiles the generated string via the mixin() statement and carries on with the code. far more pleasant than c++.
Which there is less of need for this, since we have better type deduction in C++11 and 14 as well.
One of the fundamental properties people expect from a step called "compilation" is that it finishes. Also templates notation wasn't designed for this kind of use, and does not scale well for complex programs.
In Lisp code generation is done in Lisp, a notation that scales quite well, and there isn't a separarted step called "compilation". There is no general assumption that "execution" finishes.
It's more than a bit awkward really.
Still, the OP is right: it's funny.
... in order to evaluate InfRec<T>::value ...
InfiniteRecursion<T>::value
For the MutualRec it may not set the static const value as being derived from a constexpr until after having retrieved the value, causing it to access the member in the cache before it's constexpr'ness has been determined.
For the Contra example, it would return 1 from having not'ed the 0 it found in the uninitialized static const.
Russel's paradox would be subverted in the same manner as the Contra example, returning true because it found false ( 0 ) in an uninitialized member variable after looking up the partially instatiated template instantiation in a cache.
This is all conjecture, but it fits, and it's where I would look first if debugging this. I do not know whether this is allowed by the standard, but I'd wager they did not account for referring cyclically to partially instantiated template parameterizations in a cache. GCC's errorful death is probably the correct action here, rather than clang's return of spurious values.
#include <iostream>
int main()
{
static bool p = !p;
std::cout << p << std::endl;
}
The same thing happens with Russell's Paradox, with the added twist that HasElement<M, M> always resolves to the specialization HasElement<M, T> (it 'fits' better) rather than the general version, which is never used.
~/test/O$ cat break.cpp
#include <iostream>
template <typename A, typename B>
struct MutualRecursion {
static const int a = MutualRecursion< B, A >::b ;
static const int b = MutualRecursion< B, A >::a ;
};
int main( int argc, char ** argv ){
std::cout << MutualRecursion< float, int >::b << std::endl;
return 0;
};
~/test/O$ clang break.cpp
break.cpp:6:49: error: no member named 'b' in 'MutualRecursion<float, int>'
static const int a = MutualRecursion< B, A >::b ;
~~~~~~~~~~~~~~~~~~~~~~~~~^
break.cpp:6:24: note: in instantiation of template class 'MutualRecursion<int, float>' requested here
static const int a = MutualRecursion< B, A >::b ;
^
break.cpp:11:16: note: in instantiation of template class 'MutualRecursion<float, int>' requested here
std::cout << MutualRecursion< float, int >::b << std::endl;
^
break.cpp:7:24: error: in-class initializer is not a constant expression
static const int b = MutualRecursion< B, A >::a ;
^~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
~/test/O$
// static const int b = MutualRecursion< B, A >::a ;
static const int b = 10 ;
~~clang needs to wait until it has fully constructed a type before putting it into the cache, even if it might be slower in some recursive cases. Better than wrong in them.~~
I don't know if clang is in the wrong here, so I'm rejecting a couple of statements. Its method does not allow for compilation in these circumstances, but may be technically permissible, even if gcc jives with how I envision templates operating.
This seems to be a rare case where GCC is in the right, but I'd have to double-check the standard to be sure.
In effect, I was subverting the undefined behavior associated with expanding a set of infinitely deep template instantiations by accessing a variable that was as yet undefined at the point of access.
So, my initial retractions stand, and this compiler behavior will remain appropriately undefined.
Edit: checked iso/iec 14882 (c++03), 14.7.1 Implicit instantiation. §14 "The result of an infinite recursion in instantiation is undefined".
UPDATE: Forget the part about conformance - if it is undefined behavior every result is of course correct. I made the wrong assumption that the result should definitely be an error if the correct behavior is not defined or can not be attained.
Nevertheless, I think it's bad form for a compiler to take full advantage of undefined behaviour. Reinterpreting undefined behaviour as “should not compile” (failing that, “must crash”) is possible for almost all of C99; CompCert (formally verified C compiler) obviously does it, and the implementation is the easy part (formal verification being the complicated part).
That's not a lack of soundness. It's a lack of specificity. For cases like this, that's actually a feature, not a bug.
> Nevertheless, I think it's bad form for a compiler to take full advantage of undefined behaviour.
What exactly is "take full advantage of undefined behaviour"? Isn't any behaviour just as different from "undefined" as anything else?
> Reinterpreting undefined behaviour as “should not compile” (failing that, “must crash”) is possible for almost all of C99; CompCert (formally verified C compiler) obviously does it, and the implementation is the easy part (formal verification being the complicated part).
Clang not only has an ability to do this, it includes a flag to do a quick check specifically for undefined behaviour as well as an ability to provide a trap for undefined behaviour, which is terribly useful for tool builders.
Templates control actual code generation (that's sort of their point, with generics) so they must be handled later in the compilation, by the compiler proper.
in other words, both compilers seem to be being consistent with the previous demonstrated behavior using self-recursion, and the more generic template is being ignored altogether.
Am I perhaps missing a reason it was included?