pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedlibpq++ and strings.
4+ messages / 3 participants
[nested] [flat]
* libpq++ and strings.
@ 2001-05-17 01:04 Carlos Moreno <moreno@mochima.com>
2001-05-17 12:59 ` Re: libpq++ and strings. J. T. Vermeulen <jtv@cistron-office.nl>
0 siblings, 1 reply; 4+ messages in thread
From: Carlos Moreno @ 2001-05-17 01:04 UTC (permalink / raw)
To: pgsql-interfaces
I wonder why all the string parameters and return values
are expressed in the form of char * or const char * ?
After some time sticking to C++ and learning to hate
(even more :-)) C strings, I find myself annoyed by
not being able to do this:
if (db.ExecTuplesOk ("select * from products"))
{
for loop ......
if (db.GetValue(row, "discontinued") == "t")
{
cout << "Disconinued";
}
Or something like this:
// Get results from one query and use one field to
// produce another query:
string query = "select * from table where ID='" +
db.GetValue (row, "prodID") + "'";
Don't you just hate it? At least the second one is
not that bad, because the compiler won't let you add
two pointers. But the first one slips through the
compiler, who doesn't have a problem with comparing
two pointers -- it can not even know that the comparison
will be unconditionally false to warn you... :-(
Why not just changing all the parameters and return
values to `const string &' and/or `string' ?
Any thoughts?
Carlos
--
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: libpq++ and strings.
2001-05-17 01:04 libpq++ and strings. Carlos Moreno <moreno@mochima.com>
@ 2001-05-17 12:59 ` J. T. Vermeulen <jtv@cistron-office.nl>
2001-05-18 01:41 ` Re: libpq++ and strings. Carlos Moreno <moreno@mochima.com>
0 siblings, 1 reply; 4+ messages in thread
From: J. T. Vermeulen @ 2001-05-17 12:59 UTC (permalink / raw)
To: Carlos Moreno <moreno@mochima.com>; +Cc: 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: libpq++ and strings.
2001-05-17 01:04 libpq++ and strings. Carlos Moreno <moreno@mochima.com>
2001-05-17 12:59 ` Re: libpq++ and strings. J. T. Vermeulen <jtv@cistron-office.nl>
@ 2001-05-18 01:41 ` Carlos Moreno <moreno@mochima.com>
2001-05-25 16:33 ` Re: libpq++ and strings. J. T. Vermeulen <jtv@cistron.nl>
0 siblings, 1 reply; 4+ messages in thread
From: Carlos Moreno @ 2001-05-18 01:41 UTC (permalink / raw)
To: J. T. Vermeulen <jtv@cistron-office.nl>; +Cc: pgsql-interfaces
"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
--
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: libpq++ and strings.
2001-05-17 01:04 libpq++ and strings. Carlos Moreno <moreno@mochima.com>
2001-05-17 12:59 ` Re: libpq++ and strings. J. T. Vermeulen <jtv@cistron-office.nl>
2001-05-18 01:41 ` Re: libpq++ and strings. Carlos Moreno <moreno@mochima.com>
@ 2001-05-25 16:33 ` J. T. Vermeulen <jtv@cistron.nl>
0 siblings, 0 replies; 4+ messages in thread
From: J. T. Vermeulen @ 2001-05-25 16:33 UTC (permalink / raw)
To: Carlos Moreno <moreno@mochima.com>; +Cc: J. T. Vermeulen <jtv@cistron-office.nl>; pgsql-interfaces
On Thu, 17 May 2001, Carlos Moreno wrote:
> *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++ :-))
I'm not getting much work done ATM, being "between machines" as one might
say, but one thing I expect I'll be needing help with is simply to find
the things in libpq that need to (or need not) be wrapped in libpq++.
Jeroen
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2001-05-25 16:33 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-05-17 01:04 libpq++ and strings. Carlos Moreno <moreno@mochima.com>
2001-05-17 12:59 ` J. T. Vermeulen <jtv@cistron-office.nl>
2001-05-18 01:41 ` Carlos Moreno <moreno@mochima.com>
2001-05-25 16:33 ` J. T. Vermeulen <jtv@cistron.nl>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox