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,085 of 33,346    |
|    Thomas Mang to All    |
|    allocate memory 'inside' POD    |
|    03 Apr 12 11:33:40    |
      From: thomasmang.ng@gmail.com              Hi,              Consider the need for a POD-struct which can store a given number of       double values, where this number is determined at run-time (though then       fixed). The struct itself must not use a pointer type. Access to the       double values shall be possible through members of the POD; moreover,       each POD instance and its associated double values shall cover       contiguous memory; if there is an array of these PODs then the whole       array shall also be in contiguous memory (if you wonder why all that       mess: constraints in a highly heterogeneous environment with multiple       languages and hence compatibility issues).              The snippet below does the job practically speaking, but I am afraid       it's not guaranteed to work according to C++98 / C++03 (these my       implementations refer to). I think that in foo the member 'vals' should       be appropriately aligned so it matches alignment requiresments of a       double array indepenent of the number of elements the array has.       However, according to 5.7/5 I would not be allowed to increment a       pointer to the first element of 'vals' more than once if thispointer has       been obtained through someFoo.vals.       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?              thanks!       Thomas                     #include |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca