C++20 Making Progress On Modules, Memory Model Updates

[carewolf]

It's funny how each of these iterations ('11, '14, '17 etc) were supposed to finally make the language approachable and usable but they only end up making an even bigger more complicated mess. Can't wait to see what kind of messes '20 will introduce.

You don't have to use the new features if you don't want to, they are optional and entirely free, and all the features are designed to make code simpler. Though I agree the transition as someone working on frameworks that has to work with both old, new and intermediate versions, that doing all of it at once is rather messy, but that is why doing generic frameworks is not for everybody. End programmers should just stick to a standard and coding style, and the newer it is, the nicer the code will be.

[Michael_S]

cl333r - Go is not interpreted, it does AoT compilation just like C++. It just has a built in garbage collector - maybe that's what confused you?

You said you did ten years of java development. When? And what were you using it for? Yes, it starts slower than C++ and it uses a few hundred MB of RAM at startup. If you're running a server application for hours at a time, that doesn't matter. If you're writing CLI tools, or applications for a Raspberry Pi, it does matter.

Go is not JITted. Java is also working on adding AoT compilation (through GraalVM, I think). Even in its current form, Java usually starts in server mode and does most of the JITting upfront.

GraalVM does AoT compilation of Java, but if you run the resulting program for more than a few minutes it turns out to be slower than regular Java code run on the JVM and subject to the regular JVM JIT engine code. The JVM JIT process profiles code and undoes and redoes optimizations on the fly based on detected behavior. Or at least, that's what I've read from people that have been comparing them.

So if you need relatively small self-contained binaries, less memory overhead at startup (but not necessarily less memory overhead if you run the application for a few minutes), or startup just 2-3ms slower than C++ for something like a fast-launching desktop application or a CLI tool, then GraalVM is the way to go. The binaries, at least on my machine, start at 7MB and go up in size from there. But again, you can run them on any x86_64 Linux machine and it doesn't use any existing JVM. The AoT compilation process is also very slow.

If you care more about total throughput and can live with the 80 ms JVM startup overhead on my five year old desktop (less on newer, faster hardware) and the slower performance for the first few seconds while the JIT starts, then regular Java is the way to go.

[bug77]

Michael_S Yeah, I said it's _working on_ adding AoT, I know it's not there just yet. I don't think it even works on enough architectures just yet, but I could be wrong about that, I don't monitor it closely.

If I want to squeeze a little more performance, Go would be my go to solution (see what I did there?). Cross-compiling Go is as simple as can be. But like you pointed out, the go to solution can vary based on specifics of you need done.

[Michael_S]

Michael_S Yeah, I said it's _working on_ adding AoT, I know it's not there just yet. I don't think it even works on enough architectures just yet, but I could be wrong about that, I don't monitor it closely.

Well, when you say "it's not there just yet" - I mean, it works today. I've been playing with it for fun. The performance may not be good enough yet, but the feature is fully implemented.

If I want to squeeze a little more performance, Go would be my go to solution (see what I did there?). Cross-compiling Go is as simple as can be. But like you pointed out, the go to solution can vary based on specifics of you need done.

Go is on my to-learn list. When the language launched, I thought, "No inheritance? Composition only? Are they insane?" But since then I've decided it was brilliant. I think the problem with inheritance is that it pushes you to spaghetti code. I've seen this same pattern quite seriously hundreds of times:

I need to add a slightly modified version of a feature to our product without changing the existing feature. If I rewrite the existing feature to use composition, we have to do thorough testing of the existing feature to make sure I didn't break anything. That testing is on top of the testing of my new feature. If I just subclass the existing feature code in key places and override the behavior I want, existing behavior is guaranteed not to change. Then we only need to test my new feature. Less work!

And that approach is working as designed in tiny, tightly-constrained cases. But for a lot of large Java applications I've looked through, at jobs and for open source projects, there are three or four levels of inheritance all over from this design, and you have to look up and down two or three (or four or five) inheritance hierarchies to track what is happening. It becomes a hideous mess, difficult to understand, difficult to debug, difficult to refactor.

So the Go language designers saved us from ourselves, really.

Now, you might be thinking, "I'm too smart to ever make that design mistake, so the Go designers just hurt my ability to get useful things done!" But that's only true if you work alone on projects you control completely. On a shared project, Go still protects you from the rest of your team.

[bug77]

Well, when you say "it's not there just yet" - I mean, it works today. I've been playing with it for fun. The performance may not be good enough yet, but the feature is fully implemented.

You said it yourself performance still has some way to go. And last I checked it didn't support ARM (not sure which version that was). That's why I think it's still incubating.

Go is on my to-learn list. When the language launched, I thought, "No inheritance? Composition only? Are they insane?" But since then I've decided it was brilliant. I think the problem with inheritance is that it pushes you to spaghetti code. I've seen this same pattern quite seriously hundreds of times:

I need to add a slightly modified version of a feature to our product without changing the existing feature. If I rewrite the existing feature to use composition, we have to do thorough testing of the existing feature to make sure I didn't break anything. That testing is on top of the testing of my new feature. If I just subclass the existing feature code in key places and override the behavior I want, existing behavior is guaranteed not to change. Then we only need to test my new feature. Less work!

And that approach is working as designed in tiny, tightly-constrained cases. But for a lot of large Java applications I've looked through, at jobs and for open source projects, there are three or four levels of inheritance all over from this design, and you have to look up and down two or three (or four or five) inheritance hierarchies to track what is happening. It becomes a hideous mess, difficult to understand, difficult to debug, difficult to refactor.

So the Go language designers saved us from ourselves, really.

Now, you might be thinking, "I'm too smart to ever make that design mistake, so the Go designers just hurt my ability to get useful things done!" But that's only true if you work alone on projects you control completely. On a shared project, Go still protects you from the rest of your team.

Pretty much the same reaction I had after I learned Go. Well, after I learned how it works, to this day I'm still no expert.

[kpedersen]

C compatibility has nothing to do with C++'s popularity. If you think ridding C++ of its C compatibility would make it just like Java/C#/Python

What I was more trying to explain is that without C, then C++ in its current form would not really be C++ full stop.

As Stroustrup suggested in the design of C++, a close compatibility with C is a must.

then you don't understand C++ at all.

Haha, as a C++ developer, I can safely say that I don't understand C++. If you understand C++, then you don't really understand C++ at all XD

Just the default, value and zero initialization rules alone trip me up. There was a great post from John Carmack (who I imagine is quite an experienced C and C++ developer by now) that suggested that he had to reset his counter on days without undefined initialization bugs back to zero.
We need more safety and less complexity. Which is why I personally find C++ 20 quite a big disappointment personally.

[paulpach]

I personally don't quite agree with the hate for header files, though I would love to see a slight change in how they're used. The separation between definition and declaration is one of the things that - to me - really makes C/C++ nice to use, as I don't have to trawl through implementation code - or use a tags system / object browser, just to learn what an application or library allows me to do.

The main problem is that it is not "separation", it is "duplication". You manually have to manually write every method signature twice, it is a DRY fail. As other languages demonstrate, the definition part can be simply generated instead (for example javadoc).

But don't worry, header files are not going anywhere, even though modules do support that use case, it is not recommended.

[bpetty]

I would natively compile C# and call it a day. C++ is basically trying to add all of the things that C# has but without looking like they are copying. Might as well go straight to the source.

[Kushan]

Good luck writing cross-platform code without preprocessor. What's the replacement for #if 0ing a block of code? Please don't say /* */.

-e- P.S. Replacing simple text processing with something vastly more complicated, with inferior functionality is brain dead.

The preprocessor isn't the issue, the issue is that it's utterly abused. It's simple, but often used for complicated gubbins that nobody understands and is incredibly brittle because the preprocessor is not in line with the goals and ideals of C++ itself (i.e. it's not type safe).

Other languages do it better - they still have your #if statements but that's it, that's all you need to give yourself flexibility and configuration. For everything else, use constexpr.

[carewolf]

I would natively compile C# and call it a day. C++ is basically trying to add all of the things that C# has but without looking like they are copying. Might as well go straight to the source.

Then you should be using Java, since C# is copying from Java. But no C++ is not taking anything from C#, only the superficial syntax is similar, but the langauges have very different design philosophies, and new C++ versions are only competing with older versions of itself, nothing else comes close.