ashley@cheops.eecs.unsw.oz (Ashley M. Aitken) (03/06/89)
Howdy,
Just when I thought C++ would add some productivity to my existence all hell
breaks loose (forgive me please, it is late, very late). I am having severe
problems with C++ and Apollo C System files compatability.
Can someone, anyone shed some light ?
The situation is as follows. I am programming in C++ Version 1.2.1 under SR10.1
with SR10? release of C (I think). Anyway the C++ language works well so the C
must be later that V6.00. The problems are with Header Files, that seem to be
incompatible with this C++ (but not the C). For example ..
The following code (I know some of them ain't C++ files ie stdio.h is not )
#include <stdio.h>
#include <string.h>
#include <apollo/base.h>
#include <apollo/pad.h>
#include <apollo/error.h>
#include <apollo/ios.h>
main() {
}
when compiled with ver sys5.3 /bin/ccxx ... yields the following errors and
[NOTE I AM USING THE SYS5.3 FILES from BSD (is this a problem ?)]
"/usr/include/apollo/base.h",
line 109: error: high __attribute : type expected (high is not a type name)
line 109: error: bad base type: type name high
line 109: error: argument type expected for __attribute()
caused by the new __attribute in the following I believe
10/10/88 cas make sizeof time_$clock_t alignment insensitive
change #attribute to __attribute
#if _ISP__M68K || _ISP__A88K
time_$clockh_t high __attribute((aligned(1)));
and these errors
"/usr/include/apollo/ios.h",
line 570: error: function declaration in argument list ( ios_$set_locate_buffer_size())
line 577: error: function declaration in argument list ( ios_$switch())
line 627: error: function declaration in argument list ( ios_$inq_path_name())
Sorry, too many errors
caused by the #options statement in the following I believe
ios_$get_handle(
ios_$id_t &strid,
uid_$t &type_uid,
status_$t *status
) #options(a0_return);
extern void
ios_$set_locate_buffer_size(
ios_$id_t &id,
short &size,
status_$t *status
);
It seems to me that the C++ is lagging behind the C but I am not sure, it
could easily be just stupid mistakes on my behalf. But alas, it is very
frustrating.
The release notes for the C++ recommend the use of these very /usr/include
/apollo/*.h header files (cos they have the prototyping and variable reference
included.)
HELP:
Could someone (perhaps at Apollo) please set me straight once and for
all about what version of what goes with what in this C++ system call
situation.
Thanks In Advance,
Ashley Aitken.
E-MAIL ashley@cheops.unsw.oz ACSnet
ashley%cheops.unsw.oz@uunet.uu.net ARPAnet
ashley@cheops.unsw.oz.au ARPAnet
{uunet,ukc,ubc-vision,mcvax}!munnari!cheops.unsw.oz!ashley UUCP
ashley%cheops.unsw.oz@australia CSnet
ashley%cheops.unsw.oz@uk.ac.ukc JAnetarchiel@mntgfx.mentor.com (Archie Lachner) (03/11/89)
From article <1093@cheops.eecs.unsw.oz>, by ashley@cheops.eecs.unsw.oz (Ashley M. Aitken): > Howdy, > > Just when I thought C++ would add some productivity to my existence all hell > breaks loose (forgive me please, it is late, very late). I am having severe > problems with C++ and Apollo C System files compatability. > > Can someone, anyone shed some light ? > > The situation is as follows. I am programming in C++ Version 1.2.1 under SR10.1 > with SR10? release of C (I think). Anyway the C++ language works well so the C > must be later that V6.00. The problems are with Header Files, that seem to be > incompatible with this C++ (but not the C). For example .. > > The following code (I know some of them ain't C++ files ie stdio.h is not ) We have found that the only way to insure correct compilation, linking, and execution is to generate C++ versions of the C header files. In practice this means taking the Apollo header files and modifying them so that they describe things using C++ syntax. This is painful to do the first time, but updating them with Apollo header-file changes is not too bad. In general, C++ and C are two different languages. C++ is not upward compatible with C, not matter who says so. The two languages can be made link compatible, but there are thing you must do on the C++. Writing C++ headers for the C functions you use is one of those things. You may want to ask your Apollo representative if they have any C++ header files for the C library. P.S. If you're using C++, why not use the streams package instead of stdio? -- Archie Lachner Mentor Graphics Corporation Beaverton, Oregon ...!{decwrl,sequent,tessi}!mntgfx!archiel
vasta@apollo.COM (John Vasta) (03/13/89)
I'm responsible for Apollo's C++ product. Yes, C++ is lagging behind
C in the implementation of language extensions such as __attribute()
and #options. The __attribute() syntax didn't exist when C++ was released;
the next version will support it. In the meantime, you can define macros
so that __attribute is preprocessed out:
#define NO_ATTRIBUTE
#define __attribute(a) NO_ATTRIBUTE
(The two macros are required to get around a bug in the macro preprocessor;
just defining __attribute(a) with a null expansion won't work.) Put these
macros in your source file, before including any header files.
The #options syntax was added to some header files after C++ was released,
also. Again, the next version will support it. This syntax cannot be
easily defined away, you'll have to edit the header files. I suggest putting
#ifdef c_plusplus
...
#endif
around it for now.
John Vasta (vasta@apollo.com)
Apollo Computer, Inc.