From: "J. T. Vermeulen" <jtv@cistron-office.nl>
Date: Thu, 17 May 2001 14:59:34 +0200
To: Carlos Moreno <moreno@mochima.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: libpq++ and strings.
Message-ID: <20010517145934.W14645@cistron.nl>
Mail-Followup-To: Carlos Moreno <moreno@mochima.com>,
	pgsql-interfaces@postgresql.org
References: <20010514151702.F14645@cistron.nl> <3B03239A.E4685125@mochima.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <3B03239A.E4685125@mochima.com>;
	from moreno@mochima.com on Wed, May 16, 2001 at 09:04:26PM -0400

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