D - An idea: endianness attribute
- Samuel Barber (6/6) Jul 24 2003 A feature that I've never seen in a compiler, but which I think would be
- Matthew Wilson (4/10) Jul 24 2003 This would be very nice, although of course to be used sparingly (as I'm
- Riccardo De Agostini (15/17) Jul 30 2003 Let me think... it would make network byte order transparent to the sock...
- Russ Lewis (4/28) Jul 30 2003 I agree that endianness attributes are a good feature. However, they
- Riccardo De Agostini (18/21) Jul 30 2003 As for structure alignment, we have the align keyword and I just can't
- Mark Evans (9/12) Jul 31 2003 Both of you are right. They are handy but still rarely used. What I th...
- Mark T (7/11) Aug 01 2003 I use them fairly often (if the compiler is good) when doing embedded
- Mark Evans (7/9) Aug 01 2003 Any language that aspires to be a 'systems language' should support embe...
A feature that I've never seen in a compiler, but which I think would be useful, is a means to specify the endianness of data. This would mainly be useful for public data structures (like the alignment attribute). So if I'm on an x86, and accessing bigendian words, the compiler will generate nice BSWAP instructions... Sam
Jul 24 2003
This would be very nice, although of course to be used sparingly (as I'm sure you intend). "Samuel Barber" <opendtv yahoo.com> wrote in message news:bfp2vr$156v$1 digitaldaemon.com...A feature that I've never seen in a compiler, but which I think would be useful, is a means to specify the endianness of data. This would mainly be useful for public data structures (like the alignment attribute). So if I'm on an x86, and accessing bigendian words, the compiler will generate nice BSWAP instructions... Sam
Jul 24 2003
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bfq0h4$21c6$1 digitaldaemon.com...This would be very nice, although of course to be used sparingly (as I'm sure you intend).Let me think... it would make network byte order transparent to the sockets developer, let me strip the ugliest lines of code out of my ModBus drivers... talk about "sparingly"! :-) OTOH, it is a feature that, if abused, would lead to bigger and less efficient code... but that can be said of just about anything, from floating point to marijuana. Walter, will you give us bigendian and littleendian attributes? Pretty please? :-) (Just to be clear: D *rocks* as it is now. Endianness attributes, though, are too attractive to not dream of them, at least...) Ric P.S.: No, I don't know of any current compiler with marijuana support, though I have seen programs seemingly written by someone on a bad trip :)
Jul 30 2003
I agree that endianness attributes are a good feature. However, they must be paired with a very well defined way to lay out structs, including bitfields. Riccardo De Agostini wrote:"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bfq0h4$21c6$1 digitaldaemon.com...This would be very nice, although of course to be used sparingly (as I'm sure you intend).Let me think... it would make network byte order transparent to the sockets developer, let me strip the ugliest lines of code out of my ModBus drivers... talk about "sparingly"! :-) OTOH, it is a feature that, if abused, would lead to bigger and less efficient code... but that can be said of just about anything, from floating point to marijuana. Walter, will you give us bigendian and littleendian attributes? Pretty please? :-) (Just to be clear: D *rocks* as it is now. Endianness attributes, though, are too attractive to not dream of them, at least...) Ric P.S.: No, I don't know of any current compiler with marijuana support, though I have seen programs seemingly written by someone on a bad trip :)
Jul 30 2003
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> ha scritto nel messaggio news:bg8l6g$1e3o$2 digitaldaemon.com...I agree that endianness attributes are a good feature. However, they must be paired with a very well defined way to lay out structs, including bitfields.As for structure alignment, we have the align keyword and I just can't figure out a situation where it would not be enough. Could you make an example? Bitfields are another story. Walter decided to cut them out of the language specifications because they are "rarely used". I don't agree with that statement: there are lots of places where bitfields come handy. Think of COM's HRESULT type, for instance. Or memory-mapped I/O, should the compiler be ported to CPUs other than Intel's. Or any situation where you have to communicate with external hardware, implement communication protocols... IP packets contain bitfields (talk about rarely used :-) ) and, even if I agree that one usually relies on libsocket or Winsock, what if I wanted to make a D version of WatTCP and contribute it to D's standard library, at least for the 32-bit DOS environment? It surely would look better (and be more easily read and maintained) if I could declare bitfields instead of using masks and shifts. I sincerely hope that Walter have a second thought about them. Ric
Jul 30 2003
Bitfields are another story. Walter decided to cut them out of the language specifications because they are "rarely used". I don't agree with that statement: there are lots of places where bitfields come handy.Both of you are right. They are handy but still rarely used. What I think happened with C is that no one got used to bitfields because (a) few know about them and (b) those who did never trusted their compiler to manage them correctly. The raw binary and hex strings being discussed in another thread might cover some of the territory but not all of it. You would also need language primitives to mask and extract, or mask and insert, arbitrary bits N through M. It would be nice to have the language support, yes. Mark
Jul 31 2003
Both of you are right. They are handy but still rarely used. What I think happened with C is that no one got used to bitfields because (a) few know about them and (b) those who did never trusted their compiler to manage them correctly.I use them fairly often (if the compiler is good) when doing embedded programming to map hardware register bits. Of course, I would like a endian attribute to go with them where I now use a preprocessor #ifdef. The way Ada defines bit fields is far cleaner than C IMHO. This is where Walter's bit type would be handy instead of using it as a boolean. I think that embedded programming is a good candidate for D (if they don't over-feature the base language).
Aug 01 2003
Mark Evans <Mark_member pathlink.com> I think that embedded programming is a good candidate for D (if they don't over-feature the base language).Any language that aspires to be a 'systems language' should support embedded programming by definition. I hope that is going to be the case with D. It will take actual testing on new target chips, not just assertions about language portability. Opining that a language should not be over-featured while asking for a new feature is nice diplomacy. I'll remember to do that. ;-) Mark
Aug 01 2003