We had an incredible turnout for our November 2024 C++ Meetup, hosted at the Tiobe office in Eindhoven. With over 50 attendees, we hit the venue’s maximum capacity, creating a lively and dynamic atmosphere for discussions and networking! It’s truly inspiring to see how our community is growing and attracting so many passionate C++ enthusiasts.

The evening featured engaging presentations, insightful discussions, and an opportunity to connect with like-minded professionals and learners. For those who missed the meetup or want to revisit the talks, the slides are available at our GitHub repository: https://github.com/cppeindhoven/meetups.

Talks

Jan Wilmans: Default guidelines for writing C++

Jan opened an interactive discussion about what defines ‘good code’ in C++. He shared his perspective on crafting effective and maintainable code while inviting participants to contribute their insights and experiences. This session sparked thought-provoking conversations about shared principles in writing high-quality C++.

Bart van Tongeren: On the use of the C++ Core Guidelines

Bart provided an in-depth overview of the C++ Core Guidelines, a key resource for writing modern, safe, and performant C++. He highlighted their significance, practical applications, and how they can serve as a foundation for improving code quality in both personal and organizational projects.

Paul Jansen: C++ Rulesets in large organizations

Paul focused on the role of guidelines and coding rules in large-scale software projects. He shared how these standards can be established, implemented, and enforced, while addressing their organizational impact. His talk shed light on the balance between fostering innovation and maintaining consistency in large development teams.

Thank you to everyone who joined us, and a big shoutout to Tiobe for hosting the event. We’re looking forward to continuing this momentum and seeing even more of you at future meetups!

Slides will be available at https://github.com/cppeindhoven/meetups

References

• https://github.com/cppeindhoven/code-of-conduct
• https://github.com/cppeindhoven
• https://www.meetup.com/cpp_meetup_eindhoven/
• https://twitter.com/cppeindhoven

Today marked the exciting launch of our very first C++ Meetup in Eindhoven, hosted at One Of A Kind Technologies, where I work. It was fantastic to see the enthusiasm from the local C++ community. Out of the 30 people who registered, around 20 attendees joined us, which I consider a great turnout for a debut event.

The meetup featured engaging discussions, knowledge sharing, and networking among C++ enthusiasts of varying experience levels. The atmosphere was vibrant, and it was rewarding to connect with others who share a passion for modern C++ development.

For those who couldn’t make it or would like a recap, I’ve compiled detailed notes from the meeting, which you can find here. I’m looking forward to seeing this community grow and thrive in the coming time!

References

• https://github.com/cppeindhoven/code-of-conduct
• https://codingcoach.io/
• https://www.copperspice.com/
• https://github.com/cppeindhoven
• https://www.meetup.com/cpp_meetup_eindhoven/
• https://twitter.com/cppeindhoven

@ CppCon 2019 @ Aurora (near Denver) Colorado

Just returned from one wholly awesome week of CppCon. This year the conference was held at The Gaylord Rockies Convention Center in Aurora Colorado, just outside Denver. This place is huge, take a look:

I arrived on Friday to meet up with my fellow CopperSpice team members, Barbara, Ansel, Tim and Peter. We had a two day hacking session working on CopperSpice and hashed out strategies how to better organize our team. We talked about our new libraries and integrations with Azure Pipelines, further development of the CMake support and a formal funeral for our Autotools support (well, the actual wording was more like, take it into the desert and shoot it, but remember to take a picture).

Conference Opening Keynote Bjarne Stroustrup

On Monday Bjarne gave an overview of the current C++20 status, as always, it was a straightforward, well laid out presentation that I think will be very informative to anyone who has not been actively keeping up to date with the proposals in flight during the last 3 years.

Opening for the ‘Back to Basics’ track: Jason Turner, The Best Parts of C++

Jason is always energetic and entertaining to watch; this talk was no exception. The ‘Back to Basics’ track maybe specifically targeted at the newcomers to C++, but I think many of us, also the professionals that have been in C++ for years, learned something. C++ is evolving quickly and sometimes feels like a completely new language. Jason presented a good mix of time trialed good practices and fresh new insights.

Latest & Greatest in Visual Studio 2019 for C++, Marian Luparu and Sy Brand

Whether you are a fan or not, its good to see that Visual Studio keeps up with the times and brings us exciting features with every release. However in recent years we have really seen a change in Microsoft and the the killer surprise this time was the open sourcing of the STL, the standard library that comes with visual studio!!

Hello World from scratch by Peter Bindels and Sy Brand

A wild ride, energetically presented by Peter and Sy, they explained everything that happens from sourcecode, compilation, linking, loading, until the actual execution to your main() function. I enjoyed this and learned a thing or two along the way.

Copperspice CsPaint: High performance graphics and text rendering on the GPU for any C++ application

Barbara and Ansel presented the latest development that spun out of the CopperSpice development: CsPaint a portable high performance graphics library on top of Vulcan. One of the most notable features was the infinite accuracy text rendering! A unique feature that will be used to render portable and uniform high-DPI 2D UI graphics for CopperSpice on Linux, Windows and MacOS.

Sean Parent – Better Code: Relationships, Essential Relationships

Seans presentation was about the relationships in our code, about thinking ahead about what your program will look like, comparing it with a game of chess, although I feel that usually my computer is not actively trying out moves against me I enjoyed the talk and I think a good takeaway was to think about the essential relationships between types and software designs in general. I heard someone say ‘don’t use raw pointers’ was also a take-away, I think that is a little to much simplification and I would generalize that into: think/don’t forget about the null-cases in the results of your functions. Slides and more available soon on his site.

Andrei Alexandrescu – Speed Is Found In The Minds of People

Andrei is sort of a unguided projectile in this talk about sorting while optimizing for medium sized datasets.

Jason turners talk on – Code Smells

This again was a good talk by Jason, focusing specifically on the red flags that should be investigated when reviewing code.

SG14 Study Group Meeting

The Wednesday I spend in SG14, the study group for Game Development and Low Latency. Among other things the BLAS (Basic Linear Algebra Subprograms) integration proposals where reviewed.

Lightning talks

Emery Berger: compacting memory by meshing

Really interesting talk on compacting memory using meshing and virtual memory re-mapping. Emory demonstrated an 17% reduction in memory usage in a web browser. The really fun part of this being that this could be done without having the source code nor recompilation.

Matt.org compiler explorer – Ray Casting in threefold / Object Oriented, Functional, data oriented

Matt shows three different ways to implement a path-tracer / ray casting example, analyzing the plus/minuses for the different strategies. A surprising result for me was that in this case the branch prediction was dominating the implementation style.

Louis Dionne – ABI’s for dummies

Also recommended to watch on YouTube if you care about ABI stability. Very nice talk. What surprised me was the Foo() = delete; can introduce a breaking ABI change!

J.F. Bastien – Deprecation of volatile

This was a really good talk on the history and future of volatile. Recommended talk to watch when it goes online.

Tony van Eerd – Objects vs Values

I was mostly asleep during this talk this was not due to Tony’s presentation, I will have to watch the talk again when it becomes available on youtube.

Timur Doumler – C++20 the small things

Timur gave an overview of all the little fixes and smaller features that were put into C++20 at the last SG21 meeting in Cologne.

The Hallway track with Walker Brown, Sean Parent, Stephan T. Lavavej, Louis Dionne, Lisa Lippincott, Timur Doumler and so many others, sorry that I cannot mention everybody in this title

This years so-called ‘hallway track’, the conversations you have with people outside the talks were, for me personally, the highlight of the conference. I talked to so many interesting people, I was truly inspired by the enthusiasm and openness of literally everybody I approached. I felt like I was literally radiating with pleasure walking that halls of the conference. Thank you everybody!! I hope to see all of you next year!

While writing this post I noticed Matt has also done a trip report, so check that one out too! CppCon publishes the slides for all presentations at https://github.com/CppCon/CppCon2019

Performance and usability enhancements

Some of these settings are particularly well suited for virtual machines, use common sense to judge whether is it safe (enough) to turn off these features on real machines. In embedded development and hardware integration work that I do, I often find myself in situations where the network is already restricted enough by firewalls and anti-virus measures that having these options on only gets in the way.

Developer mode – Handle With Care:

• turn off UAC (see reg file below)
• turn off Windows Defender (see reg file below)
• turn off Firewall: Win-S, Firewall, Turn Windows defined firewall on or off, private -> off, public -> off

After the firewall is turned off, you will get regular reminders about it, I have not found out how to turn these off yet. I do have a DisableNotificationCenter key in the patch below, but it reportedly does not work in all cases. Alternatively you can try to go to Control Panel\System and Security\Security and Maintenance and choose Change Security and Maintenance settings and uncheck the boxes there. This also doesn’t seem to work for everybody, but maybe you’ll get lucky For now, I just dismiss the occasional message dialog, I don’t even see it anymore, I just automatically close it.

Paranoid software engineers

As a software engineer, part of my job is to be paranoid, if something changed on my system, I have to assume I have to re-test ALL my assumptions. This means that if an update is installed during my debug session I can basically start over. This is not acceptable for me, so to prevent this I turn off updates during debug sessions. Winupdate-stop is a handy tool to turn update off and on again.

Windows 10 settings and preferences

The following settings are my personal defaults:

Responsiveness improvements / low latency HMI:

• turn off UAC
• turn off Windows Defender
• lower cl.exe priority to keep machine responsive
• allow all powershell scripts
• turn of sliding, animation and transparency
• show all tray icons

Pleasing to work with:

• keep shadows under windows
• keep font optimizations

Productivity:

• show all file extensions
• write minidumps to c:\crashdumps when any program crashes
• disable phone home to microsoft when any program crashes

And here is all of it packed into one registry patch:

Further optimization

There are also manual steps you can take to improve, for example, startup time, or overall speed

• If you are not using an SSD harddisk, this is by far the best investment you can do for productivity and general speed up of your pc.
• See Settings -> Apps -> Startup and disable all programs you don’t regularly use.
• Set power options to ‘High performance’, paste ‘Control Panel\Hardware and Sound\Power Options’ into explorer and select ‘High performance’
• If you are on a laptop, connect to a wired network if you have the option. With all the phone-homing/update checking some applications do, this can really improve response/startup times of applications.
• Turn off windows-search, I don’t recommend this unless for build servers, I have experienced bad side effects/malfunctions in using Outlook and other microsoft applications. paste ‘Control Panel\System and Security\Administrative Tools\services.lnk’ into explorer, find ‘Windows Search’ and set it to ‘Disabled’

Aside from windows settings there are tools

Aside from windows settings there are tools that can make you developer life easier. Lets start with installation of tools. I regularly reinstall my whole system, every few months or so. Installing updating all tools to the latest version and manually installing them can be a hassle. Fortunately, chocolatey.org can install lots of things completely unattended.

• first run this script as admin to install choco itself 1_install_chocolatey_as_admin.bat
• now open a new administrator command prompt and run update_packages.bat

The content of packages.bat is just an example, customize it to your wishes and save it for next time.

Tooling, roughly in order of awesome

• FileLocator Lite, can replace Ctrl-f, super fast and can search for containing text and use regular expressions
• GNU for Windows, 100+ unix tools for windows, indispensable, grep, wc, find, less, tail, tar, nano, etc, etc just works.
• Putty, my gateway to linux systems, serial ports, raw sockets, name it.
• Debugview++, collect, view and filter your application logs, from http, UDP/TCP sockets, files, name it, just drag, drop and filter.
• chocolatey, so nice, I had to mention it twice
• LockHunter, a foolproof file unlocker

More tooling that are bread and butter

• ccleaner is really useful to remove lots of unused stuff, clear caches, remove broken registrations etc.
• defrag(gler) harddisks (yea its still a thing, but only on large non-ssd harddisks with lots of small-ish ~1-2 MB files.)
• Notepad++ (Settings -> Preferences -> Backup -> Remember current session -> disable)
• Free Hex Editor Neo
• Ultraedit (paid, I’ve been a user for 20 years, just the best, but admittedly, Notepad++ and FHE Neo cover most use cases)
• git need I say more ?
• TortoiseGit (need to set Settings -> Icon Overlays -> Status cache -> None, otherwise slows down my explorer)

C++ specific tools

• Very sleepy, a free C/C++ CPU profiler
• Deleaker, a resource profiler of C++, C#, .NET and DELPHI

Did I forget anything?

Some external references are in order:

• Scott Hanselman has an extensive tool list (dated 2014), many of the tools still exist and are still awesome.
• NirSoft has so many useful tools, its just ridiculous
• Rainmeter, if you want to really customize the ‘look’ of your desktop, check out this tool

Do you have a good tweak or tool that you are missing in this post? Please let me know, preferable using twitter and I will add it (if I like it too

This is the first review I’ve even written as a blog post on my nullptr.nl website. Why start now? I considered whether I wanted to associate myself with any particular software and never really felt the need. However, in this case I was asked to review Deleaker by the author Artem Razin (Softanics). For reference, see @deleaker on Twitter or the website. Artem asked me nicely and offered me a license for the product in return and I was actually curious to try a memory leak detection program.

What is deleaker?

According the website deleaker is a ‘Profiler for C++, C#, .NET AND DELPHI’. Let me be clear up front, I have only looked at it from the C++ perspective and particularly only used it as a Visual Studio plugin.

Some features:

• integrates with Visual Studio (I tried VS2019 v16.1.6, the latest release as of July 2019)
• finds different kinds of leaks: memory, GDI, handles and others
• profiles un-managed and .Net code
• supports both 32-bit and 64-bit applications
• has report and export features

Impressions

Installation was really easy, just your regular next, next, finish wizard with no special settings needed. I did experience a little more delay during the installation than I consider ‘normal’, but after waiting an extra minute or two, everything was installed correctly.

First thing I noticed was, that if you try Deleaker without activation of a license, it works fine, it tells you if and what you problem leaks. However, it does not tell you where you leaked it. However, as long as you’re using the 14 Days Trial you will get the full functionality, including source locations where you leaked resources. This means, you can try it before buying, to see what and how much it will find, but to keep using it to solve issues after the trial, you will need to pay for a license.

After entering the license, you get full source-code references and it tells you not only what you leaked, but also where you allocated it.

Debugview++ experiment

To take Deleaker for a test-spin I took a fresh clone of DebugView++, one of my own open source projects and fired it up. I’m a consistent RAII user and standard library container user, and I felt pretty confident that, without ever actually measuring it explicitly, I did not have any (serious) memory leaks in this application.

I started the program in debug mode, played around with it and closed it. And… to my surprise Deleaker found I a couple of leaks! Three GDI handle leaks! This was of course completely unacceptable and had to be disproven immediately! After investigation its turned out the GDI handles were indeed leaked and Deleaker reported correctly.

Here is the innocuous looking code:

int CMainFrame::LogFontSizeFromPointSize(int fontSize)
{
    return -MulDiv(fontSize, GetDeviceCaps(GetDC(), LOGPIXELSY), 72);
}

After reading GetDC msdn page it turns out the handle you get from GetDC() must be released using ReleaseDC(). And, I was doing this correctly in almost all cases, except here. In this commit you can see the change I made to solve the leaks. I just used the correct Raii wrapper object to guard the handle’s scope and the leak was solved.

random artificial leak experiment

To see if Deleaker would also detect ‘normal’ memory leaks, I changed one of my std::make_unique<> calls into a (cough) ‘new’ call. Re-ran the program, closed it, and bingo: Deleaker found it immediately.

Conclusion

This is hardly a thorough review of all Deleaker capabilities, but in conclusion I must say I’m impressed. The learning curve to use the tool is extremely low, the interface is clear and the detection seems to work correctly. If you’re searching for a leak detection tool, go try Deleaker, I think you will like it.

Then at some point in 2016, I found CppCast. This is a weekly podcast with news on c++ topics. Things started rolling from there, a few months later, I was a guest on cppcast myself. I learned about cppcon, a c++ conference (back then held in Bellevue) and convinced my employer to sponsor my travel, entrance fee and stay there.

Seattle, is a 10 hour flight from the Netherlands, but well worth it! I was there for 10 days, including a pre-conference course by Stephen Dewhurst. I still feel these 10 days where a turning point for me. I met so many great people, I was in awe that so many teachers were all gathered there, easy to approach and talk to. And also many people, just like me, all searching for more knowledge.

After my first conference I was hooked, I learned about how the ISO c++ committee works, I met members of SG14 (the study group focused on low latency), I met Odin Holmes there and learned about the embo.io conference. In the months after, I visited more conferences, local talks and retrospectively listened to all episodes of CppCast (well over 100 by then, going on 200 now). I also learned about other c++ resources, communities and peer groups.

Looking back, once I found ‘my way’, the community I was looking for was there all along, I just did not know where to look. Below I will list resources that I found helpful, starting with the ‘best starting points’, followed by with what I hope is a useful set of links.

Getting started

So where to start? What if you what to learn more about c++ and let’s assume for the moment, you want to nerd out for the evening. (so stay at home, not out in the world, talking to people, that will be stage 2

Good starting points:

• join twitter
• find #include C++
• join the #include discord channel

Join twitter you may ask? Isn’t that a little 2015? While it may seem that way at first, a surprising amount of software engineers and teachers are on twitter! I can really recommend it and if you encounter content you don’t appreciate, just mute some accounts to keep your tweets interesting and on topic. Starting by following @c_plus_plus and me (@janwilmans) of course To get the most out of twitter, it helps to follow several more people, just click on @c_plus_plus and see who’s following that and go from there.

The #include C++ community is very welcoming to everybody, seriously, it is their goal to be inclusive in all aspects and you will find knowledgeable people on the discord channel who can give you pointers to new resources or answer questions directly. In there own words:

IncludeCpp is a global, inclusive, and diverse community for developers interested in C++. Join our discord.

• Follow Jason Turner on YouTube https://youtube.com/c/lefticus1

• Check out his best practices on GitHub https://github.com/cpp-best-practices/cppbestpractices

• If you are looking for a course, take a look at Kate Gregory’s material on pluralsight. https://www.pluralsight.com/courses/cplusplus-fundamentals-c17

Watch talks from conferences for example: cppcon, cppnew or meeting c++ conferences

The links in this article is a rather arbitrary set, there is no particular order or purpose to them, other then to show you that the information exists. Really it is out there, search on google, search on youtube, ask around on twitter for specific topics. Below I list a few I particularly liked or found useful in my daily job.

Recommended talks

• CppCon 2015: Joshua Gerrard “The dangers of C-style casts” is a nice 5-minute talk to get started with.
• CppCon 2015: T. Winters & H. Wright “All Your Tests are Terrible…”
• ITT 2016 – Kevlin Henney – Seven Ineffective Coding Habits of Many Programmers
• CppCon 2016: Howard Hinnant – A ＜chrono＞ Tutorial (it’s about time)

C++ resources

• https://abseil.io/tips/
• http://ericniebler.com/
• Fluent C++ – Jonathan Boccara’s blog
• https://www.youtube.com/c/Cppchat
• http://cppcast.com/
• Jason Turner’s C++ Weekly

More general resources

• Kevlin Henney is a great speaker on many topics, check him out, also on youtube.

Tips on tweeting and posting on forums:

• ask questions! and when you do explain what you already did to explore the problem and why you did not get to the desired answer/result. This helps to give context and avoids answers like ‘just google it’.
• use common sense, be nice, if you see a question you can answer, why not chip in and answer it. You may sometimes get it wrong, but that is OK, you will learn from that also!

Stage 2, meanwhile in real life…

• go to a conference! (see list of conferences below) they are the most immersive way to learn a lot in a short amount of time
• if a conference seems too expensive, remember that volunteers and students often get special discounts and some even offer free access!

• if you are employed, remind your boss that its is no more expensive compared to a regular course/training and much more immersive and interactive.

  • https://channel9.msdn.com/events/CPP/ the cppcon conference produces over 100 recorded talks ever year!
  • https://www.google.nl/search?q=youtube+cppcon

Other things to do

• read the manual cppreference.com
• watch the conference video’s! there are many many hour of premium content available online, free of charge

• read books (really!), I recommend, in order:

  • A Tour of C++ by Bjarne Stroustrup >bol<
  • Effective Modern C++ by Scott Meyers >bol<
  • C++ concurrency in action by Anthony Williams >link<

• good references

  • The C++ Programming Language (4th Edition)
  • The ISO Standard document, the official specification

These last ones are not good to start with, but it an excellent reference if you want to dive into the full details.

I got feedback from some the great folks on the orange page that just reading books is not going to make you a good software engineer. Also they mentioned: “all that stuff about >Variadic templates, meta programming, memory barriers and the specifics of memory layout< do you really need to know all that? Is that not too obscure and not used on daily basis” ?

There is absolutely truth in this. First of all: practice, practice, practice. Programming is, just like so many things a skill that is really honed by doing it a lot. Still the mentioned books are great. “A Tour of C++”, make sure to get the second edition that was just released, is only 256 (yes!) pages. I encourage you to read a few chapters and as soon as you found something new, do try it! Open up your favorite editor and try it out. Also by all means skip chapters that you find difficult, or uninteresting, read through the books to get a sense of the whole and return to the more difficult to grasp parts later.

Also worth mentioning, The 7 Habits of Highly Effective People is not about c++ at all, its about self-management, but it changed my life. Of course there are many other good books, these are just the ones that I read and really stuck with me.

• join communities

  • https://stackoverflow.com/ is an excellent place for discussion and to ask questions
  • join cpplang on slack

List of conferences

• https://cppcon.org/ (student discounts)
• http://embo.io/
• http://cppnow.org/
• https://cpponsea.uk/
• https://meetingcpp.com/
• https://codedive.pl/ (free!)

Meet dutch C++ people at local groups:

• https://twitter.com/TheDutchCppGrp
• http://www.040coders.nl

Good talks on slightly more advanced topics

• CppCon 2017: Ben Deane & Jason Turner “constexpr ALL the Things!
• CppCon 2016: Ben Deane – Using Types Effectively
• CppCon 2018: Robert Ramey – Safe Numerics

Funny videos about computer complexities

Take these with a grain of salt, yes there is truth to them, but you will probably never have to solve these problems yourself.

• The Problem with Time & Timezones – Computerphile
• Internationalis(z)ing Code – Computerphile

ping-backs

• https://www.kylegalbraith.com/learn-by-doing/volume/36/how-do-you-feel-about-cplusplus.html
• https://news.ycombinator.com/item?id=18814697

Note from the author

This post got an unusual amount of attention, I would like to emphasize that it is a work in progress, I may update it as I learn more.

• it looks like it was written before const, smart pointers or RAII were a thing
• the author was a big fan of (overly) defensive programming
• either not much thought went into the overall design or over time the design was compromised by the extensions that were made later
• there is a lack of (proper) tests

Tests

refactoring without tests is just changing sh*t. – Hamlet D’Arcy

Before you start changing anything I would suggest you get proper tests in place if they are not already there. A comment I got at a presentation was: “yes, but to add tests I need to decouple stuff, add interfaces, and that is also a change, so I can’t add any tests”. Well, true, you have to start somewhere, a good set of integration tests can be a good start, test what you can, add interfaces as you go. There is always some risk of mistake, but as adding interfaces should not change any behavior, it is often a can-be-judged-good-by-inspection kind of change. Making other changes such as ‘fixing this minor thing at the same time’ should be carefully avoided.

About defensive programming

Don’t get me wrong, Defensive programming in itself can be a useful thing or even vital in some cases. The gist of defensive programming is “do not trust other software developers to do the right thing” with your code. However, in many cases ‘we’ ourselves are the ‘other software developers’ and if you can not even trust yourself to use you own code right and you do checks everywhere, then this will come at a great costs in terms of run-time and readability/maintainability. So it stands to reason that we need to strike a balance here. Also, even if we do want to do checks against incorrect usage, there are tools that can help reduce the time and lines of code spend on doing it.

Let see some examples, so we know what we’re dealing with:

// example1: check, check, double check.

#include <assert.h>
#include <iostream>

class Bar 
{
  public:
  void barMethod() { std::cout << "boo\n"; }
}; 

void foo2(Bar* bar)
{
  assert(bar != nullptr);
  bar->BarMethod();
}

void foo1(Bar* bar)
{
  if (bar == nullptr) return;
  foo2(bar);
}

void foo()
{
  Bar b;
  foo1(&b);
}

Lets look at motivation first, what goes on in this code? The author of foo1() was concerned that someone could pass nullptr and decided to check for this condition and do nothing in that case. While this prevents a crash, if passing nullptr is truly a programming error, this will effectively cloak a bug and make it hard to detect.

The author of foo2() takes a different approach and decides that passing nullptr is a precondition violation of the method and an assertion is in order. In this case an assertion will trigger in debug builds but in production nothing will prevent it from crashing. This sounds even worse, right?

In fact both methods had a pre-condition that bar can never be null but by the way it is called, we can be absolutely sure that bar is never null. However, if some future author changes things around, that might no longer be the case. So if for some reason bar does becomes null (or any other invalid value for that matter) I would want to know about it as soon as possible. Also I would like the code to express that this was indeed the intended precondition.

There are several ways to achieve this, first of all lets look at references:

#include <assert.h> 
#include <iostream>

class Bar 
{
  public:
  void barMethod() { std::cout << "boo\n"; }
}; 

void foo2(Bar& bar)
{
  bar.barMethod();
}

void foo1(Bar& bar)
{
  foo2(bar);
}

void foo()
{
  Bar bar;
  foo1(bar);
}

Here references were used to express that bar should always have a valid value. The methods foo1() and foo2() do not explicitly check this, however, if bar does become invalid, the code will likely crash. I like this style personally and use it whenever possible, I actually prefer to crash to ignoring the call or getting an assertion since this will expose the bug early, very likely in a unit test.

Looking back at the first example: If the call is ignored, the bug will be silent and likely rear its ugly head in future unpredictable ways. Both methods will only catch the case when the value is exactly null and will not catch the case where the value is for example -1, ‘0xdddddddd’, or something else.

It is useful to remember this, because it can introduce differences in behaviour between debug and release builds. Depending on your environment, in debug builds, variables can be zero’d out and memory filled with 0xcccccccc, 0xfeeefeee or 0xdddddddd depending on if it is just allocated, initialised or freed.

The assertion can in some cases hang a continuous integration system because it pops up a message dialog by default, however, as far as I know this applies to MSVC only.

You might argue, is a crash not always worse then no crash at all? I think it is not; a program continuing to run with unknown behaviour is in my opinion much worse than a crash because it is a potential later crash that will be unpredictable and much harder to debug then the initial problem. If we’re going to crash we should do it sooner so we can catch it before it reaches production.

There are also cases where references are not an option, for example in data structures where the pointer can never be null but it should be re-assignable to point to a different object. For those cases the not_null<> template from the GSL seems to work well.

#include <iostream> 
#include <gsl/pointers>

class Bar 
{
  public:
  void barMethod() { std::cout << "boo\n"; }
}; 

void foo2(gsl::not_null<Bar*> bar)
{
  bar->barMethod();
}

void foo1(gsl::not_null<Bar*> bar)
{
  foo2(bar);
}

void foo()
{
  Bar bar;
  foo1(&bar);
}

Now this is still pretty good; each method explicitly states its the caller’s responsibility to know that the pointer is valid. And if it is not, this will fail fast by crashing. Both ways achieve to at least document the precondition and allow removal of the duplicated null checks at every level.

There are a couple of problems that can arise when applying this change. When changing the method prototype to use references there will be a point where the existing pointer has to be dereferenced to assign to the reference. You have to be sure the pointer is not null before turning it into a reference, because dereferencing a nullptr is UB. In practice it will probably not crash until the reference is actually used, but this can be tricky: (warning, bad code ahead)

Here you can see that checking a reference for null can have interesting side effects. The check is completely optimized out, fortunately clang is nice enough to emit a warning when this happens.

At first glance you might expect this to be a compiler bug, however, it is not. The reasoning goes something like this:

• you cannot assign a reference with a null value (int& i = nullptr will not compile)
• dereferencing a pointer containing the value nullptr causes undefined behavior (int &i = *ip; is UB when ip is nullptr)
• so: a reference can never have the value nullptr
• this means the if-statement can never be true and so the whole if-statement can be optimized out.

Long story short: (1) make sure the pointer you dereference is not nullptr before passing it to a method taking a reference and (2) don’t do any checking on references, it does not make any sense and will have unexpected results.

1: void foo2(Bar* bar)
2: {
3:   assert(bar != nullptr);
4:   bar->BarMethod();
5: }

A side-story on the ASSERT case above, it can have interesting side effects on static code analyzers! The analysis goes like this:

• line 3, analyzer reads: you’re telling me bar could be nullptr, i’ll make a note of that (why would you otherwise check for that)
• line 4, analyzer reads: you’re calling a method on ‘bar’, let me check if that could be nullptr, err, YES, it could be! I better warn the user to do a null-check!

Actually removing the assert gets rid of this false-positive warning from the static analyzer.

Summary for this chapter about defensive programming style:

• some code may rely on the fact the method did nothing when called with a nullptr, so removing the null check and changing to a reference in that case will introduce a crash at best and UB otherwise.
• some code may need to re-assign the pointer so using references are not always an option
• for places where reference can be used a crash will occur only when the reference is actually used
• not_null can be used in both places and can be configured to crash when it is assigned a null value, which is when I want to know about it.

Conclusion: using references in places where pointers are passed that may never be null is an improvement over raw pointers, since it is documenting the precondition. But not_null<> is more explicit in expressing this intent and has the added benefit of earlier error detection.

Dealing with raw pointers that manage lifetime

So in C++ we have smartpointers right? Raw-pointers? so passé! NO. Let me be clear: raw pointers are great, always have been, likely always will be. However, owning raw pointers, those are or should be a thing of the past. An owning raw pointer looks like this:

Foo * foo = new Foo();

Do you see the special syntax used to indicate and make very clear that this raw pointer is an owning raw pointer, meaning that the method that gets this pointer is responsible for cleaning up the allocated memory? You do not see it? Makes sense, that is because there is nothing that separates this pointer from any other kind of raw pointer.

void f()
{
    Foo * foo = new Foo();
    g(foo);
    h(foo); 
}

void g(Foo* foo) {} // non-owning raw pointer
void h(Foo* foo) { delete foo; } // owning raw pointer 

A general advice often heard is:

do not create owning raw pointers

However, what to do when you (again: I) have a 15 year old code base where this happens all over the place?

class Message{};

Message* receiveMessageFromHardware()
{
    return new Message();
}

class Engine
{
public:
  void process(Message* p) { p1(p); }
  void p1(Message* p) { p2(p); }
  void p2(Message* p) { p3(p); }
  void p3(Message* p) { delete p; }
};

Godbolt this

Here, because it is a toy example, it is easy to see the Message is allocated in the receiveMessageFromHardware() method and it is deallocated in p3(). However in practice, this can be a long and interesting journey through the code to find all the places that allocate Message objects and all end-paths that (should) deallocate the Message object. Also, if the full path to p3() is not followed, due to an error condition, who will deallocate?

The first thing to do is probably just to annotate the code to make clear the raw pointers are actually owning in this case:

#include <gsl/pointers>

class Message{};

template <typename T>
using owner = gsl::owner<T>;

gsl::owner<Message*> receiveMessageFromHardware()
{
    return new Message();
}

class Engine
{
public:
  void process(owner<Message*> p) { p1(p); }
  void p1(owner<Message*> p) { p2(p); }
  void p2(owner<Message*> p) { p3(p); }
  void p3(owner<Message*> p) { delete p; }
};

This is a great improvement to do as a first step, it documents/makes explicit the fact that the raw pointers are owning raw pointers. The gsl::owner<> template is very simple:

template <class T, class = std::enable_if_t<std::is_pointer<T>::value>>
using owner = T;

That’s all she wrote… its basically a template doing exactly nothing except check that the argument passed is a pointer type. This in itself is a very useful step in the process of documenting ownership and by doing so making the code more readable. The assumption that the pointer owns the object and thus the object will either live until the end of the method or it will be passed onto another method is now explicitly encoded in the type of parameter. Note that static analyzers can know about gsl::owner<> and can now help you to find the cases where an owning raw pointer was passed but not deallocated.

The next most obvious modern c++ solution/step is in many cases introducing a std::unique_ptr<Message> and moving the ownership through the chain, like so:

#include <memory>

class Message{};

std::unique_ptr<Message> receiveMessageFromHardware()
{
    return std::make_unique<Message>();
}

class Engine
{
public:
  void process(std::unique_ptr<Message> p) { p1(std::move(p)); }
  void p1(std::unique_ptr<Message> p) { p2(std::move(p)); }
  void p2(std::unique_ptr<Message> p) { p3(std::move(p)); }
  void p3(std::unique_ptr<Message> p) { }
};

int main()
{
    Engine().process(receiveMessageFromHardware());
}

Gobolt this

Now the code has improved in multiple ways:

• it is clear about the ownership of the Message object
• the correctness in terms of deallocation of the Message object no longer depends on the error path, early return or exceptions being thrown

When written like this it does not matter if a function exits early by returning mid-processing or whether an exception occurs, the Message object will always be correctly cleaned up and you do not have to write any cleanup code to make that happen.

However, introducing std::unique_ptr<> throughout the code can be a challenge, the Message object may be passed through a lot of layers, through a queue, passed over multiple threads etc. What if you cannot or just don’t want to change everything in a single changeset?

#include <memory>

class Message{};

Message* receiveMessageFromHardware()
{
    return new Message();
}

class Engine
{
public:
void process(Message* p)
{
    p1(p);
}

void p1(Message* p) { p2(p); }
void p2(Message* p) { p3(std::unique_ptr<Message>(p)); }  // note change
void p3(std::unique_ptr<Message> p) {}                    // note change

};

int main()
{
    Engine().process(receiveMessageFromHardware());
}

In this example, we only changed the method that does the delete and its caller, but nothing else. This can be very nice, because now we can start refactoring bottom-up but we don’t have to change everything in one go. To make the example more interesting, below, I have added two possible ‘tail calls’. It does not matter whether the Message is passed into p3() or p4(), both will take ownership and properly deallocate at the end of their execution.

#include <memory>

extern bool IsConditionMet();

class Message{};

Message* receiveMessageFromHardware()
{
    return new Message();
}

class Engine
{
public:
void process(Message* p)
{
    p1(p);
}

void p1(Message* p) { p2(p); }
void p2(Message* p)
{
    if (IsConditionMet())
    {
        p3(std::unique_ptr<Message>(p));
    }
    else
    {
        p4(std::unique_ptr<Message>(p));
    }
}
void p3(std::unique_ptr<Message> p) {}
void p4(std::unique_ptr<Message> p) {}

};

int main()
{
    Engine().process(receiveMessageFromHardware());
}

The approach does not just work bottom-up, here is a top-down example:

#include <memory>

class Message{};

std::unique_ptr<Message> receiveMessageFromHardware()
{
    return std::make_unique<Message>();
}

class Engine
{
public:
  void process(std::unique_ptr<Message> p) { p1(p.release()); }  //notice release() 
  void p1(Message* p) { p2(p); }
  void p2(Message* p) { p3(p); }
  void p3(Message* p) { delete p; }
};

int main()
{
    Engine().process(receiveMessageFromHardware());
}

Here we used make_unique<> to allocate the object and in process() took the ownership from the unique_ptr and continue passing the ‘old way’ to p2(). Theoretically, just could even start on both sides at the same time and work towards the middle, but I’m not sure that would serve any purpose.

const correctness

Another thing that is useful to document is the intention a method is not supposed to change anything. In my code base this was not really done (anywhere). The problem with adding const retrospectively is that making a method const will probably mean you have to make its callers const as well and this can snowball really quick. A good way I found to start adding it is to use a static analysis tool (I used Resharper C++) to tell you what methods can be made const (leaf methods) that are not const right now. However I should mention at this pointer that adding const in an inheritance hierarchy (any virtual method) can break existing code. This is because as const is part of the function prototype, for example:

class Base
{
  virtual void bar() = 0;
};

class Foo : public Base
{
  virtual void bar() const = 0; // by adding const here, still compiles but Foo::bar no longer overrides Base::bar!
};

class Foo2 : public Base
{
  virtual void bar() const override = 0; // compiler error! bar did not override any base class methods
};

So to deal with this, when adding const to a virtual method the overrides anything, always made sure to also add the override keyword.

After you have done this, re-running the tool will get you the next level of methods to make const, if you repeat this cycle a few (5-10) times you can quickly improve the const-correctness of a project a lot. The reason why this approach is nice is because you can stop at any time and the effects do not snowball because you started by changing the leaf methods and are working your way up the call chains.

smartpointers and RAII types

Custom destructor on unique_ptr can be used to wrap resources

// ignore (windows plaform stuff)
using HANDLE = void*;
#define INVALID_HANDLE_VALUE ((HANDLE)(-1))
#define PROCESS_QUERY_INFORMATION (1)
#define FALSE (false)
extern void CloseHandle(HANDLE);
extern HANDLE OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId);
extern int GetCurrentProcessId();
// ignore (windows plaform stuff)

#include <memory>

struct HandleDeleter
{
    using pointer = HANDLE;
    void operator()(pointer p) const;
};

typedef std::unique_ptr<void, HandleDeleter> Handle;

void HandleDeleter::operator()(pointer p) const
{
    if (p != nullptr && p != INVALID_HANDLE_VALUE)
        CloseHandle(p);
}

int main()
{
    // now we can write:
    Handle handle(::OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId()));

    // instead of:
    HANDLE h = ::OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId());
    CloseHandle(h);  // may be needed in multiple branches
 }

more smaller things

I found these ‘tricks’ handy:

• create a quick/convenient way to add logging in any place
• rewrite typedef as aliases using the using syntax

Example code for a windows specific way to make adding logging in any class a one-liner:

cdbg << "some value: " << 4 << ", and another: " << 2 << "\n";

The cdbg object is a std::basic_ostream<> that writes anything it gets passed to the OutputDebugString API. By using this approach a tool like DebugView++ can be used to monitor and filter these message. If you happen to be on another platform you can just swap out OutputDebugString for std::cout or your own favorite log function. The point here is: adding an easy to use facility to quickly add some logging get really help you understand code more quickly.

GitHub link to basic_dbgstream

Example of rewriting typedef’s to make them more readable:

// write:
using HANDLE = void*;

// instead of:
typedef void* HANDLE;

// and write:

#include <type_traits>
using FunctionPtr = std::add_pointer<void()>;  // declare a pointer to a `void()` function

// instead of:
typedef void (*FunctionPointer)();     // oldschool pointer to a `void()` function

using the dropbox NN<> template

I have not written this part yet, check back for more later….check this video to wet your appetite Youtube video on NN<> Github repo for NN<>

what about smart pointers (shared_ptr and unique_ptr) and gsl::not_null

Earlier versions of the GSL did not allow you to wrap std::unique_ptr<> or std::shared_ptr<> in a not_null<> template, however, this seems to work ok now:

class Message {};
gsl::not_null<std::shared_ptr<Message>> msg = std::make_shared<Message>();

I need to try and play with this some more and will update this post after I do.

what about a boost::shared_ptr<> “infected” code base?

When smartpointers were ‘new’ and not in the standard library yet (C++/03 era), boost had an implementation already. Many early adopters realized using a smartpointer was superior to using raw pointers for ownership. However, in these early days there was no such thing as move-semantics yet. As a consequence many developers adopted boost::shared_ptr<> as it could be copied easily and life was good (or so it seemed).

The major drawback of use boost::shared_ptr<> or any shared pointer, is that there is no explicit transfer of ownership. How long an object will live will depend on the last user and while this sounds reasonable, it encourages sloppy lifetime management and very often these program suffer from shutdown problems (crashes).

I have not had to refactor such a project yet, but I expect to take a similar approach for these project as I do for projects using raw owning pointers, start by nailing down the lifetime of objects. Replace boost::shared_ptr<> parameters with references or not_null<> pointers for methods that do not participate in the lifetime management of the object.

Final words

This post is a work in progress, I will update it after I have more experience applying these techniques or discover new ones. std::string_view is up next… stay tuned….

References: Twitter feed

The idea is simple (or so it seems). Suppose you would like to distinguish variables that have the same basic type and have the compiler enforce that, this does not seem possible at first glance. For example, this will not compile:

using AxisId = int;
using ControllerId = int;

void f(AxisId id) {}
void f(ControllerId id) {} // error: function 'void f(AxisId)' already has a body

void g(AxisId id) {}
void foo()
{
   ControllerId controllerA(42);
   g(controllerA);        // very wrong, but compiles fine and without warning
}

The idea here is that axes and controllers are identified by an index, the indexes are not unique, both ranges contain 0, 1, 2 3, etc… Now function g() should only be called with an AxisId, but if you were to give it ‘1’ or a ControllerId, that would happily compile. Also as the example shows, typedef’ed basic types cannot be used to overload a method.

This case is basically now a solved problem in C++11 with the introduction of ‘enum class’, as it can do a special trick for integers:

enum class ControllerId     // regular enum class ControllerId
{
    A, B, C
};

enum class AxisId           // specifically valued Id
{
    x = 0,
    y = 1,
    z = 2
};

void f(AxisId id) {}
void f(ControllerId id) {} // Ok, ControllerId is a unique type

void g(AxisId id) {}
{
   ControllerId controllerA(42);
   g(controllerA); // error: cannot convert argument 1 from 'ControllerId' to 'AxisId' // nice, very clear message!
}   

I should mention at this point, that there is a ‘gotcha’ in C++17 but not in earlier versions, which future textbooks will now have to refer to as the well known anti-pattern called ‘Ólafur’s Fruit Salad‘:

enum class Apple;
enum class Orange;
Apple a{3};
Orange o{5};
//o = a;   // doesn't compile
Apple fruit_salad{Orange{2}}; // compiles without warning!
‏

Hopefully this will be addressed in C++20.

Try this on godbolt.org to see if your compiler is affected.

However, what about the case where there is not a known/fixed amount of members:

using Days = int;
using Weeks = int;

int getWorkingHours(Days value)
{
    return value* 8;
}

int getWorkingHours(Weeks value) // error: function 'int getWorkingHours(int)' already has a body
{
    return value* 8 * 5;
}

Here it would have been nice to overload the method ‘getWorkingHours’ with arguments of different type for ‘day’ or ‘week’. It turns out this is actually not all that hard, lets have the enum class do its thing:

#include <type_traits>
#include <iostream>

enum class Days : unsigned int {};  // notice: enum declarations without any specific values 
enum class Weeks : unsigned int {};

template <typename T>
auto value_of(const T& t) -> std::underlying_type_t < T >
{
    static_assert(std::is_enum<T>::value, "argument of value_of is not an enum or enum class");
    return static_cast<std::underlying_type_t<T>>(t);
}

int getWorkingHours(Days value)
{
    return value_of(value) * 8;
}

int getWorkingHours(Weeks value)
{
    return value_of(value) * 8 * 5;
}

void strong_integer()
{
    std::cout << "hours in 2 days: " << getWorkingHours(Days(2)) << "\n";    // outputs: 16
    std::cout << "hours in 2 weeks: " << getWorkingHours(Weeks(2)) << "\n";  // outputs: 80
}

What happens here is that by specifying the enum class without any specific values it can only be assigned by being explicit about it, which is exactly what we want. note: the standard is not specific about the underlying type you get when no values are specified, as in enum class Days; so I make a point of specifying it explicitly as unsigned int in these cases.

The ‘value_of’ template is not strictly necessary, a ‘static_cast(x)’ would also work just as well. However you would have to make sure you specify the correct underlying type, otherwise you risk a narrowing conversion without any diagnostic warnings because they would be silenced by the static_cast<>. By using the value_of template you don’t have to repeat yourself and if the underlying type would change at some point appropriate warnings would be emitted.

So, this seems to work quite well of integer values, but what about other basic types, like for example floating point numbers?

Various use cases for strong types

These are examples of applications of strong types from different fields. The use cases vary slightly but they are all in the same category of distinct basic types.

• distinct units: disallow mixing up quantities in different dimensions (distance, weight, volume, etc.)
• distinct ids: disallow mixing up the handles or ids of different kinds
• distinct memory: disallow mixing real-, virtual- memory addresses and offsets

another way to look at the application of the district types is:

• make overloading possible for different variables of the same basic type.
• make non-sensible operations compilation errors, such as dividing by an offset or subtracting an address from an offset.
• verifying data: have user-input validated and put into a verified type

This is an example of an fairly simple ‘Strong type’. Different instances of StrongType<> are not interchangeable, so you as the developer will have to be explicit about any conversion.

template <typename T, typename ID>
class StrongType
{
public:
    StrongType(const StrongType&) = default;
    StrongType(StrongType&& value)
    {
        m_value = value.m_value;
    }
    StrongType& operator=(const StrongType&) = default;
    StrongType& operator=(StrongType&& other)
    {
        if (this != &other)
        {
            m_value = other.m_value;
        }
        return *this;
    }
    explicit StrongType(const T& value) : m_value(value) {} // basic type constructor
    virtual ~StrongType() = default;

    T get() const { return m_value; }
    void set(const T& value) { m_value = value;  }

private:
    T m_value;
};

template <typename S, typename ID>
std::ostream& operator<< (std::ostream& os, const StrongType<S, ID>& value)
{
    os << value.get();
    return os;
}

struct tag_meter {};
struct tag_millimeter {};

using Meters = StrongType < double, tag_meter >;
using MilliMeters = StrongType < double, tag_millimeter >;

MilliMeters toMillimeters(Meters m)
{
    return MilliMeters(m.get() * 1000.0); // explicit construction and .get() are needed 
}

Meters toMeters(MilliMeters m)
{
    return Meters(m.get() / 1000.0);
}

void strong_double()
{
    Meters m = Meters(1.2);
    auto mm = toMillimeters(m);
    auto m2 = toMeters(mm);
    std::cout << "the length is: " << mm << "\n";
    std::cout << "the length is: " << m2 << "\n";
    //mm = m2; // no operator found which takes a right-hand operand of type 'Meters'  
    //m2 = mm; // no operator found which takes a right-hand operand of type 'MilliMeters'  
}

I have made the ‘template class StrongType’ a little more verbose by implementing the move assignment operator and move constructor explicitly so it can be used on somewhat older compilers as well. On a C++17 compliant compilers all rule-of-five constructors could be defaulted. Also the tag type struct does not have to be on separate line, it can be defined in-place like so:

using Meters = StrongType < double, struct tag_meter() >;
using MilliMeters = StrongType < double, struct tag_millimeter() >;

So this is all very nice, but we can take it one step further; we could implement assignment operators for Meters on a Millimeter class and vice versa.

namespace si
{
    class MilliMeters;

    using MetersType = StrongType < double, tag_meter > ;
    class Meters : public MetersType
    {
    public:
        Meters(double v) : MetersType(v) {}
        Meters(const MilliMeters& v);
        Meters& operator=(MilliMeters);
    };

    using MilliMetersType = StrongType < double, tag_millimeter >;
    class MilliMeters : public MilliMetersType
    {
    public:
        MilliMeters(double v) : MilliMetersType(v) {}
        MilliMeters(const Meters& v);
        MilliMeters& operator=(Meters);
    };

    Meters::Meters(const MilliMeters& v) : MetersType(v.get() / 1000.0) {}

    Meters& Meters::operator=(MilliMeters value)
    {
        set(value.get() / 1000.0);
        return *this;
    }

    MilliMeters::MilliMeters(const Meters& v) : MilliMetersType(v.get() * 1000.0) {}

    MilliMeters& MilliMeters::operator=(Meters value)
    {
        set(value.get() * 1000.0);
        return *this;
    }

    void h(MilliMeters value) {}

    void foo()
    {
        Meters m = Meters(2); 
        h(m);
    }
}

As you can see, this is becoming more and more cumbersome. It makes sense to be able to add/subtract Meters from Millimeters. But that would also make sense for types like: picometers, micrometers, centimeters, decimeters, kilometers, etc etc. And why not addition ? Division? Multiplication ? Meters squared could actually return a new type SquareMeters… The amount of operations quickly explodes and becomes very tedious to implement. Fortunately, ideas are rarely unique or new, so searching for an existing solution quickly yielded one: Boost.Units

The Boost.Units library offers many SI units and common operations out of the box. Its documentation leaves much to be desired, but watching Robert Ramey’s CPPCON 2015 talk “Boost Units Library for Correct Code” is a good introduction.

Alternatively, a good resource is Jonathan Müller’s type-safe library, for more information read this blog post.

Another also very useful application is in string verification:

    struct raw {};
    struct verified {};

    using RawData = StrongType < std::string, raw > ;
    using VerifiedData = StrongType < std::string, verified >;

    VerifiedData verify(const RawData& data) { return VerifiedData("");  }
    void process(const VerifiedData& data) {}

Here there is no way for the ‘process’ method to accept un-verified data as an input. This is a very nice compiler check to have and as Ben Deane mentioned in his talk ‘Using types effectively’ can also promote a clear separation of responsibilities. The process method does not have to do any checks because it can be sure no unverified data will come in.

To summarize: Strong types can be implemented in C++ and getting basic type safety that way is not that difficult. The downside of doing a naive implementation is that for doing arithmetic it requires lots of explicit constructions and .get() calls which is ugly, or at least, no longer looks natural. For SI units Boost.Units can offer an alternative. As a final note: the ideas in this post were distilled from the references below, the code samples above were written be me and can be used freely.

References

recently updated: (6/6/2019) https://github.com/anthonywilliams/strong_typedef

C++Now 2017: Jonathan Müller “Type-safe Programming”
Arne Mertz’ 2016 Simplify C++ article “Use Stronger Types!”
CppCon 2016: Ben Deane “Using Types Effectively”
CppCon 2015: Kyle Markley “Extreme Type Safety with Opaque Typedefs” => Link to Kyle Markley’s sources
CppCon 2015: Robert Ramey “Boost Units Library for Correct Code”
The blog at the bottom of the sea – Getting Strongly Typed Typedefs Using Phantom Types
Jonathan Müller’s blog about strong typedefs => Link to Jonathan Müller’s sources
Link to Opaque typedef proposal
WG21/N1891 = J16/05-0151 Walter E. Brown’s 2005 Opaque Typedefs proposal
N2141 = 06-0211 Alisdair Meredith Strong Typedefs in C++09 Boost BOOST_STRONG_TYPEDEF

At a readers request, I wrote this post describing a ‘Windows 10 Creators Update’ quirk/feature.

the symptom:

While testing Debugview++ on Windows Windows 10 1703 Creators Update Build 15063.413 (the latest version at the time) one of my users found that the application hangs at startup for about 20 seconds, before actually continuing the startup. After this it was working normally.

The bug was reported here. On the version before that Windows 10 version 1607 14393.1358 this problem did not occur. Now Debugview++ is kind of special in that it listens to a ‘debugger’ API, namely to receive the ‘OutputDebugString‘ messages. For those of you not familiar with this API, it is win32 facility to output debug messages (as the name suggests).

Normally debugview++ receives these messages from another process. The mechanism to deliver the message is quite primitive, it is a fixed 4096 bytes buffer and the caller of OutputDebugString can briefly be blocked if messages are not immediately read by the debug application.

Now, I’ve optimized debugview++ to read message as fast as possible and to unblock the traced application asap. I wondered what could be causing debugview++ itself to block for 20 seconds? The 20 seconds were curious in itself because the OutputDebugString API has a 10-second timeout, so it looked awfully like two message-timeouts; could I have made a mistake and was I accidentally using the OutputDebugString myself within debugview++ ? Of course that would be problematic, as that could potentially cause an infinite recursion problem.

After some investigation this turned out, debugview++ itself was not sending any messages, at least not from its code, but the win32 libraries (specifically oleaut32.dll) that where loaded implicitly, can now call into this OutputdebugString API.

So the problem was introduced because in Windows 10 1703 the Win32 API itself started using OutputDebugString internally. Below is a stackdump from the process while it was hanging (created using taskmanager’s ‘Create dump file’ feature).

After I found out why it was happening, I was also able to do a small redesign of the flow for incoming messages so it does not matter anymore where the messages come from.

The obscure we see eventually. The completely obvious, it seems, takes longer. – Edward R. Murrow.

    ntdll.dll!_NtWaitForSingleObject@12�()  Unknown
    KERNELBASE.dll!WaitForSingleObjectEx()  Unknown
    KERNELBASE.dll!OutputDebugStringA() Unknown
>   KERNELBASE.dll!OutputDebugStringW() Unknown
    oleaut32.dll!wil::details::LogFailure(void *,unsigned int,char const *,char const *,char const *,void *,enum wil::FailureType,long,unsigned short const *,bool,unsigned short *,unsigned int,char *,unsigned int,struct wil::FailureInfo *) Unknown
    oleaut32.dll!wil::details::ReportFailure(void *,unsigned int,char const *,char const *,char const *,void *,enum wil::FailureType,long,unsigned short const *,enum wil::details::ReportFailureOptions)   Unknown
    oleaut32.dll!wil::details::ReportFailure_Hr(void *,unsigned int,char const *,char const *,char const *,void *,enum wil::FailureType,long)   Unknown
    oleaut32.dll!wil::details::in1diag3::Return_Hr_NoOriginate(void *,unsigned int,char const *,long)   Unknown
    oleaut32.dll!GetTypeInfoOfIIDFwd(struct _GUID const &,struct ITypeInfo * *,int) Unknown
    oleaut32.dll!CProxyWrapper::Connect(struct IRpcChannelBuffer *) Unknown
    combase.dll!CStdMarshal::ConnectProxyToChannel(tagIPIDEntry * pEntry, OXIDEntry * pOXIDEntry, const _GUID & ipid) Line 3206 C++
    [Inline Frame] combase.dll!CStdMarshal::ConnectCliIPIDEntry(tagSTDOBJREF *) Line 3055   C++
    combase.dll!CStdMarshal::MakeCliIPIDEntry(const _GUID & riid, tagSTDOBJREF * pStd, OXIDEntry * pOXIDEntry, tagIPIDEntry * * ppEntry) Line 2812  C++
    combase.dll!CStdMarshal::UnmarshalIPID(const _GUID & riid, tagSTDOBJREF * pStd, OXIDEntry * pOXIDEntry, void * * ppv) Line 2340 C++
    combase.dll!CStdMarshal::UnmarshalObjRef(tagOBJREF & objref, void * * ppv) Line 2208    C++
    combase.dll!UnmarshalSwitch(void * pv) Line 1843    C++
    combase.dll!UnmarshalObjRef(tagOBJREF & objref, EffectiveUnmarshalingPolicy policy, void * * ppv, int fBypassActLock, CStdMarshal * * ppStdMarshal) Line 1985   C++
    combase.dll!_CoUnmarshalInterface(IStream * pStm, bool bForceStrongPolicy, const _GUID & riid, void * * ppv) Line 1730  C++
    combase.dll!CoUnmarshalInterface(IStream * pStm, const _GUID & riid, void * * ppv) Line 1773    C++
    combase.dll!ActivationPropertiesOut::OutSerializer::UnmarshalAtIndex(unsigned long index, bool bIsWinRTOutofproc) Line 3139 C++
    combase.dll!ActivationPropertiesOut::GetObjectInterfaces(unsigned long cIfs, unsigned long actvflags, tagMULTI_QI * pMultiQi) Line 2746 C++
    combase.dll!ICoCreateInstanceEx(const _GUID & OriginalClsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, unsigned long dwActvFlags, tagMULTI_QI * pResults, ActivationPropertiesIn * pActIn) Line 1971    C++
    combase.dll!CComActivator::DoCreateInstance(const _GUID & Clsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, tagMULTI_QI * pResults, ActivationPropertiesIn * pActIn) Line 384    C++
    [Inline Frame] combase.dll!CoCreateInstanceEx(const _GUID &) Line 176   C++
    combase.dll!CoCreateInstance(const _GUID & rclsid, IUnknown * pUnkOuter, unsigned long dwContext, const _GUID & riid, void * * ppv) Line 120    C++
    uiautomationcore.dll!BlockingCoreDispatcher::CreateAndRegisterBlockingCore(void)    Unknown
    uiautomationcore.dll!BlockingCoreDispatcher::FinalConstruct(void)   Unknown
    uiautomationcore.dll!ATL::CComCreator<class ATL::CComObject<class CUIAutomation8> >::CreateInstance(void *,struct _GUID const &,void * *)   Unknown
    uiautomationcore.dll!ATL::CComCreator2<class ATL::CComCreator<class ATL::CComObject<class CUIAutomation8> >,class ATL::CComFailCreator<-2147221232> >::CreateInstance(void *,struct _GUID const &,void * *) Unknown
    uiautomationcore.dll!ATL::CComClassFactory::CreateInstance(struct IUnknown *,struct _GUID const &,void * *) Unknown
    combase.dll!CServerContextActivator::CreateInstance(IUnknown * pUnkOuter, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties) Line 872 C++
    combase.dll!ActivationPropertiesIn::DelegateCreateInstance(IUnknown * pUnkOuter, IActivationPropertiesOut * * ppActPropsOut) Line 1931  C++
    combase.dll!CApartmentActivator::CreateInstance(IUnknown * pUnkOuter, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties) Line 2163    C++
    combase.dll!CProcessActivator::CCICallback(unsigned long dwContext, IUnknown * pUnkOuter, ActivationPropertiesIn * pActIn, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties) Line 1631   C++
    combase.dll!CProcessActivator::AttemptActivation(ActivationPropertiesIn * pActIn, IUnknown * pUnkOuter, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties, HRESULT(__stdcallCProcessActivator::*)(unsigned long, IUnknown *, ActivationPropertiesIn *, IActivationPropertiesIn *, IActivationPropertiesOut * *) pfnCtxActCallback, unsigned long dwContext) Line 1518 C++
    combase.dll!CProcessActivator::ActivateByContext(ActivationPropertiesIn * pActIn, IUnknown * pUnkOuter, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties, HRESULT(__stdcallCProcessActivator::*)(unsigned long, IUnknown *, ActivationPropertiesIn *, IActivationPropertiesIn *, IActivationPropertiesOut * *) pfnCtxActCallback) Line 1384  C++
    combase.dll!CProcessActivator::CreateInstance(IUnknown * pUnkOuter, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties) Line 1262  C++
    combase.dll!ActivationPropertiesIn::DelegateCreateInstance(IUnknown * pUnkOuter, IActivationPropertiesOut * * ppActPropsOut) Line 1931  C++
    combase.dll!CClientContextActivator::CreateInstance(IUnknown * pUnkOuter, IActivationPropertiesIn * pInActProperties, IActivationPropertiesOut * * ppOutActProperties) Line 561 C++
    combase.dll!ActivationPropertiesIn::DelegateCreateInstance(IUnknown * pUnkOuter, IActivationPropertiesOut * * ppActPropsOut) Line 1983  C++
    combase.dll!ICoCreateInstanceEx(const _GUID & OriginalClsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, unsigned long dwActvFlags, tagMULTI_QI * pResults, ActivationPropertiesIn * pActIn) Line 1915    C++
    combase.dll!CComActivator::DoCreateInstance(const _GUID & Clsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, tagMULTI_QI * pResults, ActivationPropertiesIn * pActIn) Line 384    C++
    [Inline Frame] combase.dll!CoCreateInstanceEx(const _GUID &) Line 176   C++
    combase.dll!CoCreateInstance(const _GUID & rclsid, IUnknown * pUnkOuter, unsigned long dwContext, const _GUID & riid, void * * ppv) Line 120    C++
    tiptsf.dll!CImmersiveFocusTracker::_HandleAutomationEvent(unsigned long,struct HWND__ *,long)   Unknown
    tiptsf.dll!CImmersiveFocusTracker::HandleAutomationEvent(unsigned long,struct HWND__ *,long)    Unknown
    tiptsf.dll!TabletMsgWndProc(int,unsigned int,long)  Unknown
    user32.dll!_DispatchHookW@16�() Unknown
    user32.dll!_CallHookWithSEH@16�()   Unknown
    user32.dll!___fnHkINLPMSG@4�()  Unknown
    ntdll.dll!_KiUserCallbackDispatcher@12�()   Unknown
    DebugView++.exe!WTL::CCommandBarCtrlImpl<WTL::CCommandBarCtrl,WTL::CCommandBarCtrlBase,ATL::CWinTraits<1442840576,0> >::MessageHookProc(int nCode, unsigned int wParam, long lParam) Line 2747  C++
    user32.dll!_DispatchHookW@16�() Unknown
    user32.dll!_CallHookWithSEH@16�()   Unknown
    user32.dll!___fnHkINLPMSG@4�()  Unknown
    ntdll.dll!_KiUserCallbackDispatcher@12�()   Unknown
    DebugView++.exe!WTL::CMessageLoop::Run() Line 1292  C++
    [Inline Frame] DebugView++.exe!fusion::debugviewpp::MessageLoop::Run() Line 61  C++
    DebugView++.exe!fusion::debugviewpp::Main(HINSTANCE__ * cmdShow, HINSTANCE__ *) Line 156    C++
    DebugView++.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpstrCmdLine, int nCmdShow) Line 165   C++
    [Inline Frame] DebugView++.exe!invoke_main() Line 118   C++
    DebugView++.exe!__scrt_common_main_seh() Line 283   C++
    kernel32.dll!75848744() Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]  
    ntdll.dll!__RtlUserThreadStart()    Unknown
    ntdll.dll!__RtlUserThreadStart@8�() Unknown

References:

https://blogs.msdn.microsoft.com/reiley/2011/07/29/a-debugging-approach-to-outputdebugstring/

I have added and/or rephrased some passages based personal experience.

One function that does everything

Many think that they should only create functions if they are reused. No. Create functions for anything that can be thought of as a generic action. Or create functions to document steps of a process. This greatly helps in readability and structure.

Early exits

int foo() 
{ 
  if (x) 
  { 
    // lots of code ... 
     return y; 
  }
  return 0; 
}

Reverse that statement. Now the reader has a lot to go through to make sure the “bad” exit case is ok, this takes up mental space and makes reasoning about you code more difficult. If it’s reversed, everything below the if does not matter for the x == false case.

int foo() 
{ 
  if (!x) return 0;
  // lots of code ... 
  return y; 
}

This also reduces the amount of brackets and indentation levels.

Avoid magic numbers

if (something > 5) ...

What is this 5? Give it a name and put it somewhere, this number has context, show it. Put it in the scope that makes sense, it does not have to be in a big scope or reused, in the function itself is also good.

const int maximumTemperature = 5;
if (something > maximumTemperature ) ...

Notice that your brain is now probably suddenly trying to make sense of the function and questions arise like:

• should this be a floating pointer number
• are these in Celsius of Fahrenheit

These are good questions and that kind of question may be answered by the name of the variable sometimes. This also leads into the question: should that not be part of the type of the variable so trying to assign degrees of Celsius to degrees Fahrenheit would be a compiler error. This can be accomplished by using the boost units library. There is an excellent talk on this subject by Robert Ramey from CPPCON2015.

One class for everything

Similar to one function for everything. If you can categorize the actions within the class, then you can make classes out of those categories. It is really quite a burden to maintain 6000 line classes. For example, if you have a 10-step process, than maybe create a class, give it the name of the process and create 10 functions to express the steps.

Inconsistent formatting style

Reading through code is a strain mentally, not only do you have to parse what each line is doing, you need to parse the structure. If it’s inconsistent it makes it harder to parse. What style doesn’t matter, just make it the same everywhere. Tools can be a big help here. An example is clangformat, it can format your code or just a selection of it to make it conform to an agreed style by the team.

Comments everywhere

// Increment value by one 
i++;

My issue with comments is that now you have 2 meanings for everything. The line has a meaning and the comment. And they must match, or else there is trouble. Add a comment when something needs explaining, when reading the code by itself would not make sense. But you can almost always just make a function that describes that action, no comments needed then. The compiler does not read comments (obviously) so if the comment describe some precondition the must hold, just check the precondition or use static_assert is possible.

Performing complex actions in if statements

if (myFoo->Action(aBar + aBaz->GetStuff(18)))

The only time you should be placing direct actions in if statements is if you want to block the execution with an && (so-called short circuit evaluation). Otherwise put that into a variable and then ask the question.

Stringly typed

if (a == "foo") {...} else if(a == "bar") {...}

Unless you are doing actual string data parsing, you should be using classes, enums or at least numbers for determining what is what. Strings are slower to evaluate and offer no type-safety.