Soursop and Ponies in Kona: A C++ Committee Trip Report • Hacker News Board

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#61

Post by WalterBright » Mon, Nov 28, 2022, 4:41 AM UTC

kllrnohj wrote: post #60

WalterBright wrote: post #54

Earlier quoted context omitted.

Adds: 1. convenience 2. attractive appearance 3. ubiquity 4. better error messages (because compiler knows what they are) 5. one construct instead of two (vector and span) 6. overflow behavior selectable with compiler switch For example: #include std::vector v; vs: int[] v; Many D users have remarked that it's the single best feature of D.

> 3. ubiquity Hardly. A std library update is often easier and faster to ship than a new compiler toolchain. Especially in C/C++ world, although it is moderately uniquely terrible in this regard > 5. one construct instead of two (vector and span) Incorrect. Vector is an owned type, while both span and your proposal are borrowed types. > 6. overflow behavior selectable with compiler switch That sounds an awful lot lik…

My proposal also uses [] as an owned type.

> It's not generally desirable for code behavior to change depending on how it's compiled, makes debugging kinda hard.

It only changes the behavior of what happens after the program has already failed. People want different behaviors, depending on their environment, and like having the choice.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#62

Post by WalterBright » Mon, Nov 28, 2022, 4:46 AM UTC

olliej wrote: post #57

WalterBright wrote: post #42

> One of the concerns is that C and C++ are being discouraged for new projects by several branches of the US government[1], which makes memory safety important to address. The biggest memory safety problem for C is array overflows. I proposed a simple, backwards compatible change to C years ago, and it has received zero traction. Note that we have 20 years of experience in D of how well it works. https://www.digitalm…

But that change is by definition not backwards compatible - neither ABI nor source level. Using an ifdef to maintain source level compatibility doesn't work as two pieces of code will see the same function using different ABIs. That said I agree entirely - the conflation of array and pointer is the biggest flaw, it's what "necessitated" the null termination error that people are so fond of calling the biggest mistake…

Sorry, I meant it does not break existing code.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#63

Post by olliej » Mon, Nov 28, 2022, 5:46 AM UTC

WalterBright wrote: post #62

olliej wrote: post #57

Earlier quoted context omitted.

But that change is by definition not backwards compatible - neither ABI nor source level. Using an ifdef to maintain source level compatibility doesn't work as two pieces of code will see the same function using different ABIs. That said I agree entirely - the conflation of array and pointer is the biggest flaw, it's what "necessitated" the null termination error that people are so fond of calling the biggest mistake…

Sorry, I meant it does not break existing code.

Fair enough - but I also get the point that it's absurd that "modern" "safe" C++ is invariably more obnoxious and verbose than the unsafe version.

Then when new syntax _is_ added, there is no attempt to fix anything. My favorite example is the iterator syntax:

    for (thing: things) ...

Being defined as equivalent to

    for (iter = things.begin(), end = things.end(); iter != end; ++iter) { thing = *iter; ... }

Which is great because it makes any kind of range checking or reallocation safe enumeration much slower. All just to allow the spec to avoid making changes to existing "idiomatic" begin()/end() based code.

So prior to this syntax I had made the WebKit Vector class perform bounds checking on any indexed access, in all build modes. So enumeration was generally indexed, because begin()/end() are atrocious, and that meant that enumeration was both bounds and reallocation safe. But then the enumeration syntax came along, specifically in terms of begin()/end() - and I was never able to make an iterator that could have the required semantics that didn't simply shit the perf bed.

So now you have a new "modern" C++ iterator that is strictly less safe than the old form of iteration, and for which a safe and secure iterator is intrinsically hard to optimize due to the semantics of the rest of the language. Hurrah.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#64

Post by WalterBright » Mon, Nov 28, 2022, 7:53 AM UTC

olliej wrote: post #63

WalterBright wrote: post #62

Earlier quoted context omitted.

Sorry, I meant it does not break existing code.

Fair enough - but I also get the point that it's absurd that "modern" "safe" C++ is invariably more obnoxious and verbose than the unsafe version. Then when new syntax _is_ added, there is no attempt to fix anything. My favorite example is the iterator syntax: for (thing: things) ... Being defined as equivalent to for (iter = things.begin(), end = things.end(); iter != end; ++iter) { thing = *iter; ... } Which is gre…

For D it looks like:

    for (thing; things) { ... }

which is rewritten as:

    for (auto r = things; !r.empty; r.popFront) { auto thing = r.front; ... }

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#65

Post by pjmlp » Mon, Nov 28, 2022, 7:57 AM UTC

kllrnohj wrote: post #51

WalterBright wrote: post #42

> One of the concerns is that C and C++ are being discouraged for new projects by several branches of the US government[1], which makes memory safety important to address. The biggest memory safety problem for C is array overflows. I proposed a simple, backwards compatible change to C years ago, and it has received zero traction. Note that we have 20 years of experience in D of how well it works. https://www.digitalm…

C++ already has vector and now has span. Your proposal doesn't add anything over those.

Which only do bounds checking in debug builds, or when explicitly use the compiler switches to enable them in release builds, good luck trying to advocate for using at() everywhere instead of braces.

Before C++ got the STL, all collections libraries shipped with compilers used to have bounds checking enabled by default, apparently that is too much performance loss for the standard library.

Walter's proposal added bounds checking being used unless explicitly disabled, like in any sane systems language.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#66

Post by pjmlp » Mon, Nov 28, 2022, 7:59 AM UTC

slavik81 wrote: post #52

> I propose that C++ initialize all stack variables to zero, preventing ~10% of CVEs. This can be done by compilers without any change to the language standard.

It can, but then most don't use it, even though Windows and Android have proven you can ship that into production with hardly any noticeble performance loss.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#67

Post by kllrnohj » Mon, Nov 28, 2022, 6:07 PM UTC

pjmlp wrote: post #65

kllrnohj wrote: post #51

Earlier quoted context omitted.

C++ already has vector and now has span. Your proposal doesn't add anything over those.

Which only do bounds checking in debug builds, or when explicitly use the compiler switches to enable them in release builds, good luck trying to advocate for using at() everywhere instead of braces. Before C++ got the STL, all collections libraries shipped with compilers used to have bounds checking enabled by default, apparently that is too much performance loss for the standard library. Walter's proposal added bou…

Nobody has ever accused C++ of having good defaults. That is also unfortunately one of the hardest things possible to change without language-fragmentating mega breakages (see Python3)

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#68

Post by WalterBright » Mon, Nov 28, 2022, 9:35 PM UTC

pjmlp wrote: post #65

kllrnohj wrote: post #51

Earlier quoted context omitted.

C++ already has vector and now has span. Your proposal doesn't add anything over those.

Which only do bounds checking in debug builds, or when explicitly use the compiler switches to enable them in release builds, good luck trying to advocate for using at() everywhere instead of braces. Before C++ got the STL, all collections libraries shipped with compilers used to have bounds checking enabled by default, apparently that is too much performance loss for the standard library. Walter's proposal added bou…

As experience has shown, bounds checking is needed in the release builds, because those array overflows are only discovered by hackers in the released software.

D compilers allow that to be turned off, but it's only appropriate when:

1. evaluating how much the checking costs in runtime performance

2. doing competitive benchmarking

Otherwise, it should always be on.

Re: Soursop and Ponies in Kona: A C++ Committee Trip Report

#69

Post by pjmlp » Tue, Nov 29, 2022, 7:03 AM UTC

WalterBright wrote: post #68

pjmlp wrote: post #65

Earlier quoted context omitted.

Which only do bounds checking in debug builds, or when explicitly use the compiler switches to enable them in release builds, good luck trying to advocate for using at() everywhere instead of braces. Before C++ got the STL, all collections libraries shipped with compilers used to have bounds checking enabled by default, apparently that is too much performance loss for the standard library. Walter's proposal added bou…

As experience has shown, bounds checking is needed in the release builds, because those array overflows are only discovered by hackers in the released software. D compilers allow that to be turned off, but it's only appropriate when: 1. evaluating how much the checking costs in runtime performance 2. doing competitive benchmarking Otherwise, it should always be on.

Exactly, as any sane systems programming language. :)

I always force enable bounds checking on C++ code, never had a performance issue where the real culprit wasn't something else, wrong algorithm or data structure for the problem at hand.