In article <3o3mnu$7ra@silver.jba.co.uk>,
Jonathan de Boyne Pollard <JdeBP%utopium@jba.co.uk> wrote:
>scherrey@proteus-tech.com wrote:
>Two DTS C++ compilers *can* share C++ classes with each other.  As I have
>also mentioned before, I've done this so I *know* that it works.
>

This is a nice feature, however do I want to pay the price (licencing fees,
etc).

>Now all that you need to do is persuade your C++ compiler vendor to put
>DTS C++ ability in their product.  Two such vendors already have.

Who says that DTS is the *best* solution.  Just because a number of vendors
have doesn't make it good.  I'm sure few people would want to standardise
on the Microsloth binary format - with all its inherant x86 based limitations.

Different binary formats are not a problem if develops a tool to convert
between them.  Many of the tools needed already exist as part of the GNU
project (the binutils stuff).

Regards,
 Rohan

--
----------------------------------------------------------------------------
rjl@iassf.easams.com.au | All quotes can be attributed to my automated quote
Rohan Lenard            | writing tool.  Yours for just $19.95; and if you
+61-2-367-4555          | call now you'll get a free set of steak knives ...

Rohan LENARD (rjl@f111.iassf.easams.com.au) wrote:
: In article <3o3mnu$7ra@silver.jba.co.uk>,
: Jonathan de Boyne Pollard <JdeBP%utopium@jba.co.uk> wrote:
: >scherrey@proteus-tech.com wrote:
: >Two DTS C++ compilers *can* share C++ classes with each other.  As I have
: >also mentioned before, I've done this so I *know* that it works.

: This is a nice feature, however do I want to pay the price (licencing fees,
: etc).

Licencing fees ?  What licencing fees ?  As long as your platform supports
SOM (and it's available for AIX, Intel OS/2, PowerPC OS/2, DOS+Windows, and
AS/400 AFAIAA, and probably others too), you're laughing.  The only investment
as far as I am aware is the initial investment in buying the compiler ...

: >Now all that you need to do is persuade your C++ compiler vendor to put
: >DTS C++ ability in their product.  Two such vendors already have.
:
: Who says that DTS is the *best* solution.

Nobody, but it *does* solve the problems that people keep coming up with
here, such as "why can't we standardise object binary compatibility across
compilers?" or (rephrased) "why can't I put C++ classes into a DLL and
distribute them as binaries?".  DTS C++ compilers *have* a standardised
binary interface, and you can write classes and ship them as DLLs.  They're
here, now, and they work.

:                             I'm sure few people would want to standardise
: on the Microsloth binary format - with all its inherant x86 based limitations.

Microsoft ?  Who said anything about Microsoft ?  Microsoft has a severe
case of Not Invented Here when it comes to the C++ language anyway ...

As to your swipe at the Intel architechture, you are completely missing the
point.  When you want binary standards, you *must* tie yourself to the
processor architecture.  You cannot do otherwise.  There's no way that you
can standardise method table pointers (for example) at a binary level without
specifying the size and type of the actual pointer.

Doing this for every platform that has C++ implementations is a lot of work,
and quite rightly the ISO people aren't going to do it.  But the platform
people *are* doing it *already*, with schemes like SOM and DirectToSOM C++
compilers.  Which is why anyone who wants cross-compiler exchange of C++
classes at a binary level should be looking very seriously at DTS C++.

: Different binary formats are not a problem if develops a tool to convert
: between them.

Not when trying to use classes written in one C++ compiler from another C++
compiler.

I tell you what.  Why don't you sit down with two ordinary C++ compilers
and actually *try* this.  I bashed my head against that particular brick
wall for years.  It just cannot be done.  DirectToSOM C++ compilers are
a godsend in this respect, because it's the first time in my experience
that C++ compilers from different vendors have been able to share C++
classes without access to implementation source.

FWIW - I started this thread by asking (demanding?) an answer to this issue.
Obviously there is, indeed, more to it than compiler vendors agreeing on name-
mangling standards and the solution will be no small feat. Meanwhile, there *are*
some alternatives that have been mentioned (ex. SOM) so we're not completely
dead in the water.
 I'd just like to thank the people who have responded here and via email
and appreciate being clued-in to the scope of the issues involved. There have
been several well thought out replies and hopefully more people than just I have
gained some valuable knowledge.

 thanx all & later,

  Ben Scherrey
  Proteus Technologies, Inc.

scherrey@proteus-tech.com wrote:
:     Here's an example of what I want to do. Say I'm developing a code
: library or DLL for OS/2 using Borland's C++ compiler. I want to release
: the product as a binary DLL with header files that contain the class and
: method definitions needed to link to the DLL. I'm making entire classes and
: their methods available to be called, not just C functions. My understanding
: is that extern "C" { } wrapped around a class definition doesn't work
: because overloading and the implied this argument aren't supported.

It's far worse than that.  Each compiler (as was said only one message
previously) uses a different internal object layout, different calling
conventions, and different implementations of virtual inheritance and methods.

And as *I* said, a few messages back, this problem is actually *solved* by
the DirectToSOM C++ compilers, which share a common binary interface : SOM.

Two DTS C++ compilers *can* share C++ classes with each other.  As I have
also mentioned before, I've done this so I *know* that it works.

Now all that you need to do is persuade your C++ compiler vendor to put
DTS C++ ability in their product.  Two such vendors already have.