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