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

[Sergey Kashyrin]

Hi,

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 :-)

Regards,
Sergey

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
> 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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list