I always create and XXX_Initialize() (and also XXX_Finalize() for resources cleanup) in all libraries I created, because:
- You can perform initializations that cannot be done at compile time; - You can create your internal structures in the required order (C++ has the problem of initialization / finalization order of static objects, that could be a pain in some cases), independing on compiler / link order of your object files; Putting a simple call to a sqlite3_initialize() in a program costs near to nothing in my point of view, and could make things simpler for sqlite3 library. On Oct 30, 2007 12:18 PM, <[EMAIL PROTECTED]> wrote: > As currently implemented, SQLite3 requires no initialization. > You just start calling SQLite3 interfaces and they work. We > can pull off this trick on Unix because pthread mutexes can > be initialized statically at compile-time. > > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; > > On win32, we have to initialize mutexes at run-time, but this > can be done within a contrived mutex that we build off of > a static integer using InterlockedIncrement(). And mutex > initialization apparently never fails on win32, so we do not > have to worry with reporting errors that occur during > mutex initialization. > > But there are other operating systems using SQLite that do > not work this way. They need a way to initialize mutexes > (and possibly other objects such as malloc) prior to running > any SQLite interface. And the initialization needs to be able > to fail and return an error code. > > To accomodate this need, we are considering an incompatible > API change to SQLite. We are thinking of requiring that an > application invoke: > > int sqlite3_initialize(...); > > prior to using any other SQLite interface. (The parameters to > sqlite3_initialize() are not yet designed.) It will be an error > to use any other SQLite interface without first invoking > sqlite3_initialize() exactly one. It is also an error to > invoke sqlite3_initialize() more than once. > > Existing applications that use SQLite would have to be modified > to invoke sqlite3_initialize(). Presumably this would happen > very early in main(), before any threads were created. No other > code changes would be required. > > This is still just an idea. If you think that adding a new > required sqlite3_initialize() interface would cause serious > hardship for your use of SQLite, please speak up now. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > > ----------------------------------------------------------------------------- > >
