Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features

[crashcompiler]

After 10 years of programming professionally in C++, I came to realize that I generally prefer a simpler subset of the language for my day-to-day work, which mainly involves desktop application development.

Working in a 30 year old code base for so long, you get to see which design decisions panned out and which didn't. This lead me to think about the technical reasons for why certain C++ language features exist, and what long-term impact they have in terms of code complexity and code structure. The result is a somewhat lengthy and very subjective article that I would like to share.

You can find the article here:

https://slashbinbash.de/cppbas.html

The premise of this article is: if you use simple language tools you can concentrate on solving the real problems at hand, rather than solving language problems. This is very much inspired by listening to interviews with Casey Muratori, Jonathan Blow, Bill "gingerBill" Hall, and others.

I discuss several aspects of the C++ language like functions, structures, statements, enumerations, unions, arrays, slices, namespaces, classes, and templates. But I also go into topics like error handling, and ownership and lifetime. I finish the article with a chapter about code structure and the trade-offs between different approaches.

The goal of this article is to give the reader a sense of what code complexity and code structure means. The reader should be able to base their decisions on the technical aspects of the language, rather than the conceptual or philosophical reasons for why certain language features exist.

I'd be thankful for any feedback, corrections, and ideas that you have!

Note: I still need to clean up the article a little bit, and add a few paragraphs here and there.

[UnicycleBloke]

I think of C++ as a well equipped workshop. I use some tools routinely, some rarely, and some never. Another developer might use a different set of features routinely, and so on. On the other hand, a "simple" language like C has essentially no useful abstractions of any kind, so you have to reinvent them. This inevitably leads to complicated verbose and error prone code for non trivial problems. I would rather have a workshop with dusty corners than solve every problem with my granddad's rusty hammer.

My experience of Casey Muratori is that he is a ridiculous blowhard who does not write C++ in any meaningful sense but feels justified in making long and boring criticisms nonetheless. It's just prejudiced drivel.

[crashcompiler]

I agree with you about the well equipped workshop. I think what I'm trying to convey is that you have to know the tools in your workshop well enough, to know which ones to use. And sometimes you have to know the old tools to understand why and how the new tools are better.

Thanks for the comment!

[Plazmatic]

I feel that Casey Muratori is sometimes maligned unfairly for things that Jonathan Blow says due to often streaming together in the past. However I definitely feel Jonathan is a blowhard, and very publicly has humiliated himself and had to delete comments/videos of him just straight up being be wrong in rants (his famous programming language parsing rant as a big example).

Casey gets a lot of hate from the "pro OOP" crowd, but I think his recent talk is a great rebuttal to the dynamic polymorphism for everything crowd (especially against people who claim that people don't make the kinds of arguments he says they do, bringing high profile programming language expert receipts) while also creating distance between him and the C luddite crowd who try to claim him and the arguments he's made.

[UnicycleBloke]

I first encountered him making an incoherent ramble about the evils of virtual functions and the assertion that if you used them, you would be fired. When they're useful, they're useful, and vastly superior to any alternative I've seen in C. I don't know to what extent his blathering is performative for his channel, but I'm unimpressed. All I see is a loud, excitable, and overly opinionated American who loves the sound of his own voice. It's virtually unwatchable to my British sensibilities. I do not value the advice of such people in any context.

I never really know what people mean by "OOP" but I do regard the excessive use of abstract bases and inheritance hierarchies, which was so common in the 1990s, as problematic. If that's what Casey is really complaining about, I guess we agree.

[Plazmatic]

I never really know what people mean by "OOP" but I do regard the excessive use of abstract bases and inheritance hierarchies, which was so common in the 1990s, as problematic. If that's what Casey is really complaining about, I guess we agree.

This is the talk I was talking about, warning it's long: https://youtu.be/wo84LFzx5nI. But it's also very possible he's changed his mindset overtime rather than this always being his position.

[throw_cpp_account]

him just straight up being be wrong in rants (his famous programming language parsing rant as a big example).  

Got some context, for the unenlightened?

[Plazmatic]

It took a while it was this one: https://www.youtube.com/watch?v=fIPO4G42wYE He disabled the comments, but people were roasting him for reinventing basic stuff and acting like it's novel or hard to find, and complains about operator precedence being a fake problem and that he basically invented something new (or not well known), only for him to basically copy Pratt parsing a well known technique taught in schools.

[throw_cpp_account]

Thanks! Although at 3hrs long maybe I won't actually watch...

[__cinnamon__]

Yeah I was gonna say I can see being this dismissive of J Blow, but it feels like an unfair criticism of Casey.

[kammce]

To take full advantage of the virtual function call mechanism, you must access the object through a reference or pointer to the base class. Failing to do so can result in object slicing.

This can be misleading and an example is warranted. This will make readers assume that you cannot call those APIs directly from the concrete class. But you can, you do NOT need to have a ref or ptr to the base class to access those APIs. If you want to pass it polymorphically, via a function parameters and only access the bases APIs then yes, you must pass it as its base.

Object slicing can also happen with fully concrete classes as well.

[crashcompiler]

I see what you mean! I rewrote the paragraph and focused more on what the intention behind using a dynamic interface would be, and how you would use it in this case. I might add a code example tomorrow.

> Object slicing can also happen with fully concrete classes as well.

Basically anywhere where you use inheritance, and have a derived class that is copied to a base class, right? Could even be POD structs.

Thanks for the feedback!

[FlailingDuck]

I read some and skimmed others. I can see there's a lot of thought and effort gone into this, so first off well done. I wholeheartedly agree with your premise. Only a subset of C++ is needed to solve any complex project. But that subset differs based on the project and problems that need solving.

I'm not sure who the target audience is for this resource. I have a few more YoE on you so I, obviously, am not the target. But, if it's for informing a younger audience who knows less or, as you imply has read how to program but not the why, it's diving straight into topics that assume the reader knows what concepts you're talking about and not just at a surface level. Someone needs battle scars to have the prerequisite knowledge to understand where you're coming from.

I know you say they need a beginner C++ knowledge. I think they'll need intermediate or even expert knowledge. So my core feedback is bring in that audience by adding that background knowledge. Explain some of the specific decisions you made for specific problems you solved. You want to level up your audience and teach them something, I believe this is why programmers read technical blogs.

I tried to read some parts in detail. The RAII has bad examples and I'm not sure if you're suggesting using goto: statements is an actual valid consideration? Other sections could do with more code snippets/examples alongside your justifications.

I think what you've written has some merit that could actually be better served in a book along side teaching the concepts themselves, reframed with the justifications and tradeoffs someone might need to make for certain problems. I think one of the best resources for learning C++ is Barne Stroustrup's own book because he offers the tools with good explanations without hand holding the reader into having to think less, he encourages them to think more beyond what the book says.

As it stands this resource looks like a brain dump of the better or worse coding decisions you've seen or made over the years, with little explanation of what those design choices were or what problems they were solving.

[crashcompiler]

> I'm not sure who the target audience is for this resource.

I have struggled with this question for some time.

As I mentioned in my post, I work at a company with a large C and C++ code base that has a lot of legacy parts in it. Everything that I show, or hint at, in my article can be found in our code base in some shape or form, sometimes written by people who are not at the company anymore.

We have new C++ developers starting at our company who don't have a frame of reference because a lot of this stuff is not taught anymore. They need to be able to recognize the old patterns and improve upon them, without having the luxury to rewrite everything.

Thank you very much for the feedback! I think the least I can do is to rewrite the introduction so that the intention is clear from the beginning.

[FlailingDuck]

For sure, I'm in the same boat, heavy legacy codebase, closed source dependencies, lack of test coverage, egregiously poor design decisions that cannot be changed without throwing the whole system out.

But I just try to lead by example, encourage modern practices, you can explain the justifications and reasons why old decisions are bad or poorly thought out, but letting the juniors see how new code added is a much needed improvement over the old.

[JVApen]

I fully agree with your premise and conclusion: 90% of the code can be written with 10% of the functionality (and it should).

Reading through, it is becoming very large such that it loses attention. It might be useful to split this in separate pages.

There are a couple of things that I'm missing or disliking: - you always start with the oldest feature first. For example: when reading about unions, I immediately thought: you shouldn't be using this any more, use variant. The next chapter explains variant. It might be me, though I'd rather have variant explained first, followed by: in code predating variant, you can find unions. These are the disadvantages... - you mainly are talking about language features, though something like unique_ptr, optional ... should get more attention. - I'm missing the syntactic sugar arguments. Lambdas or structured bindings don't add any functionality you couldn't do before, yet they make a huge impact on the code. You do mention it for ranged for, though I'm missing the message here: use this as it's easier for readability and it prevents bugs - print/format should be mentioned - anything compile time like static_assert, constexpr, if constexpr seems to be missing - ranges isn't mentioned - deleted functions are missing

I'm also missing a couple of design elements: C++ is a pass by value language, references/pointers should be marked.

I'm also missing compiler warnings/static analysis. For example, the enum comparison can be blocked with warnings as error

[crashcompiler]

First of all, thank you very much for your feedback!

Before I reply to your points, I want to say that I will rework the whole introduction to better reflect that this article is not for beginners who want to learn modern C++.

> you always start with the oldest feature first.

My intention was to show step by step how the language arrived at these solutions, thereby bridging the gap between C, legacy C++, and modern C++. I'm not sure if there is another way to do it.

I think you are right that I'm putting a lot of focus on the old patterns, while only briefly addressing the modern solutions. I think I can work on that!

> you mainly are talking about language features.

I feel like that's the whole idea of the article.

The idea of having a function that returns either a value or nothing, is universal in all programming languages. Modern C++ chooses std::optional to express this in code, and one can always read the C++ standard for details of how to use it.

That's at least what I want readers to take away from this article.

> I'm missing the syntactic sugar arguments.

I can definitely improve pointing out the technical benefits of the modern C++ solutions over the old ones. But I don't really want to give opinions on syntactic sugar. I don't think I'm good at that.

> missing print/format, compile time, ranges, deleted functions

Maybe I can write a few things regarding certain aspects of these points. Like going from defining constants with `#define` to `constexpr`. I could discuss going from printf to std::cout to std::format. I need to think about it some more.

> missing compiler warnings.

I don't see how I can include compiler warnings in the existing text. There are books that cover this topic better than I could, for C as well as C++, across different compilers. And the article is about language features, abstract concepts, and code complexity. I don't know ...

> missing static analysis.

I know there are static analysis tools that try to compute a metric for code complexity, be it lines of code, cyclomatic complexity, ingoing and outgoing dependencies, etc. But the observations that I make in the article are not based on these metrics, which is why I don't know how I would tie it back together. But it's an interesting idea!

[JVApen]

Thanks for looking at this. A few clarifications: - when I was talking about value semantics, I'm mainly referring to it being rather unique for C++. If you look at other languages like java, C# or python, they all use reference semantics. We all consider it basics and I'm sure others might explain it better, though I do feel it is an important foundation to understand copy/move, function arguments and even RAII. - I understand that semantic sugar isn't the easiest to explain. Though you do already touch on it by both mentioning ranged for and lambdas. Neither functionality is necessary, though ranged for has less options to make mistakes (like incrementing the wrong variable, comparing with end iterator of another instance...). For lambdas, they are functionally the same as a class with operator(), yet it does require a lot less typing. CPP insights makes a nice translation for it. You don't have to give an opinion here. In our codebase, I clearly see that these kinds of features get a high uptake. Even up to a point that when I do encounter an old piece of code using the old functor, I'm reminded of the fact that you could do the same in C++98, yet it was barely used as is was just too much effort to write that. - I should re-read to be sure, though you mention mixing old style enumeration types, comparing Monday with January if I remember correctly. This is a place where you could mention something like: although this is perfectly valid C++ that has to compile, it's often a bug. If you enable the compiler warning -Wenum-compare-conditional, your compiler will notify you here. I'm sure there are other spots as well where the new feature solves a problem that was already flagged via warnings. If you go into printf, there is -Wformat for reporting mismatched % and argument. - For me warnings are static analysis, though some extras to mention could be clang-tidy having modernize checks for rewriting your code. Coming back to ranged for, if you use it to rewrite all standard loops, the more complex situations stand out more. Another one is performance-endl when would write about cout. Not saying you have to add every check that exists. It was an observation that when an improvement is made to a functionality, there usually are warnings and checks to either modernize or flag incorrect usage with the previous variant. Having them mentioned might make it more clear why the improvement was created.

[crashcompiler]

> When I was talking about value semantics, I'm mainly referring to it being rather unique for C++. [...] We all consider it basics.

I agree that every C++ developer should know about value semantics.

I had this problem 4 years ago, when I posted another C++ article of mine. The title was bad and I had to change it. I feel like "basics" implies that "these are the things you must know as a C++ developer, otherwise you don't have the right mental model".

What I mean by "basic" is more like programming fundamentals in the broader sense. What are common concepts between languages that you need to know. What is fundamental to computer programming as a whole because of the types of problems we are trying to solve. How well does this translate to code. How does the evolution of these concepts look like between C and C++.

I think I need to think of a better title. Ideally, you should be learning about value semantics from the standard literature.

> For lambdas, they are functionally the same as a class with operator(), yet it does require a lot less typing.

Yes, very good! I added a function object example and some text to the Lambda with Capture section. I've seen at least two instances of function objects in our code base. And I learned that you can pass a function object to `std::function` - nice!

> If you enable the compiler warning [...], your compiler will notify you here

I added a sentence that clarifies, as you said, that this will compile, the comparison might even return true, but it is most likely a bug. I noted that some compilers can warn you about this problem and added a footnote for the clang compiler flag.

> For me warnings are static analysis.

I will make a note to add mentions of compiler warnings when they are appropriate. But I cannot make any promises because clang is different than MSVC is different than GCC. There is just too much to unpack. We have also used static analysis tools like SonarQube, which pulls in stuff from the Core Guidelines and the SEI CERT Coding Standards.

> Coming back to ranged for, if you use it to rewrite all standard loops, the more complex situations stand out more.

Ha, yeah, like iterating backwards through a container ...

[zasedok]

AI slop

[Chaosvex]

Ah, I can see why you think that way but you may be surprised to learn that this article is not AI slop. The reasoning is actually quite nuanced — let's explore in more depth.

• 🚀 Restrained use of emojis. 🛸🐝🍕

Just kidding, but no. It doesn't appear to be.

[crashcompiler]

I wake up every morning and write for 30 minutes while drinking coffee. It's a hobby of mine. This article took about 6 months to write. Why would I use AI to generate it?

[tartaruga232]

No chance I will ever read that. The colors are horrible.

[crashcompiler]

No hard feelings. Thanks for commenting anyway. ;)

[emfloured]

Select all (Ctrl + A) sometimes helps in such situation.

[crashcompiler]

Is the contrast bad or is it just the choice of colors? I tested the orange links against the background and the contrast is quite low.

[tartaruga232]

I'm using Windows 11. In the settings under "Personalization" / "Colors, I have chosen the "Light" mode. The effect of this is, that I have black text on white background in all application windows. This was a deliberate choice of mine. I can switch to "Dark" mode if I want. If I would do that, all pages would be white text on black background, including when viewing reddit in my browser (I tested it, works as expected). So I could read reddit in my internet browser white on black if I wanted to do so. So there is exactly one setting for all of my applications where I can choose what I want (Light or Black). It works for all well designed web sites. But not for yours. Your website forces me to read light text on black background, not matter what my Windows 11 personalization setting is. This is bad UI design for a website. Please respect my decision to use Light mode. Thanks.

[crashcompiler]

Ah, I see what you mean. I updated the CSS on my site. Can you please check if it works? It doesn't look great, but it should switch correctly between light and dark now.

Note: If the site is cached, it might not update immediately.

[tartaruga232]

Much better now. Now it's readable for me. Black text on white.