Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26 is done: ISO C++ standards meeting Trip Report

herbsutter.com

Post reply on HN
Print view View original

191–200 of 437 posts

Re: C++26 is done: ISO C++ standards meeting Trip Report

#191

Post by m-schuetz »

kajaktum wrote: post #121
addaon wrote: post #17

Earlier quoted context omitted.

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

C++ needs to give itself up and make way for other, newer, modern, language that have far, far fewer baggage. It should be working with other language to provide tools for interop and migration. C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility. It does not matter what version of C++ you are using, you are still using C with classes.

C++ isn't great but so far I haven't seen anything I'd rather use.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#192

Post by dbdr »

ozgrakkurt wrote: post #163
addaon wrote: post #17

Earlier quoted context omitted.

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

I don’t understand this “next evolution” approach to language design. It should be done at some point. People can always develop languages with more or less things but piling more things on is just not that useful. It sounds cool in the minds of people that are designing these things but it is just not that useful. Rust is in the same situation of adding endless crap that is just not that useful. Specifically about t…

What "endless crap that is just not that useful" has been added to Rust in your opinion?

Re: C++26 is done: ISO C++ standards meeting Trip Report

#193

Post by Asmod4n »

dataflow wrote: post #32

> Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release. How far is Clang on reflection and contracts?

Bloomberg has a clang implementation of reflection: https://github.com/bloomberg/clang-p2996

It has been on compiler explorer for a while

This has been used to add reflection to simdjson

Re: C++26 is done: ISO C++ standards meeting Trip Report

#194

Post by uecker »

mastermage wrote: post #173
stackghost wrote: post #86

Earlier quoted context omitted.

>the mandate ended, and Ada faded from the spotlight Exactly. People stopped using Ada as soon as they were no longer forced to use it. In other words on its own merits people don't choose it.

Ada is a greatly designed language and I mean this. The problem Ada has is highly proprietary compilers.

Not having experience myself, how is GNAT?

Re: C++26 is done: ISO C++ standards meeting Trip Report

#195

Post by tialaramex »

rienbdj wrote: post #188
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Many of the recent C++ standards have been focused on expanding and cleaning up its powerful compile-time and metaprogramming capabilities, which it initially inherited by accident decades ago. It is difficult to overstate just how important these features are for high-performance and high-reliability systems software. These features greatly expand the kinds of safety guarantees that are possible to automate and the…

> One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++. Aren’t Rust macros more powerful than C++ template metaprogramming in practice?

Rust has two separate macro systems. It has declarative "by example" macros which are a nicer way to write the sort of things where you show an intern this function for u8 and ask them to create seven more just like it except for i8, u16, i16, u32, i32, u64, i64. Unlike the C pre-processor these macros understand how loops work (sort of) and what types are, and so on, and they have some hygiene features which make them less likely to cause mayhem.

Declarative macros deliberately don't share Rust's syntax because they are macros for Rust so if they shared the same syntax everything you do is escape upon escape sequence as you want the macro to emit a loop but not loop itself etc. But other than the syntax they are pretty friendly, a one day Rust bootstrap course should probably cover these macros at least enough that you don't use copy-paste to make those seven functions by hand.

However the powerful feature you're thinking of is procedural or "proc" macros and those are a very different beast. The proc macros are effectively compiler plugins, when the compiler sees we invoked the proc macro, it just runs that code, natively. So in that sense these are certainly more powerful, they can for example install Python, "Oh, you don't have Python, but I'm a proc macro for running Python, I'll just install it...". Mara wrote several "joke" proc macros which show off how dangerous/ powerful it is, you should not use these, but one of them for example switches to the "nightly" Rust compiler and then seamlessly compiles parts of your software which don't work in stable Rust...

Re: C++26 is done: ISO C++ standards meeting Trip Report

#196

Post by uecker »

extrabajs wrote: post #160
addaon wrote: post #63

Earlier quoted context omitted.

As with Spark, proving properties over a subset of the language is sufficient. Code is written to be verified; we won’t be verifying interesting properties of large chunks of legacy code in my career span. The C (near-) subset of C++ is (modulo standard libraries) a starting point for this; just adding on templates for type system power (and not for other exotic uses) goes a long way.

I don’t think this is a good comparison. Ada (on which Spark is based) has every safety feature and guardrail under the sun, while C++ (or C) has nothing.

There is a lot of tooling for C though, just not in mainstream compilers.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#197

Post by karmakurtisaani »

zzzoom wrote: post #139
suby wrote: post #11

I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified. Here's a quote from Bjarne, > So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much…

That's a genius idea, keep adding broken stuff into the standard until there's no choice but to break compatibility to fix it.

No no no, you add new stuff that will totally fix those problems!

Re: C++26 is done: ISO C++ standards meeting Trip Report

#200

Post by 72deluxe »

kajaktum wrote: post #121
addaon wrote: post #17

Earlier quoted context omitted.

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

C++ needs to give itself up and make way for other, newer, modern, language that have far, far fewer baggage. It should be working with other language to provide tools for interop and migration. C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility. It does not matter what version of C++ you are using, you are still using C with classes.

C with classes is a very simplistic view of C++.

I for one can write C++ but I cannot write a single program in C. If the overlap was so vast, I would be able to write good C but I cannot.

I've done things with templates to express my ideas in C++ that I cannot do in other languages, and the behaviour of deterministic destructors is what sets it apart from C. It is comprehensible and readable to me.

I would argue that C++ is modern, since it is in use today. Perhaps your definition of "modern" is too narrow?

Post reply on HN