> Is C++ Doomed
I wish. Unfortunately I think it is we who are doomed and stuck with it forever.
Is C++ Doomed?
21–30 of 168 posts
Re: Is C++ Doomed?
#22> Let’s say I want to know if a constructor failed
This seems like the beginning of a bad situation. I mean, this shows why constructors that do any complex work that can error out are a bad idea.
Re: Is C++ Doomed?
#23The commentary is good, but the conclusion is unsupported. These are annoying issues, but doom they do not make.
Define “doom” or “death”. Cobol still runs, FORTRAN still runs, not the coolest in the TIOBE index but in the tail. A mammalian body doesn’t die all at once, either, but past some threshold of vitality does definitively die and remains dead. Really unclear whether these languages will be dead until the last compiler stops compiling. So the discussion needs a definition for the threshold the language may reach.
Re: Is C++ Doomed?
#24I hear you.
* Move semantics itself requires a whole book https://www.cppmove.com/.
* RVO has always confused me. It was much simpler in the C++03 days. Copying large objects by value was inefficient. So you always used references. Period.
* Don't fully agree with the commentary on exceptions; it's the same in most other languages if you want resources to be freed/given back.
Re: Is C++ Doomed?
#25I used to be a C++ Fan Boy. I just started learning rust last week and noticed how old c++ is. All the good practices are built into rust that you need to specifically write in C++.
Re: Is C++ Doomed?
#26I should note that writing data structures in rust is also a fraught business! In practice, that’s just a property of languages that don’t have garbage collection. Exception safety is a serious complication in c++! Exceptions were a mistake in the language, particularly given the existence now of std::optional.
Finanally, c++ is the only language I would ever want to do linear algebra in, or for that matter, many graph algorithms. Rust is adding features to make it useful for linalg, but it’s not their yet. Linear algebra is important!
> Finanally, c++ is the only language I would ever want to do linear algebra in
Isn't something like MATLAB better for linear algebra than C++?
Re: Is C++ Doomed?
#27> I have two options, one is to pass in an in-out parameter, the other is to the throw an exception.
These are not the only options. You can also return `optional` or an other wrapped value from a factory function.
Re: Is C++ Doomed?
#28On a long enough timeline I do believe C++ is doomed or will otherwise become something completely unrecognizable from its current form. Similar to how C++98 code is wildly different than modern C++ code. People often ask, "is C++ a good language?" or "is XXX better than C++?". Doesn't really matter, what matters is whether people are willing to pay the "tax" of learning/using/maintaining C++. C++ is a generalist lan…
C++ is not a generalist language, its strengths are high performance, direct memory access and native compilation. If an application doesn't need any of that, a higher level language is usually better.
Re: Is C++ Doomed?
#29"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 Re: Is C++ Doomed?
#30The commentary is good, but the conclusion is unsupported. These are annoying issues, but doom they do not make.
In my C++ code, I've copied Rust and expressed fallible initialization by returning a std::optional from a static method (which the article failed to mention). The problem is that (like Rust) you lose placement initialization, and (unlike C++ or Rust) you can't initialize private fields using aggregate initialization or initializer lists, and must write a passthrough constructor (which can't even be private because it breaks make_unique).
https://github.com/hsutter/708 is a C++ proposal which unifies placement constructors and writable out-parameters ("definite first use"). I don't think it makes placement initialization fallible, but I'm not sure.