2ed6cadb   
   From: thor@math.tu-berlin.de   
      
   On 08.05.2013 09: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?   
      
   Probably because there is no reason to steer into this?   
      
   > Even if templates or optimizers are not capable of stating this.   
   > The COMPILERS should have something EMBEDDED to state this.   
      
   Sorry, but which use case do you want to solve? If any, then as far as   
   I see, only I/O is affected, and then this is not even an issue if you   
   design your I/O properly. But proper software design is not a matter   
   of a standard or a committee, but rather of the program author.   
      
   > 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.   
      
   This would affect performance dramatically, for little benefit. If you   
   want to serialize structures or classes, then you cannot write them to   
   disk directly anyhow, even with a standard-defined padding and   
   endianness (otherwise, please explain me how to serialize a   
   pointer). So it requires a user-generated solution in first place, and   
   given that the slow part about serialization is the I/O part, why   
   shouldn't I write out the structures in some defined form in first   
   place. Say ASCII?   
      
   > If you don't specify, then the compiler is free to do what it wants.   
      
   s/wants/should do/ And this basically because if you would force the   
   compiler to do otherwise, things would be rather slow. C or C++ are   
   designed that way, namely with performance in mind.   
      
   > 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.   
      
   The way how C is designed this is and should be the matter of the   
   program author.   
      
   > 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.   
      
   Actually, there is little you can do on systems with ANSI-C only. Not   
   even a graphical user interface or such elementary things like getting   
   a key press. C doesn't have all that. It does have the ability to link   
   to system defined functions and to adapt to its environment, and by   
   that become portable. Thus, what you describe is probably more an   
   issue of "upper level" operating system standards (not that Microsoft,   
   for example, would care), and its surely not a matter of C.   
      
   > 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?  :)   
      
   I'm not.   
      
      
   --   
         [ 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)