When i do my periodic refresh runs c++, i often question myself - why i'm bothering with it? C++ seems more about programming c++ itself than programming against the actual problem. At which point i reason that if i ever need to go native and fast, i'd simply use C, and for the higher level use not-c++.
Is C++ Doomed?
101–110 of 168 posts
Re: Is C++ Doomed?
#102No post body was provided.
Re: Is C++ Doomed?
#103I 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…
C++ exceptions aren't totally zero overhead. For an obvious example, you pay in code size.
I do agree with the overall analysis, though.
Re: Is C++ Doomed?
#104The 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.
I think "dead" is pretty clear. The work is not used anymore at all, or only for hobbyist projects.
I think "dethroned" or "unpopular" would be more correct presuming that C++ would lose popularity over time due to the issues raised.
Re: Is C++ Doomed?
#105I 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.
> 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.
How would you reconcile that with the fact that std::vector::vector() is explicitly permitted to fail? [1] Do you construct your std::vector objects with factories too?
> Exceptions: Calls to Allocator::allocate may throw.
[1] https://en.cppreference.com/w/cpp/container/vector/vector
Re: Is C++ Doomed?
#106I agree that C++ is a mess of a design, but I don't think this article quite gets how. RAII and move semantics are two of C++'s best features, and the ones that any replacement - like Rust - will copy. To me, bigger flaws with C++ are that it's too big. The language is bloated with multiple features that accomplish similar things, but each with their own odd corner cases and interference. Anytime there's an issue fro…
From a post in /r/cpp [1], > As of C++20, the right way to write a trivial getter in C++ looks like `[[nodiscard]] constexpr auto GetFoo() const noexcept -> Foo { return foo_; }` C++>11 is such a mess than most useful changes are invisible to most users due to bloat. I think it's way past time to call it quits and abandon active development of the language. New features will come from other languages without 35 years…
I'm not sure it is remotely reasonable to choose a language for a project based on the verbosity of accessor signatures when being maximally pedantic.
C++ is indeed a mess but there is almost no alternative for existing enormous codebases than to keep making it better. The industry will slowly adopt memory safe system languages, but that's going to take ages to go beyond greenfields and absolutely security-critical systems.
Re: Is C++ Doomed?
#107Earlier quoted context omitted.
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…
okay, good observation on a apparently the quote is confirmed by the man himself, though: https://www.stroustrup.com/quotes.html
I think what the OP meant was that the sentiment behind the quote doesn't reflect reality, not that Stroustrup didn't say it.
Re: Is C++ Doomed?
#108Earlier quoted context omitted.
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.
Yes, though even if rust had inheritance I don't think you would have a machine translatable mapping good enough to port a game engine.
Generally for any language which in design isn't "somewhat close to C++" I don't think this would work.
Re: Is C++ Doomed?
#109> I have two options, one is to pass in an in-out parameter, the other is to the throw an exception.
Another one would be not using constructors at all, instead implement initialize() or create() method in the class.
> Now you have the issue that every single operation can throw an exception
Depends on the code. I tend to avoid exceptions when I can.
> you need to write code that wraps every possible resource in RAII logic.
That’s generally a good idea regardless of whether exceptions are used or not. Without RAII for file handles, next day/month/year another programmer will write `if(condition) return;` and leak the handle.
> And when it comes to implementing move and copy constructors you are left feeling like you’ve definitely done something wrong
For many classes in my code, I disable both with =delete; copy constructor. This makes a class which can be neither moved nor copied, which simplifies things substantially. For instance, if you need a RAII equivalent of CAtlFile [0] over FILE* from stdio.h, immovable file handles might be a good idea. Another thing, if the class owns many gigabytes of data in some collections, you wouldn’t want to copy anyway, too expensive. In some cases I want to move such objects, for that I define a swap() method. An explicit swap() method is IMO more readable than std::move.
For many other classes in my code, I declare no constructors at all because the default compiler-generated ones already doing what I want.
[0] https://docs.microsoft.com/en-us/cpp/atl/reference/catlfile-...
Re: Is C++ Doomed?
#110You'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.
The Arduino and friends can run on C++. The Arduino “IDE” uses “C almost ++”, but C++ compilers for AVR and ARM boards do exist.