Difference between ADA and c++

Difference between ADA and c++

[Mr Doshi]

Hello

I have used ADA for one year and now want to learn C++.
Could someone please tell me the essential differences between them?

thankyou Viresh

Library model in Ada. was Re: Difference between ADA and c++

[Nasser]

In article <01bcafdf$50784b80$7774d8cc@fatman>, "Michael says...
>
>Here are several comparisions of Ada and C++ on the www:
>
>Langauge comparisons:
>
>A Comparison of Ada, C, and C++ 
>http://rep1.iei.pi.cnr.it/projects/JADA/ada-collection/tuft.html 
>

thanks for the pointers! I did not have some of these before.

Now, I was reading this below, from the above paper:

"1) Separate Compilation and Library Management   

   Ada: An Ada compiler is required to enforce consistency and
strong type checking across separate compilation.  The concept of
                                                   ^^^^^^^^^^^^^^
a program library is built into the language, based on separately
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
compilable modules called "library units" whose names are part of 
a hierarchical name space."

GNAT, probably the most popular Ada95 compiler, does NOT use the
program library model, but uses the code-source model, i.e. the 
traditional model.

So, what going on here? who is wrong, and who is right? 

thanks,
Nasser

Re: Difference between ADA and c++

[Nasser]

In article <01bcafdf$50784b80$7774d8cc@fatman>, "Michael says...
>
>Here are several comparisions of Ada and C++ on the www:
...
>Comparing Development Costs of C and Ada
>http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html 
>

From the above article :

"Conclusions 

The cost, quality, and other metrics data displayed in Tables 1 through 
4 permit me to make the following three conclusions, none of which will 
make me popular with my many friends in the Ada community: 

<cut>

The jury is still out on Ada95. There are still too few users to 
determine if Ada95 will deliver its promised benefits. Those who use 
the language to develop products complain that poor compilers and the 
lack of tools and bindings make their jobs difficult. 

C and C++ have become more cost-effective. The costs and quality 
advantages Ada has enjoyed over C and C++ have almost disappeared 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
as these languages have become more widely used. The only application
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
domain where Ada currently seems to hold a cost advantage is airborne 
and spaceborne avionics." 

What I dont understand about the above statment is this:
If you agree that langauge A is better than language B, then 
how could the more use of B makes A advantage over B disappear? 

This is like saying, if something does not taste as good, then by 
eating more of it, it will, somehow, starts to taste as good.

Nasser

Re: Difference between ADA and c++

[Robert Munck]

On Fri, 22 Aug 1997 18:50:50 +0100, Mr Doshi <viresh.doshi@virgin.net>
wrote:

>I have used ADA for one year and now want to learn C++.
>Could someone please tell me the essential differences between them?

Ada is good.
C++ is bad.

Bob Munck

Re: Difference between ADA and c++

[Dale Stanbrough]

"   Ada: An Ada compiler is required to enforce consistency and
 strong type checking across separate compilation.  The concept of
                                                    ^^^^^^^^^^^^^^
 a program library is built into the language, based on separately
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 compilable modules called "library units" whose names are part of 
 a hierarchical name space."
 
 GNAT, probably the most popular Ada95 compiler, does NOT use the
 program library model, but uses the code-source model, i.e. the 
 traditional model."

Gnat does have a program library, just as Intermetrics also has
a program library. The library just happens to be implemented as
a series of source code files, and not some mysterious black box
piece of software.

List through the requirements of such a library, and you'll find
that the source code model can meet them.

Dale

Re: Difference between ADA and c++

[Robert Dewar]

Nasser quotes

<<C and C++ have become more cost-effective. The costs and quality
advantages Ada has enjoyed over C and C++ have almost disappeared
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
as these languages have become more widely used. The only application
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
domain where Ada currently seems to hold a cost advantage is airborne
and spaceborne avionics.">>


It is always entertaining when someone says "the jury is out", and then
proceeds to appoint themselves as the lord high replacement jury, and
make a ex-cathedra judgment with no data.

In fact nothing significant has changed in C and C++ that would make
them more eeffective in generating high quality code, so that implication

is certainly bogus. If the point is that C++ compilers have become cheaper,
true, but hardly significant.

At this stage, the cost of the compiler tool suite is not a significant
factor in choice between Ada and C++ (for example, the tool suites from
SGI are pretty much identical in cost).

Furthermore, now that costs of high quality Ada technology has dropped
substantially, the cost of these tools is not usually a very significant
part of the costs of a large project, certainly it pales compared to the
costs of generating unreliable code.

Re: Library model in Ada. was Re: Difference between ADA and c++

[Robert Dewar]

Nasser says

<<Now, I was reading this below, from the above paper:

"1) Separate Compilation and Library Management

   Ada: An Ada compiler is required to enforce consistency and
strong type checking across separate compilation.  The concept of
                                                   ^^^^^^^^^^^^^^
a program library is built into the language, based on separately
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
compilable modules called "library units" whose names are part of
a hierarchical name space."

GNAT, probably the most popular Ada95 compiler, does NOT use the
program library model, but uses the code-source model, i.e. the
traditional model.

So, what going on here? who is wrong, and who is right?>>



The quoted sentence is somewhat historical at this stage, but if you
take a sufficiently abstract view of what a library is (note that the
Ada 95 reference manual substitutes the term "compilation environment",
for this term), then the statement is in fact accurate.

The big change in Ada 95 is to make it much clearer that the library
(compilation environment) is an implementatoin depenbdent abstract
concept, not some kind of file or collections of files (necessarily).

The GNAT source approach (now used by other compilers, including
those that use the Intermetrics front end), does in fact conform
with the requirements in Ada 83, although one needs to be a bit
more imaginative in reading the Ada 83 RM.

Certainly in terms of the differences between Ada and C++, the point
made in the quoted section is 100% valid and important.

Re: Difference between ADA and c++

[Robert Dewar]

Dale says

<<Gnat does have a program library, just as Intermetrics also has
a program library. The library just happens to be implemented as
a series of source code files, and not some mysterious black box
piece of software.

List through the requirements of such a library, and you'll find
that the source code model can meet them.>>


Actually we really should stop using the term program library, since it
is an Ada 83 term.

Also, the compilation environment in GNAT is not quite a set of sources,
there is additional information, including the gnat.adc file, and ali
and object files in some cases (you can have a consistent compialtion
environment in which some of the units are precompiled, and their
sources are not available).

Re: Difference between ADA and c++

[Brian Rogoff]

I've read all of those comparisons of Ada and C++ and I am struck by the 
one-sidedness of the feature comparisons. Ada enthusiasts should be 
particularly sensitive to this sort of thing, since devotees of numerous 
other language tools similarly disparage Ada. While I am not a real fan of 
C++, I have used some dialects of it and I've watched the progress of the 
Standard a little. There are certainly aspects of C++ which can be compared 
with corresponding features of Ada and appear (to me) superior. Two which 
come to mind are 

(1) The ability to interleave public/private/protected regions in a C++
    class definition.

(2) The ability to automatically infer instantiations of generic functions.
    This is a feature of C++ genericity I really like, which could be 
    added to Ada one day :-).

There are also other things you can do with C++ templates, including all
kinds of compile time calculations, but I'm not so sure that's good.

-- Brian 


On 23 Aug 1997, Michael Quinn wrote:

> Here are several comparisions of Ada and C++ on the www:
> 
> Langauge comparisons:
> 
> A Comparison of Ada, C, and C++ 
> http://rep1.iei.pi.cnr.it/projects/JADA/ada-collection/tuft.html 
> 
> Comparison of Ada and C++ Features  
> http://www.adahome.com/articles/1997-03/ada_vs_cpp.html
> 
> Ada Can Do It! (Common false claims about things Ada won't let you do,  and
> how to do them (and why some are not directly supported) 
> http://www.adahome.com/articles/1997-06/am_cando.html 
> 
> Ada, C, C++, and Java vs. The Steelman 
> http://www.adahome.com/History/Steelman/steeltab.htm
> 
> C++?? : A Critique of C++  
> http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html 
> 
> 
> Cost of Development Comparisions:
> 
> Comparing Development Costs of C and Ada
> http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html 
> 
> Quantifying the Debate: Ada vs. C++  
> http://www.stsc.hill.af.mil/crosstalk/1996/jul/quantify.html 
> 
> 
> 
> 
> Mr Doshi <viresh.doshi@virgin.net> wrote in article
> <33FDD17A.320B@virgin.net>...
> > Hello
> > 
> > I have used ADA for one year and now want to learn C++.
> > Could someone please tell me the essential differences between them?
> > 
> > thankyou Viresh
> > 
> 
> 

Re: Difference between ADA and c++

[Brian Rogoff]

On Wed, 27 Aug 1997, W. Wesley Groleau x4923 wrote:
> I agree that tons of instantiations can be a lot of clutter.
> However, every time I have come across tons of instantiations,
> it has been because someone (1) had an aversion to putting unrelated
> items in distinct packages, (2) had a bad habit of declaring several
> types that all did the same thing (zillions of type conversions
> is another symptom of this one) and/or (3) had an aversion to higher
> level generics when there was clearly a lot of unnecessary repetition.

OK, I have no such problem to seeking out the best use of the features of 
the language to enhance readability. I read my own code, and I have a small 
brain. But, I make heavy use of genericity as an abstraction mechanism.

> I can see from your responses to RBKD and JSA that there may be
> times where your idea would indeed help readability.  However,
> I still think the potential for misuse is too great.  The reason I
> equated it with promotions and demotions is that there is the same
> potential for problems.

I don't see this. The type checker still flags any problems. In fact, I
would expect that any inferencing algorithm chosen would be particularly 
conservative, and not allow many legal automatic instantiations. These 
would then have to be explicitly instantiated. 

>  With a type mismatch in Ada, the compiler
> forces you to be sure you know what you're doing.  In C, the compiler
> assumes you know what you're doing and automatically forces the 
> variables to cooperate--no matter what the result.  

That is automatic *coercion* of types, not type inference. I suggest you 
read Shen and Cormack's Tri-Ada 91 paper in order to get an idea of what 
I am proposing. 

> To me, having the
> compiler implicitly overload instantiations on different types is
> similar (although clearly not as dangerous as promotions and demotions).

More dangerous than regular overloading of subprograms based on argument
types? More dangerous than use clauses? Sounds like you'd prefer Modula 3 
or Oberon to Ada, at least on these grounds. I *prefer* these aspects of 
Ada.

-- Brian
 

Re: Difference between ADA and c++

[Robert Dewar]

Jon says

<<I don't think Brian meant that this would make them easier to read (he
said "superior") I think it would make them more difficult to read,
but in some sense "easier to write"...>>

OK, but the only justification for a feature in Ada is if it makes programs
easier to read, or at the very least is neutral. Any feature that makes
programs more difficult to read is outside the design parameters. Ada has
always favored the reader over the writer in the design!

Re: Difference between ADA and c++

[Robert Dewar]

Regarding the ANSI standard for C++ (or rather lack there of).

I saw the other day someone carrying a big tome with a giant letters
title of 

A N S I  C + +

Sorry I can't make 50 point letters in email P :-)

The in minuscule text almost invisible to the naked eye was the word
"draft"

:-)

Re: Difference between ADA and c++

[Jon S Anthony]

In article <3403A080.2A07@pseserv3.fw.hac.com> "W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> writes:

> I still think the potential for misuse is too great.  The reason I
> equated it with promotions and demotions is that there is the same
> potential for problems.

Actually, I believe the more appropriate comparison would be with
macros - and in particular real macros.  Not the sort of simplistic
stuff you have in C, but something like CL macros.  The potential for
_really_ _big_ wins would be there - as well as the potential for
completely obscure code that no one can understand what it is.

Hmmmm, (somewhat off topic here) it just occured to me that you
could probably write the entire C++ template language as an embedded
language in CL using macros.  Anyone have a reason why that might not
be true?  In which case, AS's odd claim of a couple months or so ago
in c.l.l that only C++ with its templates was capable of expressing
the STL loses all meaning (not that it had much to begin with).

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Difference between ADA and c++

[Jon S Anthony]

In article <Pine.SGI.3.95.970826174002.24873B-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> On 26 Aug 1997, Jon S Anthony wrote:
> > 
> > I don't think Brian meant that this would make them easier to read (he
> > said "superior") I think it would make them more difficult to read,
> > but in some sense "easier to write"...
> 
> Cool, we disagree :-). Certainly, if I thought that adding type inference 

Sacre Bleu!


> Jon, I'm interested in knowing exactly why you think it would make programs 
> more difficult to read, especially if the automatic instantiation was 
> optional.

Only in the sense that many large scale things are happening and
propagating behind the scenes.  Sort of like the old issue with macros
where you can end up not having even a clue as to what is happening or
what the actual result is.  Of course, as you say eleswhere, this is
simply a matter of abuse (vs. use).


> My experience has been that long instantiation sections tend to
> contribute nothing to my understanding of a program, much like most
> of the comments I read, and just obscure things. I certainly accept
> that your experience might be different, so I'm all ears.

This is an excellent point.  I think you said it elsewhere as "more
visible code does not imply more clear".


> Have you used Haskell or ML (SML or CAML)? These languages do type

I've looked into ML and now (from an earlier suggestion by you) OCAML.


> inference for everything, and I find the short code to be fairly
> readable.

Yes, but I'm not sure how well this translates for large scale system
maintenance and understanding.  When you get down to it, type
inference is more an efficiency thing (literally and for the writer as
well) than anything else (another example, Baker has an interesting
paper on how to piggy back storage inference on top of type inference
to increase GC efficiency).


> I think it is better to be mostly explicit, and so I favor the Ada
> approach in general, but a little type inference in the right place
> seems like a big win.

Sounds reasonable, but how/where do you draw the line?  Maybe that's
easier than I think??

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Difference between ADA and c++

[Jon S Anthony]

In article <5u0hj7$enj$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> Re (2):  it is my understanding that this is one of the main reasons why
> template handling appeared late, buggy, slow, and disc-hungry in C++
> compilers.  It also raises hosts of issues concerning where things get
> defined.  I have tried and tried to understand what the C++ draft standard
> says about this, and it has me baffled.

If it has you baffled, then certainly the rest of us are without hope,
:-)

[good stuff about C++ template machinery and Ada generics snipped]

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Difference between ADA and c++

[Jon S Anthony]

In article <dewar.872654913@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon says
> 
> <<I don't think Brian meant that this would make them easier to read (he
> said "superior") I think it would make them more difficult to read,
> but in some sense "easier to write"...>>
> 
> OK, but the only justification for a feature in Ada is if it makes programs
> easier to read, or at the very least is neutral. Any feature that makes
> programs more difficult to read is outside the design parameters. Ada has
> always favored the reader over the writer in the design!

Brian claims I was in the weeds with this "interpretation" of what he
said - so don't pay any attention to what I said here.  Sorry for the
rubbish.

I believe all three of us are in synch. on the read-vs-write tradeoff
in Ada, I just missed his point...


/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Difference between ADA and c++

[Samuel Mize]

Mike Young wrote:
> I offer the following without necessarily endorsing or agreeing
 with the
> preceding pro-C++ comments. ANSI standardization can be considered a
> significant event for C++.

A couple of folks have responded by pointing out that C++ is
as yet has no ANSI standard.  I think Mr. Young was referring
to the currently-ongoing PROCESS of ANSI standardization, in
the light of which his following comments are sensible:

> If nothing else, language support is much
> improved in many compilers [not a laughing matter], and there are now
> common libraries for defining and manipulating ADT's. The days of
> balancing Microsoft/Borland/gcc/RogueWave library features promise to
> disappear someday.

(Of course, these ARE laughing matters for Ada developers.)

Sam Mize

Re: Reasons why Ada is no success yet

[Joachim Schroeer]

Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote in article
<34045A8A.52E7@gsfc.nasa.gov>...

> Joachim Schroeer wrote:
> > Use bindings
> > ============
> > Libraries written in C++ are no reason, why C++ should make software
> > development more easy than Ada. C++ libraries may be used by Ada
> > developers as good as by C++ developers.
> > Ada95 can be combined with C and GNAT can bind C++.

> Sorry, many libraries consist of templates, which you cannot bind to
> Ada; you have to rewrite them as Ada generics. This will be a Good Thing
> when it gets done, but it is not easy.
> 

Ok, but is it not possible to bind the instantiations?

And what is with the SGI tool?, They built a binding to the inventor
library with it.

  Joachim

Re: Difference between ADA and c++

[Michael Young]

Richard A. O'Keefe wrote:

> >The days of
> >balancing Microsoft/Borland/gcc/RogueWave library features promise to
>
> >disappear someday.
>
> Yes, yes, jam tomorrow.  I am sick of jam tomorrow.  The last
> third-party
> C++ library I installed had to be installed twice, once for each
> compiler,
> and if we had a third compiler we'd need to install a third copy.  At
> least
> with Ada I have jam _today_.

I was referring to the large body of existing code using the "old"
libraries, not yearning for something new. The libraries are widely
available now, and have been for some time. (If it matters, I agree you
would not have similar problems, given the underwhelming selection of
Ada compilers and products. You not only don't have _jam_ _today_, you
barely have the pots and pans with which to make it.)

I stated that Ada lags behind C++ in general development because it
lacks the library support C++ enjoys. I'm hearing arguments that amount
to: "Y'all ain't got none neither," when plainly, I see useful work
being done every day. There is library support for every domain you care
to name. For Ada, there are none. Zippo. Zero. Zilch. Nada.

Anyway, I thought it of more than passing academic interest to share
this deep, unique insight. I was rather hoping to hear positive
responses of _jam_ in the making, not the steadfast denial of a few.

(Back to lurking. Wake me when you rediscover _jam_.)

Michael.

========================================
** If at first you succeed, hide your astonishment. **