> That would compel me to change *all* of the API to use a
> "sqlite4_" prefix instead of "sqlite3_".
I'm guessing that eventually backwards compatibility will be broken
in such a way that there will be an sqlite4 (and perhaps an sqlite5
down the line). When that happens you might consider using macro
slight-of-hand for major version number symbol prefixing:
#define SQLITE(b) SQLITE1(sqlite4_,b)
#define SQLITE1(a,b) a##b
This way redefining the macro SQLITE() need only change in one spot.
For example:
SQLITE(open) would expand to sqlite4_open
SQLITE(exec) would expand to sqlite4_exec
It's ugly, but at least the number of characters in the identifiers
remain the same. An external header file would still have to be created
with the new name "sqlite4.h" (or whatever) so the users would pick up the
correct sqlite header, but all the internal sqlite source code using the
new macro scheme need not change in any subsequent major version upgrade.
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
