In article <3b6edddf$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> How are you going to *reliably* save and restore your data?
> In programs made with different compilers (let alone on different
> platforms)? (Please don't say "I don't want to save my data!"
> You do. And please don't resort to indexing or other tricks).

I knew you would say this despite my _clear_ hint that it is no problem
(TIFF and TrueType are both cross-platform file formats and I have still to
see them not being readable anywhere).


* Let me deal with the cross-platform issue first (because its short to
answer):

As you know byte order is always an issue, so any storage format will have
to be specified in such a way that it is portable.  You simply can't store
the raw data, it won't work most of the time.  There are very different
formats for many other things, not just multicharacter constants.  Non-IEEE
floating-point numbers are just one example.


* Now to the cross-compiler issue:

Storing raw structures?  Again a very bad idea and not because of
multicharacter constants.  For example data alignment in memory.  Different
compilers may decide to use a different alignment of struct elements.  Not
to say that i.e. storing raw structures is a bad idea when it comes to more
complex data that i.e. has pointers in the structs so you end up having to
fix those anyway.

But even if all these were the same because of some common standard on that
particular platform (it is not uncommon to agree on common formats, or
formats set by some dominating force on a platform), then how likely is it
that the platform's compiler struct standard doesn't cover multicharacter
constants?

Further, if you define the file format you will have no other way but to
define it in such a way that the meaning of every byte is clear.  As you
have to do it anyway (i.e. it is even possible to have different byte orders
on the same platform) there is no additional work needed to do it for
multicharacter constants just like for any other type!  So again, here they
require no additional work that wouldn't be necessary for each and every
other data type.

Basically, you are confusing two things here: Cross-platform/compiler design
and unspecified implementation of data formats.  Both are _not_ the same
problem.  They are two very distinct problems:

The C/C++ standards also lets the representation of an integer as
implementation defined. There isn't even anything in there that says
integers have to have the same representation using different compiler on
the same platform.  However, you assume the format is the same for integers
but deny it for multicharacter constants?

Of course, by agreement on one platform the format of integers will probably
be the same, but it doesn't have to be!!!

So, if you observe all used compilers on one platform you will probably find
out that the representation of every built-in type (at least with some
compiler switch) will be the same.  In conclusion, it is reasonable to
assume (as you did with integers) cross-compiler issues that cannot be
worked around without modifying the source code on a particular platform do
not exist (sorry for this complicated sentence).

In summary, there is no cross-compiler-same-platform problem _specific_ to
multicharacter constants.

> there exists the MKFOURCC() macro.

What the macro is actually doing most of the time (not always!) is add
enough garbage to get certain compilers to not complain about the
multicharacter constants.  Apart from this, it can only change the bit
order, which in turn, assuming some common sense and will only be an issue
of byte order.  This in turn will be covered by the regular byte order
conversion you need to do anyway when reading/writing from/to disk

Of course, if someone thinks there is a particular brilliant better format
(after all the format isn't defined at all by the standard) than storing
each character in one byte in either little or big endian you would need to
to more, but there is always something like "common sense" (see above).
However, all this macro does has nothing to do with disk storage in the
first place!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message