Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 33,021 of 33,346    |
|    Andy Champ to AdrianH    |
|    Re: compilers, endianness and padding    |
|    08 May 13 05:22:26    |
      2ed6cadb       From: no.way@nospam.invalid              On 08/05/2013 08:32, AdrianH wrote:       > I've been looking around and am just shocked that there still after       > so many years, there doesn't seem to be any way of using the       > optimizer or templating system in any consistent way across       > compilers to generate a compile time endianness value. Does anyone       > know why the C++ committee has steered clear of this?              If you force a compiler to store data in the normal (human style)       format, or the byteswapped (Intel style format) then the processors       which access the data and have native formats that differ from your       stored format will have to perform a byte swapping operation on every       memory access to that structure. This is likely to cause an       unacceptable performance degradation. I have never worked on one, but       I understand there are processors that store a 32-bit quantity in a       3412 byte order, not the common 1234 or 4321!              For padding, different processors have different padding requirements,       and it is difficult to predict future requirements. Should the       compilers force padding of everything to 8K page boundaries, just to       be certain that the padding is accurate for all future processors?              Remember that the format of the numbers themselves may vary. I've       worked on systems where a native integer is 16, 24, 32 and 36 bits       long. To force the 36-bit one down to 32 bits would require an       operation on every memory store - probably every operation, for true       compatibility - and to force some of the 16-bit ones, which have no       hardware multiply or divide, to perform every operation in 32 bits       would be far too slow.              IMHO the best place to perform these conversions is during I/O. I'm       going to stand on the battlements and defend the castle alongside       those who produce the specification.              Andy       --       (this time anyway... I still think iterators into set should not be const!)                      [ See http://www.gotw.ca/resources/clcm.htm for info about ]        [ comp.lang.c++.moderated. First time posters: Do this! ]              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca