Everything is data. Occasionally, when programming day-to-day objects and functions, you get a reminder that everything from the keys you press to the code it makes to the bits it reads is data.

But enough, say you want to use C++ with SQLite in a sane, object-oriented way. More specifically, you want to use sqlite3_exec to execute a SQL query. Here’s an example:

int rc = sqlite3_exec(db, sql, callback, data, &errMsg);

What is each one of these parameters? The first, db, is your opened database, sql is a const char * query you want to run, callback is a static function pointer, data is a peice of data you want to send to callback, and errMsg is what it sounds like. Okay, all’s well, lets define that callback.

static int callback(void *param, int argc, char **argv, char **azColName)
{
    return 0;
}

Damnit. This is going to be called once for every row, I don’t know when it’s going to end, and it’s static, throwing any hope for object-orientation out the window.

Or does it? Switch gears for a moment: What’s one of the hallmarks of object-oriented programming? I’m talking about the keyword this or self. What this is is difficult to describe to others because you’ll often find yourself saying something like, “this is this, like you know, this is this”. But this can be thought of as a hidden parameter passed along with every message sent to an object which can access the object that the message was sent to.

Well if this is what we’re after, this is a hidden parameter, and we’ve got a void * we can put whatever we want in, how about we just reconstruct our instance of an object using C++ casting?

First, make your request:

char* customer::getPerson(int id)
{
    ...
    rc = sqlite3_exec(db, sql, callback, this, &errMsg);
    ...
}

Then, define your C callback with C++ casting to turn person into this:

static int callback(void *param, int argc, char **argv, char **azColName)
{
    Person * person = reinterpret_cast<Person *>(param);
    return person->cppCallback(argc, argv, azColName);
}

Finally, profit:

int Person::cppCallback(int argc, char **argv, char **azColName)
{
    ...
}

Thanks to this StackOverflow post for the insight.

The desire for code re-use is a strong one among considerations of how to design a program or application. This competes with the desire to implement applications in their native, and oftentimes proprietary, framework.

Arguably the most important part of a mobile application to be developed natively is the view code. Non-native views on any sufficiently complex data-centered app are almost always immediately identified by users: web views and non-standard behavior almost always give it away. Furthermore, perhaps the least important part of an application to be native is the model. The storing, manipulation, and retrieval of data is oftentimes very similar across languages and frameworks: a linked-list is a linked-list no matter what language it’s in.

Perhaps we can use this dichotomy to best satisfy the competing desires of code re-use and native implementations: keep your views and controllers in native code, but implement your data model in shared code. Specifically, I’m wondering if I can move an application’s model to C++ on iOS, Android, and Windows Phone and only implement views and minimal controllers in native code.

In fact, ideally, all data-related tasks would be handy to have in shared code: anything involving databases, making requests to servers, and parsing responses are the taks which come to my mind. I think that in order to achieve this, I’m going to need to compile a framework for manipulating a database, a framework for making network connections, and a way to have native code request and receive data.

I think a design like this at least works, but it could even be desirable. Maybe the best way for me to find out would be to try it.