Feb 142014
 

I have published my very first project on GitHub: Allocator Builder

From the summary:

A highly composable, policy based C++ allocator based on ideas from Andrei Alexandrescu, presented at the C++ and Beyond 2013 seminar.

The background behind the idea is to compensate the main problem of ::malloc() and the other standard allocators, the separation of memory pointer and the allocated size. This makes it very difficult for all kind of allocators to handle in a fast way memory allocations and deallocations.

 

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 »

Dec 202011
 

The deepest impact on my side was studying the following books during the last year: Continuous Integration by Paul M. Duvall, Steve Matyas and Andrew Glover and Continuous Delivery by Jez Humble and David Farley. These books and presentations during the OOP 2011 in Munique pushed me into the direction that I am trying to describe below.

Before I go into details how we use Cucumber, I want to describe a little bit our environment: In our company we are developing a medical application that can run as a standalone application or in a client / server setup. Each configuration consists for the user of three UI processes and about fifteen background processes or services. The data persistence is realized with a PostgreSQL database, which is handled through one of the service processes. It is a radiological reviewing workstation that is highly optimized on high volume throughput. The image data for each patient can easily be about 2.5 GB and the technical challenge is to display any of next possible radiological images, which can have easily 26-50MB each in less than a second, because our customers are used to diagnose about 60-120 cases per hour. Depending of the current workflow step, the user has to work with a different UI process.

The application has about 2,000,000 lines of C++ code, currently about 10.000 single requirements and most of the functional tests are manual paper based or steered by our test management system SpiraTest. So it is obvious that we have plenty of work to do. Beside the fact that we have way too much requirements or be more precise that the granularity of the requirements is too fine, certain parts of the code are hardly testable in an automated way. Our transition from the V-model to SCRUM two years ago brought up dramatically the fact that test automation is one important step for us to stay productive and ensure quality.

Continue reading »