Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Steve Naroff <snaroff at apple dot com>]

Of the choices you've outlined, I agree that (3) sounds best.

It would be nice to have a solution that doesn't require NULL slots for 
C/C++ (when not being used in the context ObjC, obviously). The tree's 
are already full of NULL fields...I would hate to add overhead for this 
reason.

btw...the terms "ghastly" and "horrible state of affairs seem a bit 
dramatic", eh? Take a deep breath - we'll get you through this 
difficult transition:-)

snaroff

On Sep 23, 2004, at 6:19 PM, Ziemowit Laski wrote:

> Please, folks -- this ain't rocket science...
>
> Does any C, C++ and/or global maintainer object to my proceeding with 
> (3) below?
> ----
>
> Currently, ObjC does some rather ghastly things with accessors such as 
> TYPE_CONTEXT, TREE_PUBLIC and TYPE_MAIN_VARIANT, which are used for 
> its own merry purposes in RECORD_TYPEs.  This is a horrible state of 
> affairs, and so I'd like to clean up the way ObjC stores its own 
> information so that it plays nice(r) with what C and C++ expect.  
> (This work is part of the ongoing ObjC++ integration, BTW, so a prompt 
> response would be appreciated.)
>
> There seem to be several ways of attacking this, but I'd like to ask 
> the powers that be for the preferred approach before actually 
> undertaking it:
> (1)  The additional info required for ObjC RECORD_TYPEs is stored as 
> attributes, which peacefully co-exist with C/C++ attributes in the
>      TYPE_ATTRIBUTES accessor.
> (2)  In addition to a 'struct lang_type *lang_specific' field, each 
> type node also gets a 'struct objc_lang_type *objc_lang_specific' 
> field (set to NULL in plain C and C++ modes).
> (3)  A variation of (2) in which 'struct lang_type' itself (both in C 
> and C++) gets 'struct objc_lang_type *objc_lang_specific' field.
>
> Which of these would be preferable and/or have I left out other 
> possibilities?  It seems that (1) would require least (if any!) 
> changes to existing GCC infrastructure, but the resulting ObjC/ObjC++ 
> compile-time performance would be less than stellar.  Personally, I 
> favor (3).
>
> Please advise,
>
> --Zem