I failed to prevent the C++ committee fucking up std::to_chars, sorry.
-
@vitaut C++'s 40 year insanity with strings is amazing at this point
@Foritus and it's only getting worse!
-
@vitaut Uuuuh what happened exactly?
@cvtsi2sd we'll get 400 new overloads because they decided to add char8_t, char16_t, char32_t, wchar_t support.
-
@vitaut This sounds like something that requires a blog post to explain. I'm sadly out of the loop these days.
@dominikg I have no energy for this and will just focus on doing things right in https://github.com/vitaut/zmij
-
So to_chars will be semi-broken until 26, then briefly OK with my fix and then suck again in 29.
There is a small chance that LEWG will still prevent this but it is mostly rubber-stamping garbage nowadays (including my own =))
-
@cvtsi2sd we'll get 400 new overloads because they decided to add char8_t, char16_t, char32_t, wchar_t support.
@vitaut uh anything relating to those types goes in the "don't use, probably badly thought out and not/badly implemented in actual libraries" bin in my brain, and I thought I could ignore them forever (except wchar_t on Win32 API boundaries). I hope this won't force me to change my "ignore completely" stance.
-
@vitaut uh anything relating to those types goes in the "don't use, probably badly thought out and not/badly implemented in actual libraries" bin in my brain, and I thought I could ignore them forever (except wchar_t on Win32 API boundaries). I hope this won't force me to change my "ignore completely" stance.
@cvtsi2sd Ignoring is a good idea but everyone will still pay the cost in template bloat and build time.
-
@dominikg I have no energy for this and will just focus on doing things right in https://github.com/vitaut/zmij
@vitaut It is on my list of things to check out, good to know the background for it!
-
@cvtsi2sd Ignoring is a good idea but everyone will still pay the cost in template bloat and build time.
@cvtsi2sd and quality of diagnostics because of all the new overloads
-
@cvtsi2sd and quality of diagnostics because of all the new overloads
@vitaut yeah these are both death of a thousand cuts... Any error message related to a common operator is a nightmare, and I recently benchmarked the build of our monster legacy application, currently building with g++ 14 in -std=c++11 mode, with more recent -std settings to prove this point. Everything else being the same, compared to the baseline compiling in C++14 mode is 1.7% slower, C++17 is +7.8%, C++20 is +23.3% (ranges in <algorithm>?) and C++23 is +23.8%. This stuff has a very real perf cost even if you don't use it.
-
It will only happen in 29 and maybe hit mainstream in 30s though. I hope to retire by then or switch to Rust.
@vitaut maybe rustc will be fast enough for you by then … doubt it
-
@cvtsi2sd we'll get 400 new overloads because they decided to add char8_t, char16_t, char32_t, wchar_t support.
@vitaut more like w_shar_t
-
undefined oblomov@sociale.network shared this topic on