Peter Dimov wrote:
Anthony Williams wrote:
However, Microsoft do not supply such an interface, so someone has to write one. Writing one might be a good idea, but using it to implement the C++ API, when the C++ API could be better written using the win32 API directly seems a bad plan to me, especially if you could use your C++ API to implement pthreads.
It depends on what your plan is supposed to achieve. If you want to gradually transition from where we are now to a point where Microsoft does supply a pthread layer, it's not a bad plan at all. If you want something else, it might or might not be, depending on what exactly do you want. Anyway, I see that you are taking this as an argument, so I'll leave you to your opinion.
Excuse me for being a bit daft here, but why is our plan to make Microsoft supply a Windows pthread layer? The reason we all want that today, is because there *is no* C/C++ threading standard. Once there is such a standard, we wouldn't care anymore about the underlying OS API. That's the whole purpose of this (or any) standardization effort, isn't it? Do we care about the OS file-system API? No, we don't, because there's std::fstream and soon std::tr2::file_system, that's why. Doesn't the same apply to threading?