[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New warnings (hopefully) in gcc 3.4
From: |
Ziemowit Laski |
Subject: |
Re: New warnings (hopefully) in gcc 3.4 |
Date: |
Wed, 3 Sep 2003 12:27:10 -0700 |
On Wednesday, Sep 3, 2003, at 05:09 US/Pacific, Nicola Pero wrote:
Ok. But from that point of view, even if you have a single prototype
given, it might be all wrong, for all we know.
Yes, you're right -- having an 'id'-typed receiver and a single
prototype floating around certainly doesn't
guarantee that that is the correct prototype to use. :-)
My motivation for falling back to a '(* id)(id, SEL, ...)' signature in
case of conflicts was twofold:
- That is the signature for the actual objc_msgSend() entry point; if
you called it by hand,
that's what you'd get.
- I wanted a simple, _consistent_ and easy to understand failure mode.
Note that '(* id)(id, SEL, ...)'
is picked if there are multiple prototypes, or if there is _no_
prototype -- in other words,
whenver the compiler cannot decide what to use.
If we were to construct a Frankensteinian method signature out of
competing signatures, then we would have to
acquire the ability for computing the least common ancestor (or lack
thereof) for arbitrary types, _and_
explain the algorithm involved to users so that they know what to
expect. By the time we're done, the whole
thing might make C++ overload resolution look like a walk in the park.
:-)
If multiple declarations are found, the compiler can assume that the
right
one is one of those (accepting the assumption above). If the different
declarations would cause it to generate the same code, then no matter
which one is chosen, generated code will always be right - no matter
which
of the different declarations which have been seen is actually
implemented
by the id (it must be one of those, accepting the assumption above!),
the
generated code is right.
But now you'd need to determine whether a group of signatures is
codegen-compatible,
and you'll need to explain the resulting algorithm to users of the
language.
If it finds multiple conflicting declarations, say 2 really conflicting
declarations, then - again assuming that the compiler has seen all the
relevant method prototypes before the method call - the 'id' must
implement the first one, or the second one: the compiler has a 50% of
getting it right if it picks up one randomly. If the compiler
fallbacks
to a default fallback prototype in this case, it has a different
probability of getting it right, which I feel would be less than 50%.
So
maybe the compiler should actually pick up one randomly. The only
other
option I see is aborting compilation - falling back to an abstract
default
does not seem particularly useful to me.
Perhaps I'm alone in my conviction, but I must say I really, really
detest
the notion of a compiler doing things randomly. :-) :-) Your
probabilistic
argument sounds plausible (i.e., we might have slightly better odds of
picking a "codegen-correct" signature), but I honestly don't think that
programming language design should be concerned with odds. :-)
In the past, when the compiler picked a method out of a sea of competing
signatures, many users could have been led to believe that it had a
reason for doing so, i.e., there exists some overload resolution rule
in ObjC which caused that particular method to be picked. So imagine
the users' frustration when, in the very next translation unit, the
compiler resolves the very same conflict in a different way! (This is
possible if, e.g., you #include headers in a different order.) This is
no way for a programming language to behave. :-)
Anyway, yes discussing this shows that Objective-C is somewhat lossy
and
unformalized, and has a very practical spirit. I guess it would be
nice
to have things standardized.
Standards are nice (which is why everyone should have one :-)), but
figuring
out corner cases such as this one is a good place to start, IMO.
--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
- Re: New warnings (hopefully) in gcc 3.4, (continued)
- Re: New warnings (hopefully) in gcc 3.4, Nicola Pero, 2003/09/01
- Re: New warnings (hopefully) in gcc 3.4, David Ayers, 2003/09/03
- Re: New warnings (hopefully) in gcc 3.4, Nicola Pero, 2003/09/03
- Re: New warnings (hopefully) in gcc 3.4, David Ayers, 2003/09/03
- Re: New warnings (hopefully) in gcc 3.4, Alexander Malmberg, 2003/09/03
- 2 Questions, Ziemowit Laski, 2003/09/03
- Re: 2 Questions, Alexander Malmberg, 2003/09/03
- Re: New warnings (hopefully) in gcc 3.4, David Ayers, 2003/09/03
Re: New warnings (hopefully) in gcc 3.4, Alexander Malmberg, 2003/09/03