Who the hell typeset this?

I'm guessing someone pasted from what went into the print edition. Or Bjarne himself.

It's just the first code snippet that's messed up. The rest is merely wonky.

Communications of the ACM has had unbelievably bad typography for code samples for decades (predating the web). No idea how this is allowed to continue.

You don't use 10 spaces of indentation? It's the 21st century.

It’s a wchar_tab.

I want to love C++.

Over my career I’ve written hundreds of thousands of lines of it.

But keeping up with it is time consuming and more and more I find myself reaching for other languages.

I went from being curious about C++, to hating C++, to wanting to love it, to being fine with it, to using it for work for 5+ years, to abandoning it and finally to want to use it for game development, maybe. It's the circle of life.

The masochist in me keeps coming back to c++. My analogy of it to other languages is that it’s like painting a house with a fine brush versus painting the Mona Lisa with a roller. Right tool for the job I suppose.

It's my job and career(well, C and C++) but I often try to avoid C++. Whenever I use it(usually writing tests) I go through this cycle of re-learning some cool tricks, trying to apply them, realizing they won't do what I want or the syntax to do it is awkward and more work than the dumb way, and I end up hating C++ and feeling burned yet again.

Yeah, it's a struggle. Keeping to a good subset often works out, though. I recognize the feelings. Best of luck. :)

You don't 'have' to keep up with the language and I don't know that many people try to keep up with every single new feature - but it is worse to be one of those programmers for whom C++ stopped at C++03 and fight any feature introduced since then (the same people generally have strong opinions about templates too).

There are certainly better tools for many jobs and it is important to have languages to reach for depending on the task at hand. I don't know that anything is better than C++ for performance sensitive code.

I’ve been using c++ since the late 90’s but am not stuck there.

I was using c++11 when it was still called c++0x (and even before that when many of the features were developing in boost).

I took a break for a few years over c++14, but caught up again for c++17 and parts of c++20...

Which puts me 5-6 years behind the current state of things and there’s even more new features (and complexity) on the horizon.

I’m supportive of efforts to improve and modernize c++, but it feels like change didn’t happen at all for far too long and now change is happening too fast.

The ‘design by committee’ with everyone wanting their pet feature plus the kitchen sink thrown in doesn’t help reduce complexity.

Neither does implementing half-baked features from other ‘currently trendy’ languages.

It’s an enormous amount of complexity - and maybe for most code there’s not that much extra actual complexity involved but it feels overwhelming.

It’s okay to be a few years behind the standard, the compilers tend to be as well.

Yeah, the issue is more that the perceived complexity means I’m less interested in investing time to catch it all back up

If you already used C++20 you aren't meaningfully behind, very little of interest has been introduced since then, and much of it isn't usable yet because of implementation issues.

I’ve touched on some of c++20, but haven’t used it extensively.

Specifically here are areas I haven’t used that appear to have nontrivial amounts of complexity, footguns, syntax and other things to be aware of:

* Ranges * Modules * Concepts * Coroutines

Each of these is a large enough topic that it will involve time and effort to reach an equivalent level of competence and understanding that I have with other areas of c++.

I don’t mind investing time learning new things but with commentary around the web (and even this thread) calling the implementation and syntax a hot mess, at some point it’s a better investment to put that learning in to a language without all the same baggage.

I really wish c++ had gone with breaking change epochs for c++20.

Same here.

>>contemporary C++30 can express the ideas embodied in such old-style code far simpler

IMO, newer C++ versions are becoming more complex (too many ways to do the same thing), less readable (prefer explicit types over 'auto', unless unavoidable) and harder to analyse performance and memory implications (hard to even track down what is happening under the hood).

I wish the C++ language and standard library would have been left alone, and efforts went into another language, say improving Rust instead.

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto increases readability, the only thing I dislike is that they didnt make it a reference by default.

Where do you see difficult to track down performance/memory implications? Lambda comes to mind and maybe coroutines (yet to use them but guessing there may be some memory allocations under the hood). I like that I can breakpoint my C++ code and look at the disassembly if I am concerned that the compiler did something other than expected.

E.g. `std::ranges::for_each`, where lambda captures a bunch of variables by reference. Like I would hope the compiler optimizes this to be the same as a regular loop. But can I be certain, when compared to a good old for loop?

To be fair std::ranges seems like the biggest mistake the committee allowed into the language recently.

Effectively other than for rewriting older iterators based algorithms to using new ranges iterators I just don't use std::ranges... Likely the compiler cannot optimise it as well (yet) and all the edge cases are not workes out yet. I also find it to be quite difficult to reason about vs older iterator based algorithm's.

for each would take a lambda and call the lambda for each iterator pair, if the compiler can optimise it it becomes a loop, if it can't it becomes a function call in a loop which probably isn't much worse... If for some reason the lambda needs to allocate per iteration it's going to be a performance nightmare.

Would it really be much harder to take that lambda, move it to a templated function that takes an iterator and call it the old fashioned way?

Yeah, the std::ranges implementation is a bit of a mess. The inability to start clean without regard for backward compatibility reasons limits what is possible. I think most people see how you could implement comparable functionality with nicer properties from a clean sheet of paper. It is the curse of being an old language.

There are sane approaches to dealing with this - e.g. epochs.

This wasn’t proven by the time c++11 was ready, but for c++20 and beyond it’s a shame they didn’t go with this.

Did you try the two version in Godbolt?

Just ban ranges lib, it is hot garbage anyway. The compilers are able to optimize lambdas fairly well nowadays(when inlined), I wouldn't be that concerned.

I just wish they hadn't repurposed the old "auto" keyword from C and had used a new keyword like "var" or "let".

   #define var auto
   #define let auto

If we're going that route, how about

   #define var auto
   #define let const auto

?

I was thinking of having one or the other, but let as the const form is appealing. ;-)

Given how important backwards compatibility is for C++, it's either take over a basically unused keyword or come up with something so weird that would never appear in existing code.

Java solved this by making var a reserved type, not a keyword, but I don't know if that's feasible for C++.

I've been writing C++ since 1996-ish.

Less and less, for sure.

Nothing the past few years.

They killed it.

If you only read HN, you would think C++ died years ago.

As someone who worked in HFT, C++ is very much alive and new projects continue to be created in it simply because of the sheer of amount of experts in it. (For better or for worse)

I have listened to a few podcasts by HFT people. Looks like you try to maximize performance and use a lot of C++ skills. Very interesting to listen to but I wonder how does anyone pick up the skills?

Can also confirm c++ is alive and well at FAANG. Might still be the most popular language for most new projects.

* for some values of FAANG

C++ has been dead and effectively banned at amzn for years. Only very specific (robotics and ML generally) projects get exemptions. Rust is big and only getting bigger

Fair! I would say people would be surprised to learn pretty much every large AI project is mostly c++ because of its interop with python.

Some FAANGs focus on AI more than others.

The fact that we don't have a viable alternative yet doesn't exactly mean that the language is in good shape.

It just means it's in the best shape of any of the languages in it's domain

Can confirm pretty much the entire embedded systems world uses either C or C++.

That's probably most devices in the world.

It used to be C++ would be the last choice for embedded...

Modern C++ with constexpr and friends and the massive work and cunning they have put into avoiding template bloat....

...C++ is now my first choice for embedded.

Took me a moment to realize that "killed it" was being used in the negative sense.

Almost a haiku :)

I think it's good enough or side projects. More powerful than C so I don't need to hand roll strings and some algos but I tend to keep a minimum number of features because I'm such an amateur.

since -14 or -17 I feel no need to keep up with it. thats cool if they add a bunch more stuff, but what I'm using works great now. I only feel some "peer pressure" to signal to other people that I know c++20, but as of now, I've put nothing into it. I think it's best to lag behind a few years (for this language, specifically).

The compilers tend to lag a few years behind the language spec too, especially if you have to support platforms where the toolchains lag latest gcc/clang (Apple / Android / game consoles).

Respectfully, you might want to add at least a few C++20 features into your daily usage?

consteval/constinit guarantees to do what you usually want constexpr to do. Have personally found it great for making lookup tables and reducing the numbers of constants in code (and c++23 expands what can be done in consteval).

Designated initializer is a game-changer for filling structures. No more accidentally populating the wrong value into a structure initializer or writing individual assignments for each value you want to initialize.

On the other hand, the decline of robust and high quality software started with the introduction of very immature languages such as both javascript or typescript ecosystems.

It's really any other language other than those two.

Same. Luckily my team switched to Rust almost 100%. So I don't need to learn about the godforsaken coroutine syntax and what pitfalls they laid when you use char wrong with it or in which subset of calls std::range does something stupid and causes a horrible performance regression.

Bjarne has been criticized for accepting too many (questionable) things into the language even at the dawn of C++ and committee kept that behavior. Moreover they have this pattern that given the options they always choose the easiest to misuse and most unsafe implementation of anything that goes into standard. std::optional is a mess, so is curly bracket initialization, auto is like choosing between stepping on Legos or putting your arm into a spider-full bag.

The committee is the worst combination of "move fast and break things" and "not in my watch". C++98 was an okay language, C++11 was alright. Anything after C++14 is a minesweeper game with increasing difficulty.

> Bjarne has been criticized for accepting too many (questionable) things

He even writes that way in his own article... The quote from the last section of the introduction was hilarious, and actually made me laugh a little bit for almost those exact reasons.

BS, Comm ACM > "I would have preferred to use the logically minimal vector{m} but the standards committee decided that requiring from_range would be a help to many."

You don't have to "keep up with it", if by this you mean what I think you mean.

You don't have to use features. Instead, when you have a (language) problem to solve or something you'd like to have, you look into the features of the language.

Knowing they exist beforehand is better but is the hard part, because "deep" C++ is so hermetic that it is difficult to understand a feature when you have no idea which problem it is trying to solve.

Wrong. Most programmers spend tremendous amounts of time reading and maintaining someone else's code. You absolutely have to keep up with it.

Thankfully "most" C++ code was written before C++11 (good luck with programs that fully utilize "modern" C++'s constructs and their semantics, because at this point only compilers can reliably manipulate them).

I mean, right from Bjarne's mouth:

> I used the from_range argument to tell the compiler and a human reader that a range is used, rather than other possible ways of initializing the vector. I would have preferred to use the logically minimal vector{m} but the standards committee decided that requiring from_range would be a help to many.

Oh so I have to remember from_range and can't do the obvious thing? Great. One more thing to distract me from solving the actual problem I'm working on.

What exactly is wrong with the C++ community that blinds them to this sort of thing? I should be able to write performant, low-level code leveraging batteries-included algorithms effortlessly. This is 2025 people.

Excellent article. Thanks for sharing.

I always hear about “import std” but still don’t see out of the support for it. Is it still experimental?

Last weekend, I took an old cross-platform app written by somebody else between 1994-2006 in C++ and faffed around with it until it compiled and ran on my modern Mac running 14.x. I upped the CMAKE_CXX_STANDARD to 20, used Clang, and all was good. Actually, the biggest challenge was the shoddy code in the first place, which had nothing to do with its age. After I had it running, Sonar gave me 7,763 issues to fix.

The moral of the story? Backwards compatibility means never leaving your baggage behind.

I was an extreme C++ bigot back in the late 90's, early 2000's. My license plate back then was CPPHACKR[1]. But industry trends and other things took my career in the direction of favoring Java, and I've spent most of the last 20+ years thinking of myself as mainly a "Java guy". But I keep buying new C++ books and I always install the C++ tooling on any new box I build. I tell myself that "one day" I'm going to invest the time to bone up on all the new goodies in C++ since I last touched it, and have another go.

When the heck that day will actually arrive, FSM only knows. The will is sort-of there, but there are just SO many other things competing for my time and attention. :-(

[1]: funny side story about that. For anybody too young to remember just how hot the job market was back then... one day I was sitting stopped at a traffic light in Durham (NC). I'm just minding my own business, waiting for the light to change, when I catch a glimpse out of my side mirror, of somebody on foot, running towards my car. The guy gets right up to my car, and I think I had my window down already anyway. Anyway, the guy gets up to me, panting and out of breath from the run and he's like "Hey, I noticed your license plate and was wondering if you were looking for a new job." About then the light turned green in my direction, and I'm sitting there for a second in just stunned disbelief. This guy got out of his car, ran a few car lengths, to approach a stranger in traffic, to try to recruit him. I wasn't going to sit there and have a conversation with horns honking all around me, so I just yelled "sorry man" and drove off. One of the weirder experiences of my life.

The programmers on the sound team at the video game company I worked for as an intern in 1998 would always stash a couple of extra void pointers in their classes just in case they needed to add something in later. Programmers should never lose sight of pragmatism. Seeking perfection doesn’t help you ship on time. And often, time to completion matters far more than robustness.

Vulkan does that with `void* pNext` in a lot of its structs so that they can be extended in the future.

Funny, sounds like the Simpsons gag from the same time period: “what’s wrong with this country? Can’t a man walk down the street without being offered a job?”

https://youtube.com/watch?v=yDbvVFffWV4

Interesting. I was SO into the Simpsons at one time, but somehow I'd never seen that episode (as best as I can remember anyway). Now I feel the urge to go back and rewatch every episode of the Simpsons from the beginning. It would be fun, but man, what a time sink. I started the same thing with South Park a while back and stalled out somewhere around Season 5. I'd like to get back to it, but time... time is always against us.

That episode is by far my #1 favorite. Season 8 Episode 2, “You Only Move Twice”, during the period considered by most to be the peak of the Simpsons show quality, and IMO the best episode of the season.

Cypress Creek was intended to be a reference to Silicon Valley and the tech companies there of the time, and it’s got some of the best comedy in the season (Hank Scorpio is the best one-off character ever in the show IMO.)

The Hank Scorpio episode is indeed one of the great classics!

AIEXPERT here I come!

Awesome! My current tag is /DEV/AGI :-)

what is the job market like now for C++ programmers? I'm looking for a job.

Note to the above: I am wrong. My license plate back then was C++HACKR, with the actual "+" signs. NC license plates do allow that, although while the +'s are on the tag, they don't show up on your registration card or in the DMV computer system.

I mixed up the tag and my old domain name, which was "cpphacker.co.uk" (and later, just cpphacker.com/org).

Previous from 3 days ago: https://news.ycombinator.com/item?id=42952720 (103 points, 85 comments)

Thanks! I've merged that thread hither since this one is currently on the front page.

(How is that possible, someone may ask? It's the SCP! - see https://news.ycombinator.com/item?id=26998308)

Generalizing Overloading for C++2000

Bjarne Stroustrup, AT&T Labs, Florham Park, NJ, USA

Abstract

This paper outlines the proposal for generalizing the overloading rules for Standard C++ that is expected to become part of the next revision of the standard. The focus is on general ideas rather than technical details (which can be found in AT&T Labs Technical Report no. 42, April 1, 1998).

https://www.stroustrup.com/whitespace98.pdf

How does enforcing profiles per-translation unit make any sense? Some of these guarantees can only be enforced if assumptions are made about data/references coming from other translation units.

This is the one major stumbling block for profiles right now that people are trying to fix.

C++ code involves numerous templates, and the definition of those templates is almost always in a header file that gets included into a translation unit. If a safety profile is enabled in one translation unit that includes a template, but is omitted from another translation unit that includes that same template... well what exactly gets compiled?

The rule in C++ is that it's okay to have multiple definitions of a declaration if each definition is identical. But if safety profiles exist, this can result in two identical definitions having different semantics.

There is currently no resolution to this issue.

I guess modules are supposed to be the magic solution for that, Bjarne has shown them in this article, even using import std.

Its a bit optimistic cause modules are still not really a viable option in my eyes, because you need proper support from the build systems, and notably cmake only has limited support for them right now.

Modules alone do not guarantee one definition per entity per linked program. On the contrary, build systems are needing to add design complexity to support, for instance, multiple built module interfaces for the std module because different translation units are consuming the std module with different settings -- different standards versions for instance.

I've been playing with building out an OpenGL app using C++23 on bleeding edge CMake and Clang and it really is a breath of fresh air... I do run into bugs in both but it is really nice. Most of the bugs are related to import std though which is expected... Oh and clangd(LSP) still having very spotty support for modules.

The tooling is way better than it was 6 months ago though asin I can actually compile code in a non Visual Studio project using import std.

I will be extremely happy the day I no longer need to see a preprocessor directive outside of library code.

is the job market for C++ developers still good?

Depends. For certain fields the pay is great and there’s a dearth of candidates.

For other fields there is also a dearth of candidates but the pay falls short and you’ll be leaving tens of thousands of dollars on the table compared to what you could get with other languages.

C++ should be known for the amount of collective brain cycles wasted on deciding what subset of C++ to use.

Professionals know what tool to use for a job. Does it take time to become good? Of course, like anything.

Not a question of difficulty or skill. I am saying professionals can't agree what subset to use!

They don't have to. The subset depends on the job! That's the beauty and power of C++. That's why we have projects written in it in all domains. From websites to spaceships and Mars rovers.

yes, and you will tell me exactly what subset and coding convention "makes sense" for this domain, and you will give your reasoning too. And I will give my arguments, and on and on it goes. teams have broken up over this.

A well-designed language is one in which there are very few different ways of doing the same thing. And C++ is definitely not that.

Why would a well designed language have only one or few ways to do the same thing? Seems rather arbitrary. I like when I have many ways to do the same thing.

Imagine if you told a writer or poet that English is bad because there is more than one way to say the same thing...

Programming languages are for people more than machines. Machines are happy with microcode.

RE: Why would a well designed language have only one or few ways to do the same thing?

So that you focus on solving the problem at hand, instead of endlessly arguing over decisions that are irrelevant to solving the said problem.

That's the thing though, each similar problem is subtly different. Those differences can matter and the language should allow you to model them.

Another feature of a well-designed language is how well it is able to separate features for library writers vs application writers. I have seen way too many smart coders end up polluting application code with unnecessarily complex features of C++ meant for library writers.

That's why C++ is still around today, it was built on some solid principles. Bjarne is such a good language designer because he never abandoned it. Lesser designers make a language and start another in 5 or 10 years. Bjarne saw the value in what he created and had a sense of responsibility to those using it to keep making it better and take their projects seriously.

Whenever I have an idea and I start a project, I start with C++ because I know if the idea works out, the project can grow and work 10 years later.

C++ and C still force a usage of header files.

For whatever reason this is probably the biggest reason I've struggled with it( aside from tooling... Makes me miss npm).

I dislike the style of Code used to write this. I understand that, given who wrote the article, this is blasphemy.

Opening braces should be inline with the expression or definition.

Comments can be above what they're referred to.

Combined, this makes any code snippet look like crap on mobile and almost impossible to follow as a result.

Seeing badly formatted code snippets without color highlighting in article called "21st Century C++" somehow resonates with my opinion on how hard to write and to ready C++ still is after working with other laguages.

This honestly looks like C++ being feature-juryrigged to a degree that it doesn't even look like what C++ is: a c-derived low level language.

Everything is unobvious magic. Sure, you stick to a very restricted set of API usages and patterns, and all the magic allocation/deallocation happens out of sight.

But does that make it easier to debug? Better to code it?

This simply looks like C++ trying not to look like C++: like a completely different language, but one that was not built from the ground up to be that language, rather a bunch of shell games to make it look like another language as an illusion.

Yeah, I didn't have a problem keeping my shit straight in C++ in the '90s. The kitchen-sink approach since then hasn't been worth keeping up with. The fact that we're still dealing with header files means that the language stewards' priorities are not in line with practical concerns.

I definitely wouldn't have used "<<" in an "ad" for C++ :)

(I must say that I was happy to see/read that article, though)

21st century C++? AKA Rust?

Unfortunately, Rust is significantly less expressive than C++ and therefore is unlikely to replace it for high-performance systems code. As much as I don’t like C++, it is very powerful as a tool. The ability to express difficult low-level systems constructs and optimizations concisely and safely in the language are its killer feature. Once you know how to use it, other languages feel hobbled.

C++ doesn't allow you to express low level systems constructs concisely and safely though. You usually get neither.

Look at the first example in the article, where the increment can overflow and cause UB despite that overflow having completely defined semantics at the hardware level. Fixing it requires either a custom addition function or C++26, another include, and add_sat(). I wouldn't consider either concise in a program that doesn't include all of std.

This assumes you are writing C++ in the most naive way possible. I’m sure some people do that but nothing requires it. The capabilities of a language are not defined by its worst programmers.

Modern C++ allows you to swap out most features and behaviors of the language with your own implementations that make different guarantees. C++ is commonly used in high-assurance environments with extremely high performance requirements, and it remains the most effective language for these purposes because you can completely replace most of the language with something that makes the safety guarantees you require. This is rather important. For example, userspace DMA is idiomatic in e.g. high-performance databases kernels; handling this is much safer in C++ than Rust. In C++, you can trivially write elegant primitives that completely hide the unusual safety model. In Rust, you have to write a lot of ugly unsafe code to make this work at all because userspace DMA isn’t compatible with a borrow checker. There can always be multiple mutable references to memory but it is not knowable at compile-time, safety of an operation can only be arbitrated at runtime.

Of course, it is still incumbent on the developer to use the language competently in all cases.

    The capabilities of a language are not defined by its worst programmers.

Is the implication here that Bjarne is a bad C++ developer? If the person in charge of the EWG fails "to use the language competently in all cases", what hope is there for the rest of us mere mortals?

For what it's worth, unsafe Rust is safer than C++. There's very little UB to explode your carefully crafted implementations. Safe rust of course has no UB except for what you write in unsafe blocks, so it's safer still and there's no real difference in the abstractions you can write with concepts vs traits.

I'm not actually arguing for rust here though, because this isn't a great showing for it. Trying to write the related add_wrap(T, T) function in rust is stupidly verbose compared to add_sat(T, T) thanks to bad decisions the num_traits authors made. What I am saying is C++ isn't a form of high level assembly like your original comment suggested. Understanding the relationship between the language and the hardware takes a lot of experience that most people don't use when writing code.

UB is a feature of the standard, not the implementation. Many of those behaviors can be defined. Modern C++ conveniently allows you to replace many of the bits that have UB, per standard, with your own bits with defined behavior with zero overhead. This was not always the case. You aren’t dependent on the compiler implementor. The ability to consistently do this transparently became practical around C++17 IMO. The C++ standard library is in many regards obsolete and many orgs treat it that way.

I never suggested that C++ was “a form of high level assembly”. I’ve written enough assembly and C to know better; you lose a bit of precision with C++. But now I can define (or not) the behavior I want in a way that is largely transparent. This has been a brilliant change to the language.

If you have a foundational library that makes different and/or explicit guarantees than std, it is pretty easy to police that in a code base with automation. Everyone doing high-performance and/or high-assurance systems is dragging in few if any dependencies, so this is practical. The kinds of things that C++ is really good at for new code are the kinds of things where this is what you would do regardless.

Developers don’t even have to be hardware experts, they just have to not use std for most things. That is a pretty low barrier. And std is a mess with the albatross of legacy support. Reimagined C++20 native “standard” libraries are much, much cleaner and safer (and faster).

Legacy C++ code bases aren’t going to be rewritten in a new language. New C++ code bases can take advantage of alternative foundations that ignore std and many do. Most things should not be written in C++, but for some things C++ is unmatched currently and safer in practice than is often suggested with basic hygiene.

    Modern C++ conveniently allows you to replace many of the bits that have UB, per standard, with your own bits with defined behavior with zero overhead.

Okay, let's continue the example. Please demonstrate how to replace the addition operator on a primitive type. You can't within the confines of the language and that's a good thing in most cases. What you can do is pass -fwrapv, except that MSVC doesn't officially define a comparable flag.

    Developers don’t even have to be hardware experts, they just have to not use std for most things.

Signed overflow isn't a problem with std, the solution to it is in std. Null pointers aren't a problem with std, but the recommended fixes are again in std. Etc.

    If you have a foundational library that makes different and/or explicit guarantees than std, it is pretty easy to police that in a code base with automation.

As far as I'm aware, neither folly, absl, nor boost define custom integral types with defined overflow behavior. Please provide examples of anyone doing that.

    UB is a feature of the standard, not the implementation. 

If you're writing "high assurance code", surely you're writing to the standard and not the implementation? The implementation's guarantees change with every upgrade, every new flag, and each time you build for different targets. I certainly try to avoid compiler assumptions as someone who writes safety critical code.

DMA being a problem appears to be mostly a problem with a lack of identification of the data. If the shape of the data could be verified by the language runtime, instead of being an arbitrary stream of bytes whose meaning must be known by the recipient without any negotiation, this form of unsafety would disappear, since the receiving code simply needs to assert the schema, which could be as simple as checking a 32 bit integer.

Then all you need to do is also verify that the sending code adheres to the schema it specified.

This has very little to do with borrow checking. From the perspective of the borrow checker, a DMA call is no different from RPC or writing to a very wide pointer.

In Rust you get panic instead. You need to wrapping add which is a separate function

Most high performance code is vectorized and Rust is better at autovectorization and aliasing analysis than C++, so I'm not really seeing your point.

Having to drop down to intrinsics early is not a strength.

hm, I'd be concerned about relying on autovectorization. How much better is 'better'? Compiler friends have told me that something permute-heavy like sorting is unlikely to soon work, if ever.

My biased opinion, from doing this full-time in C++, is that the C++ SIMD story is much further along, especially regarding mature libraries.

Tangential question: is there a Rust equivalent for the book “The Design and Evolution of C++”?

There is not.

I have often thought about writing something vaguely similar. We’ll see if I ever do. It wouldn’t be the same because I don’t hold the same position Bjarne did in the early days, but I am very interested in Rust history, and want to preserve it. It wouldn’t be from my perspective rather than from the creator’s perspective.

I did give a talk one time on Rust’s history. It was originally at FOSDEM, but there was an issue with the recording. The ACM graciously asked me to do it again to get it down on video https://dl.acm.org/doi/10.1145/2959689.2960081

I would 100% buy a hardback gold embossed version of this book.

Well if I could make it half as good looking as Crafting Interpreters, maybe I’d manage to make it happen, hahah.

I’m mostly focused on jj with my writing right now, but we’ll see…

Thank you. It would be interesting to read the history, including the design decisions, the influences (and distractions), the trade offs, etc.

When I read “The Design and Evolution of C++”, it gave me a better understanding of the language.

Just reading the first 1/5 of this made me bored. I started my career with C++, being heavy into it for 10 years. But I've been doing Swift for the last 10 at least. I had a job interview last week for a job that was heavy C++, with major reliance on templates and post-C++ 11... and it didn't go well. You know what? I don't give a shit.

It's crazy that with that amount of experience you wouldn't get the job, just because you lack some modern C++ info in your brain's memory. Stuff you could search for or ask an LLM in 5 seconds (or even look up in a freaking physical book). You'd probably be fully up to date within a few weeks.

Says a lot about the people hiring imo. Good luck to them finding someone who can recite C++ spec from memory.

If you last worked on Pre templates C++ and now need to work on a template heavy codebase you are effectively writing in a different language. I don't think it will be a few weeks of catching up.

Wow, that must be a very long time ago. Templates were around when I started (if I remember correctly), or soon after.

Which reminds me of something I hate more than header files: macros.

Ha, thanks, and obviously true. But I can understand companies wanting people who can just march into their codebase and "hit the ground running," I guess.

I don't need the stress anyway. The dough would've been nice, though...

Let us know when C++ gets rid of the mess that is header files.

Until then... YAWN.

The article does mention modules.

But it doesn’t mention that you can’t actually use modules without passing a bunch of random compiler flags and hoping that they work.

> [M]any developers use C++ as if it was still the previous millennium. [...] C++ now offers modules that deliver proper modularity.

C++ may offer modules (in fact, it's been offering them since 2020), however, when it comes to their implementation in mainstream C++ compilers, only now things are becoming sort of usable with modules still being a challenge in more complex projects due to compiler bugs in the corner cases.

I think we need to be honest and upfront about this. I've talked to quite a few people who have tried to use modules but were unpleasantly surprised by how rough the experience was.

Ya that is rather disingenuous, modules aren't ready, and likely won't be for another 5 years.

Also they are difficult to switch to, so I would expect very few established projects to bother.

Modules were known to be difficult to implement and difficult to migrate to. If modules are mainstream in 5 years, it would be an excellent result.

Office is one of such established projects.

loving he goes 'int main() { ... }' and never returns an int from it. Even better: without extra error / warning flags the compiler will just eat this and generate some code from it, returning ... yeah. Your guess is probably better than mine.

If the uber-bean counter, herald of the language of bean counters demonstrate unwillingness to count beans, maybe the beans are better counted in another way.

Well, actually... the "main" function is handled specially in the standard. It is the only one where the return type is not void and you don't need to explicitly return from it - if you do it, it is treated as if you returned 0. (You will most definitely get a compiler error if you try this with any other function.)

You might say this is very silly, and you'd be right. But as quirks of C++ go it is one of the most benign ones. As usual it is there for backwards compatibility.

And, for what it's worth, the uber-bean counter didn't miss a bean here...

To me, it's kinda funny that he starts with

> using namespace std

something you get told not to do easily! :D