Writing this on a debian machine, and trying "g++ --std=c++23 -fmodules-ts" does not work, and from https://en.cppreference.com/w/cpp/23 looks like the "paper" for this is P2465R3, for which clang++ 17 has "partial support". I apt installed clang++17, and it still didn't work, complaining "module 'std' not found"

I understand that "import std;" is a very new feature and not "finalized" or whatever, but this book is supposed to be for beginners to C++; I wonder how the average beginner would react to that?

(I found the same thing a year or two ago when reading "Tour of C++")

  "_Standard Library Header Units_
     The Standard Library is not provided as importable header units.
     If you want to import such units, you must explicitly build them
     first.  If you do not do this with care, you may have multiple
     declarations, which the module machinery must merge--compiler
     resource usage can be affected by how you partition header files
     into header units."

Nevertheless, I do not expect that the updating of the standard C++ library of gcc will take a long time, so later this new book will become directly usable as it is.

For someone who already knows older C++ and just wants to update their knowledge, writing the corresponding module files can be a good learning experience in itself.

But mostly, it's not realistic to directly wire up calls to g++ anymore outside of research examples. Note that other compiled languages use systems like gobuild, cargo, Maven, etc. instead of fiddling with gccgo, rustc, javac, etc. directly.

https://www.kitware.com/import-std-in-cmake-3-30/

Now, I'm pretty sure you know that, hence my confusion...

The idea that "QtCreator" is some totally independent IDE that just coincidentally happens to have the letters Qt at the beginning in the same way that Java and JavaScript are independent of one another, but otherwise has no relationship to Qt the library is just patently absurd HN pedantry.

That's not what I was trying to say. I just thought it's worth pointing out that QtCreator is really a general-purpose C++ IDE. (It's my favourite C++ IDE, btw.)

Visual Studio is also a general-purpose C++ IDE and yet I don't think anyone would say it's independent of Windows.

You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid.

I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.

We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.

I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate.

Reading a soup of std::this, std::that, std::foo, std::bar is so difficult to parse through. Especially if you're like me and you sound things out in your head, which I recently learned is not how everyone reads.

The only justification for writing all those std::'s is because compilers can't disambiguate names from their context, but you're not going to find a human who comes across a use of vector, or sort(...) and throw their hands up in confusion wondering what was meant.

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.

This to me seems like a cargo cult justification, where you've heard the argument that descriptive names are helpful for readability, so we should name our variables in a way that conveys their intention as opposed to 1 letter names or obfuscated abbreviations, but instead of genuinely understanding the principle behind the rule, you think the rule is simply that it's better to have long names over short names.

Descriptive names that can be used to disambiguate variables from one another on the basis of their purpose... yes, please do that. Writing long names just so that they are long, especially by giving everything a shared prefix like std::... no, that's a misunderstanding of the justification behind the rule.

It's similar to that saying along the lines of when a principle becomes a metric, it ceases to be a useful principle.

Bjarne's book seemed to be a comprehensive introduction and I'm currently going through it. I found that adding "using namespace std" at the beginning of the file reduced some of C++'s syntactic overhead that a beginner such as myself has to account for. It allows me to focus on the essential by learning the programming principles, rather than getting stuck on the syntax and having to (annoyingly) repeat std:: every line.

Nevertheless, I think every beginner should know the disadvantages of setting the namespace at the beginning of the file and that no one should use it in production code, but it does its job at keeping things simple if I'm just starting out with C++. There is a reason why Bjarne does this in his book, and I can see why.

Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day.

I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ...

Of course consise code is nice, and while you're in the heat of development it's easy to pretty much memorize an entire codebase, even a large one, but it's when you have to come back to it years later, and barely even recognize the code as your own, that you'll be happy it's self-documenting. Now, on a large team that "future self" may just be the new hire, or the guy who replaces you when you quit ...

>I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ...

But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names?

If it's that long names are better than short names, then by all means continue using std:: everywhere. If instead it's that descriptive names that communicate purpose or intention or actual information are better than non-descriptive names, then having a bunch of std:: everywhere doesn't do much of anything to help readability, it just adds noise.

Now people can and do justify the use of std:: but I've never heard it on the basis of making code more readable. There is nothing self documenting about a bunch of names that all share a common prefix.

And this doesn't even touch on how ironic it is that std is itself non-descriptive jargon that is an abbreviation of standard, but I am almost certain that if everyone had to liter their codebase with standard:: everywhere, no one would think twice about what the right thing to do is.

Do you always suppose that the people you are talking to are morons and cargo-cultists?

Rhetorical question - have fun.

I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming".

I don't think there is anything wrong with getting into the subtleties of whether the advice is what you originally said it was, which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names.

I think the subtlety between those two statements is not being appreciated and without a clear distinction other people may read that advice and take away the wrong conclusion.

Take care.

Are you even a developer?

In the programming world "longer names" is universally understood (except apparently by you) to mean "longer due to being more descriptive". NOBODY thinks that making identifier names longer just for the hell of it beneficial.

It's as if a chess player is describing to you the importance of controlling the center of the board, and you are wondering out load if they mean controlling it by clamping it to the table.

Perhaps you think suggestions like this make you sound smart. They don't.

If code I write today has a class called bubble_sorter, and then one day, the C++ standard library decides to add std::bubble_sorter, then:

1. If I had "using namespace std;" then all of my code is suddenly broken.

2. If I didn't have it, I'm fine.

Also, and this is just personal preference, but I simply like to be able to clearly distinguish when my code is calling into the standard library. Typing in that short "std::" reminds me that I am calling into someone else's code.

If this happened and if you included that specific header, you would get a simple compiler error due to ambiguous methods. Then you can simply add a namespace somewhere and move on. I know sometimes this can involve a lot of changes (if we're talking about other `using namespace ...` usage) but in general you're not gonna have problems.

If you're really worried about this, you can move the statement closer to where you need it. This is very helpful for dense code that you normally want to be verbose.

Certainly time to enter code (which is increasingly going to be automated) should be the last consideration - if we're considering full software lifecycle then coding probably takes up some small single-digit percentage of the time we're interacting with the code.

However, most code is not that obvious, and in the real world you're probably not looking at one mystery line of code who's function becomes obvious by context - you are more likely looking at entire functions or blocks of code, maybe without comments, trying to figure out what is going on. Try inheriting 10K of mostly undocumented code, and then you'd probably be a lot more grateful that the original author used descriptive names and comments, even though he knew what it all meant when he wrote it.

Did they? C, Lisp, Rust, Python, Ada, Go, Java, C#, ...

They all require you to qualify conflicting names if some other characteristics (for instance the number or types of arguments) don't provide enough information, or outright don't permit it (C, since it has no notion of name spaces).

Can you point to the "every other language[s]" which have solved this problem?

And with those C++ namespaces you can do `using some_namespace::some_specific_name;`. Which resolves the issue just like in those other languages.

  def foo(n):
    return n + 2
  def foo(n):
    return n * 2
  foo(3) # which one is called?

It's still a name clash at compile time.

BeOS probably had the nicest looking API. Let's hear it for is_computer_on_fire()

Oh come on now, about 7.5k of those lines are comments and/or blank lines. Furthermore, a good chunk of the code is devoted to type checking, thorough error handling, compiler compatibility and/or workarounds, etc, all within the restrictions of C++11.

… bundled in a single header as the one true distribution format.

Yes, build systems are a significant pain point for C++ and C. Many users prefer to largely avoid the issue and use header-only libraries. That said, Conan and vcpkg are making genuine strides at improving the issue.

I note the CI cmake script at a thousand lines of cmake.

This is ridiculous. It’s a CI script running multiple test suites over dozens of compiler versions, of course it’s going to be a lot. Would it make you feel better if that CI script didn’t exist? If not, then what’s the “correct” size for CI script?

That's a very idiomatic representation of a C++ library, thank you for the example.

The library is genuinely good. It’s portable, well tested, user friendly, and widely supported. Your snark is unwarranted.

If I have an existing JSON file that I want to quickly parse for a demo project there is almost zero chance I would pick C++. In comparison, Python is already installed in many environments and has built-in json parsing.

One of the first things I did when I got my PiDP-11 which can run RSX-11M and the DEC fortran compiler. I spent many many hours programming in Fortran when I was in college and thought wow I could relive some of that, about 5 minutes in I was "okay, step slowly away from the console." :-)

I really wish there were more string util functions in Cpp. I mean C had strtok()!

Sure the builds are slow and Python _kinda_ has static typing, but rust just has a lot of stuff I like and it's practical to install and use natively without learning all the jargon like venvs and eggs and wheels and which package manager and package manager manager (rye?) to use this year

I tried Python years ago and never got the motivation to push through that learning curve. I've used c++ a lot but it always required me to "keep my hands inside the ride at all times". Rust feels like it actually wants to be easy to use

I can understand not wanting to use Python for everything, but I see the problem being the 'use it for everything' not the language choice.

Use the tool that excels at the job. There is no language that is good at everything.

Some that come to my mind: its versatility binding native code and its easy-to-fit in your brain mental model for many tasks. The fact that you can script with Python without a compilation step also helped a lot to spread its popularity I think.

I'm indifferent when it comes to Python vs Rust for scripting, but I'd take Rust over a shell script (of any variety) any day.

It's also totally impractical. Rust isn't the only language I haven't tried; there are more than a thousand of them. I'm not using JOVIAL for scripting, or Fortran, or a bunch of others. No, I haven't tried any of those either. No, I'm not going to.

Turning specifically to Rust, I don't use it for scripting because it's not what I look for in a scripting language. It's compiled; I look for a language that doesn't have that extra step. It has the borrow checker; I don't write scripting code that needs that level of discipline and care.

In fact, most of my scripting is of the form "pick some bits out of a text file". For that, Perl is my tool of choice. Sure, other languages have regexes. None of them do it as cleanly and simply as Perl. (Note well: "clean" does not apply to the Perl syntax...)

The actual language is not awful. Some features are even nice, like infinite precision integers by default, and separate / and // operators.

Language is ok. Setting everything up is atrocious.

The other quite annoying thing is that the docs are extremely badly organised so Google rarely points you directly at what you want. Instead you get stuff like w3schools which is trash, but much better organised. Also annoying that the docs still don't include types.

I would use Typescript (via Deno), Go or Rust instead. There are some other Python replacement languages I haven't tried yet that might be an option like Mojo, Lobster, Nim. Probably still too niche for production; I'd stick with Typescript.

I'm sure, but it also sounds like it will take about 2 weeks of reading manuals and learning Nix before I'll get to the same point as Rust and Go start at.

And that's not really an option for big teams, which is the only situation where I'm forced to use Python anyway.

I once heard that the C++ language contains 4 components: the first catalog is "C", the second is for OOP, the third is for productivity and flexibility such as stl and templates, and the last one is for special cases such as volatile, asm, etc. He then recommends to use catalog 1 with care, and avoid scenarios that one has to use catalog 4. Does that make sense?

This is fine if you do not plan to share your work with others, but it's not well-written C++. It will bite you later on. It's best to learn the C++ way of doing things. It will save you so much time and headache. Don't use character arrays, use strings. Don't use C arrays, use std::vector or std::array. Don't write your own lists or sets, use std::list/set or std::unordered_list/set. Don't use strcat when std::string operator + exists. Etc.

I personally rarely use smart pointers or make_shared/make_unique these days. I just don't need pointers. Most of the time allocation can be done without them, and when I need to pass things around I use references. There are exceptions for C APIs for cross-platform/cross-compiler work, of course. And sometimes library code needs it, ofc.

The STL and are your friend. They solve so many problems in a very elegant way. Learning them should be a priority.

I'd go easy on the OOP elements unless you know OOP programming very well. Just using classes as containers for data and functions is more than fine for C++ most of the time.

Writing your own templates can be a bit of a footgun until you understand them. Feel free to put that off awhile.

Don't mess with volatile and asm unless you are 100% sure that what you're doing needs it.

Also: Be cautious with use of auto. A bit here and there is fine, but too much and code can become unreadable. C++ is a typed language for a reason.

If that paragraph doesn't make any sense, and you think you need volatile then there are basically two possibilities: You're writing a Java program (which uses that keyword for something else), or you need std::atomic (or __sync_* for C) instead.

Yes, although one place where "auto" should almost always be used is to declare iterators (not that one should be needing them so much nowadays), and I think harmless for range-based for loops "for (auto i : v)" although as you say there's definitely a convenience/readability trade off.

1) The major part of C to avoid is raw pointers and malloc, and generally anything where C++ has a more modern alternative. Don't use C datastructures (pointers, strings, arrays) where C++ replacements exist (smart pointers, std:string, std::array and std::vector, etc), or use C libraries where C++ replacements exist (e.g. C++ std::string vs C's string.h).

Of course you can't avoid all of C, since the syntax of C++ is an extension of C.

2) I wouldn't characterize what C++ adds to C as OOP. OOP is a design methodology, whereas the main addition C++ gives you is classes which are better thought of just as powerful and convenient type of data structure.

The core feature of classes you always want to use are constructors and destructors. Any initialization of the class's data members should be done in the constructor (don't leave things uninitialized), and any final cleanup (releasing memory or locks, closing files, etc) should be put in the destructor so that it always happens (even if your program throws exceptions).

Don't feel that just because classes support subclassing, polymorphism (virtual methods), etc, that you should be using them. They are there in case you need them, but if in doubt don't.

3a) The STL is just the standard library for C++. You should always be using STL data structures (std::string, std::list, std::vector, std::map, etc) when applicable - not just "for productivity".

3b) Templates (template classes, constructors/methods, functions) are not needed for most everyday use of C++. They are there for library writers, and on occasion for writing your own class and libraries. Think of them a bit like class inheritence - they are there in case you need them, but not something you should be reaching for unless there is no better way.

4) C++ has a LOT of stuff (esp. libraries) that might be considered as "for special case use only". A rookie mistake might be to think that C++ has all this stuff - I should be using it! In general you should ignore the obscure stuff, and only use it when some special circumstance requires it.

The Standard Template Library is Alexander Stepanov's generic programming achieved via the relatively new (at the time) C++ Templates feature. At this point (the late 1980s through early 1990s) Generic Programming is an obscure academic idea, it's not how normal software works. Stepanov is persuaded to present his library to WG21 ("the committee") in 1993 and their work is eventually standardised as C++ 98 a few years later.

The most important part of the STL is the algorithms, generic algorithms are an amazing idea. The collections, eh, they're nothing to write home about, there are a dozen takes on the iterator problem with different trade-offs, but this idea of generic algorithms unlocks so much power and that's why lots of languages grew generics or for new languages had them on day one.

Newer languages and modern C++ favor composition instead. You define interfaces that provide some well-defined capability, and then you write things that wrap the interfaces to provide additional functionality. In C++ you can use templates to do this without any runtime overhead. In C, you can either use preprocessor macros (ouch) or you can build your own vtables. The vtable approach adds virtual method invocations all over the place, so it's not zero cost.

The C++ approach actually isn't zero-cost either: You can end up having many copies of the same template logic, which blows up your instruction cache. One of the big innovations of swift was to avoid that. As far as I know, Rust macros and "go generate" produce binaries that are closer to the C++ approach.

Anyway, especially for emulators, you should look into getting good with C++ template meta programming, or just learn rust and then use its implementation of generics. Both approaches will let the compiler inline the heck out of stuff that ends up in the inner loop. In particular, clang + gcc are both good at constant propagation.

One problem with jumping straight from C to rust is that you basically have to already be able to write stable C++ code in order to get it to compile at all. The borrow checker moves subtle but common C++ errors from runtime to compile time. If you have a lot of experience with C already, the jump might be OK.

(edit: I should add that C++ isn't standing still, and there are lots of cool efforts to backport the good ideas from Rust to it. Systems language competition is a good thing, and they're my two favorite languages!)

linkers have been able to perform identical-code-folding optimizations for a few decades now

Without having to squint, 12 of those languages are easily categorized as OO languages. Given the mindshare of those 12 languages, I don't think it makes sense to say that "OO programming is mostly frowned upon." [emphasis added] Maybe it's frowned upon by some, maybe even many, but if it's mostly frowned upon then a lot of people must hate their work.

Only in certain circles. For the software world as a whole, "mostly" is rather an overstatement. (For that matter, for the software world as a whole, "mostly" is an overstatement no matter what claim follows the "mostly".)

> OO added the idea of implementation inheritance to interfaces, and that's mostly a bad idea.

There is more than one flavor of OO. Not all of them support implementation inheritance. You're using a feature of a sub-part to complain about the whole. (In fairness, though, this is a thread about C++...)

Current best practice is "prefer composition over inheritance". There are places, though, where inheritance is the correct answer. When you hit those places, use it. Where it's not, don't use it.

Just tested, works fine with Safari (mobile, but desktop usually has the same behavior).

Chrome's attempt to use a secure connection resulting in 404 while the actual link works fine isn't great. But it's understandable and the TLS-first assumption the're using probably works just fine in the other 99.999% situations.

If only they'd taken the time to copy the http config and setup let's encrypt or cert from GEANT Vereniging CA apparently preferred by rug.nl...

It's such a good book. If you really take the time to understand the book C++ it seems kind of sad the world was so afraid of it.

But of course after all this I of course met an army of people who had never read a book like this at all and wrote horrifying C++ code.

2nd edition:

Paperback ‏ : ‎ 1312 pages

Item Weight ‏ : ‎ 4.81 pounds

3rd edition:

Paperback ‏ : ‎ 656 pages

Item Weight ‏ : ‎ 2.71 pounds

"The third edition of Programming: Principles and Practice Using C++ is about half the size of the second edition. Students having to carry the book will appreciate the lighter weight. The reason for the reduced size is simply that more information about C++ and its standard library is available on the Web."

Even if you're an experienced programmer or have no interest in C++ you should still read this book.

It's one of the best examples of technical writing and teaching computer programming that I'm aware of.

I recently started at a company with a bit of a hairy c++ application that I would love to refactor or understand more thoroughly. Is this book a good place.

Note that I have read a very basic book on C++ much more learning programming book, but got me introduced to the memory management concepts.

As well I've been getting through Effective C++: 55 ways..., but this seems more like a tips and tricks and I don't think I'm getting much out of it.

If you want to work on your "hairy c++ application" you'll benefit from understanding how "modern c++" it is (and what your toolchain supports).

Meyer's effective books are good with two caveats: first, they are really meant to improve practice for people who are already working in the language (e.g. don't do it that way, and here's why). Second, the older ones are now dated and some advice need updating to work with newer language spec.

If 3rd edition of this one lives up to previous, it should be a pretty good read but as others have mentioned the "Tour of C++" book is a good entry.

Any recommendations?

If you just started learning C++, why did you choose it instead of another language? (Rust, C#, Go, etc)

I know a bit of C but feel that the sheer "thickness" of C++ is too daunting and scary to even start.

On the other hand, if you don't need these "hard-core" features then any language will do. In fact, most of these have Python or other language interfaces so you don't need to know much C++.

You won't get "extreme performance" from C++ because it is buried under the weight of decades of compatibility hacks.

This doesn't even make sense. What is an example of something that can't be fast because it is done in C++? What "compatibility hacks" are slowing programs down?

This does not sound like something someone with experience in C++ would say.

Let's look at two very different perf leaks in ISO C++. Firstly move assignment which is right at the heart of the language. Initially C++ doesn't have move semantics at all, which is a problem because in a bunch of cases that's key to "extreme performance". So in the "lost decade" period between C++ 03 and C++ 11 considerable work was done to figure out a way to unlock this, but of course C++ insisted on backwards compatibility with the code written for C++ 98 with no such semantic.

The result is that the actual move semantic people wanted can't quite be done, this is now called "destructive move" and proponents of the compatible option C++ 11 and later had claim it's equivalent to the move they delivered, plus delete. But that's... disingenuous. The C++ 11 move is actually (move + create), so to build "destructive move", when that's what you need, you must write (move + create) + destroy. Sometimes the compiler can see what's happening here and emit the same machine code you'd get in a language with native move semantics, but sometimes it has no way to figure this out, and you're emitting move + create + destroy, which is markedly slower as well as of course being more error prone.

Secondly right up at the surface, where we can feel the rain, and appropriately something Bjarne Stroustrup (author of the book we're talking about here) has noticed himself, the provided growable array, std::vector lacks the bifurcated reservation. Vec::reserve_exact isn't enough, you need Vec::reserve as well for good performance with a growable array API, but C++ doesn't provide this, it provides only Vec::reserve_exact under the name "reserve" and there's no room to offer both in the compatible API, which means as a user/ application programmer this fundamental type is a small perf leak.

Bjarne shrugs this off, oh well, just don't use the reserve API to get performance benefits. But everybody else can do so, this choice means C++ is leaving it on the table for somebody else with a better growable array type.

Finally though, I want to look at a beacon over the horizon, where "extreme performance" really is something they're thinking about. Iterator Loops (sometimes "Chunk Loops") are a technique where the language lets you directly express in your definition of a loop how it can be performed in a SIMD-fashion, so e.g. you write the code to search an N byte buffer for the byte you're looking for, but then revisit that loop and also write code for searching N=M*16 bytes, using 16 bytes at once. This lets you write, in a high level language, code which will be easy for a compiler to SIMD accelerate without fragile idiom recognition. C++ of course does not provide Iterator Loops and instead you'd reach for manual inline assembler in these cases today.

That's not C++ any more, you can inline assembly into several other languages for whatever that's worth, which isn't much in this context. "But I could use assembly language" is no more C++ having "extreme performance" than "But I could book a minicab" would give the London Underground "24/7 service".

Vec::reserve_exact isn't enough, you need Vec::reserve

Reserve reserves the amount that you give it. This isn't hard or complicated. What exactly do you think it should do differently, and how hard would it be to write your own? Vector is a simple data structure. Anything you don't like about it isn't a language limitation.

this fundamental type is a small perf leak

Show me a program that illustrates what you are talking about.

I want to look at a beacon over the horizon,

You can do this with intrinsics or libraries that use intrinsics.

the language lets you directly express in your definition of a loop

This isn't a performance limitation it's a convenience you want integrated into the language. There is one that does this, it's called ISPC. Is that what you use?

This seems to me like you've gone down some sort of anti C++ rabbit hole where people who don't know what they're doing get worked up about things that don't matter.

Meanwhile in the standard library there is actually the unordered_map design which is stifled by algorithmic complexity requirements, but people use flat maps to get around that.

I'm sure, and yet the people who care have noticed that C++ is slower, that's what P1144 and P2786 and so on are trying to solve, without quite saying "destructive move" out loud.

Here's the current iteration of P1144: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p11... Like pointer provenance this is something WG21 would prefer not to think about because it's embarrassing, so it has hung around like a bad smell for quite a few years but I suspect (unlike provenance work) it'll get into C++ 26 in some form.

> Reserve reserves the amount that you give it. This isn't hard or complicated. What exactly do you think it should do differently

It's OK, after all Bjarne Stroustrup didn't see this either, but you've missed something quite important

The whole idea of this type is amortized constant time growth, typically via doubling although any fixed ratio would work and there could be a benefit to choosing other ratios in principle (Folly has a long paper about this). For this purpose it's crucial that capacity doesn't grow linearly. But if our only reservation mechanism is Vec::reserve_exact (aka C++ reserve) we end up with linear growth. Bjarne's solution is to abandon use of reserve for performance, but we can do much better by just bifurcating the API as Rust did (and as some other languages do)

I started writing a program to illustrate this, but it's probably easier to just spell it out with an example. Suppose we receive Doodads over the network, they arrive in groups of say up to 20 Doodads at a time, and we don't know in advance how many there will be, until the last group indicates it's the end of the Doodads. Typically in total there's maybe 40-50 Doodads, but there can be as few as five (one group of just five) or as many as a thousand. We're going to put all the Doodads in a growable array as we receive them. Let's walk through receiving 19, 14, 18, 12 and finally 6 Doodads.

Bjarne says don't bother with reservation as in C++ this doesn't work for performance, so we just use the "natural" doubling. Our std::vector allocates space for 1, 2, 4, 8, 16, 32, 64 and finally 128 Doodads (eight allocations), and does a total of 127 copy Doodad operations. Surely we can do better knowing what's coming?

If we ignore Bjarne's advice and use C++ std::vector reserve to reserve for each group, we allocate space for 19, 33, 51, 63 and finally 69 Doodads (five allocations), and we perform 19 + 33 + 51 + 63 = 166 copy operations. Fewer allocations, more copies.

If we have the bifurcated API, we allocate space for 19, 38 and 76 Doodads (three allocations) and we do 19 + 33 = 52 copy operations. Significantly better.

> This isn't a performance limitation it's a convenience you want integrated into the language

I disagree and the results speak for themselves.

> There is one that does this, it's called ISPC. Is that what you use?

I've never used ISPC. It's somewhat interesting although since it's Intel focused of course it's not actually portable.

> This seems to me like you've gone down some sort of anti C++ rabbit hole where people who don't know what they're doing get worked up about things that don't matter.

It's always funniest to read about what "doesn't matter" right before it gets fixed and suddenly it's important. The growable array API probably won't get fixed, education means that Bjarne's "Don't use reserve" taints a whole population so even if you fix this today it'd be years before the C++ programming community use reserve where it's appropriate but I expect "relocation" in some form will land, and chances are in a few years you'll be telling people it's why C++ has "extreme performance"...

† in the UK there was a discrepancy between what happens to the sort of teenager who exhibits talent and interest in an area like writing software, who is sent to just watch adults doing that and mostly doesn't do any actual work themselves as "Work Shadowing", versus those whose direction seems more... manual who are expected to actually go do stuff in the same period, supervised by adults of course, but still very much doing the actual work, "Work Experience". This seems very obviously unfair, although of course as the teenager who wasn't expected to actually do much I wasn't complaining at the time...

Thirty years ago the future was C++. How did that work out? Seems like it was pretty popular, this thread is about the third edition of a book about it.

No one learns all of C++, you just need to learn the bits that are useful for the kinds of applications you write. If, for example, you are building database kernels then you are unlikely to use any of the STL containers (even std::array and std::vector are infrequent) in most of the code. However, you will need to know how to manually fix-up object lifetimes using semi-obscure language features you would never need to know about for most server apps.

If you stay within a relatively narrow application domain, the useful parts of C++ for that domain crystallize pretty readily in my experience, which is much easier to learn.

That said, I sometimes get the impression that Bjarne recognizes the monstrosity that he created and a large part of his talks and his book is how to make use of the good parts of C++ without making use of the bad parts.

ken thompson wouldn't use it. then he invented go to spite him.