jane@uunet.uu.net (Jane Kusuma) (12/04/89)
Has anyone used Sun's C++ (beta or first release). We're expecting 1st customer shipment and are wondering what other people's experiences were with it (beta or first release). I'd appreciate any feedback (ie: how are the migration tools, debuggers, etc..). Please email responses. Thanks in advance Jane Kusuma Greenwich Capital Markets Greenwich, CT uunet!gcm!jane
saito@cs.yale.edu (Naoki Saito) (12/18/89)
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@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@sdr.slb.com)
Schlumberger-Doll Research