Questions on Sun's C++

[Naoki Saito]

I've been using the Sun's C++ for 2 weeks.  I'm pretty much satisfied.
This is exactly the same as the AT&T C++ 2.0 except that Sun does not
provide the source codes.  The following article is the one I posted on
the comp.lang.c++ a week ago.  Maybe you will find some interesting
things.

Regards,
Naoki Saito(saito at sdr.slb.com)
Schlumberger-Doll Research

==========================================================================

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 at sdr.slb.com)
Schlumberger-Doll Research