Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[gwinn@ma.ultranet.com (Joe Gwinn)]

In article <dewar.893595400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
[snip]
> <<By the way, coders don't choose languages, managers do.>>
> 
> That's perfectly reasonable. Indeed "coders" often don't have the perspective
> to make a choice. What is important is that whoever makes the decision,
> no matter what their title be, have the kind of technical knowledge that
> is needed to make a sound decision. All too often managers don't know enough
> of the details to make sensible decisions. I have seen managers choose a
> programming language when they knew absolutely nothing about the language
> at all.

So have I.  Choice of language is only rarely a technical issue.  Nor are
managers likely to become more technical.  Sorry.


> By the way "coders" is a rather contemptous term for a manager to use. I
> trust you are not operating in an environment where you really have people
> coding who understand nothing in the programming process other than actual
> coding. That was a model used by many COBOL shops in the 60's and 70's (the
> very ones who give us the Y2K headaches today), and is largely discredited.
> Certainly in the kind of technical area for which Ada is used, I would look
> for programmers with excellent knowledge of both Ada and the entire
programming
> process to be involved.

Call "coders" programmers if you like, or even software engineers; it
makes little difference, and I've been called all of these, and worse.

 
> <<You know, just listening to the newsgroup traffic for a year would give
>   one the idea that there might be an issue or two here.  I recall lots of
>   C/C++ to Ada interface questions.  Do you think there might be a pattern
>   in all those unsubstantiated postings?>>
> 
> I am always suspicious of people lumping C/C++ together in one breath as
though
> they are one language. They are most definitely NOT one language. 

Of course not, but close enough for my purposes.  There is after all a
more than passing relationship between C and C++, and Ada95 is close to
neither.


> ... If you look
> at these posts, you will find the following clear pattern.
> 
>   In the case of C, the Ada 95 definition is adequate. The one remaining
>   glitch of which I am aware, namely the issue of passing structs' by value
>   (not such a common occurrence) is handled by the pragma C_Pass_By_Copy,
>   implemented compatibly in GNAT and Intermetrics (i.e. including Green
Hills).
> 
>   In the case of C++, no C++ standard was in effect at the time that Ada was
>   standardized (indeed as I assume you know, the C++ standard is very recent).
>   So there is no standardized method in the Ada 95 RM for interfacing directly
>   to C++. In practice there is no problem because C and C++ can interoperate,
>   and Ada and C can interoperate, so a portable solution can be created by 
>   using a C interface layer (this is the sort of knowledge that should be
>   at hand in any work you do in this area).
> 
>   GNAT does provide a set of pragmas for direct interfacing to C++, but
>   these are not a standard part of the language. The ARA technical committee
>   has made some progress towards a common set of interfaces for C++, but
>   this work is not yet complete.
> 
>   Quite a few of the posts you are talking about have to do with using these
>   special GNAT features. This is an area that you cannot expect Ada
>   programmers to be familiar with, and indeed we definitely spend time
>   helping our supported customers use these GNAT-specific problems.
> 
>   But for most purposes the use of an intermediate C layer solves the
>   problems. Whether this is true in your case (or whether your case 
>   involves C++ at all) remains to be seen pending some more technical
>   details on the problems that you actually face.

I would have to point out that we need *portable* but *bulletproof* 
Ada95-C/C++ interfaces.  With any chosen fixed set of compilers, one can
usually get things to work well enough.  If portability is required,
things get much harder.  In any case, it doesn't much matter what
theoretical portability features are claimed, as this is a particularly
difficult and bug-ridden area.

There are two Ada-C/C++ issues here:  Direct subroutine calling, and also
passage of messages back and forth.


> <<As I said, I will dig up a list, probably next week.>>
> 
> We look forward to it. A list would be very instructive, but even ONE
> clear technical answer would help get this conversation out of the rather
> uninformative philosophical level onto a technical level.

Doesn't seem too promising, does it? 


Joe Gwinn