[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Calling C++ from GNU COBOL

From: Sergey Kashyrin
Subject: Re: [open-cobol-list] Calling C++ from GNU COBOL
Date: Fri, 14 Nov 2014 14:15:02 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Hi Scott,

Isn't it enough ?

extern "C" int COBMAIN();

int main(int argc, char * argv[]) {
    cob_init(argc, argv);
    return COBMAIN();

And that will guarantee all C++ static initializations.


On 11/14/2014 12:08 PM, Scott McKellar wrote:

Compiling cobcrun as C++ would presumably work, if we were going to use 
cobcrun, but it turns out not to be necessary.

At least in our environment (gcc and g++ on RedHat), the C compiler seems to 
know how to initialize global C++ objects.  What I thought would be a problem 
isn't a problem after all.  In other environments the situation may be 

I would rather not use cobcrun anyway.  Our current practice is to compile 
binary executables on our development box and then install them on the 
production box.  As I understand it, with cobcrun we would install a bunch of 
shared object files instead of binary executables, and all linkage would be 

I won't try to address the advantages and disadvantages of static linkage 
versus shared linkage, but static linkage is what we're using now, apart from 
some third-party shared libraries.  Switching everything to dynamic linkage 
would be disruptive.  It will be hard to sell GnuCOBOL to upper management if I 
can't provide drop-in replacements for the existing executables.

There is another issue with cobcrun (at least I think there is; I haven't tried it).  We 
rely pretty heavily on being able to see what's running by using the ps utility and 
looking at the executable name.  If cobcrun is running, then ps will presumably 
report an instance of cobcrun.  We will see "foobar" as part of the command 
line, but our scripts may not recognize it there.  Things could get very messy, 
especially during the transition when a growing subset of programs are running under 
cobcrun and others are still running as free-standing executables (along with our C and 
C++ programs).

The earlier suggestion (writing a thin C++ wrapper for every COBOL program) 
would be disruptive in other ways.

Today we have foobar.cob that gets compiled to foobar.o and linked into 
foobar.exe (yeah, we use the Windows convention for naming executables).  A C+ 
wrapper would presumably be named foobar.cpp, and it would get compiled to 
foobar.o -- oh, wait, we're already using that name for the object file from 

No doubt we could come up with some kind of naming convention to avoid these 
collisions, but it would almost certainly be messy and disruptive.

Fortunately none of these forms of disruption appears to be necessary.

Scott McKellar

----- Original Message -----
From: Simon Sobisch <address@hidden>
To: Scott McKellar <address@hidden>
Cc: address@hidden
Sent: Friday, November 14, 2014 7:06 AM
Subject: Re: Calling C++ from GNU COBOL

Hi Scott,

Sergey Kashrin suggested to simply compile the current cobcrun with a
C++ compiler (maybe rename it to cobcrun.cpp) and start the COBOL
modules via the resulting executable (one c++ main for all COBOL modules
- identical to what I suggested but less to code).

Did you tested this?

How does this entail a sizeable disruption to your existing code base
and development practices?

Date: Tue, 11 Nov 2014 08:09:31 -0800
From: Scott McKellar <address@hidden>
Subject: Re: [open-cobol-list] Calling C++ from GNU COBOL
To: "address@hidden"
Content-Type: text/plain; charset=us-ascii

Responding to my own post...

Simon Sobisch and Patrick both suggested that I write a small wrapper in C++ 
that would call the real program in COBOL and not do much else.  I had 
considered that briefly, but I had hoped to avoid that approach.  It would 
entail a sizable disruption to our existing code base and development practices.

Also, Brian mused about possibly adding explicit support in GNU COBOL for 
calling C++ routines.

Finally I got around to what I should have done in the first place, namely some 

I got my Hello World program (in COBOL) to link to a little C++ routine that 
wrote a message to standard output using std::cout (I had to add the -lstdc++ 
option to the compile line).  Rather to my surprise, it worked.

Thinking there might be something special going on with std::cout, I concocted 
a little class whose constructor stores a time stamp for the current date and 
time.  Then I declared a static instance of that class and referenced it from 
my little C++ routine.  That worked too.  The static instance got initialized 
somehow, even though the top-level program was in COBOL.

I also tried calling the same routine from C, with GNU COBOL taken out of the 
picture.  It still worked.

Conclusion: at least in my environment (gcc and g++ on RedHat Linux), C knows 
how to initialize static objects defined in C++.

For my purposes, I think that's good enough, provided that I'm willing to 
sacrifice some portability.

However I wouldn't generalize this finding to other environments.  I have read 
warnings about calling C++ from other languages, but the danger is highly 


In the more general case, one might find oneself on a system where the C 
compiler isn't smart enough to initialize C++ standard objects.  In that case, 
maybe the following approach would work:

If GNU COBOL is compiling a module that includes a main(), it could contrive to 
compile it as C++, instead of C, provided that a C++ compiler were available.  
Then the top-level module would be in C++ and it would know how to initialize 
static objects.

This approach assumes that the C code generated by GNU COBOL is compilable as 
C++, or could be made compatible with a minimum of fuss.  The main issue would 
be to make sure that suitable function prototypes were in scope.  I don't know 
how much of a big deal that would be.


Thanks to all who responded.

Scott McKellar


Is it possible to call C++ routines (declared of course as extern "C")
from GNU COBOL?  Do we need to use the version that emits C++, or can we > use 
the version that emits C?

Context: I'm trying to evaluate a possible migration to GNU COBOL from
an expensive proprietary COBOL compiler (currently running Linux, RedHat > 
4.1.2).  Many of our existing COBOL programs rely on C++ routines for
various things, especially for parsing XML.  I really don't want to have > to 
rewrite all that stuff in some other language.

What concerns me most is the initialization of static objects.  For
example, std::cout is a statically allocated instance of an ostream.  It > 
needs to be initialized before use (to connect it to standard output).

If the main program is in C++, the C++ compiler can give it special
treatment to ensure that static objects are initialized before control
enters main().  If the main program is in some other language, we still > need 
the same kind of magic, or else static objects won't get

Our current compiler provides this magic if you feed it the right
compile option.  I don't see a similar option for GNU COBOL.

So far I've been playing with GNU COBOL 1.1, compiled from source.  I
tried a Hello World program that called a little C++ program, but it
didn't get past the link because it couldn't find the library for
std::cout.  I can probably find a way to make the link work, but if I
do, I suspect that std::cout won't work.

I understand that there is a GNU COBOL CPP from Sergey that emits C++
instead of C.  In that case we could presumably call C++ routines as we > do 
today and any static objects would be healthy.

However I get the impression that the CPP version is a recent
development and may still be bleeding-edge.  Ours is a big corporate
shop; bleeding edges make people nervous.

    * Is there a way to call C++ safely from GNU COBOL 1.1, or do we have > to 
use the CPP version?

    * Is the CPP version considered production-ready?  Is anyone using it > 
successfully in a large-scale production environment?

Scott McKellar
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
open-cobol-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]