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,244 of 33,346   
   Alf P. Steinbach to Gene Bushuyev   
   Re: Most-derived objects objects shall h   
   05 May 12 06:05:41   
   
   ec995c3a   
   From: alf.p.steinbach+usenet@gmail.com   
      
   On 05.05.2012 08:39, Gene Bushuyev wrote:   
   > On May 3, 2:25 pm, Johannes Schaub   
   > wrote:   
   >> The C++11 spec says at 1.8p5   
   >>   
   >> "Unless it is a bit-field (9.6), a most derived object shall have a   
   >> non-zero size and shall occupy one or more bytes of storage. Base   
   >> class subobjects may have zero size."   
   >>   
   >> The following is supposed to be valid   
   >>   
   >>      int *x = new int[0];   
   >>   
   >> The object created by "new int[0]" has zero size (int[0] == 0 *   
   >> sizeof(int)), but that contradicts the above quote.   
   >>   
   >> How is this to be interpreted?   
   >   
   > In my view the word "array" is overloaded in the standard, the rules   
   > are different for statically and dynamically allocated arrays though   
   > both are just called arrays. One meaning of the "array" is an object   
   > defined in the form of "T array[n1][n2]...", to which the   
   > non-negative compile-time const requirements are applied as well as   
   > sizeof(array) is defined as n*sizeof(T) in 5.3.3/2. A different   
   > meaning of the "array" is an object which is the result of an array   
   > form of new expression calling "operator new[]", which isn't   
   > actually the type of an array, for creation of which the   
   > non-negative integral expression is required and "sizeof(*new T[n])"   
      
   That does not apply sizeof to an array type object.   
      
      
   > is always positive as described in 5.3.4/7.   
      
   No, it describes no such thing.   
      
   It would be remarkable it the standard confused pointers and arrays   
   (it's a novice level misconception).   
      
      
   > The trait is_array also treats them differently:   
   >   
   > #include   
   > #include   
   >   
   > int main()   
   > {   
   >      int a[10];   
   >      int* b = new int[10];   
   >   
   >      std::cout<<  "a is an array: "<<  std::boolalpha<<   
   > std::is_array::value;   
   >      std::cout<<  "\n*b is an array: "<<  std::boolalpha<<   
   > std::is_array::value;   
   > }   
   >   
   > The output:   
   >   
   > a is an array: true   
   > *b is an array: false   
      
   It doesn't tell you anything, because type information is discarded in   
   the conversion to pointer-to-first-element, which is called a "decay"   
   to pointer (note: also function types can decay to pointers).   
      
   Applying * does not magically retrieve that lost information.   
      
   The type of the object created is 'int[10]', while the type that you   
   pass to decltype is 'int'.   
      
      
   Cheers & hth.,   
      
   - Alf   
      
      
   --   
         [ 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