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

121–130 of 168 posts

Re: Is C++ Doomed?

#121

Post by dataflow »

Const-me wrote: post #117
dataflow wrote: post #105

Earlier quoted context omitted.

> 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; }

Yeah but that's completely avoiding my point. You're claiming constructors aren't supposed to throw, but I'm pointing out the standard explicitly lets vector's constructors fail, and there's no other mechanism to handle that failure than by catching the exception (it's literally designed that way). It's fine if you prefer not to use those constructors in the first place, but that's kind of beside my point about what constructors are "supposed" to do.

Re: Is C++ Doomed?

#122

Post by AnimalMuppet »

henning wrote: post #111
AnimalMuppet wrote: post #60

Earlier quoted context omitted.

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.

In what possible way can RAII be said to do those things?

Re: Is C++ Doomed?

#123

Post by Shadonototra »

Animats wrote: post #17

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…

rust is not good for game dev

compilation time is even worse than c++

there are hidden allocations EVERYWHERE that you can't even control

stop trying to push that narrative, it makes rust look bad

rust is nice if you target things like drivers, anything else it's bad

the other day i read people who thought rust could replace javascript

just take a nap and move on, you are delusional

Re: Is C++ Doomed?

#124

Post by Const-me »

dataflow wrote: post #121
Const-me wrote: post #117

Earlier quoted context omitted.

> 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; }

Yeah but that's completely avoiding my point. You're claiming constructors aren't supposed to throw, but I'm pointing out the standard explicitly lets vector's constructors fail, and there's no other mechanism to handle that failure than by catching the exception (it's literally designed that way). It's fine if you prefer not to use those constructors in the first place, but that's kind of beside my point about what…

> but I'm pointing out the standard explicitly lets vector's constructors fail

Yeah, but that thing has more than one constructor. Since C++/17, the default constructor of std::vector which doesn’t allocate any storage is usually marked as noexcept, i.e. the standard does not allow it to throw anything. This feature allows to make classes which contain vectors yet don’t throw exceptions from constructors.

P.S. The move constructor of std::vector is marked with noexcept as well, i.e. it’s even possible to construct non-empty vectors without any exceptions.

Re: Is C++ Doomed?

#125

Post by 3836293648 »

beached_whale wrote: post #74
bodhiandphysics wrote: post #15

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.

that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as good as returning nullptr, in this case. And what strength of an exception guarantee does one really need? A basic guarantee is not that bad to give and most things do not need to worry if they don't use unmanaged resources without RAII types(e.g pointers). But t…

Exceptions as a concept weren't a mistake, but their specific details and implementation absolutely is.

Re: Is C++ Doomed?

#126

Post by dataflow »

Const-me wrote: post #124
dataflow wrote: post #121

Earlier quoted context omitted.

Yeah but that's completely avoiding my point. You're claiming constructors aren't supposed to throw, but I'm pointing out the standard explicitly lets vector's constructors fail, and there's no other mechanism to handle that failure than by catching the exception (it's literally designed that way). It's fine if you prefer not to use those constructors in the first place, but that's kind of beside my point about what…

> but I'm pointing out the standard explicitly lets vector's constructors fail Yeah, but that thing has more than one constructor. Since C++/17, the default constructor of std::vector which doesn’t allocate any storage is usually marked as noexcept, i.e. the standard does not allow it to throw anything. This feature allows to make classes which contain vectors yet don’t throw exceptions from constructors. P.S. The mo…

Try https://en.cppreference.com/w/cpp/container/set/set

Re: Is C++ Doomed?

#127

Post by nyanpasu64 »

qayxc wrote: post #118
nyanpasu64 wrote: post #112

Earlier quoted context omitted.

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

> I don't understand the obsession with constructors.

The article describes how smart pointers are more difficult to use for opaque/POD structs without destructors. Correct me if I'm wrong, but I think types with destructors generally require constructors too (though you can sometimes rely on default destructors/constructors, by holding fields which themselves have destructors/constructors).

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

Understandable. Rust lacks any safe means for placement initialization (even infallible), resulting in stack overflows (often disappearing in optimized release builds) when allocating large heap arrays (because it has to stack-allocate the array, then memcpy to the heap), eg. https://github.com/rust-lang/rust/issues/53827. I haven't encountered this firsthand though.

> It also again boils down to a case of premature optimisation

Copying can be a correctness issue as well as performance. One time I wrote a function which took an object by copy (when I should've passed by reference), and returned a reference to the object, resulting in a use-after-free. Additionally mutating a copy doesn't mutate the original object, unlike a non-const reference.

Re: Is C++ Doomed?

#128

Post by beached_whale »

3836293648 wrote: post #125
beached_whale wrote: post #74

Earlier quoted context omitted.

that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as good as returning nullptr, in this case. And what strength of an exception guarantee does one really need? A basic guarantee is not that bad to give and most things do not need to worry if they don't use unmanaged resources without RAII types(e.g pointers). But t…

Exceptions as a concept weren't a mistake, but their specific details and implementation absolutely is.

I am curious, what would you change?

Re: Is C++ Doomed?

#129

Post by atq2119 »

brigade wrote: post #79
cenny wrote: post #32

I'm no C++ expert. But Wouldn't a private constructor and a static method that returns nil if input is bad fix this problem? Joshua Kerievsky talks a bout this problem in his book [Refactoring to patterns]( https://www.programmingbooks.dev/#refactoring-to-patterns ), specifically the refactoring "Replace Constructors with Creation Methods" That is maybe beside the point of the articles argument he is making about C++…

Then you can't allocate the object in-place (e.g. on the stack), and also you have to ban copy assignment/construction. Probably a more common solution is like what STL's own fstream does - don't throw an exception on construction, and have a "not valid" state.

Sorry to say it, but your C++ knowledge seems outdated. What the gp comment explained is perfectly viable due to (Named) Return Value Optimization is for. Compilers have been doing that for a while and it's mandatory since C++17.

Yes, C++ has started changing a lot about a decade ago, and despite what the naysayers claim, most of the changes (like this one) are for the better.

Re: Is C++ Doomed?

#130

Post by thecosmicfrog »

potbelly83 wrote: post #87
flyingfences wrote: post #40

Earlier quoted context omitted.

In this aerospace company, we use C, no C++ allowed, to avoid all the extra footguns that get in the way of safety and certification. Rust will probably be the next choice on the scene, but I expect it'll take as long to come as Ada took to go.

Off topic, but curious why Ada went?

Would also be curious to know this. I had heard (anecdotally) that Ada is commonplace in aerospace tech.
Post reply on HN