On Thursday, December 20, 2012 04:31:05 Red wrote:
> Not a major issue of course, but I am just wondering why the definition of POD says "no destructor" and "no hidden members" whereas a D struct has both and is referred to as POD.

D structs really aren't necessarily PODs. They can be used as PODs, but they don't have to be. A POD is basically a C struct which just holds data. D structs are nearly identical to C classes except for the fact that they can't have inheritance. They can have functions, destructors data hiding, etc., in which case they aren't POD types at all. The D docs should probably be changed.

- Jonathan M Davis

Aleksey S. Skidan:

> Great thanks, but I do know what POD is. But unfortunately D's structs are not POD
> types. They depend on TypeInfo. For ex.:

In LDC there are pragmas to disable specific typeinfos/moduleinfos:
http://wiki.dlang.org/LDC-specific_language_changes#LDC_no_typeinfo

Bye,
bearophile

On 12/20/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> They can have functions.. in
> which case they aren't POD types at all.

Having regular functions doesn't change the state of PODs. Having a ctor/dtor/postblit probably does though (you can no longer safely do a memcpy).

But AFAIK you can always rely on the field layout of a non-nested D struct, so a D struct should mostly remain compatible to C structs.

On Thursday, 20 December 2012 at 10:57:08 UTC, Andrej Mitrovic wrote:
> On 12/20/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> They can have functions.. in
>> which case they aren't POD types at all.
>
> Having regular functions doesn't change the state of PODs. Having a
> ctor/dtor/postblit probably does though (you can no longer safely do a
> memcpy).

How presence of ctor/dtor/postblit affect the POD (in a sense of changing structure size and alignment)?

>
> But AFAIK you can always rely on the field layout of a non-nested D
> struct, so a D struct should mostly remain compatible to C structs.

Agree, unless it is a non-static nested function struct which has hidden member.

On 12/20/12, Maxim Fomin <maxim@maxim-fomin.ru> wrote:
> How presence of ctor/dtor/postblit affect the POD (in a sense of changing structure size and alignment)?

It doesn't, but the semantics are different. For example if you pass your struct to the C side the C code might do copies of your struct but it will have no idea about your postblits or destructors.

On 12/29/2006 12:48 PM, Aleksey S. Skidan wrote:
> Great thanks I'll try it. Though IMHO it's not a convinient way (more C-lysh is
> more convinient as for me [the KISS rule]).
> But as the language is young...

Another way, if you're feeling adventurous, is to write a program to read the .o files and remove those sections. It's not hard, but if you're not comfortable with the .o file format, it can be a bit daunting.

On 12/29/2006 5:41 AM, Aleksey S. Skidan wrote:
> I just wonder if there's such a thing as POD type in D? I have failed to find
> one. The extern(C) struct seems not to be the thing because it is hardwired to
> the ABI.
>

D's definition of POD:

/***************************************
 * Return true if struct is POD (Plain Old Data).
 * This is defined as:
 *      not nested
 *      no postblits, constructors, destructors, or assignment operators
 *      no fields with with any of those
 * The idea being these are compatible with C structs.
 *
 * Note that D struct constructors can mean POD, since there is always default
 * construction with no ctor, but that interferes with OPstrpar which wants it
 * on the stack in memory, not in registers.
 */
bool StructDeclaration::isPOD()
{
    if (isnested || cpctor || postblit || ctor || dtor)
        return false;

    /* Recursively check any fields have a constructor.
     * We should cache the results of this.
     */
    for (size_t i = 0; i < fields.dim; i++)
    {
        Dsymbol *s = fields[i];
        VarDeclaration *v = s->isVarDeclaration();
        assert(v && v->storage_class & STCfield);
        if (v->storage_class & STCref)
            continue;
        Type *tv = v->type->toBasetype();
        while (tv->ty == Tsarray)
        {   TypeSArray *ta = (TypeSArray *)tv;
            tv = tv->nextOf()->toBasetype();
        }
        if (tv->ty == Tstruct)
        {   TypeStruct *ts = (TypeStruct *)tv;
            StructDeclaration *sd = ts->sym;
            if (!sd->isPOD())
                return false;
        }
    }
    return true;
}

On 12/19/2012 7:31 PM, Red wrote:
> The definition says no destructor and no hidden members. Whereas
> above it says that a D struct has a (trivial) destructors.

A "trivial" destructor is the implicit one that does nothing, i.e. it means no destructor.

On 12/20/2012 4:12 AM, Andrej Mitrovic wrote:
> On 12/20/12, Maxim Fomin <maxim@maxim-fomin.ru> wrote:
>> How presence of ctor/dtor/postblit affect the POD (in a sense of
>> changing structure size and alignment)?
>
> It doesn't, but the semantics are different. For example if you pass
> your struct to the C side the C code might do copies of your struct
> but it will have no idea about your postblits or destructors.


There's more than that. POD structs can exist solely in registers. Having ctor/dtor/postblit means that structs cannot be enregistered, because those operations require a pointer to the instance.

There are subtleties to it. It affects all kinds of things like ABI call/return issues, varargs, etc.

There needs to be an easy way to query a type to see if it is POD, and currently there isn't one.

On Friday, 29 December 2006 at 13:41:20 UTC, Aleksey S. Skidan wrote:
> I just wonder if there's such a thing as POD type in D? I have failed to find
> one. The extern(C) struct seems not to be the thing because it is hardwired to
> the ABI.

POD = Prisoner of D?