List:MySQL++« Previous MessageNext Message »
From:Philippe Dirkse Date:March 16 2007 6:14pm
Subject:Re: Why does ColData need two strings for the same data?
View as plain text  
> Philippe Dirkse wrote:
>> I noticed the ColData template copying the 'c' string data
>> passed to it during construction twice: once into itself (as a
>> derivate from std::string) as the 'entire' buffer (so using the
>> std::string(char*, int) constructor) but then also into a member
>> std::string buf_ which only copies the contents till the first '\0'
>> encountered. Is this really necessary? I can understand why you want
>> to make a copy of the data, but twice?
> Yes, you're right, this is inefficient and hard to justify.  I didn't 
> write it, so my best guess at the reasoning behind it is that this is all 
> defined in ColData_Tmpl, which is not *necessarily* instantiated with 
> std::string or similar.  It reduces coupling between the template proper 
> and the instantiations of it.
> But, that's weak.  In all the years I've been maintaining and using this 
> library, I've never seen anyone use ColData* in any way not prescribed by 
> the library's current design.  For that matter, the typedef MutableColData 
> is only used once within the library, and it's a questionable use to begin 
> with.
> For v3.0, I propose that we collapse this whole thing into a concrete 
> class with no more functionality than is needed within the library.  We 
> might even change the public inheritance from const std::string to a 
> private inheritance, or even just a private data member.  We don't 
> actually need an is-a relationship here.

Well, like I said, I only inspected the ColData template because I could not 
why I could not retrieve my blob data via the Row::operator const char*(). 
It's really weird
when you look at the constructor to see that you DO actually copy the entire 
thing into
the ColData object but only until the first '\0' into the buf_ string member 
which is used for
accessing the data.

> For v2.3 (or thereabouts), all I think we can do is stop using the buf_ 
> member, and keep everything in the parent class's data members.  We'll 
> carry around a useless empty std::string instance, but we break the ABI if 
> we go further.
>> Another small suggestion/request: is it possible to add the function
>> 'Row::raw_data(char* fieldName) to the Row class as a convenience
>> function? Why support it for operator[] only? After searching the
>> source I found that using
>> raw_data(theRow.parent().field_num(fieldName)) also does the trick
>> but give us some more (syntactic) sugar!!!
> This feels a little odd, since raw_data shouldn't be all that widely used. 
> It's a low-level kind of thing, so why is sugar desirable here?

Accessing blob data. You cannot do it using the ColData wrapper
(unless there is a backdoor that's eluding me) so raw_data() is the way
to go. I use a serialization/visitor approach in my code to access the 
so everything is retrieved by key name, hence my suggestion for this method.

> I'm guessing you're proposing this feature to cover the remaining 
> weaknesses in the library's null character handling.  I'd rather fix that 
> than add inappropriate sugar that we'll regret later.

So well yes, in a way these problems are indeed caused by the null handling
and yes especially when working with blob data this does become a nuisance.
My main reason for asking though is because I was curious whether there was
a specific reason for the way the thing is currently implemented.



Why does ColData need two strings for the same data?Philippe Dirkse14 Mar
  • Re: Why does ColData need two strings for the same data?Warren Young15 Mar
  • Re: Why does ColData need two strings for the same data?Philippe Dirkse16 Mar
    • Re: Why does ColData need two strings for the same data?Warren Young17 Mar