Boost logo

Boost :

From: Martin Fuchs (martin-fuchs_at_[hidden])
Date: 2002-06-30 14:26:05


Every time I'm writing a new program there are some things, for which I
wish, I'd have a library, which would make live a bit easier. One of this
things is related to datasets.

An example makes it clear:

At the start of an application it reads a list of data base descriptors out
of an configuration file.
This list contains data sets of the form: database name to display, database
server, server port.
The user can select one of this data base entries, and proceed with logon on
to the data base.
In the following mask the user can choose out of an list of customers.
Each customer data set has properties such as: first name, last name,
country, street, and so on...
This is all standard, you could say. Yes - but, what I'm missing is a
standard way to handle all this different things in the source code.
Is it realy the solution to re-engenier the wheel every time or to
copy-and-paste the solution from the last project? I don't think so.

There are already many different aproaches. If you look at the MFC
you will find an easy but powerfull solution, which is integrated
with VC's class wizard. But, not every one wants and even can
use this kind of thing. There are other platforms than WIN32. ;-)

So, what I'm searching for, is a "universal data set class/library/
what ever else". Here is my list of things, it should be able to handle:
- data storage in memory, one by one and also in form of a list/map
- serialization for data storage in external media such as files
  or for transfering over other interfaces (for example over the clip board)
- interfacing to data bases (relational or object oriented ones)
- input/output to/from a graphical user interface in various ways
- initialisation/resetting of data
I think this list is not in any way complete, and you can extent it for
more entries.

Let's go on to the different implementation posibilities:

a.) the struct method

struct DatasetStruct {
    int _dataMember1;
    string _dataMember2;
    ...
};

advantages:
- It's easy to implement and understand.

disadvantages:
- You can't write generic routines because the struct doesn't know of
its data members. For example, you have to define things such as transfer
functions for any data set struct, you want to use:

DatasetStruct::input_output(Archive& archive, bool output)
{
    if (output) {
        archive << dataMember1 << dataMember2;
    } else {
        archive >> dataMember1 >> dataMember2;
    }
}

DatasetStruct::clear()
{
    dataMember1.clear();
    dataMember2.clear();
}

You have to implament all this functions, and you have to update all of
them, if you want to extend your data set definition.

b.) the generic aproach with data member registration

struct DatasetStruct : public DatasetBase {
    int _dataMember1;
    string _dataMember2;
    ...

    DatasetStruct()
    {
        register(dataMember1);
        register(dataMember2);
    }
};

advantages:
- You can write generic routines which handle data transfer and management.

disadvantages:
- You have to register all your data set members in some way and have this
registration up-to-date, if you change your data set definition.

c.) the meta programming aproach aka type lists:
Registration can be handled in an automatic way, if you define your data
set class using type lists.

advantages:
- You don't have to bother with making your registration function
up-to-date, if you change your data set definition.

disadvantages:
- As I had to experience, there are severe problems debugging such kind of
thing. Not only, that the data members are not as easy accessable, as
if they would lie in a C structure. Therere are also problems, which result
from debuggers, which are not able to handle the complex data types.
(One time you merely can't display the data members in the ten'th base
class, another time, the debugger simply crashes.)
- Compile times can increase in a drastic way.

What do you think?

Martin


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk