What is the reason why clang and gcc do not implement std::hardware_{constructive,destructive}_interference_size?

Question

I know the answer could be that they did not prioritize it, but it really feels like intentional omission, they already have plenty of C++20 core language/library features and this C++17 feature is still not implemented.

In fact according to this table it is the only C++17 library feature that both clang and gcc did not implement.

Lemmy

did you read this? Its a discussion also about some problems in implementing it – Miculek

Most likely they have too many platforms to support that makes this difficult to implement. MSVS on the other hand has very few CPU's it targets. – Savannahsavant

@idclev463035818 Why does every message there show up as being from the same person? – Morocco

@Morocco What, people can't talk to themselves anymore? ;) Looks like some sort of email to forum post adapter going on. – Savannahsavant

@Morocco What's that, Nathan? – Morocco

@Nathan From the main page of the forum: This forum is an archive for the mailing list [email protected] (more options) Messages posted here will be sent to this mailing list. Clang is a subproject of the LLVM Project . The cfe-dev mailing list is the best way to talk with other developers on the project. It is for everything clang related (questions and answers, bug reports, etc), other than patch submission/discussion. In addition to the cfe-dev list, a significant amount of design discussion takes place on the cfe-commits mailing list – Savannahsavant

@AlexisMurzeau This is a fun way to communicate. – Morocco

@Morocco in the messages you can see that is was a dialogue between JR, Eli and others. Anyhow the last message there is from october 2018, so there must be more recent information on the topic – Miculek

"That would be useful feedback on the paper… prior to it getting into C++17" :) I guess it is a problematic feature to implement... kind of sucks, but TIL to not use it for portable C++ code. – Lemmy