Ctrl+f "Reflection" -> 0 results Maybe next year ..
pybind29 has a nice ring to it.
Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
31–40 of 141 posts
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#32> 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.
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++-...
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#33> 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.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#34I 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.
I for one welcome the new features! I don't think it's too hard to learn a few new things every 3 years.
> I don't think it's too hard to learn a few new things every 3 years.
Do you think that in software development circles backwards incompatible changes only happen each 3 years?
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#35It'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.
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.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#36I 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.
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#37"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/p27...
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.
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...
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#38Does 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).
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#39> 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. 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 uses modules).
Re: Trip report: Summer ISO C++ standards meeting in Varna, Bulgaria
#40It'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.
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.
>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).