Re: How to to convert object to XML string and back again
jaibuduvin@gmail.com (Le Chaud Lapin) wrote (abridged):
You're right that looking at the dataset above versus XML is easier
on your eyes.
I usually find XML easier to follow because it usually has more names in
it.
So with every change of the Airbus_A380 , the programmer must touch
the serialization code, and this is what bothers the
XML-to-object-to-XML people so much.
I guess by "XML-to-object-to-XML people" you mean the ones who want to
generate the XML automatically. If so, that is a rather misleading way to
refer to them. You can attempt to generate data automatically without
using XML, and you can also use XML without automated generation.
They want to eliminate this touching and many try in vain to find a
breakthrough to do this, perplexed that it is trivial in Java, but
seemingly impossible in C++, not realizing that Java and C++ are not
really comparable as programming languages, in the sense that one
cannot call Java a generic programming language any more than one
could call 8080 assembly a generic programming language, because
both presume a specific execution environment. Java presumes
the JVM, 8080 assembly presumes the 8080 CPU, and C++ presumes
pretty much any computer that has a Von-Neumann architecture
and sufficient RAM, and even a few other architectures.
Java can be compiled directly to machine code - it doesn't need a JVM.
Certainly automatically generating XML does not require a full JVM-like
runtime. It just needs the compiler to include a description of the
program's types in the executable. Doing so wouldn't make a language less
general purpose.
Use Method 2, explicitly writing out the labels of the structures in
Boost-like serialization code, using a target arhive that knows
that a long double should be writtten out with the string 'long
double', for example.
I found I generally didn't want too much type information in the file.
It's more important to know the names of the fields. You need types if
the objects are polymorphic, of course, but for something like:
Engine E1, E2, E3, E4;
the program already knows the types and just needs the names "E1" etc.
Having names enables the program to cope with data which is missing,
present unexpectedly, or in a different order. Having types just enables
type-checking of the data. For me that's not much benefit, and is
sometimes a positive hinderance as I may want to change the type between
versions.
Define a data structure in C++ which is an associative tree of
strings, each node of the street a map from string-to-string or
string-to-list-of-string. The C++ code surrounding the object in
RAM will do lookups of string values, then interpret them at run-time.
The object containing the state can be trivial serialized to and
from disk, with hiearchical formatting and even comments, but
rigitity of form inside the program will quickly disintegrate
with this method. The code will be very messy, as the "raw"
internal C++ code will be doing run-time intepretation of
strings, and it will be easy to add an unknown string ....
(then what?)...
I'm not sure what you have in mind here. My approach led to code like:
enum Colour { Black, Red, Green, Blue, White };
....
Colour faciaColour;
LoadEnum( pXml, L"facia", faciaColour, White );
which seems tidy enough. There is code that does run-time interpretation
of string values, but it's in a library somewhere and doesn't add to the
mess in client code. Unexpected strings get ignored, and missing strings
get their default values (White in this case).
It becomes less clean as the data evolves, leading to things like:
ColourObject *pFaciaColour;
if (!LoadObject( pXml, L"facia2", pFaciaColour, White )) {
Colour faciaColour;
LoadEnum( pXml, L"facia", faciaColour, White );
pFaciaColour = new EnumColour( faciaColour );
}
where the original enum type has been replaced by a heirarchy of classes
that provide different colour models - RGB, CMYK etc. The serialisation
code first looks for the new format, and if it can't find it then looks
for the old format and converts it.
Do you think this is too rigid and will "quickly disintegrate"?
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]