From: Per Bothner <per@bothner.com>
To: gcc@gcc.gnu.org
Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...)
Date: Thu, 09 Sep 1999 09:28:00 -0000 [thread overview]
Message-ID: <m23dwoxd7f.fsf@magnus.bothner.com> (raw)
In-Reply-To: <199909090801.KAA00952@mira.isdn.cs.tu-berlin.de>
"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
> > I put my design up on http://www.bothner.com/~per/jv-inherit.txt
> Interesting. Is this used in jc1/linbgcj? I couldn't find it there.
No. I'm hoping it (or something better) will get implemented.
Currently, Gcj does a linear search on *each call*, which is
why something better has high priority.
> I think cc1plus could certainly follow this ABI for extern "Java"
> classes. It won't work as a general C++ ABI, for a number of reasons:
>
> - It requires (potentially dynamic) allocation of numbers to
> interfaces, and in turn potentially dynamic resizing of arrays.
> C++ users (especially those designing embedded applications) usually
> don't like the idea of the C++ runtime system allocating memory when
> they didn't explicitly requires that.
No, the design requires *link-time* allocation of numbers. Thus your
objection about embedded applications is not relevant, since such
applications use static linking.
> - It requires class information structures which more details than
> mandated by the C++ standard. For the standard C++ ABI, only features
> justified by the C++ standard are acceptable (in the case of RTTI,
> this is dynamic_cast, typeid, and EH)
I don't follow this. Yes, Java does require more class
information data structures than C++, but that is all orthogonal to
my design. My design proposes alternative data structured for
virtual function calls and exactly the things you mention.
> - It appears to assume a single-rooted class hierarchy. In C++, an
> interface can be implemented by classes that don't share a base class.
> If a pointer-to-interface really means pointer-to-complete-object
> in the ABI, I don't think you can support multi-rooted hierarchies
> at the same time. You wouldn't know where the vtbl is, or the class
> description (i.e. you couldn't implement OBJECT_CLASS)
Well, the write-up is written in the context of Java. But is there
any fundamental reason the basic idea can't be generalized to more of
C++? Note the idea is to use special "extra-indirect vtables", but *only*
for abstract classes with no fields. Specifically, I don't think
pointer-to-interface needs to mean pointer-to-complete-object. Instead,
how about pointer-to-interface meaning pointer-to-*concrete*-object,
where a "concrete" object corresponds to a class that has fields or
non-abstract virtual methods.
> - It distinguishes between classes and interfaces, when there is no
> such distinction in C++.
But we can make a distiction between "classes that have no instance fields
or non-abstract virtual methods" and "other classes" in the implementation.
> As a result, it does not support all features
> required in C++. E.g. in Java, you cannot cast from one interface
> to another, unless they are in an inheritance hierarchy (you need
> two casts to implement a cross-cast). In C++, you can dynamic_cast to
> a sibling class.
I think that is an implementation detail.
> So, in short: I think its nice for Java, but it doesn't port to C++.
I am not convinced yet. Of course I'm not the one that needs to be
convinced either way, as I don't see myself being able to do the
implementation.
--
--Per Bothner
bothner@pacbell.net per@bothner.com http://www.bothner.com/~per/
WARNING: multiple messages have this Message-ID
From: Per Bothner <per@bothner.com>
To: gcc@gcc.gnu.org
Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...)
Date: Thu, 30 Sep 1999 18:02:00 -0000 [thread overview]
Message-ID: <m23dwoxd7f.fsf@magnus.bothner.com> (raw)
Message-ID: <19990930180200.d0Xe1yOaE_gVqgKk_AblAX6PF8KUcT2owVtEyNK1Sng@z> (raw)
In-Reply-To: <199909090801.KAA00952@mira.isdn.cs.tu-berlin.de>
"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
> > I put my design up on http://www.bothner.com/~per/jv-inherit.txt
> Interesting. Is this used in jc1/linbgcj? I couldn't find it there.
No. I'm hoping it (or something better) will get implemented.
Currently, Gcj does a linear search on *each call*, which is
why something better has high priority.
> I think cc1plus could certainly follow this ABI for extern "Java"
> classes. It won't work as a general C++ ABI, for a number of reasons:
>
> - It requires (potentially dynamic) allocation of numbers to
> interfaces, and in turn potentially dynamic resizing of arrays.
> C++ users (especially those designing embedded applications) usually
> don't like the idea of the C++ runtime system allocating memory when
> they didn't explicitly requires that.
No, the design requires *link-time* allocation of numbers. Thus your
objection about embedded applications is not relevant, since such
applications use static linking.
> - It requires class information structures which more details than
> mandated by the C++ standard. For the standard C++ ABI, only features
> justified by the C++ standard are acceptable (in the case of RTTI,
> this is dynamic_cast, typeid, and EH)
I don't follow this. Yes, Java does require more class
information data structures than C++, but that is all orthogonal to
my design. My design proposes alternative data structured for
virtual function calls and exactly the things you mention.
> - It appears to assume a single-rooted class hierarchy. In C++, an
> interface can be implemented by classes that don't share a base class.
> If a pointer-to-interface really means pointer-to-complete-object
> in the ABI, I don't think you can support multi-rooted hierarchies
> at the same time. You wouldn't know where the vtbl is, or the class
> description (i.e. you couldn't implement OBJECT_CLASS)
Well, the write-up is written in the context of Java. But is there
any fundamental reason the basic idea can't be generalized to more of
C++? Note the idea is to use special "extra-indirect vtables", but *only*
for abstract classes with no fields. Specifically, I don't think
pointer-to-interface needs to mean pointer-to-complete-object. Instead,
how about pointer-to-interface meaning pointer-to-*concrete*-object,
where a "concrete" object corresponds to a class that has fields or
non-abstract virtual methods.
> - It distinguishes between classes and interfaces, when there is no
> such distinction in C++.
But we can make a distiction between "classes that have no instance fields
or non-abstract virtual methods" and "other classes" in the implementation.
> As a result, it does not support all features
> required in C++. E.g. in Java, you cannot cast from one interface
> to another, unless they are in an inheritance hierarchy (you need
> two casts to implement a cross-cast). In C++, you can dynamic_cast to
> a sibling class.
I think that is an implementation detail.
> So, in short: I think its nice for Java, but it doesn't port to C++.
I am not convinced yet. Of course I'm not the one that needs to be
convinced either way, as I don't see myself being able to do the
implementation.
--
--Per Bothner
bothner@pacbell.net per@bothner.com http://www.bothner.com/~per/
next prev parent reply other threads:[~1999-09-09 9:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-26 15:59 Jason Merrill
1999-08-26 16:38 ` Jason Merrill
1999-08-31 23:20 ` Jason Merrill
1999-08-26 17:05 ` Joe Buck
1999-08-26 17:13 ` Jason Merrill
1999-08-26 17:26 ` Mumit Khan
1999-08-31 23:20 ` Mumit Khan
1999-08-31 23:20 ` Jason Merrill
1999-08-31 23:20 ` Joe Buck
1999-08-31 23:20 ` Jason Merrill
1999-09-07 18:42 ` Per Bothner
1999-09-07 23:14 ` Martin v. Loewis
1999-09-07 23:53 ` Per Bothner
1999-09-08 0:49 ` Martin v. Loewis
1999-09-08 6:33 ` Per Bothner
1999-09-09 1:39 ` Martin v. Loewis
1999-09-09 9:28 ` Per Bothner [this message]
1999-09-30 18:02 ` Per Bothner
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Per Bothner
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Per Bothner
1999-09-30 18:02 ` Martin v. Loewis
1999-09-30 18:02 ` Per Bothner
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=m23dwoxd7f.fsf@magnus.bothner.com \
--to=per@bothner.com \
--cc=gcc@gcc.gnu.org \
/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).