objc data structures

[Geoffrey Keating]

On 07/10/2004, at 12:03 PM, Ziemowit Laski wrote:

>>>>>> - Is it ever necessary to have this information as well as the 
>>>>>> information that C or C++ stores in the lang_specific field?
>>>>>
>>>>> No idea.
>>>>
>>>> Could you please find out?  This information is essential to the 
>>>> design.
>>>
>>> How do you suggest I do that?  You're asking me to establish 
>>> constraints on the use of a local data structure by other 
>>> front-ends.
>>
>> Is it necessary in the current compilers, to which you have source?
>
> Even if the "current compilers" were set in stone, I still fail to see 
> how you'd compute this predicate.
>
>> More generally, given what the current compilers have in the 
>> lang_type structures, is it necessary to have both that data and the 
>> data that objc needs?
>>
>> Or, to phrase it another way, could we just decide that lang_type can 
>> be a union that can point to either the data that objc needs or the 
>> data that the C or C++ frontend needs?
>
> You're asking me
>   (1) the exact conditions under which C or C++ might decide to store 
> lang_specific information in a type node; and
>   (2) the exact conditions under which ObjC/ObjC++ needs to store 
> lang_specific information (for now, protocols) in a type node; and
>   (3) whether (1) and (2) are guaranteed to be mutually exclusive.
>
> The only one of these I could even _begin_ to answer is (2).

*sigh*.

You do it very simply.  You look at the actual source code of the C and 
C++ frontends, and determine (1).  Then, you look at the actual source 
code of the objc/objc++ frontend and determine (2).  Then, you 
determine what the overlap is.

I will give you an worked example, from the C frontend.  Looking at the 
C frontend, we see that 'struct lang_type' looks like:

struct lang_type GTY(())
{
   /* In a RECORD_TYPE, a sorted array of the fields of the type.  */
   struct sorted_fields_type * GTY ((reorder ("resort_sorted_fields"))) 
s;
   /* In an ENUMERAL_TYPE, the min and max values.  */
   tree enum_min;
   tree enum_max;
};

Now, from the information you gave earlier, we are concerned with 
record types.  The 'struct lang_type' has a field that looks like it's 
used for record types.  Searching for TYPE_LANG_SPECIFIC indicates that 
it's used in 'lookup_field' in c-typeck.c, and maybe other places.  So, 
it seems like the answer for the C part of (1) is "any record type".

Now, following my example, please answer (1) for C++, and (2) for ObjC 
and ObjC++.  If you get stuck, let me know.

>  Unless you can present a methodology for computing (1), as well as 
> ensuring that _no_ future patch to the C or C++ front-ends alters (1) 
> in ways that violates (3), I posit that the C/C++ and ObjC/ObjC++ 
> lang_specific information must be treated as orthogonal.

You can posit it, but it is clearly not correct.  We do not need to 
solve the problem for every possible compiler, we only need to solve it 
for the one that we have now.  Future expandability is a concern in the 
design, but it is not the question that I was asking about.

-- 
Geoff Keating <geoffk@apple.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2361 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20041008/ed332907/attachment.p7s>