13 ms·

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

85 points by agluszak 3y ago

saboot 3y ago
Ctrl+f "Reflection" -> 0 results Maybe next year ..
- 2h 3y ago
  Same for "safety"
  - nick__m 3y ago
    reflection seems almost dead but there are 2 papers listed on Herb's summary that directly relate to safety: P2530 hazaerd pointers https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2530r3.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p25... P2757 type checking for std::format https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2757r2.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...
    - plorkyeran 3y ago
      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.
      - gpderetta 3y ago
        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.
        plorkyeran 3y ago
        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.
    - tialaramex 3y ago
      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 other is for RCU) - both of which will likely get accepted - with useful but simplified reclamation schemes. In Rust their equivalents live on crates.io, e.g. https://crates.io/crates/haphazard https://crates.io/crates/haphazard is more or less the same Hazard Pointers, even based on the same work at Folly - and so they can be updated, or obsoleted, or alternatives may become prominent, it all Just Works™. Closer to safety work is the proposal to have C++ admit that it's possible for a program to be wrong and yet not throw its hands in the air and refuse to explain what it does, as "Erroneous Behaviour". The idea is that e.g. suppose I declare there's going to be a variable named foo, which is an integer, but then I never actually initialize it. Well that's not OK, that program is nonsense, but C++ has long allowed it, even though it's nonsense, so just refusing to compile would annoy programmers. On the other hand, if foo is now silently zero, we actually introduced new semantics to the language, which isn't OK. With "Erroneous Behaviour" C++ could emit a warning ("Don't do that, uninitialized variable foo") but also zero it anyway. A new syntax would be added to mean "I genuinely don't want this initialized, for some good reason" because it's still C++ so being needlessly dangerous is part of their whole ethos, but at least you did it on purpose. I tried to find this proposal but the links don't work, once upon a time it was 2795 "Erroneous Behaviour". Maybe the author asked that it be withdrawn for some reason?
      - gpderetta 3y ago
        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.
        tialaramex 3y ago
        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.
  - jupp0r 3y ago
    If you are waiting for a Rust-like feature that guarantees memory safety - this won't happen. Changes to the language required for this would break too much. Also, existing code wouldn't compile anymore because it contains a ton of memory bugs.
  - pjmlp 3y ago
    Reducing UB use cases is safety related improvements.
  - alphanullmeric 3y ago
    Turns out no language actually used in production wants to copy the mistakes of rust.
- blt 3y ago
  pybind29 has a nice ring to it.
- einpoklum 3y ago
  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/p0847r7.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p08...
soulbadguy 3y ago
I am very happy to see that the work on fibers is continuing. I was under the impression that with the addition of coroutines, the focus would have shifted. Glad i am wrong. What's the best way for someone to keep track of the progress and the conversation around a specific proposal ?
- jupp0r 3y ago
  https://www.open-std.org/jtc1/sc22/wg21/docs/papers/ https://www.open-std.org/jtc1/sc22/wg21/docs/papers/ has all the papers. To follow discussions, it's probably best to attend the standard meeting online or in person.
- foonathan 3y ago
  You subscribe to the Github issue of the proposal: https://github.com/cplusplus/papers/issues https://github.com/cplusplus/papers/issues
rightbyte 3y ago
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.
- foota 3y ago
  I for one welcome the new features! I don't think it's too hard to learn a few new things every 3 years.
  - rightbyte 3y ago
    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.
    - nazgulsenpai 3y ago
      While I don't follow Python development super closely, as a scripting language it is still pretty simple and user friendly. I'm sure once the complexity rises... well, the complexity rises.
      - rightbyte 3y ago
        Ye sure. My point is that Python is harder than it could be. Not that it is harder to use or learn than C++. It is like the language design now is centered around those with 10 year plus experience in the language. I firmly remember how hard it was to understand each concept as a newbie. And all the additions since I started out must be insanely confusing now.
    - 59nadir 3y ago
      It's not only about newbies in the end. When I started learning C++ back in ~2000 the semi-joke was that "C++ takes about 10 years to learn". The language is far bigger now, with more things you either need to know to cut out or somehow just not learn, but then you need to learn it if you end up working with code that uses it, etc.. This stuff, to use properly, usually comes with a list of "dos and don'ts" in C++ so it's not feasible to just on-demand learn the additions to the language and call it a day.
fractallyte 3y ago
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...
- foonathan 3y ago
  There are two reasons for that: Herb didn't attend in person and the meeting was in Golden Sands, not Varna...
- svilen_dobrev 3y ago
  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/ https://svilendobrev.com/snimki/more/ That said.. very little software/tech stuff happens here, all goes to Sofia :( and people follow..
tw1984 3y ago
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.
- rewmie 3y ago
  > (...) 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.
  - tialaramex 3y ago
    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.
    - lionkor 3y ago
      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?
      - 3y ago
logicchains 3y ago
It's nice that whatever may be going on in life, at least we've always got an exciting new C++ release to look forward to every 3 years. I'm particularly excited that C++23 is finally getting std::flat_map and flat_set, more memory-friendly data structures with much nicer latency characteristics than the old non-flat variants.
- jb1991 3y ago
  flat maps are not quite what many assume they are, some panacea for performance. In fact for most cases, you will still benefit from using the ordinary maps already provided in C++. In fact if you merely swap out std::map with std::flat_map, most code will start running much more slowly. They have a very specific, limited use case and for everything else, you should not make any changes.
  - logicchains 3y ago
    >some panacea for performance I said for latency, not performance in general. If you're generally working with maps with only 10s to 100s of small entries, it's easily possible to see a 10x reduction in worst-cost latency by switching from std::[unordered_]map to flat_map, due to a massive reduction in latency and pointer chasing (e.g. std::unordered_map allocates for every single insertion, and std::map lookup/pointer chasing often leads to log(n) cache misses).
  - lionkor 3y ago
    Your comment has a gaping lack of real world profiling and "it depends", so that's likely why it's getting downvoted. > most code will start running much more slowly Most code, as in, most code that uses it? Are there are stats on how exactly std::map (and std::unordered_map, the more useful general purpose map) are used?
    - tialaramex 3y ago
      > and std::unordered_map, the more useful general purpose map std::unordered_map is a hash table. It's not a very good hash table but that's what it is, and so whilst that is much more generally useful, it's also irrelevant to the purpose of map (and thus of flat_map). It seems to me that if "most code" would be harmed by using flat_map instead of map that's actually good news, since map isn't going anywhere. What I anticipate is the reality is that a considerable amount of code would benefit from using flat_map instead of map, because of the improved performance from linear access.
galkk 3y ago
"type checking format args" [1] is rather sad reading. I think that it's time to admit that C++ will never have things like string interpolation, that are norm in other modern languages. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2757r2.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...
- vinkelhake 3y ago
  What a weird comment. What would be the point of "admitting" something that is an obvious fact? std::format, being a function for string formatting, is already part of the C++ standard library and can do some of its error checking at compile time. The paper you link is about making that error checking even better.
  - galkk 3y ago
    And that is the problem, from my pov. Instead of accepting reality that this part of c++ plain sucks and needs significant improvements, they try to do tactical updates. There are 2 names of such activities, select one which you prefer: gold plating/turd polishing...
    - logicchains 3y ago
      >c++ plain sucks and needs significant improvements What a silly thing to say. How many other mainstream languages support writing a library for compile-time checking of format strings? Having the power to do this as a library means that you can also write similar stuff customised to your own needs when you need to, as it doesn't rely on anything hard-coded in the compiler.
muxator 3y ago
> 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 characteristics. 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.
- lifthrasiir 3y ago
  > 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 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, ...). C++ is still struggling with a false premise of stable ABI (see [1] for a good argument against it). [1] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-...
  - jmgao 3y ago
    > 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 uses modules).
    - tialaramex 3y ago
      The proposal (Epochs) to do this in C++ even says it needs modules. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... It would have been extremely difficult to do this for say C++ 20 even if the other work was abandoned (which IMO would have been sensible) and I feel confident it is now impossible.
staunton 3y ago
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. Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? C++ is already a mess of around 3.5 languages jumbled together. When will it stop?
- rewmie 3y ago
  > 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 others from improving upon a language they use? > Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? What's the point of that? You have a perfectly good and working programming language that is used to build software everyone in the world uses every single day. Why would anyone think it's a good idea to just throw that out and water their time reinventing the wheel? Are you the one who is going to rewrite every single C++ software project into your flavor of the month?
  - staunton 3y ago
    > 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 generally make it easy to shoot oneself im the foot. C++ has bad defaults (they were most reasonable at the time, of course) and it's not possible to change them due to backwards compatibility. C++ is also the most complex (widely used) language, to the point where it's quite easy to produce a 20 line program that half the ISO committee couldn't tell you if it should compile or not (they do this apparently for fun sometimes in Cpp-con talks). To summarize, the point of stopping to add features is to have a stable language that is manageable. It will be around for many decades and not be thrown out. However, if it keeps evolving at the current pace, any new developer inheriting a large codebase will have to know 10 programming languages crammed into one and interacting in weird ways. If your answer is "what's wrong with that?", I guess we won't agree. Question for you: Should they start adding variadic templates and mutable lambdas to C? Would you like that? > Are you the one who is going to rewrite every single C++ software project into your flavor of the month? Not wanting to rewrite code is the very reason they should stop adding features. Already, the standard suggestion in C++ circles is that you should "modernize" your codebase and use "best practices" that change every decade. That's bordering on rewriting it in a different language. I am against rewriting stuff that works in a new language. The sad thing is that I agree with pretty much all these "modernization" suggestions individually. The bigger picture of it seems crazy though. New projects can be started in new languages that don't need to be backwards compatible to stuff from the 80s and have sane defaults with the benefit of hindsight. That's how languages evolve in my view, sometimes starting fresh is the way to go. The old languages stay around for a long time, which is fine. Incessantly messing with them and making them more complicated is the issue.
blux 3y ago
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 https://www.youtube.com/watch?v=ARYP83yNAWk).
- sigsev_251 3y ago
  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.
einpoklum 3y ago
I am disappointed there is no progress on: * Standardizing `__restrict__` (which C has, and C++ doesn't). Everybody relies on the compilers offering it as an extension, as without it - performance often suffers very badly. * Universal call syntax (i.e. equivalence of `foo(myobj, myparam)` and `myobj.foo(myparam)` ). There were what I considered to be rather trivial objections, last decade, then it somehow went away.
- kolbe 3y ago
  I've found the lack of alias guarantees to be far more bark than bite. What's the primary use case? For automatic vectorization? Ultimately the only cost to check is an integer add and an integer comparison. Yeah, aliasing guarantees would eliminate those two ops (and eliminate generating the aliased version's code path). But in general, it isn't some 8x monumental cost that many people think it is.
  - einpoklum 3y ago
    > What's the primary use case? For automatic vectorization? No. Without aliasing guarantees, every load via a by-ref/by-addr input param after a store via another such param must actually be executed. So either you manually cache your accesses, or you can't do loop unrolling, strength reductions, and possibly other optimization work. > Ultimately the only cost to check is an integer add and an integer comparison 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. 2. The interest is also for the _definition_ side of things, not just for the implementation. I want to tell the user of my function "pass unaliased arguments". This is important, because otherwise you have to provide a bunch of convoluted implementations for the case of there _being_ aliasing - which often changes the semantics of the function to something you had no intention of writing. 3. In real life, there is no guarantee that memory ranges with disjoint addresses are not aliases of the same region. There's probably no such guarantee that the standard makes, but IANALL.
    - kolbe 3y ago
      Sorry I didn't see your response. > 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. I wasn't implying to do it manually. Compilers do it all the time. 2, I understand and would use. I also want to restrict input alignment. 3, I never knew, but compilers I use for x86 on linux seem to think it's fine to just check memory address distances.
deleted 3y ago
[deleted]
omoikane 3y ago
P2558 should be "Add @, $, and ` to the basic character set", but somehow the article had % instead of $.
black_13 3y ago
[dead]

85 points by agluszak 3y ago

saboot 3y ago

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

2h 3y ago
Same for "safety"
- nick__m 3y ago
  reflection seems almost dead but there are 2 papers listed on Herb's summary that directly relate to safety: P2530 hazaerd pointers https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2530r3.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p25... P2757 type checking for std::format https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2757r2.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...
  - plorkyeran 3y ago
    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.
    - gpderetta 3y ago
      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.
      - plorkyeran 3y ago
        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.
  - tialaramex 3y ago
    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 other is for RCU) - both of which will likely get accepted - with useful but simplified reclamation schemes. In Rust their equivalents live on crates.io, e.g. https://crates.io/crates/haphazard https://crates.io/crates/haphazard is more or less the same Hazard Pointers, even based on the same work at Folly - and so they can be updated, or obsoleted, or alternatives may become prominent, it all Just Works™. Closer to safety work is the proposal to have C++ admit that it's possible for a program to be wrong and yet not throw its hands in the air and refuse to explain what it does, as "Erroneous Behaviour". The idea is that e.g. suppose I declare there's going to be a variable named foo, which is an integer, but then I never actually initialize it. Well that's not OK, that program is nonsense, but C++ has long allowed it, even though it's nonsense, so just refusing to compile would annoy programmers. On the other hand, if foo is now silently zero, we actually introduced new semantics to the language, which isn't OK. With "Erroneous Behaviour" C++ could emit a warning ("Don't do that, uninitialized variable foo") but also zero it anyway. A new syntax would be added to mean "I genuinely don't want this initialized, for some good reason" because it's still C++ so being needlessly dangerous is part of their whole ethos, but at least you did it on purpose. I tried to find this proposal but the links don't work, once upon a time it was 2795 "Erroneous Behaviour". Maybe the author asked that it be withdrawn for some reason?
    - gpderetta 3y ago
      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.
      - tialaramex 3y ago
        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.
- jupp0r 3y ago
  If you are waiting for a Rust-like feature that guarantees memory safety - this won't happen. Changes to the language required for this would break too much. Also, existing code wouldn't compile anymore because it contains a ton of memory bugs.
- pjmlp 3y ago
  Reducing UB use cases is safety related improvements.
- alphanullmeric 3y ago
  Turns out no language actually used in production wants to copy the mistakes of rust.
blt 3y ago
pybind29 has a nice ring to it.
einpoklum 3y ago
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/p0847r7.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p08...

soulbadguy 3y ago

I am very happy to see that the work on fibers is continuing. I was under the impression that with the addition of coroutines, the focus would have shifted. Glad i am wrong. What's the best way for someone to keep track of the progress and the conversation around a specific proposal ?

jupp0r 3y ago
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/ https://www.open-std.org/jtc1/sc22/wg21/docs/papers/ has all the papers. To follow discussions, it's probably best to attend the standard meeting online or in person.
foonathan 3y ago
You subscribe to the Github issue of the proposal: https://github.com/cplusplus/papers/issues https://github.com/cplusplus/papers/issues

rightbyte 3y ago

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.

foota 3y ago
I for one welcome the new features! I don't think it's too hard to learn a few new things every 3 years.
- rightbyte 3y ago
  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.
  - nazgulsenpai 3y ago
    While I don't follow Python development super closely, as a scripting language it is still pretty simple and user friendly. I'm sure once the complexity rises... well, the complexity rises.
    - rightbyte 3y ago
      Ye sure. My point is that Python is harder than it could be. Not that it is harder to use or learn than C++. It is like the language design now is centered around those with 10 year plus experience in the language. I firmly remember how hard it was to understand each concept as a newbie. And all the additions since I started out must be insanely confusing now.
  - 59nadir 3y ago
    It's not only about newbies in the end. When I started learning C++ back in ~2000 the semi-joke was that "C++ takes about 10 years to learn". The language is far bigger now, with more things you either need to know to cut out or somehow just not learn, but then you need to learn it if you end up working with code that uses it, etc.. This stuff, to use properly, usually comes with a list of "dos and don'ts" in C++ so it's not feasible to just on-demand learn the additions to the language and call it a day.

fractallyte 3y ago

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

foonathan 3y ago
There are two reasons for that: Herb didn't attend in person and the meeting was in Golden Sands, not Varna...
svilen_dobrev 3y ago
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/ https://svilendobrev.com/snimki/more/ That said.. very little software/tech stuff happens here, all goes to Sofia :( and people follow..

tw1984 3y ago

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.

rewmie 3y ago
> (...) 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.
- tialaramex 3y ago
  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.
  - lionkor 3y ago
    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?
    - 3y ago

logicchains 3y ago

It's nice that whatever may be going on in life, at least we've always got an exciting new C++ release to look forward to every 3 years. I'm particularly excited that C++23 is finally getting std::flat_map and flat_set, more memory-friendly data structures with much nicer latency characteristics than the old non-flat variants.

jb1991 3y ago
flat maps are not quite what many assume they are, some panacea for performance. In fact for most cases, you will still benefit from using the ordinary maps already provided in C++. In fact if you merely swap out std::map with std::flat_map, most code will start running much more slowly. They have a very specific, limited use case and for everything else, you should not make any changes.
- logicchains 3y ago
  >some panacea for performance I said for latency, not performance in general. If you're generally working with maps with only 10s to 100s of small entries, it's easily possible to see a 10x reduction in worst-cost latency by switching from std::[unordered_]map to flat_map, due to a massive reduction in latency and pointer chasing (e.g. std::unordered_map allocates for every single insertion, and std::map lookup/pointer chasing often leads to log(n) cache misses).
- lionkor 3y ago
  Your comment has a gaping lack of real world profiling and "it depends", so that's likely why it's getting downvoted. > most code will start running much more slowly Most code, as in, most code that uses it? Are there are stats on how exactly std::map (and std::unordered_map, the more useful general purpose map) are used?
  - tialaramex 3y ago
    > and std::unordered_map, the more useful general purpose map std::unordered_map is a hash table. It's not a very good hash table but that's what it is, and so whilst that is much more generally useful, it's also irrelevant to the purpose of map (and thus of flat_map). It seems to me that if "most code" would be harmed by using flat_map instead of map that's actually good news, since map isn't going anywhere. What I anticipate is the reality is that a considerable amount of code would benefit from using flat_map instead of map, because of the improved performance from linear access.

galkk 3y ago

"type checking format args" [1] is rather sad reading. I think that it's time to admit that C++ will never have things like string interpolation, that are norm in other modern languages. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2757r2.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

vinkelhake 3y ago
What a weird comment. What would be the point of "admitting" something that is an obvious fact? std::format, being a function for string formatting, is already part of the C++ standard library and can do some of its error checking at compile time. The paper you link is about making that error checking even better.
- galkk 3y ago
  And that is the problem, from my pov. Instead of accepting reality that this part of c++ plain sucks and needs significant improvements, they try to do tactical updates. There are 2 names of such activities, select one which you prefer: gold plating/turd polishing...
  - logicchains 3y ago
    >c++ plain sucks and needs significant improvements What a silly thing to say. How many other mainstream languages support writing a library for compile-time checking of format strings? Having the power to do this as a library means that you can also write similar stuff customised to your own needs when you need to, as it doesn't rely on anything hard-coded in the compiler.

muxator 3y ago

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

lifthrasiir 3y ago
> 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 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, ...). C++ is still struggling with a false premise of stable ABI (see [1] for a good argument against it). [1] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-...
- jmgao 3y ago
  > 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 uses modules).
  - tialaramex 3y ago
    The proposal (Epochs) to do this in C++ even says it needs modules. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... It would have been extremely difficult to do this for say C++ 20 even if the other work was abandoned (which IMO would have been sensible) and I feel confident it is now impossible.

staunton 3y ago

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. Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? C++ is already a mess of around 3.5 languages jumbled together. When will it stop?

rewmie 3y ago
> 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 others from improving upon a language they use? > Can't the new-feature enthusiasts just make a new language, or join existing efforts at building new ones? What's the point of that? You have a perfectly good and working programming language that is used to build software everyone in the world uses every single day. Why would anyone think it's a good idea to just throw that out and water their time reinventing the wheel? Are you the one who is going to rewrite every single C++ software project into your flavor of the month?
- staunton 3y ago
  > 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 generally make it easy to shoot oneself im the foot. C++ has bad defaults (they were most reasonable at the time, of course) and it's not possible to change them due to backwards compatibility. C++ is also the most complex (widely used) language, to the point where it's quite easy to produce a 20 line program that half the ISO committee couldn't tell you if it should compile or not (they do this apparently for fun sometimes in Cpp-con talks). To summarize, the point of stopping to add features is to have a stable language that is manageable. It will be around for many decades and not be thrown out. However, if it keeps evolving at the current pace, any new developer inheriting a large codebase will have to know 10 programming languages crammed into one and interacting in weird ways. If your answer is "what's wrong with that?", I guess we won't agree. Question for you: Should they start adding variadic templates and mutable lambdas to C? Would you like that? > Are you the one who is going to rewrite every single C++ software project into your flavor of the month? Not wanting to rewrite code is the very reason they should stop adding features. Already, the standard suggestion in C++ circles is that you should "modernize" your codebase and use "best practices" that change every decade. That's bordering on rewriting it in a different language. I am against rewriting stuff that works in a new language. The sad thing is that I agree with pretty much all these "modernization" suggestions individually. The bigger picture of it seems crazy though. New projects can be started in new languages that don't need to be backwards compatible to stuff from the 80s and have sane defaults with the benefit of hindsight. That's how languages evolve in my view, sometimes starting fresh is the way to go. The old languages stay around for a long time, which is fine. Incessantly messing with them and making them more complicated is the issue.

blux 3y ago

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 https://www.youtube.com/watch?v=ARYP83yNAWk).

sigsev_251 3y ago
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.

einpoklum 3y ago

I am disappointed there is no progress on: * Standardizing `__restrict__` (which C has, and C++ doesn't). Everybody relies on the compilers offering it as an extension, as without it - performance often suffers very badly. * Universal call syntax (i.e. equivalence of `foo(myobj, myparam)` and `myobj.foo(myparam)` ). There were what I considered to be rather trivial objections, last decade, then it somehow went away.

kolbe 3y ago
I've found the lack of alias guarantees to be far more bark than bite. What's the primary use case? For automatic vectorization? Ultimately the only cost to check is an integer add and an integer comparison. Yeah, aliasing guarantees would eliminate those two ops (and eliminate generating the aliased version's code path). But in general, it isn't some 8x monumental cost that many people think it is.
- einpoklum 3y ago
  > What's the primary use case? For automatic vectorization? No. Without aliasing guarantees, every load via a by-ref/by-addr input param after a store via another such param must actually be executed. So either you manually cache your accesses, or you can't do loop unrolling, strength reductions, and possibly other optimization work. > Ultimately the only cost to check is an integer add and an integer comparison 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. 2. The interest is also for the _definition_ side of things, not just for the implementation. I want to tell the user of my function "pass unaliased arguments". This is important, because otherwise you have to provide a bunch of convoluted implementations for the case of there _being_ aliasing - which often changes the semantics of the function to something you had no intention of writing. 3. In real life, there is no guarantee that memory ranges with disjoint addresses are not aliases of the same region. There's probably no such guarantee that the standard makes, but IANALL.
  - kolbe 3y ago
    Sorry I didn't see your response. > 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. I wasn't implying to do it manually. Compilers do it all the time. 2, I understand and would use. I also want to restrict input alignment. 3, I never knew, but compilers I use for x86 on linux seem to think it's fine to just check memory address distances.

deleted 3y ago

[deleted]

omoikane 3y ago

P2558 should be "Add @, $, and ` to the basic character set", but somehow the article had % instead of $.

black_13 3y ago

[dead]