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

[Geoffrey Keating]

On 23/09/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?

Yes, I object.

> ----
>
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2408 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040924/279e64d4/attachment.p7s>