From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-20 00:41:36
----- Original Message -----
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
> POD should be allowed to do. For reference I have appended the
> definitions from the standard.
> The first thing I notice is that PODs are a type of aggregate, and
> aggregates are already forbidden to have constructors. So one way to
> allow a POD to have constructors would be to drop that restriction,
> I believe the purpose of that restriction is to prevent users from
> circumventing user-declared constructors by using an
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk