Re: Getting to learn libpqxx - Mailing list pgsql-interfaces

Sorry for chipping in so late--I'm just back from a vacation and trying to
catch up with a few thousand unread emails.  My Internet connection in
Thailand was sporadic at best.  Hope it's still of some use.


> (You don't need to specify the .h extensions in C++)

Actually, that only applies to the standard C++ headers.  These now have
names without the ".h" which may exist side-by-side with, and need not be
compatible with, the ".h" ones.

On to Michiel's message.  I'm afraid many of the problems here are C++
questions, rather than libpqxx-specific problems.  Check out the test
programs provided with libpqxx; if you download the latest Development
version from http://pqxx.tk/, test001.cxx has been cleaned up a lot to
provide a simpler example.  See below for more.


> -----Original Message-----
> From: Michiel Lange [mailto:michiel@minas.demon.nl]

> Yes, pqxx/connection.h is in the include path, the errormessage I would
> get would be very different...

Are you also using the pqxx namespace?  Remember, all symbols defined by
libpqxx are within the pqxx namespace just as cout, string etc. exist only
inside the std namespace.


> foo = bar << "blah" << bla;
>
> would be perfectly valid... but I can be mistaken... I will try your
> suggestion and see if it will help...

Why not just use the + operator?

foo = bar + "blah" + bla;


> yet, the problem that the declaration (Connstring *db;) is not valid...

There is no Connstring class in libpqxx.  Do you mean Connection?  Or did
you define a Connstring

BTW, are you sure you want a pointer?  In many cases it'll be easier to
create a Connection object as a local variable.


>>Only to discover that there is hardly any documentation on how to access
>>stuff... now I, myself am more a C-programmer, and I know C++ is pretty
>>much different... it is really hard for me to think in classes and stuff,
>>to think object-oriented...

Here's the bad news: Object-orientation is no longer where the action is
in C++.  It's moved on to generic programming and whatnot.


>>         db = new Connection(connstring,true);
>>
>>         if(db->is_open())
>>         {
>>                 cout << "Connection succesful!" << endl;
>>                 cout << db->Options();
>>         }
>>         else
>>         {
>>                 cout << "Something went wrong... oops" << endl;
>>         }

This is not needed.  The constructor will throw an exception if it fails. 
Besides, it may defer the actual opening of the connection until it is
actually used.  So all you need to do is:

int main(int argc, char *argv[])
{ try    // (which you should do anyway!) {   // Build connstring...   Connection db(connstring);   // Use db... }
catch(const exception &e) {   cout << e.what() << endl;   return 1; } return 0;
 
}


>>         delete db;
>>         return 0;

This is not the safe way to do it!  If your program throws an exception,
the delete may never be performed.


>>I get my first errors at "Connection *db" declaration... there is no
>>Connection defined...
>>Can anyone point out how to reference the classes libpqxx has?

They're in namespace pqxx.  So you can either write "using namespace
pqxx;" at the head of your program (just like the example programs do) or
refer to Connection etc. as pqxx::Connection etc.  Chances are you'll want
the first option.


>>Also I was curious if my connstring was correctly built, but that is
>>another subject I think... One other very important thing would be: how
>> can
>>I find out the error PostgreSQL will throw at me when I did something
>> ugly?
>>At least I can find out the problem, when I make one then...

It's just a standard exception, derived from C++'s runtime_error class (in
the std namespace).

I'm sorry if this is a lot coming at you at the same time.  C++ really is
a major change from C and there is a lot to learn before you can start to
write serious programs in it, regardless of your existing C knowledge.  It
really has become a pretty language in some ways, but hellishly
complicated in others and it definitely isn't just "A Better C" anymore.


Jeroen