Jan 232015
 

Sean Parent posted today via Twitter this small neat algorithm:

 

 

Problem:

During my today’s work I came across the problem that inside a predicate there was a check if a specific enum value is equal to a set of possible values.

So the code looked like this:

I don’t like this collection of comparisons for equalness. From my point of view it is some kind of semantically copy-and-paste.

So with Sean’s code in mind I started thinking and I searched for alternatives. The first used a std::initializer_list:

So the example from above would read like this:

That is already better, but it does not read so fluently. So I tried to solve this with a builder like pattern:

The code example would then be like this:

That’s much better, but the curly braces inside the parameter are annoying. It would read much better this way and would be less typing, don’t you think?

So this is my next attempt to solve it with variadic templates:

My next idea was, that there must be a way to do it with variadic templates without the recursion terminating bool in(T)  method.

 

So I played around a bit with Sean’s code, after I understood what it is actually doing, this is the result (thanks to cpplearner for the improvement hint):

One disadvantage of this solution is, that the order of evaluation of the arguments is not defined.

But with Jay Miller’s comment, based on Eric Niebler’s improved version of the for_each_arg, this keeps the order of evaluation of the arguments.

Conclusion:

The last version is the most compact one, but it has the disadvantage compared to all the others, that the internal comparisons does not terminate early. So the code will compare all possible values, even a match was already found. As long as the value to be checked against the set of values cannot be evaluated during compile time, I don’t see a way to do it in a similar way like the last version. If you see one, please let me know.

Unfortunately the code does not fulfill Sean’s challenge: “Goal for Better Code: Fit each function in a tweet”. Never the less I think it is worth sharing it.

Since this is almost my very first experiment with variadic templates, all ideas for improvements or comments are welcome.

 

Note:

Please use “crayon” to enter source code in he comment. The “code” tag removes all “<” and “>”.

This code does not compile with Visual Studio 2013 update 3 in release mode, only in debug. It works fine with update 4 and VS2015 CTP and the recent Clang and GCC.

 

Sep 202013
 

During the development in TDD manner of some generic C++ code in our project I stumbled over the problem that I wanted to forbid the usage of integral, floating point and pointer types as a certain template argument. Only types with a default constructor made sense in that context. My very first attempt was to use a static_assert like:

I checked inside my file with the unit test, that the instantiation of Foo<int>() actually led to a compile time error. So fine so good. I made an #if 0 … #endif around this sample failure code and went on.

Later a colleague of mine reviewed the code and brought up the point, that a) this is not a real unit test and b) whenever someone changes the file containing the definition of Foo<> he has no knowledge about the commented code in the unit test file. He was right! But how to ensure that on one hand something does not compile and on the other hand how to guarantee that the unit test fails if the tested code gets changed in the future, e.g. during a refactoring? It seems to be a paradox. One could move this failure detection from compile time to runtime. But this would worse than the static_assert, because the advantage of early feedback to the developer would be gone. So I kept the compile time check.

Continue reading »