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,105 of 33,346    |
|    Thomas Mang to All    |
|    Re: allocate memory 'inside' POD    |
|    08 Apr 12 11:21:20    |
      From: thomasmang.ng@gmail.com              Am 07.04.2012 23:29, schrieb Francis Glassborow:              >> But I read 3.8/2 in a manner that once placement new[] has been       >> used to create the array of doubles (starting at the address given       >> by first), my array instance itself would have ceased to exist (as       >> the memory is reused for something else) and I would - officially -       >> not be allowed to access its members any more.       >       > I think you are tying yourself in unnecessary knots. You will have       > to be careful about how you handle the dtor for the object but that       > is it. I cannot see how even a perverse implementation could result       > in errors if you treat first as an array.              Let me ask from a different perspective:       My original code, your sketch and those of others here in this thread       - for which I am really thankful because they show inspiring nice       details - make access to the actually array through first. Assume the       definition of first is treated as array of size one (so no matter if       it had declared as such, or as a scalar). Is there really no seriously       used implementation out which then, in strong debug mode, internally       not uses raw pointers but instead some sort of checked pointers /       iterators (like to a std::vector) to that array and which detect and       trigger on out-of-bounds moves by these pointers? Personally I would       not judge such an implementation to be perverse, but actually really       helpful generally (though not in this particular case) as it would be       able to detect not completely uncommon bugs, let alone serious       security holes. Hence my personal judgement would have been to better       treat 5.7/5 literally and stay away from anything which does violate       it. Is it really the case that all present and probable upcoming       versions (I know noone can predict the future precisely ...) of major       implementations (say those supporting boost) would let the pointer       arithemtic used in these examples here always go through?                     --        [ 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