Thread: libpq++ updates

Greetings,

There are a couple of changes I would like to make to libpq++,
but I thought I would write first to check
-if there would be any interest in including any of these items
-if anyone else has these items covered
-if any of these items are clearly bad ideas

a) add string overloads to the methods accepting char*'s

b) allow for a minimized libpq++.h

including libpq++.h includes a host of other files dumping
quite a few definitions into the global namespace that,
strictly speaking, are not necessary for a user's application.
For example, I ran into trouble when c.h typedef'ed Index,
which I had already typedef'ed to a different value in my
application.

The idea would be to have the user visible header include
only the class specifications and none of the postgres.h
internal definitions.  These could be included separately
should the use so need them.

Also, as namespace is fully supported in the latest gcc's,
this might be a good time to optionally include the
classes in a single namespace (PQ, LibPQ, Pg, PgXX or some such).

c) Move PgConnection::Connect and PgConnection::PgConnection()  from the protected to the public interface.

Any reasons why this would be undesirable?
It would require a check at the start of some methods for the
presence of a connection, but the performance hit shouldn't
be significant.

any thoughts will be appreciated,

-d

Wed, May 24, 2000 at 04:54:05PM -0400, dagraz@mindspring.com пишет:
> There are a couple of changes I would like to make to libpq++,
> but I thought I would write first to check
> a) add string overloads to the methods accepting char*'s

Are you mean somefun(const char *) --> somefun(string) or
somefun(const string &) ? It would be useful, with 'string' from STL.
But it will force class users to use STL :(.

> 
> c) Move PgConnection::Connect and PgConnection::PgConnection()
>    from the protected to the public interface.
> 
> Any reasons why this would be undesirable?

The only reason is that: less public members is better. If you really need,
for example, PgConnection::Connect() in your program, you can derive
class from PgConnection or PgDatabase and use the protected member in derived
class methods. These protected members have almost no use for 'public users'.

> any thoughts will be appreciated,

Maybe some methods like ExecTuplesOk, ExecCommandOk should emit exceptions?
Something derived from standard class 'exception', like

#include <exception>
class PGerror : public exception
{
private:string err; // or, maybe, 'const char *err' if you don't like STL
public:PGerror(PgDatabase *db) : err(db->ErrorMessage()) {}virtual const char *what() const { return err.c_str(); }
};

-- 
jk