gcc vs CC

gcc vs CC

Post by Ron Natali » Wed, 10 Mar 1999 04:00:00




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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by Olivier Lefevr » Thu, 11 Mar 1999 04:00:00



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

 
 
 

gcc vs CC

Post by Martin von Loewi » Thu, 11 Mar 1999 04:00:00



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

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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by Tom Bj?rkhol » Thu, 11 Mar 1999 04:00:00



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

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

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

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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by Oleg Zablud » Thu, 11 Mar 1999 04:00:00


: 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 *ly transmitted, 100% lethal disease.

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.veryComputer.com/++/faq.html              ]

 
 
 

gcc vs CC

Post by James Kuype » Thu, 11 Mar 1999 04:00:00


...

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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]
 
 
 

gcc vs CC

Post by David Binderma » Thu, 11 Mar 1999 04:00:00




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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by David R Tribbl » Thu, 11 Mar 1999 04:00:00



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

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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by Ron Natali » Fri, 12 Mar 1999 04:00:00


Quote:

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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]
 
 
 

gcc vs CC

Post by James Kuype » Fri, 12 Mar 1999 04:00:00




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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]
 
 
 

gcc vs CC

Post by Christopher Eltschk » Fri, 12 Mar 1999 04:00:00




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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by Tom Bj?rkhol » Sat, 13 Mar 1999 04:00:00





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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

gcc vs CC

Post by Oleg Zablud » Sat, 13 Mar 1999 04:00:00


: >
: > : 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.veryComputer.com/; 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 *ly transmitted, 100% lethal disease.

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.veryComputer.com/++/faq.html              ]

 
 
 

1. gcc vs CC

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

2. HP Laserjet III problems

3. problem with ofstream (SUN CC vs gcc)

4. FAQ for elisp?

5. Overwrite cc with gcc??

6. NEED HELP: Combining two networks through a computer

7. What's the difference between CC and GCC

8. Date formatting problem

9. vector::const_iterator problem with VC++, but not CC or gcc

10. compiler CC and GCC

11. gcc/cc compilition

12. Interoperability Sun CC & GCC

13. Combining cc and gcc?