On Mon, Jun 13, 2005 at 01:45:28PM -0600, Warren Young wrote:
> >The reason to get rid of stream inheritance would be the copying that
> >Query objects might do,
> Can you clarify that, please?
Well, I read it somewhere from someone I believe knows what he's talking
about (I think it was Nathan Meyers, but I can't find it anymore, so don't
A quick search in google groups turns up: http://tinyurl.com/ap3m8
I browsed around the libc++ headers, and noticed a distinct lack of
memory allocation in streambufs and base iostream objects, where I assumed
there would be. This is good, since copying streambufs and stream
objects just copies the pointers to memory allocated elsewhere in
the normal case, and won't create leaks even if you try.
But as the link above points out, there could be state involved in
a streambuf: pointers to get/set locations in a circle buffer, for example,
which would then be duplicated as straight pointer copies in the copied
stream objects and go out of sync.
Some iostream implementations even define iostream copy constructors
and operator=() as private, so it can't be relied on for portability,
I suspect. (Although this may be a non-standard thing in these
iostream libraries, added for safety). (http://tinyurl.com/duyuq)
In mysql++, copying occurs in the mysqlpp::Connection::query() member's
return value, so these dangers are (in theory, anyway) still there.
The good news, is that std::stringstream is based on a streambuf that
uses std::string for its storage (which copies properly), and
std::stringstream contains the streambuf internally (no pointers to
external streambufs) so copying works fine for string streams and streambufs.
I'm basing this on g++'s libstdc++ headers on my system, but I believe
all standard std::stringstream objects use std::string for storage,
so we're safe.
In summary, sorry, it turns out it's not a reason to remove the
stream inheritance in SQLQuery. It came close though. :-)
I do think inheriting from stringstream provides the least-maintenance
solution for a query object, so I'm glad I found that it can stay.
Maintaining our own set of overloaded operator<< and >> seems like a lot