[comp.lang.c++] g++-1.34.2 vs Sun C++ 2.0

saito@sdr.slb.com (Naoki Saito) (12/08/89)

	Hello, folks!  We recently purchased the Sun C++ 2.0.  I recompiled
and relinked my signal processing package originally done with GNU C++-1.34.2.
During the trial, I found the following differences.  I think someone in the
network might be interested in this. I should have compared the Sun C++ with
GNU-1.36.x.  However, my package doesn't require any multiple inheritance so
I'm still sticking with the older version.
If someone tries to do the same kind of things, let's share some tips!


(1) "one_arg_error_handler_t" and "two_arg_error_handler_t" is not defined in
the stddef.h of Sun C++.

(2) "enum bool" is not defined in stddef.h of Sun C++.

(3) "PI" is not defined in math.h of Sun C++.

(4) Casting is necessary for "char*" argument if one tries to pass another type
argument in Sun C++. ==> 2.0 features (Stronger type checking)

(5) Default values for function arguments cannot be set more than once in Sun
C++. ==> 2.0 features

(6) Sun C++ accepts the +a1 flag which produce ANSI C rather than K&R C.
However, header files coming with the tape is not ANSI C base.
As a result of that, ANSI C cannot be used without some modification in header
files.  Sun's C compiler doesn't accept ANSI C either.
So, for instance, an aggregate at local scope cannot be initialized.
e.g.,

void f()
{
  int i[1] = {1};
}

(7) More strict visibility rules in Sun C++ ==> 2.0 features
The following program shows this example.

class Base
{
protected:
  int a;
public:
  Base() { a = 100; }
  ~Base() {};
  int get_a() { return a; }
};

class Derived : public Base
{
public:
  Derived() : () { a = 10; }
  ~Derived() {};
  void f(Base& b) { cout << a + b.a << "\n"; }
  void g(Base& b) { cout << a + b.get_a() << "\n"; }
};

main()
{
  Base x;
  Derived y;

  y.f(x); // Error in Sun C++. not error in GNU-1.34.2.
  y.g(x);
}

(8) Differences in header file hierarchy between the GNU and Sun.
e.g., in order to use "strcmp", Sun C++ requires to include <strings.h>.  In
GNU, just including <stream.h> is fine because it also includes <std.h> where
"strcmp" is declared.

(9) Sun C++ cannot expand inline function with return statement without
expression or void type.
Neither 

inline void f() { return; }

nor

inline void f() {}
inline void g() { return f();}

works.  This is described in the appendix of "AT&T C++ Language System
Reference Manual."  Is this a translator limitation??? 

(10) Differences in stream package. ==> GNU-1.36.x stream package might not so
different from Sun C++'s, I think.

(11) Linking with external C or Fortran functions requires type safe linkage
style in Sun C++. ==> 2.0 features.
However, even for Fortran routines, keyword "C" is necessary, i.e.,
extern "C" { void sub_(); }  where sub_() is a fortran subroutine.
Is there any extern "FORTRAN" syntax???

(12) Difference between Sun's ld and GNU ld++.
A management style of my package/library follows the idea of Dr. J. Coggins'
paper "Managing C++ Libraries", Sigplan notice, vol.24, No.6, 1989.
This suggests that each class should have its own directory and each non-inline
member function should be stored in a separate file.  As a result of this,
the names assigned to the source files might not be unique across the entire
library.  In the case of GNU, even there exist multiple .o files in the
library, it correctly load objects and produced the executable.  However, Sun's
C++/ld cannot handle this situation.  Has anybody resolved this problem???



Finally, I will probably post some numerical benchmark test for GNU-1.34.2
and Sun C++ soon.

Thank you for your attention,



	
-- 
Naoki Saito (saito@sdr.slb.com)
Schlumberger-Doll Research

rdr@mdavcr.UUCP (Randolph Roesler) (12/09/89)

Another difference is that Gnu G++ allows pointer arthmatic
on type (void *), while ATT does not.

I discovered this while tring to compile Tomas Wang's MM garbage
collector.  There looks to be a fair number of little fixups
to make, like to one above.

Is anybody serious about creating a patch set for MM ?  If not,
I will get to it in January and post the patch to the net (remind me).

Oh, Tomas, a bug -- in barebones.h -- you include line.h, should
be line_t.h ?


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's not the size of your signature that 	Randy Roesler
counts - it's how you use it!			MacDonald Dettwiler & Assc.
email ...!uunet!van-bc!mdavcr!rdr		BC Canada 604-278-3411