Subj : Re: Thoughts about threads in C++
To   : comp.programming.threads
From : Maciej Sobczak
Date : Mon May 30 2005 10:12 am

Hi,

Arash Partow wrote:

> As far as the extern C issue goes, why on earth would I want to be
> extern C'ing a C++ wrapper of an API which is already available in C?
> why wouldn't the person just use the standard pthread API in the first
> place?

It is not the point of making the whole C++ wrapper extern "C". And it 
is also not the point to please the users, but to please the standards.
The problem is that you assume that a pointer to function has the same 
"form" no matter whether it has a "C" linkage or "C++" linkage. This is 
the case in most popular platforms, but it is not universally true.
You pass the pointer to the static starter function (which is a member 
function and therefore has "C++" linkage) to the pthread_create 
function, which is a "C" function and does not have to understand the 
"C++" kind of pointer - they can have different forms.
Your code may fail to compile on some platforms.

The solution is to put the starter function outside of the class and 
declare it extern "C".

> As for locking etc, I have to disagree with you.

That's OK.

> What C++ is about is
> really left to the programmer. If *they* wanted to they could have the
> made the language more restrictive like java and have something like
> the synchronized syntax. But its not like that, C++ lets you do pretty
> much whatever you can get away with, and if you're happy with that, and
> if that gets the job done, then that should be enough. Bringing up the
> example of why the "finally" keyword doesn't exist in C++ just shows
> that what you think about this issue and what i think are two different
> things.

> Also the derived thread class method/pattern (whatever), is pretty
> standard way of threading a piece of code in OO manner. Its popular,
> its simple to implement and understand, and has a very low over-head.

As I've already written, I know that this approach is quite popular. 
This does not make it any more correct from the design point of view, 
however.
What I don't like in it are the following points, which are forced by 
your approach:

1. thread is an object
2. some object "is a" thread

Whereas the first is rather a delicate issue, the second is a clear 
misuse of inheritance. IMHO, of course.

> Btw I noticed in your messaging example, you templated the
> ListenersCollection
> and Messaging classes with Mutex policies. Though in your example code
> you pass NoSynchronization, I'm assuming people can implement their own
> mutexing policies where by you invoke their implementations of lock and
> unlock?
> 
> Wouldn't that be a form of technical hypocrisy or technopocrisy? ;)

The article you mentioned was written a couple of years ago (it was 
published long after I submitted it). I'm sure that today I would not 
write it the same way. So no, this is not hypocrisy - I'm just still 
learning.

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

.