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

71–80 of 103 posts

Re: C++26: Erroneous behaviour

#71

Post by Ygg2 »

wolvesechoes wrote: post #62
Ygg2 wrote: post #60

Earlier quoted context omitted.

> Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Slint, Bevy and no idea what a GPU framework is (even search engines are stumped; they keep recommending Framework laptops). Is it just CUDA? Not gonna lie, what exactly is this mismatch of stuff? How to be C++ in 3001 steps? Ergonomic as C++? That sounds as oxymoronic as "musical as nails on a chalkboard or a ca…

> Slint Where is its equivalent of QGraphicsView? Or QTextDocument? And Slint is probably more mature than any other pure Rust GUI. They, as of now, are little more than toys. Look, I enjoy Rust as well, but be realist.

> Where is its equivalent of QGraphicsView

I wasn't aware having feature parity with was necessary for language to beat C++. I could have sworn Java did it without half of those.

Ultimately it depends what you want to do? Cross platform GUI or winning pointless debates.

If you really want cross platform GUI you pretty much have to use Web based UI. Because Apple is extremely hostile to anything that tries to be native on its platform.

Re: C++26: Erroneous behaviour

#72

Post by Ygg2 »

pjmlp wrote: post #61
Ygg2 wrote: post #60

Earlier quoted context omitted.

> Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Slint, Bevy and no idea what a GPU framework is (even search engines are stumped; they keep recommending Framework laptops). Is it just CUDA? Not gonna lie, what exactly is this mismatch of stuff? How to be C++ in 3001 steps? Ergonomic as C++? That sounds as oxymoronic as "musical as nails on a chalkboard or a ca…

Unreal, Godot, and being on the console devkits are the minimum bar to match. Followed by being integrated into RenderDoc, Pix, Instruments, NSights, for debugging purposes and instrumentation. GPU frameworks is having matching CUDA, Open API, Metal Shading Language, ROCm feature parity, in IDE tooling, graphical debuggers, industry and academic support. Having a seat at the table when Khronos and its partners are di…

Well according to your definition only one language could have ever fit the description.

It had to have a commercial game engine: so C++ or C#. It had to have cross platform GUI with Qt features - so C++, maybe Delphi. And it had to have seat at GPU standards so C, C++ and Python.

Forget Rust. C doesn't fit your criteria. Or Java. Or C#...

By cherry picking your criteria you can create an argument that pre selects one language.

Re: C++26: Erroneous behaviour

#73

Post by tialaramex »

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 crucial difference isn't technology, as others have described Rust's technology is actually an option for C++ though NIH means the committee will prefer anything else. The real difference is cultural.

The difference in API shapes in their respective standard libraries is because of culture not technology. Easy to see example: In C++ the two fundamental sort functions are named sort and stable_sort. In Rust those same two sorts are named sort_unstable and sort, a subtle but crucial safer choice. Or compare C++ vector::pop_back against Rust Vec::pop

Re: C++26: Erroneous behaviour

#74

Post by 0xCAP »

Why are we still trying to get C++ to become a viable choice instead of calling it a day and moving on?

I guess it's my old theory that organisations turn into living beings and start living off of mere survival instinct even past the point of serving any purpose to society.

Re: C++26: Erroneous behaviour

#75

Post by pjmlp »

Ygg2 wrote: post #72
pjmlp wrote: post #61

Earlier quoted context omitted.

Unreal, Godot, and being on the console devkits are the minimum bar to match. Followed by being integrated into RenderDoc, Pix, Instruments, NSights, for debugging purposes and instrumentation. GPU frameworks is having matching CUDA, Open API, Metal Shading Language, ROCm feature parity, in IDE tooling, graphical debuggers, industry and academic support. Having a seat at the table when Khronos and its partners are di…

Well according to your definition only one language could have ever fit the description. It had to have a commercial game engine: so C++ or C#. It had to have cross platform GUI with Qt features - so C++, maybe Delphi. And it had to have seat at GPU standards so C, C++ and Python. Forget Rust. C doesn't fit your criteria. Or Java. Or C#... By cherry picking your criteria you can create an argument that pre selects on…

There are several commercial game engines that were C before being C++, same applies to industry standards in the graphics and games industry.

Console devkits included.

Also the fact that C89 (minus one or two things) is a subset of C++ is still a reality that many studios take advantage of.

Java is indeed not used at all in the commercial games industry, unless the authors only focus on desktop or Android.

There is a reason why the very first thing Microsoft did after Mojang's acquisitions was to rewrite Minecraft into C++ for mobile platform and game consoles. They only don't get rid of Java version due to the modding community.

C# is only used thanks to Unity and even that is powered via C++ engine, and a compiler that translates MSIL bytecode into C++.

Yes, Rust still has a lot to catch up in this GUI and games industry.

On VFX, it isn't even part of the reference platform for the industry,

https://vfxplatform.com/

Re: C++26: Erroneous behaviour

#76

Post by pjmlp »

Ygg2 wrote: post #71
wolvesechoes wrote: post #62

Earlier quoted context omitted.

> Slint Where is its equivalent of QGraphicsView? Or QTextDocument? And Slint is probably more mature than any other pure Rust GUI. They, as of now, are little more than toys. Look, I enjoy Rust as well, but be realist.

> Where is its equivalent of QGraphicsView I wasn't aware having feature parity with was necessary for language to beat C++. I could have sworn Java did it without half of those. Ultimately it depends what you want to do? Cross platform GUI or winning pointless debates. If you really want cross platform GUI you pretty much have to use Web based UI. Because Apple is extremely hostile to anything that tries to be nativ…

Not on desktop, it didn't.

IDEs are the only surviving Java desktop applications, and a few outliers like Bitwig DAW.

Re: C++26: Erroneous behaviour

#77

Post by pwdisswordfishz »

Why bother with this category? The code exercising it is buggy either way, regardless of whether the behaviour is specified or not, and having a fixed definition may constrain implementations and negatively impact performance. And if that "erroneous" definition comes with stability guarantees, then you might not even bother calling it "erroneous" at all, because then it's going to be as toothless as declaring any given JavaScript syntax to be "improper": https://github.com/twbs/bootstrap/issues/3057#issuecomment-5...

Re: C++26: Erroneous behaviour

#78

Post by [deleted] »

aw1621107 wrote: post #25
quotemstr wrote: post #6

Earlier quoted context omitted.

> 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

[deleted]

Re: C++26: Erroneous behaviour

#79

Post by tialaramex »

pwdisswordfishz wrote: post #77

Why bother with this category? The code exercising it is buggy either way, regardless of whether the behaviour is specified or not, and having a fixed definition may constrain implementations and negatively impact performance. And if that "erroneous" definition comes with stability guarantees, then you might not even bother calling it "erroneous" at all, because then it's going to be as toothless as declaring any giv…

Ignoring performance considerations, which I'm happy to address separately if people care, the options were:

#1 Require initialization (like many modern languages). Makes sense. But now your existing C++ doesn't even compile so that's a hard "No" from the committee.

#2 Status quo, evaluating uninitialized variables is Undefined Behaviour. We cannot diagnose this reliably, any attempt will be Best Effort and several vendors already supply this but when it doesn't catch you arbitrary nonsense happens.

#3 Zero init. Now not initializing has defined behaviour, all the diagnostic tools we saw in #2 are invalidated and must be removed, but did you actually mean zero? Awful bugs still occur and now our best tools to solve them are crippled. Ouch.

#4 Erroneous Behaviour. Unlike #3 we do not invalidate those diagnostic tools from #2 because we've said the tool was correct. However, we do avoid Undefined Behaviour, something bad might happen but at least it's something you can reason about and it is clearly stated that it's your fault.

Re: C++26: Erroneous behaviour

#80

Post by Ygg2 »

pjmlp wrote: post #76
Ygg2 wrote: post #71

Earlier quoted context omitted.

> Where is its equivalent of QGraphicsView I wasn't aware having feature parity with was necessary for language to beat C++. I could have sworn Java did it without half of those. Ultimately it depends what you want to do? Cross platform GUI or winning pointless debates. If you really want cross platform GUI you pretty much have to use Web based UI. Because Apple is extremely hostile to anything that tries to be nativ…

Not on desktop, it didn't. IDEs are the only surviving Java desktop applications, and a few outliers like Bitwig DAW.

It didn't except for programs that did?

Well by that measure neither did C/C++. Only few survivors in the deluge of Electron apps.

Chrome and Firefox also use JavaScript/CSS for their GUI.

Post reply on HN