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

41–50 of 103 posts

Re: C++26: Erroneous behaviour

#41

Post by jb1991 »

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 have to disagree, I find the language quite elegant if you primarily use modern features. It continues to improve with every new standardization. The old style of writing C++ should indeed die.

Re: C++26: Erroneous behaviour

#42

Post by jenadine »

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…

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

So does Rust.

> It's very general purpose and permissive

I don't really understand this point.

> And there are many programmers with C++ (or C) knowledge out there already

Indeed, the only thing C++ has for it is it's legacy: Lots of projects written in C++ and many programmer who knows the language. And that's exactly why it is difficult to change.

When there are new features added to the language, it takes time to adjust because the old code isn't getting converted by itself, and the devs need to learn and get used to the new features.

(If you can afford to teach your team new features of C++, you can as well teach your team Rust.)

Re: C++26: Erroneous behaviour

#44

Post by jenadine »

dwattttt wrote: post #14

> with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game. Unless they were incumbent and inertia keeps them in. Or they're the only choice you have for a niche target. Or you have some other reason to keep them, such as (thinking?) the performance they bring is more important.

> The performance they bring is more important

For this case, there is the [[indeterminate]] attribute.

Re: C++26: Erroneous behaviour

#45

Post by jjmarr »

galangalalgol wrote: post #40
benreesman wrote: post #33

Earlier quoted context omitted.

I dramatically prefer modern C++ to either of Python or Rust in domains where it's a toss up. It's really nice these days. Like any language that lasts (including Python and Rust) you subset it over time: you end up with linters and sanitizers and static analyzers and LSP servers, you have a build. But setting up a build is a one-time cost and maintaining a build is a fact of life, even JavaScript is often/usually th…

I agree that python is often painful to get right. But asan really, doesn't help you unless you have tests that cover the path with the mistake it would catch. Safe rust doesn't segfault ever . Unsafe rust is still easier to get right for me than c, but mostly because c targets weird architectures with weird rules. Rust is also easier for me to develop fast in than either python or c++. For c++ that is because fragme…

> 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

Re: C++26: Erroneous behaviour

#46

Post by jb1991 »

ghosty141 wrote: post #8
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…

Absolutely spot on in my opinion. Also things often just don’t compose well. For example if you have a nested class that you want to use in an unordered_set in its parent class then you just can’t do it because you can’t put the std::hash specialization anywhere legal. It’s just two parts of the language which are totally valid on their own but don’t work together. Stuff like this is such a common problem in c++ that…

The example you mentioned here suffers from a design program, not a language problem.

Re: C++26: Erroneous behaviour

#47

Post by jb1991 »

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.

Writing cross-platform code between CPU and GPU, a very common occurrence, is certainly one reason to use C++.

Re: C++26: Erroneous behaviour

#48

Post by jenadine »

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.

There is also COBOL 2023 and Fortran 2023. C++ will probably be quite niche in a few decades, but I don't see why it should stop being updated.

Re: C++26: Erroneous behaviour

#49

Post by kachapopopow »

jb1991 wrote: post #47
kachapopopow wrote: post #11

Earlier quoted context omitted.

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.

Writing cross-platform code between CPU and GPU, a very common occurrence, is certainly one reason to use C++.

gpu-rs (hopefully) will do it better including all the sub-projects around it.

Re: C++26: Erroneous behaviour

#50

Post by kachapopopow »

TuxSH wrote: post #29
kachapopopow wrote: post #11

Earlier quoted context omitted.

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?

kinda don't get me wrong c++ is useful, however, rust is a platform language and should be used as such, like c++, but much further than that.

modern games are almost never made in a native language, but rather on a language on top of it, be it squirle, lua, blueprints, c#, wasm, javascript, state trees, binary trees, decision trees...

Post reply on HN