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

91–100 of 141 posts

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

#91

Post by pjmlp »

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…

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

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

#94

Post by stathibus »

rightbyte wrote: post #5

I feel things with C++ are not as bad as with Python, but I would really like a "core language freeze" for 10 years now or something. I don't want to keep up with all these changes. To many enthusiasts on the committee.

Lucky for us regular people, almost all of the features added after C++11 are completely ignorable, including everything in this trip report.

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

#95

Post by saalweachter »

ReleaseCandidat wrote: post #57
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…

No. This is actually the biggest error C++ made. C++ should have learned from Fortran 77 -> 90 and made C++11 a new language and either let the compilers handling compatibility of C++98 and C++11 or introduce some compatibility functions like `extern C`.

They did do that.

It is called D.

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

#96

Post by dralley »

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…

>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 central resource that can be consulted.

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

#97

Post by tialaramex »

lionkor wrote: post #74
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…

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.

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

#98

Post by planede »

lionkor wrote: post #74
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…

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?

AFAIK asio based networking TS is dead.

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

#99

Post by planede »

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.

It would be quite weird to have these vocabulary types in the standard without any way to use them for networking within the standard library. Like having std::filesystem::path without having actual filesystem operations working on them.

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

#100

Post by Asooka »

jmgao wrote: post #39
lifthrasiir wrote: post #32

Earlier quoted context omitted.

> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. This is true, but C++ hasn't learned enough from other languages' experiences either. Let's assume that `_` couldn't not be introduced without breaking changes. Even in that case it would be reasonable to opt in that syntax for some…

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

You can just say that this feature is only local to the current file and does not affect included files, nor files that this one is included in. There are already some preprocessor features that act like that, e.g. __FILE__, which contains the name of the current file being parsed and obviously is local to it; or "#pragma once", which indicates the current file should not be parsed if it has already been included once. The information for which file is being parsed currently is not lost after the preprocessor stage, so you can have file-local directives.
Post reply on HN