From: news.x.richarddamon@xoxy.net   
      
   On 4/3/12 2:33 PM, Thomas Mang wrote:   
   > 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).   
   >   
      
   This sounds exactly like the "Struck Hack" issue that was solved in C by   
   allowing the last item of a struct to be an unspecified sized array, is in   
      
   struct foo {   
       int nVals;   
       double vals[];   
   };   
      
   prior to this syntax being adopted, it was commonly "hacked" by using   
   what you wrote of   
      
   struct foo {   
       int nVals;   
       double vals[1];   
   }   
      
   (vals[1] sometimes replaced with vals[0] as an extension on some systems)   
      
   This new syntax has not (as far as I know) been brought into C++, I   
   believe for a few reasons.   
      
   1) in C, this type of object could only really be created on the heap   
   with a statement like to following:   
      
   foo* ptr = malloc(sizeof(foo) + n*sizeof(double));   
      
   this would map in C++ to using new foo, but some syntax would need to be   
   invented to specify the number of elements in the array to allocate.   
      
   2) Since the unspecified sized array MUST be the last subobject in the   
   object, foo can not be derived from, or the derived object may place   
   something in the space the needs to be claimed by the indefinite array.   
      
   3) Because the actual size of the object is unknown to the compiler, a   
   number of member functions normally created by default by the compiler   
   become incorrect/unusable including:   
      
   the constructor (the default constructor will not create/construct the   
   array), and the only place the constructor should be called is in the   
   code that builds the object from the raw memory allocated which includes   
   space for the array.   
      
   the default destructor will not destroy all of the array.   
      
   the default copy/move constructors will not copy the array (and even if   
   the user provided a replacement, you have an issue with what to do if   
   the two objects have different sized arrays)   
      
   operator = won't copy the array, and has the same issue with handling   
   differing sized arrays.   
      
   The "struct hack" "work" for most implementations, but does technically   
   has undefined behavior due to addressing beyond the declared limit of   
   the array, but practically works for any implementation that doesn't go   
   out of its way to verify this (at least for reasonable sized arrays).   
      
   Because of the above issues, I doubt that the C++ committee is apt to   
   adopt the C solution syntax, the C++ method would be to add an   
   collection object (like vector or array) which don't   
   meet your requirements of not using a pointer, but I actually suspect   
   that some of your other languages accessing the object are going to run   
   into similar problems (variable sized complex object [those more   
   complicated than an array]) are not widely supported in 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)