[Top][All Lists]

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

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

From: J Martin Rushton
Subject: [open-cobol-list] Fwd: Re: Calling C++ from GNU COBOL
Date: Fri, 07 Nov 2014 23:05:35 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0

Hash: SHA1

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

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

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 
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
> 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
> ------------------------------------------------------------------------------
Version: GnuPG v2.0.22 (GNU/Linux)


reply via email to

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