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: Matt Austern <austern at apple dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Ziemowit Laski <zlaski at apple dot com>, 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 18:40:35 -0700
- Subject: Re: PING: Question: Need to store ObjC-specific info in type nodes.
- References: <C4DA0684-0DC7-11D9-A90Bemail@example.com> <firstname.lastname@example.org>
On Sep 23, 2004, at 6:36 PM, Zack Weinberg wrote:
Ziemowit Laski <email@example.com> writes:
Please, folks -- this ain't rocket science...
You posted your question three hours ago. Generally it takes at least
a day to get an answer out of anyone.
I find either (1) or (3) infinitely preferable to (2), and would
suggest you consider a (3a) in which the ObjC/ObjC++ front ends
enlarge the C/C++ lang_type structures (in much the same way that all
these front ends currently build on struct c_common_identifier to
create their struct lang_identifier). This is preferable to (3) if
the additional data is small (up to, say, four pointers), or if it
needs allocating for practically every RECORD_TYPE. If it is both
large and rarely needed, your original (3) is better.
You should determine the answer to the question "is it rarely needed?"
by measurement of real code.
As I commented offline, the other thing to consider is that attributes
(even with Geoff's rewrite) are expensive. Zem's suggestion #1 would
probably only be a good idea if this information is *really* rarely