41–50 of 168 posts
I 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.
"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…
So instead of
(T*)malloc(sizeof(T) * capacity_);
(T*) operator new(sizeof(T)*capacity_, std::align_val_t{alignof(T)});
It's of course a little telling that the compiler will not complain about these errors and you have to use and know to use tools like address sanitizer, memory sanatizer and valgrind to let a machine help you find them.
It's true that implementing a standard library in C++ seems daunting but a) most C++ users don't implement stuff that goes into the standard b) you can tailor your data structures to the problem at hand instead of making it usable with every type and use case c) quoting Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
b is a limitation. C++ makes writing good general code a nightmare so you reduce to taylor your data structures to your problem c is just folk wisdom. That quote is just untrue a is true but it has gotten to the point that implementing C++ std libraries and compilers is so daunting a task that even the big vendors do not rush into it anymore. There is this growing fatigue that left only MSVC, gcc and llvm in the game…
apparently the quote is confirmed by the man himself, though: https://www.stroustrup.com/quotes.html
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 false dichotomy to begin with - it's perfectly acceptable to simply record the validity as part of the object's state and provide access to that (especially if the state established in the ctor isn't an invariant). So there's more than just two options.
Then there's more confusing arguments like the custom FILE wrapper. So instead of just using std::unique_ptr, i.e. the idiomatic solution for the past decade that the author claims to be after, they blame their C++03-style on the language? I don't understand.
Fortunately they don't provide any concrete examples of "features bleeding into each other", since I suspect that would only further illustrate their lack of understanding and knowledge gaps...
They end with
> I’m not in the business of writing the perfect program that satisfies an arbitrary standard. I’m in the business of making stuff with tools. [...]
Well great, then don't use C++ if you're not productive with it. Yes C++ is a complex language. A big portion of its complexity can be avoided by simply not using features one doesn't need (or understand) or by limiting oneself to a reasonable subset of said features.
The author seems to look for something like Go instead. C++ wasn't exactly "designed" and is the result of a steady evolution that kept some legacy baggage and bad earlier decisions around.
This is a great point. It means that you cannot mix C and C++ code without care, which seems like a huge design smell to me especially since this is not something that can easily be verified statically.
Using C++ with exceptions disabled is the only foolproof way to run it in a large heterogenous application.
The 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…
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 inheritance for code re-use tent to also not be too hard to represent in rust.
But I would argue that even if rust had inheritance engines like Unreal Engine would not be ported, at least not until they do a major rewrite anyway. Because of it being a lot of work with not too much intermediate gains.
Even if you look at it as at a strictly legacy technology, this legacy will be around for a looong time. A lot of important code is written in C++, without any viable replacement.
Also, like Fortran, it will keep improving even while relegated to its niche, and will become much nicer (yes, even nicer than the latest standard).