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

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-24 19:00:22

> 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