Sep 212013
 

During the last weeks I spend some time in optimizing a C++ string class that we use in our application. You may ask, why one should spend time today in writing ones own string class. There are already so many available for C++ like std::string and QString.

Many years ago we decided to implement because of different reasons our own string class in C++. One reason was that we have to handle very often UIDs in our domain – medical applications. They have a maximum length of 64 chars.  The Visual Studio’s STL implementation is highly optimized for strings with a max length of 16 bytes. So we decided that our class should have a chunk of 128 bytes to avoid unnecessary additional heap allocations.

Continue reading »

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 »