This is the mail archive of the 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]

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

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
(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,


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