Yuval Ronen wrote:
Peter Dimov wrote:
Yuval Ronen wrote:
I never said that. If the C standard committee decides to fully adopt pthreads, I'd be fine with it. And if the C++ standard committee decides to be backwards compatible with C, and also adopt pthreads, I'd be fine with that too. I just don't think it should come instead of "the best" C++ interface, which is what I care about most.
Nobody can disagree with that. The problem in our discussion lies with tying whether one C++ API is better than another with whether the C++ API comes with a C API in the same proposal. This implies that the second C++ API contains design compromises purely because it has a C sibling - guilt by association - without actually stating any.
The problem with bringing a C and C++ in the same proposal is that you tie them together, while they are not (providing I assume interoperability is not an issue, which is probably not agreed by everyone). It makes it hard, at least psychologically, at least for me, to accept one without the other, which is what I'm after.
True. But as I said, someone had to do it (in my opinion). That is, make the assumption that the committee would like to accept an unified C/C++ proposal and proceed based on that. I do realize that this leads to a psychological penalty for the C++ part of N2178. My aim was to make sure that it doesn't lead to a design or efficiency penalty.