Another idea I had when talking to someone on Mozilla irc was that endianness should be explicit. You should tell the compiler which endianness you use and that is kept in mind by the compiler. There would be 3 options:

setBigEndian
setLittleEndian
setDefaultEndian    <- uses system's method

Endianness causes a lot of problems in XP code.

Brian Bober wrote:

> Another idea I had when talking to someone on Mozilla irc was that
> endianness should be explicit. You should tell the compiler which endianness
> you use and that is kept in mind by the compiler. There would be 3 options:
> 
> setBigEndian
> setLittleEndian
> setDefaultEndian    <- uses system's method
> 
> Endianness causes a lot of problems in XP code.



And if your endianness request doesn't match the target
environment's endianness, does the compiler generate
code to accomodate, or does it issue an error?

-Russell B

Ignore the other two posts... I'm going to cancel them.

It compenstates and produces assembler code as if people were using the correct endianess.

Also, there should be a getDefaultEndian and getCurrentEndian or something equivalent.

This is almost a necessity for things like XP graphics - such as image
decoders.
In Mozilla, we have macros defined that switch the endianness - which is
obviously slower than the compiler taking it into consideration and
generating
different code.

D should be written in such a way that every caveat of cross-platform and cross-language programming is addressed.

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C5E219E.1070202@estarcion.com...
> Brian Bober wrote:
>
> > Another idea I had when talking to someone on Mozilla irc was that endianness should be explicit. You should tell the compiler which
endianness
> > you use and that is kept in mind by the compiler. There would be 3
options:
> >
> > setBigEndian
> > setLittleEndian
> > setDefaultEndian    <- uses system's method
> >
> > Endianness causes a lot of problems in XP code.
>
>
>
> And if your endianness request doesn't match the target
> environment's endianness, does the compiler generate
> code to accomodate, or does it issue an error?
>
> -Russell B
>
>

Default Endian isn't explicitly required.

Endian conversions have value only for I/O.  And I/O is closely associated with the passing of structures between machines.

As a result endian specifications should be a character of structures rather than simple variables.

I suggest that a special class of IO structure be created which is intended specifically for information sharing.  Operations on such structures could be restricted to simple assignment so that unnecessary endian conversions can be avoided.  The programmer would be forced to complete a compatible structure,  then perform an explicit assignment to the I/O structure before it is output.

This would also provide the opportunity for the compiler to perform other byte alignment operations. as needed.


> Another idea I had when talking to someone on Mozilla irc was that endianness should be explicit. You should tell the compiler which
endianness
> you use and that is kept in mind by the compiler. There would be 3
options:
>
> setBigEndian
> setLittleEndian
> setDefaultEndian    <- uses system's method

I agree with you that its not required, but it wouldn't hurt to put it in.
There might be some
strange reason someone wants it. Saying no one will is kind of like
saying that no one would need more than 1MB of ram 20 years ago.

I do like your idea for the structures. Do you think a special keyword on
structs and integers
would work?

"D" <s_nudds@hotmail.com> wrote in message news:a3ldt4$nel$1@digitaldaemon.com...
> Default Endian isn't explicitly required.
>
> Endian conversions have value only for I/O.  And I/O is closely associated with the passing of structures between machines.
>
> As a result endian specifications should be a character of structures
rather
> than simple variables.
>
> I suggest that a special class of IO structure be created which is
intended
> specifically for information sharing.  Operations on such structures could be restricted to simple assignment so that unnecessary endian conversions can be avoided.  The programmer would be forced to complete a compatible structure,  then perform an explicit assignment to the I/O structure
before
> it is output.
>
> This would also provide the opportunity for the compiler to perform other byte alignment operations. as needed.
>
>
> > Another idea I had when talking to someone on Mozilla irc was that endianness should be explicit. You should tell the compiler which
> endianness
> > you use and that is kept in mind by the compiler. There would be 3
> options:
> >
> > setBigEndian
> > setLittleEndian
> > setDefaultEndian    <- uses system's method
>
>

"D" <s_nudds@hotmail.com> wrote in message news:a3ldt4$nel$1@digitaldaemon.com...
> Default Endian isn't explicitly required.
>
> Endian conversions have value only for I/O.  And I/O is closely associated with the passing of structures between machines.

For file (and general stream) I/O, I'll add conversion functions to my Stream class. It'd work like this:

    File file;
    ...
    file.writeBE(666);    // big-endian
    file.writeLE(666);    // lil-endian

DefaultEndian is the default by definition.  The only way I could see it being used is if the language assigned numeric values to the types for the purpose of run time type checking.  The kind that's used for Varints.

In that case you would have

If DefaultEndian = bigEndian then....

I say restrict the endian types to structures, and not to simple variables at all, or any complex type that permits element by element assignment.

Further, there should be two classes of endienness.  EndianByte and EndianBit.




Brian Bober <netdemonz@yahoo.com> wrote in message news:a3lg5l$qg4$1@digitaldaemon.com...
> I agree with you that its not required, but it wouldn't hurt to put it in.
> There might be some
> strange reason someone wants it. Saying no one will is kind of like
> saying that no one would need more than 1MB of ram 20 years ago.
>
> I do like your idea for the structures. Do you think a special keyword on
> structs and integers
> would work?

"Brian Bober" <netdemonz@yahoo.com> wrote in message news:a3lakj$m5o$1@digitaldaemon.com...
> D should be written in such a way that every caveat of cross-platform and cross-language programming is addressed.

I have a start in \dmd\src\phobos\system.d. Endianness is already there. I'm open to suggestions.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3lk7q$sfb$1@digitaldaemon.com...
> "D" <s_nudds@hotmail.com> wrote in message news:a3ldt4$nel$1@digitaldaemon.com...
> > Default Endian isn't explicitly required.
> >
> > Endian conversions have value only for I/O.  And I/O is closely
associated
> > with the passing of structures between machines.
>
> For file (and general stream) I/O, I'll add conversion functions to my Stream class. It'd work like this:
>
>     File file;
>     ...
>     file.writeBE(666);    // big-endian
>     file.writeLE(666);    // lil-endian

I agree doing it in the streams is the right place.

"Walter" <walter@digitalmars.com> wrote in message news:a4je37$1qhv$1@digitaldaemon.com...

> "Brian Bober" <netdemonz@yahoo.com> wrote in message news:a3lakj$m5o$1@digitaldaemon.com...
> > D should be written in such a way that every caveat of cross-platform
and
> > cross-language programming is addressed.
>
> I have a start in \dmd\src\phobos\system.d. Endianness is already there.
I'm
> open to suggestions.

Define a processor family identificator, so it is possible to write:

    asm
    {
        version (i386)
            ...
        else version (alpha)
            ...
        ...
    }

Would help to write _fast_ cross-platform thingies. Like GNU's bignum, GMP...