From: | "J(dot) T(dot) Vermeulen" <jtv(at)cistron-office(dot)nl> |
---|---|
To: | Carlos Moreno <moreno(at)mochima(dot)com> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: libpq++ and strings. |
Date: | 2001-05-17 12:59:34 |
Message-ID: | 20010517145934.W14645@cistron.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
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. const char * is easier to tune, and
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.
OTOH I do think you have a point w.r.t. the obvious mistakes to make, and the
lack of help from the compiler in spotting them.
> Why not just changing all the parameters and return
> values to `const string &' and/or `string' ?
One possible tradeoff (and one I was leaning towards) is to take string
parameters (so passing const char [] will still work) but return const char *
in case you don't need the extras of a full C++ string. Unfortunately this
doesn't help with the comparison-with-string-constant problem you cite.
I guess this one boils down to how important performance is. 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.
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Hayner | 2001-05-17 13:44:23 | Re: help with programming |
Previous Message | Carlos Moreno | 2001-05-17 01:04:26 | libpq++ and strings. |