This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: ObjC++ template expansion -- Part 1
On 15 Sep 2004, at 14.42, Mark Mitchell wrote:
Ziemowit Laski wrote:
On 14 Sep 2004, at 0.04, Kai Henningsen wrote:
mark@codesourcery.com (Mark Mitchell) wrote on 13.09.04 in
<4145F860.3000404@codesourcery.com>:
language feature. Objective-C++ seems to want to say "these two
types
are the same (in that you can intra-convert between them) but also
not
the same (in the sense that you have to know which one you have)."
If
that's the case, then I think we've got the wrong approach here.
The
It is a little bit (but not exactly) like multiple inheritance,
Yes, the usage of ObjC protocols is sort of like C++ multiple
inheritance;
the protocols themselves can be thought of as abstract base classes
with no
data members (and no member function definitions, only pure virtuals).
A much simpler way to describe ObjC protocols is to say that they are
like
Java interfaces. In fact, I believe the latter were inspired by the
former.
Well, that's basically a special case of multiple inheritance. I
think that what Jason and I are saying is that we'd like to see them
modeled as such in the C++ front end. We consider it something of an
invariant that if t1/t2 are two types such that same_type_p (t1, t2)
is true, then it doesn't matter which one you use. If it does matter,
then they're not the same type.
Yes, you're absolutely right.
The problem that this patch, along with the build_c_cast() patches
before it, is trying to solve is that ObjC currently misuses the
TYPE_MAIN_VARIANT accessor. Returning to my example, the tree node
corresponding to the 'NSObject <Foo> *' type will have its
TYPE_MAIN_VARIANT pointing at the unadorned 'NSObject *' type.
This is clearly broken, but has been done like this since time
immemorial. All the type comparison routines in the compiler that I've
run into traverse the TYPE_MAIN_VARIANT accessor and therefore conclude
that these two types are the same. In the vast majority of cases, we
can tolerate this false positive. The cases where we cannot include
building casts (where we do need to preserve the cast), and when
instantiating/specializing templates (which is what this patch is
about).
Here's what I would propose to do/try:
- Hoist the assignment out of the conditional, per RTH's request
- In the example above, try pointing TYPE_MAIN_VARIANT back at
'NSObject <Foo> *' instead of 'NSObject *' (in ObjC++ only for now, for
simplicity) and see if I can restore ObjC++ to working condition with
this change. If I can, then the present patch (and probably the
build_c_cast() patch as well) may not be needed after all!
- If the TYPE_MAIN_VARIANT experiment fails, then I'd suggest marking
off my patch with 'if (c_dialect_objc ())'. I realize that this is
still a hot spot in the compiler, but that is probably the best we can
do. The only "faster" approach would be to compile pt.c separately for
ObjC++.
In the future, I think it would be a good idea to reimplement ObjC
protocols so that they are handled internally as attributes (e.g.,
'NSObject __attribute__((objc_protocol(Foo))) *'), which should allow
us to simplify this mess.
As for modeling ObjC++ features in terms of the C++ front-end, I think
it is a great idea, but only after the C++ front-end is robustified to
handle all the C family variants. Before that point, we'd still need a
separate implementation for plain ObjC.
Anyway, I'll experiment with the TYPE_MAIN_VARIANT idea and let you
know what I find. If you have other questions/suggestions, please let
me know.
--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