Hi,
Christophe de Vienne wrote:
Hi,
I'm currently working on the threading wrappers, mainly hidding the implementation details dependant from the thread system we use.
I have a few questions :
1) In Thread::~Thread(), the join is done directly instead of using Thread::join, which make code duplication. Is there a particular reason for that ?
You're right Thread::join must be directly called. However I think I did not call it directly because of a deadlock under Windows.
2) Thread::thread is protected. Since I'm hidding it, the children classes won't be able to access it directly.
The way I hide is the following :
In thread.h :
class Thread {
// ...
protected:
struct Impl;
Impl const & getImpl();
private: Impl impl; };
In thread.cpp: 31 struct Thread::Impl 32 { 33 Impl(): thread(0) {}; 34 35 /** Thread descriptor */ 36 #ifdef LOG4CXX_HAVE_PTHREAD 37 pthread_t thread; 38 #elif defined(LOG4CXX_HAVE_MS_THREAD) 39 void * thread; 40 #endif 41 42 };
This mean that children classes wanting to access the underlying descriptor need to know the Impl struct.
So what I would propose is to put the Impl declaration is a separate file, threadimpl.h, which the children class implementation file can include.
Pre-question is : Does this solution looks good to you ?
More important question : Is it really necessary to have such a possibility ?
I don't think so. Thread overrides must be platform independant, so the Impl struct has not be known.
I mean the abstraction should provide everything needed, and I don't see a real case in which it's necessary. Moreover doing this will make more complicated to elimate those damn macros we're trying to get rid of.
I have the same question for threadspecificdata and CriticalSection.
Same answer !
More questions may comes later :-)
Regards,
Christophe
Regards,
-- Michaël CATANZARITI log4cxx project manager
log4cxx user mailing list:
mailto:[EMAIL PROTECTED] log4cxx developer mailing list:
mailto:[EMAIL PROTECTED]
