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 32,096 of 33,346    |
|    Thomas Mang to All    |
|    Re: allocate memory 'inside' POD    |
|    05 Apr 12 11:11:06    |
      From: thomasmang.ng@gmail.com              Am 04.04.2012 20:46, schrieb Ulrich Eckhardt:              >> I could treat the bytes at vals and beyond as an array of doubles, but       >> according to 3.8/2 it seems that a single memory region can only be of       >> one type at a time; if it's the vals member of a foo object than I can       >> access it but can't increment the pointer to reach all elements; if it's       >> interpreted as an array of doubles then technically there would be no       >> foo object any more and I would not be allowed to access it through the       >> foo interface.       >>       >> Any possibility to making it fully C++ compliant while sticking to above       >> constraints?       >       > Looking at your code, I'd say it will work in pretty much any       > environment you are likely to encounter. For me, that would be enough in       > most cases.              To some degree I had been surprised that it did work without problems.              The compiler has a really easy job finding out that vals is an array of size       1. Hence it should easily figure out that getting a pointer to (vals + 1) is       as valid as dereferencing *(vals + 0), but anything beyond that would not be       valid any more. I would        not have wondered if implementations had triggered on pointer operations       beyond these.                            --        [ 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