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

Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

herbsutter.com

Post reply on HN
Print view View original

101–110 of 141 posts

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#101

Post by kps »

tialaramex wrote: post #52
rewmie wrote: post #36

Earlier quoted context omitted.

> (...) any reasonable change (e.g. networking, fiber, reflection etc) (...) Except those aren't small or simple or trivial or consequence-free. Also, we're talking about standardizing current practices. You can do networking in C++ in a myriad of ways already, and none of which is standard.

For vocabulary reasons it makes sense for the standard library to express basic types. That's why Rust's core::net::Ipv6Addr - sure, this $5 WiFi-enabled thermal probe and a $5000 100Gb/s fibre switch probably have no common elements when it comes to how they actually do networking, but it's worth acknowledging that 128-bit IPv6 addresses are actually the same thing in both codebases. There should not need to be some…

This one? https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html

That's actually a very good example. Because sooner or later, you'll find yourself ten libraries deep with a FE80::1234 that you can't use because nine of the ten thought Ipv6Addr was enough.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#102

Post by tialaramex »

gpderetta wrote: post #64
tialaramex wrote: post #42

Earlier quoted context omitted.

P2530 isn't really about safety, it's an example of how inadequate package management tooling results in the C++ standard library having to (very poorly) attempt the role of curator instead. C++ needs reclamation mechanisms and astoundingly even in 2023 that still means they need to live in the standard library and be designed by WG21. It's a story about institutional failure. This is one of a pair of proposals (the…

I fail to see the difference. You can find hazard pointers and RCU as libraries in C++. The only reason these are proposed for standardization as opposed to other features is that someone is willing to go through the pains for their pet feature.

Actually the rationale document says that "The plan was always to include a basic interface into C++ IS". I'm not sure that "This was always the plan" constitutes a rationale, because it begs the question, but not my circus, not my monkeys.

I'm arguing that C++ has to pay this cost because of inadequate tooling. There is, as you correctly observe, no functional advantage. Unlike std::string_view this is not a situation where shared vocabulary is valuable. I probably do not want to expose my use of Hazard Pointers in an API for third parties, for example.

Look at the story of Hive. It's a niche data container type, it's not necessary vocabulary, it's not a huge performance win for most people, it's not a fundamentally novel core type, in Rust the RFC would have been closed years ago. Aria even tried to banish LinkedList -- she failed, but that's how high the bar was for weird container types. WG21 are still spending committee time on Hive.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#103

Post by plorkyeran »

gpderetta wrote: post #86
plorkyeran wrote: post #11

Earlier quoted context omitted.

Yeah, hazard pointers address one of the very common sources of memory safety problems (iterator invalidation). It's definitely not a magic solution that solves all problems, especially given that none of the standard library containers will use them, but they're a very useful tool.

Hazard pointers matter if you are writing lock-free concurrent data structures and you need a way to handle deferred reclamation after a node delete. It is a very exotic problem to have and it is hardly a 'very common source of memory safety issue'. I'm not sure what they have to do the general iterator invalidator problem.

Well, you could read the proposal? Using them in iterators is one of the use cases it specifically calls out. Hazard pointers are a key part of how Folly's ConcurrentHashMap lets you mutate the hash map without invalidating existing iterators into it, and while that's intended for multi-threaded cases it also works if the writes happen to be on the same thread as the read.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#105

Post by lionkor »

tialaramex wrote: post #97
lionkor wrote: post #74

Earlier quoted context omitted.

Are you not aware of the networking TS and the asio / boost::asio library its based on? Those have asio::ip::(tcp|udp)::address, both v4 and v6 iirc. Not sure if I'm missing something?

> asio::ip::(tcp|udp)::address You mean asio::ip::address presumably. That's not shared vocabulary. Suppose I'm writing a small program maybe a couple of dozen lines of code, and I need some IPv4 addresses. Should I bring in all of ASIO to have this type? It makes plenty of sense for ASIO to live outside of the C++ standard library. But the standard library would benefit from these basic types as vocabulary.

When do you need ip addresses but no sockets?

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#106

Post by tialaramex »

eesmith wrote: post #75
Entalpi wrote: post #53

Earlier quoted context omitted.

Pretty sure from a build system perspective its quite a flex .. to be fair.

I understand the intent of the flex, but if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. By comparison, there's so much publicly available Python code, from so many sources, that no one can honestly say they can even find it all. The same for C++. I've seen papers where the source code was included in the paper itself…

Rather than hypothesising about an imagined tool you could look at the actual tool which of course is in Rust's source code repo: https://github.com/rust-lang/crater

> new proposed C++ changes - are checked against only easily and "well-known" accessible package.

Now that I have, so to say, shown you mine, lets see yours. Where is the tool to perform these checks in C++?

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#107

Post by eesmith »

dralley wrote: post #96
eesmith wrote: post #75

Earlier quoted context omitted.

I understand the intent of the flex, but if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. By comparison, there's so much publicly available Python code, from so many sources, that no one can honestly say they can even find it all. The same for C++. I've seen papers where the source code was included in the paper itself…

>if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. You seem to be suggesting that it's a good thing that the public code is spread across so many different places that it cannot all be found. I don't see how that's an inherently good thing. It says less about the total amount of code than it does about the lack of any ce…

> that it cannot all be found.

Do you think you can find all public Rust code?

Like, if I'm teaching a Rust course, and put a hello-world.rs program on my department's public GitLab instance, under an MIT license, do you think I should also put that on GitHub? And register it as a crate?

> the lack of any central resource that can be consulted.

And you say that like it's a good thing.

You want everything to be centralized on GitHub? If so, you want to force all research software developers to agree to the GitHub's terms, including those who are ardent free software advocates.

You also prevent 12 years olds from publishing their Rust source code. (GitHub's terms of service don't allow that.)

Or, do you also allow BitBucket [1], and GitLab [2]?

[1] https://bitbucket.org/project_samar/samar_lite/src/master/ contains two Rust programs, neither on crates.io

[2] https://gitlab.com/rouault-team-public/analysis/umaprs

What about department instances of GitLab? [3]

https://gitlab.anu.edu.au/mu/mu-impl-fast/-/tree/rtmu-dev

It really doesn't seem like it's all that easy to find all publicly available Rust code.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#108

Post by Asooka »

ReleaseCandidat wrote: post #67
gpderetta wrote: post #61

Earlier quoted context omitted.

No. 99% backward source compatibility was a primary requirement for C++11. It was bad enough that the ABI was broken.

That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten rid of include files (and using modules instead). It would have been enough (see Fortran for example) to be able to use C++98 libraries and compile them with the same compiler (every C++ compiler I know of is a C Compiler too).

The biggest lesson for me is that you need to provide an incremental path to using the new features. The reason C++ succeeded as much as it did is because you can incrementally C++-ify your existing C code. You can provide C interfaces to your new C++ stuff and you can use C interfaces from C++. Any new feature that you add to C++ has to offer such a path. That is why move semantics were very successful - you could add them incrementally and you could put a preprocessor guard around their definition so your library could be used by code written for both older and newer C++. In contrast, it is hard to incrementally module-ify. You can't transform half of your library to a module and I haven't seen a good story on how to offer a library as both a module and as traditional headers. So it's hard to adopt modules in an existing codebase, thus it's hard to get good feedback on them, thus modules took a long time to really iron out.

Offering a path to incremental improvement is very important for large projects where features and bugfixes happen constantly. We can't stop our regular work to untangle the whole carefully built system of dependencies. The new features have to be offered in a form where we can use them in new code, while remaining compatible with old code and gradually add them to it as time permits.

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#109

Post by 3836293648 »

dthul wrote: post #33
muxator wrote: post #27

> Some compiler needs to implement -Wunderbar Hidden gem! On a more serious note, the author of this little proposal (officializing "_" as a no name placeholder) had to perform a thorough research to show that this change would not break existing code. This kind of attention is necessary for a language with broad scope and a long successful history such as C++, and would be for every other language with such characte…

There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.

But soundness fixes are typically considered more important than compat and go ahead anyway

Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria

#110

Post by JohnFen »

lifthrasiir wrote: post #49
jmgao wrote: post #39

Earlier quoted context omitted.

> Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). You can't really do this in a language where the way you use libraries is by textual inclusion of headers which can include arbitrary code (no one…

That's a bad excuse. In fact I think editions are possible without modules at all, if you are really willing to fix this issue. Tying epochs to modules suggests that they don't think this is a huge issue to start with. One possible design is to assign editions to all preprocessed tokens. This implies the edition definition should be some sort of pragma (say, `#pragma STDCXX EDITION 2023`) and preprocessors should add…

The main problem with C++ right now, in my opinion, is that is has turned into a hodgepodge of syntactic idiosyncrasies. I'm not sure adding more would be a benefit.
Post reply on HN