POD
Andrej Mitrovic
andrej.mitrovich at gmail.com
Fri Dec 28 15:53:49 PST 2012
On 12/28/12, Walter Bright <newshound2 at digitalmars.com> wrote:
> There needs to be an easy way to query a type to see if it is POD, and
> currently there isn't one.
I suggest we implement a compiler trait via __traits(isPOD, Type).
C++11 has is_pod, D should have a Phobos template that wraps around
the new trait.
C++03/11 also define their meaning of PODs to allow interfacing with
C. C++03 rules:
http://stackoverflow.com/questions/4178175/what-are-aggregates-and-pods-and-how-why-are-they-special/4178176#4178176
and C++11 rules:
http://stackoverflow.com/questions/4178175/what-are-aggregates-and-pods-and-how-why-are-they-special/7189821#7189821
According to that function you gave access specifiers in D do not
change the meaning of PODs (unlike in C++), but other than that the
rules are very similar.
What about field initalizers though? Can their presence make the
default-generated struct constructor non-trivial in D, or does it not
matter?
E.g. in C++11:
struct NotAggregate {
int x = 5; // OK
std::vector<int> s{1,2,3}; // makes it a non-aggregate, therefore non-POD
};
I'm not sure if D has these sort of issues.
More information about the Digitalmars-d
mailing list