
Modern C++ Won't Save Us - neptvn
https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
======
jandrewrogers
A significant issue I have with C++ is that even if your code base is pure
C++17, the standard library is a Frankenstein's monster of legacy and modern
C++ mixed together that required many compromises to be made. A standard
library that usefully showed off the full capabilities of C++17 in a clean way
would have to jettison a fair amount of backward compatibility in modern C++
environments.

I've noticed that more and more people like me have and use large alternative
history "standard libraries" that add functionality, reimagine the design, and
in some cases reimplement core components based on a modern C++ cleanroom.
I've noticed that use of the standard library in code bases is shrinking as
result. You can do a lot more with the _language_ if you have a standard
library that isn't shackled by its very long history.

~~~
fooker
I don't see the problem. You are free to use such a modern library (Google
does, it's called absl).

The good thing here is that the standard library doesn't require 'magic' to be
implemented (unlike Swift where the standard library relies on hidden language
hacks).

~~~
nradov
Sure it's possible to use a non-standard "standard library". But at that point
you're already halfway to using a different language so why not consider
switching from C++ to D / Rust / Go?

~~~
ncmncm
The whole point of C++ is that it enables writing more powerful libraries,
capturing semantics in libraries that can then just be used. C++ is still
quite a lot more powerful for this purpose than Rust. Rust will get better at
it, over time, but it has a long way to go and C++ is not siiting still.

Rust is still a niche language, and if its rates of adoption and improvement
do not keep up, it will remain a niche language, and fade away like Ada.

I cannot imagine a serious programmer switching from C++ to Go. If you can,
you have a much livelier imaginary life than I do.

~~~
ajxs
The Ada partisans are all out in force here in this thread to defend Ada, all
four of us. haha... For what it's worth, niche as Ada may be, it's an
_important_ niche. It remains widespread in safety-critical applications, and
isn't going anywhere anytime soon. It's really good to see Rust taking lessons
from Ada/SPARK in the area of formal proofing! If any language is going to
threaten C++, it looks like Rust. I don't expect an Ada resurgence to happen,
unfortunately.

> I cannot imagine a serious programmer switching from C++ to Go. If you can,
> you have a much livelier imaginary life than I do.

This got a laugh out of me.

~~~
pjmlp
A large majority of Ada partisans found their corner in Java, C# and C++'s
type system improvements over C, and made the best we could from the sour
grapes of C's copy-paste compatibility.

~~~
ajxs
Calling myself an Ada partisan is a bit of a stretch. I've recently begun
using it for embedded development, which is a domain almost completely
dominated by C. That's the angle I'm coming in from.

~~~
pjmlp
It depends on each one naturally.

For me, coming from Turbo Pascal 3 - 6, it allowed me in 1993 to use a
language with a similar level of safety and language features, instead of
having to deal with PDP-11 constraints.

I was always the weird kid that asked the professors if I could deliver C
projects written in C++ instead, which thankfully some of them did accept.

Specially given that at my degree, C was already out of fashion by the early
90's. First year students got to learn Pascal and C++, and were expected to
learn C from their introduction to C++ programming.

------
namirez
This has been discussed extensively in the C++ community. I think if you need
a very safe code, you shouldn't use the string_view or span without thinking
about the potential consequences. These are added to the language to prevent
memory allocation and data copy for performance critical software.

Herb Sutter has concrete proposals to address this issue and Clang already
supports them: [https://www.infoworld.com/article/3307522/revised-
proposal-c...](https://www.infoworld.com/article/3307522/revised-proposal-
could-solve-longstanding-c-bugs.html)

~~~
tatersolid
> think if you need a very safe code, you shouldn't use the string_view or
> span without thinking about the potential consequences.

That’s the whole point: your caveat shows that’s it’s C/C++ which are _unsafe
in their very nature_ and therefore should not be used in code exposed to
potentially malicious (e.g. user or network) input. Which is just about
everything useful.

HPC are generally closed systems and have different threats, but the industry
just needs to run (not walk) away from C/C++ for the majority of use cases.

~~~
alfalfasprout
"which is just about everything useful". This statement is wildly without
merit.

Sure, for the typical user facing application HN readers talk about then C++
can certainly contain vulnerabilities that are worrisome. Many performance
critical applications can tolerate vulnerabilities in favor of latency.

It seems to me that the world of realtime systems including avionics,
autonomous control software, trading, machine learning, and more is "not
useful" as per your comment. The extreme low level control that C++ offers and
powerful metaprogramming allows for performance that even Rust cannot hope to
rival.

The industry _has_ moved away from C++ for plenty of these user facing use
cases. Codebases like Chrome and Firefox can't just be rewritten in Rust
overnight. You can try and rewrite eg; SSL libraries but that has its own host
of problems (eg; guaranteeing constant time operations).

I encourage the people parroting a move away from C++ to really think about
what it is that should move and what the pros/cons are. I think you'll find
that many of the things at risk (i.e user facing applications) are already on
their way to being rewritten in Go/Rust.

~~~
fulafel
> The extreme low level control that C++ offers and powerful metaprogramming
> allows for performance that even Rust cannot hope to rival.

Rust has vastly better metaprogramming, and as much low level control, no? And
many low-level things are well-defined in Rust, and undefined behaviour or
implementation-defined in C++.

~~~
comex
Depends. Some metaprogramming features in C++ are currently ahead of Rust
(values as generic parameters, generic associated types, constexpr, etc.), but
Rust is ahead in other areas (procedural macros) and is working on parity in
the other cases I mentioned. Meanwhile, Rust has none of C++'s legacy cruft,
and its typed, trait-based generics are arguably a better foundation for
metaprogramming than C++'s "dynamically typed at compile time" template
system.

------
pjmlp
It is true, C++ has several warts some of them caused by the copy-paste
compatibility with C.

Which is both a blessing and a curse. A blessing as it allowed us
Pascal/Ada/Modula refugees never to deal with what was already outdated,
unsafe language by the early 90's.

But also makes it relatively hard to write safe code when we cannot prevent
team members, or third party libraries, to use Cisms on their code.

Regarding the alternatives, Swift is definitly not an option outside Apple
platforms. And even there, Apple still focus on C++ for IO Kit, Metal and LLVM
based tooling.

Rust, yes. Some day it might be, specially now with Google, Microsoft, Amazon,
Dropbox,... adopting it across their stacks.

However for many of us it still doesn't cover the use cases we use C++ for, so
it is not like I will impose myself, the team and customers, a productivity
pain, take the double amount of time that it takes to write a COM component or
native bindings in C++ for .NET consumption just to feel good.

When we get Visual Rust, with mixed mode debugging, Blend integration and a
COM/UWP language projection for Rust, then yeah.

~~~
masklinn
> It is true, C++ has several warts some of them caused by the copy-paste
> compatibility with C.

I mean that's a bit of a cop-out given C++ has more non-C warts and UBs than
it has C warts and UBs at this point. It's not just "copy-paste compatibility
with C" which made std::unique_ptr or std::optional deref and UB.

~~~
pjmlp
Sure it is, because they need to be compatible with C pointer semantics.

The large majority of C++ UB comes from compatibility with ISO C UB 200+
documented cases.

And ISO C++ working group is trying to reduce the amount of UB in ISO C++,
which is exactly the opposite of ISO C 2X ongoing proposals.

~~~
masklinn
> Sure it is, because they need to be compatible with C pointer semantics.

They don't _need_ to be compatible with unsafe / UB C pointer semantics,
allowing them to _both_ contain garbage and be deref'able were explicit
decisions the C++ committees did not _have_ to make but _chose_ to.

~~~
pjmlp
Some people prefer a Python 2/3 community schism, others prefer that tools
actually get adopted in spite of a few transition flaws.

------
Animats
The C++ people are trying to refit ownership to the language without adding a
borrow checker. This is painful. They've made it possible to write code that
expresses ownership, but they can't catch all the places where the abstraction
leaks.

string_view is really a non-mutable borrow. But the compiler does not know
this.

~~~
fooker
> but they can't catch all the places where the abstraction leaks.

Why does static analysis not work here?

~~~
kllrnohj
It does, it's just a warning and not an error. And also experimental.

But it does exist, and does catch some of these errors. Example:
[https://godbolt.org/z/CZTfSx](https://godbolt.org/z/CZTfSx)

~~~
humanrebar
I'd rather run diagnostics as a separate CI pass, so warnings work for me
perfectly.

------
raphlinus
From the article:

> Dereferencing a nullptr gives a segfault (which is not a security issue,
> except in older kernels).

I know a lot of people make that assumption, and compilers used to work that
way pretty reliably, but I'm pretty confident it's not true. With undefined
behavior, anything is possible.

~~~
_wmd
Linux hit a related situation: a harmless null pointer dereference was treated
by GCC as a signal that a subsequent isnull test could not be true, causing
the test to be optimized away.
[https://lwn.net/Articles/575563/](https://lwn.net/Articles/575563/)

~~~
mjevans
My opinion on that, is that such code MUST NOT be optimized away. Instead it
should be a compile error.

~~~
raphlinus
You might wish for that, but the ship has sailed. Undefined behavior means
that the implementation can do whatever it can. That said, I do expect tools,
both sanitizers and static analyzers to improve to detect more of these kinds
of cases.

~~~
lmm
The original intention of standardization was that compilers would gradually
reach consensus on what the behaviour in certain cases should be, and once
that happened the standard would be updated to standardize that behaivour.
Compilers are allowed - indeed encouraged - to provide additional guarantees
beyond the minimum defined in the standard (indeed part of the point of UB is
that a compiler is allowed to specify what the behaviour is in that case).

------
jclay
I really don't get all the hate that C++ gets. The suggested alternatives in
the article are Rust and Swift. What if you need to develop a cross platform
GUI, that has a backend running a CUDA or OpenCL algorithm? For the former,
you can use Qt, which isn't without it's warts, but is pretty tried and true
in my experience (see KDE, VTK, etc). For the latter, you'll end up writing
your CUDA code in C++ anyways. I guess you could go the route of writing
bindings, but that is not without additional effort. Not that it won't happen
for Rust, but C++ also has tooling suited for enterprise use that are largely
unmatched in other languages (Visual Studio, Qt, etc). Sandboxing, static
analysis, and fuzzing tools are also mostly built for C/C++ codebases. It's
also an ISO standard language which makes it both a language full of warts due
to decision by committee, but also a candidate for a stable, long-lasting
language that will outlive many of us. (Try finding an ISO Standard Language
you don't hate).

Either way, C++ is certainly not for every project, but the articles scattered
around the web claiming it should be superseded by Rust are plentiful. These
opinion pieces make no attempt to credit C++ for when it _does_ make sense to
use. Despite it's quirks, it is still the most optimal way to program HPC
applications or cross platform GUIs that are not Electron based. The security
tools around it and the fact that it's an ISO standard language make it a
solid choice for many enterprises.

~~~
mannykannot
I do not think it helps to think in emotional terms such as 'hate'. There is
nothing wrong with discussing potential problems, and the current utility of
the language should not stop us asking whether we could do better in future.

FWIW, I use C++, not Rust or Swift, and I have a fair amount of knowledge and
experience vested in it, but I think these questions are worth asking.

~~~
blub
The questions are worth asking. But the Rust crowd is not asking questions,
they're dictating solutions, or rather that one old solution of rewriting
everything to Rust.

Meanwhile the Firefox rewrite, the premium example of what they propose is
still plodding along and Mozilla PR blogs aside, Firefox is still plugging
vulnerabilities in each release and will be for the foreseeable future.

Now let's look at the Swift community... do we have blog posts from them every
week about how awesome Swift is and why one should rewrite their working C and
C++ code in Swift? No, they keep doing their thing, Swift is becoming better
at cross platform, it's also getting some support for machine learning.

That's how one grows a language, through building successful projects, staying
positive (and having an entire platform behind it). Not through doomsday
scenarios and a constant barrage of criticism.

~~~
0815test
> That's how one grows a language, through building successful projects,
> staying positive (and having an entire platform behind it). Not through
> doomsday scenarios and a constant barrage of criticism.

This is exactly what the Rust community is doing! RIIR is something that's
only really insisted on for relatively _small_ pieces of _security-critical_
code. With huge codebases like Firefox the rewrite is done piecemeal, to put
the rewritten code in use as quickly as possible. The "doomsday scenario" talk
about memory-unsafe languages does not come from people writing Rust, it
mostly comes from the security community, even at places like Microsoft -
because guess what, they've literally been running around with their hair on
fire for _decades_ , and they're sick of this especially now that something
like Rust is available!

------
ycombonator
_" Don't be clever"_. Yes. In the CppCon 2017 opening keynote: The Learning
and Teaching Modern C++. The accompagnying slide says "Don't be (too) clever"
but I can't promounce parentheses :-). My point was to discourage overly
clever code because "clever code" is hard to write, easy to get wrong, harder
to maintain, and often no faster than simpler alternatives because it can be
hard to optimize. - Bjarne Stroustrup

------
0xDEEPFAC
What do you need saving from - Ada has existed for nearly 30 years now ; )

~~~
ajxs
I came here to the comments to post this exact thing, haha. I'm very late to
the Ada party, and I'm amazed at how ahead of its time this language was. It's
still very usable and modern by today's standards.

~~~
DoingIsLearning
> by today's standards

You make it sound like Ada stopped in the 80's.

They don't release standards in rapid succession but 'Ada 2012' has pretty
much all of the features that people were asking for in C++ since 2011.

The only issue (on top of the obvious lack of coolness and hype around it) is
that professional grade Ada compilers/toolchain are still quite a high cost
for single developers or small companies. AdaCore's business model is still
pretty much focused on support contracts to big Aerospace/ATC/Defense clients.

~~~
0xDEEPFAC
Many of AdaCore's "community" versions are the full compiler and if they dont
have builds available for your bareboard arch you can build it yourself or get
one from gcc.

The only difference is that use of the special "GNAT.X" packages _outside the
standard runtime_ are under a GPL restriction and you would be required to
export those dependencies as a separate lib and do open dev on it.

Otherwise you are free to sell or keep any trade secrets you want without
giving AdaCore anything.

~~~
DoingIsLearning
TIL. I was under the impression they were a lot less permissive outside a
commercial license.

------
jasonhansel
Can someone at least make a linter that ensures you only use a "safe" subset
of C++?

~~~
steveklabnik
The Core Guidelines are an attempt at this, but it’s not fully safe. Safer,
which matters! But not safe.

There isn’t really any useful safe subset of C++. If there were, Rust may
never have been created in the first place.

~~~
pjmlp
Still, C++ is good enough for the unsafe low level bindings of a Java/.NET
application.

Until Rust's tooling catches up with C++/CLI, C++/CX, C++/WinRT + .NET or Java
+ C++ (Eclipse/Netbeans/Oracle Studio), CUDA, Unreal/Unity, GLSL/HLSL/Metal
Shaders allow for, it will stay as a safe way to write CLI apps and a couple
of UNIX libs.

I like the language and advocate it often, but I am also very pragmatic
regarding the areas I and customers work on.

------
User23
For systems programming languages, safe by default with scoped unsafe code is
a Pareto improvement on unsafe everywhere.

~~~
pjmlp
A feature that exists since 1961, across several systems languages.

~~~
kiriakasis
I never understood this type of comments, is what you are trying to say
something like:

"It was already tried and failed, why is this time better"

"Mainstream languages always end up not using it"

"People should reference more the original works of the past"

...

One of the many explainations of the name Rust is that it represents a
collection of old ideas. What was the point you were trying to convey in
specific?

~~~
pjmlp
People should reference more the original works of the past instead of
rediscovering them

~~~
kaens
I think more rediscoveries may be references than you suspect, but in the
cases that are rediscoveries there is a bit of a knowledge and discoverability
issue for PL features for people who aren't PL nerds already.

I'd love it if more people had a more solid understanding of the ideaspaces
that have been covered in the PL landscape, but considering that most common
paths to working in software (and even to creating and contributing to langs)
don't involve needing to know PL history I'm not sure how to get there from
here.

If you have resources you think people should be utilizing here, please speak
up.

~~~
pjmlp
I keep posting them here.

How I got to learn about them?

Having a solid Informatics Engineering degree, with focus on systems
programming, graphics and compilers, and a very nice university library.

That was it, we had to hunt for books, compuserve, gopher and BBS were still a
thing.

Nowadays learning about the history of PL is a google/bing/... search away, a
couple of seconds with access to plenty of scanned papers and conference
proceddings since the early 60's, so one has to be quite lazy not to research
them.

------
jmole
Question - How does one write microcontroller code (or other memory-mapped I/O
code) using a memory-safe language?

~~~
tedunangst
By calling unsafe code. :) The semantics and guarantees offered by the
interface vary, but that's the short version.

~~~
User23
Often that unsafe code is assembly language.

~~~
AnimalMuppet
Been there, done that. We were using Pascal (standard Pascal, no Turbo
extensions) on a machine with memory mapped I/O. This means that we had to
drop into assembly to write to the I/O registers. And that meant that we lost
all type checking for those functions. We couldn't even check the number of
parameters! Unsurprisingly, that led to a crash.

That is: The extreme safety of Pascal led to a crash (when we had to do
something that Pascal, in its wisdom, said we weren't allowed to do).

------
systemBuilder
Many of the problems he talks about come from the lunacy of the C++ compiler
making all sorts of temporaries and calling hidden type conversion functions,
making all sorts of assumptions that it should never ever ever make without
being told by the programmer. That is why C will always be a better language
than c++ on a fundamental level. In this area stroustrup took C in a bad
direction.

------
nitwit005
The string_view issue has popped up even in relatively safe languages. Java's
String class used to do something similar, where substring returned a String
that referenced the original String object's internal array to avoid a copy.
They gave up on it because too many people accidentally held a references to
large strings and leaked memory that way.

~~~
kccqzy
As far as I know, this is rather popular. Haskell's ByteString and Text still
types do the same. So does Rust, where most of the time you are very
consciously borrowing the original string instead of making copies.

------
0xe2-0x9a-0x9b
There is no call in the article for a deeper C++ code analysis by the
compiler. Deeper analysis will be the future of C++ - the article fails to
foresee this.

~~~
notacoward
> Deeper analysis will be the future of C++

As if C++ compile times aren't crazy enough already.

------
shmerl
_> Nonetheless, the question simply must be how we can accomplish it, rather
than if we should try. Even with the most modern C++ idioms available, the
evidence is clear that, at scale, it's simply not possible to hold C++ right._

So, how then? That's the main question indeed :)

------
sys_64738
Today's C++ will be considered a cobbled together relic in a few C++ standards
time periods!

~~~
ncmncm
By then Rust will also seem a cobbled-together relic, and you will be chasing
the new hotness. In the meantime, we are writing the code that makes the world
work. In C++.

By then, many will also be writing it in Rust, and you will be sneering at
them, too. It has always bern easy to sneer at people busy making things work.

------
MiroF
The stringview example is surprising and certainly something I could have
fallen for.

I feel like the lambda example is pretty contrived. If I was returning a
lambda that was capturing values by reference, I would already be pretty wary
of UB.

~~~
umanwizard
I guess it comes down to the individual reader. I had to look at the lambda
example several times to realize what the problem was with it. I guess my eyes
just skim over the capture section unless I have some good reason to look at
it. The string_view example, on the other hand, was immediately obviously
wrong to me.

------
IshKebab
> Dereferencing a nullopt however, gives you an uninitialized value as a
> pointer, which can be a serious security issue.

Is this really true? Surely it just gives you an uninitialised `int` (or
whatever is in the `optional`)?

------
leshow
Rust and Swift have different definitions of memory safety, don't they?

~~~
0815test
Yes, AIUI Swift does not ensure memory safety for concurrent code like Rust
does. You have to expressly opt-in to concurrency-safety, and it's not checked
by the compiler. Go definitely has this issue, which is admittedly bizarre for
a language that's so often used to code network-oriented services making heavy
use of concurrency.

~~~
favorited
That's because Swift doesn't have a first-class concurrency story yet. I
imagine that concurrency safety will be sorted out when Swift gets
concurrency, but in the meantime all Swift concurrency is using C primitives
like pthreads and libdispatch.

~~~
leshow
That sounds like it's going to be a mess. If they introduce compile time
checks that have the same strictness as Rust it will break existing code. It
seems like Swift has already done that a few times over.

~~~
favorited
Using a new language concurrency feature would require you to change your code
anyway, the same way using any new feature would. And when the Elm/Rust-style
ownership annotations are made public, they will be opt-in.

------
foobar_
Can virtualisation solve this ? Is it possible to have a virtualised
environment like Qubes but for programs ?

~~~
simias
Virtualization can help reduce the harm caused by a misbehaving program but it
won't magically make the program behave correctly.

Having a program cause a memory violation and be killed by the OS is the best
possible outcome in this case, it stops the program from doing any damage and
you get a clear symptom of the problem for debugging.

It's when the issue is _not_ that obvious that you're in real trouble because
it may start behaving erratically, corrupt data and be exploited by malicious
actors to get access to resources that shouldn't be exposed.

------
sayusasugi
Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism
Strikeforce.

~~~
insulanian
And rightly so! What's wrong with spreading awareness about safer alternative?
If that wasn't the case in the past, we'd still be programming in Cobol and
Fortran.

~~~
pjmlp
On the contrary, we had plenty of safer alternatives for systems programming,
derived from Algol and PL/I.

Then came an OS, with a symbolic price instead of the typical market prices of
competing OSes, alongside source code tapes, and a systems programming
language that was the "JavaScript" of system languages.

~~~
0815test
The biggest factor was that the OS was written to run on minicomputers as
opposed to big iron, and was written in a portable language. Thus it could
seamlessly jump over to micros (as soon as these became powerful enough, of
course), and even later on to embedded and "wearable" compute. You just _can
't_ do that unless you're writing in a highly flexible _and_ highly portable
language - more like the FORTRAN of systems languages than anything like
JavaScript!

~~~
pjmlp
Ironically, systems written in hardware 10 years older than PDP-11, thus with
less resources, were written in safer system languages, go figure.

------
fetbaffe
Without any data to back this up, my guess is that there is no good reason to
pick C++ for a new project except when the developer is already fluent in C++.

Assume we have this abstract developer that has a good knowledge in
programming theory but has no experience in programming languages.

The developer starts a new project, but in what language?

web: Don't see any reason for this. Exist lots of great alternatives. This is
not really one of C++ strengths so is not that strange.

desktop-GUI: Probably one of the biggest strengths of C++ is the Qt framework,
it is solid choice. I can see this a possible choice. However with electron
dominating & PWA:s becoming a more viable option it is probably much higher
chance that a HTML/JS environment is picked instead, especially how it already
dominates the web. And by using TypeScript you can do it an solid language.

mobile apps: Most apps are written in some web technology or directly with
Swift or Java. Qt has some support for this, but not sure how widely used. My
experience with NDK was not pleasant. I can't really see this as a viable
option.

embedded: I don't do embedded, but my understanding is that plain C is much
more common here & if faster development is needed you integrate something
like Lua. Maybe?

memory safe: use rust I guess.

compiled binary: Use golang, no complicated buildstep.

Parallellism: Better to use a language designed for this like erlang.

Game development: For the majority of games today a scripting language like
JavaScript or Lua is good enough. HTML/JS has some really good frameworks for
game development today.

3D game development: Probably a good fit to use C++, but I think that C# with
Unity is a much better choice. Great framework, good community, however C++ is
not bad choice for this. Possible.

Commandline tool: If the developer is building the next grep, C++ could fit
that, but most commandline tools does not have that performance requirement,
Probably do some HTTP, JSON decoding, DB access. Bash is good enough or any
other dynamic language.

Scientific: my understanding is that today this is mostly python or matlab.
Maybe?

System development (drivers etc): I know too little about this to make a good
assessment, to be fair I put this as a possible choice.

And if the developer do decides to use C++ for a new project, the initial cost
is quite high to just understand the basics, even if he/she uses the latest
C++ version. Copy constructors, lvalue & rvalue (xvalue, glvalue, prvalue...),
move semantics, const refs, rvo, smart pointers, auto etc

Any good arguments to pick C++ for a new project?

~~~
pjmlp
NVidia is designing their GPUs with C++ in mind as source language.

desktop-GUI: I guess you might be joking here with Electron, I rather use my
GPU for something else other than blinking cursors. Even with Cocoa, UWP and
WPF, the underlying UI shaders are written in C++.

Embedded: Yes, C does rule over C++, which is a reason why embedded is so open
to security exploits due to wrong manipulation of string and arrays.

Parallellism: HPC, FinTech, GPGPU all domains where C++ rules for the time
being.

3D game development: C++ is king here, even with Unity the core engine is
written in C++. Yes many of us hope to see the day when Unity is 100% written
in a mix of C# and HPC#, but even then, LLVM will be part of the stack.

Scientific: Someone needs to write those Fortran and C++ libs called by Python
and Matlab.

System development: Google, Apple and Microsoft use C++ on their driver layers
for their respective OSes.

IDE tooling: C++ is known for not having IDEs that match what Java/.NET are
capable of. Languages that want to take C++'s place, are even worse than C++
in IDE tooling.

~~~
fetbaffe
desktop-GUI: I'm not a fan of Electron either, however the community seems not
to be joking about picking it. It seems like most projects are going that
direction. None of your arguments here are about a new projects, just about
existing technologies.

Embedded: But how is that an argument for C++? I can do safe stuff in Lua
without the hassle of C++ & then use C when needed.

Parallellism: Agree. Here we have a case.

Scientific: Yes, someone needs to write the underlying libraries for Python &
Matlab, but if you are starting a new project, do you actually start writing a
library first or do you use an existing one?

IDE tooling: Yes, good tooling can be a good argument in itself to pick a
technology. With C++ maturity is as a clear advantage, however some of the
languages that i listed do have quite nice tooling today, e.g. C# &
TypeScript.

~~~
pjmlp
desktop-GUI: What community? Web devs trying to write desktop apps?

Embedded: Try to write a safe string and vector with bounds checking, or IO
port access in C like in C++ type system allows for. Lua is nice for hobby,
not production class hardware deployments.

Scientific: Depends, many libraries are yet to be written.

IDE tooling: Typescript and C# audience isn't the same as those using raw C++.

~~~
fetbaffe
desktop-GUI: Yes, frontend today is a combination of Web & apps, C++ does not
fit in either. UWPs can be written with JS or C#.

Writing desktop-GUI is also on the decline, however I could see potential
increase in desktop-GUI-programs if governments continue to pass bad
regulations of the web like content filters & link tax.

Embedded: How come C++ is not dominating embedded? According to you, it
should.

IDE tooling: If you are writing a 2D-game or desktop-GUI it is.

Even though C++ is used as an important building block for other technologies,
too survive, C++ must attract a new generation of developers, to continue
carrying the torch & develop it further. Does it? I have seen little evidence
of that. My impression is that developers learn C++ because of existing
projects. Sure, there exists lots of good C++ projects out there that will
continue attract developers & push the language further, but will it be
enough? I'm not convinced.

~~~
pjmlp
desktop-GUI: Many UWP APIs are only accessible to C++/CX. Plus only UWP
controls written in C++ are usable from Win32 side.

I have spent the last 4 years doing green field desktop GUIs, apparently those
customers haven't got the news.

HTML5 APIs still aren't a match for plenty of native APIs.

Embedded: Religious hate against C++ from older timer devs, as discussed in
several CppCon and Meeting C++ talks, e.g. Dan Saks has quite a few of them.

CppCon 2019 will change location, because they no longer can fit everyone on
the old location.

------
781
There was an article recently about a behavior which in a recent version of
C++ was made from defined behavior into undefined behavior, because making it
undefined allowed for better compiler optimizations.

I always thought that undefined behaviors were historical accidents. But
apparently sometime people just say "hey, lets add a few more undefined
behaviors"

This is the insanity of C++

~~~
sbov
This sounds wrong. You're probably thinking of undefined behavior that
happened to behave the same across all available C++ compilers, so people
began to rely on it. But since it was technically undefined behavior,
optimizers were free to take advantage of it, and when they started to it
smashed any code that relied on that undefined behavior behaving in a
consistent way.

~~~
zaphar
While technically correct, (which is the best kind of correct), the sad
reality is that de-facto standards matter. Languages that understand this tend
to be safer than languages that do not.

