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