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

61–70 of 103 posts

Re: C++26: Erroneous behaviour

#61

Post by pjmlp »

Ygg2 wrote: post #60
pjmlp wrote: post #52

Earlier quoted context omitted.

Python isn't for people that care about performance, and Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Backwards compatibility is what keeps C and C++ relevant, for better or worse. All major languages value backwards compatibility to certain extent. Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things aroun…

> 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 discussing the next GPU standards, so far only C, C++ and most recently Python, have a seat allocated.

Re: C++26: Erroneous behaviour

#62

Post by wolvesechoes »

Ygg2 wrote: post #60
pjmlp wrote: post #52

Earlier quoted context omitted.

Python isn't for people that care about performance, and Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Backwards compatibility is what keeps C and C++ relevant, for better or worse. All major languages value backwards compatibility to certain extent. Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things aroun…

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

Re: C++26: Erroneous behaviour

#63

Post by pjmlp »

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.

Or Qt Design Studio for that matter, and integration with designer tools.

Re: C++26: Erroneous behaviour

#64

Post by tempodox »

Kranar wrote: post #32
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…

There is a version of C++ that adds complete memory safety to the language by adding features to the language in a way that preserves complete backwards compatibility with existing C++ source code. That version of C++ is called Circle/Safe C++, it represents a monumental amount of effort that was written by a single individual, and it's a complete disgrace that the C++ committee has informally shut the door on that i…

There is even a reference implementation, so it could be added to existing compilers?

That would at the very least be better than what we have now.

Re: C++26: Erroneous behaviour

#65

Post by wolvesechoes »

quamserena wrote: post #51
jjmarr wrote: post #45

Earlier quoted context omitted.

> Safe rust doesn't segfault ever . https://github.com/Speykious/cve-rs > That is why cve-rs uses #![deny(unsafe_code)] in the entire codebase. There is not a single block of unsafe code (except for some tests) in this project. > cve-rs implements the following bugs in safe Rust: * Use after free * Buffer overflow * Segmentation fault

Rust’s borrow checker has been mathematically verified to be always sound.[0] These are edge case implementation bugs that user code is unlikely to touch. I have never had a soundness hole/segfault from safe Rust, and I am not aware of any code in the wild which stumbled into one of these soundness holes either. The main bug is [1], which is very contrived lifetime shenanigans that wouldn't appear in real code. Some…

So it is not 100% contrary to some bombastic claims floating around.

Re: C++26: Erroneous behaviour

#66

Post by aw1621107 »

jb1991 wrote: post #43
Kranar wrote: post #38

Earlier quoted context omitted.

The committee very politely showed him the door.

Which individual are you referring to?

Almost certainly Sean Baxter, the person behind the Safe C++ proposal and its reference implementation (via Circle, which also implements some unrelated features)

Re: C++26: Erroneous behaviour

#67

Post by aw1621107 »

LoganDark wrote: post #39
Kranar wrote: post #38

Earlier quoted context omitted.

The committee very politely showed him the door.

Yes, I got that much, but I'm curious to see what happened. Do you have any links about it?

The interpretation is probably up for some debate especially since meeting details are not public, but some relevant links are:

- The P3390R0 Safe C++ proposal and the related vote in the 2024-11 Wrocław meeting: https://github.com/cplusplus/papers/issues/2045

- The adoption of the paper P3466 R1 (Re)affirm design principles for future C++ evolution at the same meeting, which contains language which can be interpreted as preemptively foreclosing a Safe C++-style approach: https://github.com/cplusplus/papers/issues/2121

Re: C++26: Erroneous behaviour

#68

Post by tempodox »

saghm wrote: post #9
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…

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

With C++ I can use Qt to make a GUI app that builds and runs on macOS, Linux, and Windows. Is there anything even close to that for Rust?

Re: C++26: Erroneous behaviour

#69

Post by ladyanita22 »

pjmlp wrote: post #56
leoh wrote: post #53

Earlier quoted context omitted.

Really? I have found the UX stuff with egui to be super ergonomic. It's not "native", though. Trying to do macOS UX with it, I have found, generally sucks (curious if anyone knows of any good libraries). Then again C++ probably sucks for native macOS too. So I really don't think Rust is far off.

Yes really, because it is nothing like Qt, in IDE integration, tools for designers, or ecosystem from 3rd parties components. C++ sucks for macOS, because it was never a first party language, unless using it via Objective-C++. The only role of C++ in macOS is for drivers, LLVM and being the Metal Shader Language (C++14 with extensions).

Aren't apps, core system components et al built in C++? That was my impression.

Re: C++26: Erroneous behaviour

#70

Post by pjmlp »

ladyanita22 wrote: post #69
pjmlp wrote: post #56

Earlier quoted context omitted.

Yes really, because it is nothing like Qt, in IDE integration, tools for designers, or ecosystem from 3rd parties components. C++ sucks for macOS, because it was never a first party language, unless using it via Objective-C++. The only role of C++ in macOS is for drivers, LLVM and being the Metal Shader Language (C++14 with extensions).

Aren't apps, core system components et al built in C++? That was my impression.

Objective-C, the main difference to NeXTSTEP is that DriverKit changed from Objective-C into C++ with IO Kit, that uses Embedded C++ in a COM like approach.

In an homage to NeXTSTEP, the userspace version of IO Kit is named DriverKit.

There are some frameworks that might use C++ in their implementations, like Core Audio, however they are exposed to userspace as C APIs and Objective-C frameworks.

Hence why Apple nowadays mostly cares about LLVM, clang is good enough for their limited uses of C++.

https://developer.apple.com/xcode/cpp/

https://cppreference.com/w/cpp/compiler_support.html

Post reply on HN