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,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