<James.Kanze@dresdner-bank.com> wrote:
>In article <7c2h4a$mom$1@nnrp1.dejanews.com>,
>  ittay@my-dejanews.com wrote:
>
>> the company i work for supports 4 different unix platforms & win nt.
>> means that all of our code needs to be compiled on all 5 platforms.
>> ...
>> the assumption is that by using native compilers we gain more efficient
>> executables. is this true?...
>
>With regards to speed, it varies.  But unless your work is really
>numbers crunching, I doubt that the difference will be enough to
>matter.

Something to note, also, is that "gcc" as such is likely to be a poor
choice.  The Egcs compiler suite, now at version 1.1.2, is its successor.
It has major improvements over gcc-2.8.x, particularly in C++ support,
and in optimization -- although 1.2 (as represented by snapshot
versions available now) will do substantially better.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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              ]

James Kuyper <kuyper@wizard.net> wrote:
> I don't see how it can be said to "run on almost anything" if it doesn't
> run one one of the world's most widely used platforms. I don't develop
> code for Windows, but many people do. I find it puzzling that KAI does
> target other products for the Windows market, but not C++.

Its in the works.

-Kevin

[ Moderator's note: normally, articles about individual implementations   ]
[ are not considered to be on-topic for comp.std.c++.  However, in this   ]
[ case the article has a bearing on the question     ]
[            ]
[      Is the standard well defined and compilers sufficiently    ]
[      well conforming, that it is worthwhile for us to try to write   ]
[      standard-conforming code, and to port it between different   ]
[      compilers, thus getting efficiency benefits?     ]
[      Or in practice would it actually be better for     ]
[      us to just stick with a single compiler?      ]
[              ]
[ which I read as being implicit in the original article that started   ]
[ this thread.  On a broader scale, the articles in this thread are       ]
[ relevant to the question        ]
[           ]
[      Which is really best -- standardization via specification and   ]
[      multiple implementations, or just picking a single implementation  ]
[      and porting it?         ]
[           ]
[ It would be nice if any followups in this thread could head back   ]
[ towards these standards-related topics rather than getting into   ]
[ too much detail about the nitty gritty of particular implementations.   ]
[           ]
[ -moderator (fjh).        ]

--
----------->  Kevin Jacobs  <-----------|------->  (216) 778-8487  <--------
S.A.G.E. Project Technical Coordinator  | Department of Epidemiology
  & System Administrator                |   & Biostatistics
Internet E-mail: jacobs@darwin.cwru.edu | Case Western Reserve University
----------------------------------------------------------------------------
---
[ 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              ]

ittay@my-dejanews.com writes:

> the assumption is that by using native compilers we gain more efficient
> executables. is this true?

There are certainly compilers that produce code better than g++. There
are also compilers that produce worse code. The specific relationship
very much depends on your application, and the specific compilers you
compare.

> also, we use external libraries which sometime force us to compile
> the whole module with the compiler the suppliers of the libraries
> used. is there any way to circumvent that?

No. You typically cannot combine code written for different C++
compilers. With some luck, it might be possible to write C wrappers
around the external C++ library, and then call these wrappers from you
C++ code. Combining two C++ runtime systems into one executable might
be difficult, though.

Regards,
Martin
---
[ 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              ]

ittay@my-dejanews.com wrote:
>
> the company i work for supports 4 different unix platforms & win nt. this
> means that all of our code needs to be compiled on all 5 platforms. right now
> we're using the native compilers that come with each platform, so we have to
> write code that's compatible with each compiler. this results in a lot of
> compilation / linking problems and also forces us to use only the most common
> c++ features (we don't have dynamic_cast, for example).

I agree. We have been there. We have had the same trouble.


>  if we use one uniform compiler
> (the only one i know of is gcc, if you know of something else please tell me)

We are using KAI C++. See http://www.kai.com. We are using it on 3 unix
platforms
and we are really pleased. We get the latest C++ features and identical
C++ code
(save for some OS-specific include files).

> will we have slower modules?

We got faster modules. The KAI C++ optimizer is really good.
(KAI C++ actually uses the OS native C compiler as backend,
 so the low level optimization depends on the C compiler.
 KAI has a good high level optimizer, optimizing the C++ constructs.)

> also, we use external libraries which sometime
> force us to compile the whole module with the compiler the suppliers of the
> libraries used. is there any way to circumvent that?

Not really. This is a pain.
We only use external libraries if they are C libraries or if we can buy
the source code.

Actually there is a way to circumvent the problem, we have used
it for one library:
  Use "nm" on the library to see the symbols in the different
  .o modules. Then replace all modules that have references outside
  the library (calls the std c++ library, or is called from code outside
  the library) with modules that you write yourself in C.
  The modules you write should of course implement the same inteface,
  but act as a glue between the calling convetions and name manglings.
  I do not recommend this approach, it involves a lot of guessing.

It is a shame that the C++ standard didn't address the issue of
object code interoperability between different C++-compilers on
the same target OS/hardware.

/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              ]

ittay@my-dejanews.com wrote:
: the assumption is that by using native compilers we gain more efficient
: executables. is this true? what i mean is, if we use one uniform compiler
: (the only one i know of is gcc, if you know of something else please tell me)

KAI runs on almost anything.

: will we have slower modules?

First you have to make sure it really matters. Most of the time
it doesn't or other problems (correctness for example) far
outweight performance problems.

: also, we use external libraries which sometime
: force us to compile the whole module with the compiler the suppliers of the
: libraries used. is there any way to circumvent that?

Not really. If the interface you need from the library is really
small, you can try to reexport it via extern "C" functions.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ 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 Bj=F6rkholm wrote:
...
> It is a shame that the C++ standard didn't address the issue of
> object code interoperability between different C++-compilers on
> the same target OS/hardware.

That's not it's responsibility. You need a different standard for each
platform, and the same standard for many different languages, not just
C++. That standard must specify any of the things that the C++ standard
allows to be implementation-specific, which affect object code
interfaces, such as padding of structures, sizes of data types, name
mangling, etc.
---
[ 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              ]

Oleg Zabluda wrote:
>
> ittay@my-dejanews.com wrote:
> : the assumption is that by using native compilers we gain more efficient
> : executables. is this true? what i mean is, if we use one uniform compiler
> : (the only one i know of is gcc, if you know of something else please tell me)
>
> KAI runs on almost anything.

True, but if you are going to put all your eggs in one basket, you
would be prudent to make sure it's a good basket.

This is true for KAI or gcc.

With multiple compilers, you have reduced the cost to make another port.

My experience with KAI is over a year old now, but then I found that
while it supported ISO C++ fine, it didn't have *any* support for older
C++ code, necessitating a large cost in converting old cfront style
iostreams code to new ISO C++ code. This was over a project of over
500,000 lines of C++. I think in the end, KAI got abandoned, even
though it was a good compiler, with the closest ISO C++ conformance.

ISO C++ remains a dream for many, perhaps for the next 2-3 years.
Especially for those who develop for multiple boxes.

Regards
dcb
---
[ 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              ]

ittay@my-dejanews.com wrote:
>: also, we use external libraries which sometime force us to compile
>: the whole module with the compiler the suppliers of the libraries
>: used. is there any way to circumvent that?

Oleg Zabluda wrote:
> Not really. If the interface you need from the library is really
> small, you can try to reexport it via extern "C" functions.

That's what we did in our project (600,000 lines of C++).  We provide
our customers with libraries and header files containing only
extern C API functions.  Internally, all our code is C++ and
arranged in shared libraries; the C API functions make calls to
our internal classes.

This means that the customer's code doesn't have to be re-compiled
when we issue a new version of our libraries.  It does, however,
require our customers to use the same C++ standard libraries that
we use.

The only way around this is if none of our code called any standard
or system C++ functions, but only called extern C functions (such
as those in the standard C library).  Most O/S functions are C
functions, not C++, so this is theoretically possible.  But it's
a practical impossibility; this means our code can't use things
like <iostream> or the STL.

-- David R. Tribble, dtribble@technologist.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              ]

>
> The only way around this is if none of our code called any standard
> or system C++ functions, but only called extern C functions (such
> as those in the standard C library).  Most O/S functions are C
> functions, not C++, so this is theoretically possible.  But it's
> a practical impossibility; this means our code can't use things
> like <iostream> or the STL.
>

That still won't be good enough.  You also need to kludge some
runtime support to boot in the C++ libraries that you write.
For example the major reason a lot of C++ libs are incompatible
is that the pre-execution initialization (staticly defined object
construction, etc...) only happens for whatever was used to
compile MAIN.
---
[ 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              ]

Oleg Zabluda wrote:
>
> ittay@my-dejanews.com wrote:
> : the assumption is that by using native compilers we gain more efficient
> : executables. is this true? what i mean is, if we use one uniform compiler
> : (the only one i know of is gcc, if you know of something else please tell me)
>
> KAI runs on almost anything.

According to KAI's list of supported platforms,
<http://www.kai.com/C_plus_plus> they still don't support DOS/Windows.
---
[ 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 Bj   rkholm wrote:
>
> ittay@my-dejanews.com wrote:
> >
> > the company i work for supports 4 different unix platforms & win nt. this
> > means that all of our code needs to be compiled on all 5 platforms. right now
> > we're using the native compilers that come with each platform, so we have to
> > write code that's compatible with each compiler. this results in a lot of
> > compilation / linking problems and also forces us to use only the most common
> > c++ features (we don't have dynamic_cast, for example).
>
> I agree. We have been there. We have had the same trouble.
>
> >  if we use one uniform compiler
> > (the only one i know of is gcc, if you know of something else please tell me)
>
> We are using KAI C++. See http://www.kai.com. We are using it on 3 unix
> platforms
> and we are really pleased. We get the latest C++ features and identical
> C++ code
> (save for some OS-specific include files).
>
> > will we have slower modules?
>
> We got faster modules. The KAI C++ optimizer is really good.
> (KAI C++ actually uses the OS native C compiler as backend,
>  so the low level optimization depends on the C compiler.
>  KAI has a good high level optimizer, optimizing the C++ constructs.)
>
> > also, we use external libraries which sometime
> > force us to compile the whole module with the compiler the suppliers of the
> > libraries used. is there any way to circumvent that?
>
> Not really. This is a pain.
> We only use external libraries if they are C libraries or if we can buy
> the source code.
>
> Actually there is a way to circumvent the problem, we have used
> it for one library:
>   Use "nm" on the library to see the symbols in the different
>   .o modules. Then replace all modules that have references outside
>   the library (calls the std c++ library, or is called from code outside
>   the library) with modules that you write yourself in C.
>   The modules you write should of course implement the same inteface,
>   but act as a glue between the calling convetions and name manglings.
>   I do not recommend this approach, it involves a lot of guessing.
>
> It is a shame that the C++ standard didn't address the issue of
> object code interoperability between different C++-compilers on
> the same target OS/hardware.

How could it?
Should it come with an additional ABI standard for each known
platform?

The fact that C ABI is usually compatible comes from the fact that
most OSs are written in C, and not being compatible with the
OS calling interface would surely not raise the market share
of a compiler ;-)
On operating systems which offered a native C++ API, all
C++ compilers would agree on the ABI, for sure.


[ 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              ]

Christopher Eltschka wrote:
>
> Tom Bj   rkholm wrote:
> >
> > ittay@my-dejanews.com wrote:
> > >
> > > also, we use external libraries which sometime
> > > force us to compile the whole module with the compiler the suppliers of the
> > > libraries used. is there any way to circumvent that?
> >
> > Not really. This is a pain.
> >
> > It is a shame that the C++ standard didn't address the issue of
> > object code interoperability between different C++-compilers on
> > the same target OS/hardware.
>
> How could it?
> Should it come with an additional ABI standard for each known
> platform?
>
> The fact that C ABI is usually compatible comes from the fact that
> most OSs are written in C, and not being compatible with the
> OS calling interface would surely not raise the market share
> of a compiler ;-)
> On operating systems which offered a native C++ API, all
> C++ compilers would agree on the ABI, for sure.
>

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).

I am aware of the fact that specifying these things in the standard
prohibits implementors to experiment with new more efficient
memory layouts and name mangling schemes. But, it is also important
to be able to use 3-rd party (binary) libraries. As it is today
all serious library vendors need to use C, or ship source code.

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              ]

James Kuyper <kuyper@wizard.net> wrote:
: Oleg Zabluda wrote:
: >
: > ittay@my-dejanews.com wrote:
: > : the assumption is that by using native compilers we gain more efficient
: > : executables. is this true? what i mean is, if we use one uniform compiler
: > : (the only one i know of is gcc, if you know of something else please tell me)
: >
: > KAI runs on almost anything.

: According to KAI's list of supported platforms,
: <http://www.kai.com/C_plus_plus> they still don't support DOS/Windows.

What's that?

Anyway, whatever it is, you can use gcc to cross-compile the
KAI-generated C code on any platform where KAI supports gcc,
say Linux. Alternatively, you can natively compile the generated
code with gcc on Windows.

You are not seriously proposing to _actually_ develop on Windows,
are you?

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ 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 Bj   rkholm wrote:
>
> Christopher Eltschka wrote:
> >
> > Tom Bj   rkholm wrote:
> > >
> > > ittay@my-dejanews.com wrote:
> > > >
> > > > also, we use external libraries which sometime
> > > > force us to compile the whole module with the compiler the suppliers of the
> > > > libraries used. is there any way to circumvent that?
> > >
> > > Not really. This is a pain.
> > >
> > > It is a shame that the C++ standard didn't address the issue of
> > > object code interoperability between different C++-compilers on
> > > the same target OS/hardware.
> >
> > How could it?
> > Should it come with an additional ABI standard for each known
> > platform?
> >
> > The fact that C ABI is usually compatible comes from the fact that
> > most OSs are written in C, and not being compatible with the
> > OS calling interface would surely not raise the market share
> > of a compiler ;-)
> > On operating systems which offered a native C++ API, all
> > C++ compilers would agree on the ABI, for sure.
> >
>
> 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).

3) Treatment of exceptions.
   Does the implementation use "zero-overhead-exceptions" (i.e.
   a table driven exception mechanism which gives no overhead
   to the normal execution path, except for optimisation
   losses)? If so, where is the table stored? What format
   does the table have? If not, what scheme is used?
   In any case, what are the parameters of the stack
   unwinding function? Or is there possibly no such function,
   but the stack unwinding code is generated separately for
   each function?

4) RTTI.
   Layout of type_info objects?
   What name is returned on type_info::name?
   How are they obtained? Is there a permanent pointer in the
   vtbl? Are they created on demand?

5) vtbl layout.
   Is thunking used? Where is the vtbl pointer in an object?
   How are vtbls implemented? Can derived objects share vtbls
   with their parent object?

6) Standard library.
   Unlike the C library, the C++ library has a lot of types with
   non-specified internal structure. But to link two files
   together which both use the same type, those type must have
   the same layout. In effect, this would pretty much fix the
   implementation of all the standard classes: containers,
   streams, even complex numbers. That is, to provide binary
   compatibility, you'd have to make a fixed implementation
   of the standard components for the platform.

7) Exported templates.
   How are exported templates stored? How is their context
   stored? Note that with exported templates, the two compilers
   must share not only some external symbols and linking/layout
   interfaces; they must agree on a description of C++ template
   context. One compiler has to instantiate templates which
   another compiler parsed, accessing the complete relevant
   context information.

8) I'm near to certain that I've forgotten something here.

[...]


[ 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 <36E8E365.6136B30C@ebc.ericsson.se>, Tom Bj   rkholm <tom.bjork
holm@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).
>
>I am aware of the fact that specifying these things in the standard
>prohibits implementors to experiment with new more efficient
>memory layouts and name mangling schemes. But, it is also important
>to be able to use 3-rd party (binary) libraries. As it is today
>all serious library vendors need to use C, or ship source code.

Actually with the increasing use of templates shipping source code is
often the only option.

As many of the active participants in the standards committees are
compiler developers there is no way that they would agree to constrain
their work in such a manner (this is one of the areas where users
benefit from the competitive drive to better implementations).

The difference between C-structs (in which the only real consideration
is alignment/padding) and C++ objects means that there are very serious
issues with the latter that have no effect on the former.  I can easily
imagine platforms where an efficient implementation of an MI object
required a specific layout that was different from that on another
platform.

I have said before, there is a way to support linkage between object
modules using different name-mangling algorithms and that is to use
extern "<linkage spec">



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 <36E8E365.6136B30C@ebc.ericsson.se>,
Tom =?iso-8859-1?Q?Bj=F6rkholm?=  <tom.bjorkholm@ebc.ericsson.se> wrote:

> 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.

One reason is that it is hard to devise a conformance test.

> 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.

What would you do with a machine that has two mutually incompatible
C compilers?  Or no C compiler at all?
--
    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              ]

Oleg Zabluda wrote:
>
> James Kuyper <kuyper@wizard.net> wrote:
> : Oleg Zabluda wrote:
> : >
> : > ittay@my-dejanews.com wrote:
> : > : the assumption is that by using native compilers we gain more efficient
> : > : executables. is this true? what i mean is, if we use one uniform compiler
> : > : (the only one i know of is gcc, if you know of something else please tell me)
> : >
> : > KAI runs on almost anything.
>
> : According to KAI's list of supported platforms,
> : <http://www.kai.com/C_plus_plus> they still don't support DOS/Windows.
>
> What's that?
>
> Anyway, whatever it is, you can use gcc to cross-compile the
> KAI-generated C code on any platform where KAI supports gcc,
> say Linux. Alternatively, you can natively compile the generated
> code with gcc on Windows.
>
> You are not seriously proposing to _actually_ develop on Windows,
> are you?

I don't see how it can be said to "run on almost anything" if it doesn't
run one one of the world's most widely used platforms. I don't develop
code for Windows, but many people do. I find it puzzling that KAI does
target other products for the Windows market, but not C++.


[ 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              ]

Andrew Koenig wrote:
>
> In article <36E8E365.6136B30C@ebc.ericsson.se>,
> Tom =?iso-8859-1?Q?Bj=F6rkholm?=  <tom.bjorkholm@ebc.ericsson.se> wrote:
>
> > 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.
>
> One reason is that it is hard to devise a conformance test.

Another is that there is no requirement to mangle names.
If the symbol table had enough extra fields to encode the
function args, you could leave the names alone.  The problem
is shoehorning C++ into a loader that was designed for C.
Most of the ugliness of template instantiation is also from
building C++ out of 70's generation tools.  As a matter of
fact there's a lot of goop in C with regard to external symbols
mandated by the fact that C didn't want to enforce any behavior
on the linker (though it was odd to many of us at the time that
if you had the support to do FORTRAN common blocks, you had all
you needed to do C the original K&R way).

>
> > 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.
>
> What would you do with a machine that has two mutually incompatible
> C compilers?  Or no C compiler at all?

And what about the C++ overhead as well.



[ 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              ]

Ron Natalie wrote:
>
> Andrew Koenig wrote:
> >
> > In article <36E8E365.6136B30C@ebc.ericsson.se>,
> > Tom =?iso-8859-1?Q?Bj=F6rkholm?=  <tom.bjorkholm@ebc.ericsson.se> wrote:
> >
> > > 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.
         ^^^^^^^^^^^^^^^
> >
> > One reason is that it is hard to devise a conformance test.
>
> Another is that there is no requirement to mangle names.

He's proposing that there be such a requirement (which I think is a bad
idea).


[ 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:

>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).

>I am aware of the fact that specifying these things in the standard
>prohibits implementors to experiment with new more efficient
>memory layouts and name mangling schemes. But, it is also important
>to be able to use 3-rd party (binary) libraries. As it is today
>all serious library vendors need to use C, or ship source code.

You have only scratched the surface; there are many more issues.

Regarding your #1, platforms differ in the characters allowed
in external names, and in the maximum length allowed for an
external name. A standard scheme would have to take the
smallest values allowed by any platform, leading to inferior
implementations on more capable platforms. Beyond that, some
platforms have ABIs that place requirements on external
names. If the platform was incompatible with whatever the
C++ standard said, implementers would have to choose between
complying with the standard or with the platform's rules.

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.

More things that can differ among C++ implementations:

3. The way the "this" pointer is passed to a member function.

4. The mechanism for keeping track of virtual functions in a class.

5. The mechanism by which a virtual function gets called.

6. The layout of pointer-to-member, and the way a member function
is called via a ptm.

7. The mechanism for keeping track of template instantiations.
For example, some use a repository for created instantiations
to avoid duplicates. What format should that take? Others create
all instantiations as needed and discards duplicates at link time.
Discarding duplicates is not a practical implementation on all
platforms. Other schemes are also in use.

8. The way the array forms of operator new keep track of the
number of elements. This feature requires cooperation between
the compiler and the run-time library.

9. The exact exception-handling mechanism. There are many
different schemes, all depending on the mutually-incompatible
requirements of different platforms.

I'm sure I've overlooked some important issues, but these are
the ones that come immediately to mind.

The C++ standard could specify exactly how all these things
are to be accomplished. To so do would force a least common
denominator approach, leading to inefficient implementations
on every platform. One of the major design goals of C++ was
to a language that could provide all the efficency of a
low-level language.

The province of compatible implementations is the ABI specified
for a platform, not the C++ language standard. Anyone implementing
C++ for that platform can provide a compatible implementation.

--
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              ]

Tom Bj=F6rkholm wrote:
...
> There are 2 main things that need to be addressed in order to
> be able to mix object code from 2 different C++ compilers.
>=20
> 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).

Solving that for one platform at a time is fairly trivial. Solving it in
a single way that works well on all platforms is well-nigh impossible.
The issues of byte size, sizeof(), byte order, bit order (for bit
fields) alignment, padding bytes and padding bits are all highly
non-trivial. They've been left implementation-defined precisely because,
for each of those issues, for any one possible resolution, there are
many platforms where that resolution could not be efficiently
implemented.=20

Additional issues that would also need to be resolved:

1. Work-arounds used to emulate standard types for which there is no
corresponding hardware-supported type.
2. Handling of non-standard data types (i.e. long long)
3. Signed integer representation.
4. Floating point representation.
5. Method used for determining the underlying types of enumerations.
6. Representation of pointers.
 Size, and whether or not it varyies with the type of the object being
 pointed to. Whether or not run-time bounds checking is implemented,
 and how. Whether or not garbage collection is implemented, and how.
 How pointers to physically different types of memory are represented.
7. Argument passing conventions.
8. Return value passing conventions.
9. Any compiler "magic" used in implementing Standard Library features.
 It's not rare for a call to a standard library function to be
 translated into something other than a simple call to a function with
 the name and function signature you might naively expect.
 STL coding. I think it would be virtually impossible to successfully
 link together object modules written to use two differently
 implemented versions of std::vector<>, if a function in one tries to
 reference a vector<> defined in the other.
10. Which reserved names are used by the standard library, and with what
 meaning.

Any choice on any of these issues that was imposed by the C++ standard
would result in certain platforms no longer having a conforming
implementation of C++.

> I am aware of the fact that specifying these things in the standard
> prohibits implementors to experiment with new more efficient
> memory layouts and name mangling schemes. But, it is also important
> to be able to use 3-rd party (binary) libraries. As it is today
> all serious library vendors need to use C, or ship source code.

Per-platform ABIs, promoted by companies associated with that platform,
provide all the standardization that is needed. Since object file
formats are themselves usually incompatible between different platforms,
why should you care whether or not they use compatible interface
schemes?
---
[ 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 <36E98FA7.382510E7@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>He's proposing that there be such a requirement (which I think is a bad
>idea).

Well, someone has to specify a mechanism to allow interoperability between
different compilers for the same platform.  However, it probably should be
whoever specifies the ABI for the platform.  There's certainly no reason
why a compiler for Intel/DOS needs to use the same mangling scheme as a
compiler for Sparc/Solaris, since you would never need to link those
binaries together.  But if you want to be able to purchase or download
binary libraries for Sparc/Solaris and link them with code that may have
been compiled with different implementations, someone (e.g. Sun or Sparc
International) needs to specify a common approach to all the language
features that have cross-module implications.  This would have to be done
independently for each platform, by an authority appropriate for that
platform (I'm not sure who would be the appropriate authority for Linux,
would it be Linus himself?).

--
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 <36E6152C.98E57FA9@ebc.ericsson.se>,
  Tom <tom.bjorkholm@ebc.ericsson.se> wrote:
> It is a shame that the C++ standard didn't address the issue of
> object code interoperability between different C++-compilers on
> the same target OS/hardware.

The standard doesn't even acknowledge the concept of object code.
Conceptually, you put in valid source code here, not neccesarily
all at the same time, and eventually you get a working program
there. What happens in between is not governed by the C++ standard.

Nor should it be. Can you imagine what would happen if there were
such a thing as ISO object code files? Every C++ compiler would
have to use them. C++ interpreters would be impossible. We could
never have compilers that write directly to a memory image for
speed. And if this hypothetical standard object code was designed
specifically for C++, we could never have mixed-language projects
again. But if it were designed to have every possible whiz-bang
feature that current and future languages might ever need on any
processor anywhere, then it would be huge. Even if you accepted
that it would be very large, there's the problem of those other
languages. The C++ standardization committee cannot make changes
to the COBOL or FORTRAN language standards in order to support
this new marginally-useful object code format, which might or
might not make sense to use depending on the current environment.

Perhaps we would make the object code layout a separate standard,
not part of the C++ or Fortran or COBOL language standards. But
once you do that, you remove most of the incentive to use the
darn things. Once again, I would be able to write a C++ compiler
that uses my own proprietary object code layout (or none at all),
and still be ISO-C++ compliant, simply by ignoring the ISO-object
code layout.

No, I think that very few would ever use it.

----
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              ]

hi,

the company i work for supports 4 different unix platforms & win nt. this
means that all of our code needs to be compiled on all 5 platforms. right now
we're using the native compilers that come with each platform, so we have to
write code that's compatible with each compiler. this results in a lot of
compilation / linking problems and also forces us to use only the most common
c++ features (we don't have dynamic_cast, for example).

the assumption is that by using native compilers we gain more efficient
executables. is this true? what i mean is, if we use one uniform compiler
(the only one i know of is gcc, if you know of something else please tell me)
will we have slower modules? also, we use external libraries which sometime
force us to compile the whole module with the compiler the suppliers of the
libraries used. is there any way to circumvent that?

-----------== 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              ]

ittay@my-dejanews.com wrote:

> the assumption is that by using native compilers we gain more efficient
> executables. is this true? what i mean is, if we use one uniform compiler
> (the only one i know of is gcc, if you know of something else please tell me)
> will we have slower modules? also, we use external libraries which sometime
> force us to compile the whole module with the compiler the suppliers of the
> libraries used. is there any way to circumvent that?

We are in the same boat.  We use VC++ on NT and the native compilers on
Solaris, IRIX, etc...  The only thing we use GCC for is LINUX.   Back
about 10 years ago, we found that GCC equalled or outperformed the
vendor implementatiosn (some of which were still PCC based).  Since
GCC was already pusing ANSI (C) compliance and some of the vendor
compilers couldn't do function prototypes yet we used a lot of GCC.

A few years back we did the tests again.  Most C implementations
were pretty good standards wise (at least as far as the language
itself was concerned) and the performance of all the vendor compilers
far outsripped GCC.  We gave up and went back to using the native
compilers.  Since going to C++ we still head bang around  many of
the compiler braindamanges (which include G++) when it comes to
C++ implementation.  We carry around the SGI STL implementation
so we have a known quantity there.

As far as the library issue goes, you're stuck.  You either have
to have a KNOWN application interface that all the compiler vendors
code to (which exists for SGI and Sun for example) or you end up
not being able to mix and match.  The other option is to go to one
of the network based API's like CORBA (which however, is still
more pain and suffering than it's worth in my opinion).



[ 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 <7c2h4a$mom$1@nnrp1.dejanews.com>,
  ittay@my-dejanews.com wrote:

> the company i work for supports 4 different unix platforms & win nt. this
> means that all of our code needs to be compiled on all 5 platforms. right now
> we're using the native compilers that come with each platform, so we have to
> write code that's compatible with each compiler. this results in a lot of
> compilation / linking problems and also forces us to use only the most common
> c++ features (we don't have dynamic_cast, for example).
>
> the assumption is that by using native compilers we gain more efficient
> executables. is this true? what i mean is, if we use one uniform compiler
> (the only one i know of is gcc, if you know of something else please tell me)
> will we have slower modules? also, we use external libraries which sometime
> force us to compile the whole module with the compiler the suppliers of the
> libraries used. is there any way to circumvent that?

With regards to speed, it varies.  But unless your work is really
numbers crunching, I doubt that the difference will be enough to
matter.

The problem with third party libraries, on the other hand, is real, and
as far as I know, there is no work-around.  If the vendors do not supply
a version for g++, and do not supply the sources, then you are out of
luck.

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                              Beratung in industrieller Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany    Tel. +49 (069) 263 17946

-----------== 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              ]

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ron Natalie wrote:

> As far as the library issue goes, you're stuck.  You either have
> to have a KNOWN application interface that all the compiler vendors
> code to (which exists for SGI and Sun for example) or you end up
> not being able to mix and match.

Which interface are you talking about in SUN's case? AFAIK it is _not_
possible to mix-and-match C++ libraries under Solaris. If you know
otherwise, please provide chapter and verse.

Thanks,

-- O.L.
--MimeMultipartBoundary--
---
[ 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              ]

I am currently trying to choose which of gcc and CC compilers am I going to use.
I did not see such topic covered in the FAQ.

I will appreciate as many comments I can have replyed by e-mail....

Thank you for your time....

 Stephane Morvan