This is the mail archive of the
mailing list for the GCC project.
Re: PING: Question: Need to store ObjC-specific info in type nodes.
- From: Steve Naroff <snaroff at apple dot com>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: gcc List <gcc at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, gcc-help at group dot apple dot com
- Date: Thu, 23 Sep 2004 19:07:30 -0700
- Subject: Re: PING: Question: Need to store ObjC-specific info in type nodes.
- References: <C4DA0684-0DC7-11D9-A90Bfirstname.lastname@example.org>
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
btw...the terms "ghastly" and "horrible state of affairs seem a bit
dramatic", eh? Take a deep breath - we'll get you through this
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
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
(1) The additional info required for ObjC RECORD_TYPEs is stored as
attributes, which peacefully co-exist with C/C++ attributes in the
(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