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

111–120 of 141 posts

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

#111

Post by staunton »

pjmlp wrote: post #91
staunton wrote: post #88

Earlier quoted context omitted.

> what leads you to believe that there is value in stopping others from improving upon a language they use? Continuously "improving" a language has upsides and downsides. The upside is, of course, people get to use the new features, which is good if the features are useful. A significant downside is the added complexity once there are very many features. A lot of the features of C++ don't interact in good ways and ge…

> Question for you: Should they start adding variadic templates and mutable lambdas to C? Would you like that? Who knows what might still come into C26.

Sure, who knows. But would you like new features in C?

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

#112

Post by dralley »

eesmith wrote: post #107
dralley wrote: post #96

Earlier quoted context omitted.

>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 centra…

What bearing does any of this have on the previous thread of discussion?

Why do you think a 12 year old needs to publish their "hello world" programs because of Crater? The purpose of Crater is uncovering subtle compiler regressions. If "hello world" is ever broken then it would likely be discovered by the standard test suite or generally long before the Crater run.

This isn't a matter of "allowing" anything. It's just a statement that yes a Crater run does test all meaningful publicly available code, where "meaningful" at the very least means code which is consumed via crates.io. Sure, there is very likely public code that exists elsewhere which Crater cannot find, and that's OK. The point is that a Crater run coming back clean means something, because a very very wide swath of code was tested.

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

#113

Post by pjmlp »

staunton wrote: post #111
pjmlp wrote: post #91

Earlier quoted context omitted.

> Question for you: Should they start adding variadic templates and mutable lambdas to C? Would you like that? Who knows what might still come into C26.

Sure, who knows. But would you like new features in C?

Yes, specially if they finally come around to implement fat pointers as proposed by Dennis Ritchie in 1990.

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

#114

Post by tialaramex »

lionkor wrote: post #105
tialaramex wrote: post #97

Earlier quoted context omitted.

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

Sockets are an OS feature (initially on BSD) to make it simple to program with IP on Unix-like systems. They're not crucial to the Network, they're happenstance. Indeed in the early 1990s you'd have found pockets of people who weren't convinced sockets were even the Right Thing™ they wanted some other API to the same network. Same IP addresses, same services, same protocols, different API.

So there's no reason the very cheap device would care about sockets. But it does talk to the network, and for that it needs to know about addresses.

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

#115

Post by tialaramex »

kps wrote: post #101
tialaramex wrote: post #52

Earlier quoted context omitted.

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.

Kinda, yes. std::net::Ipv6Addr re-exports core::net::Ipv6Addr - it lives in core because you don't need an operating system to have network addresses.

If you wanted the [u8; 16] that's octets() if you wanted [u16; 8] that's segments() and those are both inline constant functions.

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

#116

Post by 59nadir »

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…

To be fair to the original argument, I think it's important to understand that there is next to no Rust code in comparison to the amount of C++ code out there. It has almost no projects in comparison, and those projects are much, much smaller. I don't think that's a very controversial statement, because it's very obviously true.

Now, it's also important to keep in mind that C++ has a terrible story when it comes to centralized (or otherwise, really?) repositories for packages, so the corresponding system for C++ is at the moment completely infeasible and not at all useful. That doesn't really make the Rust code that's tested against any more meaningful in comparison to the vast amounts of C++ code out there, though.

Edit:

At the kind of pointless and debilitating scale that C++ exists and then with the relationship C++ has with packages and dependency management this entire idea is basically impossible.

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

#117

Post by maratc »

gkedzierski wrote: post #68
gpderetta wrote: post #65

Earlier quoted context omitted.

I'm 99% sure that ot was being sarcastic.

I know, I wasn't though (but I know I'm in a minority)

I'm in an even smaller minority and I think C++ was a monstrosity already in 99.

To use an analogy, it looked like a cat with 11 legs, even back then. Of course they added more legs since, and they keep on adding.

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

#118

Post by rewmie »

staunton wrote: post #88
rewmie wrote: post #30

Earlier quoted context omitted.

> I still think they should stop adding new features and do what the C committee does in keeping the language stable over the decades which it will take to slowly die, as it should. Other than catering to your unexplainable desire to see the death if one of the most popular programming languages ever designed, what would be the point of that? More importantly, what leads you to believe that there is value in stopping…

> what leads you to believe that there is value in stopping others from improving upon a language they use? Continuously "improving" a language has upsides and downsides. The upside is, of course, people get to use the new features, which is good if the features are useful. A significant downside is the added complexity once there are very many features. A lot of the features of C++ don't interact in good ways and ge…

> Continuously "improving" a language has upsides and downsides.

It has zero downsides. If you are interested in new features you're free to adopt them. If you are not interested in them then you can simply not use them, or even sit out a specific version. There are zero drawbacks.

> A significant downside is the added complexity once there are very many features.

There is zero complexity. No one forces you to play standard library bingo. No one forces you to use each and every single feature ever devised. No one forces you to adopt a new standard.

That's the best feature of C++'s standardization process: it specifies existing features, and provides you with a convenient way to onboard or not onto them.

I've worked on C++14 projects until a couple of years ago. My team inherited a C++11 project and we decided to migrate to C++14 mainly because of std::make_unique. We considered C++17 but we didn't bothered with it. C++20 was already out. No one held a gun to our heads. It's ok if you don't jump onto the latest and greatest.

> Question for you: Should they start adding variadic templates and mutable lambdas to C? Would you like that?

C would greatly benefit from supporting templates. I don't understand what point you tried to make. The question sounds too luddite.

> Not wanting to rewrite code is the very reason they should stop adding features.

This is a pretty lame strawman. No one is forced to rewrite stuff when bumping a C++ version. I was involved in a couple of projects that underwent those upgrades and basically the migration consisted of flipping a switch in the build system and addressing a couple of compiler errors caused by the compiler flaggin a couple of warnings as errors. That was it.

Things are simpler if we don't invent problems.

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

#119

Post by eesmith »

tialaramex wrote: post #106
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…

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++?

Thank you for showing that I was right to in my belief: 'I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.'

My point is that dthul's comment "they usually test it against all publicly available Rust code" implies Rust has a very small user base. Since crater runs only against "parts of the Rust" - those available on GitHub and crates - it implies a rather larger ecosystem.

As for "mine" - what I know about C++ development comes from reading links posted to HN; hardly "mine" in any meaningful sense. I also don't accept your wording "these checks", because my point is that similarly useful checks are done, not exactly identical tests. I wrote 'FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.'

From previous readings, I know they do code surveys, and experiments using existing code bases and compilers.

For examples, there's https://codesearch.isocpp.org/ ("developed for ISO Standard C++ proposal authors in order to explore existing C++ practice and to provide empirical evidence to support claims about existing practice made in proposals.") done in surveys to understand how code is used. For example, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14... .

At https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p11... they used a custom tool to analyze Boost, Chromium, Firefox, the Linux Kernel, Libreoffice, LLVM, and Qt: "Estimated 30 to 80 millions LOC compiled".

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

#120

Post by eesmith »

dralley wrote: post #112
eesmith wrote: post #107

Earlier quoted context omitted.

> 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 centra…

What bearing does any of this have on the previous thread of discussion? Why do you think a 12 year old needs to publish their "hello world" programs because of Crater? The purpose of Crater is uncovering subtle compiler regressions. If "hello world" is ever broken then it would likely be discovered by the standard test suite or generally long before the Crater run. This isn't a matter of "allowing" anything. It's ju…

What is "the previous thread of discussion?"

My response was all of 5 lines, saying that if dthul's comment were true, then it implies that Rust has a rather small code base.

And indeed, Crater does not test all publicly available Rust code. ("Not all code is on crates.io! There is a lot of code in repos on GitHub and elsewhere", and only for "Linux builds on x86_64", not Windows, says https://rustc-dev-guide.rust-lang.org/tests/crater.html).

Rust is much bigger than dthul's comment implies.

You may well be correct when adding the qualifier "meaningful", but that's a different thread of discussion.

> Why do you think a 12 year old needs to publish their "hello world" programs because of Crater?

I mentioned that because you changed the thread of discussion to discuss centralized vs. decentralized code distribution.

> because a very very wide swath of code was tested.

And C++ language developers also analyze a 'wide swath of code' - millions of lines or more - for changes.

Post reply on HN