jashugun wrote:
I'm trying to write a small program which is meant to interact with an
sqlite database. My idea is to create once a database handler, which
happens to be an opaque pointer (a pointer to a struct which is not
defined anywhere, if I understood correctly). Now, if I had the
possibility of instantiating a concrete struct, I would create a
function like this:
struct sqlite& myDb()
{
static struct sqlite mydb;
return mydb;
}
And then use myDb() whenever the uniquely created object is needed,
and &myDb() whenever the pointer to my database is needed. My moderate
knowledge of C++ does not help me here. I cannot create a concrete
struct sqlite, everything in the API uses an opaque pointer (and
pointers to this pointer). How can I modify the above code and get a
static opaque pointer? I'm actually wondering if it is at all
possible. If not, what do people do in these situations? Is there any
widely accepted/used idiom?
Well, I generally use an abstract base class for that. You define
a class that has all the interface just like 'mydb' would, and then
declare all members virtual. Then you derive your concrete class from
it and define the behaviour is all the overriders. Something like
// user includes this header:
struct sqlite {
virtual bool do_that();
virtual void do_something_else();
};
sqlite& myDb();
// and you put the rest in a library:
#include <sqlite.h>
struct sqlite_impl : sqlite {
bool do_that() {
// something specific here...
return false; // or whatever
}
void do_something_else() {
// something else
}
};
sqlite& myDb() {
static sqlite_impl actual_thing;
return actual_thing;
}
In this case a pointer (or a reference) is not opaque in terms of what
it can do, but it's opaque in _how_ it does it.
Another possibility (which is essentially the same thing), is to have
all the functions in your library be non-members and accept the pointer
to your 'sqlite', which internally will be used polymorphically, for
example. That's just a functional wrapper around the class, allowing
change the actual class without the user's code changes. However, it
would still require rewriting the wrapper to accommodate class changes.
V
--
Please remove capital As from my address when replying by mail
