Re: [boost] Predictable Layout for certain non-POD data types

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2002-03-20 03:32:17

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> \> "David Abrahams" <david.abrahams_at_[hidden]> writes:
> > > Ralf and I have authored this paper for the upcoming C++ committee
> > > meeting
> > > http://cci.lbl.gov/~rwgk/tmp/enhanced_pod_proposal.html
> >
> > Excellent job, thanks.  It has gotten me thinking about what an
> enhanced
> > POD should be allowed to do.  For reference I have appended the
> relevant
> > definitions from the standard.
> >
> > The first thing I notice is that PODs are a type of aggregate, and
> that
> > aggregates are already forbidden to have constructors.  So one way to
> > allow a POD to have constructors would be to drop that restriction,
> but
> > I believe the purpose of that restriction is to prevent users from
> > circumventing user-declared constructors by using an
> initializer-clause.
> 
> 
> Your post seems to be starting from a slightly different premise than
> our paper. When I spoke to John Spicer about the issues, he expressed
> the opinion that we needed to preserve the POD concept without
> modification, but that another "enhanced POD" might be designated to
> give us some of the extra flexibility we want. Accordingly, our proposal
> is aimed not at changing the standard definition of POD, but at
> outlining the properties of a new "enhanced POD concept". Notably, the
> ability to use initializer-clauses is not one of the properties we
> thought we'd need for enhanced PODs.
>
> We hoped that by checking with John first we'd get a better sense of
> what would be likely to be acceptable, so that's why we did it this way.
> Of course, it's possible the rest of the committee would feel it's more
> appropriate to loosen the restrictions on POD data, so your analysis
> could be useful.

Reading my own post I've decided I don't like the solution I posted, and
I'll get back to it soon.  But I think the analysis is on the right track,
since a POD is a more restricted type of aggregate, and an enhanced POD
would be a less restricted form of POD, but the restriction to be removed
(against user-defined constructors) is also a restriction on aggregates.
So we could wind up with:

    an aggregate is a restricted type of struct, union, or array

    a POD is restricted type of aggregate

    an enhanced POD is not an aggregate or a POD

Now maybe this is OK, but it does seem tricky to specify, and both
aggregate and POD are important concepts that need to be preserved.

Perhaps the right name for "enhanced POD" is pseudo-POD (pun intended)?