C++Talk.NET

Andreas Pokorny · Guest

Ich beschäftige mich dieser Tage mit möglichst formatunabhängiger
(De)Serialisierug ( oder Persistenz ) von Objekten. Ziel war ein System
das vom Benutzer verwendet wird um formatfrei Elemente in Klassen zu
deklarieren die dann von dem jeweiligen Serialisierer verwendet werden
um die Daten auszulesen oder in neu erstellte Objekte zu schreiben.
Nachdem das System nun weitesgehnd funktionsfähig zu sein scheint und
der XML-Serialisierer funktioniert, kommen mir Zweifel ob es die Mühe
wert und ob das Konzept nicht gleichzeitig zu einschränkend und zu
komplex ist.

Das System hat folgenden Aufbau:

Jeder Typ der serialisiert werden soll definiert eine zugängliche
Struktur Typ::serialization diese sollte von serializeable<Typ,
ListeMitMetaTypen> abgeleitet sein. Dann müssen noch zwei Funktionen
implementiert werden doch dazu später mehr.
ListeMitMetaTypen sollte ein mpl::vector oder eine mpl::list sein.
Deren Elemente spiegeln die Elemente des zu serialisierenden Typs
wieder. Derzeit stehen dazu die Schablonen s_element, s_data, s_class
und s_container zur Verfügung.

s_element<Element>: charackterisiert eine einzelne Variable vom Typ
Element. Der Typ muss direkt aus dem Strom parsebar sein. ( im Falle von
XML wird dies als Attribut interpretiert )

s_data<Element>: wie s_element - wird aber bei xml in den
<tag>Innenbereich</tag> geschrieben

s_class<Element>: beschreibt eine Variable eines komplexeren Typen der
selbst wieder eine innere serialization-Struktur bereitstellt. ( im
Falle von xml wird hier ein neuer Tag aufgemacht )

s_container<ContainerTyp>: beschreibt eine Sequenz von Objekten mit
gleichem Typ. ContainerTyp wird hier verwendet um über value_type und
andere durch den Standard vorgesehene Typdefinitionen an den
eigentlichen Typ der Objekte zu kommen. Derzeit funktioniert dies nur
mit Typen die selbst wieder eine serialization-Struktur anbieten. An
dieser Einschränkung tüftle ich gerade. Vielleicht wird hier später bei
eingebauten Typen ein Wrapper vorgeschoben der diese Sturktur dann
bereitstellt.

Ein wichtiges Kriterium für dieses System war die Möglichkeit den Aufbau
eines XML-Dokumententyps über C++ Typen nachbauen zu können.

Die Aufgabe der serializable-Schablone ist es die statische Funktion
get_class_info() bereitzustellen die eine initialisierte class_info
Struktur zurückgibt. Darin befindet sich eine verarbeitete Variante der
obigen "ListeMitMetaTypen" und der Name der Klasse. Dazu muss
serializable die einzelnen Typlistenelemente (s_element, s_class .. )
zu meta_element, meta_class usw verarbeiten. Die meta_-Schablonen
bekommen einen weiteren Templateparameter, der für den zu
serialisierenden Typ steht, um get und set Methoden anbieten zu können.
Jede dieser instantierten meta_-Schablonen bietet 2 bis 3 init Methoden
an. Über die init Methode wird der Name der Variable, und der Zugriff
festgelegt. Es ist möglich beispielsweise einen get- und einen
set-Methodenpointer zu übergeben, oder einen Speicheroffset relativ zum
umgebenden Typ (auch hier muss serializable etwas Vorarbeit leisten).
Da dies serializeable aber nicht selbst festlegen kann muessen hier
Funktionen der serialization Struktur aufgerufen werden, die vom
Anwender hoffentlich implementiert wurden. Einerseits get_name um den
Namen der Klassse festzulegen, und init_member_list um die Liste der
instantierten meta_-Schablonen zu initialisieren.

Hierzu ein Beispiel:
<Window title="My Window">
<button name="OkButton" EventId="0">Ok</button>
<button name="CancelButton" EventId="1">Cancel</button>
</Window>
Zugehörige Klassenstruktur:
class Button
{
private:
int id;
std::string name, text;
public:
void setName( const std::string & n);
const std::string & getName() const;

struct serialization : public serializable<Button, mpl::vector<
s_element >
{
static const std::string get_name() const {return "button";}

template <size_t Offset, class MetaInfo>
static void set_member_list( MetaInfo& meta, size_t memory_offset)
{
field_nc<Offset+0>(meta ).init( "id",
memory_offset + MEMBER_OFFSET(Button,id) );
field_nc<Offset + 1>(meta ).init( "name",
&Button::setName,
&Button::getName );

field_nc<Offset + 2>( meta ).init( "text",
memory_offset + MEMBER_OFFSET( Button, text ) );
}
};
};

Auf die Attribute text und id wird direkt über den Speicheroffset
zugegriffen. Dieser wird aus dem durch memory_offset übergebenen Offset
der Klasse relativ zum eigentlich "Objektanfang" und dem Offset der
Variable in der Klasse berechent. ( Die Klasse koennte ja von einer
anderen verebt worden sein und sozusagen Teil eines größeren Objekts sein ).
Für das Attribut name wird stattdessen eine get und eine set Funktion
angeboten. Dies hat den Nachteil dass der serialisierer wohl eine
temporäres Objekt anlegen muss welches dann zum setzen übergeben wird.
Es gibt hierbei noch eine dritte Möglichkeit, wenn man nämlich einen
Set-Methodenpointer vom Typ ElementTyp & (ObjektTyp::*)() übergibt. Dann
kann beim Deserialisieren auch ohne ein temporäres Objekt gearbeitet werden.

Bei Window muss die Kontainer-Schablone verwendet werden:

class Window
{
private:
std::string title;
std::list<Button> buttons;
public:
struct serialization : public serializable<Window, mpl::vector<
s_element >
{
static const std::string get_name() const {return "window";}
template <size_t Offset, class MetaInfo>
static void set_member_list( MetaInfo& meta, size_t memory_offset)
{
field_nc<Offset + 0>(meta).init( "title",
memory_offset + MEMBER_OFFSET( Window, title ) );

field_nc<Offset + 1>(meta).init( "button",
memory_offset + MEMBER_OFFSET( Window, buttons),
&std::list<Button>::push_back,
&std::list<Button>::begin,
&std::list<Button>::end );
}
};
};

Mir sind bisher folgende Nachteile aufgefallen:
- Zyklische Sturkturen wurden in diesem Konzept noch gar nicht
behandelt... könnten und werden wohl aber noch eingebaut werden.
- Die Struktur der Serialisierung zwingt den Programmierer einen
bestimmten Klassenaufbau einzuhalten.
- Da in den meta_-Schablonen get, set und get_ref Methodenpointer
abgelegt werden, muss sich der Anwender an exakt diese Protoypen halten.
Man kann nicht von implizieter Konvertierung des Parameters oder des
Rückgabewerts profitieren.

Der bisherige Aufbau ist also eher komplex und teilweise unhandlich.

Ich richte mich mit dem Konzept an die Newsgroup, da ich Wege suche es
noch weiter zu verbessern. Den Quellcode der serialize Schablone und des
Xml-(De)Serialisierers könnte ich hier vöffentlichen, falls Interesse
besteht.

Grüsse
Andreas Pokorny

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Jan Langer · Guest

Andreas Pokorny wrote:

Marco Budde · Guest

Andreas Pokorny wrote:

Andreas Pokorny · Guest

Jan Langer wrote:

Robert Frunzke · Guest

Torsten Robitzki · Guest

Robert Frunzke wrote:

King Leo - Martin Oberzal · Guest

Torsten Robitzki wrote:

Robert Frunzke · Guest

Das Beispiel hatte ich mal schnell zusammengeschrieben, das
Gesamt-Konzept hat Factories und es gibt keine Basisklasse Serializable
(war ne dumme Idee das dazuzudichten *g*) usw.

Torsten Robitzki · Guest

King Leo - Martin Oberzalek wrote:

Markus Schaaf · Guest

"King Leo - Martin Oberzalek" <kingleo (AT) gmx (DOT) at> schrieb:

Torsten Robitzki · Guest

Robert Frunzke wrote: