On Wednesday, Aug 28, 2002, at 11:52 US/Pacific, Stan Shebs wrote:
> Ziemowit Laski wrote:
>
>>>
>>> /* APPLE LOCAL Objective-C++ */
>>> - { $$ = get_class_ivars ($3); }
>>> + { $$ = get_class_ivars_from_name ($3); }
>>
>>
>> We can do this, but perhaps it would be simpler if we checked for
>> the existence of the class inside of 'get_class_ivars' ?
>
> I suppose so. I was thinking that get_class_ivars and
> get_class_ivars_from_name have different "signatures",
> but it wouldn't hurt (except for a tiny speed cost :-) ) to
> test inside get_class_ivars.
Actually, I just realized that the routine you introduced _is_ useful --
for doing the 'finish_member_declaration' thingie in ObjC++. There is
currently an orphaned code fragment in objc-act.c that should go into
get_class_ivars_from_name. I'll do this.
>
>>> /* Used by: build_private_template, continue_class,
>>> and for @defs constructs. */
>>>
>>> @@ -4075,8 +4094,7 @@
>>> else
>>> UOBJC_CLASS_VARIABLES_decl = 0;
>>>
>>> - /* APPLE LOCAL bitfield alignment */
>>> - chain = CLASS_OWN_IVARS (implementation_template);
>>> + chain = CLASS_IVARS (implementation_template);
>>
>> Are you sure this is correct? I'm not sure that it's not :-(, so
>> I'll take a closer look at the sources before I talk.
>
> I'm not sure either, but empirically, CLASS_OWN_IVARS is
> not filled in by finish_struct while CLASS_IVARS is. Perhaps
> they should both be filled in?
The only difference between CLASS_IVARS and CLASS_OWN_IVARS is
that the former may have been side-effected. This may not matter
for the usage above. And, since the FSF sources have 'CLASS_IVARS',
it probably makes no sense to fix what ain't broken. :-(
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477
