schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:


>All programmers, distributers etc would be very glad if there were a
>standard so that objectfile/libraries generated any compiler are
>compatible (i.e. linkable) with oneanother. This means standards for
>objectfile-format, namemangeling, vtables, aggregate return/parameter
>etc.
>But this a question of implementation and not of language. IMHO a
>standard for C++- *compilers* would be a good idea. Maybe we should have a
>comp.std.compiler.c++ newsgroup that deals with this.

You would need a separate such standard for each different platform
(computer/operating-system combination). Different computers have
incompatible requirements on low-level details, and different
operating systems have incompatible low-level requirements even for
the same computer. For a given operating system, the details may
change over time. It doesn't do any good for a C++ standards committee
to mandate conventions which cannot be followed.

On some platforms there is a "500-pound gorilla" who sets a de-facto
standard, which might not be published. Anyone who wants to sell
compilers does what the gorilla does, sometimes by reverse engineering.

Sun Microsystems (my employer) is in the process of developing a
complete ABI for C++ on Solaris, such as you suggest. Future Sun
compilers will comply with the ABI, and any compiler writer will be
able to get a copy of the spec and follow it. Other computer
manufacturers also do this for their platforms.

Some details of Sun's ABI will have to wait for the C++ Committee
to settle some language issues, however. Depending on those decisions,
established ABI's on other platforms may also need to change.
--
Steve Clamage, stephen.clamage@eng.sun.com

All programmers, distributers etc would be very glad if there were a
standard so that objectfile/libraries generated any compiler are
compatible (i.e. linkable) with oneanother. This means standards for
objectfile-format, namemangeling, vtables, aggregate return/parameter
etc.
But this a question of implementation and not of language. IMHO a
standard for C++- *compilers* would be a good idea. Maybe we should have a
comp.std.compiler.c++ newsgroup that deals with this.


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de
WWW:   http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle9/~schuenem/index.html

In article <37udb4$1q@news.uni-paderborn.de>,
                Carsten Ditze <cadi@sumba.uni-paderborn.de> wrote:

>Many compilers allow to access the virtual tables that are constructed when
>using virtual methods.  For instance __vptr may be used within C++ source code
>(in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code address
>of a single virtual method dynamically at runtime.  This technique is i.e. a
>very attractive feature to implement runtime binding of methods in new object
>oriented operating systems.
>

This does not exist in C++. It only exists after the C++ source has been
converted to C, and only with cfront. In fact I am surprised cfront lets
you get away with it - perhaps an early stage of the C++->C convertion
brings the C equivs of the class structures and method vtables into
scope before cfront has determined that you are using something that
doesnt exist.

--
Adam

======================================================================
| Computech  Tel/Fax: 081 673 7817  email: adam@comptech.demon.co.uk |
======================================================================

In article <JASON.94Oct22021000@phydeaux.cygnus.com>, jason@cygnus.com (Jason Merrill) writes:
|> >>>>> Ulf Schuenemann <schuenem@Informatik.TU-Muenchen.DE> writes:
|>
|> > All programmers, distributers etc would be very glad if there were a
|> > standard so that objectfile/libraries generated any compiler are
|> > compatible (i.e. linkable) with oneanother. This means standards for
|> > objectfile-format, namemangeling, vtables, aggregate return/parameter
|> > etc.
|> > But this a question of implementation and not of language. IMHO a
|> > standard for C++- *compilers* would be a good idea. Maybe we should have a
|> > comp.std.compiler.c++ newsgroup that deals with this.
|>
|> or comp.std.c++.abi?

There would likely be some interest in this.
The Sparc camp has been actively working on ABI proposals.
The MIPS ABI and ABI+ (x86 processor) groups are also
working such issues.

In article <38056k$8jh@news.uni-paderborn.de> cadi@sumba.uni-paderborn.de (Carsten Ditze) writes:
|
|Matt Landau told me in a mail reply, that providing these variables would
|
|"tie the hands of compiler writers too much (they're not free to find better,
|more efficient, or more clever implementations of virtual function dispatch, or
|to optimize it for interlanguage calling, or whatever else they might want to
|do)"
|
|Today the hands of operating system programmer are already tied strong since
|this is treated as an "implementation detail".  Openness in this area could
|enable many pretty thinks:
|
| It would define an entry point for
|    - **dynamic method code loading (on demand) by an operating system**
|    - encapsulation of method time measurements
|       (automatic integration of calls to stop time before and after a
|        method call)
|    - automatic semaphore protection of methods

While I do not disagree that these things might be interesting to
standardize on, what you propose is that the tail wag the dog.
Languages do not specify the requirements of an operating system,
rather, an operating system specifies the requirements of a conforming
compiler and/or linker.  So, as operating systems become more and more
OO in the future, the operating systems specify how conforming compilers
and linkers [for various languages -- not just C++ !!!] have to do their
jobs in order to be compatible with the OO aspects of the operating
system.  For example, on today's predominately non-OO operating systems,
the operating system specifies conventions for how compiler and linkers
have to work in order to be compatible with system's SDKs, memory management,
DLLs, etc.  Likewise we are seeing similar operating system requirements
being developed on the OO aspects of compilers and linkers.

Thus attempting to specify these things on a *language* basis would be
inappropriate and doomed to failure.

I think, I've got a serious problem writing portable code using C++.  So before
I start to implement some critical C++ code, I'd like to know if some features
of current C++ compilers (e.g. SunOS, Gnu) are also subject to the
standardization process.


So here's my problem:

Many compilers allow to access the virtual tables that are constructed when
using virtual methods.  For instance __vptr may be used within C++ source
code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
address of a single virtual method dynamically at runtime (without
introducing a new derived class at the desgin step).  This technique is i.e.
a very attractive feature to implement runtime binding of methods in new
object oriented operating systems.

I've already scanned the FAQ, but I found no hint on this topic, so I decided
to post an article to this group.  I'm quite interested to know, if these
internally used variables will be supported in a future standard.  I could
imagine that compiler writers provide standard classes that allow for
manipulation of internally used virtual tables, ctors and dtors.


Thanks for your reply,

Carsten

PS.: Today I'm really scared to use internals like __vptr because otherwise
     a complex project could be for nothing in a few years even though
     implementing in a highly portable programming language.

+------------------------------------------------------------------------+
| Carsten Ditze                   | e-mail: cadi@uni-paderborn.de        |
| University of Paderborn         | or:     cadi@pbinfo.uucp             |
| FB 17 (Dept. of Math. & CS)     | or:     ...!uunet!unido!pbinfo!cadi  |
|                                 | voice:  +49 +5251 60-2074            |
| 33095 Paderborn, Germany        | fax:    +49 +5251 60-3427            |
+------------------------------------------------------------------------+

--

From: mav@gaia.cc.gatech.edu (Maurizio Vitale)
>  In article <37ufr2$1t7@news.uni-paderborn.de>
>  cadi@uni-paderborn.de (Carsten Ditze) writes:
>
> ! <question about assumption of v-table implementations>
>
>  Forget it: the vtable pointer is an implementation detail.
>  Even if a compiler uses the vtable mechanism at all (which
>  is probably the case for most/all current compilers),
>  there's no reason why the vtable pointer couldn't be
>  optimized away. While programming in C++ you whouldn't
>  even know about the existence of a vtable*, let alone
>  use it.

While I agree with the advice not to build vtable dependencies into
a program, it's worth noting an existing exception. The Microsoft
Common Object Model (COM) exposes a vtable implementation for its
interfaces. While the mechanism is "language-independent", it's clear
that it is intended to be accessible via C++ class functions. I
believe Microsoft has stated a policy that its own language products
will continue to support this vtable mechanism. If so, other PC
language vendors will also have to preserve this mechanism.

Net result: the mechanism has a lot of momentum behind it becoming
a de facto standard.
---
NeXTMail:peter.kron@corona.com
Corona Design, Inc.
P.O. Box 51022
Seattle, WA 98115-1022

In article <37ufr2$1t7@news.uni-paderborn.de> cadi@uni-paderborn.de (Carsten Ditze) writes:

   So here's my problem:

   Many compilers allow to access the virtual tables that are constructed when
   using virtual methods.  For instance __vptr may be used within C++ source
   code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
   address of a single virtual method dynamically at runtime (without
   introducing a new derived class at the desgin step).

Forget it: the vtable pointer is an implementation detail. Even if a
compiler uses the vtable mechanism at all (which is probably the case for
most/all current compilers), there's no reason why the vtable pointer
couldn't be optimized away. While programming in C++ you whouldn't
even know about the existence of a vtable*, let alone use it.

   This technique is i.e.
   a very attractive feature to implement runtime binding of methods in new
   object oriented operating systems.

thus bypassing every and all static typechecking?

   I've already scanned the FAQ, but I found no hint on this topic, so
   I decided to post an article to this group.  I'm quite interested
   to know, if these internally used variables will be supported in a
   future standard.  I could imagine that compiler writers provide
   standard classes that allow for manipulation of internally used
   virtual tables, ctors and dtors.

The metaclass protocol won't make it easily into C++, if ever.





--
    Maurizio Vitale
 _______________
|        _      |\   e-mail: mav@cc.gatech.edu     | How many times can
|  /|/| '_) | ) | |  voice:  (404) 881-6083 (home) | a man turn his head,
| | | |_(_|_|/  | |          (404) 853-9382 (work) | and pretend that he
|_______________| |                                | just doesn't see ?
 \_______________\|  fax:    (404) 853-9378        |  - Bob Dylan

In <37udjc$18b@news.uni-paderborn.de> cadi@sumba.uni-paderborn.de (Carsten Ditze) writes:


>I think, I've got a serious problem writing portable code using C++.  So before
>I start to implement some critical C++ code, I'd like to know if some features
>of current C++ compilers (e.g. SunOS, Gnu) are also subject to the
>standardization process.

>Many compilers allow to access the virtual tables that are constructed when
>using virtual methods.  For instance __vptr may be used within C++ source
>code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
>address of a single virtual method dynamically at runtime (without
>introducing a new derived class at the desgin step).  This technique is i.e.
>a very attractive feature to implement runtime binding of methods in new
>object oriented operating systems.

>I've already scanned the FAQ, but I found no hint on this topic, so I decided
>to post an article to this group.  I'm quite interested to know, if these
>internally used variables will be supported in a future standard.  I could
>imagine that compiler writers provide standard classes that allow for
>manipulation of internally used virtual tables, ctors and dtors.

The virtual function pointer is an implementation detail that will never be
part of the standard, because there is no technical reason an implementation
_has_ to even have one, and because its only use is to break (sorry, "work
around") the type features built into C++.  If you use them, you tie yourself
into a very, very specific implementation of C++.  For example, who is to say
what a given vtable pointer points to?

RTTI is just about as close as you will get to implementation details in the
C++ standard, I suspect.

-simon tooke

===============================================================================
Simon Tooke  (not speaking for) SCO Canada, Inc.         Voice:  (416) 960-4041
....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5

In <38056k$8jh@news.uni-paderborn.de> cadi@sumba.uni-paderborn.de (Carsten Ditze) writes:

>First of all I've to apologize for sending my initial request six times!  That
>was due to a failure in our news reading system.

>In article <MAV.94Oct17184859@gaia.cc.gatech.edu>, mav@gaia.cc.gatech.edu (Maurizio Vitale) writes:
>>> In article <37ufr2$1t7@news.uni-paderborn.de> cadi@uni-paderborn.de (Carsten Ditze) writes:
>>>
>  Many compilers allow to access the virtual tables that are constructed when
>  using virtual methods.  For instance __vptr may be used within C++ source
>  code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
>  address of a single virtual method dynamically at runtime (without
>  introducing a new derived class at the desgin step).
>>>
>>> Forget it: the vtable pointer is an implementation detail. Even if a
>>> compiler uses the vtable mechanism at all (which is probably the case for
>>> most/all current compilers), there's no reason why the vtable pointer
>>> couldn't be optimized away. While programming in C++ you whouldn't
>>> even know about the existence of a vtable*, let alone use it.
>>>
>   This technique is i.e.
>   a very attractive feature to implement runtime binding of methods in new
>   object oriented operating systems.

No, no, no, no.  No.  Bzzzt.  If you want to implement runtime binding of
a subset of methods, you create a pointer within the object that you wish to
do that to, and the pointer points to a polymorphic object.  Yes, there's
an extra level of indirection, but rule number one of software engineering
seems to be "new feature <==> add another level of indirection".

....

>Matt Landau told me in a mail reply, that providing these variables would

>"tie the hands of compiler writers too much (they're not free to find better,
>more efficient, or more clever implementations of virtual function dispatch, or
>to optimize it for interlanguage calling, or whatever else they might want to
>do)"

It is an implementation detail because, although it is the most obvious way
of implementing virtual functions, it is not the _only_ way.

....

>I'm still thinking to build classes for manipulating vtables, ctors, etc.  --
>hoping that older versions of CFRONT built object files can be linked with
>newer once.

Nobody is stopping you from using your hard-gained knowledge.  Just understand

1) cfront may not (chuckle) be around forever.
2) whatever compiler you get next might not link with your old object files
   anyways, since name mangling is also neither mandated nor defined by the
   emerging standard.

-simon tooke

===============================================================================
Simon Tooke  (not speaking for) SCO Canada, Inc.         Voice:  (416) 960-4041
....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5

First of all I've to apologize for sending my initial request six times!  That
was due to a failure in our news reading system.

In article <MAV.94Oct17184859@gaia.cc.gatech.edu>, mav@gaia.cc.gatech.edu (Maurizio Vitale) writes:
>> In article <37ufr2$1t7@news.uni-paderborn.de> cadi@uni-paderborn.de (Carsten Ditze) writes:
>>
  Many compilers allow to access the virtual tables that are constructed when
  using virtual methods.  For instance __vptr may be used within C++ source
  code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
  address of a single virtual method dynamically at runtime (without
  introducing a new derived class at the desgin step).
>>
>> Forget it: the vtable pointer is an implementation detail. Even if a
>> compiler uses the vtable mechanism at all (which is probably the case for
>> most/all current compilers), there's no reason why the vtable pointer
>> couldn't be optimized away. While programming in C++ you whouldn't
>> even know about the existence of a vtable*, let alone use it.
>>
   This technique is i.e.
   a very attractive feature to implement runtime binding of methods in new
   object oriented operating systems.
>>
>> thus bypassing every and all static typechecking?
>>

Yes, indeed all those pretty things would be bypassed.  Today it'd be in the
responsibility of the programmer (likewise when using the cast - operator).

Matt Landau told me in a mail reply, that providing these variables would

"tie the hands of compiler writers too much (they're not free to find better,
more efficient, or more clever implementations of virtual function dispatch, or
to optimize it for interlanguage calling, or whatever else they might want to
do)"

Today the hands of operating system programmer are already tied strong since
this is treated as an "implementation detail".  Openness in this area could
enable many pretty thinks:

 It would define an entry point for
    - **dynamic method code loading (on demand) by an operating system**
    - encapsulation of method time measurements
       (automatic integration of calls to stop time before and after a
        method call)
    - automatic semaphore protection of methods

I'd propose to consider these aspects regarding future syntax/semantics in C++.
There are already some nice oo operating systems that relied on the
availability of vtables, ctors, etc.  Operating systems have often been cited
to be a very suited example for an oo design.  That is definitely correct, but
simply rejecting the features mentioned above prohibits an oo implementation of
fundamental OS technics.  Although many reasons recommend C++ as an design
language for OSs, the one reason mentioned could be the reason not to use it.

I'm still thinking to build classes for manipulating vtables, ctors, etc.  --
hoping that older versions of CFRONT built object files can be linked with
newer once.


Carsten
--

+------------------------------------------------------------------------+
| Carsten Ditze                   | e-mail: cadi@uni-paderborn.de        |
| University of Paderborn         | or:     cadi@pbinfo.uucp             |
| FB 17 (Dept. of Math. & CS)     | or:     ...!uunet!unido!pbinfo!cadi  |
|                                 | voice:  +49 +5251 60-2074            |
| 33095 Paderborn, Germany        | fax:    +49 +5251 60-3427            |
+------------------------------------------------------------------------+

peter.kron@corona.com writes:
>
> From: mav@gaia.cc.gatech.edu (Maurizio Vitale)
> >  In article <37ufr2$1t7@news.uni-paderborn.de>
> >  cadi@uni-paderborn.de (Carsten Ditze) writes:
> >
> > ! <question about assumption of v-table implementations>
> >
> >  Forget it: the vtable pointer is an implementation detail.
> >  Even if a compiler uses the vtable mechanism at all (which
> >  is probably the case for most/all current compilers),
> >  there's no reason why the vtable pointer couldn't be
> >  optimized away. While programming in C++ you whouldn't
> >  even know about the existence of a vtable*, let alone
> >  use it.
>
> While I agree with the advice not to build vtable dependencies into
> a program, it's worth noting an existing exception. The Microsoft
> Common Object Model (COM) exposes a vtable implementation for its
> interfaces. While the mechanism is "language-independent", it's clear
> that it is intended to be accessible via C++ class functions. I
> believe Microsoft has stated a policy that its own language products
> will continue to support this vtable mechanism. If so, other PC
> language vendors will also have to preserve this mechanism.
>
> Net result: the mechanism has a lot of momentum behind it becoming
> a de facto standard.

Aha.  That would explain the intention behind that recent MS patent of a
vtable implementation.

-Luddy Harrison
harrison@csrd.uiuc.edu

I think, I've got a serious problem writing portable code using C++.  So before
I start to implement some critical C++ code, I'd like to know if some features
of current C++ compilers (e.g. SunOS, Gnu) are also subject to the
standardization process.


So here's my problem:

Many compilers allow to access the virtual tables that are constructed when
using virtual methods.  For instance __vptr may be used within C++ source code
(in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code address
of a single virtual method dynamically at runtime.  This technique is i.e. a
very attractive feature to implement runtime binding of methods in new object
oriented operating systems.


I'm quite interested to know, if these internally used variables will be
supported in a future standard.  I could imagine that compiler writers provide
standard classes that allow for manipulation of internally used virtual tables,
ctors and dtors.


Thanks for your reply,

Carsten

PS.: Today I'm really scared to use internals like __vptr because otherwise
     a complex project could be for nothing in a few years even though
     implementing in a highly portable programming language.

+------------------------------------------------------------------------+
| Carsten Ditze                   | e-mail: cadi@uni-paderborn.de        |
| University of Paderborn         | or:     cadi@pbinfo.uucp             |
| FB 17 (Dept. of Math. & CS)     | or:     ...!uunet!unido!pbinfo!cadi  |
|                                 | voice:  +49 +5251 60-2074            |
| 33095 Paderborn, Germany        | fax:    +49 +5251 60-3427            |
+------------------------------------------------------------------------+

I think, I've got a serious problem writing portable code using C++.  So before
I start to implement some critical C++ code, I'd like to know if some features
of current C++ compilers (e.g. SunOS, Gnu) are also subject to the
standardization process.


So here's my problem:

Many compilers allow to access the virtual tables that are constructed when
using virtual methods.  For instance __vptr may be used within C++ source
code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
address of a single virtual method dynamically at runtime (without
introducing a new derived class at the desgin step).  This technique is i.e.
a very attractive feature to implement runtime binding of methods in new
object oriented operating systems.

I've already scanned the FAQ, but I found no hint on this topic, so I decided
to post an article to this group.  I'm quite interested to know, if these
internally used variables will be supported in a future standard.  I could
imagine that compiler writers provide standard classes that allow for
manipulation of internally used virtual tables, ctors and dtors.


Thanks for your reply,

Carsten

PS.: Today I'm really scared to use internals like __vptr because otherwise
     a complex project could be for nothing in a few years even though
     implementing in a highly portable programming language.

+------------------------------------------------------------------------+
| Carsten Ditze                   | e-mail: cadi@uni-paderborn.de        |
| University of Paderborn         | or:     cadi@pbinfo.uucp             |
| FB 17 (Dept. of Math. & CS)     | or:     ...!uunet!unido!pbinfo!cadi  |
|                                 | voice:  +49 +5251 60-2074            |
| 33095 Paderborn, Germany        | fax:    +49 +5251 60-3427            |
+------------------------------------------------------------------------+

I think, I've got a serious problem writing portable code using C++.  So before
I start to implement some critical C++ code, I'd like to know if some features
of current C++ compilers (e.g. SunOS, Gnu) are also subject to the
standardization process.


So here's my problem:

Many compilers allow to access the virtual tables that are constructed when
using virtual methods.  For instance __vptr may be used within C++ source
code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
address of a single virtual method dynamically at runtime (without
introducing a new derived class at the desgin step).  This technique is i.e.
a very attractive feature to implement runtime binding of methods in new
object oriented operating systems.

I've already scanned the FAQ, but I found no hint on this topic, so I decided
to post an article to this group.  I'm quite interested to know, if these
internally used variables will be supported in a future standard.  I could
imagine that compiler writers provide standard classes that allow for
manipulation of internally used virtual tables, ctors and dtors.


Thanks for your reply,

Carsten

PS.: Today I'm really scared to use internals like __vptr because otherwise
     a complex project could be for nothing in a few years even though
     implementing in a highly portable programming language.

+------------------------------------------------------------------------+
| Carsten Ditze                   | e-mail: cadi@uni-paderborn.de        |
| University of Paderborn         | or:     cadi@pbinfo.uucp             |
| FB 17 (Dept. of Math. & CS)     | or:     ...!uunet!unido!pbinfo!cadi  |
|                                 | voice:  +49 +5251 60-2074            |
| 33095 Paderborn, Germany        | fax:    +49 +5251 60-3427            |
+------------------------------------------------------------------------+

I think, I've got a serious problem writing portable code using C++.  So before
I start to implement some critical C++ code, I'd like to know if some features
of current C++ compilers (e.g. SunOS, Gnu) are also subject to the
standardization process.


So here's my problem:

Many compilers allow to access the virtual tables that are constructed when
using virtual methods.  For instance __vptr may be used within C++ source
code (in cfront of the SunOS CC 3.0 compiler) to instantiate/modify the code
address of a single virtual method dynamically at runtime (without
introducing a new derived class at the desgin step).  This technique is i.e.
a very attractive feature to implement runtime binding of methods in new
object oriented operating systems.

I've already scanned the FAQ, but I found no hint on this topic, so I decided
to post an article to this group.  I'm quite interested to know, if these
internally used variables will be supported in a future standard.  I could
imagine that compiler writers provide standard classes that allow for
manipulation of internally used virtual tables, ctors and dtors.


Thanks for your reply,

Carsten

PS.: Today I'm really scared to use internals like __vptr because otherwise
     a complex project could be for nothing in a few years even though
     implementing in a highly portable programming language.

--

+------------------------------------------------------------------------+
| Carsten Ditze                   | e-mail: cadi@uni-paderborn.de        |
| University of Paderborn         | or:     cadi@pbinfo.uucp             |
| FB 17 (Dept. of Math. & CS)     | or:     ...!uunet!unido!pbinfo!cadi  |
|                                 | voice:  +49 +5251 60-2074            |
| 33095 Paderborn, Germany        | fax:    +49 +5251 60-3427            |
+------------------------------------------------------------------------+