“Modern” C++ Lamentations
aras-p.info
aras-p.info
That said, I completely switched over to rust many months ago and rarely look back. Rust is a tribute to C++, an incorporation of lessons learned that sheds all of the baggage C++ will never be rid of. Rust also has less of learning curve than C++ (although both are quite high), simply because C++ has so many odds and ends to keep track of these days.
Rust has also made me realize how bad class based OO is as an abstraction. OO glues together operator overloading, methods, inheritance, all into one package. Rust breaks those concepts into component parts that provide much better abstractions with less keywords and jargon to worry about.
That's not to say I don't allow for trade-offs.. I gladly trade some milliseconds (or, grudgingly seconds) for features.
Sure, incremental linkers exist [1], but all of them tend to do O(n) work on every invocation. Source control software, even developed explicitly to scale [2], behaves the same way. Makefiles as well; Tup [3] tries to solve this, in vain since the linking step is still holding everything up. There is so much inherent inability to scale built into our tools. So on big projects everything grinds to a halt as you cannot buy enough developers and hardware to keep up with O(n^2) forever.
[1] MSVC cl, GNU gold
[2] git: http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html
[3] tup: http://gittup.org/tup/manual.html
This works really well in practice for us. We use GCC to compile.
I see it as being like walking into an armoury and being able to choose anything you want. Chances are, if you want to resolve a domestic dispute, you don't want a claymore. Or a Howitzer. Or an aircraft carrier, or a lump of unshielded semi-critical plutonium. But that's OK, you don't have to choose them. You can walk right past those shelves to the shelf with the megaphone and the padded vest, and just take those.
That's how you program with C++.
Is this an Ammu-Nation ad? :)
It reduces mental overhead.
The first code block in the article made my jaw drop, and my first thought was "what the hell has happened to C++? I was only away for 5 years". Then I saw the "simple style" example and breathed a sigh of relief. That is the C/C++ I recognize. Even the third example with structs is not necessary. The author is right. Sometimes reusability is overrated. Duplication is better than the wrong abstraction.
It's a useful answer to the point: Well what if it was 15 for loops with a bunch of esoteric function calls. The struct example would still be better.
What a nightmare.
I spent more time figuring out the idiosyncrasies of cgo than actually writing useful code. And in many cases, cgo couldn't actually do what I needed to do. I had to write some functions and see inside of the .go file.
I'm sure rust would have been easier to call C with since the languages bare inherently more compatible, but I don't want to go down that path again right now.
I recommend Rust or D for your next try since compiler quality is best for those. D will be easiest to learn. You can always use unsafe in either if memory management gets in way.
Last I heard D was definitely not all of those (it doesn't even have a straight story on garbage collection, as its creator said himself! [1]), and I'm not sure about Rust or Nim.
[1] https://www.quora.com/Which-language-has-the-brightest-futur...
But yeah, if that matters to you, it’s less mature. We’ll get there!
To clarify, I didn't necessarily mean that D is not reliable, just that it doesn't have the combination of stable+reliable+supported that C++ enjoys.
D and Nim are a bit more iffy since they have built in GC. It can be turned off, but at that point you lose a major selling point over C++, memory safety.
Hard to beat C++ and Qt in this case, IMO.
I've worked on an image processing project in C for a while and am now doing one in rust and would never want to go back. The code is much cleaner and easy to maintain. The zero-cost abstractions really pay off, and the safety guarantees means you don't spend so much of your time chasing heisenbugs from subtle threading and locking issues.
I use Rust as my main language, but as far as I have seen gtk-rs is the only somewhat mature binding for an existing UI toolkit. This is not coincidental, since Gtk+ is a C (with objects) toolkit, it is much easier to bind than toolkits in other languages. Unfortunately, outside Linux, Gtk+ also looks pretty out of place.
AFAIK, there isn't any binding for e.g. Qt or Cocoa that has wide API coverage and is mature. Definitely not for production-level work. I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc.
> I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc.
This is the worst case and is not that bad. It does force you to write in two languages but on the other hand it enforces a cleaner UI vs backend split and that's not a bad habit to have.
In a production ready manner?
There are tools to help you out, like c2nim, but in my experience the output it produces requires fixing to get it working, and of course when the upstream library changes or adds to its API those sorts of things have to be taken into account as well.
It's not a given for Rust, and especially not a given for D or Nim (since they don't have any large companies behind them).
To borrow an old bit of snark: I don't know what the "default" programming language of 2025 will look like, but I know it will be called C++.
Like Ethernet (the original subject of that snark), C++ has evolved into a form unrecognizable to those who saw its birth. Unlike Ethernet, the older forms haven't gone away. They still reappear often in large/old/important codebases, keeping compiler writers busy and everyone else less productive. I'm generally the last person to suggest replacing things that already work, but C++ really does just need to get paved over.
This kind of language advertising where one can't even bother mentioning one negative thing about the product is sad but effective, because people want to believe that there's a perfect language out there...
That doesn't even come close to being relevant. Address the argument, not the person.
C++ has issues and problems because it's too old and it's not going to get rid of the old baggage, hence it will have to carry it forward while adding new stuff on top (concepts, ranges...). Those issues are not going away, they will only get worse over time.
Rust has different kinds of issues and problems because it's still relatively young. For instance, pretty bad compile times (even compared to C++ with heavy templates use). But that's solvable, it will just take time. Most issues with the language itself that I've personally encountered were of the kind "it's not stabilized yet" or "it's not fully implemented yet".
> Compile time of this really simple example takes 2.85 seconds longer than the “simple C++” version.
> Lest you think that “under 3 seconds” is a short time – it’s absolutely not. In 3 seconds, a modern CPU can do a gajillion operations. For example, the time it takes for clang to compile a full actual database engine (SQLite) in Debug build, with all 220 thousand lines of code, is 0.9 seconds on my machine. In which world is it okay to compile a trivial 5-line example three times slower than a full database engine?!
Today I'm trying to port some big old Embarcadero (Borland) C++ projects to their new clang-compiler but the compile times are so terrible that I'm not sure this will be usable at all (and these projects are mostly C++98).
I've also played a lot with Borland C++ Builder and the compile times for C++ (pre-C++98) are comparable (that is, practically instant).
At least, that's how I've usually understood it. And the example you mention seems like a complaint with C++20's Ranges in particular. I guess I'd fall into the, "but can't you just ignore the parts you don't like?" camp.
This post is written in the context of game engines, but I see a lot of the same 'OG C' arguments made when people in embedded development resist giving C++ a try.
We're all writing resource-constrained applications that work on tight time budgets, and none of us feel comfortable throwing up our hands and 'trusting the compiler' in that sort of atmosphere. But C isn't getting any younger, and it's hard to do polymorphism without getting hack-y.
Now, who's turn is it to advocate Rust?
Rust is definitely further along the scale towards the end of "giving more to the compiler so it takes longer". I usually like the trade. Most of the time.
While I do appreciate build speed improvements, saying that it's better than it was isn't a super high bar in terms of user experience.
I love Rust, I really do, but it's still incredibly slow. I'm excited for any progress it makes on this front.
I feel that in modern C++ modern style ”trust the compiler” often means ”leave the programmer out of the loop”
I really, really would hate to have to try to debug the ranges example, for example.
The issue is that many libraries (including std/stl) tend to produce long compile times.
> In many ways the '++' in 'C++' comes from giving the compiler more information to work with.
This is definitely not the origin of the '++'. I believe the '++' name was literally a play about "one better than C."
use std::time::SystemTime;
fn main() -> Result<(), Box<dyn std::error::Error>> {
let t0 = SystemTime::now();
let triples = (1..).flat_map(|z|
(1..=z).flat_map(move |x|
(x..=z).filter_map(move |y|
if x * x + y * y == z * z {
Some((x, y, z))
} else {
None
}
)
)
);
for triple in triples.take(100) {
println!("{:?}", triple);
}
let elapsed = t0.elapsed()?;
println!(
"{}",
elapsed.as_secs() as f64 + elapsed.subsec_nanos() as f64 * 1e-9
);
Ok(())
}
In debug mode, it runs in 0.047586s, in release mode, 0.002304.
I was pleasantly surprised to see this is actually better on the build times and debug build performance, given that those are two often cited sore points in Rust.
I would also say that while this is a little bit noisy, it is more readable than the proposed C++20 version. "1.." looks more like a range starting at 1 than "iota(1)" does. There's an actual "if" statement in there.
In fact, while Rust doesn't officially have generator/coroutine support yet, it is available in nightly builds for the implementation of async/await. If you use the nightly compiler, enable the unstable features, and wrap an adapter type around Generator that implements Iterator, you can write:
let triples = IterGen(||
for z in 1.. {
for x in 1..=z {
for y in x..=z {
if x*x + y*y == z*z {
yield (x, y, z)
}
}
}
}
);
Rust doesn't have generators yet, so this is only really fair to compare to the generator/co_yield example in C++ (which is also proposed but not yet standardized). I'd say Rust's syntax compares favorably to that example; the ranges are more clear than the traditional C-style "for" loops, there's native tuple syntax, and it's just be "yield" instead of "co_yield".
While on C++ I can take advantage of incremental compilation and linking, while using binary libraries for all dependencies, with cargo I have always to build the whole world from scratch minus standard library.
It still doesn't do incremental linking, and cargo still builds everything from scratch without any support for binary libraries.
Additionally, it is not like every C++ library is full of meta-programming templates.
Finally, there are other languages with library "metadata" and generic data types, which can easily beat Rust compile times like Delphi, Eiffel and Ada.
And are you sure GCC's Ada has better compile times? My sense is that so few people use Ada at scale that we don't really know.
Well, as explained in the article, those 5 lines generate hundred thousands of lines of code behind the scene.
And you don't use C++ for fun, you use it because you have a serious performance problem. And in that case you'll wait the compile times, because there is no alternative.
Let's not even go into link time code generation or profile guided optimizations, which increase compilation times by another order of magnitude.
That's part of the problem; most of the time, the "thousands of lines of code" that are created from type-generic code have a lot of useless duplication, and the compiler has trouble coalescing the duplicated and redundant code (I don't even think a serious attempt is made, AIUI). There's a lot of scope for improvement.
Yyou are probably using many of those and would not enjoy them being slower.
I keep coming back to a talk by Daniel J. Bernstein, that the assumptions computer science teaches about performance are wrong. His claim is for real programs most code is ice cold and a tiny percentage is hot. And that's getting worse not better as time goes on.
What important is; correctness, latency, compile time. Not raw speed.
As Wirth languages fanboy, I belive that if Java 1.0 had AOT compilation from day one, instead of leaving it to commercial third parties, and proper value types, the amount of C and C++'s adoption would have looked much different.
"Modern languages like Java and C# may well be superior to old ones like Fortran, PL/I, and C, but they are far from perfect, and they could be much better. Their manuals of several hundred pages are an unmistakable symptom of their inadequacy. Engineers in industry, however, are rarely free from constraints. They supposedly they must be compatible with the rest of the world, and to deviate from established standards might be fatal."
https://www.inf.ethz.ch/personal/wirth/Miscellaneous/IEEE-An...
"In 1995 Sun Microsystems presented its language Java , fully 6 years after Oberon. It incorporated much of the "philosophy" of Oberon, but, alas, chose the style and syntax of C. Around 2000 Microsoft released its language C# as a strong competitor of Java, and Google followed in 2007 with its language Go, even more strongly following (the 18 years old) Oberon. The crux with these languages, which all became wide-spread due to strong industrial support, is their size and complexity. The ambition to provide everything to everybody prevailed and let them grow into complex bodies difficult to master."
https://www.inf.ethz.ch/personal/wirth/Miscellaneous/Compute...
Oberon-2, Concurrent Pascal, Active Oberon and Zonnon variants were designed by students or together with ETHZ fellow researchers.
Oberon is smaller than Modula-2, and Oberon-07 lost features on each language revision.
So from our point of view Go isn't complex.
From my point of view Go still lacks several features, which Go 2.0 will kind of address.
However, from Wirth's point of view, which after being retired was still trying to design such minimal language, Go is indeed complex.
You can see this by reading the language reports.
And "modern" compile times... increasing the time between results and further thinking and writing. Don't forget that; the article doesn't.
And "modern" debugging... well, good luck.
It is all a matter of focus and pratice.
Writing a composition score for an orchestra falls under similar conditions, how each instrument sounds, how they sound together, when each comes and goes into play, and so forth.
Most complaints about C++'s complexity can be equally applied to languages that look deceivably simple like Python.
Complexity is like thermodynamics, it gets pushed somewhere, if it isn't on the code, it gets shoved either into boilerplate, or architecture.
Sure, Python makes it easy to listen on a socket, parse HTTP, and send HTML down -- hiding a lot of complexity. But it's made it impossible to do so very efficiently and scale up. Try and dive into Python's stack for that (Re: 'hold in your brain all the "modern" features'), and you'll get lost in a myriad of CPython (or whatever flavor you choose) generics and indirection that you can't optimize. Startup times matter, because you are all about hiding complexities and went "serverless" and constantly eat cold starts (Re: '"modern" compile times').
I think it's apt to compare "modern" C++ as moving towards something like Python. Not great for a lot of applications of C++ (Re: games, in the article and my focus) or its perceived goals as a better C. That's the point. Many of the C++ additions are being slagged for making a worse C. It's looking nothing like C any longer. It's a giant ball of complexity with dozens of ways of doing the same thing and hoping you learned them all.
This is why I think languages like Rust (or even Go) get a lot of attention. They have a good interop story with C, like C++ has. And if we're going to learn a bunch of non-C looking language grammar, C++ is doing a worse job.
The language + standard library + C API references are around 2392 pages, not counting the other minor documentation like the 500 PEPs, release notes and differences across each Python release, even minor ones.
Then there is the whole set of meta-classes, decorators, mixins, generators, operator overloading, multiple inheritance, abstract classes, fp like programming and much more.
The big difference to C++, is that the community doesn't care about performance, leaving the PyPy guys a Quixotic battle regarding adoption, which isn't the case with C++ compilers.
Even C isn't as simple as many think, with its 200+ documentated cases of UB, and the days that C mapped 1:1 to PDP 11 Assembly are long gone.
How C code looks like, and what gets generated via auto-vectorization, GPGPU code, SIMD intrisics are very much two worlds appart.
As for Python performance, on the contrary, I think there was a large portion of the Python community that did care during my years with it. I think 3.x adoption was hurt a lot by being slower than 2.7.x. I think a lot of the community jumped ship to Golang or similar, for both performance and complexity reasons.
I would absolutely love for C++ to tackle C UB or make incompatible insecure C. Instead, we get stuff like Ranges, time and again. I'm struggling to understand what complexities you are finding it covers that are worth supporting forever, committing gray matter, committing productivity loss, committing debug travesties, &c. Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?
Because C++ is the sane alternative to C on OS SDKs, HPC, GPGPU programming, regarding portable code.
Now, ideally as memory safe systems advocate, I would like to see more of Swift, .NET Native, D, Go, Rust, Java (AOT), OCaml, ...
However, when using languages not endorsed by vendors, it always means inferior IDE/debugging experience, lacking IDE support, manually writting FFI integration code, tracking down which layer is responsible for certain bugs,..., so switching to something that looks easier turns out to become harder in the long run as the whole stack experience suffers.
There are already signs of OS vendors finally improving a bit the situation, with Apple continuously pushing for Swift, Google restricting what is at all possible to do with NDK, Windows teams focusing on .NET Native in spite of C++/WinRT (nee C++/CX), Rust adoption by all big names.
However we are still at least a decade away of any of those languages enjoying a similar industry position in platform SDKs as C++ enjoys nowadays, after 30 years fighting against C.
So I rather keep that baggage in memory, while doing my best to use modern C++, alongside the other more type safe languages, also part of the respective platform SDKs, than additing additional attrition to my production code toolbox.
I imagine my opinion is not unique.
Compilation takes 0.064 seconds, produces 8480 byte executable
I am experienced with Asm so I can come up with an instinctive order-of-magnitude estimate, but even those who aren't should try to roughly estimate how many machine instructions are required to implement that code, and come to the conclusion that over 8000 bytes for three nested loops with not much in them, a comparison, some arithmetic, and a handful of library function calls seems rather excessive. Even 800 would be on the high side --- somewhere around 100-200 bytes is my estimate.
Also, watch this 4k demo (everything you see and hear is generated in realtime by a 4096-byte executable):
I wouldn't call it fluff: even assuming no debugging info (which you won't have in your avr object file) it has info needed at runtime (program start time) such as where to load what into memory, how much initial uninitialised memory to allocate when starting up, etc. It all gets used.
If I dig into the .text segment of the optimized executable, only 235 bytes belong to the main function (others are stuff like __libc_csu_init and register_tm_clones). Looking at the assembly the loop would be about 123 bytes.
So lots of overhead, but I wouldn't say it is in the nested loop.
otool tells me the assembly routine is 74 instructions (279 bytes, if I’m counting correctly)
You have to be careful, a lot of those 8000 bytes might well be printf().
If it was a statically linked executable, it would be far bigger than 8K.
Haskell, Rust, Scala etc. also have a lot of trouble with compile times. I wonder why, though - is it just a matter of priorities being placed on things other than optimizing the compiler, or is there some actual, inherent complexity in compiling these "modern" languages that doesn't apply to C or Go? (I suspect mostly the former, FWIW).
In C++, when compiling:
for (; *it; ++it) { }
It’s a complex set of issues that we’re constantly working on.
(So yes, Go and C do not have generics, and so do not have this problem.)
Would it make sense to have two types of generic implementation with a boxing unboxing mechanism. AKA a fast one that requires a rebuild when you monkey with something. And a slow one that doesn't but compiles fast.
I think it'd be acceptable if the 'dev' version used GC as long as the final build didn't. Basically anyway to get the development cycle to go fast.
fn<T: MyTrait> compile_time(thing: &T) {}
fn run_time(thing: &dyn MyTrait) {}
It would be possible to find cases where compile time polymorphism is replaced with runtime polymorphism, but I'm not sure it would really gain much given the restrictions.
Now if you start changing the language semantics a lot more becomes possible, but I don't even know what changes you would have to make to the language to let that happen.
1. Maybe monomorphisation overduplicates code, so that different invocations produce the same machine code in the end?
2. If that's not happening, maybe idiomatic Rust code causes a lot of code to be generated where a C programmer would have written something differently, e.g. using a void* instead of passing by value?
3. If that's not happening either, maybe monomorphisation is more or less producing what a C programmer would have monomorphised manually, but it takes the compiler a long time to optimise away abstractions?
It seems that in this C++ example the problem is #3: it takes a long time to optimise away the range & lambda abstraction.
If so, is Rust worse than C++ when it comes to compile times of those? Heavily templated C++ code is known to be slow to compile due to this. Is it much worse in Rust? Are you aware whether C++ compilers do some special optimizations that Rust compiler doesn't have yet?
I don't see what can be done to make this better, the whole point of templates is to "pay" at compile time for some gains at runtime. (or in this case for gains in the amount of code a developer has to write)
There’s at least one thing that could be done, in Rust at least. But it’s only in some limited circumstances. See here: http://www.suspectsemantics.com/blog/2016/12/03/monomorphiza...
Monomorphization seems to be the source of 2 major problems: compile time, and binary size.
An optimization that could reduce the compile time by caching the generated code (at least when compiling over-and-over the same code base. i.e. "Incremental compilation") - and it seems that Rust already is doing something with it [1]. I wonder if something specific is done for template instantiations there.
Optimizations aimed at reducing binary size seems much more tricky, if not impossible, except as you pointed out in the limited cases described above. In the regular cases, templates are kind of working as intended: the developer has to think if he/she would have written the same amount of code N times if templates were non existent.
This is partly why there are hacks like unity builds (not related to the engine, where all source is bundled into a single translation unit). These have plenty of drawbacks too so it's not a clear win.
Adding to all of this, there are fancier mechanisms for template meta-programming like SFINAE rules + computed template values. Sure, it's "turing complete" but this is why we see such clever libraries with huge explosions in code generation size. I'm far from an expert in modern C++ features but it's clear that there is an entire interpreted programming language of templates bolted on the to the rest of C++. It reminds me of this post on a similar take on Haskell type level programming: https://aphyr.com/posts/342-typing-the-technical-interview (or similar feats by Oleg Kiselyov).
pub fn big_function<T: Into<i32>>(x: T) {
let y: i32 = x.into();
... code that uses y but not x ....
}
That detection can happen as a side effect of specialising that code to some particular {T: Into<i32>, x: T, y: i32} for the first time. As you specialise that code you record which parts of the type environment actually got used, and you use only those parts as a key in the cache. The type environment object itself could take care of recording what the compiler looked up in it. Another advantage of doing it this way, rather than analysing the code ahead of time, is that it can handle cases where a particular type variable does or doesn't get used depending on what type some other type variable is instantiated to. You could also use the same system to avoid duplicating code that only relies on particular aspects of a type. For instance, a function that permutes the values in a &mut[T] might only care about the size of T and not about the precise type T, so that all its specialisations to T of 4 byte size can call into the same code.
Another thing you'd probably want to do is integrate a basic form of constant propagation & dead code elimination during monomorphisation, so that you don't spend a lot of time monomorphising code that ends up dead for particular type instantiations.
Yes, that's what I'm saying.
> Another thing you'd probably want to do
This is a very interesting idea!
Edit: especially if that 3 s pays for generating code that nobody has to write correctly or ever look at.
Whereas in Go, say, stuff like ranges and maps is just built in, no more abstraction than is necessary to do a generalist job with a few specialised common cases. Even the standard library is largely one-level, direct code, and only abstract at the interfaces.
So simply and literally, C++ has to compile more lines of code to do the thing.
C was unusual that so much of it was in its libraries rather than being built in. Programming language design in those days didn't have the clean differentiation we have today.. or perhaps did: it's fascinating to see the arc bend back.
Pascal and C were definitely influenced by Simula, a language ahead of its time.
When K&R wrote that line I suspect they were thinking more of PL/1 which was the Multics implementation language. Though it has OPEN/CLOSE etc they were keywords not external labels.
I think it’s pretty likely K had heard of Pascal at the time.
More interestingly BCPL’s i/o was via library rather than innate. And c descends directly from BCPL (->b->c) rather than from PL/1; simula-67 and BCPL were developed contemporaneously in Europe.
Again, apologies for my prior brevity.
On Haskell's case it depends on which compiler backend you are actually using.
So yes, it is a matter of effort spent in the code compilation, specially if the language does support modules.
Borland still did a great job with their implementation performance-wise, and the legendary reputation of their Pascal compilers is well-deserved. But they had a solid foundation to build on in form of a tool-friendly language, which C++ just doesn't offer.
Same applies to C++ Builder, at least until they decided to move to clang.
Also, IIRC Delphi had only recently gotten generics, and they're still not heavily used? I suspect that code that's heavy on those will compile pretty slow.
It's mostly working on the linux kernel and qemu that showed me I could write extremely nicely structured code, in plain C. Very easy to debug, very readable, very quick to compile and run.
And then one day I looked at one of my C++ module and told myself I actually didn't /need/ all that jazz of classes, namespaces, constructors etc etc. It could be done as a small .h/.c couple with 2 functions...
And that day I started to convert many many lines of C++ to plain C. Because it's /indestructible/, it'll continue compiling and working on /anything/ forever, without having to figure out why the new C++ compiler is throwing you a 10 lines error message just because that codebase is 10yo and isn't up to scratch with the 'new' way of doing things.
I DO miss bits of C++, I miss some of the encapsulation it provides, I miss stack-based objects, and funnily enough, I miss exceptions. But I haven't looked back.
The other points he makes about 'junior hires' is also very valid, with C++ you could /easily/ have a new guy write completely bonkers code, add subtle bugs that takes days to find, much much later. I had my own horror stories about that, and that's another factor that pushed me over the edge to drop the language.
Does this happen? I thought the committee was so into backwards-compatibility that C++ will also work on everything forever.
Then one day, you recompile it and no, it /needs/ to be ZERO and not NULL sorry.
But it's just one simple to fix example, in plenty of cases, especially as templates (and especially template instantiations) evolved, the whole thing would come crashing on you. For a while trying to compile templated code on MS, CodeWarrior and GCC was pretty much impossible without deploying ruses that made C preprocessor macros tame in comparison.
Judging by your mention of CodeWarrior, this all sounds like war stories from pre-standardization days (and of course it still took a while after ISO C++98 was published, for implementations to actually adopt it).
True, but is was guaranteed that NULL expands to “an implementation-defined C++ null pointer constant” (C++98 §18.1), where a ‘null pointer constant’ is “an integral constant expression (5.19) rvalue of integer type that evaluates to zero" (C++98 §4.10). So while it didn't have to be just plain (literal) 0, it did have to be a compile-time constant integer 0, which is otherwise just as good unless you're doing macro magic.
(This differed from C (ANSI era), in which a null pointer constant can alternatively have type (void*), and often does.)
The fact that a pure declaration requires a literal single character ‘0’ (rather than 0) is just one sad example of C++'s ad-hoc irregular overloading of things to mean different things.
Of course, for English, this is exactly the sort of problem that is addressed by style guides (and teachers/peers reacting to you, and natural selection). I think what we need is more and better opinionated C++ style guides that don't just talk about what line to place your { on, but have the confidence to say things on the level of "std::move may add a marginal amount of efficiency, but greatly detracts from the legibility of code. Avoid using it altogether."
Compare inline assembly: it can be absolutely essential to talk to hardware or use specialised processor features (like if you want to use fancy SIMD instructions in the inner loop of a linear algebra library), but everyone would probably agree that a library which keeps the actual assembler code contained inside one or two specific functions is somehow preferable to one where each of the 40 different ways of calling it happily start out with an __asm block that packs their respective arguments into the relevant special-purpose registers and only then call the common "do the actual processing" function.
* Yes to classes.
* Yes to inheritance and virtual member functions, because interfaces are a very useful and easy to understand abstraction. Moreover, especially for games, idioms such as "class Monster : public DamageableObject" are really the most natural thing. However, avoid situations in which you need dynamic_cast like the plague. No to virtual inheritance.
- I really wish class memory layout were standardised more, but at least some non-standard assumptions are fairly safe in my experience: e.g. class A : B {...} ... B * x; assert((long)static_cast<A* >(x) == (long)x);
* Before you start using "friend class", consider whether you could get around it somehow. If a class is not public-facing, set everything public and enforce encapsulation by self-discipline rather than language features.
* Yes to templates in their C++ 101 application of making a $type-specialised version of classes and functions. No to using them to perform any real compile-time computation, or anything of the type Boost pulls. No to Boost.
* "Keep the parts of your code that only do C stuff in C".
- printf over iostream.
- (de)allocate classes with new/delete, but POD with malloc/free
- exception: std::string over char* , because it is really that much more convenient
* Yes to lambdas, but only pass them as function arguments if there is no good alternative, because of legibility. Avoid stuff like the for_each(..., []{ ... }) in the Ranges example.
* Yes to STL containers and algorithms, because everyone knows how they work and they are usually good enough.
* Range-based for over for(std::container::iterator i=...). Using the Ranges TS when a plain for loop would do strikes me as novelty-chasing and violates "do C stuff in C".
* Cautious yes to auto. It does somewhat detract from comprehension in some use cases. Don't just auto everything because you are too lazy to figure out the type.
* std::shared_ptr only when you actually think you can't answer the question of what the appropriate point to deallocate a piece of memory is, or at least not without significantly changing the structure of your code.
* Avoid std::tuple, std::variant and other awkward STL attempts to replicate functional language idiom without the syntactic support. It's terrible to read. Unfortunately, STL containers sometimes force you to use pair.
* No to exceptions; their interaction with other language features is awkward, and the eternal difficulties with platform support make me feel no confidence in the reliability of the feature. (I'm unfamiliar with the bowels of the implementation, but it seems like unwinding C++ stacks is fundamentally a hard problem.)
* No to novelty features such as user-defined literals.
* goto only to break out of multiple levels of nested loops.
* Coroutines strike me as something that's unambiguously cool but so far removed from the standard idiom of C++ programming that I'm inclined to say no. Maybe there's an alternative style guide you could write that says yes to coroutines and no to some of the things above. Multi-paradigm should not mean "use all the paradigms".
(I'm very happy to be persuaded otherwise on any of these points.)
(I have of course produced my share of memory leaks - praise be to valgrind - but they were all in scenarios where unique_ptr would have been too restrictive (without a Rust-style complete reconsideration of the code's ownership structure).)
In fact, I have seen a number of horrific instances that someone decided to write clever tricks with object lifetime which leads to production crash and no one really understand (or even bother) what's going on there. The only way to deal with such code is looking into its implementation, probably for a week or two. And found that the original author has left the company.
In these cases, static type annotation helps a lot by serving as a formal contract. To reason about object lifetime, you don't need to dig into the implementation; all you need is looking into variable's type signature. Same thing can be applied to types other than those related to object lifetime.
I get that if you just use it for usual the owning class, it doesnt provide that much, but it annotates lifetime, and its pretty cool when you get used to it.
if you see this:
class X {
Y* y;
};
class X {
std::unique_ptr<Y> y;
};
class X {
std::unique_ptr<Y> CreateY();
Y* CreateY();
};
Now in the second example you are not sure if X retain and will handle the deletion of Y, and you should use Y, while in the first example its perfectly clear the api intention.
the same here:
void AddY(std::unique_ptr<Y> y)
void AddY(Y* y)
Before std::move() i get it, but after you can pass things by moving them, i dont get it why anyone would not like to use this.
For me this is basically the "lifetime annotation" feature, only that it is by convention, and not enforced by the compiler. Unlike others these are the reasons why i dont feel the urge to jump the Rust bandwagon, and prefer to use things like Swift when i need a more "chill" environment to work, as i didnt feel more productive in Rust than in C++, while with Swift it happened and it also has a pretty good story perfomance wise.
I prefer to mix C++/Swift as my perfect duo, than try to make it all fit in one language, as this always lead to frustation and a lot of headaches.
The compiler knows where the lifetime ends. Why do the computer's work for it?
You need dynamic_cast for dynamic interface queries ("does this object support X?"), even in the absence of virtual inheritance.
Some would say that there's no downside to always using it when you can. If what you're doing is an upcast, it's a no-op. If it's a downcast, then at least you get an exception instead of an invalid pointer that may or may not blow up if what you're casting is not of the correct type.
> Before you start using "friend class", consider whether you could get around it somehow. If a class is not public-facing, set everything public and enforce encapsulation by self-discipline rather than language features.
Why? It's a language feature that's there to help you enforce said discipline. What's the downside?
> I really wish class memory layout were standardised more, but at least some non-standard assumptions are fairly safe in my experience: e.g. class A : B {...} ... B * x; assert((long)static_cast<A* >(x) == (long)x);
That the object is allocated at the same address as its base subobject is guaranteed by the standard, if I remember correctly. Your particular assert is not, though, because long is not guaranteed to fit a pointer (and doesn't, on Win64).
> printf over iostream.
Not only you lose type safety, but it's extremely easy to write code that kinda sorta works but actually doesn't. The most common case is passing a struct with a single field to printf - this is actually implementation-defined, and some implementations detect it and treat it as invalid, while others just put the contents of the struct on stack. So it happens sometimes that people e.g. pass std::string that way, expecting it to work with %s - and it does... on that one implementation, and for that particular string. Then it breaks elsewhere.
iostream is still bad tho, both design-wise and perf-wise. The answer is actually Boost, which has proper typesafe formatting.
> (de)allocate classes with new/delete, but POD with malloc/free
There's no benefit to using malloc/free whatsoever, and it forces you to cast.
> Avoid std::tuple, std::variant and other awkward STL attempts to replicate functional language idiom without the syntactic support
Tuple has syntactic support as of C++17:
https://en.cppreference.com/w/cpp/language/structured_bindin...
> No to exceptions; their interaction with other language features is awkward, and the eternal difficulties with platform support make me feel no confidence in the reliability of the feature.
If you ditch exceptions, you might as well ditch constructors as well, since there's no way to report errors from them otherwise. You're also forced to use new(nothrow) then. Basically, the language is designed around exceptions, and excluding them is fighting it.
But I don't see the point. C++ exceptions have been supported and stable on all platforms for a long time now. On sane platforms (i.e. not x86, but e.g. amd64), they're also zero-time-cost at runtime for the non-exceptional path. It's not the 90s anymore.
I prefer using C-style casts for brevity, and implementing support queries like that explicitly (i.e. via a "type" member or GetType() function or whatever in the base class). Quite often, you wind up needing that information anyway (resulting in redundancy), and the C++ casts are extremely verbose and ugly.
> Why? It's a language feature that's there to help you enforce said discipline. What's the downside?
I've tried working with it, but in my experience this language feature very quickly consumes more cognitive energy (by having to maintain the list of friend classes and just having to deal with it being there, consuming space in the source) than it saves over maintaining discipline manually. (This maybe a consequence of me not having worked on a lot of C++ projects with a high (number of contributors)/(lines of code) ratio.)
> That the object is allocated at the same address as its base subobject is guaranteed by the standard, if I remember correctly.
Huh. All sources I could find seem to claim that it actually isn't, but maybe I'm looking at the wrong ones.
> Your particular assert is not, though, because long is not guaranteed to fit a pointer (and doesn't, on Win64).
My bad. I've mostly only used unixoid systems for too long now.
> printf over iostream
But printf is so much more legible when you have to format complex strings.
> passing struct or std::string to printf
Who does that?
> There's no benefit to using malloc/free whatsoever, and it forces you to cast.
I do value keeping portions of code that don't use C++ features in C for reusability purposes, and moreover there is the whole issue that it's easy to get confused about initialisation with int* a=new int (uninitialised)/new int() (=0). If you use malloc, it's clear to everyone that it's uninitialised.
> Tuple has syntactic support as of C++17:
Yes, ugly, non-principled syntactic support.
std::tuple<int,int> a = {1,2}; // { }, like most other instances of lists of things
auto [x,y] = a; // [ ], for some reason (not used for lists/tuples anywhere else)
auto [z,w] = {1,2}; // this doesn't work at all
> If you ditch exceptions, you might as well ditch constructors as well, since there's no way to report errors from them otherwise. You're also forced to use new(nothrow) then. Basically, the language is designed around exceptions, and excluding them is fighting it.
I've worked with a number of embedded platforms that had C++ support without exceptions. As far as I know, there are also still issues when exceptions are thrown through non-C++ stack frames (e.g. a callback invoked from a C library). I'm aware of the problem of errors in constructors, but think that in general it is best to try and write code so that constructors don't do anything that can cause errors (I strongly prefer constructors to only serve the role of putting the object in a coherent state, and having a separate Init function for any nontrivial operations that could fail.)
Memory allocation may be an exception to this, but I feel like code where the sane reaction to OOM is not to treat it as a panic-abort condition is special enough that special measures such as an provisioning an explicit "constructed, but no memory has been acquired" state in your objects are justified.
I really do want exceptions to work - having worked with Standard ML for a long time, I'm well aware of how right they feel as a solution to error handling - but the C++ implementation of them still feels like it ultimately has way too many moving parts to be trustworthy.
(Edit: The new * italics syntax on HN is really throwing me off.)
There are strong reasons to avoid them altogether in C++, not the least is that you can sometimes get a reinterpret_cast where you expected a static_cast semantically - usually because you have forgotten to include the header that has the definition of the type, and are dealing with an incomplete type (explicit static_cast will fail in that case; but C-style cast will be treated as a reinterpret_cast, even if it would have been a static_cast if the definition was visible and type was complete).
> Who does that?
The typical example is when people pass std::strings to printf, either because they expect them to work with %s, or because they simply forgot to call data(). Unfortunately, on compilers that don't try to detect structs-as-varargs, this often works by accident.
How come we don't see exceptions being used in serious C++ projects then (e.g. Chromium and Windows)?
I have professionally worked in many async (and synchronous) languages, and the implementation of async in modern C++ is my favorite. That is weird to type out, but it's true. I'm really enjoying modern C++, but I do follow almost all the rules you list.
(Also, PHP isn't perfect, but it's really good at allowing clear readable code, while also allowing terrible code, also the performance is terrible... Basically, don't waste your breath on why PHP is terrible - it isn't, it's a decent language - you're just using it wrong)
Imperative programming has no future IMHO. Rust is going to the ends of the earth to make it "safe" but my gut feeling is that it will never be fully statically analyzable. Today I only see needless complexity that distracts from the underlying logic. I lost interest in this style of programming around a decade ago.
Functional programming via templates is an admirable endeavor, and I went all the way to the ends of the earth to make something of it. I was left with code that wasn't reusable (wasn't salable) so in the end, just wasted years of my life on needless complexity.
And both of the above only make sense from a performance perspective. An argument that becomes weaker with each passing year as processing speed improves.
I think the future will be something more like reactive functional programming, written in a high level language like Javascript and only dropping down to bare metal optimizations with something like Rust when necessary. It will work like the UNIX shell (which is the only proven model that's endured). So something like the Actor model where a series of black boxes are wired together with pipes and as much FP as possible, and any IP sections are treated like monads and flagged as having unknown side effects. ClojureScript does something like this, running its FP code to completion and then yielding until more input/output happens on the Javascript side. Another way of thinking about this is a spreadsheet with some imperative code within the cells where needed.
PHP is my favorite language currently because it has some notion of constness and fairly decent higher order functions (but who are we kidding, map and reduce give us everything else). PHP is a conceptually simple language that has some longstanding flaws with naming conventions that make it not as easy as it could be. It's largely succeeded in moving away from object-oriented programming, favoring a fairly simple interface implementation instead. I've never run into the implicit context problems that plague languages like Ruby (where convention over derivation is written into its DNA).
And PHP is fairly fast, on the order of 200 times slower than C++ but probably within the same order of magnitude as the newer C++ methods mentioned in the article. My gut feeling is that proper string handling, with every contingency accounted for, runs approximately the same speed in any language. I'm not willing to spend time and effort trading safety for performance anymore.
Uhm, how are cell functions in spreadsheets an example of imperative programming?
I'd like to see a spreadsheet that uses something like Elixer or Clojure though because then any cells that don't have monads could be fully statically analyzed and form a purely declarative solution.
In other words, the cells could be decomposed further into cells containing individual functions instead of composed statements. That way the spreadsheet could be transpiled into lisp or a syntax tree. I'm using all these terms loosely, but they are equivalent.
https://www.aerospike.com/blog/php7_php5/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
That said, I think it's too complex for a portion of our team to grasp. So now what - do we use it, and alienate them? Or stay in the "dark ages"?
This, to me, is a very powerful statement that points to the major change between old C++ and the current model (which is IMO is a monster). It may have gained a lot in the process, but at a huge cost to conciseness and clarify of written code. And this may be fatal for a general purpose language.
Maybe as other languages with focus on cleanliness and clarity (Pythons, Kotlins and Haskells of this world) become fast and powerful enough for large projects the use case for simple and clear C++ code decreases. Then C++ can still provide benefit for, say, intermediate representations. But this complexity increase may be one of the last nails into its coffin as a general purpose language. My 2c.
no. Just no. Haskell is a lot like C++.
However, in general, (in my opinion of course) the cognitive load for Haskell is low as a novice, but gets higher and higher as you go down the rabbit hole toward learning, understanding and applying all of its power - which is constantly evolving not unlike C++.
So, I would argue the cognitive load is similar, and both lay everything out right in front of your eyes. Although, Haskell will do it with less syntax (alternatively, read that as "with more syntactic sugar").
One part that really struck me as odd is the focus on non-optimized performance. To me, this is an important consideration, but not nearly as important as optimized performance. Using techniques like ranges can definitely slow down debug performance, but much of the time it _dramatically increases_ optimized performance vs. naive techniques.
How do ranges speed up optimized builds? One of the best techniques for very high performance code is separation of specifying the algorithm and scheduling the computation. What I mean by this is techniques like [eigen](http://eigen.tuxfamily.org/index.php?title=Main_Page) and [halide](http://halide-lang.org) where you can control _what_ gets done and _how_ it gets done separately. Being able to modify execution orders like this is critical for ensuring that you're using your single-core parallelism and cache space in an efficient way. This sort of control is exactly what you get out of range view transformers.
This claim will require some evidence. In my experience, it's extremely common for novice engineers to trade orders of magnitude in build time overhead chasing negligible runtime performance improvements.
> One part that really struck me as odd is the focus on non-optimized performance
I'm guessing your high performance applications aren't interactive? When your application has to respond to user input in real time, a binary that is 100x slower than real time is completely useless. You can't play a game at 0.3 frames per second.
I would be interested in seeing an example of how Halide-like techniques can be used with C++ ranges. I am skeptical that you could get the kind of performance improvements that Halide can achieve. And of course you won't get the GPU or DSP support that is really useful for that kind of computation.
Also, I think build time is super important in most contexts - what I think is less important is runtime speed when you’ve disabled all optimizations.
Edit: I see, I carelessly used the word "build" to mean a compiled binary, which was ambiguous. I've changed it.
With "modern" techniques, the performance ceiling is a bit higher - whether that benefit is worth it depends on a lot of factors.
And for games you need decent runtime speed. If you cannot run your game in debug build one has to do good old printf debugging. And yes, if you cannot actually play the game (as in over 10fps) that means you cannot run it in debug build.
Don't make my Debug build into a RelWithDebInfo build or it makes it a huge pain to track down subtle bugs/errors in non-performance-critical unit tests.
In particular, you can always debug a tiny version of whatever problem you're trying to solve, so you don't really care that much about non-optimized performance, and a lot of times you're willing to eat a long compile time if it means you squeeze out that last couple percent. Conversely, you care a lot about cache micro-optimizations and talking to GPUs and stuff like that, and generally you want to be just banging on some piece of memory you got from the OS, all things that non-C++ languages make extraordinarily painful.
Even Fortran, which the haters were trying to push as "just better" than C++ for linear algebra has really disappointed me.
To add insult to injury, std::variant is a rather bad approximation of a sum type. variant<int,int> is only partially functional, and you can’t disambiguate the two ints by name the way you could in, say, Rust.
I think that a lot of these problems stem from two systematic problems
1. The desire to avoid modifying the language. A good modern language should have sum types. Heck, the ranges paper explains how ranges fundamentally have the wrong semantics wrt const and that this can’t be fixed without changing the language. So fix the language, please!
2. The fact that even new libraries are specified to be header files. Surely there could be a variant module even if modules aren’t really for full deployment.
I hate to sound like a broken record but I've been telling everyone I know to try https://zapcc.com. If you are on Linux then it is a real solution to long compile times, especially for incremental builds.
yeah, <variant> is so slow that I wrote my own (domain-specific but could be repurposable) variant-like code generator. It keeps the same API but makes everything sooooooooooooo much faster to compile - especially the visitations with multiple arguments.
(ugly fugly, full of dirty hacks, but it only had to run once or twice : https://github.com/OSSIA/libossia/blob/master/tools/gen_vari...)
Somehow, it feels good to use it and after a while you find yourself reveling in complexity. I'm almost ashamed to say really.
R-value references, for example. This is entirely a problem that C++ has created for itself with its copy semantics. From inside the C++ ecosystem, the language feature makes sense, but from outside the C++ ecosystem, the idea that there are now two types of references and two types of copy semantics triggered based on the implicit interaction of reference types, and you sometimes need to do idiomatic things like declaring undefined private copy constructors to lock down unintended implicit behaviors relating to copy semantics for R-value references... yup, hamster wheel.
C++ isn't the only language where I get this feeling. I think Scala is pretty guilty of this too. It's not that I can't grok it if I wanted to (survived my share of proof based, pure theory math classes back in college), it's that I think it's entirely too much energy to be spending on mundane code.
include normal pointers and it's three.
The one I always think back to is DirectX vs OpenGL. DirectX has had historically better driver support, documentation, and ready-to-compile example code (OpenGL has caught up a lot admittedly over the years, due to greater proliferation of OpenGL-driven devices).
[1] subjective opinion
In order to improve C++ compilers, we are going to need to throw away some old assumptions about how they should work. Zapcc challenges the notion that the compiler should exit after compiling each file and start over with the next one. Perhaps some of the other issues Aras points out could be addressed by rethinking some assumptions. For example, tighter integration between the compiler and debugger could potentially make it feasible to debug optimized builds.
this idea has been floating for a long time :
ftp://gcc.gnu.org/pub/gcc/summit/2003/GCC%20Compile%20Server.pdf
and
https://gcc.gnu.org/wiki/IncrementalCompiler
sadly, it seems that modules has put these approaches on hold, even though I am pretty sure that modules won't solve the problem.
I immediately thought about some Java (Gradle) projects at work that take 10 minutes to build, and other transpiled javascript projects that take an hour or so. What am I doing with my life?
The calculation of Pythagorean Triples is literally one line in Haskell (a language I have used for almost three decades), as a simple list comprehension. It also can then be consumed or used in any fashion, and is calculated lazily.
While I am not particularly adept at other "functional" languages, I would imagine similar brevity in F#, OCaml and possibly even Python (which I believe has some sort of list comprehension syntax).
I have worked in the game industry and have many bad experiences with printf/logging consuming so much performance it makes games unplayable.
I still like C++ though. At least a subset of it anyway.
I think Bjarne Stroustrup is partly to blame here. He has succeeded in creating a versatile and popular language but has given little priority to problems like build time, error messages and debug performance. These sound like petty, practical problems that the tooling guys should eventually figure out. Except they aren't. They are hugely dependent on the language design.
Another thing we are missing is a high profile figure that will show the way on correct patterns and that will literally publicly shame the authors of too "meta" template heavy libraries. You are not smart if you are writing these monstrosities. It should not feel good. Making it simple requires much more intelligence.
The "cult of generic metaprogramming" is the very community pushing for those features.
> literally publicly shame the authors of too "meta" template heavy libraries.
This is pretty harsh. I agree that metaprogramming abuse in application code is a problem, and it's not something that should be advocated. However, there is a big difference between promoting C++ literacy and saying "everyone should commit metaprogramming code at work". The blame for metaprogramming abuse lies _squarely_ on engineering teams with poor quality control, not on library developers who like to push the language to its limits in their free time.
Everyone knows that C++ is a language of footguns. Metaprogramming is one of them; Boost is a mixed bag. Every successful C++ engineering team enforces coding standards to address this.
Wouldn't they say we should instead shame the people who can't read them? What makes you right and them wrong?
These excesses have in fact a positive side: the extent that people will go to get a specific functionality (in this case lazy ranges) as a library is a signal that the feature should be part of the language.
This happened with lambdas, boost.lambda, boost.phoenix and to a lesser extent boost.bind showed that the functionality could be implemented as a library, people stated playing with it and demanded the functionality to be baked into the language.
A similar thing is happening now, there is a push to extend the proposed await syntax to become a more general (and more efficient) continuation syntax that, among other things should lead to built-in support for lazy ranges.
As I see it, there are multiple "sub languages" in c++:
-Macros: use as little as possible.
-Classic C: use only when interacting with C libraries, or in the few cases where it's more convenient (printf over cout).
-Classic C++ (classes, etc): use it all the time.
-Template meta programming: use only for simple things, eg containers.
-Functional C++: try to avoid.
Modules.