[Top][All Lists]

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

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

From: Sergey Kashyrin
Subject: Re: [open-cobol-list] Calling C++ from GNU COBOL
Date: Fri, 07 Nov 2014 16:24:06 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0


For static initialization I think the easiest way is to rename cobcrun.c into cobcrun.cpp and use C++ compiler (or just use cobcrun from C++ version ?).
And of course call the program using it.

And regarding:

* Is the CPP version considered production-ready?

It is in process of the HEAVY testing.
Several minor things has been discovered but I am not ready to put the fixes into SVN yet. Need to reorganize the way how to handle names collision issue, maybe put that into configurable external file As an example the COBOL program has variable LC-NUMBER which translated into LC_NUMBER, but that is predefined variable in some C header ! And within ~5000 COBOL programs I've already found 10 different name collisions. And I think it is not a good way to hardcode that (as I temporarily did).

I expect another 3 months before I can say "go ahead".

But all are welcome to test and report any issues. I will pay immediate attention, as now it is in my interests too :-)


On 11/6/2014 11:16 AM, 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 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.

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?
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


open-cobol-list mailing list

reply via email to

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