Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is C++ Doomed?

tednesday.wordpress.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Is C++ Doomed?

#111

Post by henning »

AnimalMuppet wrote: post #60
henning wrote: post #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.

No, they're fundamental to how C++ is idiomatically used. "Resource acquisition is initialization". This means that, if you have an object, and creating that object can fail, then it should fail in the constructor. So you either have a valid object, or none at all - you never have an invalid object. Now, you could squint and say that an optional returned from a factory is a valid object; that is, it's a valid optiona…

This just shows what a bad idea RAII is. You're destroying opportunities for managing resources in bulk and coupling that to just gathering a group of related data under a single identifier.

Re: Is C++ Doomed?

#112

Post by nyanpasu64 »

qayxc wrote: post #63
mark-r wrote: post #14

Earlier quoted context omitted.

Have you heard the phrase "death by 1000 cuts"? That's what programming in modern C++ is like. I agree they don't quite make the case for "doom" but it's still not a pretty picture.

This image is mostly painted by people who forgot to stop. By that I mean stop using every feature and detail because it's there. C++ can be used like a much better C (smart pointers, references, const-correctness, generics via templates) and most of the complications can be ignored that way. Premature optimisation is another big factor. If there's no measurable performance bottleneck, things like move-semantics don'…

Does the "much better C" include constructors are not? Smart pointers (which you include) are primarily designed for types with ~Type destructors, and difficult to use with C-style types with free functions for deallocation. And ~Type is difficult (unsure if impossible) to use without constructors, through either new Type or placement new into malloc'd memory. There is the trick of defining a passthrough constructor and moving initialization logic to a separate function calling the constructor. But if you want placement initialization, I'm unsure if C++ allows the C trick of casting malloc'd memory into Type * and passing it into a placement-init function that isn't a Type() constructor (pretty sure it's illegal to do so if Type contains std::vector, or shared_ptr, possibly unique_ptr). And constructors cannot report failures outside of out-parameters or exceptions, both of which were criticized in the article. So "most of the complications can be ignored that way" isn't true in my experience.

If you want fallible placement initialization, perhaps you could define a static method or free function taking a void* to malloc'd memory, which performs some logic then conditionally calls a placement constructor on the void*, then [[nodiscard]] return whether you succeeded. I find this awkward and not much better than C. Personally I give up placement initialization and return a std::optional.

>references... generics via templates

Implicit copy constructors are a footgun not found in C, and references decay to copies at every opportunity (auto, templates).

Re: Is C++ Doomed?

#113

Post by nyanpasu64 »

qayxc wrote: post #45

I 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…

Using a function pointer as a unique_ptr's deleter type, and passing it in at runtime, makes the unique_ptr fat (two pointers large). The "idiomatic solution for the past decade" is a lot more complicated than you make it sound.

To avoid this overhead, I prefer passing in a default-constructible type with an operator() deleter function, and not passing in a value into the unique_ptr constructor. A neat party trick is to use the decltype of a lambda as such a type (https://old.reddit.com/r/cpp/comments/rlvsq0/does_anybody_re...).

Re: Is C++ Doomed?

#114

Post by CyberRabbi »

AlexandrB wrote: post #78
CyberRabbi wrote: post #46

> That means you need to write code that wraps every possible resource in RAII logic. 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.

> Using C++ with exceptions disabled is the only foolproof way to run it in a large heterogenous application. Is there a way for a ctor to report failure in newer C++ standards or are exceptions still the only way[1]? [1] https://www.yosefk.com/c++fqa/exceptions.html#fqa-17.2

Exceptions are the only way. You can workaround this by using static factory methods.

The herbceptions proposal for “deterministic” exceptions addressed this issue well IMO.

Re: Is C++ Doomed?

#115

Post by Apocryphon »

reincarnate0x14 wrote: post #52

I hope so, because I irrationally decided I didn't like it versus Objective-C a long time ago and I can't wait to be vindicated :) But even if it is doomed, given inertia it will still be a mainstay of HPC and such long after Rust or whatever takes the crown as the language people take the time to complain about, to paraphrase Stroustrup.

For all of the square brackets, Objective-C is a much more pleasant language syntactically speaking than C++.

Re: Is C++ Doomed?

#116

Post by nine_k »

colejohnson66 wrote: post #110
nine_k wrote: post #81

Earlier quoted context omitted.

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.

Certainly you can write C++ for MCUs; the question is, should you, and does the ecosystem encourage that.

OTOH a bigger ARM core can very well be found on a small embedded computer, and it's capable enough to run something like a browser. At this scale, pure C becomes burdensome, and libraries (like a browser engine, or Qt) are in C++ anyway.

Re: Is C++ Doomed?

#117

Post by Const-me »

dataflow wrote: post #105
ghosty141 wrote: post #62

Earlier 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.

> 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:…

> Do you construct your std::vector objects with factories too?

I usually do it like that:

    try
    {
        vec.resize( wantedSize );
    }
    catch( const std::bad_alloc& )
    {
        return E_OUTOFMEMORY;
    }

Re: Is C++ Doomed?

#118

Post by qayxc »

nyanpasu64 wrote: post #112
qayxc wrote: post #63

Earlier quoted context omitted.

This image is mostly painted by people who forgot to stop. By that I mean stop using every feature and detail because it's there. C++ can be used like a much better C (smart pointers, references, const-correctness, generics via templates) and most of the complications can be ignored that way. Premature optimisation is another big factor. If there's no measurable performance bottleneck, things like move-semantics don'…

Does the "much better C" include constructors are not? Smart pointers (which you include) are primarily designed for types with ~Type destructors, and difficult to use with C-style types with free functions for deallocation. And ~Type is difficult (unsure if impossible) to use without constructors, through either new Type or placement new into malloc'd memory. There is the trick of defining a passthrough constructor…

I don't understand the obsession with constructors.

Placement new exists, but I'm not sure that's what you asked w.r.t. placement initialisation, which doesn't make much sense for non-trivial types anyway.

Fallible placement initialisation into allocated memory is something that I honestly don't know a good use case for. It's certainly not something that's very common and I never encountered it.

It's just one of those things that smell like a design that doesn't suit the problem. Do you by any chance have an example for when this would be useful? I'm curious to learn about this.

Implicit copy constructors can be disabled if need be by simply deleting them (Type(Type const&) = delete). It's up to the programmer since the compiler simply cannot know. As far as auto and copies goes: almost always auto&& and when in doubt, spell it out (i.e. don't use auto).

Again, not knowing the semantics isn't really an argument against the language. It also again boils down to a case of premature optimisation if copies concern you even though there must be a profiling log pointing to that being a problem first.

Re: Is C++ Doomed?

#119

Post by Animats »

dathinab wrote: post #108
biesnecker wrote: post #83

Earlier quoted context omitted.

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.

Right. C++ to Rust is a big jump. C++ to C# or Java or D might be automatable. At least the object model is roughly compatible.

Re: Is C++ Doomed?

#120

Post by mbrodersen »

There are 5+ million C/C++ programmers out there. Why? Because most of the world runs on C/C++. Even Java/Python/JavaScript etc. runs on C/C++ VM’s running on top of operating systems written in C/C++. Rust is nice but it will take a very very long time for it to have the kind of impact C/C++ has. If it ever happens.
Post reply on HN