On Thu, Jan 22, 2015 at 3:49 PM, Edward Diener wrote:

On 1/22/2015 6:05 PM, Matt Calabrese wrote:

...

On Wed, Jan 21, 2015 at 4:52 PM, Matt Calabrese wrote:

I've found it useful, especially in tests, to easily be able to do

...

expression validity checking via SFINAE in a static assert.

Bump, and also a couple of additional macros for checking constexpr-ness of an expression are linked farther down in this email, using similar tricks as the SFINAE checks int the previous email (pushing more complicated checks into the body of a lambda such that the macro expands to an expression).

Motivation for this is that often when writing templated code it is difficult to be certain that a specific instantiation is actually constexpr even if the constexpr keyword is used with the function template. For instance, for a matrix type whose value type is a template parameter T, it can be difficult to know if matrix<T>'s multiplication operation actually results in a constexpr object, even if it has constexpr inputs. Particularly when designing such a library, it is useful to be able to write simple tests that check the constexpr-ness of a specified expression in the form of a static_assert. A proof-of-concept implementation of this is linked below:

http://ideone.com/ko09KQ

As an example of such a usage:

////////////////////

int foo(int) { return 0; }

STATIC_ASSERT_CONSTEXPR ( (constexpr int) var = 5, foo(var) );

////////////////////

Produces the error:

prog.cpp:70:1: error: static assertion failed:

********************

Given: constexpr int var = 5;

The following expression was expected to be constexpr but was not: foo(var)

********************

This looks interesting but I am confused about where this implementation is. Is it available somewhere ? is it documented at all ? Are there examples/tests ? Is there a good general of when some of these macros should/would be used in template code ?

Slimmed-down implementations were linked in the emails (this is just a request for comments, I'm not proposing anything -- more just seeing if people find this useful so that I can consider proposing a more capable boosty implementation): SFINAE checks: http://ideone.com/RHd6FM constexpr checks: http://ideone.com/ko09KQ The examples are self-contained and able to be compiled/run in the browser if you want to play around with them. Both examples have example uses at the bottom of the file. I apologize that they are not documented -- consider them just as a proof of concept to show that the macros work. Describing how they work is a bit complicated and I didn't feel like going into details. If any of the magic needs clarification, let me know. For details on how to invoke the macros linked, the basic pattern for the SFINAE checks are: STATIC_ASSERT_VALID ( (int) a, // This says "given a variable a of type int..." ++a // Would the expression ++a be "valid" ); The "invalid" expression check works similarly. Underneath the hood is an IS_VALID_EXPR macro that has the same form and is usable on its own, yielding a constexpr bool expression. For instance, you can use it to easily do: template <class T> struct has_preincrement_operator : std::integral_constant {}; The above checks that T supports ++a, without the user having to do SFINAE directly (it also does not place any other requirements on T, other than it not being a void type or an incomplete reference type, and probably a couple of other oddball cases, but those can all be handled gracefully with a slightly more complicated implementation). The constexpr macros work in the same manner, only you need to initialize your "given" objects. Another limitation of the constexpr facility is that your givens must all be constexpr if you reference them in the expression that you are checking. It also will produce a compile-time error instead of a nice static_assert if the expression yields void (there might be some magic to fix, but I haven't given it much thought). It will also fail if your expression is simply the name of a global object (there also might be a way around this). It looks like you are saying that in place of BOOST_STATIC_ASSERT one can

use your macros at compile time to produce compile time errors, but the majority of C++ expressions have to be evaluated at run-time. So is this strictly for compile-time expressions or what ?

These are strictly compile-time checks. I find them particularly useful for concept checking and for writing unit tests.

Your original OP looked like it worked with run-time expressions ( ++a, a+b etc. ).

It is doing expression-validity checking (using C++11 extended SFINAE rules). The ++a in the example email is checking if ++a would be valid if "a" were of the specified type during substitution. A more boostified version which I have implemented locally allows the SFINAE checks to work with any number of "given" declarations and any number of expressions. It only depends on Boost.Preprocessor. -- -Matt Calabrese

On Thu, Jan 22, 2015 at 4:12 PM, Matt Calabrese wrote:

On Thu, Jan 22, 2015 at 4:09 PM, Matt Calabrese wrote:

...

For instance, you can use it to easily do:

template <class T> struct has_preincrement_operator : std::integral_constant {};

Hmm, actually this use doesn't seem to work, though I'm not sure why... I should have tested it in the browser before posting the sample. I'm pretty sure it fails due to a compile-bug but I'm not entirely certain. -- -Matt Calabrese

On Thu, Jan 22, 2015 at 5:24 PM, TONGARI J wrote:

2015-01-23 8:26 GMT+08:00 Matt Calabrese :

...

On Thu, Jan 22, 2015 at 4:12 PM, Matt Calabrese wrote:

...

On Thu, Jan 22, 2015 at 4:09 PM, Matt Calabrese wrote:

...

For instance, you can use it to easily do:

template <class T> struct has_preincrement_operator : std::integral_constant {};

Hmm, actually this use doesn't seem to work, though I'm not sure why... I should have tested it in the browser before posting the sample. I'm pretty sure it fails due to a compile-bug but I'm not entirely certain.

I'm sure that lambda cannot be used in unevaluated context.

Right, but the magic of this trick is that it's not actually using the lambda in an unevaluated context (at least that's my understanding, and I've searched the standard for all instances of the term unevaluated)! A lambda itself never actually appears in a typeid/decltype/sizeof/alignof/noexcept. I do the tricks indirectly, using the lambdas just as a means to introduce declarations inside a nested scope of the expression and to create nested templates via generic lambdas for SFINAE. No lambda itself is actually invoked or directly used in an unevaluated context. I deduce information that the lambdas contain indirectly. Anyway, what is interesting is that the following *does* compile, as I thought it would: ////////// using T = std::integral_constant; ////////// The above uses the lambda internally in the same way as the previous email, but without failure. I just pass the result of the macro invocation as a compile-time bool template argument, with the main difference being that I use "int" here instead of a dependent type. I don't immediately see why that difference should cause failure. As far as I can tell, they should both compile, or if I'm wrong somewhere, it seems that NEITHER should compile. -- -Matt Calabrese

On Thu, Jan 22, 2015 at 6:49 PM, TONGARI J wrote:

You're right, I misunderstood the situation.

Your code doesn't work for clang, it seems to be more strict than g++: "error: a lambda expression may not appear inside of a constant expression" I suspect it's also a bug, since a hand-written functor does compile.

Hmm, this might be the problem, but I'm still not sure if this is a compiler bug or not. According to the standard, the type of the object yielded by a lambda expression has an implicitly declared default constructor/copy constructor/destructor as they are for any other type, and since the type is stateless, that would mean that those operations are constexpr. I don't mind that operator() isn't constexpr because I never actually use it as such. I suppose that if someone were to be pedantic, they could argue that even though all of the constructors are constexpr, the object still might not necessarily be a constant expression. Still, I'm not certain that the omission of such a detail would imply that the object isn't a constant expression. I think the standard may have just unintentionally left this unspecified, in which case it would be valid for a compiler to accept this code or for a compiler to deny the code. -- -Matt Calabrese

On Thu, Jan 22, 2015 at 8:05 PM, TONGARI J wrote:

Not sure if this helps: http://pfultz2.com/blog/2014/09/02/static-lambda/

I believe that will actually do the trick! -- -Matt Calabrese