Re: how to store list of varying types
"Tom Serface" <email@example.com> ha scritto nel messaggio
I'd have to do some testing to agree with the idea that it is that much
more efficient. Perhaps if OP is writing a ton of data, but I've written
out files with over 100K significantly appointed XML records in about 5
I agree with you about the need for testing.
Of course, if the OP is writing small data, both XML and binary formats are
But, e.g. if I had to write lots of real numbers (double's) for example to
describe some complex 3D geometry, I would prefer a binary format: I think
that would be much faster, and occupy less space on disk; in fact, each
double is 8 bytes if stored in binary, else imagine something like this (for
complex geometries with lots of vertices) in XML:
<!-- just for one vertex (3 doubles) -->
So, the overhead of XML over binary sequence of doubles is important in that
Another example is XAML: if my understanding is correct, XAML is converted
to a *binary* format before WPF processes it for rendering the GUI. And that
is because handling binary data is much faster (and has less memory
footprint) than XML.
However, again, it all depends on the amount of data. Like lots of people
wrote here (I recall especially Joe), trying to blindly optimize the code
means "having no contact of reality" [(c) by Joe] :)
i.e. it is important to first make things work, then after that we should
identify those particular parts that need an optimiziation (like a loop
executed millions of times, or some particular algorithm, etc.), and focus
our time and energy only on these parts.
You are right that a parser to read the file is more trouble (unless you
consider the format to be very rigid), but writing XML is trivial and can
be done with CStdioFile WriteStrings() with a little CString formatting.
But there are subtle aspects in writing, for example you must escape some
characters like < or > or &, etc.
And XML tends to be UTF-8, so it is important to pay attention to conversion
from UTF-16 to UTF-8.
Nothing particularly complex, of course.