You'll have to prize C and C++ from the cold dead hands of the embedded programmers. Most of them are still doing OO using plain C.
C, yes! C++?
I also think that Zig has a good chance to become popular in the MCU space.
Is C++ Doomed?
81–90 of 168 posts
Re: Is C++ Doomed?
#82Gonna be a long while before safety and certification bodies for industries like aerospace move away from C++. All the tools for the past few decades focus on C++ as the main systems language in these cases. Rust is great as a spiritual successor with more stable performance (in general) but the institutional inertia with C++ is strong.
Aerospace industry? C++? Frightening. I thought Ada is prevalent in this space.
Ada never really "won". It was mandated by DOD, but the industry more or less rebelled at the idea. Fortran was pretty common, but C and C++ are the dominant languages. The last greenfield aerospace (avionics) project I was on, we were given a choice and it seemed that we (and everyone else) went with C or C++. There are a lot of static analysis tools now that cover most of what you get from Ada (and then some, even with SPARK), but the choice was really based on familiarity for potential new hires. You also use strict subsets of C or C++ in this field, not every feature will be available. (I wish it had been in Ada, a lot of issues in the system wouldn't have happened in Ada, but they did eventually get worked out anyways.)
Re: Is C++ Doomed?
#83The basic problem with C++ is that it has has hiding without safety. C has neither, and most newer languages have both. Attempts to add safety to C++ via templates always seem to leak raw pointers, since many APIs never converted to C++. It's significant that there isn't a C++ Linux kernel API, where you use C++ strings for everything and get rid of the null-terminated stuff. You see this in the original poster's exa…
I would say many (not all) game engines could probably be converted, by finding common pattern in usage of inheritance and mapping it to rust patterns. EDIT: Through automatizing this, or making C++ to rust bindings for it would be hard. I mean creating inheritance graphs for entities is as far as I know already seen as an anti pattern since a while. Things like ECM are nicely re-presentable in rust. Many patterns of…
There's a pretty wide gap, though, between "nicely representable in rust" and "mechanically translatable from the C++ implementation" that mostly requires human effort to span.
Re: Is C++ Doomed?
#84I am very confused. Some of these ramblings are just plain wrong, like > But exceptions come at a performance cost. No they don't. An exception that isn't thrown costs nothing. Also > Let’s say I want to know if a constructor failed. I have two options, one is to pass in an in-out parameter, the other is to the throw an exception. Using a factory function instead is a third option that avoids this. Besides, this is a…
> An exception that isn't thrown costs nothing. It costs binary size for unwinding tables, and in some cases it is an optimization barrier.
and yet when benchmarking, exceptions are often faster. cross-posting a comment I just made on r/programming: https://www.reddit.com/r/programming/comments/sz86fl/comment...
Re: Is C++ Doomed?
#85I think the first step is to explain to people that C++ is just C with more stuff, the original is way simpler and the ONLY real reason to use a C++ compiler is that most dependencies that you need (OpenGL, OpenAL etc.) uses C++ by default. That took me 3 years to figure out on my own, such a waste of time. In C++ defense namespaces, strings and streams do have some usefulness to them, but if I could use a C compiler…
OpenGL, at least, is a C API, not C++. If you're using it directly, there is no need to use a C++ compiler. EDIT: And I just double checked, OpenAL is also a C API.
Re: Is C++ Doomed?
#86> IS C++ DOOMED?
Yes, as are all of today's imperative programming languages.
Re: Is C++ Doomed?
#87Gonna be a long while before safety and certification bodies for industries like aerospace move away from C++. All the tools for the past few decades focus on C++ as the main systems language in these cases. Rust is great as a spiritual successor with more stable performance (in general) but the institutional inertia with C++ is strong.
In this aerospace company, we use C, no C++ allowed, to avoid all the extra footguns that get in the way of safety and certification. Rust will probably be the next choice on the scene, but I expect it'll take as long to come as Ada took to go.
Off topic, but curious why Ada went?
Re: Is C++ Doomed?
#88I am very confused. Some of these ramblings are just plain wrong, like > But exceptions come at a performance cost. No they don't. An exception that isn't thrown costs nothing. Also > Let’s say I want to know if a constructor failed. I have two options, one is to pass in an in-out parameter, the other is to the throw an exception. Using a factory function instead is a third option that avoids this. Besides, this is a…
To add to "Let’s say I want to know if a constructor failed." Constructors are simply not meant to fail. You should never do something like io in a constructor. For everything more complicated than setting some fields a factory is better suited.
Why? Isn't one of the ideas of C++ that every constructed object is in a valid state? Even the STL has constructors that can fail, and it does it through member variables/flags, which doesn't seem like a very good solution:
std::fstream s(filename);
if (!s.is_open()) {
std::cout Re: Is C++ Doomed?
#89Earlier quoted context omitted.
What's the state of Rust/C++ interop currently? Naively it seems like allowing Rust in C++ projects could be a reasonable way forward, but I haven't tried it personally yet.
I think you're implicitly saying that Rust solves the problems in the article, and so migrating C++ projects to use Rust is a path forward. However, the blog author's first example was implementing a "contiguous circular queue", so you should try to do that in Rust. Of course Rust already has VecDeque , but then C++ already has std::deque too (although not promised to be contiguous). So the exercise is to implement y…
> Later in the article, he talks about exception safety. For something like a container, the most likely exceptions are that you've run out of memory, or you can't move/copy/construct an item in the container. I'm honestly not sure how Rust's builtin containers handle these problems. (Panic?)
As I understand it yes, the containers will panic.
Part of the discussion about using Rust in the Linux kernel is what to do about failed memory allocations. And this is a problem more generally for Rust usage in embedded systems.
So there may need to be support for alternative allocators or something else.
Re: Is C++ Doomed?
#90"Is C++ Doomed?" No. The FILE example is either bad, tired, lazy or shows lack of knowledge of the standard library. A better way of opening/closing the FILE with RAII is right in the example [0] of unique_ptr at the wonderful cppreference.com: std::ofstream("demo.txt") ; unique_file_t fp(std::fopen("demo.txt", "r"), &close_file); if (fp) std::cout I'm sorry, I'm not trying to be negative towards the author, but you…
But this also shows a lot of warts that mean RAII isn't "really working", as in it isn't reducing the mental load of resource management as far as we'd like. - You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use. - Probably most critically, fp can be null! If A is I, then I is A, yet here we are with a resource in-scope b…
> - You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use.
But you're not supposed to use fopen / fclose at all, in unique_ptr or not, so the language shouldn't encourage you to use those.
They are just often shown in unique_ptr, because when making examples to teach the language, it's a quick and easy way to showcase how to wrap any kind of pre-existing handles, not only memory, through the unique ownership semantics of unique_ptr; any other example would be platform specific (say, HWND on Win32, GL contexts or who knows what). Everyone knows fopen/fclose.
Basically, that unique_ptr thing is just here to show that it's possible to quickly ease porting 45 million lines of C to C++ without having to change every fopen into an ifstream/ofstream.