Hi,
I tried to review some code inside mysqlpp and possibly modify it for me
(I want to replace some parts with code from other libraries, eg
boost.date_time etc, since I use date_time in my app) and I found some
strange code

class Lock, BasicLock, and Locable are strange pieces of code in my
point of view. First of all, there's no need to have virtual methods for
such simple class. Locable has a really doubtful piece of code - it
creates BasicLock using new! I find it to be really strange, as I don't
see any need to have pointer to an object that's one byte in size.
Perhaps, the intention was to have possibility replace underlying Lock
with some other Lock object, but isn't it's strange to change threading
models at runtime? As with my first mail I may be wrong without knowing
the underlying code, but why it was designed this way? I think I never
saw anything like this.
This issue is well discussed in "Modern C++ Design" and loki-lib has
some good code for implementing it.
basically, from this book it seem that a better decision is:
template<template <class> ThreadingModel>
class connection : ThreadingModel<connection> {}

and inside connection::method(){
lock(*this);
//do something...
}

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

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

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

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.

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.

See Advanced C++ by James Coplien.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren Young wrote:
As far as I understand this will allow people to download newer
mysqlpp.dll and just replace it without rebuilding, am I correct?
What's ABI stands for??
How many overrides for this class there might be? (1 or 2 more).
Anyways, threadingmodel classes could be all inside headers without .cpp
files... if that solves this problem

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

pps wrote:
Within a major version, yes, that's the idea.

Application Binary Interface. That is, a program using a dynamic or
shared library version of MySQL++ has expectations such as object layout
that must be preserved within a major version. Essentially, we're
promising not to break the ABI until v3.x.

I anticipate only 2 right now, both of which I mentioned in my previous
message.

No, it doesn't help, because Lockable is used as a base class. If its
object layout changes, the ABI of classes derived from it also change.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw