Re: libpq++ and strings.

"J. T. Vermeulen" wrote:
> 
> On Wed, 16 May 2001, Carlos Moreno wrote:
> 
> > I wonder why all the string parameters and return values
> > are expressed in the form of char * or const char * ?
> 
> Performance would be one reason, I'd say. 

Oh, c'mon!!  Enough with that myth!  :-)

I'm probably naive and not too experienced when it comes to 
databases...  But we're talking accessing information from 
disk, perhaps across a network, and you estimate that an 
extra allocation and copying of memory will have a measurable 
impact on overall efficiency?

I know the PostgreSQL backend might have some of the information 
in the memory, and that the access mechanisms may use unbelievably 
efficient techniques (generally speaking), but I think the amount 
of work required to execute a query and get the data to the 
requesting program is orders of magnitude more than the overhead 
involved in a string construction.

Notice also that most C++ libraries implement copy-and-write 
semantics for strings, which means that copying them is almost 
as inexpensive as returning a char *.

> of course the underlying library uses const char *'s anyway.  Also of course,
> a string is easily constructed from a const char * but the other way needs an
> explicit method call.

Hmmm...  Who are we kidding...  If someone is working with C++, 
they will want string objects anyway;  and even if not, they 
sure will be used to putting the .c_str() if they need it to 
pass it to atoi/atof, or opening a file, etc.   I think it is 
more what you gain than what you would sacrifice...

> I guess this one boils down to how important performance is. 

Hmmm, I don't know...  I get the feeling of premature optimisation 
here...  :-)   It's true that we're not talking about something 
made for a particular application -- we're talking about a library 
for usage in a wide variety of applications, so efficiency is a 
must -- but again, my argument is that given that we're talking 
about accessing fields of databases, the overhead of creating an 
extra string has to be negligible...  (after all, there are fields 
that are numeric, and the library handles them all as strings... 
There is an overhead in that, but that's simply the way it works)

> One thing I'd
> like to do about it in the upcoming version is to provide type-safe access to
> the tuples.  There'd still be a GetValue() returning const char *, but you
> wouldn't need to use it the way you showed in your example, because you'd be
> able to read it simply as a native bool.

*Now* we're talking!  :-)  That would be the real hit!  I was 
actually thinking about doing it myself for my personal use... 
Do you need help with that?  :-)   (I'm no particular expert 
with databases, but I do know my way around with C++  :-))

Cheers,

Carlos
--