home bbs files messages ]

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