home bbs files messages ]

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