Re: locable.h: strange design dessision??

pps wrote:
> class Lock, BasicLock, and Locable are strange pieces of code in my 
> point of view. 

That's because you don't understand the motivation, which isn't 
surprising because it hasn't been documented anywhere but the Wishlist yet.

> First of all, there's no need to have virtual methods for 
> such simple class. 

Yes, there is, because there will be an override someday.

> Locable has a really doubtful piece of code - it 
> creates BasicLock using new! 

Read up on the pImpl idiom.  (Also called Handle-Body, and other 
things.)  BasicLock is the current implementation, but in v2.1, there 
will be alternate implementations for platforms that support locks.  I 
anticipate a Boost::Threads based implementation at least, and possibly 
others.  And there still must be a BasicLock implementation for those 
platforms that do not support Boost::Threads, or where the user doesn't 
want to install it.

> isn't it's strange to change threading models at runtime? 

The purpose of hiding the implementation behind a pointer is so we can 
change that implementation without breaking the library's ABI, which 
adding data to a plain Lockable base class would do.

> I think I never saw anything like this.

See Advanced C++ by James Coplien.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx