This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



On 23 Sep 2004, at 18.40, Matt Austern wrote:


On Sep 23, 2004, at 6:36 PM, Zack Weinberg wrote:

Ziemowit Laski <zlaski@apple.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 needed.

Agreed; unfortunately, all ObjC structs will need this, so I don't think
that "rarely" applies. I'll investigate doing (3a), and see where that goes.


--Zem


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]