No
Is C++ Doomed?
91–100 of 168 posts
Re: Is C++ Doomed?
#92I believe it's inevitable. But I would have given a very different answer even a few years ago. What strikes me the most though is that C++ is that it's not being succeeded by a new better C++ but instead it's being slowly replaced by multiple languages at once. C#, Java, Go, Rust, Swift, and JavaScript, (and maybe even python) are all replacing C++.
In 22 if someone wants to make a general desktop app they'll probably use web technologies, or python, or java. If you do server development it's Python, C#, Java, Ruby, or Go. Embedded development is predominantly pure C. C++ is used but less often. Gaming is still a singular C++ affair but I'm starting to see C# make headway and now Rust is gaining traction. I've seen more game developers excited about Rust than I have about anything in the last 5 years.
You can see it happening slowly, as more and more technologies are coming out and chipping away at it's use cases. Unless you're targeting game consoles, or a very specific rare domain, using C++ might be more of a handicap with so much better options out there.
Re: Is C++ Doomed?
#93I 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 is a pure C api, absolutely not c++.
Re: Is C++ Doomed?
#94I 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…
> The author seems to look for something like Go instead But in Go you also have to write exception safe code, something the author complained about. Before someone says "but you're not supposed to throw or catch in Go": the std http server swallows exceptions thrown in handlers, and fmt.Print does for String callbacks too. And before someone says Go doesn't have exceptions: It does, 100%, in all but name. I actually…
> And before someone says Go doesn't have exceptions: It does, 100%, in all but name.
But here the name actually matters. They're called "panic"s, not exceptions. When you panic, you signal a fatal error that should ideally terminate the program. You shouldn't care about closing files or freeing memory, because well-written Go does not panic, and if it does, execution will end very soon. A panic in a String() method is just bad code, don't do it. Meanwhile in C++ you can reasonable expect an exception anywhere. Bad arguments, invalid states, IO failures, and other errors that should be expected in the execution of a program all throw exceptions in idiomatic C++.
Re: Is C++ Doomed?
#95I 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…
All those things are C APIs not C++
Re: Is C++ Doomed?
#96Define doomed? Not being around in century? It certainly have enough inertia to carry on for long time, probably decades.
Re: Is C++ Doomed?
#97Practical implementations of data structures require consideration of memory layouts and pools which have real equivalent in other languages.
For example, imagine building a graph structure to hold a uint8 field but calling malloc for every node. You get that and worse in Python.
Simply put you cannot write performant, non-toy data structures outside of low level languages like C++.
I think OP is simply not aware of the kind of structures that are used in algorithm critical applications, like CAD, compilers, etc.
Re: Is C++ Doomed?
#98I believe it's inevitable. But I would have given a very different answer even a few years ago. What strikes me the most though is that C++ is that it's not being succeeded by a new better C++ but instead it's being slowly replaced by multiple languages at once. C#, Java, Go, Rust, Swift, and JavaScript, (and maybe even python) are all replacing C++. In 22 if someone wants to make a general desktop app they'll probab…
> In 22 if someone wants to make a general desktop app they'll probably use web technologies, or python, or java.
I wonder what apps you are talking about. The immense majority of apps I use are Qt. Just last week I was trying some newish Intel GPU profiler GUI: https://www.intel.com/content/www/us/en/developer/tools/grap... ; a Qt app. Last month I produced a video, with Da Vinci Resolve, also a Qt-based software.
On the other hand, on my whole desktop I literally don't have any Java apps installed at the moment, like, not even a JDK. There may be a 2012-era copy of Minecraft in some backup folder. Likewise for Python, at most some apps will embark Python scripting around a C++ core like Blender but I don't think I use any app where the main() is written in Python.
Re: Is C++ Doomed?
#99Earlier quoted context omitted.
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 No one should ever have to use factories, they really suck. Too much boilerplate, too much code duplication.
how do you do non-trivial dynamically-loaded plug-ins without factories ?
Re: Is C++ Doomed?
#100Earlier quoted context omitted.
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 a…
Part of the key is that they’re not really “built in.” They’re in the standard library. When you’re in those contexts, you just don’t use the standard library. Problem solved.
Now, the standard library is also getting support for these things not panicking on allocation failure, and when that’s ready enough for those that want it (Rust for Linux has pulled the changes into their tree, in my understanding) then they could use them.
(I work on embedded systems with no dynamic allocation, Rust is great.)