comp.lang.ada
 help / color / mirror / Atom feed
* Calling Ada from C++ (MS Visual C++)
@ 2002-04-05  8:30 Julian Robbins
  2002-04-05 18:18 ` Stephen Leake
  0 siblings, 1 reply; 7+ messages in thread
From: Julian Robbins @ 2002-04-05  8:30 UTC (permalink / raw)


Hi All,

I have a question regarding calling Ada from Microsoft Visual C++. I
am currently in the situation where I can export a function from an
Ada package and then compile this into my C++ application, following
the standard approach of pragma Export. For example, I have the
spec/code as follows:

     package MathUtil is
        function Square( Value : in Float) return Float ;
        pragma export (CPP, Square, "ada_square") ;
     end MathUtil;

     package body MathUtil is
        function Square( Value : in Float) return Float is
        begin
           return Value * Value ;
        end Square;
     end MathUtil ;

I can use gcc command (GNAT 3.14) to compile this into a .o file,
include this in my Visual C++ project and then simply call the
"ada_square" function from anywhere in my C++ code. This works and
produces an executable that does what it is supposed to.

However, this is a very simplistic model. I have done much reading on
the subject of interfacing Ada and C++ and I believe that the above
approach would fall over as soon as I started to put any real code in
the Ada section. Specifically I am talking about the Ada executive
functions and "ellaboration". The C++ program is the 'main' program
and so no Ada 'main' is yet being called. Could some please comment on
whether my assertion is correct? If I only include the .o files, at
some point it is going to fall over horribly?

So, using GNAT I believe that I can include the 'adainit()' and
'adafinal()' in the binding stage using 'gnatbind -n mathutil.ali'.
However, this seems to produce a .o file that I could then only use
with gnatlink to link the C++ objects and Ada objects together. This I
can not do - I need to use MS Visual Studio to link the final
executable, including any relevant Ada objects.

My big question, therefore, is : Is this possible? Can I use the GNAT
tools to create the adainit() and adafinal() functions in such a way
that I can then simply include the object files into my Visual Studio
project?

Thanks in advance for any help!

Julian Robbins
Software Engineer
Logica UK



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Calling Ada from C++ (MS Visual C++)
@ 2002-04-05 10:26 Caldwell Ian
  0 siblings, 0 replies; 7+ messages in thread
From: Caldwell Ian @ 2002-04-05 10:26 UTC (permalink / raw)


You can use a DLL. Have a look at 'Microsoft Windows Topics' section in the gnat user guide.

Ian Caldwell
Q218 
QinetiQ Malvern 
+ 44 (0) 1684 89 4461


-- 
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution, 
or any action taken or omitted to be taken in reliance on such information is
prohibited and may be unlawful.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Calling Ada from C++ (MS Visual C++)
  2002-04-05  8:30 Julian Robbins
@ 2002-04-05 18:18 ` Stephen Leake
  2002-04-11  8:51   ` Julian Robbins
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Leake @ 2002-04-05 18:18 UTC (permalink / raw)


julian_robbins@bigfoot.com (Julian Robbins) writes:

> So, using GNAT I believe that I can include the 'adainit()' and
> 'adafinal()' in the binding stage using 'gnatbind -n mathutil.ali'.
> However, this seems to produce a .o file that I could then only use
> with gnatlink to link the C++ objects and Ada objects together. This I
> can not do - I need to use MS Visual Studio to link the final
> executable, including any relevant Ada objects.

You can link the .o file containing adafinal() and adainit() with your
C++ code, same as any other Ada .o.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Calling Ada from C++ (MS Visual C++)
  2002-04-05 18:18 ` Stephen Leake
@ 2002-04-11  8:51   ` Julian Robbins
  2002-04-11 17:15     ` Stephen Leake
  0 siblings, 1 reply; 7+ messages in thread
From: Julian Robbins @ 2002-04-11  8:51 UTC (permalink / raw)


Okay, so here is what I have done...

Compiled the original "mathutil.adb" into "mathutil.o". Then used
"gnatbind -n mathutil" which produced the files "b~mathutil.adb" and
".ads". I then compiled these using gcc and renamed the resulting .o
file "main.o".

Within my VC++ project I have then included the mathutil.o and main.o
files, added calls to adainit() and adafinal() and then
compiled/linked. This throws up various missing links, so I have
included the following library files:
   libgnat.a
   libgcc.a
   libmingw32.a

Does this seem correct?? It seems to compile and run, but I can't help
thinking that this process seems a bit odd.

Cheers,

Julian



Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<u1yduhuw5.fsf@gsfc.nasa.gov>...
> julian_robbins@bigfoot.com (Julian Robbins) writes:
> 
> > So, using GNAT I believe that I can include the 'adainit()' and
> > 'adafinal()' in the binding stage using 'gnatbind -n mathutil.ali'.
> > However, this seems to produce a .o file that I could then only use
> > with gnatlink to link the C++ objects and Ada objects together. This I
> > can not do - I need to use MS Visual Studio to link the final
> > executable, including any relevant Ada objects.
> 
> You can link the .o file containing adafinal() and adainit() with your
> C++ code, same as any other Ada .o.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Calling Ada from C++ (MS Visual C++)
  2002-04-11  8:51   ` Julian Robbins
@ 2002-04-11 17:15     ` Stephen Leake
  2002-04-16 12:27       ` Karel Miklav
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Leake @ 2002-04-11 17:15 UTC (permalink / raw)


julian_robbins@bigfoot.com (Julian Robbins) writes:

> Okay, so here is what I have done...
> 
> Compiled the original "mathutil.adb" into "mathutil.o". Then used
> "gnatbind -n mathutil" which produced the files "b~mathutil.adb" and
> ".ads". I then compiled these using gcc and renamed the resulting .o
> file "main.o".

I wouldn't call it "main", since it is _not_ your C "main". Call it
"ada_elab_stuff". Or at least "ada_main". Actually, there's nothing
wrong with "b~mathutil" :).

> Within my VC++ project I have then included the mathutil.o and
> main.o files, added calls to adainit() and adafinal() and then
> compiled/linked. This throws up various missing links, so I have
> included the following library files: libgnat.a libgcc.a
> libmingw32.a
> 
> Does this seem correct?? 

Yes, you've got it.

> It seems to compile and run, but I can't help thinking that this
> process seems a bit odd.

Welcome to the world of multi-language multi-vendor programming :).

You've got it easier than I did; I was using Borland C++, which has a
different object file format than GNAT on Win32. So I had GNAT build a
DLL to link with Borland. Reverse engineering the naming conventions
took a while!

Just out of curiosity, why are you using MS C++ instead of Gnu C++?
I'll assume it's to get MFC.

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Calling Ada from C++ (MS Visual C++)
  2002-04-11 17:15     ` Stephen Leake
@ 2002-04-16 12:27       ` Karel Miklav
  2002-04-16 14:07         ` Stephen Leake
  0 siblings, 1 reply; 7+ messages in thread
From: Karel Miklav @ 2002-04-16 12:27 UTC (permalink / raw)


> Just out of curiosity, why are you using MS C++ instead of Gnu C++?
> I'll assume it's to get MFC.

I'm considering options to escape from MS world (VC++/VB/scripting/COM/),
mostly get rid of VC. Is it possible to use Gnu C++ on Windows box as an
industry-strenght compiler with possibilities to interface to other
languages like Ada and Eiffel without too much hassle (hassle = 90% of time
spent on interfacing)?

Regards,
Karel Miklav






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Calling Ada from C++ (MS Visual C++)
  2002-04-16 12:27       ` Karel Miklav
@ 2002-04-16 14:07         ` Stephen Leake
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Leake @ 2002-04-16 14:07 UTC (permalink / raw)


"Karel Miklav" <karel@inetis.removeme.com> writes:

> > Just out of curiosity, why are you using MS C++ instead of Gnu C++?
> > I'll assume it's to get MFC.
> 
> I'm considering options to escape from MS world (VC++/VB/scripting/COM/),
> mostly get rid of VC. Is it possible to use Gnu C++ on Windows box as an
> industry-strenght compiler with possibilities to interface to other
> languages like Ada and Eiffel without too much hassle (hassle = 90% of time
> spent on interfacing)?

Interfacing Gnu Ada and Gnu C++ is easier than interfacing Gnu Ada and
non-Gnu C++. Neither is standard; the simplest way is to use C as the
intermediate language. But Gnu Ada does support directly
importing/exporting Gnu C++ classes. 

I'm not clear on Eiffel; if it supports exporting functions to Gnu C,
then interfacing it with Gnu Ada will be simple.

"industry-strength" is a very ambiguous term. If you mean "supported
by a strong company with a good rep", then Gnu Ada is
industry-strength. If you mean "comes with lots of widgets that do 90%
of my business GUI app", then no, Gnu Ada is not.

The amount of "hassle" involved in interfacing depends heavily on what
libraries you are interfacing to. 

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2002-04-16 14:07 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-05 10:26 Calling Ada from C++ (MS Visual C++) Caldwell Ian
  -- strict thread matches above, loose matches on Subject: below --
2002-04-05  8:30 Julian Robbins
2002-04-05 18:18 ` Stephen Leake
2002-04-11  8:51   ` Julian Robbins
2002-04-11 17:15     ` Stephen Leake
2002-04-16 12:27       ` Karel Miklav
2002-04-16 14:07         ` Stephen Leake

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox