Re: [boost] Boost.Threads, N2178, N2184, et al

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-25 07:23:38

Emil Dotchevski wrote:
>> 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.

Have you ever needed such interoperability in practice? I haven't. 
That's not to say it's nonsense. I just think it's rare enough to be 
negligible.

>> 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.)

Again, saying "I'm pretty sure there are many benefits if..." is 
hypothetical. I haven't met such benefits myself in real life.

>> 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.

So we agree ;-)

>> 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.

I'd leave that for Howard (whose hands finally slipped out ;-) ) to 
answer. He'll be much better at this than me...