Re: [boost] low-level sub-allocation/alignment challenge

From: Greg Colvin (greg_at_[hidden])
Date: 2000-08-24 12:39:56

From: Darin Adler <darin_at_[hidden]>
> on 8/24/00 10:17 AM, Greg Colvin at greg_at_[hidden] wrote:
> 
> > So this is a POD too?
> > 
> >   struct Rule
> >   {
> >       unsigned long cost;
> >       const void* action;
> >       char& operator[](size_t i) { return ((char*)(&action+1))[i]; }
> >       char operator[](size_t i) const { return ((char*)(&action+1))[i]; }
> >   };
> 
> Yes. I went and reviewed the rules on POD in the standard.
> 
> A POD type is (3.9/10) one of:
> 
>     a) a scalar type
>     b) a POD-struct type
>     c) a POD-union type
>     d) an array with elements of POD type
>     e) a cv-qualified POD type
> 
> A POD-struct (9/4):
> 
>     1) is an aggregate class
>     2) has no non-static data members that are
>         a) pointer to member
>         b) non-POD-struct
>         c) non-POD-union
>         d) arrays of non-POD-struct
>         e) arrays of non-POD-union
>         f) reference
>     3) has no user-defined copy assignment operator
>     4) has no user-defined destructor
> 
> An aggregate class (8.5.1):
> 
>     1) has no user-declared constructors
>     2) has no private or protected non-static data members
>     3) has no base classes
>     4) has no virtual functions
> 
> Your example fits the bill!

Good.  I recall arguing that the definition of aggregate
was sufficient to do the job of the much more complicated
POD-struct and POD union.  But I lost that argument --
implementers claimed they might want to use some bizarre
representations of references and pointer-to-member --
and now I can never remember all the gotchas.  I still
say it's unecessary license to vendors at the expense of
users.