From: Warren Young
Date: November 24 2008 9:33pm
Subject: Re: RELEASE: v3.0.7
List-Archive: http://lists.mysql.com/plusplus/8196
Message-Id: <9ECB4951-42BA-4E50-A32A-F377D1EA4F9E@etr-usa.com>
MIME-Version: 1.0 (Apple Message framework v929.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On Nov 24, 2008, at 8:24 AM, Rick Gutleber wrote:

> Just out of curiosity, since mysqlpp::String is _not_ derived from  
> std::string, I was wondering about the decision process behind this,  
> since it seems to be a natural thing to do.

mysqlpp::String is designed to be invisible to MySQL++ users, for the  
most part.  It is simply what MySQL++ uses when it needs to return SQL  
field data to a caller.  Most of the time, it converts instantly to  
something else:

	int foo = row[0];

There's a String in there, you just don't see it.

We parallel the std::string interface is only because, well, why not?   
It's a perfectly reasonable model to follow, and familiar to any C++  
programmer.

That said, it's intentionally not a complete clone of std::string.  We  
don't copy anything over that can be used to modify the string.  This  
is, again, because it's only an output container.  We have a  
legitimate need for a different kind of wheel, so while we keep the  
pointless differences down as much as we reasonably can, the goal is  
not to reinvent std::string.

Besides which, it lets us do reference counted buffer management among  
MySQL++ classes, rather than rely on std::strings everywhere to get  
CoW behavior.  Look at SQLBuffer.