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,020 of 33,346   
   AdrianH to All   
   compilers, endianness and padding   
   08 May 13 00:32:41   
   
   2ed6cadb   
   From: adrianh.bsc@googlemail.com   
      
   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?   
      
   Even if templates or optimizers are not capable of stating this.  The   
   COMPILERS should have something EMBEDDED to state this.  It is, after   
   all, generating the code.  And there are constants that are lying   
   about in memory too that it has to create.  So logically, it knows   
   what endianness of the target binary is going to be, even if it   
   doesn't know what it is outside the data segment that the constants   
   are stored in.  I only know a little about multi-endian architectures,   
   but IIRC, they have a way to automagicaly transfer data from different   
   endian segments correctly.   
      
   Still, with cloud computing and other interoperable computing models,   
   COMPILERS need to take responsibility to make it possible for   
   programmers to make sane code without such clumsy methods as an   
   endian.h header file.  Padding is another issue that the committee has   
   stayed clear of.  This is just so infuriating in this day and age.   
      
   Actually, a FAR BETTER alternative would be to be able to force a type   
   to be of a specific endianness and have padding of a struct be able to   
   be forced as well.  If you don't specify, then the compiler is free to   
   do what it wants.  This way, the compiler can do whatever   
   optimizations it needs to make it work as optimally as possible in   
   either case, removing the endianness and padding issues from the non-   
   standard compiler world, to a more cooperative interoperable world.   
   Those who don't need it, don't have to worry about it.  Those who do,   
   don't have to go writing code that could potentially barf on some   
   systems.   
      
   I think we should storm the C++ committee's castle and tell them that   
   this insanity has gone on long enough. Who's with me?  :)   
      
   Comments are definitely welcome.   
      
      
   A   
      
      
   --   
         [ 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