Simon:
Compiling cobcrun as C++ would presumably work, if we were going to use
cobcrun, but it turns out not to be necessary.
At least in our environment (gcc and g++ on RedHat), the C compiler seems to
know how to initialize global C++ objects. What I thought would be a problem
isn't a problem after all. In other environments the situation may be
different.
I would rather not use cobcrun anyway. Our current practice is to compile
binary executables on our development box and then install them on the
production box. As I understand it, with cobcrun we would install a bunch of
shared object files instead of binary executables, and all linkage would be
dynamic.
I won't try to address the advantages and disadvantages of static linkage
versus shared linkage, but static linkage is what we're using now, apart from
some third-party shared libraries. Switching everything to dynamic linkage
would be disruptive. It will be hard to sell GnuCOBOL to upper management if I
can't provide drop-in replacements for the existing executables.
There is another issue with cobcrun (at least I think there is; I haven't tried it). We
rely pretty heavily on being able to see what's running by using the ps utility and
looking at the executable name. If cobcrun is running foobar.so, then ps will presumably
report an instance of cobcrun. We will see "foobar" as part of the command
line, but our scripts may not recognize it there. Things could get very messy,
especially during the transition when a growing subset of programs are running under
cobcrun and others are still running as free-standing executables (along with our C and
C++ programs).
The earlier suggestion (writing a thin C++ wrapper for every COBOL program)
would be disruptive in other ways.
Today we have foobar.cob that gets compiled to foobar.o and linked into
foobar.exe (yeah, we use the Windows convention for naming executables). A C+
wrapper would presumably be named foobar.cpp, and it would get compiled to
foobar.o -- oh, wait, we're already using that name for the object file from
foobar.cob.
No doubt we could come up with some kind of naming convention to avoid these
collisions, but it would almost certainly be messy and disruptive.
Fortunately none of these forms of disruption appears to be necessary.
Scott McKellar
----- Original Message -----
From: Simon Sobisch <address@hidden>
To: Scott McKellar <address@hidden>
Cc: address@hidden
Sent: Friday, November 14, 2014 7:06 AM
Subject: Re: Calling C++ from GNU COBOL
Hi Scott,
Sergey Kashrin suggested to simply compile the current cobcrun with a
C++ compiler (maybe rename it to cobcrun.cpp) and start the COBOL
modules via the resulting executable (one c++ main for all COBOL modules
- identical to what I suggested but less to code).
Did you tested this?
How does this entail a sizeable disruption to your existing code base
and development practices?
Simon
Date: Tue, 11 Nov 2014 08:09:31 -0800
From: Scott McKellar <address@hidden>
Subject: Re: [open-cobol-list] Calling C++ from GNU COBOL
To: "address@hidden"
<address@hidden>
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=us-ascii
Responding to my own post...
Simon Sobisch and Patrick both suggested that I write a small wrapper in C++
that would call the real program in COBOL and not do much else. I had
considered that briefly, but I had hoped to avoid that approach. It would
entail a sizable disruption to our existing code base and development practices.
Also, Brian mused about possibly adding explicit support in GNU COBOL for
calling C++ routines.
Finally I got around to what I should have done in the first place, namely some
experimentation.
I got my Hello World program (in COBOL) to link to a little C++ routine that
wrote a message to standard output using std::cout (I had to add the -lstdc++
option to the compile line). Rather to my surprise, it worked.
Thinking there might be something special going on with std::cout, I concocted
a little class whose constructor stores a time stamp for the current date and
time. Then I declared a static instance of that class and referenced it from
my little C++ routine. That worked too. The static instance got initialized
somehow, even though the top-level program was in COBOL.
I also tried calling the same routine from C, with GNU COBOL taken out of the
picture. It still worked.
Conclusion: at least in my environment (gcc and g++ on RedHat Linux), C knows
how to initialize static objects defined in C++.
For my purposes, I think that's good enough, provided that I'm willing to
sacrifice some portability.
However I wouldn't generalize this finding to other environments. I have read
warnings about calling C++ from other languages, but the danger is highly
system-specific.
----------
In the more general case, one might find oneself on a system where the C
compiler isn't smart enough to initialize C++ standard objects. In that case,
maybe the following approach would work:
If GNU COBOL is compiling a module that includes a main(), it could contrive to
compile it as C++, instead of C, provided that a C++ compiler were available.
Then the top-level module would be in C++ and it would know how to initialize
static objects.
This approach assumes that the C code generated by GNU COBOL is compilable as
C++, or could be made compatible with a minimum of fuss. The main issue would
be to make sure that suitable function prototypes were in scope. I don't know
how much of a big deal that would be.
----------
Thanks to all who responded.
Scott McKellar
________________________________
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
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list