2 ms·

The article's point in a nutshell: > The problem is that std::simd in 2026 is the 2012 solution arriving after the world moved on. The committee spent a decade

by zombot 5mo ago

The article's point in a nutshell: > The problem is that std::simd in 2026 is the 2012 solution arriving after the world moved on. The committee spent a decade polishing a library-based approach while compilers solved the easy cases automatically and ISPC solved the hard cases with language-level support. I find it interesting that the C++ committee would make that kind of mistake. Shouldn't they know better?

tialaramex 5mo ago
> I find it interesting that the C++ committee would make that kind of mistake. Shouldn't they know better? The main reason why people attend WG21 meetings is to get their pet features into the C++ language or the associated standard library. To some extent you can further that goal by shooting down other people's suggestions, especially if they would conflict ‡ C++ is a vast sprawling language. There are no genuine "C++ experts" for the same reason there aren't any people who know all of mathematics. There are a lot of people who are experts on some corner of the language or its libraries, and some who know a little bit about almost everything but no overarching experts. ‡ A good way to do this work would try to have such rivals all work together to improve the language, a sort of "yes, and" collaborative approach but although this has occasionally been able to work in C++ the whole WG21 structure works against it, in particular they vote to achieve consensus, which is not what the word "consensus" means and rewards appeasing haters much more than it does finding out what the problems are and working to fix them.
fg137 5mo ago
(having no first hand experience with WG21) Many people think there are a lot of problems with C++ committee and the standards process. Some would claim that the ISO governance model doesn't work at all. There is a lot of drama that the outside world has no idea about, because much of the discussion is behind closed doors. You can look it up (e.g. on blogs and /r/cpp), but I am not linking to anything because lots of content is very biased and hard to verify. Something that is not controversial and worth a read is https://thephd.dev/embed-the-details https://thephd.dev/embed-the-details and you can see the point. I do feel the TC39 (the group behind the ECMAScript/JavaScript standard) seems more practical and effective. There are disagreements and dramas but not nearly as bad as with C++.
- germandiago 5mo ago
  The best witness to the committee (I do not think it is that bad) is to check C++ pre 11 and C++26. There will always be things people want or comolaints. But the list of useful features and fixes is very long. But you always see the contentious topics at the top, shadowing a lot (most) of the work that is delivered.
jcranmer 5mo ago
The C++ standards committee is pretty damn dysfunctional at this point for a variety of reasons. Only like 10% of the committee are actually responsible for an implementation in some manner; the vast majority are users, often looking to get their feature into the standard. This also means that only a tiny minority of the committee actually understands things like the difference between a prototype hack and a proper implementation. I get the sense that it's extremely bad on the library front--all of the standard library implementors I know are basically pleading "please stop adding new features, we want time to catch up." One of the big issues with library features is that library vendors can't just copy-paste existing implementations for licensing reasons, so they have to reimplement it largely from scratch, and they people doing so may not necessarily be skilled in that particular domain. On top of that, standard libraries are much more sensitive to ABI breaks than other libraries are, so a bad design gets ossified to a much worse degree than regular libraries. The best examples of baked-in bad implementations are std::unordered_map and std::regex, but honestly even std::unique_ptr has similar ABI-unfixable issues (it's not a pointer for ABI calling conventions). Yet you still see people cheer on additions to the standard library because obviously those people are going to make existing implementations better.

by zombot 5mo ago

tialaramex 5mo ago

> I find it interesting that the C++ committee would make that kind of mistake. Shouldn't they know better? The main reason why people attend WG21 meetings is to get their pet features into the C++ language or the associated standard library. To some extent you can further that goal by shooting down other people's suggestions, especially if they would conflict ‡ C++ is a vast sprawling language. There are no genuine "C++ experts" for the same reason there aren't any people who know all of mathematics. There are a lot of people who are experts on some corner of the language or its libraries, and some who know a little bit about almost everything but no overarching experts. ‡ A good way to do this work would try to have such rivals all work together to improve the language, a sort of "yes, and" collaborative approach but although this has occasionally been able to work in C++ the whole WG21 structure works against it, in particular they vote to achieve consensus, which is not what the word "consensus" means and rewards appeasing haters much more than it does finding out what the problems are and working to fix them.

fg137 5mo ago

(having no first hand experience with WG21) Many people think there are a lot of problems with C++ committee and the standards process. Some would claim that the ISO governance model doesn't work at all. There is a lot of drama that the outside world has no idea about, because much of the discussion is behind closed doors. You can look it up (e.g. on blogs and /r/cpp), but I am not linking to anything because lots of content is very biased and hard to verify. Something that is not controversial and worth a read is https://thephd.dev/embed-the-details https://thephd.dev/embed-the-details and you can see the point. I do feel the TC39 (the group behind the ECMAScript/JavaScript standard) seems more practical and effective. There are disagreements and dramas but not nearly as bad as with C++.

germandiago 5mo ago
The best witness to the committee (I do not think it is that bad) is to check C++ pre 11 and C++26. There will always be things people want or comolaints. But the list of useful features and fixes is very long. But you always see the contentious topics at the top, shadowing a lot (most) of the work that is delivered.

jcranmer 5mo ago

The C++ standards committee is pretty damn dysfunctional at this point for a variety of reasons. Only like 10% of the committee are actually responsible for an implementation in some manner; the vast majority are users, often looking to get their feature into the standard. This also means that only a tiny minority of the committee actually understands things like the difference between a prototype hack and a proper implementation. I get the sense that it's extremely bad on the library front--all of the standard library implementors I know are basically pleading "please stop adding new features, we want time to catch up." One of the big issues with library features is that library vendors can't just copy-paste existing implementations for licensing reasons, so they have to reimplement it largely from scratch, and they people doing so may not necessarily be skilled in that particular domain. On top of that, standard libraries are much more sensitive to ABI breaks than other libraries are, so a bad design gets ossified to a much worse degree than regular libraries. The best examples of baked-in bad implementations are std::unordered_map and std::regex, but honestly even std::unique_ptr has similar ABI-unfixable issues (it's not a pointer for ABI calling conventions). Yet you still see people cheer on additions to the standard library because obviously those people are going to make existing implementations better.