Peter Dimov wrote:
Yuval Ronen wrote:
So I'll try to re-phrase. The point I tried to make is that the pthread philosophy would be accepted by the C/C++ standard, but the pthread exact syntax doesn't have to. The C/C++ standard can adopt a different syntax.
Sure. We seem to agree that we want a C threading standard and a C++ threading standard, both based on the pthreads model, compatible with each other, supported by Microsoft and the rest of the world.
I guess the key word we are disagreeing about is "compatible" (which is what Emil's talking about). I assume you want threads created with the C++ API to be able to be manipulated by the C API. I don't see any major advantage in that.
Because C++ is compatible with C, one can come up with infinite number of examples of useful inteoperability between C libraries and C++ programs, as well as C++ libraries and C programs. I don't see how you could not see the advantage of that.
There's no precedence to such a thing. Do we want files opened with std::fstream to be read using fgetc()? Was this ever considered a factor when designing the C++ iostreams? Is there anyone missing this feature now? I've never heard anyone answering "yes" to any of those question (as much as that counts).
On the other hand, aren't most iostreams implementations based on the C standard library anyway? I can't answer the question whether it would make more sense if this was required by the C++ standard, however I'm pretty sure there are many benefits if such compatibility was official (which doesn't necessarily mean that there are no drawbacks.)
It's not that there's anything inherently wrong with such C<->C++ interoperability, as long as it doesn't cripple the C++ API.
My point exactly.
If it prevents creating the "ideal" C++ interface (which, IMHO, is something along the lines of Howard's non-copyable thread class), then I'd consider it a disadvantage.
If someone can show that to be the case, I'd agree. (Off-topic to this argument, but in response to your opinion, I am not sure I see the benefits of non-copyable thread handles. I am also concerned about the fact that in N2184 there is no thread handle for the current thread, which means that code that manipulates the current thread needs to be special case. To me, this looks a lot like C++ without a this pointer. Good design is all about selectively limiting unnecessary flexibility, but I am not sure that having copyable thread handles is unnecessary.) Emil Dotchevski