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,069 of 33,346    |
|    Edward Rosten to James K. Lowden    |
|    Re: compilers, endianness and padding    |
|    21 May 13 04:39:41    |
      From: firstname.dot.lastname@googlemail.com              On Tue, 21 May 2013 01:21:28 -0700, James K. Lowden wrote:              > Well, it wouldn't really hobble the optimizer, would it?              That depends on how much you want the result to be standardised.              > The report might be misleading in some circumstances, nothing we       > don't deal with already. There's still a call stack, even if some       > functions are inlined.              Going on personal experience, I've had some surprisingly large       programs report an error in `main' when they segfaulted. Naturally,       almost all of the work was done in ancillary functions, so the result       of that was an almost useless report.              I'm not saying it's a common case, but it can happen.              For the change not to interfere with the optimizer, this would have to       be quite close to an optional feature in that there may be anything       from almost no information up to complete information (the type you       get when compiled with full debugging and no optimizations). Of course       on some platforms it would have to be disabled entirely.              I'm not claiming that this is not a useful feature (far from it), just       that it would be tricky to standardise.              -Ed                     --        [ 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