Re: [open-cobol-list] open-cobol-list Digest, Vol 85, Issue 1

[Simon Sobisch]

> Date: Wed, 5 Nov 2014 11:24:51 -0800
> From: Scott McKellar <address@hidden>
> Subject: [open-cobol-list] Calling C++ from GNU COBOL
> To: "address@hidden"
>       <address@hidden>
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> 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
Hi Scott,

there should be no problem using the C version. I'd highly suggest to
not use the 1.1 release but the 2.0 branch which is currently checked by
lots of smaller and bigger companies (some are *real* big) for use in
production.
I don't know of any production usage of the CPP version which is in some
parts outdated but should work for most cases nonetheless.

In your specific case I'd suggest to
* write an own main in CPP doing whatever you need (including a possible
load of C++ libraries) and starting the GnuCOBOL runtime afterwards,
either with a fixed COBOL start program or getting it from command line
- have a look at cobcrun.c (or cobcrun.cpp) how to do that
* compile all your COBOL sources to modules and don't do static linking
(should go without linker errors)
* if you don't load all your C++ libraries in your main use COB_PRE_LOAD
and COB_LIBRARY_PATH to do so on initialization (see the FAQ)

Simon