Tom> I realize that my original posting was very unclear.
Tom> What I tried to say is that the memory layout of objects
Tom> could be speciefied in as a mapping between C++ classes and
Tom> C structs. As an example:

It's rather hard to do that, because doing so would force a
particular choice of implementation, and there are many
possible optimizations of class layout that some vendors
might want to use and others might not.

As a simple example, consider a pointer to member.  Suppose,
for example, that we have

    class Foo { /* ... */ };

    class Bar {
    // ...
       int (Foo::*fp)(int, int);
    };

How should the compiler represent Bar::fp?  Well, it knows that
fp must point to a member of class Foo that is a function that takes
two int arguments and returns an int result.

What if there are only two such functions?  Then fp might reasonably
be stored as a single byte, rather than as a more conventional
pointer.  Does it make sense that every implementation be required
to implement that optimization in exactly the same way?

Even if you say that it does make sense, I might argue that it
could be impossible.  Suppose that a vendor has come up with such
an optimization and patented it.  Then a standard could not require
everyone to implement it.  But neither could it legitimatelly
require the vendor who invented the optimization to stop using
it.  Can you imagine the flap that would ensue?

Then there is the question of vtable layout.  Would you mandate
a single data structure there too?  If so, what would you do about the
fact that there are already two different data structures for vtables
that are, as far as I know, both widely used?

Tom> The memory layouts of the C structs are specified
Tom> by the C implementation of the platform.

Saying `the C implementation' implies that there is only one.
What do you do with two different, incompatible C compilers
on the same machine (as I had at one point)?

Tom> Please note the practical side of this: C libraries
Tom> compiled with different compilers can call each other.

Not in general.

Tom> This is not the case with C++.

Nor is it always the case with C.

Tom> If someone (maybe Posix, maybe the C++ standards
Tom> committee, ...) would specify the memory layout
Tom> mapping from C++ to C, then C++ libraries compiled
Tom> with different compilers could call each other.

No, that does not follow.  There is lots more that would have
to be specified, such as the machine-level calling sequence,
including all permissible optimizations, the handshake to
the exception-handling library, which standard-library
functions have special calling sequences for optimization
purposes, and so on.

Tom> Today the OS vendors all have their C++ compilers,
Tom> of which almost none implement the ISO/ANSI standard C++.
Tom> We also have some multi-platform compilers (egcs,
Tom> KAI C++, ...) which does a fair job implementing
Tom> the standard.  But if you want to use libraries you
Tom> are almost always forced to use the C++ compiler
Tom> sold by the OS vendor. This is not good.
Tom> As buyers of C++ compilers it would be much
Tom> better if there was a real competition
Tom> between different compiler vendors.

There I think we agree.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tom =?iso-8859-1?Q?Bj=F6rkholm?= <tom.bjorkholm@ebc.ericsson.se> writes:

>Steve Clamage wrote:
>>
>> Tom =?iso-8859-1?Q?Bj=F6rkholm?= <tom.bjorkholm@ebc.ericsson.se> writes:
>>
>> >There are 2 main things that need to be addressed in order to
>> >be able to mix object code from 2 different C++ compilers.
>>
>> >1) Name mangling. I see no reason why this could not be addressed
>> >   in the standard.
>> >2) Memory layout of objects. This is to some extent platform
>> >   dependant, but the standard could get around the this problem
>> >   by specifying the memory layout as C structs. The mapping between
>> >   C structs and real memory layout is already solved on all
>> >   platforms (as you have already mentioned).
>>
>>
>> Regarding your #2, what does C struct layout mean for a class
>> with multiple inheritance, virtual functions, and virtual
>> base classes? These things do not exist in C, and there is no
>> C definition for their layout.
>>

>I realize that my original posting was very unclear.
>What I tried to say is that the memory layout of objects
>could be speciefied in as a mapping between C++ classes and
>C structs. As an example:

Andy Koenig has already pointed out problems with requiring the
same object layout for all implementations.

But it appears you still think that object layout is the only
area of incompatibility that matters. Off the top of my head
I listed in my article quite a few others you haven't addressed,
and several other people listed still more areas of incompatibility.

Please notice that even in C you don't have assured compatibility
of implementations. It has been common on many platforms to have
incompatible C compilers, each fully compliant with the C standard.
That is because the C standard does not try to mandate a particular
implementation. Where C implementations are compatible, it is because
either the platform has a standard ABI which the C implementers
choose to follow, or there is a C implementer so dominant that others
feel constrained to match those implementation details.

The only way for the C++ standard to assure compatibility of systems
would be to mandate all the low-level details of the implementation.
If, as you suggest, we ignore the details already covered by C, the
additional degrees of freedom listed in other articles in this thread
are daunting enough. It would force every implementation to use the
same techniques, independent of whether those techniques made sense
for the particular platform, and independent of whether those
implementation techniques violated the ABI for the platform.

You would wind up with universally inefficient C++ implementations,
some of which would be incompatible with object code from other
languages on the same platform. Maybe you think this degree of
sacrifice is worth the benefit of being assured of mixing code
from any two C++ compilers on the same platform. I doubt you
would find many people to agree with you.

As I stated before, the place to assure compatibility of compilers
is at the platform level. After all, I don't think you insist on
being able to use object code for Intel/Windows on SPARC/Solaris,
for example. That point alone demonstrates that the C++ standard is
too high a level for such a specification.

It is common for those who set the standards for a platform to
publish an ABI for programming languages. It is in the interests of
compiler implementers to follow that ABI. If there is no ABI for the
platform, maybe whoever controls the platform could be shamed into
publishing one.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7cgp71$h2h$1@engnews1.eng.sun.com>,
Steve Clamage <Stephen.Clamage@eng.sun.com> wrote:
> Where C implementations are compatible, it is because
>either the platform has a standard ABI which the C implementers
>choose to follow, or there is a C implementer so dominant that others
>feel constrained to match those implementation details.

Or simply because the mapping from C to hardware is so obvious that
everyone happens to use the same thing.  C is a pretty low level language,
so this is quite common.  And C also specifies some low-level features,
such as the representation of strings (zero-terminated array of char).
C++, on the other hand, is a relatively complex, higher-level language
where there are many different possible approaches.  And it's still too
soon to know which approaches are best -- we need more experience with
high-performance implementations.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <XtSG2.223$p4.63180@burlma1-snr2>, Barry Margolin
<barmar@bbnplanet.com> writes
>Or simply because the mapping from C to hardware is so obvious that
>everyone happens to use the same thing.

But that is not actually true, hence the existence of libraries shipped
as shrouded source code.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <XtSG2.223$p4.63180@burlma1-snr2>,
Barry Margolin  <barmar@bbnplanet.com> wrote:

> Or simply because the mapping from C to hardware is so obvious that
> everyone happens to use the same thing.

But they don't!  For a number of years, I used a computer that had
two mutually incompatible C compilers on it.  For that matter, I
recall a C compiler for the PC that offered two different calling
sequences, too.  You had to compile entirely with one or with the
other.  (If I remember correctly, one of them was compatible with
Pascal, and the other was faster)
--
    Andrew Koenig
    ark@research.att.com
    http://www.research.att.com/info/ark



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <F8n7CI.Bqu@research.att.com>, Andrew Koenig wrote:
>
>In article <XtSG2.223$p4.63180@burlma1-snr2>,
>Barry Margolin  <barmar@bbnplanet.com> wrote:
>
>> Or simply because the mapping from C to hardware is so obvious that
>> everyone happens to use the same thing.
>
>But they don't!  For a number of years, I used a computer that had
>two mutually incompatible C compilers on it.  For that matter, I
>recall a C compiler for the PC that offered two different calling
>sequences, too.  You had to compile entirely with one or with the
>other.  (If I remember correctly, one of them was compatible with
>Pascal, and the other was faster)

In both   C and C++  current IRIX  compilers can  switch between three
different incompatible compilation  modes,  one of them  even changing
the size of long and pointers from 32 to 64 bits.

  OG.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

ark@research.att.com (Andrew Koenig) writes:
> In article <XtSG2.223$p4.63180@burlma1-snr2>,
> Barry Margolin  <barmar@bbnplanet.com> wrote:
> > Or simply because the mapping from C to hardware is so obvious that
> > everyone happens to use the same thing.
> But they don't!  For a number of years, I used a computer that had
> two mutually incompatible C compilers on it.  For that matter, I
> recall a C compiler for the PC that offered two different calling
> sequences, too.  You had to compile entirely with one or with the
> other.  (If I remember correctly, one of them was compatible with
> Pascal, and the other was faster)

As far as I recall from my DOS days, both Borland and Watcom's C
compilers let the programmer select one of several calling
conventions. I don't remember how many alternatives Borland has, but
Watcom has more than the two you mentioned, plus the ability to "roll
your own" calling convention, which is incredibly useful when
interfacing with assembly language since you can trim away unneeded
overhead.

Both of these compilers allow the programmer to specify the calling
convention in the function prototype or definition, so you *can* mix
calling sequences. For instance, you can write a C module where a few
functions use the Pascal convention and the other - generally static -
functions use the C convention, and then link that module with a
Pascal program. (everyone, say 'extern "C"'!)

The traditional Pascal calling convention on the PC (as established by
TurboPascal) is left to right, callee restores stack, whereas C
compilers generally use right to left, caller restores stack. The
Pascal convention is actually faster in the sense that most of the
calling sequence is within the callee, which makes it possible to
optimize away irrelevant parts (you can't do that in the caller, since
you don't always know what the callee looks like when you compile the
caller).

The downside of the Pascal convention is that it makes varadic
functions difficult to implement, since the callee needs to know the
exact number and size of the arguments which were pushed on the stack
in order to restore the stack pointer before returning to the caller.
This is not a problem in Pascal since the language does not allow
varadic functions; write and writeln are exceptions which are usually
special-cased by the compiler.

I once had the displeasure of disassembling a TurboPascal program (a
failed trojan attack, the intended effect of which I was asked to
document), and I seem to remember that the writeln calls were compiled
to a sequence of calls to specialized procedures, one for each data
type. I'd have to dig up my report - assuming it's still lying around
somewhere - to confirm that.

DES
--
Dag-Erling Smorgrav - des@ifi.uio.no


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <F8n7CI.Bqu@research.att.com>, ark@research.att.com says...

[ ... ]

> But they don't!  For a number of years, I used a computer that had
> two mutually incompatible C compilers on it.  For that matter, I
> recall a C compiler for the PC that offered two different calling
> sequences, too.  You had to compile entirely with one or with the
> other.  (If I remember correctly, one of them was compatible with
> Pascal, and the other was faster)

Actually, most current C++ compilers on the PC offer at least two
different calling conventions, and many have more than that -- MS (for
one example) supports at least three.  Inprise/Borland compilers offer
three that are similar, and the last time I looked at least one more
besides.

Of these, only one is really particularly similar between the two,
primarily because it's the one that MS defines for calling Win32 OS
functions, which (of course) both use on a regular basis.

I suspect on machines that have more or less implicit support for an
efficient calling convention (e.g. the SPARC) less variation is
likely.  In the case of PCs, an extremely competitive market and a CPU
that makes efficient function calls difficult combine to produce lots
of variations in an attempt at producing as good of code as possible
in a difficult situation.

All of which does little more than highlight the level of difficulty
that would be involved in attempting to standardize any of this except
on a platform-by-platform basis.  Even on a particular piece of
hardware, different OSes typically have enough different requirements
that different calling conventions might make sense -- e.g. Win32 has
quite a few functions that take a relatively large number of
parameters, so MS has to deal with that on a regular basis.  Given the
smaller number of parameters (on average) involved in implementing
UNIX, it probably makes sense for Solaris on the x86 to use a
different calling convention.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <F8n7CI.Bqu@research.att.com>,
  ark@research.att.com (Andrew Koenig) wrote:
>
> In article <XtSG2.223$p4.63180@burlma1-snr2>,
> Barry Margolin  <barmar@bbnplanet.com> wrote:
>
> > Or simply because the mapping from C to hardware is so obvious that
> > everyone happens to use the same thing.
>
> But they don't!

Mr. Koenig, you took this sentence out of context. Barry Margolin didn't
say that this happens on all C compilers.

In article <7cgp71$h2h$1@engnews1.eng.sun.com>,
Steve Clamage <Stephen.Clamage@eng.sun.com> wrote:
> Where C implementations are compatible, it is because
> either the platform has a standard ABI which the C implementers
> choose to follow, or there is a C implementer so dominant that others
> feel constrained to match those implementation details.

And Barry Margolin replied:
> Or simply because the mapping from C to hardware is so obvious that
> everyone happens to use the same thing.  C is a pretty low level language,
> so this is quite common.

Certainly he didn't intend to imply that it was universal!

> For a number of years, I used a computer that had
> two mutually incompatible C compilers on it.
[...]
Your counter-example doesn't prove that it never works this way.
Presumably Barry Margolin used a different platform than you did,
perhaps one where the mapping was more obvious.

For instance, the VAX has register conventions and assembly
language instructions designed to make argument passing painless
and easy. In such an environment it would be rare to see a
compiler (C or otherwise) that deliberately violated the convention.
If someone DID go out of their way to accomplish this, it wouldn't
be non-compliant, just pointless.

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7cp3np$v5t$1@nnrp2.dejanews.com>,
formerly AllanW@my-dejanews.com <allan_w@my-dejanews.com> <allan_w@my-dejanews.com> wrote:

> And Barry Margolin replied:
> > Or simply because the mapping from C to hardware is so obvious that
> > everyone happens to use the same thing.  C is a pretty low level language,
> > so this is quite common.

> Certainly he didn't intend to imply that it was universal!

But I'm not even sure it's all that common.

Certainly there were incompatible C implementations on PC platforms
a number of years ago, and I would be surprised to find that there
is now only a single universal set of C calling conventions in use.

> Your counter-example doesn't prove that it never works this way.
> Presumably Barry Margolin used a different platform than you did,
> perhaps one where the mapping was more obvious.

I didn't say that it never works that way, only that it doesn't
always work that way.

> For instance, the VAX has register conventions and assembly
> language instructions designed to make argument passing painless
> and easy. In such an environment it would be rare to see a
> compiler (C or otherwise) that deliberately violated the convention.
> If someone DID go out of their way to accomplish this, it wouldn't
> be non-compliant, just pointless.

Oh well, I once used a VAX that had a C compiler that deliberately
avoided the hardware subroutine-call instructions.  The reason is
that they're horrendously slow, and an appropriate hand-crafted
calling sequence can run *much* more quickly over a wide range
of applications.
--
    Andrew Koenig
    ark@research.att.com
    http://www.research.att.com/info/ark



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> Tom =?iso-8859-1?Q?Bj=F6rkholm?= <tom.bjorkholm@ebc.ericsson.se> writes:
>
> >There are 2 main things that need to be addressed in order to
> >be able to mix object code from 2 different C++ compilers.
>
> >1) Name mangling. I see no reason why this could not be addressed
> >   in the standard.
> >2) Memory layout of objects. This is to some extent platform
> >   dependant, but the standard could get around the this problem
> >   by specifying the memory layout as C structs. The mapping between
> >   C structs and real memory layout is already solved on all
> >   platforms (as you have already mentioned).
>
>
> Regarding your #2, what does C struct layout mean for a class
> with multiple inheritance, virtual functions, and virtual
> base classes? These things do not exist in C, and there is no
> C definition for their layout.
>

I realize that my original posting was very unclear.
What I tried to say is that the memory layout of objects
could be speciefied in as a mapping between C++ classes and
C structs. As an example:

---------------------

// C++
class foo {
public:
  foo();
  virtual ~foo();
private:
  int a;
};

/* would as en example have the same memory layout
 * as these C structs */

struct foo_vtbl {
  void (*__dt)();
};

struct foo {
  struct foo_vtbl *__vtbl;
  int a;
};


// and this C++:

class bar : public foo{
public:
  bar();
  ~bar();
  virtual double func(int);
private:
  double b;
};

/* would as en example have the same memory layout
 * as these C structs */

struct bar_vtbl {
  struct foo_vtbl base;
  double (*func)(int);
};

struct bar {
  union { /* the 2 __vtbl ptrs share the same location */
    struct bar_vtbl *__vtbl;
    struct foo base;
  } base;
  double b;
};

--------------------------------

I am not claiming that this is a good memory
layout. I am only demonstrating that the memory layout
of C++ objects can be described as C structs.

The memory layouts of the C structs are specified
by the C implementation of the platform.

Please note the practical side of this: C libraries
compiled with different compilers can call each other.
This is not the case with C++.

If someone (maybe Posix, maybe the C++ standards
committee, ...) would specify the memory layout
mapping from C++ to C, then C++ libraries compiled
with different compilers could call each other.

Today the OS vendors all have their C++ compilers,
of which almost none implement the ISO/ANSI standard C++.
We also have some multi-platform compilers (egcs,
KAI C++, ...) which does a fair job implementing
the standard.  But if you want to use libraries you
are almost always forced to use the C++ compiler
sold by the OS vendor. This is not good.
As buyers of C++ compilers it would be much
better if there was a real competition
between different compiler vendors.

Best Regards,

/Tom

--------------------------------------------------------------------------
Tom Bjorkholm            Ericsson Telecom AB
Sr. Software Designer    Nacka Strand, 131 89 Stockholm, Sweden
C++ and UN*X             phone: +46-8-4221348, fax:+46-8-4222080


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]