In case you don’t know, I’m collecting patches that improve Boost’s support for Code Gear (formerly Borland) compilers and making them available through the bcbboost project.
The current version of bcbboost, 1.34.0-5.9.0-0.1, supports the recently released Boost 1.34.0 and Code Gear’s compilers up to bcc32 5.9.0, corresponding to C++Builder 2007.
Over the years I wrote a few reviews for programming related books, which are available from the ACCU’s book review collection. I plan to write more reviews and to make the new ones also available through ACCU, if they accept them. Meanwhile I hope you will find the following useful:
With a not very original approach SqlCli’s entry point is the sql_cli::connection class, which is meant to be used as follows:
// Create a connection to a specific backend:
// ODBC, Oracle, PostgreSQL, etc.
sql_cli::connection conn("ODBC");
// Connect to a specific database
conn.connect(...);
My problem is what to put in the ellipsis’s place. At one extreme I could try to be completely independent from the underlying technology, by assuming that all DBMS’s support the use of database, user and password as connection parameters and only provide access through those:
conn.connect("Customer", "nmusatti", "password1");
This is a convenient approach, especially for those that aren’t too familiar with relational database implementations or need to write code that’s independent from the underlying technology, but it’s not very general.
The opposite approach would request a connection string as single parameter, to be passed unchanged to the lower level API routines:
conn.connect("SERVER=Customer;UID=nmusatti;PWD=password1;");
This is as general as it gets, but requires that users know some rather specific details of the DBMS they’re connecting to.
One intermediate alternative is a combination of the two; the database, username and password parameters are still used, but some optional mechanism is also provided to allow the specification of additional parameters. This is certainly as general as the second option above, but I’m not convinced that it provides any gain in terms of clarity and simplicity. Moreover, such an additional mechanism is likely to involve some ad hoc argument specification syntax, which would further complicate things.
What is your point of view?
Chi volesse discutere dell’argomento in italiano trova lo stesso quesito sul newsgroup it.comp.lang.c++.
