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

[J Martin Rushton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For a discussion of a similar problem, but with FORTRAN instead of
COBOL, see:

https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gfortran/Mixed_002dLanguage-Programming.html#Mixed_002dLanguage-Programming

For the specific issue of a non-FORTRAN main program and the
requirement to initialise correctly see:

https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gfortran/Non_002dFortran-Main-Program.html#Non_002dFortran-Main-Program

Obviously you will need to interpret these for the needs of COBOL but
it may give an insight.  Try also using a "Hello World" program and
looking at the assembly language, it will help you find out what
initialisation is required.

HTH, Martin

PS. Apologies to Brian for misaddressing the first draft: I'm using a
different mail system from the one I'm used to. M.

On 06/11/14 16:16, Brian Tiffin wrote:
> On 11/5/14, Scott McKellar <address@hidden> wrote:
>> 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?
> 
> Yes, and no you don't need GnuCOBOL-CPP for this.  As long as
> there is an unmangled entry point, (extern "C") for the linker, it
> all works.
> 
>> 
>> 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.
> 
> This could be tricky.  The pre-init issue will need some looking 
> into, but it'll be a do-able thing.
> 
> As an example (and I just noticed the code listing repo has gone 
> stale, so I'll fix that soon), see 
> http://opencobol.add1tocobol.com/gnucobol/#can-gnucobol-interface-with-falcon-pl
>
>
> 
Falcon is written in C++ and all that was required for embedding
> in GnuCOBOL was an extern "C" wrapped entry point.
> 
> While the first GUI will be GTK+, there are long term plans to 
> include a layer for Qt, and aside from the wrappers to get entry 
> points to the linker, has tested out ok.
> 
>> 
>> Our current compiler provides this magic if you feed it the
>> right compile option.  I don't see a similar option for GNU
>> COBOL.
> 
> There isn't really, but C can be made to play nice with C++, so 
> it'll be possible with GnuCOBOL as well.
> 
>> 
>> 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.
> 
> It should, but may require an extra call or two.
> 
>> 
>> 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.
> 
> Yep.
> 
>> 
>> 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.
> 
> Yep.
> 
>> 
>> 
>> * Is there a way to call C++ safely from GNU COBOL 1.1, or do we 
>> have to use the CPP version?
> 
> I'm going to say yes, but you've raised issues that will require an
> experiment or two.
> 
>> 
>> * Is the CPP version considered production-ready?  Is anyone 
>> using it successfully in a large-scale production environment?
> 
> Sergey could answer that one better, but yes I believe so.
> 
>> 
>> Scott McKellar
>> 
> 
> Cheers, Brian
> 
> ------------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJUXVA/AAoJEAF3yXsqtyBlb1MQAIfOYlOgzaF6SQ6FgYKGeIs3
haZc+rtL4WJFlBvmQ04wgk6KM7QkhqfokjSMtrJALMSQioZ75t2WZk1bhVZhy7C8
grYeaL1xnPw0BrO5Vx6rjdSEwRdrpIj5Bu0I4TT1AiqoJQnOubXUf1HSjc6An920
qg5k20JqPzDhQkdSQsum/l27EX5vyOmRB/fUHeqLJAg3bcaqNC3Lhg+3YynoO9U7
u1qpR2GYC9HhLZ9ti+xSOJeUqPO92qYovHRbqcIkKUwOuGG6TiEv+/0QyrRbW81H
JfGp5S9lO6/P/y8ZfBcUryqTNU1Q6uE8kmjrH0unOtyqFjf6vJXA6fiHCeg+nzQl
3jhGQ/Sl8EdnRMGZm4G7VMdM56O5i2N0VR4vgxEhyTVESb+dWDtRPiHvgvvaoSNo
mb1fckb/CghYZ01PetlD4ODIAtaXbwvgkiH/Vvny2F8e2oI9L/FbFuvUiuBDsEvh
STnYPyOIbqy2TGuCUuwyBFv/vVcmbeHwajUlyyvFylEIiuUkdLcTS/E9r6AhBCQA
hcZlHdXuJfE9OBB1+WaL1YX6nuKkx/K9qDMQQXuSvgQSUyP9sDqj61Rwp2fhu2Gs
XT/sv3wgpOfn/7Nw9OLNlThEiB6K8Y1hqGCBvcYMAeSm8UE1D2tK3t55BfXwTo/i
YpQUwnipunTDB3MnA1aN
=4xBG
-----END PGP SIGNATURE-----