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

51–60 of 168 posts

Re: Is C++ Doomed?

#51

Post by ridiculous_fish »

OP is trying to create a circular queue by using malloc(). This may be a good learning exercise, but the code could be made much simpler by just wrapping `std::vector`. Working with raw uninitialized memory is difficult in any language.

Most of the article was about C++ exceptions specifically, and I agree C++ exceptions are probably "doomed." They are already disfavored by major codebases (Google, LLVM, others). It is indeed unreasonably hard to make exception-safe C++ containers.

One possible future path here is Herb Sutter's Zero Overhead Deterministic Exceptions [1] which "throws" values through the ordinary return path, as is done in Swift/Rust/Go etc.

I don't know how `bad_alloc` will get handled, but I'm not sure how useful that even is any more, given Linux memory overcommit. Curious to know if anyone takes bad_alloc seriously?

> Let’s say I want to know if a constructor failed

Usual advice here is "don't write fallible constructors." Use a factory function instead.

I can't agree with some of the other points. I don't see how "copies that result from calling a function have a different meaning to regular copies." RVO became guaranteed in C++11, and you don't need to worry about value categories when implementing move or copy constructors. C++ is not an easy language but it does have rules. And most of the time this stuff can be ignored: if I copy a string an extra time it usually doesn't matter.

1: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...

Re: Is C++ Doomed?

#52

Post by reincarnate0x14 »

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.

Re: Is C++ Doomed?

#53

Post by CyberRabbi »

hermitdev wrote: post #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 I'm sorry, I'm not trying to be negative towards the author, but you…

His point is that C code often calls into C++ code. This is always incorrect unless the C++ entry point is guaranteed not to throw an exception. This is especially bad since this is not automatically checked by default.

Re: Is C++ Doomed?

#55

Post by jvanderbot »

flyingfences wrote: post #40
uoaei wrote: post #3

Gonna be a long while before safety and certification bodies for industries like aerospace move away from C++. All the tools for the past few decades focus on C++ as the main systems language in these cases. Rust is great as a spiritual successor with more stable performance (in general) but the institutional inertia with C++ is strong.

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.

In this aerospace company, we use C, and sometimes a subset of C++ that is basically C+epsilon. That's all new, however, so each new project that goes that direction is walking a dark forest.

We've got some Rust on the ISS, but honestly, the interest from the serious FSW folks isn't there.

Re: Is C++ Doomed?

#56

Post by morelisp »

hermitdev wrote: post #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 I'm sorry, I'm not trying to be negative towards the author, but you…

But this also shows a lot of warts that mean RAII isn't "really working", as in it isn't reducing the mental load of resource management as far as we'd like.

- You've needed to manually specify the deleter. Why do I need to invent unique_file_t myself? The stdlib is failing to support idiomatic language use.

- Probably most critically, fp can be null! If A is I, then I is A, yet here we are with a resource in-scope but not allocated!

- You've had to manually add a scope to handle it, and (unlike e.g. Python with or Java try) there's nothing per se to indicate that's what the scope is for. SBRM is supposed to be interesting because of how often our scopes align with lifetimes naturally; manually adding a scope isn't too far from manually calling a destructor.

Please don't respond with the reasons "why" it is this way; we all know. That also doesn't change that they are still major warts that undermine safe, clean C++.

Re: Is C++ Doomed?

#57

Post by nine_k »

uoaei wrote: post #3

Gonna be a long while before safety and certification bodies for industries like aerospace move away from C++. All the tools for the past few decades focus on C++ as the main systems language in these cases. Rust is great as a spiritual successor with more stable performance (in general) but the institutional inertia with C++ is strong.

Aerospace industry? C++? Frightening.

I thought Ada is prevalent in this space.

Re: Is C++ Doomed?

#58

Post by LoveGracePeace »

Simple, it's a war between those who are Pascal inclined (and probably liked Macs and Steve Jobs) e.g. (https://www.quora.com/Why-does-the-type-go-after-the-variabl... - add Rust, Kotlin and Scala) and those who know the best languages, the ones that are actually used in production at companies large and small worldwide: C, C++, Java and C#. IOW, if the language does "type varname" then it's correct, if it does "varname: type" then it is doomed. It's sarcasm but it's true.

Re: Is C++ Doomed?

#59

Post by rowls66 »

sharikous wrote: post #16
zwieback wrote: post #5

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…

No post body was provided.

Re: Is C++ Doomed?

#60

Post by AnimalMuppet »

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 optional. I can sort of twist my mind that far, but it's not idiomatic. (It might become so, I suppose...)

Post reply on HN