Hi Jay,> I'll have another go then!thanks!>> I find this distinction between structs with names and structs without >> names strange. Why is a name relevant to anything? If you can add fields >> to a struct with a name [...] > > This corresponds to the following C constructs: > > struct S; // create struct with name but no fields > ... > struct S { int i, j; } // add fields to named structIn Ada you can have a forward declaration with fields (known as discriminants), for example: type X (Z : Integer); -- Z is the discriminant type XP is access X; type X (Z : Integer) is record P : XP; -- Add an additional field, now there are two end record; I don't think this will cause any problems since GCC has resolved the type by the time it hits dragonegg (i.e. dragonegg doesn't see the incomplete type). In llvm-gcc we would see the incomplete type, but I don't care about llvm-gcc any more :)>> [...] why not to a struct without a name? > > This would imply that you were starting with a struct with no name and > no fields, which is not something you can create in C: > > struct; // this isn't a C type!I see structs with fields but without names come flying out of gcc for C++ code all the time. I'm not sure where they come from - perhaps they are utility types created by the front-end. These are probably harmless since then can just be given an invented name. Or maybe it is harmless to let them have no name.> Maybe "adding fields" is bad terminology -- we're really talking about > setting the struct's list of fields, which you can only do once. (You > can't add yet more fields later.)The name-noname distinction still seems artificial to me. I assume it is being driven by efficiency considerations: i.e. not allowing named types to be refined simplifies LLVM's internals considerably. Ciao, Duncan.
>>> [...] why not to a struct without a name? >> >> This would imply that you were starting with a struct with no name and >> no fields, which is not something you can create in C: >> >> struct; // this isn't a C type! > > I see structs with fields but without names come flying out of gcc for C++ > code > all the time.That's fine; in C this is like the type of s in: struct { int i, j; } s; But in this case, you know what the fields are straight away; you don't need to create a tag-less field-less struct and then add the fields *later*. To put it another way, when a C struct is first declared, it has either a name (tag) or a list of fields or both, but not neither!> The name-noname distinction still seems artificial to me. I assume it is > being > driven by efficiency considerations: i.e. not allowing named types to be > refined > simplifies LLVM's internals considerably.I see your point. Maybe Chris's implementation *does* allow you to refine unnamed types. I hadn't really considered it before. Jay.
On Jun 30, 2011, at 8:56 AM, Jay Foad wrote:>> The name-noname distinction still seems artificial to me. I assume it is >> being >> driven by efficiency considerations: i.e. not allowing named types to be >> refined >> simplifies LLVM's internals considerably. > > I see your point. Maybe Chris's implementation *does* allow you to > refine unnamed types. I hadn't really considered it before.There is no refinement in the new system: once a type is created, it doesn't change. The only "refinement" allowed is to specify a body for a named type. The implication of this is that the only way to get a recursive type is to use a 'named' struct. If we were to simplify anything away, it would be anonymous structs. I thought about this quite a bit, but I think that having the ability to allow simple (non-recursive) aggregation is really useful for frontends. -Chris