I prefer to recommend C# these days.
This is a electronics forum, about mostly embedded systems.
Who in his right mind will use a garbage language, meaning a automatic garbage collected only, indeterministic, factually vendor proprietary language and eco-system there?
Possibly only someone who can't handle a gun, always shoots himself in the foot and thus wants to ban all guns.
Lots of embedded applications don't have a real time requirement. As far back as 2004 I've been deploying C# on windows CE in embedded systems. This spans everything from mobile vehicle tracking systems to aircraft. In a lot of cases the application's "embedded" portion is a tiny piece of the picture and most of the application is actually on traditional compute. Hell if you look at a lot of embedded use cases, some of them are even desktop windows builds...
Some points:
1. As for the underlying C# platform (.net), you realise it's open source and supports AOT compilation?
2. As for the platform, you also realise it doesn't matter if it's open source or not? Same as everyone just buys Keil etc. What matters is applicability to the problem domain within the budgetary constraints.
For hard real-time applications you're right. I used Ada on PowerPC when I did that.
Note, also not C++ and not C because why the hell would you use that?!?! We used formally verified compilers and formally verified code for those applications, most of which ended with a large boom.
My personal preference for hard real time applications is FORTH and native assembly for ref. I write C for the AVR now for personal interest because it's the path of least resistance and it's cheap as chips and there is precisely zero risk of anything I do causing harm to anyone. I won't touch the Arduino toolchain because of the tangled bastardised C++ nightmare that sits over it. Just managing interrupts and library opinions is a chore.
The "bad boys" will always keep their guns.
Put your gun away. We're not shooting anyone
And about your string_view example, the language allows you to do optimizations crucial in embedded or systems programming that simply aren't possible in less deterministic managed languages, and it's misuse can be detected by tools, either if it happens by accident, incompetence or even intentional like in your example.
I think you miss the point. The point is that this was intentional on my part, because I understand the problem domain. The majority of people do NOT understand the problem domain even people with 20+ years of "embedded experience" so determining intent is difficult from what is presented to you. If there was that much determinism there wouldn't be stuff like
http://www.underhanded-c.org/ . With power comes responsibility and most people are too arrogant to handle that responsibility, something I observe here regularly.
The comparison with C# above was strictly to illustrate how many of the problems evaporate if you pick the right tool for the jobEdit: Incidentally the static analysers I have here (Coverity and Sonar) didn't actually pick this use after free up. Valgrind didn't either.
Optimisation, fair enough. I don't argue that. We sometimes have hardware constraints which need to be managed but at no point would I consider even throwing a C++ compiler in that direction. Just the abstractions it forces on you are too large for the hardware. C is about as close to the metal as you can go. It's basically a high level assembler there. The C++ abstractions are just way too high level to even throw anywhere near embedded stuff at that level.
And possibly there are people that want to do bloated toy embedded systems with managed languages, because the alternative is too difficult for them, but i suspect they don't earn much because the customer tends to buy what bangs most for his buck.
The customer spends what the customer wants and that is barely related to what comes out the other end. I actually know someone who's entire business is based on the Parallax Basic Stamp and he does very well and his products work fine. He knows his limits and what the risks are if he migrates everything to C so made a sound engineering decision to buy something in to make that risk go away.
As for money, I make it solving problems, not picking political sides in a battle of engineering requirements. The customer doesn't always care how they are solved. I have to compromise somewhere which means picking technology that won't fail both myself (thus incurring maintenance costs and decline in profit) or the customer (thus incurring wrath).
You see it with something like the Raspberry PI, or Adruino, for example.
The money there is made by selling people something that makes them feel they are a "maker", but what they "design" hardly makes any money by selling it, but of course he may tell others how great it is and increases sales of the "maker" supplies.
I'll avoid getting into the "maker" discussion here but that's just a marketing fad, a hashtag to shove on any old shit to try and sell it.
If we stick to the commercial side of this there is a market for high level languages in embedded systems and yes it is because they are easier but this is because it reduces time to market and risk profile for what you are doing.
C++ is a joke for everything. It doesn't fit anywhere. It only exists simply because of momentum. On the desktop it's dying on it's arse; people are rewriting shit in JavaScript and Electron and other high level languages. No one wants to deal with ATL/MFC/Qt any more. Apple are even walking away from Objective-C now and implementing their own higher level language. Mozilla are heading to Rust. On the embedded side of things, C++ has as much non determinism as on the desktop. C is marginally better but at the same time, it's a mess of non-determinism as well. Even the basic ANSI C specification has more unknowns than knowns in it.
Now my day job these days, past that history of embedded work at various levels, mostly consists of attempting to prevent large financial companies from doing stupid stupid things and giving them sound architectural advice. I've learned a lot over the years from C and C++ and that is basically summarised as:
If you want to spend money maintaining shit with a high failure and security risk, pick C or C++.
Now back to the Ad Hominem side of things, now we're done with the technical evaluation. Honestly I've worked with people with your general attitude of superiority and arrogance and fired them sharpish!
std::string a = "a";
std::string_view b = a + "b\n";
std::cout << b;
Looks like "clang experimental -Wlifetime" in compiler explorer gives a warning about this.
https://godbolt.org/z/zK4HVx
But not very glorious that GCC 9.1 doesn't. Maybe the newest MSVC also catches this with it's static analyzer or warnings.
If the argument for not using C++ is the deficiency of tooling that seems to be fixed rather soon even for the freely available tools or is fixed already for people using commercial static analyzers, it sounds rather compulsive.
Some more information here:
https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/
This covers my point nicely:
1. GCC doesn't. MSVC maybe. clang does. Non-determinism.
2. clang experimental warn feature flags this. Experimental.
3. I am not harry potter and don't wish to have to shout "Expelliarmus!" every time I accidentally load up the foot gun.
The deficiency is not the tool chain but the language design and specification and the crack in the pipe that was smoked by Stroustrop.