From: news.x.richarddamon@xoxy.net   
      
   On 4/8/12 2:21 PM, Thomas Mang wrote:   
   > 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?   
   >   
   >   
      
   There may (and I would say probably is, but I am not aware of it) an   
   implementation that in some strong DEBUG mode, would trap on the access,   
   as it strongly checks all array accesses. This is expensive enough that   
   I seriously doubt that there exists any compiler that would do this in   
   release mode.  Unless someone comes up with a hardware platform which   
   forces all "pointers" to include bounds, making the check "free" (since   
   you can't avoid paying the cost), I would expect this to continue to be   
   true.   
      
   There comes a point in many projects where you hit a wall that you can   
   not crack if you limit yourself to code that is strictly conforming to   
   the standards. This is such a point. C++ objects (except for native   
   anonymous arrays accessed via a pointer) have fixed sizes, period. Your   
   specifications call for an object to have a run time variable size, this   
   is not compatible with C++. C came to a similar problem, and adopted a   
   couple of solutions for differing circumstances, run time sized arrays   
   of automatic scope and unspecified sized arrays at end of objects, to   
   handle some of these (the first wouldn't help in your circumstance).   
      
   You need to come to grips with this and accept one of the possible   
   solutions:   
      
   1) Change you code that accesses these objects to C (C99 or later),   
   which does have the syntax are rules for this.   
      
   2) Accept that your code is not going to be strictly conforming to the   
   C++ language rules and either live with the "undefined behavior" that   
   will do what you want to do for all but highly checking debug   
   implementations.   
      
   3) Use a C++ compiler that has adopted as an extension, the C99 syntax   
   and definitions for the code, and thus your code will generate errors if   
   compiled as a strictly conforming code   
      
   4) You can change the definition of the structure layout. I will add   
   that I doubt that this data format is processable by many languages.   
   Variable size non-homogeneous data structures are an oddity.  It might   
   be the internal format for some languages variable sized array, or it   
   might be something someone designed and they are doing the equivalent of   
   the "struct hack" in all of the languages.   
      
      
   --   
         [ 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)