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

31–40 of 103 posts

Re: C++26: Erroneous behaviour

#31

Post by Kranar »

wffurr wrote: post #27
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.

Safety profiles don't exist and there are so many issues with them that it's unlikely they will ever get added to the language. For example, you mention how it's a method applied to a source file, but C++ doesn't have the concept of a source file, it only knows about translation units.

But then the problem becomes where exactly do you opt-in to this feature? If you do it in a header file then this can result in a function being compiled with the safety profile turned on in one translation unit and then that exact same function is compiled without that safety profile in another translation unit... which ironically results in one of the most dangerous possible outcomes in C++, the so-called ODR violation.

If you don't allow safety-profiles to be turned on in header files, then you've now excluded a significant amount of code in the form of templates, constexpr and inline functions.

Re: C++26: Erroneous behaviour

#32

Post by Kranar »

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 individual:

https://safecpp.org/draft.html

Re: C++26: Erroneous behaviour

#33

Post by benreesman »

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 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 the output of a build.

And with the build done right? Maybe you dont want C++ if youre both moving fast and doing safety or security critical stuff (as in, browser, sshd, avionics critical) but you shouldnt be moving fast on avoinics software to begin with.

And for stuff outside of that "even one buffer overflow is too many" Venn?

C++ doesn't segfault more than either of those after its cleared clang-tidy and ASAN. Python linking shoddy native stuff crashes way more.

Re: C++26: Erroneous behaviour

#34

Post by socalgal2 »

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 think it's like 50/50. There's been proposals for various things like --perfectly-safe-subset-only (making that up). But there's so much to fix and so much arguing about whether it should actually be fixed or not.

I would personally like a safe (and fast) subset that doesn't require me to be vigilant but catches every thing I could do wrong to the same level as rust. Then, like rust, you could remove that flag for a few low-level parts that for some reason need to be "unsafe" (maybe because they call into the OS).

There was a good talk from the WebKit team about stuff they did to get more safety.

https://www.youtube.com/watch?v=RLw13wLM5Ko

Some of it was AST level checks. IIRC, they have a pre-commit check that there is no pointer math being used. They went over how to change code with pointer math into safe code with zero change in performance.

A similar one was Ref usage checking where they could effectively see a ref counted object was being passed to as a raw pointer to a function that might free the ref and then still used in the calling function. They could detect that with an AST based checker.

That said, I have no idea how they (the C++ committee) are going to fix all the issues. --no-undefined-behavior would be a start. Can they get rid of the perf bombs with std::move? Why do I have to remember that shit?

Re: C++26: Erroneous behaviour

#35

Post by Kranar »

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…

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

This is not true. From within your parent class you use an explicit hashing callable, and then from outside of the parent class you can go back to using the default std::hash.

The result looks like this:

    struct Foo {
      struct Bar {};
      struct BarHasher {
        std::size_t operator ()(const Bar&) const noexcept;
      };
      std::unordered_set bar_set;
    };

    namespace std {
      template
      struct hash {
        std::size_t operator()(const Foo::Bar& b) const noexcept {
          return Foo::BarHasher()(b);
        }
      };
    }
The std::hash specialization at the end is legal and allows other users of Foo::Bar to use std::unordered_set without needing the explicit BarHasher.

Re: C++26: Erroneous behaviour

#36

Post by almostgotcaught »

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've used C++ for so long and I'm a good way into thinking that the language is just over

"no one goes there anymore it's too crowded"

Re: C++26: Erroneous behaviour

#37

Post by LoganDark »

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…

> it's a complete disgrace that the C++ committee has informally shut the door on that individual

What do you mean?

Re: C++26: Erroneous behaviour

#38

Post by Kranar »

LoganDark wrote: post #37
Kranar wrote: post #32

Earlier quoted context omitted.

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…

> it's a complete disgrace that the C++ committee has informally shut the door on that individual What do you mean?

The committee very politely showed him the door.

Re: C++26: Erroneous behaviour

#39

Post by LoganDark »

Kranar wrote: post #38
LoganDark wrote: post #37

Earlier quoted context omitted.

> it's a complete disgrace that the C++ committee has informally shut the door on that individual What do you mean?

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?

Re: C++26: Erroneous behaviour

#40

Post by galangalalgol »

benreesman wrote: post #33
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 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 fragmented package management and build systems, and syntax that lets me express things I don't want to, like a race condition. Python slows me down because the duck typing can't help me reason about my design like static explicitly converted types can.
Post reply on HN