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: generalized lvalues



On 18 Nov 2004, at 15.44, Zack Weinberg wrote:


Matt Austern <austern@apple.com> writes:

On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote:
The most straighforward -- and intuitive -- way of doing this is
precisely via a cast applied to the lvalue, as seen above (with
'__strong' expanding to an appropriate attribute).  While we have
investigated some syntactic alternatives to the cast in light of
the impending lvalue cast removal, all of them are counterintuitive
in that they fail to express what is being done -- namely, altering
the type of a variable for a particular assignment.

I would like to point out that in *my* arrogant opinion, this use of lvalue casts is completely *un*intuitive; I would prefer either declaring the void * with the "this is a GC root" attribute in the first place, e.g.

   id object;
   void *__gcroot ptr;
   ...
   ptr = object;

or (if for some reason that is impossible) a builtin function call,
e.g.

   id object;
   void *ptr;
   ...
   __builtin_gc_register(ptr);
   ptr = object;

Thing is, the code in AppKit and Foundation (our ObjC frameworks) routinely
juggles large swaths of uninitialized (and "untyped") memory which is then
gradually used up to hold various things, only some of which are pointers
to GC-able objects. So statically typing 'ptr' in such cases is out of
the question. Of course, in other cases, what you suggest _is_ possible
and we do it already:


    __strong void *ptr;
       :
    ptr = object;    /* write-barrier call will be generated. */

(Note the consistent way in which '__strong' is used.)

The __builtin_gc_register approach would require that the entire GC API
be redesigned, and of course would be extremely inefficient, since _every_
assignment in a program would have to go through a write-barrier which would
either do something or nothing depending on whether __builtin_gc_register and/or
__builtin_gc_unregister has been called.


The "cleanest" syntactic approach we could come up with so far is

__builtin_objc_gc_strong(ptr) = object;

which I suppose we can live with, though the lhs doesn't look too lvaluish this way... :-(

--Zem


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