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

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-25 15:20:38

> >> <snip>
> >> The fact that pthreads exist is completely irrelevant. We setup a C++> >> standard, and it should be as good as it gets. The POSIX model is good,> >> so we take it. The POSIX syntax is not so good (for C++, obviously) so> >> we don't take it.> > > > What follows then, is that you would like existing pthread C libraries to > > continue to be non-portable. I don't see why. I might be blind, but I don't > > see why would that be desirable.> > 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.
 
If pthreads becomes part of C or C++ in its current form, what you'll get is that I can write C++ code on pthreads, or C code on pthreads, and it'll work. You will not be able to respond in C++ to a pthread_cancel, because pthread is a C standard and therefore doesn't specify that pthread_cancel throws.
 
If all of your code is in C++, you'd know not to call pthead_cancel because it won't work. That would be no problem because you can work at the C++ <thread> level where everything is nice and cool -- but what if a 3rd party library built on <pthread> calls pthread_cancel?
 
Even today, on non-windows platforms where pthread is standard, we have this problem. So this discussion is not about adopting pthreads. It's about adopting an extended pthread interface, which specifically deals with C/C++ interoperability.
 
It is because this issue affects both the C and the C++ community that we can not simply say "we'll leave it up to the others to figure out."
 
> > <snip>
> > While strictly speaking I do not *need* to use existing C libraries in my > > C++ code, I *want* to be able to. And I mean this in general, not just for > > threading libraries.> > Ok, so we come again to what seems to be the true heart of the debate. > Do we want interoperability between the C library and the C++ library, > and how much are we willing to pay for it. And it seems we give > different answers to this question.
I'm sure you're familiar with the zlib library. It's free, and if it does what you need, would you rather use it as-is, or would you "port" it to C++?
_________________________________________________________________
Your friends are close to you. Keep them that way.
http://spaces.live.com/signup.aspx