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

[Simon Sobisch]

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