Ownership and lifetimes

It is clever to add links to other postings, and wholly invent remarks to pretend to quote from them. It is even more clever to invent things that must surely have happened before he was born. But it is not clear why anyone should try to tease out the few, lonely correct statements that accidentally appear in the roiling cloud of phantasms presented.

That's incorrect. You can get ODR violations by having multiple clashing template specializations, that can be in different parts of the application (for the added fun).

Back in MSVS 2006 days, I also spent several days debugging an issue where two inline functions (exempt from ODR) had different padding due to different compilation options.

Honestly, C++ is not growing rapidly. C++20 improvements were mostly in libraries and infrastructure around them.

The major language-level feature in C++20 are concepts, but they had to be cut down quite a bit. Coroutine support is at the barest minimum possible. Modules haven't made it either.

Newer compilers actually warn about ODR violations. Previously is was completely silent, so nobody knew how much they were violating it. I once compiled some random C++ program with such a compiler and I just sat and watched as the ODR violation warnings just scrolled by, on and on, endlessly.

So. "The difference between practice and theory is bigger in practice than in theory." (I think it's an old engineering saying.)

So, the Fact is that Stroustrup doesn't talk about ownership in that book. The much later (less than ten years old as I write this) Fourth Edition does talk extensively about ownership. Can't shut up about it actually. In some places, nearby text survives, or has been transplanted from earlier editions, but the talk of ownership is new. Why? Because of shared_ptr and unique_ptr which did not exist when the Second Edition was written. This inspires Stroustrup to explain even before introducing any C++ syntax at all, that programmers must "represent ... Ownership relationships" in their code. Which, in C++ 11 they now can try to do.

Throughout the Fourth Edition's "Tour" of C++, there are opportunities, taken or at least pointed out to the reader for their own benefit, to express Ownership. The Desk Calculator example explicitly tracks whether it owns the Input Stream it is using, offering methods to give it a reference (which it doesn't own) or a raw pointer (which it does) and clean up appropriately. Second Edition makes no mention of this, it too has a Desk Calculator example, but it doesn't bother with Input Streams, it just reaches inside the system's standard input and mangles that directly.

So, you're wrong, factually even if you firmly believe now that ownership has "always been understood and actively managed" it seems to have escaped mention by the language's father in their text intended to introduce the language _until_ decades later the language grew facilities to actually try to "actively manage" this problem.

Lifetimes are an interesting contrast. The Second Edition does spend a few paragraphs on this topic, but mostly the reader is encouraged not to think about it too hard. Objects begin living when they're Constructed, and this lifetime ends when their name goes out of scope whereupon they will be Destroyed. Except, that's not quite true and there are a few paragraphs trying to justify that before a reference to paragraphs later in the book about the Free Store.

By the Fourth Edition, lifetimes get their own sizeable Chapter in the much larger book, "Construction, Cleanup, Copy and Move". So I agree that by this point Stroustrup is aware that this is a problem, indeed that chapter uses words like "trap" and "mistake" and most sub-sections are accompanied by considerable verbiage basically encouraging the programmer to try harder not to get this wrong. But he doesn't have anything to really propose as a solution. Yet.

Today, Stroustrup has a proposed change to C++ to add actual lifetime tracking. I don't expect it will make it into C++ 23. You claim that Stroustrup "never, ever rants" but he seems quite animated when it comes to the committee not accepting all his ideas as quickly as he might like or adjusting them in ways he isn't pleased with, and equally animated about cutting down other people's proposals.

Just had to deal with this last week in fact. ODR violations are rampant when some dependency does not follow C++ "best practices" nor uses extra-language bits that are compiler/platform dependent (`__attribute__(visibility)` and `__declspec`).

One of our dependencies doesn't export symbols properly. Luckily, CMake has a way to say "le sigh, just export everything" on Windows to fix that problem. However, there's a deeper problem lurking in such a codebase: RTTI duplication. There are these simple interface classes that have their definitions completely in the header. Seems reasonable; header-only is fine, right? However, the source code of the library does `typeid` comparisons with a `std::type_info` that is passed in to see which of these interface types you're asking about. Because the complete definition (trivial `{}` bodies for the ctor and dtor with pure virtual methods otherwise) are in the header, every library that sees this declaration can say "huh, no export symbol? I can make it mine" and generate its own unique RTTI table for the type. The linker will resolve these together into a shared library boundary, but nothing resolves it across a shared library boundary at runtime, so you then get two different `typeid` blocks for the same type. Hilarity ensues when the dependency goes "yeah, I have no idea what you're on about, have a `nullptr`".

Now, C++ *could* have just standardized `export` or some other syntax to say whether a declaration "belongs" to the current TU's target or not, but that requires macros at compile time to know which library you're actually compiling for so things get linked up properly. And C++ *hates* talking about compilation strategies beyond "pile of TU outputs linked into a program" because it never bothered to reign in the madness from the beginning and now suggesting anything is likely to get somebody clutching pearls immediately. So, C++20 has modules where what is "in" and what is "out" can be more easily tracked with actual standard-compliant syntax, but this has been an issue since C's textual inclusion compilation model was a thing and only now we have a solution that requires rewriting all of your headers and leaving old, dumb `%.o: %.cpp` build systems behind anyways (because compiling C++20 modules is the same problem as compiling Fortran modules and everyone remembers how much fun that has been, right?).

OK, so language theory discussions are fascinating (thank you everyone) but now let's get real a bit. Let's pretend I'm managing a software team and I've been asked to get rid of most safety issues in the C++ codebase of our mission-critical application. What -Wold-unsafe-c++ compiler flag do I turn on to make sure my not-all-perfect developers don't make any mistake and stick to "modern C++"? If that compiler flag is not available, what static analyzer(s) should I use? I have practically unlimited budget so I don't mind commercial products. (Even an unlimited budget is unfortunately not enough to hire an elite team of C++ developers who never make any mistake)

> there is no worry about lunch.

I don't think anyone doubts C++ will still make a lot of money after even the youngest people in this discussion are dead, no reason to feel threatened.
There is a shortage of developers, not a shortage of code to write. Apparently you can still get paid to fix COBOL code:
https://www.theverge.com/2020/4/14/21219561/coronavirus-p...

Whether it's true or not, I'm afraid you don't realize how cultish that is perceived.