Re:Compiling, binding, and linking an Ada prog. interfaced with C

Re:Compiling, binding, and linking an Ada prog. interfaced with C

[You4818]

Hi

I am trying to interface an Ada program to C, such that the main
program is in Ada and some entities are being imported from a 
C header file (e.g. constant variables).

For example, consider the following 

C_File.h  :  #define  Max_Val 100


Ada_File.adb : with Interfaces.C ;
				procedure Ada_File is
				MAX_VAL : Integer ;
				pragma Import(C,MAX_VAL,"Max_Val") ;

				begin
					...... process MAX_VAL ;
				end Ada_File ;


How do I compile, bind and link the above files (where Ada_File
is the main program).


Thanks in advance
Samir

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Ronald Ali]

On Mon, 27 Jul 1998 15:09:37 GMT, dennison@telepath.com wrote:

>In article <1998072706002200.CAA02664@ladder01.news.aol.com>,
>  you4818@aol.com (You4818) wrote:

Snip

>If you have a lot of them, there is a C conversion tool available to help
>automate the process. Check HOTBAP.
>

We are in need of a C conversion tool.
Please tell me where to find "HOTBAP."

Ronald Ali
RonAli@WriteMe.com

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Dr Richard A. O'Keefe]

You4818 wrote:
> I am trying to interface an Ada program to C, such that the main
> program is in Ada and some entities are being imported from a
> C header file (e.g. constant variables).
> 
> For example, consider the following
> 
> C_File.h  :  #define  Max_Val 100

I see no constant variable here.  All I see is a macro.
If you tried to link this with other *C* code, say

 D_File.c:    extern int Max_Val;

it wouldn't link.  If you want a read-only object in C that
can be accessed from another C file (let alone an Ada file),
you should put

    int const MaxVal = 100;

in a .c file.

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Fergus Henderson]

"Dr Richard A. O'Keefe" <ok@atlas.otago.ac.nz> writes:

>You4818 wrote:
>> I am trying to interface an Ada program to C, such that the main
>> program is in Ada and some entities are being imported from a
>> C header file (e.g. constant variables).
>> 
>> For example, consider the following
>> 
>> C_File.h  :  #define  Max_Val 100
>
>I see no constant variable here.  All I see is a macro.

This is true.  It's a constant value, implemented using a macro,
rather than a constant variable.  The original poster's terminology
was not quite right.  Nevertheless, it is still an "entity",
and it is still something which it makes sense to import into
another language.

This is one respect in which Ada's otherwise excellent C interface
features are not quite as good as those of Mercury or ISE Eiffel,
which both allow you to import C macros without having to write a
separate C file containing glue code.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Robert I. Eachus]

In article <6pn02g$2ue$1@mulga.cs.mu.OZ.AU> fjh@cs.mu.oz.au (Fergus Henderson) writes:

 > This is one respect in which Ada's otherwise excellent C interface
 > features are not quite as good as those of Mercury or ISE Eiffel,
 > which both allow you to import C macros without having to write a
 > separate C file containing glue code.

   Huh?  The Ada way to imitate C in this area is to run the C
preprocessor over your code and live with the result no matter how
bizarre, just like it works in C.  Of course, if you have C macros
that actually generate C source, then you can only use those inside
units written in C.

  Several Ada compilers come with C style preprocessors as well.  But
not many people use them.  Ada programmers don't like obfusticated
code, and the preprocessor is the easiest way to obfusticate things.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Robert Dewar]

<< > This is one respect in which Ada's otherwise excellent C interface
 > features are not quite as good as those of Mercury or ISE Eiffel,
 > which both allow you to import C macros without having to write a
 > separate C file containing glue code.
>>


Obviously "importing" C macros in full generality would mean inporting
the full syntax and semantics of C into the parent language, not something
that is remotely feasible at the language definition level if you ask me.
Sure a given implementation may be able to rig something up (e.g. if it
translates into C anyway).

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

><< > This is one respect in which Ada's otherwise excellent C interface
> > features are not quite as good as those of Mercury or ISE Eiffel,
> > which both allow you to import C macros without having to write a
> > separate C file containing glue code.
>>>
>
>Obviously "importing" C macros in full generality would mean inporting
>the full syntax and semantics of C into the parent language, not something
>that is remotely feasible at the language definition level if you ask me.

On the contrary, it is quite feasible.

Those syntax and semantics can be imported "by reference",
so there's no significant increase in the complexity of
the language or the length of the language standard.
It can be implemented without requiring the Ada compiler to
understand or even parse C syntax.

>Sure a given implementation may be able to rig something up (e.g. if it
>translates into C anyway).

As it happens, both ISE Eiffel and Mercury translate to C.  That's
probably what prompted us to invent the feature in the first place.
But the feature can be implemented quite easily even in an implementation
that does not normally translate to C.

For example, something that we plan for a future release of Mercury is an
interface to C++ macros.  Our compiler does not compile to C++ and nor
do we plan to make it do so.  Rather, we'll just get it to spit out
a few C++ code fragments for the `pragma import("C++ macro", ...)'
declarations, if any, and pass them to a C++ compiler,
while for the remainder of the Mercury module being compiled we will
generate C code as usual.

Yes, this implementation technique for interfacing with C (or C++) macros
will only work if you have a C (resp. C++) compiler around.  That is
not a drawback, since if you need to interface with C (resp. C++)
macros you're going to need that anyway, regardless of whether your
Ada (or Eiffel, or Mercury) compiler generates the interfacing stubs
automatically or whether you have to write them by hand.
And generally when doing inter-language interfacing you do have
compiler for both languages available anyhow.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Robert Dewar]

<<As it happens, both ISE Eiffel and Mercury translate to C.  That's
probably what prompted us to invent the feature in the first place.
But the feature can be implemented quite easily even in an implementation
that does not normally translate to C.
>>

No surprise! Yes, of course this is easy if you translate to C. But let's
have an example of implementing this where you do NOT translate into C.
I don't for a moment accept that this is technically reasonable or feasible.
It would be like requiring the acceptance of machine language inserts for
the IBM 370 on all targets.

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

><<As it happens, both ISE Eiffel and Mercury translate to C.  That's
>probably what prompted us to invent the feature in the first place.
>But the feature can be implemented quite easily even in an implementation
>that does not normally translate to C.
>>>
>
>No surprise! Yes, of course this is easy if you translate to C. But let's
>have an example of implementing this where you do NOT translate into C.

Do you mean where you do not translate this construct to C,
or do you mean where the implementation as a whole does not normally
translate things to C?

Of course for this specific construct you need to implement it by
translation to C.  Asking to implement it otherwise would indeed
be unreasonable.  But there's no reason why an implementation
that normally works by compiling directly to assembler or object files
can't handle occurrences of this specific construct by translation to C.

Would you be satisfied with an example of an implementation that
does not normally translate to C++, but allows interfacing to C++ macros?
I don't have one available right now, but one of the other members of
the Mercury team said he would have a go at implementing this at some
time in the future, and I don't expect that it will take him long to
implement once he gets around to it.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[David Coote]

Robert said:

>Obviously "importing" C macros in full generality would mean inporting
>the full syntax and semantics of C into the parent language, 

Well, you could just support a subset of the language via a macro facility 
interface to Ada. Certainly simple #def's like the one given earlier in the 
thread might be useful for compatibility/porting. As a C programmer for many 
years using Ada for the first time I for one would love to have some decent 
support for conditional compilation. 

David

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[tedennison]

In article <6q441b$o20$1@eplet.mira.net.au>,
  dccoote@werple.mira.net.au (David Coote) wrote:
> Well, you could just support a subset of the language via a macro facility
> interface to Ada. Certainly simple #def's like the one given earlier in the
> thread might be useful for compatibility/porting. As a C programmer for many
> years using Ada for the first time I for one would love to have some decent
> support for conditional compilation.

There are plenty of pre-processors out there you can use, if that's what you
want to do. I for one don't like pre-processors (particularly the source code
people generate for them), and am quite happy that the language doesn't have
one. But nothing's preventing you from using one yourself.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Compiling, binding, and linking an Ada prog. interfaced with C

[Fergus Henderson]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>fjh@cs.mu.oz.au (Fergus Henderson) writes:
>
> > This is one respect in which Ada's otherwise excellent C interface
> > features are not quite as good as those of Mercury or ISE Eiffel,
> > which both allow you to import C macros without having to write a
> > separate C file containing glue code.
>
>   Huh?  The Ada way to imitate C in this area is to run the C
>preprocessor over your code and live with the result no matter how
>bizarre, just like it works in C.

I don't see how that technique could work as a method for interfacing
to existing C code, because typical C header files contain (in addition
to the macros that you want to interface with) lots of C declarations
which would not be valid Ada syntax.

Furthermore it would have the following problem that you mention yourself:

>Of course, if you have C macros
>that actually generate C source, then you can only use those inside
>units written in C.

Indeed.  And so trying to use them in Ada source files would be at
best a violation of encapsulation, and more likely simply wouldn't work.
Even simple things like hexadecimal and octal constants would be
a problem.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.