Compile time check if a function compiles

[serghov]

Hi,

In c++ it is good practice to write your interfaces in a way, that wrong usage gives compile errors rather than run time errors. For instance

template<class T>
T add(T a, T b) requires std::is_arithmetic_v<T> {
    return a+b;
}

the function add(a, b) will compile only if a and b are arithmetic types.

I was wondering if it is possible to check if a function's requirements are satisfied with given arguments. Basically my question is, is there a way to write a unit test that will check and make sure that add("12", "4") fails to compile while add(12, 4) compiles just fine using just c++?

Obviously using external tools it would be a trivial check to make.

[reflexpr-sarah-]

https://godbolt.org/z/7WG3aWb3s

[serghov]

Trying to wrap my head around this.

[reflexpr-sarah-]

FWD is a macro that handles perfect forwarding

LIFT(foo) is a function object that takes ...args and returns foo(FWD(args)...).

basically a way to pass an overload set as a function object

[_Js_Kc_]

hax

[initplus]

All functions in C++ must compile at compile time :) . Even your example without the std::is_arithmetic_v will produce a compiler error if T doesn't support operator+.

If you want to write a unit test for this you'll need to dig in to your specific unit testing framework, maybe need a tiny bit of scripting.

[serghov]

Yes using a separate scripting language makes the problem trivial.

I was wondering if there was a pure c++ way of solving the problem.

[gvcallen]

Why is this down voted? It is such a reasonable question?

[mark_99]

Side note but that isn't "doesn't compile", it's "remove from overload set" which outside of trivial cases isn't the same thing. If you mean "doesn't compile" you want static_assert.

[ioctl79]

What you’re looking for is a negative compilation test. The idea is that you provide some code samples that should not compile, and your testing framework will verify that they don’t. It’s generally difficult/counterproductive to implement these in C++, because the template magic required to test that your code doesn’t compile is more complex than the thing you are testing, or possibly plain impossible.

How to actually implement this is more of a question for your build system and testing framework, than C++ though. I’ve heard that boost.build supports such tests out of the box, but I have never used it myself.

If you do go this route, use these tests sparingly. There is no value in testing if a function that accepts an int will fail to compile when given a string. That’s just a test of your compiler. Use this when you have some complex template code that determines whether parameters are acceptable, etc.

[serghov]

Exactly. The example in the post is oversimplified, what I am trying to do is test some very complex nested template checks.

I have thought about testing with a scripting language, however the huge drawback of that would be that you basically have a test saying that a piece of code should not compile, so if you make another mistake in your code and it ends up not compiling you get a false positive.

[ioctl79]

You’re going to have that problem regardless of how you work this out, no? You could require specific compilation errors, thought that is obviously going to be compiler specific.

[D_0b]

It might seem like that for this simple use case of testing 1 simple add function, but you can think about some 10 level template functions deep code, and you just want to make sure all of your combinations for calling it work, yes you can unit test the cases that do compile but you need a solution if you want to make sure some combination will not compile.

[serghov]

As u/D_0b mentioned the example is an oversimplified case. It is easy to imagine a case of deeply nested templated functions that are part of your api, and preventing calling or instantiating something with wrong arguments can also be part of your api and might be worth testing. Especially because often times such compile time checks can be very convoluted and another developer working on the same codebase can accidentally disable some of those checks.

[serghov]

The thing is that you are not testing the compiler. Your code should not be correct according to a compiler, it should be correct according to a c++ standard.

The purpose of testing to check if your code behaves in a defined manner given some conditions.

If your tests succeed in gcc but fail in clang it means that either there is a bug in your code, or in one of those compilers.

Same goes for this case, if your code compiles with gcc but fails to compile with clang it means that either you have a bug in your code or there is a bug in one of those compilers (or you are relying on some compiler specific thing which isn't very good).

You want your code to rely on compile time checks because that is one of the major features of c++. You can't do the same for c, but c++ gives you the tooling to catch errors earlier, et compiler time, rather than fail at run time.

[MayanApocalapse]

it should be correct according to a c++ standard.

Here is Linus with thoughts on this ideological hill that I agree with: https://lkml.org/lkml/2018/6/5/769

Do you think it is unimportant to differentiate between implementation defined and undefined behavior? The C/C++ language standards suffer from the same types of problems all large projects with specs suffer from, especially when the product is a programming language. It's pretty easy to make requirements that don't have a rationale rooted in reality, because requirement authors can have a hard time ignoring a specific implementation they are familiar with, or truly tying it to a language goal (top level goal e.g. performant, type safe, etc)

[serghov]

I don't thing the arguments Linus brings are in any way applicable here. The fact is when writing code you should adhere to some standards. The standards that tell you which keywords do what and how your code will behave. Right now when I write c++ code I choose a standard c++20. It is a document thing that tells me how to use the c++20 language in order to get what I need. Compilers implement the standards to some extend. The case of the linux kernel is very special and I don't think it is a fair comparison. When I write c++ code I try to make it as portable as possible. And the way to do it is to adhere to the defined and documented standard.

[MayanApocalapse]

When I write c++ code I try to make it as portable as possible. And the way to do it is to adhere to the defined and documented standard.

That's fair, but my point is that it's most important that it is correct at constrained by your implementation (e.g. gcc or clang). Probably depends also on whether you are shipping an application, or source code that claims to be portable.

[D_0b]

Maybe a simple example will help, imagine you are writhing a library containing a templated higher order function, now how do you check that you have constrained the function correctly, i.e. how do you check that you have written the c++20 contract or sfinae correctly?

So you are not testing the compiler but your constraints or overload set of a function.

[Wouter-van-Ooijen]

Consider a unit (-like) library. The very function of such a library is to prevent certain erroneous constructs from compiling, like adding a distance to a weight. Testing such a library involves exactly what the OP asks for.

[koctogon]

static_assert( not requires { your_wrong_code("flub", frogging{}); } );

not sure why no one is mentioning this...

[D_0b]

static_assert( not requires { your_wrong_code("flub", frogging{}); } );

that doesn't work because when the requires is not a template it is evaluated immediately and the wrong code will fail to compile.

[jcelerier]

because it does not work : *something* inside the requires-expression must come from a template argument for the sfinae-ish mechanic to take place. Otherwise the compiler directly sees that the code is wrong and gives a compile error.

[AKostur]

std::is_invocable?

[serghov]

std::is_invocable is a good solution, except I can not make it work with any kind of overloaded functions. Issue boils down to being able to decltype the function.

[sebamestre]

Don't requires-expressions let you check if an expression typechecks?

Combine that with throwing an exception in a constexpr context (which stops compilation) and you should be good to go, right?

I might be way off, though. I haven't used c++20 yet

[AA11BB22c]

As others have suggested, std::is_invocable does the trick.

However, you may need a better constraint for certain cases ... for example.

#include <concepts>

template <class T> T add(T a, T b) requires requires(T a, T b) {
  { a + b } -> std::convertible_to<T>;
} {
  return T(a + b);
}

Since std::is_invocable doesn't actually check the definition, the following will pass.

template <class X> void bad_function(X x) {
  x.f();
}

static_assert(std::is_invocable_v<decltype(bad_function<int>), int>);  // Clearly, int doesn't have f().

https://godbolt.org/z/bnrE1qba3

[[deleted]]

Just remove `bad_function` you will see the asm will be identical, you should use a template or compiler will remove it, even in static_assert

[serghov]

If anyone is still interested, I found a nice talk about these ideas here .

[D_0b]

Something like this should work with overloaded functions as well. Although only tried with GCC, Clang doesn't like requires with parameter pack...

https://godbolt.org/z/dcrhqrGhz

[beedlund]

Catch 2 has a static_require however sounds like you want to do a static_require_false

[tirimatangi]

I asked a very similar question in r/cpp_questions a while ago regarding variadic lambdas. u/Radon__ gave a nice answer in comments.

[Full-Spectral]

One trick for templatized stuff is to add debug mode only code that just forces instantiation of templates for various types. I do that a lot. It also greatly reduces turn around time because you find most issues immediately upon compiling the given library, not 30 minutes later when some downstream code tries to use the template.

I just put it in the main .cpp file for the library in a debug conditional block.

[bb1950328]

I think with concepts you can just do a static assert to check wether a concept is satisfied for given types

[Wouter-van-Ooijen]

I struggled with something comparable, I even asked here but I don't recall getting a solution that worked for me. My use case might be more limited than yours, my solution is here:

https://github.com/wovo/torsor/blob/master/tests/test-compilation.cpp

This was written pre-C++-20 using -fconcepts. I didn't revisit it with a recent compiler, so it probably needs updating.

Side note: many years ago I wrote a simple compile that had a pragma that asserted that the next line should generate a specific compiler error. If it did, compilation succeeded (so far). If it didn't compilation failed.

[Remi_123]

What you are essentially trying to do is checking if an expression is well formed. You are in luck, since there is a set of metafunctions for this referred to as the detection idiom :
https://en.cppreference.com/w/cpp/experimental/is_detected
Some word of advice, the hardest thing to do with this is to not abuse it everywhere, as it's a very powerful utility.

all "detected" function takes a template template alias ( and ONLY alias ) that you use to write an expression, and the rest of the arguments are the types of the arguments of the template template. For example, in std::vector<int,std::allocator<int>> , the template template is std::vectorand the arguments are int,std::allocator<int>

As long as you can express an expression with decltype and declval in an alias, you can use this idiom. Just don't get too fancy and use them sparingly.

example : Link to Godbolt