From: Ziemowit Laski <zlaski@apple.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Matt Austern <austern@apple.com>, gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: generalized lvalues
Date: Fri, 19 Nov 2004 01:38:00 -0000 [thread overview]
Message-ID: <39B69E96-39C9-11D9-8317-00039390FFE2@apple.com> (raw)
In-Reply-To: <87zn1eiuy4.fsf@codesourcery.com>
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
next prev parent reply other threads:[~2004-11-19 1:20 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-18 3:50 Matt Austern
2004-11-18 3:52 ` Andrew Pinski
2004-11-18 4:01 ` Andrew Pinski
2004-11-18 4:18 ` Daniel Berlin
2004-11-18 4:21 ` Andrew Pinski
2004-11-18 4:27 ` Matt Austern
2004-11-18 7:15 ` Joe Buck
2004-11-18 7:37 ` Matt Austern
2004-11-18 13:17 ` Giovanni Bajo
2004-11-18 17:57 ` Joe Buck
2004-11-18 18:28 ` Mike Stump
2004-11-18 18:44 ` Joe Buck
2004-11-19 1:39 ` Mike Stump
2004-11-19 4:52 ` Matt Austern
2004-11-19 22:24 ` Michael Matz
2004-11-19 22:30 ` Robert McNulty Junior
2004-11-20 1:00 ` Ziemowit Laski
2004-11-20 1:20 ` Joe Buck
2004-11-20 1:51 ` Ziemowit Laski
2004-11-20 5:04 ` Joe Buck
2004-11-20 5:17 ` Ziemowit Laski
2004-11-22 20:54 ` generalized lvalues -- patch outline Ziemowit Laski
2004-11-22 21:01 ` Andrew Pinski
2004-11-22 21:11 ` Ziemowit Laski
2004-11-22 21:39 ` Matt Austern
2004-11-22 22:11 ` Joe Buck
2004-11-22 22:12 ` Matt Austern
2004-11-23 0:06 ` Gabriel Dos Reis
2004-11-23 0:04 ` Gabriel Dos Reis
2004-11-23 0:27 ` Mike Stump
2004-11-24 20:40 ` Kai Henningsen
2004-11-23 0:11 ` Mark Mitchell
2004-11-23 1:19 ` Matt Austern
2004-11-23 1:26 ` Mark Mitchell
2004-11-23 1:32 ` Dale Johannesen
2004-11-23 1:42 ` Mark Mitchell
2004-11-23 1:45 ` Andrew Pinski
2004-11-23 1:55 ` Dale Johannesen
2004-11-23 1:56 ` Andrew Pinski
2004-11-23 2:12 ` Dale Johannesen
2004-11-23 2:10 ` Marcus G. Daniels
2004-11-23 9:43 ` Eric Botcazou
2004-11-23 18:27 ` Aaron W. LaFramboise
2004-11-22 21:23 ` Nathan Sidwell
2004-11-22 22:33 ` Ziemowit Laski
2004-11-23 0:09 ` Gabriel Dos Reis
2004-11-23 9:54 ` Nathan Sidwell
2004-11-23 13:35 ` Michael Matz
2004-11-23 14:56 ` Daniel Berlin
2004-11-23 15:02 ` Michael Matz
2004-11-23 15:15 ` Andrew Pinski
2004-11-23 15:47 ` Michael Matz
2004-11-23 15:56 ` Gabriel Dos Reis
2004-11-23 15:50 ` Steve Naroff
2004-11-23 15:51 ` Gabriel Dos Reis
2004-11-23 16:50 ` Eric Botcazou
2004-11-23 17:01 ` Paul Koning
2004-11-23 17:16 ` Andreas Schwab
2004-11-23 18:03 ` Thomas Kunert
2004-11-23 18:30 ` Nathan Sidwell
2004-11-23 18:57 ` Thomas Kunert
2004-11-23 21:21 ` Paul Koning
2004-11-23 21:52 ` Thomas Kunert
2004-11-23 15:51 ` Gabriel Dos Reis
2004-11-23 16:12 ` Michael Matz
2004-11-23 16:31 ` Richard Guenther
2004-11-23 16:44 ` Andreas Schwab
2004-11-23 20:16 ` Gabriel Dos Reis
2004-11-23 15:01 ` Nathan Sidwell
2004-11-23 15:09 ` Michael Matz
2004-11-23 19:11 ` Matt Austern
2004-11-23 21:10 ` Eric Botcazou
2004-11-23 21:34 ` Ziemowit Laski
2004-11-23 22:09 ` Joseph S. Myers
2004-11-23 22:23 ` Eric Botcazou
2004-11-23 22:27 ` Joseph S. Myers
2004-11-24 0:05 ` Eric Botcazou
2004-11-24 0:07 ` Steven Bosscher
2004-11-24 0:32 ` Joseph S. Myers
2004-11-25 8:41 ` Ian Lance Taylor
2004-11-25 20:41 ` Gabriel Dos Reis
2004-11-25 21:54 ` Matt Austern
2004-11-25 23:27 ` Gabriel Dos Reis
2004-11-29 18:06 ` Joe Buck
2004-11-29 18:57 ` Matt Austern
2004-11-23 23:27 ` Gabriel Dos Reis
2004-11-23 22:24 ` Nathan Sidwell
2004-11-23 0:07 ` Gabriel Dos Reis
2004-11-24 20:43 ` Kai Henningsen
2004-11-24 23:09 ` Gabriel Dos Reis
2004-11-24 23:17 ` Zack Weinberg
2004-11-22 21:31 ` Richard Henderson
2004-11-23 0:11 ` Gabriel Dos Reis
2004-11-23 0:03 ` Jonathan Lennox
2004-11-20 1:40 ` generalized lvalues Joseph S. Myers
2004-11-18 19:11 ` Alex Rosenberg
2004-11-18 4:24 ` Matt Austern
2004-11-18 5:33 ` Dale Johannesen
2004-11-18 17:14 ` Fariborz Jahanian
2004-11-18 18:23 ` Joe Buck
2004-11-19 0:20 ` Ziemowit Laski
2004-11-19 0:40 ` Steven Bosscher
2004-11-19 1:20 ` Joe Buck
2004-11-19 2:00 ` Ziemowit Laski
2004-11-18 23:36 ` Ziemowit Laski
2004-11-18 23:37 ` Matt Austern
2004-11-18 23:49 ` Zack Weinberg
2004-11-19 1:38 ` Ziemowit Laski [this message]
2004-11-19 2:52 ` Zack Weinberg
2004-11-19 3:56 ` Ziemowit Laski
2004-11-19 4:22 ` Zack Weinberg
2004-11-19 13:10 ` Nathan Sidwell
2004-11-19 21:58 ` Ziemowit Laski
2004-11-18 23:44 ` Andrew Pinski
2004-11-18 23:45 ` Joe Buck
2004-11-25 4:42 ` Aaron W. LaFramboise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39B69E96-39C9-11D9-8317-00039390FFE2@apple.com \
--to=zlaski@apple.com \
--cc=austern@apple.com \
--cc=gcc@gcc.gnu.org \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).