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

C++26: Erroneous behaviour

sandordargo.com

Post reply on HN
Print view View original

21–30 of 103 posts

Re: C++26: Erroneous behaviour

#21

Post by saghm »

mcdeltat wrote: post #13
saghm wrote: post #9

Earlier quoted context omitted.

> do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? This is an interesting perspective to me, because my view as someone who's been using Rust since close to 1.0 and hasn't done much more than dabbled in C++ over the years is basically the opposite. My (admittedly limited) understanding is that this has ne…

It's true that without backwards compatibility concerns, Rust looks like a great alternative. However I think C++ still has some things going for it which may make it a useful option, assuming the core issues were fixed. C++ gives ultimate control over memory and low level things (think pointers, manual stack vs heap, inline assembly). It has good compatibility with C ABIs. It's very general purpose and permissive. A…

I think I might be getting confused about the point you're making here. To me, pre-existing knowledge and the decades-long legacy of C++ feel like much stronger arguments against changing anything in a breaking way compared to making breaking changes to improve the language. I do agree with you around a lot of the new features being introduced not feeling super necessary, but I'm guessing that the stance of people in favor of them is that adding them doesn't feel like it's a huge problem either given that they can do them without breaking anything. My perception is that C++ has already been a fairly large language for a while, and that most codebases already develop a bit of a dialect of which features to use or not use (which you allude to as well), so I could imagine that they expect people who don't like the new features to just ignore them.

I think I'm most confused about the last part that you're saying. A significant overhaul to the language in a breaking way feels pretty much the same as saying "screw it" and starting from scratch, just with specific ergonomic choices being closer to C++ than to Rust. Several of the parts that you cite as the strengths of the language, like inline assembly and pointers are still available in Rust, just not outside of explicitly unsafe contexts, and I'd imagine that an overhaul of C++ to enhance memory safety would end up needing to make a fairly similar compromise for them. It just seems like the language you're wishing for would end up with a fairly narrow design space, even if it is objectively superior to the C++ we have today, because it would have to give up the largest advantage that C++ does have without enough unoccupied room to grow into. The focus on backwards compatibility doesn't seem to be that it would necessarily be the best choice in a vacuum, but a reflection of the state of the ecosystem as it is today, and a perception that sacrificing it would be giving up its position as the dominant language in a well-defined niche to try to compete in a new one. This is obviously a subjective viewpoint, but it doesn't seem implausible to me, and given the fact that we can't really know how it would work out unless they do try, sticking with compatibility feels like the safer option.

Re: C++26: Erroneous behaviour

#22

Post by dwattttt »

saghm wrote: post #21
mcdeltat wrote: post #13

Earlier quoted context omitted.

It's true that without backwards compatibility concerns, Rust looks like a great alternative. However I think C++ still has some things going for it which may make it a useful option, assuming the core issues were fixed. C++ gives ultimate control over memory and low level things (think pointers, manual stack vs heap, inline assembly). It has good compatibility with C ABIs. It's very general purpose and permissive. A…

I think I might be getting confused about the point you're making here. To me, pre-existing knowledge and the decades-long legacy of C++ feel like much stronger arguments against changing anything in a breaking way compared to making breaking changes to improve the language. I do agree with you around a lot of the new features being introduced not feeling super necessary, but I'm guessing that the stance of people in…

The biggest question I have around the viability of breaking changes in C++ is whether you can compile some code with a newer breaking standard, some with an older standard, and link them.

Headers would be a problem given their text inclusion in multiple translation units, but it's not insurmountable; you're currently limited to the oldest standard a header is included into, and under a new standard that breaks compatibility you'd be limited to a valid subset of the old & new standard.

EDIT: ironically modules (as a concept) would (could?) solve the header problem, but they've not exactly been a success story so far.

Re: C++26: Erroneous behaviour

#24

Post by aw1621107 »

webdevver wrote: post #16

C++26, C++29, C++32, ... C++50? Surely all good things come to an end, but where? i reckon there will be a C++29. what about C++38? C++43 sounds terrifying. Mid-century C++? there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11.

> Surely all good things come to an end, but where?

As long as there are people willing to put in the work to convince the standards committee that the proposals they champion are worth adding to C++ (and as long as there is a committee to convince, I suppose), then new versions of C++ will continue to be released.

> there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11.

Sure, different developers will find different features compelling and so will be comfortable living with different standards. That one group is fine with existing features shouldn't automatically prevent another from continuing to improve the language if they can gain consensus, though.

Re: C++26: Erroneous behaviour

#25

Post by aw1621107 »

quotemstr wrote: post #6
mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

> As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? Memory safety semantics aside (needed and will be disruptive, even if done gradually) --- You could get 80% of the way to ergonomic parity via a 1:1 re-syntaxing, just like Reason (new syntax for O…

> You can address a lot of the pain points by making an alternative, clean-looking "modern" syntax that, because it's actually the same language as C++, would have perfect interoperability.

Sounds like Herb Sutter's cpp2/cppfront: https://github.com/hsutter/cppfront

Re: C++26: Erroneous behaviour

#26

Post by aw1621107 »

CoastalCoder wrote: post #7
mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

On the bright side, any sufficiently motivated team can fork the language to try out ideas like yours. Perhaps a better language could even get some traction without major corporate sponsorship. I think (?) rust and zig are examples of that.

> Perhaps a better language could even get some traction without major corporate sponsorship. I think (?) rust and zig are examples of that.

Rust might not count depending on whether you count Mozilla's sponsorship a major corporate sponsorship.

Re: C++26: Erroneous behaviour

#27

Post by wffurr »

mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

>> The committee are really letting the vision of a good C++ down by refusing to break backwards compatibility to fix core problems

IIUC this is what Profiles are. It’s an opt in source file method to ban certain misfeatures and require certain other safe features.

Re: C++26: Erroneous behaviour

#28

Post by jandrewrogers »

mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

The saving grace of C++ is that 80% of my complaints are really about the standard library rather than the language itself. I can replace the standard library with something else more consistent and modern without regard for legacy compatibility, and many people do.

Most of the rest of my complaints could be addressed by jettisoning backward compatibility and switching to more sensible defaults. I realize this will never happen.

C++ still has some unique strengths, particularly around metaprogramming compared to other popular systems languages. It also is pretty good at allowing you to build safe and efficient abstractions around some ugly edge cases that are unavoidable in systems programming. Languages like Rust are a bit too restrictive to handle some of these cases gracefully.

Re: C++26: Erroneous behaviour

#29

Post by TuxSH »

kachapopopow wrote: post #11
mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

I just don't see a reason to use c++ anymore when rust does quite literally, everything better. For prototyping, hacking, firmware and native interfacing though? c++ any time of the day.

> quite literally, everything better

Like retained mode GUIs, games, intrusive containers or anything that can't be trivially represented by a tree of unique_/shared_ptr?

Re: C++26: Erroneous behaviour

#30

Post by TuxSH »

dwattttt wrote: post #22
saghm wrote: post #21

Earlier quoted context omitted.

I think I might be getting confused about the point you're making here. To me, pre-existing knowledge and the decades-long legacy of C++ feel like much stronger arguments against changing anything in a breaking way compared to making breaking changes to improve the language. I do agree with you around a lot of the new features being introduced not feeling super necessary, but I'm guessing that the stance of people in…

The biggest question I have around the viability of breaking changes in C++ is whether you can compile some code with a newer breaking standard, some with an older standard, and link them. Headers would be a problem given their text inclusion in multiple translation units, but it's not insurmountable; you're currently limited to the oldest standard a header is included into, and under a new standard that breaks compa…

> EDIT: ironically modules (as a concept) would (could?) solve the header problem, but they've not exactly been a success story so far.

Because they are little different from precompiled headers. Import std; may be nice, but in a large project you are likely to have your own defines.hpp file anyway (that is going to be precompiled for double-digits compile times reduction).

Ironically too, migrating every header in an executable project to modules might slow down build times, as dependency chains reduce the parallelism factor of the build.

Post reply on HN