topic Re: porting C to C++ on OpenVMS in Operating System - OpenVMS

porting C to C++ on OpenVMS

Ryan Rogalla — Fri, 08 Jan 2010 15:17:45 GMT

The team I work with has been looking at cleaning up our company's rather large business application written in C. One of the things we are looking at is starting to use C++. The first step would be to try and compile our C code using the cxx compiler. We have been running into a lot of errors. Has any one else went through this before? I knoticed one of the settings on the cc compiler is /STANDARD=VAXC, which I am sure was used during the migration over to the alphas. Is there anything similar for the cxx compiler? Some of the main errrors I am seeing is

%CXX-E-UNDECLARED, identifier "globalvalue" is undefined
at line number 2769 in file DATA8:[DEV_SPLIT.GS.SOURCE]GS_DEF.H;287

#module rt_detail_read_sp
.^
%CXX-W-BADPPDIRKEY, unrecognized preprocessing directive
at line number 1 in file DATA8:[DEV_SPLIT.RT.USERS.RYANR]RT_DETAIL_READ_SP.C;7

status = gs_sql_error_ss(&sqlcode);
.................^
%CXX-E-UNDECLARED, identifier "gs_sql_error_ss" is undefined
at line number 90 in file DATA8:[DEV_SPLIT.RT.USERS.RYANR]RT_DETAIL_READ_SP.C;7

I was able to get rid of the above errors by compiling the external functions locally for the piece of code I was testing with.

Any help or advice would be greatly appreciated.

Re: porting C to C++ on OpenVMS

Robert Gezelter — Fri, 08 Jan 2010 16:18:48 GMT

Ryan,

First, Welcome to the HP ITRC OpenVMS Forum.

I have been through this process quite a few times with various clients. I have also dealt with it a few times in moving code among VAX C, DEC C, GNU C, and DEC C++.

My experience has been that the first step is to clean up the sources. The /STANDARD=VAXC is a crutch that defers correction of a number of obsolete constructs, and they can cause more excitement when they are encountered at a later point.

Also, C++ is far more strict about defining external functions.

Often, errors will be reported due to missing declarations. Some of these will be reported at compile time, some at link time.

Most often, I turn off the back compatibility features and clean up the sources to current standard before switching to C++.

- Bob Gezelter, http://www.rlgsc.com

T

Re: porting C to C++ on OpenVMS

H.Becker — Fri, 08 Jan 2010 16:49:43 GMT

I saw it in another reply: "Don't! ?! :-)". You may have some good reasons to convert the code and you are probably aware, that even if you compile with C++, this is still C code.

Anyway, I would start with cc/stand=relaxed (relaxed ANSI C) and /warnings=enable=all. The compiler should tell you about all VMS, DEC, Compaq and/or HP extensions, you may see:

%CC-I-PRAGMAMOD, Please use the preferred "#pragma module" directive in place of the "#module" directive.

%CC-I-GLOBALEXT, A storage class of globaldef, globalref, or globalvalue is a language extension.

%CC-I-IMPLICITFUNC, In this statement, the identifier "foo" is implicitly declared as a function.

After cleanup of all the errors/warnings (or at least understanding all the warnings and the informationals) I would compile with the C++ compiler.

Depending on the C++ errors/warnings I would look up some info about the differences of C and C++. Google is your friend. As you probably know, C++ is not a superset of C.

If you do not run into differences in the language you end up with better C code: C++ requires all external functions to be declared before they can be used and it checks the interface by mangling parameter types into the function names and so making a function plus parameters unique across modules. Obviously you have to link to find all function/argument mismatches. But be aware that some external functions, for example system services, are external C functions for the C++ compiler and their interface isn't checked the same way.

But then I would recompile the sources with a C compiler. :-)

Re: porting C to C++ on OpenVMS

Steven Schweda — Fri, 08 Jan 2010 18:31:45 GMT

> #module rt_detail_read_sp
> [...]

HELP CC Language_topics Preprocessor #module

The #module directive is retained for compatibility with VAX C and
is supported only when running the HP C compiler in VAX C mode
(/STANDARD=VAXC). See also the ANSI C equivalent #pragma module
directive.

That pretty much sums it up, doesn't it?

> %CXX-E-UNDECLARED, identifier "gs_sql_error_ss" is undefined [...]

You're not using function prototypes?

> [...] the first step is to clean up the
> sources. [...]

I'm with him.

> The first step would be to try and compile
> our C code using the cxx compiler.

Why? Why not use the C compiler on the C
code (after you fix the stuff), and the C++
compiler on the C++ code?

Re: porting C to C++ on OpenVMS

John Reagan — Fri, 08 Jan 2010 18:50:02 GMT

Can you tell us the:

- architecture
- version of C compiler
- version of C++ compiler

Re: porting C to C++ on OpenVMS

Ryan Rogalla — Fri, 08 Jan 2010 21:21:15 GMT

Thanks for the suggestions so far. I realize this could take some effert. Right now we are in the research stage of trying to improve our application (architecture, coding standards, etc). Of coarse finding time is another issue with the continual projects coming through (same old story). We are basically looking at options, and one is to try and make small incremental improvements and try and propagate them through the system. For some of the things we have discussed it would make life easier to use C++, and gradualy move it in to our code base. I am just trying to get a feel for the effet.

A question for Steve - you comment on use both compilers. Is it possible to easily call the functions compiled by each compiler to the other? I may be in the wrong mindset

John - HP C Version 7.1
HP C++ V7.3-009 for OpenVMS Alpha V8.3

Actually I am researching on an alpha machine, but we just recently went over to the itanium

Re: porting C to C++ on OpenVMS

Robert Gezelter — Fri, 08 Jan 2010 21:24:33 GMT

Ryan,

Yes, it is possible to have some modules in C and other modules in C++.

You will need to properly configure C++ to generate the C-compatible (non-mangled) external names. This is documented.

- Bob Gezelter, http://www.rlgsc.com

Re: porting C to C++ on OpenVMS

Ryan Rogalla — Fri, 08 Jan 2010 22:26:38 GMT

thanks for the reply.

On a small scale I was able to link some of our C code compiled with the C compiler with the c++ linker, and was able to call back and forth between functions compiled in C and C++, but both linked using the C++ compiler. It seemed the main ideas was to provide headers for the functions and use the extern "C", As Robert pointed out about name mangling.

Does anyone know of any problems doing this? This would at least allow us to slowly introduce and imporve our code base.

Are there better ways?

Is this safe to do?

Re: porting C to C++ on OpenVMS

Steven Schweda — Fri, 08 Jan 2010 23:16:18 GMT

> Is this safe to do?

It had better be. So far as I know, that's
how the whole C run-time collection is made
available to a C++ program. Have you looked
at the C/C++ header files? 'extern "C"' is
a pretty popular construct.

Re: porting C to C++ on OpenVMS

Robert Gezelter — Sat, 09 Jan 2010 00:37:44 GMT

Ryan,

I would call it a hazard, not a danger. The hazard is that functions using the C naming cannot use overloaded function names (which is what the C++ name mangling is all about).

- Bob Gezelter, http://www.rlgsc.com

Re: porting C to C++ on OpenVMS

Dennis Handly — Sun, 10 Jan 2010 20:20:05 GMT

Even if you decide to still use the C compiler, compiling with C++ will give you "lint clean" source that is fully prototyped. (Hopefully you will centralize the prototypes in headers.)

Note that declarations like void foo() are valid for C++ but not for scummy C. You need to add void: void foo(void)

You may also want to compile with C99 where missing prototypes is deprecated.

One difference between C and C++ is that const has internal linkage in C++:
const struct foo bar = { 99 };
Change to:
extern const struct foo bar = { 99 };