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

51–60 of 141 posts

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

#51

Post by TeMPOraL »

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…

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

(content warning: below are just some thoughts without any kind of final point or argument; skip if you're not interested in random musings)

Makes me think of evolution, biological death, and the limits of lessons learned. C++[0] embeds decades of practical experience; many mistakes and pivots add up to how it looks today - but every change made meant complexity was growing, and today, it's hard to incorporate new experience into the language, because of all that accumulated complexity. New languages get to distill what works, and incorporate the lessons into their design directly - starting fresh, without the complexity baggage. However, some things are lost in translation - all that complexity thrown away wasn't just random noise, it was a record of mistakes and wrong turns that the new languages are now liable to repeat.

What I'm thinking is: evolving a language for decades keeps all the experience, but becomes superlinearly[1] expensive and slow. Starting from scratch resets the costs, but also loses some experience in the process. Where continuous evolution of a language, in the limit, will be approaching the point where incremental upgrade takes infinite effort to pay the "complexity debt", the "one funeral at a time" evolution seems like it could reach a different limit: the point at which it each generational transition loses as much experience as the subsequent generation will add.

Not sure what to make of it yet.

--

[0] - I'm including here both the language proper, standard library and compilers, which all co-evolved, and all form the larger body of C++ as a real tool, and not just paper abstraction.

[1] - Would say exponentially, but I'm not really sure how fast it grows - only that it grows faster than linear.

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

#52

Post by tialaramex »

rewmie wrote: post #36
tw1984 wrote: post #22

I really like the fact that it takes "decades" for any reasonable change (e.g. networking, fiber, reflection etc) in C++ to be approved, implemented and promoted. It has never been a better time to depreciate such dinosaur language controlled by a small closed group of people with a combined age of thousands. It is a language for those with several million $ worth of RSU waiting to be vested.

> (...) 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 stupid adaptor layer, or the need to translate via strings.

Now, Rust's standard library also provides BSD sockets in std (that cheap WiFi probe presumably lacks an OS and wouldn't have sockets). That's much less obviously necessary, although it's hardly a big problem and I think if C++ had this since 1998 there would be less squabbling. But the fundamental types are vocabulary and it's silly that C++ doesn't have them in its stdlib.

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

#53

Post by Entalpi »

eesmith wrote: post #46
dthul wrote: post #33

Earlier quoted context omitted.

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.

I'm not sure that's the flex you think it might be. At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code. I have a hard time even estimating how long it would take to test a change against all publicly available C++ code. FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.

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

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

#54

Post by sigsev_251 »

blux wrote: post #38

Does anyone know what happened with Herb's idea for zero-overhead exceptions? I remember liking the idea when he presented it at CppCon ( https://www.youtube.com/watch?v=ARYP83yNAWk ).

Both the C++ paper and the variants of it for C are blocked from lacking implementation experience. The C papers had other flaws too and the initial paper (written by the lcc-win32 maintainer) was outright rejected. To be fair it's not a trivial thing to implement nor to specify.

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

#55

Post by nickelpro »

rightbyte wrote: post #8
foota wrote: post #6

Earlier quoted context omitted.

I for one welcome the new features! I don't think it's too hard to learn a few new things every 3 years.

You have to think about newbies too. Python has made the same mistake as C++, but worse. At least C++ is not pretending to be user friendly. "Modern" C++ was a mountain to climb for me. I think I will not even try to catch up on modules, contracts and what not. I'd rather go back to C for personal projects. I just don't have the stamina for another big C++ language change. And they add up.

I don't understand this complaint even a little bit. Don't use features you don't want. If you want anything from C++ use just that.

No one is going to put a gun to your head and make you #include when all you wanted was C with Classes.

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

#56

Post by einpoklum »

TeMPOraL wrote: post #51
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…

> 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. (content warning: below are just some thoughts without any kind of final point or argument; skip if you're not interested in random musings) Makes me think of evolution, biological death, and the limits of lessons learned. C++[0] em…

> New languages get to distill what works, and incorporate the lessons into their design directly

In principle. In practice, most new languages distill _some_ of what works and incorporate _some_ lessons. Which is ok, but the point is that when they hit those situations where things _don't_ work, they either ignore it or start becoming more complex themselves.

> but becomes superlinearly[1] expensive and slow

Are you talking about the language standard? The standard library API? Idiomatic use "cognitive load"? Advanced use brain load?

For some of these, your statement is not true. Especially for the idiomatic use of the language: Quite a few things have gotten simpler, rather than more complex, for the lay user, with the addition of more functionality into the language.

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

#57

Post by ReleaseCandidat »

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

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

#58

Post by einpoklum »

saboot wrote: post #2

Ctrl+f "Reflection" -> 0 results Maybe next year ..

Full compile-time reflection perhaps not, but we are getting deduction-of-this in C++23, which is a useful reflection feature:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p08...

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

#59

Post by svilen_dobrev »

fractallyte wrote: post #18

No pictures of Varna? That's a bit sad. It's a beautiful city, in places - the older buildings (neglected), the waterfront park that stretches KILOMETERS, one of the best puppet museums in Europe, and an incredible nature reserve parallel to the beach, out of town to the north...

come over, make your own :)

btw there's much-much more (unattended) forest+small-beaches to the south than to north.. and i have a few spare tents :)

https://svilendobrev.com/snimki/more/

That said.. very little software/tech stuff happens here, all goes to Sofia :( and people follow..

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

#60

Post by jmgao »

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…

> But I still argue that this design is simple, checks all checkboxes as long as open questions are decided, and can be independently deployed.

You're handwaving a ton of complexity. You don't even need token pasting for this to become a confusing mess, just consider what happens if GUARD takes the name as an argument, or if an expression is constructed by putting two macros with different editions next to each other. You're also missing the biggest issue, which is 'what happens with headers that don't care about editions, and only begrudgingly even include an extern "C" for C++ users?'.

> (A systematic approach would be to collect a set of all editions used in syntactic tokens, and if not all editions in that set result in the same result, to issue an error.)

This does not work in general. Suppose you wanted to remove most vexing parse in a new edition: changing the result of `Foo bar(std::array())` is the goal!

Post reply on HN