Feb 042016
 

I just read Jens Wellers article regarding raw loops vs. STL algorithms.

At the end he states “When I work with Qt, there are some cases, when you only get the count and a method to access item n, like in a QListWidget:” with the example:

And that is the point where I want bring in the possibility to use Qt widget container like objects in range based for loops or in STL algorithms. The only thing that one needs for this, is a small proxy that provides the begin(), end() interface:

So how to use it in the example from above?

For better readability and perhaps later reuse at other places let’s define this type:

And now the example becomes:

The template might be simplified in regard of the interface. But Visual Studio 2013, the compiler I have to use currently, lags certain C++11 features.

What do you think? So feedback is welcome.

 

 

Mar 262015
 

I just finished the first draft of the implementation of my enum_extend library. It is available via github.

It offers

  • Ranges over all defined enumerated values
  • Filtered ranges over a subset of enumerated values
  • ++ and — pre- and postfix operators
  • Attaching a textual representation to each enumerated value

Some examples:

Only this specialization and the implementation of the operators is necessary:

There exists a set of macros that simplifies the process of specializing the extender and implementing the operators.

Much more details and examples can be found in this first tutorial

Feedback is welcome!

 

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.

 

Oct 212014
 

I am happy to announce that I published a C++ library that offers a lightweight version of a Design by Contract functionality. You can find it under http://github.com/FelixPetriconi/contract_light.

Here is a simple example for the beginning. More to come later

 

Oct 032014
 


James O. Coplien started a discussion in May 2014 about the value of UnitTests and why most of them are waste. In August he added the 2nd installment.

In this context I hear often the argument that the majority of tests should be UnitTests over all others. Mike Cohn suggests this as well with the layout of his Testing Pyramid, because UnitTests can be executed faster. Robert C. Martin (Uncle Bob) is a strong advocate of this too – see one of his recent blog entries. Later on I will come back to his blog post and his statement that a UnitTest framework must not slow down the developers’ pace. But first to the “argument” that UnitTests can be executed faster than the others:

When I talk in the following text only about End-To-End (E2E) tests, then as a pars pro toto for all kind of tests that check not just a single unit, but complex business logic or complete features.

So shall we write UnitTests “only” because they are executed faster than E2E tests? This sounds to me like some kind of a workaround. Because we cannot get easily execute broader applied tests fast, we test something that we can test faster? Exaggeratory, isn’t it somehow similar to the old joke below?

SearchKeyUnderLight

Continue reading »