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
--