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

> (if you would like to answer, please: provide code snippets
> or something; not just general thoughts)

Code for what?  Portable reading/writing of multicharacter constants?  As I
have now pointed out, reading and writing to disk of any binary
representation of any basic type is implementation dependent!

> I asked you about aportable way of storing/loading of a
> *single* number. You failed? You started to talk about non-IEEE
> fp numbers...

And where is the difference?  There is *no* portable way to write any binary
representation of basic types.  I tried to explain it, but it seems I did
not succeed :-(

If you have found a solution how write fully portable code (obviously
without conditional compilation) that can write binary representations i.e.
of the basic type "int" I would really like to see it!

Well, from your statement
    "There is a known way of doing this for integer values: write
    byte-by-byte, then restore byte-by-byte (doing proper shifts
    and additions); POV-Ray does exactly that when, say,
    loads tga files."
and the previous discussion I concluded that you were talking about binary
files, not text files.  Obviously I am talking about binary files (what else
are TIFF or TrueType files?)

Further, what do text files have to do with your problem with multicharacter
constants?

>  Thorsten, I state that non-IEEE numbers
> represent a lesser problem then multicharacter constants.

And can you prove it?

> With your multicharacter constants, what are you going to do?

As far as I know, the C library specification is missing functions that
output multicharacter constants.  Of course, for a C library (as it is
usually specific to a compiler to some extend), it would have been no
problem to specify such an output format in the standard.  Don't blame me
for this not being in there...

> Your assumption about integers' representation not been
> standartized is, again, wrong. According to ISO, there is a single
> possible representation for unsigned integers, plus several
> possible representations for signed numbers. If I were

Where?  In my copy of ISO/IEC 14882:1998(E) (ISO C++ Standard) I cannot find
any such specification.  To the contrary, section 3.9.1 _only_ specifies
that "Plain ints have the natural size suggested by the architecture of the
execution environment; the other signed integer types are provided to meet
special needs".  For unsigned numbers it only requires that they have the
same size, alignment requirements and "obey the laws of arithmetic modulo
2n".  The whole section, nor the whole standard contains a normative
reference to any other ISO standard that defines any of the basic types'
formats.

In particular, "even if the implementation defines two or more basic types
to have the same value representation they are nevertheless different types"
is important if you understand the term "implementation" (3.9.1.10) - in
short it refers to the compiler and thus it is up to the compiler, not the
architecture (of the platform) to specify the size of basic types!

> The keywords here are 'byte order conversion'. Even just the term
> 'order'. This statement implies knowledge of that 'order'. And you
> always have that, on each platform -- for short, int, long, float, double,
> whatever -- but not for multicharacter constants. Endianness is
> one thing, storing characters within long is another thing. You *first*
> pack characters into 'long' (this is governed by some INTERNAL
> compiler rules, UNAVAILABLE to mere mortals), and *then* put
> that 'long' into memory (this is governed by 'endianness').

Well, do you _know_ the byte order of an integer?  How so, it is also
"governed by some INTERNAL compiler rules" according to the ISO C/C++
standards (as I pointed out above)!!!

All you can know is the maximum value you can store in an integer, but you
know next to nothing about its internal representation.  In fact, the byte
order of integers, or to be more general the representation of all basic
types is completely transparent and there is no standard method to determine
it in a program in a portable way!

Indeed, this is the root of all cross-platform problems:  The C/C++
standards don't specify internal representations in order to allow you they
most flexibility when doing low level programming with a specific
compiler/platform combination.  For the standard there is no "world" outside
a single implementation of the standard.

Thus, all assumptions you make are based on your observations or good
compiler documentation, but not because they are specified that way in the
C/C++ standards!  Essentially you have proven that the information you claim
to be "UNAVAILABLE to mere mortals" is available to you because if you know
unspecified implementation dependent details like "short, int, long, float,
double".  So, using the same method you used to obtain this information can
be used to obtain the implementation dependent format of every basic type's
data, and surely the implementation dependent details of multicharacter
constants - you forgot that multicharacter constants, by specification, are
integers.  As the number of integers is finite you can obtain the
representation of every multicharacter constant in every implementation
without exception.

However, you will never need to do so because all (existing) implementations
of ISO C++ use one byte ASCII characters and store the value of each byte of
each character of a multicharacter constant either starting with the highest
or lowest byte and then following the obvious order.  Of course, this is not
part of the standard, but if you assume it and test you won't have to use
the method I outlined above in order to determine the value of every
multicharacter constant without this assumption.

> That's just plainly non-portable. To be able to convert, you have to
> know *WHAT* on Earth do you have.

Contrary to your claim above I have shown that it is possible to determine
the integer representation of every possible multicharacter constant.  Thus,
multicharacter constants are portable because the all implementation details
can be determined and proper action can be taken when reading/writing
multicharacter constants.

In summary, I get the impression you assume good C/C++ code will always be
portable *without* any implementation specific changes.  This is plain
wrong.  The very nature of C/C++, by targeting a range of applications from
GUIs to kernels and drivers, and the language specification itself
explicitly trade portability for low-level programming options in many
places.


    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