Some C++ Programming Guidelines

Pokitto Programming C++ language
1

I just came across some really useful C++ programming guidelines compiled with input from prominent C++ experts like Bjarne Stroustrup and Herb Sutter.

You can read the HTML formatted version, which is slightly nicer to navigate but may not be up to date:

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

Or you can read the markdown version, which is always up to date:

I haven’t read everything, but of what I have read these guidelines contain some of my favourite bits of advice about C++ programming, such as:

(In places the guidelines refer to the GSL (Microsoft Guideline Support Library), but the guidelines are still mostly meaningful without worrying about those parts.)

4 Likes
2

@drummyfish, they’ve got two guidelines on when to use struct and when to use class that you might be interested in:

3 Likes
3

Thanks for sharing it! I’ll start reading it bits per bits :slight_smile:

1 Like
4

I recommend skipping the introduction and going straight to the ‘Philosophy’ section.

The Expects and Ensures mentioned in the ‘Interface’ section appear to be GSL extensions,
but there will be an [[expects]] and [[ensures]] in C++20 so even some of the GSL-specific bits are generally applicable.

Also if you aren’t planning to read it in chronological order,
I recommend look at the ones I highlighted in my first post because I think they’re really important.

1 Like
5

I’m going to read it all haha

1 Like
6

I like how clearly it’s written. Going to read through it, especially the performance part. Thanks for sharing!

1 Like
7

Unfortunately many of the points in ‘Performance’ are lacking examples at the moment, but I’ve read examples in other documents that show most of these rules are true.

My favourite parts of 'Performance’ares probably points 4 and 5:
“Don’t assume that complicated code is necessarily faster than simple code”
and
“Don’t assume that low-level code is necessarily faster than high-level code”
I like them because I see so many people make those assumptions without taking the time to understand why those assumptions aren’t necessarily correct.

(Also #10 “Rely on the static type system” and #11 “Move computation from run time to compile time” are good bits of advice.)

2 Likes
8

True, I’ve seen people create complicated code that was supposed to be optimized that was eventually slower because of unpredictable memory access which killed the cache. (Recently I’ve been informed there is no cache on Pokitto MCU though!)

I’m interested in Per.17: Declare the most used member of a time-critical struct first now, which is sadly lacking details.

In my raycasting engine I recently started moving a lot of computation to compile time, it helps a lot!

1 Like
9

There is indeed no cache on the Pokitto’s MCU, not the Arduboy’s MCU.
In fact I think anything small enough to be classed as an ‘MCU’ rather than a ‘CPU’ would probably be without a cache.

There’s more to it than just the cache though.

For example, C++-style std::sort is considered to be generally faster than C-style qsort (reference here and here), thanks to the way templates allow for code to be optimised on a per-type basis,
and if a function object (or lambda) is used in place of a function pointer then the sort function can be inlined and a level of indirection can be elided - something not possible with qsort.

Fortunately I can answer this one.

Members of any class (or struct) are accessed by taking the this pointer (the pointer that points to the first address of the class in memory, possibly word aligned) and offsetting it by a given amount.
Hence more frequently accessed members should be given a smaller offset, and the most frequently accessed member should be at the top, because that requires no offset, just an indirection.

I’ve actually seen this in action when helping @Botisaurus optimise his Arduwars.
By moving the large arrays to later in the structures and the more frequently accessed members towards the start, the progmem usage dropped.

I think it’s possible for a struct to be split across a series of registers if it’s small enough, but it might not be.
There might be language rules that forbid that.

2 Likes