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