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

[Scott McKellar]

Simon:

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 
different.

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 
dynamic.

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 
foobar.so, 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 
foobar.cob.

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?

Simon
> 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"
>     <address@hidden>
> Message-ID:
>     <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 experimentation.
>
> 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 system-specific.
>
> ----------
>
> 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 
>> > initialized.
>> >
>> > 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