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

201–210 of 437 posts

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

#201

Post by 72deluxe »

drfloyd51 wrote: post #146
kevin_thibedeau wrote: post #127

Earlier quoted context omitted.

Is a pointer parameter an input, output, or both?

Input. You are passing in a memory location that can be read or written too. That’s it.

In terms of contract in a function, you might be passing the pointer to the function so that the function can write to the provided pointer address. Input/output isn't specifying calling convention (there's fastcall for that) - it is specifying the intent of the function. Otherwise every single parameter to a function would be an input because the function takes it and uses it...

I worked on a massive codebase where we used Microsoft SAL to annotate all parameters to specify intent. The compiler could throw errors based on these annotations to indicate misuse.

This seems like an extension of that.

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

#202

Post by Joker_vD »

ozgrakkurt wrote: post #178
jandrewrogers wrote: post #174

Earlier quoted context omitted.

What is non-obvious about “[[indeterminate]]”? That terminology has been used throughout the standards in exactly this context for ages. This just makes it explicit instead of implicit so that the compiler can know your intent.

I know roughly what indeterminate means in english but it is not obvious to me when I see something like this in code. So I would have to look it up and be very careful about it since I can break something easily in C++. This just makes things more difficult from the perspective of using/learning the language. Similar problem with "unsequenced" and "reproducible" attributes added in c. It sounded cool after I took th…

I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.

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

#203

Post by daemin »

zarzavat wrote: post #142
lmm wrote: post #138

Earlier quoted context omitted.

Multiple package managers is fine, what's needed is a common repository standard (or even any repository functionality at all). Look at how it works in Java land, where if you don't want to use Maven you can use Gradle or Bazel or what have you, or if you hate yourself you can use Ant+Ivy, but all of them share the same concept of what a dependency is and can use the same repositories.

Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases. There should be a happy path for the majority of C++ use cases so that I can make a package, publish it and consume other people's packages. Anyone who wants to leave that happy path can do so freely at their own risk. The important thing is to get one system blessed as The C++ Package Format by the sta…

That would actually be pretty cool. Though I think there might have been papers written on this a few years ago. Does anyone know of these or have any updates about them?

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

#204

Post by maccard »

mgaunard wrote: post #123
maccard wrote: post #115

Earlier quoted context omitted.

The problem is doing this requires a team to support it that is realistically as large as your average product team. I know Bazel is the solution here but as someone who has used C++, modified build systems and maintained CI for teams for years, I have never gotten it to work for anything more than a toy project.

I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days. Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based.

> I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days.

Really? I'd love a link to even something that works as a toy project

> Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based.

I agree

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

#205

Post by 72deluxe »

affenape wrote: post #6

Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.

What do you mean by a destructing move? Are you trying to avoid use of a moved object after you've moved it?

eg. B = std::move(A); // You are worried about touching A when it's in this indeterminate state?

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

#206

Post by 72deluxe »

VerifiedReports wrote: post #33

As long as programmers still have to deal with header files, all of this is lipstick on a pig.

I don't understand this at all. There are modules.

But headers are perfectly fine to deal with and have been for decades and decades! Next you'll be arguing that contents pages in all books should be removed.

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

#207

Post by [deleted] »

jesse__ wrote: post #180
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.

> 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. In my experience, this is absolutely true. I wrote my own metaprogramming frontend for C and that's basically all you need. At this point, I consider the metaprogramming facilities of a language it's most important feature, by far. Ever…

[deleted]

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

#208

Post by peterfirefly »

j1elo wrote: post #189
kevin_thibedeau wrote: post #148

Earlier quoted context omitted.

A pointer doesn't necessarily point to memory.

A nitpick to your nitpick: they said "memory location". And yes, a pointer always points to a memory location. Notwithstanding that each particular region of memory locations could be mapped either to real physical memory or any other assortment of hardware.

No. Neither in the language (NULL exists) nor necessarily on real CPUs.

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

#209

Post by saagarjha »

jandrewrogers wrote: post #174
ozgrakkurt wrote: post #169

Earlier quoted context omitted.

I envy the person that will walk into a c++ codebase and see "[[indeterminate]]" on some place. And then they will need to absolutely waste their time searching and reading what "[[indeterminate]]" means. Or over time they will just learn to ignore this crap and mentally filter it out when looking at code. Just like when I was learning rust and trying to read some http code but it was impossible because each function…

What is non-obvious about “[[indeterminate]]”? That terminology has been used throughout the standards in exactly this context for ages. This just makes it explicit instead of implicit so that the compiler can know your intent.

I mean there's a sibling comment that literally says that the word was chosen to be mysterious and make people look up what it means

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

#210

Post by saagarjha »

WalterBright wrote: post #182
jcalvinowens wrote: post #159

Earlier quoted context omitted.

There's a whole section on that: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

I don't understand its claim of a "self-documentation trap". I'm surprised the "= void;" wasn't discussed. People liked it immediately in D, and other alternatives were not proposed.

The syntax is probably fine but I feel that the default kind of sucks; default initialization has mostly fallen out of favor these days.
Post reply on HN