From: Warren Young
Date: September 19 2005 5:28pm
Subject: Re: locable.h: strange design dessision??
List-Archive: http://lists.mysql.com/plusplus/4955
Message-Id: <432EF551.2000700@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.