Strong types and C. Possible and Even Better than C++.

You are a software developer.  You are first-time reading two header files of two phone book components. Your task is to select and use one.



Which one is better and why?

I vote B. I can see shredded glass on the path A. This image is not strange. It is a shredded glass on particular path you have chosen.

ucrt problems
the path of a developer who has made a mistake

Run-time “Access violation”

Yet another real life use case  in favour of simple strong types.

Recently I was given an “honourable” task to find and remedy a “mystery” bug in a pretty complex multi threading system. Core is written in C.

In software development we all know: “mystery” is one sure way to “misery”.

Run-time “Access violation” coming from previously working parts. In particular freeing pointers to corrupted stack.And not always.

It was one of those: “But it was working before?!” kind of a mysteries. And to cut the long story short. here was this function:

It is used from a lot of threads upon starting each of them. It is part of the tried and tested common library. It is passed as initial thread data, and it is threads responsibility to free it upon specific usage.

So. A lot of developers calling one simple function from a lot of locations, sprinkled arround their complex code.

What could possibly go wrong?

Some of the callers have mixed the arguments order.

But which callers? In where? We are talking many components, many developers and several projects.

That mistake was easy to make. Both arguments are of the same type. Compiler can not spot logical mistakes.

Enter Strong Types

So instead of spending a lot of coordinated effort and time, I have re-declared this one function like so.

Infinitely better vs previous declaration.

Recompile everything  and lo-and-behold, the several “culprits” have been found.  As soon as arguments have been re-declared as strong types, they realized they have made a mistake in the order of arguments.

Now the code  required to call make_name has suddenly made it very obvious which argument is which.

In any case it is very obvious which value is used as which argument. Maintenance of the software code is often forgoten as critical and potentially very costly activity. Anyone diving  into the code above, even years after the release, will be immeditalely clear, calling the make_name is all ok.

That “strong types as literals” code  is better than C++. Please compare.

You have not seen this code before. You need to debug it. In the C++ call above, are you always going to be sure which argument is Id and which one is Origin?


Before I left, the team has decided they like the approach and  they have improved the declaration of the “offending function” :

They have added yet another strong type, to this function signature: Name. As the return value type. After that, they have compared the performance of this version  with the previous version with no strong types.

The difference in favor of no strong types was negligible. They have paid the cost, learned the lesson, and decided to stay with the “strong types” variant.

Option C

Ah and by the way. Option B is better than option A. But the best option I vote for is:




Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.