Help me to chose between ADA 95 and C++

Help me to chose between ADA 95 and C++

[Robert]

I work with ORACLE on AIX at my job and I want to learn one
serious object oriented language.I have some expirience with Java
,but this is not what I want.At my opinion Java is good, portable
,easy to learn and debug but as a language is just a C++ without
things that programing in C++ makes as art.So I am trying to chose
between ADA 95 and C++.I don't know anything about ADA 95
,but I hearded that is wey good object oriented language, wey safe.
Please send me your opinion and answers to my questions:

1)Is enough good a combination Oracle + ADA 95 as a
  combination ORACLE + C++ or Java ?
2)Does exist any tool and library for GUI design with ADA 95
   on Windows 95/NT or X-Windows, comercial or free ?
3)How are things with finding jobs on Europe for ORACLE + ADA 95 ?
4)Is learning ADA 95 and profesional programing, debuging
  easiest than do this in C++ ?


                                          Thanks !
                                          Robert Bralic
                                          robert.bralic@si.tel.hr

Re: Help me to chose between ADA 95 and C++

[Andreas Winckler]

Robert wrote:
> 3)How are things with finding jobs on Europe for ORACLE + ADA 95 ?

We are searching for software engineers with this skills!


Greetings,

AW
-- 
=========================================================
Andreas Winckler
Dipl.-Ing.
Software engineering
FREQUENTIS Network Systems GmbH
Tel: (+49) (7541) 282 - 462  Fax: (+49) (7541) 282 - 299
http://www.frqnet.de

Re: Help me to chose between ADA 95 and C++

[Harald Schmidt]

in Beitrag [BEITRAG] schrieb Robert unter robert.bralic@si.tel.hr am
26.11.1999 11:48 Uhr:

> I work with ORACLE on AIX at my job and I want to learn one
> serious object oriented language.I have some expirience with Java
> ,but this is not what I want.At my opinion Java is good, portable
> ,easy to learn and debug but as a language is just a C++ without
> things that programing in C++ makes as art.So I am trying to chose
> between ADA 95 and C++.I don't know anything about ADA 95
> ,but I hearded that is wey good object oriented language, wey safe.
> Please send me your opinion and answers to my questions:
> 
> 1)Is enough good a combination Oracle + ADA 95 as a
> combination ORACLE + C++ or Java ?
> 2)Does exist any tool and library for GUI design with ADA 95
> on Windows 95/NT or X-Windows, comercial or free ?
> 3)How are things with finding jobs on Europe for ORACLE + ADA 95 ?
> 4)Is learning ADA 95 and profesional programing, debuging
> easiest than do this in C++ ?
> 
> 
> Thanks !
> Robert Bralic
> robert.bralic@si.tel.hr

Hi Robert,

...if you want to learn a serious OO language
why not using Smalltalk, everything is an object,
no friend functions, no abstract datatypes ;-)

Harald

Re: Help me to chose between ADA 95 and C++

[Andreas Winckler]

Harald Schmidt wrote:
> Hi Robert,
> 
> ...if you want to learn a serious OO language
> why not using Smalltalk, everything is an object,
> no friend functions, no abstract datatypes ;-)

... and no jobs in Europe. ;-)


AW
-- 
=========================================================
Andreas Winckler
Dipl.-Ing.
Software engineering
FREQUENTIS Network Systems GmbH
Tel: (+49) (7541) 282 - 462  Fax: (+49) (7541) 282 - 299
http://www.frqnet.de

Re: Help me to chose between ADA 95 and C++

[Florian Weimer]

Andreas Winckler <andreas.winckler@gmx.de> writes:

> > ...if you want to learn a serious OO language
> > why not using Smalltalk, everything is an object,
> > no friend functions, no abstract datatypes ;-)
> 
> ... and no jobs in Europe. ;-)

Well, I've seen a few customer-specific Smalltalk applications here
in Germany, and even with Smalltalk and the OO stuff, people who write
the code are still required...

Re: Help me to chose between ADA 95 and C++

[Richard D Riehle]

In article <B46461D2.259F%Harald.Schmidt@tomcat.de>,
	Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:

>....if you want to learn a serious OO language
>why not using Smalltalk, everything is an object,
>no friend functions, no abstract datatypes ;-)

Figure I might as well stir things up a little bit again.

Smalltalk is certainly a nicely designed language. However,
if one is serious about object-oriented programming, 
Ada is an excellent choice. The only appropriate alternative
to Ada, for serious OOP, is probably Eiffel.   

Richard Riehle
http://www.adaworks.com

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Pascal Obry wrote:
> 
> Richard D Riehle <laoXhai@ix.netcom.com> a �crit dans l'article
> <829rbv$a8m$1@nntp6.atl.mindspring.net>...
> > Smalltalk is certainly a nicely designed language. However,
> > if one is serious about object-oriented programming,
> > Ada is an excellent choice. The only appropriate alternative
> > to Ada, for serious OOP, is probably Eiffel.
> 
> I second that. For me the 2 bests designed languages for serious
> (read industrial) OO development are Ada and Eiffel.
> 
> Pascal.
> 

I would not recommend Ada 95 for OO development. Okay, it has all the
benefits of Ada 83 for type safety, etc, but the syntax of its class
programming constructs seems to make the code long winded, obscure and
error prone. I can give examples if anyone is interested/disagrees.

I suppose C++ is a swear word in this newsgroup, but I prefer it, even
though I preferred Ada 83 to C. C++ is more type safe than C, the
Standard Template Library (if used) can protect from memory leaks, array
bounds checking, etc; the sorts of problems that made C unsuitable for
'industrial strength' development. (Ironically, C has been used for lots
of very serious software, though).

Chris.

Re: Help me to chose between ADA 95 and C++

[Marin D. Condic]

Chris Powell wrote:
> I would not recommend Ada 95 for OO development. Okay, it has all the
> benefits of Ada 83 for type safety, etc, but the syntax of its class
> programming constructs seems to make the code long winded, obscure and
> error prone. I can give examples if anyone is interested/disagrees.
> 
On my web page I've been trying to collect examples of how something
might be done in C++ with equivalent code in Ada95. (I've been a bit
stalled in putting up new examples lately, but I intend to continue this
as time permits.) You may want to look at some of those examples.

I agree that the equivalent code in Ada is somewhat more verbose, but
that isn't necessarily all bad. What C++ provides in terseness it takes
away in clarity. IMHO, the Ada examples are easier to read and
understand the effects of when compared to the C++ examples. Of course,
the language you are most familiar with is always more clear than
languages of lesser familiarity. But I would still contend that the
syntax and semantics of equivalent Ada code has a clarity advantage.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Help me to chose between ADA 95 and C++

[Richard D Riehle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5812 bytes --]

In article <385112AE.7E2CFA9@rdel.co.uk>,
	Chris Powell <chris.powell@rrds.co.uk> wrote:

>Pascal Obry wrote:
>> 
>> Richard D Riehle <laoXhai@ix.netcom.com> a �crit dans l'article
>> <829rbv$a8m$1@nntp6.atl.mindspring.net>...
>> > Smalltalk is certainly a nicely designed language. However,
>> > if one is serious about object-oriented programming,
>> > Ada is an excellent choice. The only appropriate alternative
>> > to Ada, for serious OOP, is probably Eiffel.
>> 
>> I second that. For me the 2 bests designed languages for serious
>> (read industrial) OO development are Ada and Eiffel.
>> 
>> Pascal.
>> 
>
>I would not recommend Ada 95 for OO development. Okay, it has all the
>benefits of Ada 83 for type safety, etc, but the syntax of its class
>programming constructs seems to make the code long winded, obscure and
>error prone. I can give examples if anyone is interested/disagrees.

Since this is a response to something I said, I suppose I must say
something.  

1) Type safety    This is a real benefit of Ada that is not
                  as well represented in C++.  The default in
                  Ada, for every construct, is type safe. The
                  default, in the C family of languages, including
                  C++, is type unsafe.  It is true that one can
                  make C++ a little more type safe, but this requires
                  additional effort, an understanding of which
                  class to use (smart pointers, etc.) and a great
                  deal of careful programming.  Even with that care,
                  a C++ maintenance programmer has all the tools to 
                  easily violate the type safety another programmer has                                                    
                  diligently developed.

2) Long-winded    Speaking as a person reknowned for being a little
                  long-winded, at times, I do not find this to be a
                  bad thing.  Seriously,  Ada seems long-winded because
                  of the very rules that support the default for
                  type safety.  Among these rules one finds a very 
                  strict model for scope versus visibility, a language
                  feature that C++ has tried to adopt, but which falls
                  far short of that already integrated into the Ada
                  language.  I can teach someone unfamiliar with Ada
                  to read it more easily than I can teach the same skill
                  to someone unfamiliar with C/C++.

3) Obscure        Sure this falls into the category of what clinical
                  pyschologists call "projection."  One of my favorite
                  columns from the magazine, "C++ Report," is at the
                  end of each issue and titled, "Obfuscated C++."  One
                  create C++ code that is so mangled that even the most
                  expert of C++ practitioners is hard-pressed to explain
                  the exact outcome.  It is far easier to write obfuscated
                  C++ that obfuscated Ada.  

4) Error Prone    Here we go with the projection again.  The notion that
                  Ada is more error-prone than C++ reflects either an
                  ignorance of Ada, an ignorance of C++ or both. I can't
                  imagine anyone who knows both languages _well_
                  making such a statement.  

>I suppose C++ is a swear word in this newsgroup, but I prefer it, even
>though I preferred Ada 83 to C. C++ is more type safe than C, the
>Standard Template Library (if used) can protect from memory leaks, array
>bounds checking, etc; the sorts of problems that made C unsuitable for
>'industrial strength' development. (Ironically, C has been used for lots
>of very serious software, though).

No, C++ is not a swear word.  C++ is a language with much to recommend
it for certain circumstances.  However, anyone who would choose C++
over Ada for safety-critical software, especially DoD weapon systems,
is suffering from a failure to understand the relative virtues of
both languages.   One of my colleagues, who shall remain unnamed, says
that picking C++ over Ada is irresponsible.  While I might consider his
opinion a little over-stated, he is not without some knowledge of this
issue.  

As to the STL, you are kidding, of course.  The fundamental ideas of 
STL are important and many of those components are excellent.  I still
hear from colleagues here in Silicon Valley who grumble about their
reliability and the level of support offered by compiler publishers.
Add to that your parenthetical qualification, "(if used)," and you 
have another interesting problem.  Rarely do I seen anyone using
smart pointers or smart array classes as implemented in STL.  This is
sad since these are among the more important STL components available.
Even when they are used, it is often so sparingly that one continues
to find pointer problems scattered merrily through the rest of the code.

C++, when used correctly and responsibly, is an excellent language for
many kinds of software development.  It is not appropriate for safety
critical software, the application domain best served by Ada. It is
a stupid choice for business data processing software except where one
is interfacing to some kind of GUI environment, since it does not have
inherent support for financial data types (a la COBOL and Ada). It
it is not particularly well-suited to software that needs to be modified
a lot.  

Not that I have an opinion about this.  :-)

Richard Riehle

            P.S.  Example code fragments could be thrown back and
                  forth over the transom, but it would be an endless
                  dialogue of example and counter-example that would
                  lead nowhere.  
 

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Richard D Riehle wrote:
 
> Since this is a response to something I said, I suppose I must say
> something.
> 
> 1) Type safety    This is a real benefit of Ada that is not
>                   as well represented in C++.  The default in
>                   Ada, for every construct, is type safe. The
>                   default, in the C family of languages, including
>                   C++, is type unsafe.  It is true that one can
>                   make C++ a little more type safe, but this requires
>                   additional effort, an understanding of which
>                   class to use (smart pointers, etc.) and a great
>                   deal of careful programming.  Even with that care,
>                   a C++ maintenance programmer has all the tools to
>                   easily violate the type safety another programmer has
>                   diligently developed.

Equal care is required in Ada, but possibly for different reasons. If
types are defined incorrectly the resultant code ends up worse than if
no types were used. Although explicit type conversions are required
which should alert the programmer to a potential violation of the
intended design, often there end up being so many conversions everywhere
that the programmer no longer gives them a second thought.

Good type design (especially in an OO system) would define types with
appropriate functions acting on those types, possibly returning other
types effectively defining allowed conversions. This is no different
from defining C++ classes with appropriate methods which are effectively
type safe through data hiding and a well defined public interface.

> 2) Long-winded    Speaking as a person reknowned for being a little
>                   long-winded, at times, I do not find this to be a
>                   bad thing.  Seriously,  Ada seems long-winded because
>                   of the very rules that support the default for
>                   type safety.  Among these rules one finds a very
>                   strict model for scope versus visibility, a language
>                   feature that C++ has tried to adopt, but which falls
>                   far short of that already integrated into the Ada
>                   language.  I can teach someone unfamiliar with Ada
>                   to read it more easily than I can teach the same skill
>                   to someone unfamiliar with C/C++.

Some of Ada's long windedness is useful, but some adds no value and just
obscures what the code is doing, e.g. the type conversions problem
described above.

> 3) Obscure        Sure this falls into the category of what clinical
>                   pyschologists call "projection."  One of my favorite
>                   columns from the magazine, "C++ Report," is at the
>                   end of each issue and titled, "Obfuscated C++."  One
>                   create C++ code that is so mangled that even the most
>                   expert of C++ practitioners is hard-pressed to explain
>                   the exact outcome.  It is far easier to write obfuscated
>                   C++ that obfuscated Ada.

Possibly, but if the aim is not to purposely produce obfuscated code,
the class programming contructs of Ada 95 in their simplest form are
more difficult to read than the simplest C++, e.g.
Object'Class(This.all)'Access. (Note that I am waiting for responses to
my 'nowhere leading' code example post and may have completely
misunderstood Ada 95...)
 
> 4) Error Prone    Here we go with the projection again.  The notion that
>                   Ada is more error-prone than C++ reflects either an
>                   ignorance of Ada, an ignorance of C++ or both. I can't
>                   imagine anyone who knows both languages _well_
>                   making such a statement.

I thought I did know both languages well, and I suppose I do not make
many of the common mistakes in either language anymore: both languages
were hard to learn.

> No, C++ is not a swear word.  C++ is a language with much to recommend
> it for certain circumstances.  However, anyone who would choose C++
> over Ada for safety-critical software, especially DoD weapon systems,
> is suffering from a failure to understand the relative virtues of
> both languages.   One of my colleagues, who shall remain unnamed, says
> that picking C++ over Ada is irresponsible.  While I might consider his
> opinion a little over-stated, he is not without some knowledge of this
> issue.

Did the coding standard for the safety-critical software developed allow
full use of Ada 95 constructs? My experience of safety-critical software
is that while Ada is usually the chosen language, most of the Ada
language features are disallowed. I worked on one project where
constrained types were not allowed (because they are more likely to
raise exceptions than unconstrained types), no packages (because data
hiding limited testability) and certainly nothing as difficult to test
as inheritance/polymorphism could be used.

> As to the STL, you are kidding, of course.  The fundamental ideas of
> STL are important and many of those components are excellent.  I still
> hear from colleagues here in Silicon Valley who grumble about their
> reliability and the level of support offered by compiler publishers.
> Add to that your parenthetical qualification, "(if used)," and you
> have another interesting problem.  Rarely do I seen anyone using
> smart pointers or smart array classes as implemented in STL.  This is
> sad since these are among the more important STL components available.
> Even when they are used, it is often so sparingly that one continues
> to find pointer problems scattered merrily through the rest of the code.

At least C++ has something in the way of a useful library that is part
of the ANSI standard for the language. I always use STL containers now
and it should ensure that my programs are free from the errors there
would have been in my own implementations of containers and algorithms
for sorting/seraching. The STL is also supremely more efficient than
anything I would have time to write. In Ada I'd most probably use arrays
and linear/binary searching and perhaps at a push I'd implement a linked
list. An STL implementation is available for Ada (and all sorts of other
useful libraries), but because it is not part of the standard, there
seems to be a reluctance to use it.

As for compiler publishers, the support we receive for our Ada
environment is expensive and unhelpful. The Ada language requires a more
complex compiler which has led to far more compiler bugs than C++, and
we find more of them because the developer base for Ada is so much
smaller than that of C++. And the compiler is so slow! Wow I've really
gone off on one now! Sorry.

The amazing thing is, I don't dislike Ada that much! I know that both
languages have strengths and weaknesses and that computer languages are
just tools. The languages are not so different compared to the people
using them: some people write software that works, others never do.

Chris.

Re: Help me to chose between ADA 95 and C++

[Richard D Riehle]

In article <38566835.B4A2D48@rdel.co.uk>,
	Chris Powell <chris.powell@rrds.co.uk> wrote:

>Good type design (especially in an OO system) would define types with
>appropriate functions acting on those types, possibly returning other
>types effectively defining allowed conversions. This is no different
>from defining C++ classes with appropriate methods which are effectively
>type safe through data hiding and a well defined public interface.

I am going to respond to only one of your points.  Your response to
my other arguments was intelligent and thoughtful.  In the case of
this response, you are right on the mark!

I have long felt that we often expose too much of some numeric types
in our packages and ought to take more care to hide some of the
details.  This would lead to better maintenance as well as more
options for "design by contract."

The following example will be short, and that is always a problem since
code fragments never fully represent the range of possibilities.

package Real_Number is
  type Real is private;
  function "+" (L, R : Real) return Real;
  -- same for all other operators
  Divide_By_Zero : exception; 
  -- more exceptions
private
  type Real is digits 9;
end Real_Number;

The corresponding package body can have additional checks within
each operation to ensure conformity to the application constraints.
It turns out, though, that implementing this, in Ada, is somewhat
tedious because of the need to avoid recursive calls within each
function in the package body.  It can be done.  

More interesting is,

generic
   type Number is private;
   with function "+" (L, R : Number) return Number is <>;
   -- all other operators similarly declared as generic parameters
package Generic_Operators is end Generic_Operators;

with Generic_Operators;
generic
  with package Operators is new Generic_Operators (<>);
package Statistics is 
   ...
end Statistics;

which allows instantiation with any numeric type.  Also, there is a
way to instantiate this with a non-numeric type that I published in
an Ada Letters a couple of years ago.  

So, on this point, Chris, I am pretty much in agreement with you.

Richard Riehle

      P.S.  I apologize if my earlier reply was a bit to harsh.

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <8363hv$6cu$1@nntp9.atl.mindspring.net> , Richard D Riehle 
<laoXhai@ix.netcom.com>  wrote:

> package Real_Number is
>   type Real is private;
>   function "+" (L, R : Real) return Real;
>   -- same for all other operators
>   Divide_By_Zero : exception;
>   -- more exceptions
> private
>   type Real is digits 9;
> end Real_Number;
>
> The corresponding package body can have additional checks within
> each operation to ensure conformity to the application constraints.
> It turns out, though, that implementing this, in Ada, is somewhat
> tedious because of the need to avoid recursive calls within each
> function in the package body.  It can be done.

Indeed it can.  You have a couple of possibilities:

1) Implement the full view of the type as a record containing a single
floating point component; or,

2) Implement the full view of the type as a private derivation, and do
type conversions in the body to convert between public and private views
of the type.

Re: Help me to chose between ADA 95 and C++

[Larry Kilgallen]

In article <38566835.B4A2D48@rdel.co.uk>, Chris Powell <chris.powell@rrds.co.uk> writes:

> Equal care is required in Ada, but possibly for different reasons. If
> types are defined incorrectly the resultant code ends up worse than if
> no types were used. Although explicit type conversions are required
> which should alert the programmer to a potential violation of the
> intended design, often there end up being so many conversions everywhere
> that the programmer no longer gives them a second thought.

If conversions get that numerous, it is a sign of bad design.
One can code Fortran in any language.  Coding C in Ada is much
worse than coding C in C.

Larry Kilgallen

Re: Help me to chose between ADA 95 and C++

[Robert A Duff]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> If conversions get that numerous, it is a sign of bad design.

I don't agree.  If you have:

    type A1 is access all T1'Class;
    type A2 is access all T2'Class;

where "T2 is new T1 with ...", then it is perfectly natural to want to
convert from A2 to A1.  It is not a sign of bad design at all.  But Ada
requires an explicit type conversion in this case, which is a flaw in
Ada.

This one flaw is not enough to make me switch to C++, though.

> One can code Fortran in any language.  Coding C in Ada is much
> worse than coding C in C.

- Bob

Re: Help me to chose between ADA 95 and C++

[Richard Pinkall-Pollei]

>> If conversions get that numerous, it is a sign of bad design.
>
>I don't agree.  If you have:
>
>    type A1 is access all T1'Class;
>    type A2 is access all T2'Class;
>
>where "T2 is new T1 with ...", then it is perfectly natural to want to
>convert from A2 to A1.  It is not a sign of bad design at all.  But Ada
>requires an explicit type conversion in this case, which is a flaw in
>Ada.

Hm.  Without any context, the claim that the above is or is not bad
design cannot be made.  Since T2 is derived, would a access to base
type be more appropriate?  Is T2 really an extension or should it be
incorporated in T1?  What is the purpose and how will they be used?


Rich Pinkall-Pollei
---
C makes it easy for you to shoot yourself in the foot.  C++ makes that
harder, but when you do, it blows away your whole leg.
		-- Bjarne Stroustrup


  -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
   http://www.newsfeeds.com       The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including  Dedicated  Binaries Servers ==-----

Re: Help me to chose between ADA 95 and C++

[Ray Blaak]

Chris Powell <chris.powell@rrds.co.uk> writes:
> Did the coding standard for the safety-critical software developed allow
> full use of Ada 95 constructs? My experience of safety-critical software
> is that while Ada is usually the chosen language, most of the Ada
> language features are disallowed. I worked on one project where
> constrained types were not allowed (because they are more likely to
> raise exceptions than unconstrained types), no packages (because data
> hiding limited testability) and certainly nothing as difficult to test
> as inheritance/polymorphism could be used.

Oh Lord. Packages not allowed? In a safety-critical system? Packages are the
one of the fundamental building blocks of Ada to piece systems together with.

Controlling the namespace effectively prevents all sorts of errors, and is the
necessary for having a reasonable design. Anything else is chaos -- a
collection of library level procedures, I suppose, with what cohesiveness?

The testing argument is bogus -- design your packages with testing in mind, and
export the necessary services to allow coverage.

I would hate to maintain that system, or to work for that company in the first
place.

I have also worked in situations with some language features were not allowed
(i.e. access types), and have usually found that the work-arounds to overcome
the missing feature usually tended to be more error-prone and confusing than
using the feature directly.


-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Help me to chose between ADA 95 and C++

[Simon Wright]

Chris Powell <chris.powell@rrds.co.uk> writes:

> Did the coding standard for the safety-critical software developed allow
> full use of Ada 95 constructs? My experience of safety-critical software
> is that while Ada is usually the chosen language, most of the Ada
> language features are disallowed. I worked on one project where
> constrained types were not allowed (because they are more likely to
> raise exceptions than unconstrained types), no packages (because data
> hiding limited testability) and certainly nothing as difficult to test
> as inheritance/polymorphism could be used.

I can understand most of this, even if I don;t like it: indeed SPARK
Ada would probably not differ (speaking only as one who knows the name
of it): but not allowing constrained types! because they are "more
likely to raise exceptions than unconstrained types"!!!!! Isn't the
standard practice in SC software to PROVE that no exceptions will be
raised and THEN disable range checking? and wouldn't you expect it to
be easier to do the proof if you give the prover a helping hand by
using constrained types?

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Simon Wright wrote:
> 
> Chris Powell <chris.powell@rrds.co.uk> writes:
> 
> > Did the coding standard for the safety-critical software developed allow
> > full use of Ada 95 constructs? My experience of safety-critical software
> > is that while Ada is usually the chosen language, most of the Ada
> > language features are disallowed. I worked on one project where
> > constrained types were not allowed (because they are more likely to
> > raise exceptions than unconstrained types), no packages (because data
> > hiding limited testability) and certainly nothing as difficult to test
> > as inheritance/polymorphism could be used.
> 
> I can understand most of this, even if I don;t like it: indeed SPARK
> Ada would probably not differ (speaking only as one who knows the name
> of it): but not allowing constrained types! because they are "more
> likely to raise exceptions than unconstrained types"!!!!! Isn't the
> standard practice in SC software to PROVE that no exceptions will be
> raised and THEN disable range checking? and wouldn't you expect it to
> be easier to do the proof if you give the prover a helping hand by
> using constrained types?

I agree with you and found the whole thing quite frustrating. I tend to
avoid safety critical work now... It always seemed like the decisions
made about what we could and could not use were made by safety critical
software experts, who were never programmers.

Chris.

Re: Help me to chose between ADA 95 and C++

[Robert A Duff]

Chris Powell <chris.powell@rrds.co.uk> writes:

> I agree with you and found the whole thing quite frustrating. I tend to
> avoid safety critical work now... It always seemed like the decisions
> made about what we could and could not use were made by safety critical
> software experts, who were never programmers.

The "safety critical software experts" must know *something*.  After
all, airplanes fall out of the sky far less often than the software on
my desktop PC crashes.

- Bob

Re: Help me to chose between ADA 95 and C++

[Ted Dennison]

In article <38566835.B4A2D48@rdel.co.uk>,
  Chris Powell <chris.powell@rrds.co.uk> wrote:

> Equal care is required in Ada, but possibly for different reasons. If
> types are defined incorrectly the resultant code ends up worse than if
> no types were used. Although explicit type conversions are required
> which should alert the programmer to a potential violation of the
> intended design, often there end up being so many conversions
> everywhere that the programmer no longer gives them a second thought.

There are two possible things you could be talking about here:
  Explicit type conversions between numeric types with constrained
ranges.
  Unchecked_Conversion conversions.

If you are talking about the latter, you are describing heinously bad
code. You should almost *never* see an unchecked conversion outside of
an OS or external language interface, or perhaps a stream
implementation.

If you are talking about the former, you're right. Generally we try to
avoid excessively constrained numeric types, as doing conversions to and
from them just to handle temporary range excedences in intermediate
calculations is a real pain. I think the only constrained numeric types
we use are angle types (which are in their own package with mathematical
and conversion operations for them).

> At least C++ has something in the way of a useful library that is part
> of the ANSI standard for the language. I always use STL containers now

Unfortunately that standard isn't nearly as well adhered to as Ada's.
Check out the STL threads in comp.os.vxworks for an example. I have only
seen one thread here *ever* about an incorrect implementation of annex
A.

> As for compiler publishers, the support we receive for our Ada
> environment is expensive and unhelpful. The Ada language requires a
> more complex compiler which has led to far more compiler bugs than
> C++, and we find more of them because the developer base for Ada is so
> much smaller than that of C++. And the compiler is so slow! Wow I've

That's really wierd, because I'd say just the opposite (well, perhaps
not the "expensive" part). But most sources will tell you that the C++
standard is *more* complicated. I'd say the amount of compiler bugs, if
indeed they are more (I don't know that for a fact) are probably due to
you using a much less exercised compiler for Ada than you do for C++.

My experience with Ada vendors (Aonix, Rational, GreenHills, OC, ACT
"unsupported") has shown them all very responsive. Certainly moreso than
I could expect from Microsoft.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help me to chose between ADA 95 and C++

[Stefan Skoglund]

Ted Dennison wrote:
> That's really wierd, because I'd say just the opposite (well, perhaps
> not the "expensive" part). But most sources will tell you that the C++
> standard is *more* complicated. I'd say the amount of compiler bugs, if
> indeed they are more (I don't know that for a fact) are probably due to
> you using a much less exercised compiler for Ada than you do for C++.
> 

As usual the vendors asks the price they think they can get and if
the buyer is a DoD contract worker the buyer takes it.

Why is UNIX productivity sw so expensive compared to its PC
counterparts.

Personally i would love seeing a hard slash on Framemaker (why is the
PC version cheaper ?.)

Re: Help me to chose between ADA 95 and C++

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]


Chris Powell <chris.powell@rrds.co.uk> a �crit dans le message :
38566835.B4A2D48@rdel.co.uk...
> Did the coding standard for the safety-critical software developed allow
> full use of Ada 95 constructs? My experience of safety-critical software
> is that while Ada is usually the chosen language, most of the Ada
> language features are disallowed. I worked on one project where
> constrained types were not allowed (because they are more likely to
> raise exceptions than unconstrained types), no packages (because data
> hiding limited testability) and certainly nothing as difficult to test
> as inheritance/polymorphism could be used.
>

No packages, is that a joke ??

This is the most stupid limitation I've ever eard !!!!!

Who could possibly decide to not use packages in an Ada project ?

How can you even design such application ?

You have only procedures and functions ? Where do you put the shared
types ? Don't tell us that you use only predefined types ? Or maybe
your application is just one procedure with everything in it :)

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: pascal.obry@edf.fr        |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|   http://ourworld.compuserve.com/homepages/pascal_obry
--|
--|   "The best way to travel is by means of imagination"

Re: Help me to chose between ADA 95 and C++

[Rakesh Malhotra]

Pascal Obry wrote:
> 
> Chris Powell <chris.powell@rrds.co.uk> a �crit dans le message :
> 38566835.B4A2D48@rdel.co.uk...
> > Did the coding standard for the safety-critical software developed allow
> > full use of Ada 95 constructs? My experience of safety-critical software
> > is that while Ada is usually the chosen language, most of the Ada
> > language features are disallowed. I worked on one project where
> > constrained types were not allowed (because they are more likely to
> > raise exceptions than unconstrained types), no packages (because data
> > hiding limited testability) and certainly nothing as difficult to test
> > as inheritance/polymorphism could be used.
>
> No packages, is that a joke ??
[snip]

I don't think that the elimination of packages in safety critical
systems is not a general one.  I have worked on several such systems to,
both, European and US standards and have not come across this
restriction.   Perhaps, eliminating packages was a self imposed
restriction of the team that did the work ?

Certainly, data hiding limits the ability of automatic tools to analyse
the program which is why SPARK requires that you "expose" this data
using SPARK annotations.  However, even with SPARK you can use
packages.    So, again, I am not sure where the above restriction comes
from.

Rakesh

Re: Help me to chose between ADA 95 and C++

[Geoff Bull]

Rakesh Malhotra wrote:

> Certainly, data hiding limits the ability of automatic tools to analyse
> the program 

Just wondering why these automatic tools can't look at the hidden bits
same as a compiler does??
(I know zero about safety critical software)

Geoff

Re: Help me to chose between ADA 95 and C++

[Aidan Skinner]

On Thu, 16 Dec 1999 09:43:41 +0100, Pascal Obry <p.obry@der.edf.fr> wrote:

>No packages, is that a joke ??
>
>This is the most stupid limitation I've ever eard !!!!!

After careful analysis I have decided that no programmer on any safety
critical project I am currently managing is to use the assignment
statement, since this can lead to all exceptions being raised.

This is in addition to the current mandate to only use functions and
no access types (so all data is manipulated "in the clear").

- Aid^H^H^HCatbert

-- 
If you're not part of the soloution, you're part of the precipitate.
http://www.skinner.demon.co.uk/aidan/

Re: Help me to chose between ADA 95 and C++

[Lutz Donnerhacke]

* Pascal Obry wrote:
>You have only procedures and functions ? Where do you put the shared
>types ? Don't tell us that you use only predefined types ? Or maybe
>your application is just one procedure with everything in it :)

No chance. You may need nested packages in the declaration part.

Re: Help me to chose between ADA 95 and C++

[Robert Dewar]

In article <38566835.B4A2D48@rdel.co.uk>,
  Chris Powell <chris.powell@rrds.co.uk> wrote:

> As for compiler publishers, the support we receive for our Ada
> environment is expensive and unhelpful.

Perhaps this is due to your failure to choose a vendor
carefully. There are definitely Ada compilers available with
excellent support. Certainly lack of support has nothing to
do with Ada, and everything to do with your choice!

> The Ada language requires a more complex compiler

Nope, that's simply false

> which has led to far more compiler bugs than C++

If your Ada compiler has lots of bugs, again, perhaps you chose
the wrong compiler!

> and we find more of them because the developer base for Ada is
> so much smaller than that of C++.

More likely it is a basic quality problem, and that again comes
down to your choice of compilers.

> And the compiler is so slow!

There is no reason for an Ada compiler to be slow. If your
compiler is slow, again you chose the wrong one. Sounds like
you need to be quite a bit more careful in your procurement
decisions for Ada compilers!




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help me to chose between ADA 95 and C++

[Ted Dennison]

In article <83na60$8lo$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <38566835.B4A2D48@rdel.co.uk>,
>   Chris Powell <chris.powell@rrds.co.uk> wrote:
> > And the compiler is so slow!
>
> There is no reason for an Ada compiler to be slow. If your
> compiler is slow, again you chose the wrong one. Sounds like
> you need to be quite a bit more careful in your procurement
> decisions for Ada compilers!

Well, in truth there is one minor reason. Ada compilers systems
typically do a lot of the work of "make" as well as of a traditional
compiler. So if you compare an Ada compiler's speed with that of a C
compiler without taking into account the speed of make and the time it
takes you to create all those make rules (or run your makefile maker),
then it isn't really a good comparison.

For our moderately large (1300 file) system, the upfront library
registration with Tucker's favorite front end takes a quite noticable
amount of time on a clean system (well over a minute). But then again,
all our source is on networked ClearCase drives, which significantly
slows down every file access.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help me to chose between ADA 95 and C++

[Robert Dewar]

In article <83o786$ssb$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Well, in truth there is one minor reason. Ada compilers
> systems typically do a lot of the work of "make" as well as of
> a traditional compiler. So if you compare an Ada compiler's
> speed with that of a C compiler without taking into account
> the speed of make and the time it takes you to create all
> those make rules (or run your makefile maker),
> then it isn't really a good comparison.

There is no reason whatever for an Ada compiler to spend any
noticable time on this "make" functionality. Certainly with
GNAT there is no overhead at all from this source that is
noticable.

> For our moderately large (1300 file) system, the upfront
> library registration with Tucker's favorite front end takes a
> quite noticable amount of time on a clean system (well over a
> minute). But then again all our source is on networked
> ClearCase drives, which significantly slows down every file
> access.

A minute for the clean build case is not that significant. You
are not doing this kind of
registration each time you compile a unit, so I think it is
probably negligible in practice. In any case this is an artifact
of one particular approach of one particular compiler, nothing
to do with Ada or Ada compilers in general.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Robert Dewar wrote:
> 
> In article <38566835.B4A2D48@rdel.co.uk>,
>   Chris Powell <chris.powell@rrds.co.uk> wrote:
> 
> > As for compiler publishers, the support we receive for our Ada
> > environment is expensive and unhelpful.
> 
> Perhaps this is due to your failure to choose a vendor
> carefully. There are definitely Ada compilers available with
> excellent support. Certainly lack of support has nothing to
> do with Ada, and everything to do with your choice!
> 
> > The Ada language requires a more complex compiler
> 
> Nope, that's simply false
> 
> > which has led to far more compiler bugs than C++
> 
> If your Ada compiler has lots of bugs, again, perhaps you chose
> the wrong compiler!
> 
> > and we find more of them because the developer base for Ada is
> > so much smaller than that of C++.
> 
> More likely it is a basic quality problem, and that again comes
> down to your choice of compilers.
> 
> > And the compiler is so slow!
> 
> There is no reason for an Ada compiler to be slow. If your
> compiler is slow, again you chose the wrong one. Sounds like
> you need to be quite a bit more careful in your procurement
> decisions for Ada compilers!

Can you give me any advice regarding the compiler/development
environment we should we be using? We do host development under Solaris
and cross compile to a PowerPC embedded target running VxWorks.

Thanks for your help: hopefully you won't suggest the compiler we are
already using! It would also be useful if you could identify
compilers/environments which you know to be slow and/or buggy...

Cheers; Chris.

Re: Help me to chose between ADA 95 and C++

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2523 bytes --]

On Fri, 10 Dec 1999, Chris Powell wrote:
> Pascal Obry wrote:
> > Richard D Riehle <laoXhai@ix.netcom.com> a écrit dans l'article
> > <829rbv$a8m$1@nntp6.atl.mindspring.net>...
> > > Smalltalk is certainly a nicely designed language. However,
> > > if one is serious about object-oriented programming,
> > > Ada is an excellent choice. The only appropriate alternative
> > > to Ada, for serious OOP, is probably Eiffel.
> > 
> > I second that. For me the 2 bests designed languages for serious
> > (read industrial) OO development are Ada and Eiffel.
> > 
> > Pascal.
> 
> I would not recommend Ada 95 for OO development. Okay, it has all the
> benefits of Ada 83 for type safety, etc, but the syntax of its class
> programming constructs seems to make the code long winded, obscure and
> error prone. I can give examples if anyone is interested/disagrees.

Yes, examples please. 

> I suppose C++ is a swear word in this newsgroup, but I prefer it, even
> though I preferred Ada 83 to C. C++ is more type safe than C, the
> Standard Template Library (if used) can protect from memory leaks, array
> bounds checking, etc; the sorts of problems that made C unsuitable for
> 'industrial strength' development. (Ironically, C has been used for lots
> of very serious software, though).

Prefer C++ in general, for "OO" development, what? C++ certainly has a few 
things I like that Ada doesn't, and while everything you say is true, its
not enough for me. While C++ offers greater type safety than C, it offers
its own loopholes as well as most of the C ones. I still prefer Ada, which
is far safer. 

The STL is cool, and you can certainly do a variant in Ada. The Ada
version loses some of the readability of the C++ version IMO due to 
all of the instantiations but really gains in other ways since you can 
express typing information directly in the generic. Another powerful
feature of Ada generics is the ability to pass subprogram arguments; when 
combined with subprogram nesting the Ada STL has more useful functional 
programming capability than the C++ one. 

Of course, none of this is really OO, but I think OO is way overrated anyways.
Since you mention STL in the same paragraph as OO, I suppose I should ask
you what you mean by OO. Most people wouldn't consider the STL OO,
including its authors. 

I suppose I could be convinced that C++ is more convenient for a "pure OO" 
style of programming than Ada. Let's see those examples...

-- Brian

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Brian Rogoff wrote:

> Of course, none of this is really OO, but I think OO is way overrated anyways.
> Since you mention STL in the same paragraph as OO, I suppose I should ask
> you what you mean by OO. Most people wouldn't consider the STL OO,
> including its authors.

Its true that the STL is not implemented using OO constructs, but it is
conceptually OO, with the concept of a container base class defining
methods for manipulating elements, which are overriden to work
differently for specific container types and the abstraction of
iterators which can work on any type of container... but this wasn't
really why I mentioned the STL:

If I were to choose Ada 95 for OO programming I would have a safer
program, at the expense of more obscure OO syntax. So, in order to use
the syntax that I prefer, ie. C++, I need to find ways to make C++
programs safer and one way is to use the STL. 

Interestingly, many of the OO related pitfalls are evident in Ada 95 and
C++, because the way the two languages work is not actually that
different, for example attempting to override a method, but mis-typing
the name in the derived class making it a new method rather than an
overriden one.
 
> I suppose I could be convinced that C++ is more convenient for a "pure OO"
> style of programming than Ada. Let's see those examples...

I have posted one example. I guess it comes down to how important you
think programming elegance is, compared to intrinsic safety. I feel I am
experienced enough in C++ to be rarely caught out, but I admit there are
some nasty gotchas!

Chris.

Re: Help me to chose between ADA 95 and C++

[Brian Rogoff]

On Tue, 14 Dec 1999, Chris Powell wrote:
> Brian Rogoff wrote:
> 
> > Of course, none of this is really OO, but I think OO is way overrated anyways.
> > Since you mention STL in the same paragraph as OO, I suppose I should ask
> > you what you mean by OO. Most people wouldn't consider the STL OO,
> > including its authors.
> 
> Its true that the STL is not implemented using OO constructs, but it is
> conceptually OO, with the concept of a container base class defining
> methods for manipulating elements, which are overriden to work
> differently for specific container types and the abstraction of
> iterators which can work on any type of container... but this wasn't
> really why I mentioned the STL:

Conceptually, its just modular/ADT style programming with heavy use of 
parameterized types. The main idea is decoupling containers from the 
algorithms which work on them by providing intermediary structures for
traversing and accessing those containers (called "iterators") and writing 
all of the algorithms in terms of these iterators. The important
efficiency argument given by STL proponents is that there is no run time 
dispatching in the library at all; everything is known at compile time and 
so a sufficiently smart compiler could optimize it to the speed of hand
written C code (in theory!). 

Even if we use the "state based" definition of OO proposed by some here,
I'd still argue that STL doesn't fit. I can achieve the same goals in 
SML or OCaml using the module system, which has structures, signatures, 
and functors (Ada 95 fans read packages, generic signature packages, and 
generic packages with formal package parameters respectively :-). I might 
lose some of the mutating capabilities, but I could easily write a
functional STL in one of the MLs.

> If I were to choose Ada 95 for OO programming I would have a safer
> program, at the expense of more obscure OO syntax. So, in order to use
> the syntax that I prefer, ie. C++, I need to find ways to make C++
> programs safer and one way is to use the STL. 

Yes, that's true.

> > I suppose I could be convinced that C++ is more convenient for a "pure OO"
> > style of programming than Ada. Let's see those examples...
> 
> I have posted one example. I guess it comes down to how important you
> think programming elegance is, compared to intrinsic safety. I feel I am
> experienced enough in C++ to be rarely caught out, but I admit there are
> some nasty gotchas!

I'd rather the language defaulted to "very safe" and allowed you to be 
unsafe with some extra effort. I think C and C++ are the opposite. Also, 
there are lots of (non-OO) things that are more elegant (IMO of course) in
Ada than C++, though I admit that Ada support for MI is weaker than
C++. I am very glad to hear Tucker Taft mention that Java style
interfaces (or GNU C++ style signatures :-) are being considered for a
future Ada. 

BTW, I don't consider C++ a swear word, and unlike many Ada folk I do
appreciate that the implicit instantiation (well, some of it) of templates 
can enhance readability. But for "safety critical" software? I skept. 
Those nasty gotchas you can avoid may not be so easily avoided by less
competent programmers like me.

-- Brian

Re: Help me to chose between ADA 95 and C++

[Preben Randhol]

Chris Powell <chris.powell@rrds.co.uk> writes:

| If I were to choose Ada 95 for OO programming I would have a safer
| program, at the expense of more obscure OO syntax. So, in order to use
| the syntax that I prefer, ie. C++, I need to find ways to make C++
| programs safer and one way is to use the STL. 

I don't see what is so obscure. One thing that is important is that
Ada is designed so that the source code should be as readable as
possible. Therefore it might be a bit more verbose than C/C++, which
are not that easy to read most of the time. At least not if you try
read others code.

| Interestingly, many of the OO related pitfalls are evident in Ada 95 and
| C++, because the way the two languages work is not actually that
| different, for example attempting to override a method, but mis-typing
| the name in the derived class making it a new method rather than an
| overriden one.

What is your solution to this? To me it sounds like the programmer
does not proof-read his code if this is a _real_ problem. :-)

| I have posted one example. I guess it comes down to how important you
| think programming elegance is, compared to intrinsic safety. I feel I am

Some actually like Perl too :-) 

-- 
Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/]     
         "Det eneste trygge stedet i verden er inne i en fortelling." 
                                                      -- Athol Fugard

Re: Help me to chose between ADA 95 and C++

[Stephen Leake]

Preben Randhol <randhol@pvv.org> writes:

> | Interestingly, many of the OO related pitfalls are evident in Ada 95 and
> | C++, because the way the two languages work is not actually that
> | different, for example attempting to override a method, but mis-typing
> | the name in the derived class making it a new method rather than an
> | overriden one.
> 
> What is your solution to this? To me it sounds like the programmer
> does not proof-read his code if this is a _real_ problem. :-)

I just wasted a couple of hours on a closely related problem, which I
propose we call "the snark effect" (see thread "hunting snarks"). I
changed the profile of the base type operation (one parameter changed
from "in out" to "access" to avoid an accesibility problem). But I
forgot to change one of the operations in one of the (many) derived
types. In similar situations, Ada catches such errors (ie, change spec
but forget to change body). I'd like Ada to catch this as well.

-- Stephe

Re: Help me to chose between ADA 95 and C++

[Tucker Taft]

Stephen Leake wrote:
> 
> Preben Randhol <randhol@pvv.org> writes:
> 
> > | Interestingly, many of the OO related pitfalls are evident in Ada 95 and
> > | C++, because the way the two languages work is not actually that
> > | different, for example attempting to override a method, but mis-typing
> > | the name in the derived class making it a new method rather than an
> > | overriden one.
> >
> > What is your solution to this? To me it sounds like the programmer
> > does not proof-read his code if this is a _real_ problem. :-)
> 
> I just wasted a couple of hours on a closely related problem, which I
> propose we call "the snark effect" (see thread "hunting snarks"). I
> changed the profile of the base type operation (one parameter changed
> from "in out" to "access" to avoid an accesibility problem). But I
> forgot to change one of the operations in one of the (many) derived
> types. In similar situations, Ada catches such errors (ie, change spec
> but forget to change body). I'd like Ada to catch this as well.

A trio of pragmas have been proposed for eventual standardization that will
allow the compiler to catch this problem.  Basically you will be able
to indicate whether a given operation is or is not presumed to override
some inherited operation.  See the following AI for details:

    http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00218.DOC?rev=1.3
> 
> -- Stephe

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Help me to chose between ADA 95 and C++

[Stephen Leake]

Tucker Taft <stt@averstar.com> writes:

> Stephen Leake wrote:

> A trio of pragmas have been proposed for eventual standardization that will
> allow the compiler to catch this problem.  Basically you will be able
> to indicate whether a given operation is or is not presumed to override
> some inherited operation.  See the following AI for details:
> 
>     http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00218.DOC?rev=1.3

Cool. Those look like just what I want. 

Is ACT putting these in GNAT? or should I add that to my list of
things to do?

-- Stephe

Re: Help me to chose between ADA 95 and C++

[Preben Randhol]

Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:

| I just wasted a couple of hours on a closely related problem, which I
| propose we call "the snark effect" (see thread "hunting snarks"). I
| changed the profile of the base type operation (one parameter changed
| from "in out" to "access" to avoid an accesibility problem). But I
| forgot to change one of the operations in one of the (many) derived
| types. In similar situations, Ada catches such errors (ie, change spec
| but forget to change body). I'd like Ada to catch this as well.

Yes. :-) 

But how should the Ada compiler know that you meant to write:

procedure Eat

and not

procedure Eats

I may have misunderstood the original request, but I don't see how the
Ada compiler could know if you wanted to write Eat or not here.

-- 
Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/]     
         "Det eneste trygge stedet i verden er inne i en fortelling." 
                                                      -- Athol Fugard

Re: Help me to chose between ADA 95 and C++

[Richard Pinkall-Pollei]

With some trepidation, I'm throwing my "int cents = 2;"/"cents:
integer range 0..99 := 2;" worth in.  I use both languages at work and
at home.  I don't care to argue specific language features, since such
preferences are very much tied to personal taste and familiarity; both
languages are general-purpose so that essentially any programming task
can be written in either language with some differences in effort
required.  When comparing Ada to C++, I look at the overall language
design in relation to three general categories:  programming effort
(cost), portability, and transition from design specification to
actual code.

As far as programming effort goes, Ada programs are much easier to
write in general.  The Ada philosophy of strict typing along with
various other consistency checks relieve the programmer of doing these
tedious checks himself; if the program compiles correctly, an Ada
program is much more likely to execute correctly than a C++ program
unless the programmer has been *very* careful.  Likewise, C++ is more
of a "build it yourself" language -- some of the standard Ada language
features such as multi-threading (POSIX threads), protected types
(mutex's), and exceptions (an exception type must be defined before it
can be used) must be hand-coded when using C++ (of course, this is an
advantage for those who like to build their own -- it can be done in
Ada, but it's easier in C++).  As well, whenever a scalar type of a
certain accuracy is required, a C++ programmer must know the machine
representation of the built-in types before deciding which type to
use, as opposed to direct specification of accuracy in Ada.  Finally,
repeated studies have confirmed that it costs less to write and
maintain non-trivial Ada programs.

C++ compilers run on more machine architectures and operating systems
than Ada compilers, but C++ requires a little more effort to create
truly portable programs.  Various tools have been developed, such as
automake and it's relatives, that compensate for differing header file
and library implementations among various systems.  Ada source code,
on the other hand, will run unchanged on multiple architectures
(unless one uses the C language hooks or non-standard, implementation
specific features that *must* be documented).  Part of the reason I'm
jumping in is that I'm facing a portability dilemma involving C++ and
Ada.  I recently acquired an Alpha-based machine running Linux.  There
are not pre-built GNAT binaries for this particular CPU/OS
combination, and since GNAT is written in Ada, I am trying to build a
cross compiler that will allow me to port GNAT to that machine.  That
way, the programs I write in GNAT will be easily portable to that
system.  The problem is that GNAT is based on the old GCC 2.8.1
release, and I'm having some porting problems, so I have to decide
whether the time spent porting GNAT is more important than converting
to C++ for these particular programs.

Finally, for me, program specification and design precede coding for
any non-trivial program I write.  While I can think in both C++ and
Ada, I find that when I write specifications and design interfaces,
the text resembles Ada -- so much so that I can use the specs almost
directly as Ada code.

As a last comment, there are a lot more C++ programmers than Ada
programmers.  This strikes me as another example of the "nobody ever
got fired for using <whatever>" syndrome.  IBM was one of the first
examples.  Our shop uses Unisys hardware for our largest and most
critical applications because it's better designed and more powerful
than equivalent IBM hardware.  Yet, IBM is still the best-selling
hardware.  The same is true of Micro$oft -- it's not the best OS by a
long shot, but people tend to stick with what their comfortable with.
Ada now seems in the same boat -- for my money, it is generally the
best programming language available for most purposes.  Yet, as things
stand, it will not overcome C++'s popularity in the foreseeable
future.  So, I'll just keep pluggin' away at promoting it, and hope
someday it will become the next Linux phenomenon.


Rich Pinkall-Pollei
Team Ada
Ada for Linux Team
---
A computer lets you make more mistakes faster than any other invention,
with the possible exceptions of handguns and Tequilla.
	-- Mitch Ratcliffe

Re: Help me to chose between ADA 95 and C++

[Richard Pinkall-Pollei]

On 15 Dec 1999 19:09:15 GMT,
   Richard Pinkall-Pollei <whraven@msn.fullfeed.com> wrote:
> [deleted]

Sorry about the typos in my post -- I was trying to do too many things
at once.

Re: Help me to chose between ADA 95 and C++

[Geoff Bull]

Richard Pinkall-Pollei wrote:
> 
> Finally,
> repeated studies have confirmed that it costs less to write and
> maintain non-trivial Ada programs.

References?

Re: Help me to chose between ADA 95 and C++

[Tucker Taft]

Geoff Bull wrote:
> 
> Richard Pinkall-Pollei wrote:
> >
> > Finally,
> > repeated studies have confirmed that it costs less to write and
> > maintain non-trivial Ada programs.
> 
> References?

Here are a couple.  The first is a presentation with a number
of graphic charts illustrating the savings using Ada
relative to other languages:

    http://www.adaic.org/docs/present/ajpo/pll-cost/html/

There are further references interspersed through this presentation.

This second one is a study done by Verdix (now Rational) about their
experience using Ada and C in developing compiler components:

http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl?doc_key=337

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Help me to chose between ADA 95 and C++

[Ted Dennison]

In article <385FBEB6.8D34217@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Geoff Bull wrote:
> > References?
>
> Here are a couple.  The first is a presentation with a number
> of graphic charts illustrating the savings using Ada
> relative to other languages:
>
>     http://www.adaic.org/docs/present/ajpo/pll-cost/html/
>
> There are further references interspersed through this presentation.

I found a single page/slide listing 6, some of which themselves were
compendiums of other studies. Wow.

> This second one is a study done by Verdix (now Rational) about their
> experience using Ada and C in developing compiler components:
>
>
http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl?doc_k
ey=337

My favorite line:
 "This graph shows that customers were far more unhappy with features
implemented in C than they were in Ada."

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Help me to chose between ADA 95 and C++

[DuckE]

Chris Powell <chris.powell@rrds.co.uk> wrote in message
news:385112AE.7E2CFA9@rdel.co.uk...
[snip]
>
> I would not recommend Ada 95 for OO development. Okay, it has all the
> benefits of Ada 83 for type safety, etc, but the syntax of its class
> programming constructs seems to make the code long winded, obscure and
> error prone. I can give examples if anyone is interested/disagrees.
>
Please do post an example or two to the newsgroup.  Not because I doubt your
statements, but because someone might post suggestions on how to improve the
code.

I wrote my first OO Ada95 program about 6 months ago.  It is working well
and has benefited from the use of inheritance in adding new objects.  But I
do find some of the references to objects messy.  I would be interested in
seeing examples of how to do things better.

BTW: The only significant feature of Ada95 object definitions that I really
don't like is the implicit range of an objects definitions.  This is
somewhat inconsistant with other parts of the language.  For example: an
"IF" statement is always ended by an "END IF", making the extent of the
object quite clear.  When looking at tagged record definitions and the
methods defined following the records, careful study and knowledge of
"freezing rules" is required.  I would have much preferred a syntax where
the start and end of an object and its methods are explicitly defined.

SteveD

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <3855af39.0@news.pacifier.com> , "DuckE" 
<nospam_steved@pacifier.com> wrote:

> When looking at tagged record definitions and the methods defined following
> the records, careful study and knowledge of "freezing rules" is required.

Not really.  The primitive operations of a type are defined in the
enclosing package, unless the type is frozen prematurely.  But in the
latter case, the compiler will tell you.

> I would have much preferred a syntax where the start and end of an object and
> its methods are explicitly defined.

Yes, you have that syntax already.  The package in which the type is
declared demarcates the primitive operations of the type from the
operations that are nonprimitive.


--
The new standards [for science curricula in Kansas] do not forbid the
teaching of evolution, but the subject will no longer be included in
statewide tests for evaluating students--a virtual guarantee, given the
realities of education, that this central concept of biology will be
diluted or eliminated, thus reducing courses to something like chemistry
without the periodic table, or American history without Lincoln.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <385112AE.7E2CFA9@rdel.co.uk> , Chris Powell 
<chris.powell@rrds.co.uk>  wrote:

> I would not recommend Ada 95 for OO development. Okay, it has all the
> benefits of Ada 83 for type safety, etc, but the syntax of its class
> programming constructs seems to make the code long winded, obscure and
> error prone.  I can give examples if anyone is interested/disagrees.

Please do so, especially any examples that you think are "error prone."

Perhaps there is just a misunderstanding about how to properly declare a
type.

--
The political forces that try to eliminate evolution from science
classrooms impose a narrow, sectarian doctrine on our educational
systems. This imposition represents an affront not only to the
constitutional separation of church and state but also to the moral and
intellectual integrity embedded in that constitution.

<http://www.nabt.org/evolutionks.html>

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Matthew Heaney wrote:
> 
> In article <385112AE.7E2CFA9@rdel.co.uk> , Chris Powell
> <chris.powell@rrds.co.uk>  wrote:
> 
> > I would not recommend Ada 95 for OO development. Okay, it has all the
> > benefits of Ada 83 for type safety, etc, but the syntax of its class
> > programming constructs seems to make the code long winded, obscure and
> > error prone.  I can give examples if anyone is interested/disagrees.
> 
> Please do so, especially any examples that you think are "error prone."
> 
> Perhaps there is just a misunderstanding about how to properly declare a
> type.

Okay, this is where I find out that I have been getting it wrong for the
last year! But here goes:

package body Example is

   procedure Dispatching_Method (This : access Object) is
   begin
      -- This call correctly redispatches to Another_Dispatching_Method
      Another_Dispatching_Method (This => Object'Class
(This.all)'Access);

      -- This (probably incorrectly) calls this object's
      -- Another_dispatching_Method directly, without dispatching
      Another_Dispatching_Method (This => This);

   end Dispatching_Method;


   procedure Class_Method (This : access Object'Class) is
   begin

      -- This call correctly dispatches, since this is already 
      -- classwide in this case
      Another_Dispatching_Method (This => This);

   end Class_Method;


   procedure Another_Dispatching_Method (This : access Object) is
   begin
      null;
   end Another_Dispatching_Method;

end Example;

It has proven to be a common mistake to neglect to convert an object to
its class wide type before attempting a redispatch.

Passing 'This' as an access parameter is common (since references to
objects are often stored by an object, but further complicates the
syntax.

By contrast, C++ provides redispatching as the default behaviour which
makes more sense to me. If a function is declared virtual (ie
dispatches) you would normally want dispatching to occur and then have
to use special syntax to prevent dispatching. In Ada, it is the other
way round. So for completeness, the code above in C++ might be:

void Example::Dispatching_Method()
{
   // Dispatch by default
   Another_Dispatching_Method();

   // Scope explicitly with class name to prevent dispatching
   Example::Another_Dispatching_Method();
} 

void Example::Class_Method( Example* instance )
{
   instance->Another_Dispatching_Method();
}

Note that the Class_Method would have been declared static in the class
spec.


This is one example, perhaps a bit verbose. I can try and think of more
if anyone is interested, or please set me straight!


Other Ada quibbles:

C++ encapsulates methods and data in a single structure. In Ada, class
methods are defined outside the object type so do not appear to 'belong'
to the type. 

Having to explicitly pass the object instance as a parameter (the
implicit 'this' in C++) further separates the logical association
between methods and objects.

I am a Multiple Inheritance fan, because I think I know how to use it
properly. I do not believe it (always) indicates a bad design, as some
do. Ada 95 has some constructs to allow different types of MI, but not
all provided by the more general approach of C++, and again, the syntax
is obscure involving tagged types within generics, access discrimiated
records, etc. In C++ you simply define an X as a Y and a Z. In Ada, the
syntax would have been (if allowed):

   type Object is new X.Object and new Y.Object with record .... 

Comments?

Chris.

Re: Help me to chose between ADA 95 and C++

[Stephen Leake]

Chris Powell <chris.powell@rrds.co.uk> writes:

> Okay, this is where I find out that I have been getting it wrong for the
> last year! But here goes:
> 
> package body Example is
> 
>    procedure Dispatching_Method (This : access Object) is
>    begin
>       -- This call correctly redispatches to Another_Dispatching_Method
>       Another_Dispatching_Method (This => Object'Class
> (This.all)'Access);
> 
>       -- This (probably incorrectly) calls this object's
>       -- Another_dispatching_Method directly, without dispatching
>       Another_Dispatching_Method (This => This);
> 
>    end Dispatching_Method;
> 
> 
>    procedure Class_Method (This : access Object'Class) is
>    begin
> 
>       -- This call correctly dispatches, since this is already 
>       -- classwide in this case
>       Another_Dispatching_Method (This => This);
> 
>    end Class_Method;
> 
> 
>    procedure Another_Dispatching_Method (This : access Object) is
>    begin
>       null;
>    end Another_Dispatching_Method;
> 
> end Example;
> 
> It has proven to be a common mistake to neglect to convert an object to
> its class wide type before attempting a redispatch.

Hmm. I don't see why Dispatching_Method should _want_ to re-dispatch.
You could simply override Dispatching_Method, in addition to
Another_Dispatching_Method. Can you give a good example of when this
is not a good idea?

> Passing 'This' as an access parameter is common (since references to
> objects are often stored by an object, but further complicates the
> syntax.

No problem here. The syntax is complicated (I assume you are refering
to "Object'Class (This.all)'Access") because you are doing things the
hard way; just override Dispatching_Method.

> By contrast, C++ provides redispatching as the default behaviour which
> makes more sense to me. If a function is declared virtual (ie
> dispatches) you would normally want dispatching to occur and then have
> to use special syntax to prevent dispatching. In Ada, it is the other
> way round.

In Ada, you have complete control over whether a call dispatches or
not. If the actual parameter is class-wide, you get dispatching.
Otherwise, you get static binding. Static binding is a Good Thing in
some situations; I'm not clear you ever get it in C++.

> Other Ada quibbles:
> 
> C++ encapsulates methods and data in a single structure. In Ada, class
> methods are defined outside the object type so do not appear to 'belong'
> to the type. 

That's what packages are for. If you choose, you can use a programming
style where all subprograms in a package are primitive operations on
a type. Or, you can choose a different style. Ada gives you more
freedom to choose your programming idiom; C++ gives you one idiom.
 
> Having to explicitly pass the object instance as a parameter (the
> implicit 'this' in C++) further separates the logical association
> between methods and objects.

C++ uses "object.method". Ada uses Method (object). Same logical
association. Hmm, if you have more parameters, and don't put the
object first in Ada, you might lose something. Once again, Ada gives
you a choice, C++ doesn't.
 
> I am a Multiple Inheritance fan, because I think I know how to use it
> properly. I do not believe it (always) indicates a bad design, as some
> do. Ada 95 has some constructs to allow different types of MI, but not
> all provided by the more general approach of C++, and again, the syntax
> is obscure involving tagged types within generics, access discrimiated
> records, etc. In C++ you simply define an X as a Y and a Z. In Ada, the
> syntax would have been (if allowed):
> 
>    type Object is new X.Object and new Y.Object with record .... 
> 
> Comments?

I'll have to leave this one for Tuck; I don't really understand what
the problems are with the C++ style of multiple inheritance. But
again, Ada gives you a choice :).

-- Stephe

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Stephen Leake wrote:
 
> Hmm. I don't see why Dispatching_Method should _want_ to re-dispatch.
> You could simply override Dispatching_Method, in addition to
> Another_Dispatching_Method. Can you give a good example of when this
> is not a good idea?

My example was too simple. In reality, Dispatching_Method would perform
some other functionality as well as calling Another_Dispatching_Method.
Overriding Dispatching_Method would mean this behaviour would need to be
reimplemented in the derived class, probably via cut and paste.
 
> > Passing 'This' as an access parameter is common (since references to
> > objects are often stored by an object, but further complicates the
> > syntax.
> 
> No problem here. The syntax is complicated (I assume you are refering
> to "Object'Class (This.all)'Access") because you are doing things the
> hard way; just override Dispatching_Method.

No, I only write the same bit of code once: in the base class.

> In Ada, you have complete control over whether a call dispatches or
> not. If the actual parameter is class-wide, you get dispatching.
> Otherwise, you get static binding. Static binding is a Good Thing in
> some situations; I'm not clear you ever get it in C++.

Yes C++ has both. The difference is that C++ uses dynamic binding by
default and Ada uses static.
 
> C++ uses "object.method". Ada uses Method (object). Same logical
> association. Hmm, if you have more parameters, and don't put the
> object first in Ada, you might lose something. Once again, Ada gives
> you a choice, C++ doesn't.

C++ does allow binary methods which are defined outside a class, so in
fact it is C++ which gives you the choice, and Ada which does not.

Chris.

Re: Help me to chose between ADA 95 and C++

[Tucker Taft]

Chris Powell wrote:
> 
> Matthew Heaney wrote:
> >
> > In article <385112AE.7E2CFA9@rdel.co.uk> , Chris Powell
> > <chris.powell@rrds.co.uk>  wrote:
> >
> > > I would not recommend Ada 95 for OO development. Okay, it has all the
> > > benefits of Ada 83 for type safety, etc, but the syntax of its class
> > > programming constructs seems to make the code long winded, obscure and
> > > error prone.  I can give examples if anyone is interested/disagrees.
> >
> > Please do so, especially any examples that you think are "error prone."
> >
> > Perhaps there is just a misunderstanding about how to properly declare a
> > type.
> 
> Okay, this is where I find out that I have been getting it wrong for the
> last year! But here goes:

Thanks for taking the time to post these examples.  I will give some
of the rationale for the choices made...

> package body Example is
> 
>    procedure Dispatching_Method (This : access Object) is
>    begin
>       -- This call correctly redispatches to Another_Dispatching_Method
>       Another_Dispatching_Method (This => Object'Class
> (This.all)'Access);
> 
>       -- This (probably incorrectly) calls this object's
>       -- Another_dispatching_Method directly, without dispatching
>       Another_Dispatching_Method (This => This);

This choice of "static" over "dynamic" binding was very explicit
in the language design.  By making static binding the default,
you minimize unexpected coupling between a parent type and a derived
type.  I'll say more below...

>    end Dispatching_Method;
> 
>    procedure Class_Method (This : access Object'Class) is
>    begin
> 
>       -- This call correctly dispatches, since this is already
>       -- classwide in this case
>       Another_Dispatching_Method (This => This);
> 
>    end Class_Method;
> 
>    procedure Another_Dispatching_Method (This : access Object) is
>    begin
>       null;
>    end Another_Dispatching_Method;
> 
> end Example;
> 
> It has proven to be a common mistake to neglect to convert an object to
> its class wide type before attempting a redispatch.

I would have said that a common mistake in most OO languages
is to use dynamic binding between dispatching methods
when static binding would have been better.

This will not happen in Ada 95 because static binding between
dispatching methods is the default, and you have to work a little
harder and be explicit if you want redispatching.

 
> Passing 'This' as an access parameter is common (since references to
> objects are often stored by an object, but further complicates the
> syntax.
> 
> By contrast, C++ provides redispatching as the default behaviour which
> makes more sense to me. If a function is declared virtual (ie
> dispatches) you would normally want dispatching to occur and then have
> to use special syntax to prevent dispatching. In Ada, it is the other
> way round. 

Here we have a difference of opinion.  I agree when calling from the
"outside" use want dispatching to occur, and that is what happens in
Ada (and C++).  However, when calling from one dispatching operation
to another, static binding has a lot of advantages.  In particular,
if you inherit one operation and override the other, the one you
inherit continues to work as it used to, rather than having some
unspecified change in behavior due to redispatching.

The critical point to recognize is that any redispatching within
a dispatching operation affects the *external* behavior of the operation
upon inheritance.  So you can't inherit an operation as a black box
if it has internal redispatching.  You basically have to look at the
source of the inherited operation (i.e. this means "white box" reuse), 
or have unusually good documentation on exactly what redispatching
is happening inside and when.

I remember attending a panel session at OOPSLA several years ago where
essentially all of the panel members were griping about the difficulties
of doing maintenance and enhancement on class libraries when users are
taking advantage of this internal redispatching (also called "self
dependencies").  Users were overriding some but not all of the operations, 
and then relying on this overriding to subtly affect the semantics of the
inherited operations.  When the next version of the class library came out,
these users were very annoyed if the subtle effects were different.  

This problem would not occur in a language like Ada 95 where the default
binding between dispatching operations is static.  The developer of the class
library would only use redispatching if they felt it were part of the
*specification* of the operation, and hence would be intending to
document it.  By contrast, in C++, Java, Eiffel, Smalltalk, etc., 
redispatching is the default (and except for C++, static binding
is not even an option), so these kinds of self dependencies are produced
everywhere and anywhere there are calls between dispatching operations.
Quite often these were calls made out of convenience of implementation
of the operation, not out of an intent to create a subtle linkage
between the operations from an inheritance point of view.

So it is the collective experience of class providers like these that
reconfirmed (at least for me) our decision to make static binding the
default, while still providing a way for the programmer to redispatch
if that is what the specification of the routine requires.

> ...
> This is one example, perhaps a bit verbose. I can try and think of more
> if anyone is interested, or please set me straight!
> 
> Other Ada quibbles:
> 
> C++ encapsulates methods and data in a single structure. In Ada, class
> methods are defined outside the object type so do not appear to 'belong'
> to the type.

This is clearly a matter of taste and background.  The notion of
an abstract data type, like "complex numbers" and a set of operations
defined along side them has a long history.  Ada 83 was built around
this notion of abstract data type, where a type and its operations
were all defined in a package, where the package provided the
encapsulation.  Ada 95 was designed to allow the extension of abstract
data types, providing both inheritance between abstractions and/or
their implementations, and polymorphism between multiple implementations 
of an abstraction.  This preserves the heritage of "abstraction" orientation,
while providing the extensibility and dynamism associated with the
object-oriented model.  It also means that binary operations are very
natural in Ada 95, whereas they are awkward and somewhat arbitrarily
asymmetric in languages like C++ and Java (e.g. the nasty need to
write "if S1.equal(S2) {" in Java, rather than "if S1 = S2 then" in
Ada 95, or the awkward connection between operator "friends" in C++
and the "associated" class).

Admittedly, Ada 95 is a bit less natural in the heavily "state"-oriented
model, where all operations "do things" to an object, and is a bit more 
natural in a "value"-oriented/functional model where (abstract) operations 
take in one or more values of a given ADT and produce a result.
Personally the problem I have with the "state"-oriented model is
for various operations that have two or more objects involved,
and it is not at all obvious which one is the "primary" object.
With the symmetric Ada (and Common Lisp Object System/CLOS) approach, 
they are all operands of the operation, and no unique "primary" object
need be identified.

> Having to explicitly pass the object instance as a parameter (the
> implicit 'this' in C++) further separates the logical association
> between methods and objects.

Again, the C++ syntax is useful for clearly "one-primary-operand" operations,
and somewhat arbitrary for "two-or-more-significant-operand" operations.

> I am a Multiple Inheritance fan, because I think I know how to use it
> properly. I do not believe it (always) indicates a bad design, as some
> do. Ada 95 has some constructs to allow different types of MI, but not
> all provided by the more general approach of C++, and again, the syntax
> is obscure involving tagged types within generics, access discrimiated
> records, etc. In C++ you simply define an X as a Y and a Z. In Ada, the
> syntax would have been (if allowed):
> 
>    type Object is new X.Object and new Y.Object with record ....

We certainly debated multiple inheritance.  I think we were reluctant
to build in syntax for a feature that seemed in some cases a
solution looking for a problem.  Also the fact that the designers of
C++ couldn't decide  between "virtual" and "non-virtual" base classes,
and felt obliged to support both, and that many Eiffel uses of
multiple inheritance seemed to represent "uses" rather than "is-a"
relationships, made us feel that multiple inheritance was still in an awkward
stage of development.  

The one thing I would add now to Ada 95 would probably
be something more akin to the Java multiple inheritance of interfaces.
Inheriting implementations from multiple parents seems quite error prone,
but inheriting interfaces is pretty clean.  However, there is still
the annoying name clash possibility, where two interfaces happen to use
the same name for otherwise unrelated methods.  You also can't implement
an interface in multiple ways with a single type, which could be useful
for things like the "observer" pattern where a single object wants to
observe multiple other objects.  

For Ada 95, a solution built more around the notion of explicitly implementing
an interface, using something like the syntax of a generic instantiation, 
would give more flexibility and power (including multiple implementations
of the same interface), while avoiding the annoyances
associated with name clashes.  We have begun moves toward an Ada 200X, so some
ideas like these may emerge...
> 
> Comments?

See above.

> 
> Chris.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <38567806.FD1F4232@averstar.com> , Tucker Taft 
<stt@averstar.com>  wrote:

> You also can't implement an interface in multiple ways with a single type,
> which could be useful for things like the "observer" pattern where a single
> object wants to observe multiple other objects.


There's an example of how to do this in the design patterns archive.

<http://www.acm.org/archives/patterns.html>

Use the search engine to search for "observering multiple subjects" or
something like that.

In my little example, a digital clock observes, simultaneously, both a
battery (to indicate when the power is low) and a timer (its source of
time).  Like this:

package Digital_Clocks is

  type Digital_Clock
    (Battery : access Battery_Type;
     Timer   : access Timer_Type) is limited private;

private

  type Battery_Observer
    (Clock : access Digital_Clock) is
   new Observer with null record;

  type Timer_Observer
    (Clock : access Digital_Clock) is
   new Observer with null record;

  type Digital_Clock
    (Battery : access Battery_Type;
     Timer   : access Timer_Type) is
    new Limited_Controlled with record
      Battery_Obs : Battery_Observer (Digital_Clock'Access);
      Timer_Obs   : Timer_Observer (Digital_Clock'Access);
    end record;
...
end Digital_Clocks;

Re: Help me to chose between ADA 95 and C++

[Chris Powell]

Sorry for the delay in my response...

Tucker Taft wrote:
 
> This choice of "static" over "dynamic" binding was very explicit
> in the language design.  By making static binding the default,
> you minimize unexpected coupling between a parent type and a derived
> type.  I'll say more below...

I have always viewed this coupling as part of the desired behaviour of
OO. If the base class has defined a dispatching method it is explicitly
declaring that the derived class may change the default behaviour (if
any) of the base class. Why would the base class explicitly declare this
intention, only to then deny the derived class its behaviour by default?

It would be bad OO design if a base class was dependent on specific
behaviour in a derived class rather than the logical semantics of the
method, and I do not believe it is the language's job to 'tolerate'
this.

> I would have said that a common mistake in most OO languages
> is to use dynamic binding between dispatching methods
> when static binding would have been better.

I find it confusing that a dispatching method isn't dispatching by
default all the time. 

> I remember attending a panel session at OOPSLA several years ago where
> essentially all of the panel members were griping about the difficulties
> of doing maintenance and enhancement on class libraries when users are
> taking advantage of this internal redispatching (also called "self
> dependencies").  Users were overriding some but not all of the operations,
> and then relying on this overriding to subtly affect the semantics of the
> inherited operations.  When the next version of the class library came out,
> these users were very annoyed if the subtle effects were different.

> This problem would not occur in a language like Ada 95 where the default
> binding between dispatching operations is static.  The developer of the class
> library would only use redispatching if they felt it were part of the
> *specification* of the operation, and hence would be intending to
> document it.  By contrast, in C++, Java, Eiffel, Smalltalk, etc.,
> redispatching is the default (and except for C++, static binding
> is not even an option), so these kinds of self dependencies are produced
> everywhere and anywhere there are calls between dispatching operations.
> Quite often these were calls made out of convenience of implementation
> of the operation, not out of an intent to create a subtle linkage
> between the operations from an inheritance point of view.

What if only those methods that are intended to be overriden are made
dispatching operations?
Both C++ and Ada 95 give the choice as to whether a method is
overridable or not. It would be an error in the design of the class
library's base class if it depended on specific behaviour in the derived
class, or if it allowed essential base class behaviour to be overridden
and thus lost.

I can see there would be a problem if the language makes all operations
dispatching, but this is not the case in C++. However, I have seen many
examples of C++ class libraries defined with all methods virtual 'just
in case' a derived class needs to do something unforseen. I do not agree
with this approach.

> It also means that binary operations are very
> natural in Ada 95, whereas they are awkward and somewhat arbitrarily
> asymmetric in languages like C++ and Java (e.g. the nasty need to
> write "if S1.equal(S2) {" in Java, rather than "if S1 = S2 then" in
> Ada 95, or the awkward connection between operator "friends" in C++
> and the "associated" class).

Functions may be defined in C++ as binary operations by declaration
outside a class, e.g.

class Person
{
...
   friend Marry( Person&, Person& ); // Only needed in Marry needs
access to private data/methods
};

void Marry( Person&, Person& );

> Personally the problem I have with the "state"-oriented model is
> for various operations that have two or more objects involved,
> and it is not at all obvious which one is the "primary" object.

Here, neither person is the 'primary' object: probably both objects are
updated with the details of their partner. 

> We certainly debated multiple inheritance.  I think we were reluctant
> to build in syntax for a feature that seemed in some cases a
> solution looking for a problem.  Also the fact that the designers of
> C++ couldn't decide  between "virtual" and "non-virtual" base classes,
> and felt obliged to support both, and that many Eiffel uses of
> multiple inheritance seemed to represent "uses" rather than "is-a"
> relationships, made us feel that multiple inheritance was still in an awkward
> stage of development.

As a programmer looking for tools to support the abstraction of problems
into code, I would sooner have both than neither.

I would be happy with an implementation of MI that only allowed mix-in
inheritance, where classes do not overlap and all methods must be
unique.

> The one thing I would add now to Ada 95 would probably
> be something more akin to the Java multiple inheritance of interfaces.
> Inheriting implementations from multiple parents seems quite error prone,
> but inheriting interfaces is pretty clean.  

Yes, but I will then have to 'cut and paste' the common code behind
multiple uses of an interface, and cut and paste leads to
unmaintainable, error prone code. What are the chances of all the code
behind an interface being different?


On the one hand, I like Ada for its 'programmer protection' mechanisms;
on the other I regret losing what I consider powerful or natural
features and behaviour because of common programming mishaps.

C++ seems to be geared to providing all the power with no regard for the
abilities of an average programmer. Scary.


One final Ada quibble: Why are Ada generics so static? Generics would be
far more powerful, without being less safe(?), if the *instantiations*
were compiled statically, rather than the generic itself. 

Chris.

Re: Help me to chose between ADA 95 and C++

[Robert A Duff]

Chris Powell <chris.powell@rrds.co.uk> writes:

> One final Ada quibble: Why are Ada generics so static? Generics would be
> far more powerful, without being less safe(?), if the *instantiations*
> were compiled statically, rather than the generic itself. 

What do you mean by that?

- Bob

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <38561A6C.5DE3D901@rdel.co.uk> , Chris Powell 
<chris.powell@rrds.co.uk>  wrote:

> C++ encapsulates methods and data in a single structure. In Ada, class
> methods are defined outside the object type so do not appear to 'belong'
> to the type.

The enclosing package defines what operations are primitive for a type.
So of course the operations are declared "in the type," because they're
in the same package:

package Apples is

  type Apple_Type (<>) is tagged limited private;

  procedure Eat (Apple : access Apple_Type);
...
end Apples;

Procedure Eat is a primitive operation of type Apples.  That's not
obvious?


> Having to explicitly pass the object instance as a parameter (the
> implicit 'this' in C++) further separates the logical association
> between methods and objects.

When I see the procedure declaration:

package Stacks is

  type Stack_Type is limited private;

  procedure Push
    (Item : in     Item_Type;
     On   : in out Stack_Type);
...
end Stacks;


it's perfectly obvious that it's a primitive operation for stacks.

When I see the procedure invocation:

  Push (Item, On => Stack);

it's perfectly obvious that Push is operating on a stack object.

So I don't buy your argument that the syntax "separates the logical
association between methods and objects."

Note also that the Ada95 syntax simplifies binary operations:

  Marry (Adam, Eve);

is a lot more natural than

  Adam.Marry (Eve);



> I am a Multiple Inheritance fan, because I think I know how to use it
> properly. I do not believe it (always) indicates a bad design, as some
> do. Ada 95 has some constructs to allow different types of MI, but not
> all provided by the more general approach of C++, and again, the syntax
> is obscure involving tagged types within generics, access discrimiated
> records, etc. In C++ you simply define an X as a Y and a Z. In Ada, the
> syntax would have been (if allowed):
>
>    type Object is new X.Object and new Y.Object with record ....

Yes, you have to understand how to use access discriminants (to do MI)
and generic formal tagged types (to do mixin inheritance).

The MI and mixin idioms are built on existing language features, so this
keeps the language itself simpler.

I could argue the point the other way.  In C++, the keyword "virtual" is
used so often for so many different things, that it's hard to keep them
all straight.

Re: Help me to chose between ADA 95 and C++

[Hyman Rosen]

"Matthew Heaney" <matthew_heaney@acm.org> writes:
> I could argue the point the other way.  In C++, the keyword "virtual" is
> used so often for so many different things, that it's hard to keep them
> all straight.

No, no, you're thinking of the keyword "static" :-)

The keyword virtual is used for only two completely different
things. A virtual method is dispatching. A virtual base class
is present only once in a derived object, regardless of how
many times it appears in the inheritance hierarchy (as virtual).

Re: Help me to chose between ADA 95 and C++

[Preben Randhol]

"Robert" <robert.bralic@si.tel.hr> writes:
[...]
| between ADA 95 and C++.I don't know anything about ADA 95
| ,but I hearded that is wey good object oriented language, wey safe.
| Please send me your opinion and answers to my questions:

Look at these pages:

http://www.adaic.org/intro/
http://www.adaic.org/jobs/
http://www.AdaPower.com/

| 2)Does exist any tool and library for GUI design with ADA 95
|    on Windows 95/NT or X-Windows, comercial or free ?

Here is one that is free. 

http://gtkada.eu.org/

| 4)Is learning ADA 95 and profesional programing, debuging
|   easiest than do this in C++ ?

Personally I find Ada95 easier to learn than C++. 

One of the big advantages with Ada 95 is the strict typing. This means
that the compiler will catch a lot of your mistakes and tell you. Thus
you find many of the bugs at compile-time rather during execution of
the program (if using a less strict typing language). Therefore you
will probably be able to reduce time you have to spend with the
debugger. I'm using the GNAT Ada95 compiler (http://www.gnat.com). I
find it very good. Not only does it tell me that I have done something
wrong, but sometimes it can also spot the reason why it is wrong. Like
yesterday I had forgotten to put:

with Ada.Text_IO; use Ada.Text_IO; 

in one of the files, and the compiler suggested that there might be a
missing Text_IO as I was trying to use Put_Line. 

One also has the ability to turn on style checking. That is the
compiler will check for proper indentation of the code and other
tihngs. This is very nice for a newbie like me at least.

But other Ada 95 compilers might have the same nice functionality, I
have just tried GNAT.

-- 
Preben Randhol                     "Marriage is when you get to keep
[randhol@pvv.org]                   your girl and don't have to give
[http://www.pvv.org/~randhol/]      her back to her parents." (Eric, 6)

Re: Help me to chose between ADA 95 and C++

[Preben Randhol]

Preben Randhol <randhol@pvv.org> writes:

| One also has the ability to turn on style checking. That is the
| compiler will check for proper indentation of the code and other
                                             ^^^^^^^^^^^
of the source code

-- 
Preben Randhol                     "Marriage is when you get to keep
[randhol@pvv.org]                   your girl and don't have to give
[http://www.pvv.org/~randhol/]      her back to her parents." (Eric, 6)

Re: Help me to chose between ADA 95 and C++

[Lionel Draghi]

Robert wrote:
> 
> I work with ORACLE on AIX at my job and I want to learn one
> serious object oriented language.I have some expirience with Java
> ,but this is not what I want.At my opinion Java is good, portable
> ,easy to learn and debug but as a language is just a C++ without
> things that programing in C++ makes as art.So I am trying to chose
> between ADA 95 and C++.I don't know anything about ADA 95
> ,but I hearded that is wey good object oriented language, wey safe.
...
You will find many papers on the WEB comparing Ada and C++ (and Java)
features.
If you allready have some C++ knowledge,
http://www.adahome.com/Ammo/cpp2ada.html
is an interesting paper.

________________________________________________________________________
Lionel Draghi                                          http://attac.org/

RE: Help me to chose between ADA 95 and C++

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Richard Riehle et al.
How do you set an instantiation equal to a universal integer or
universal_real? I tried to do this with a 32 bit data type and had to define
a non_private type for simple operations like
Data_32 : Data_32_Type := 7;
I then converted from the non_private to the private (Ugly).

-----Original Message-----
From: Richard D Riehle [mailto:laoXhai@ix.netcom.com]
Sent: Tuesday, December 14, 1999 10:55 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Help me to chose between ADA 95 and C++


In article <38566835.B4A2D48@rdel.co.uk>,
	Chris Powell <chris.powell@rrds.co.uk> wrote:

>Good type design (especially in an OO system) would define types with
>appropriate functions acting on those types, possibly returning other
>types effectively defining allowed conversions. This is no different
>from defining C++ classes with appropriate methods which are effectively
>type safe through data hiding and a well defined public interface.

I am going to respond to only one of your points.  Your response to
my other arguments was intelligent and thoughtful.  In the case of
this response, you are right on the mark!

I have long felt that we often expose too much of some numeric types
in our packages and ought to take more care to hide some of the
details.  This would lead to better maintenance as well as more
options for "design by contract."

The following example will be short, and that is always a problem since
code fragments never fully represent the range of possibilities.

package Real_Number is
  type Real is private;
  function "+" (L, R : Real) return Real;
  -- same for all other operators
  Divide_By_Zero : exception;
  -- more exceptions
private
  type Real is digits 9;
end Real_Number;

The corresponding package body can have additional checks within
each operation to ensure conformity to the application constraints.
It turns out, though, that implementing this, in Ada, is somewhat
tedious because of the need to avoid recursive calls within each
function in the package body.  It can be done.

More interesting is,

generic
   type Number is private;
   with function "+" (L, R : Number) return Number is <>;
   -- all other operators similarly declared as generic parameters
package Generic_Operators is end Generic_Operators;

with Generic_Operators;
generic
  with package Operators is new Generic_Operators (<>);
package Statistics is
   ...
end Statistics;

which allows instantiation with any numeric type.  Also, there is a
way to instantiate this with a non-numeric type that I published in
an Ada Letters a couple of years ago.

So, on this point, Chris, I am pretty much in agreement with you.

Richard Riehle

      P.S.  I apologize if my earlier reply was a bit to harsh.

RE: Help me to chose between ADA 95 and C++

[Richard D Riehle]

In article <NBBBJNOMKDIAJALCEFIJOELFDGAA.rleif@rleif.com>,
	"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote:

>From: Bob Leif
>To: Richard Riehle et al.
>How do you set an instantiation equal to a universal integer or
>universal_real? I tried to do this with a 32 bit data type and had to
define
>a non_private type for simple operations like
>Data_32 : Data_32_Type := 7;
>I then converted from the non_private to the private (Ugly).

Robert,

A universal integer is not a defined type.  You would want to 
declare a type to accomplish instantiation using my generic 
example.  It cannot be instantiated with a universal integer
or a universal float since it is a private type formal parameter.

I am not sure whether I actually answered your question.  Perhaps
someone else will have a different reading of it.

Regards,

Richard

-- =========== Code from my earlier post follows =================  

>generic
>   type Number is private;
>   with function "+" (L, R : Number) return Number is <>;
>   -- all other operators similarly declared as generic parameters
>package Generic_Operators is end Generic_Operators;
>
>with Generic_Operators;
>generic
>  with package Operators is new Generic_Operators (<>);
>package Statistics is
>   ...
>end Statistics;
>
>which allows instantiation with any numeric type.  Also, there is a
>way to instantiate this with a non-numeric type that I published in
>an Ada Letters a couple of years ago.
>
>So, on this point, Chris, I am pretty much in agreement with you.
>
>Richard Riehle
>
>      P.S.  I apologize if my earlier reply was a bit to harsh.
>
>
>
>
>
>

 

RE: Help me to chose between ADA 95 and C++

[Robert C. Leif, Ph.D.]

Richard
I was remarking on a standard private type in the specification of a generic
or any other package. If your numeric types are declared in the private part
of a package, you can not set them equal to the literal value of a number,
like 7. Perhaps your solution of using generics would eliminate this
problem. I can not write a subprogram specification to put into a package
specification using ":=" as a function where the formal parameter would be a
universal type. This makes be question how you could create an instantiation
of a generic function to do this.

Yours,
Bob

-----Original Message-----
From: Richard D Riehle [mailto:laoXhai@ix.netcom.com]
Sent: Tuesday, December 14, 1999 7:09 PM
To: comp.lang.ada@ada.eu.org
Subject: RE: Help me to chose between ADA 95 and C++


In article <NBBBJNOMKDIAJALCEFIJOELFDGAA.rleif@rleif.com>,
	"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote:

>From: Bob Leif
>To: Richard Riehle et al.
>How do you set an instantiation equal to a universal integer or
>universal_real? I tried to do this with a 32 bit data type and had to
define
>a non_private type for simple operations like
>Data_32 : Data_32_Type := 7;
>I then converted from the non_private to the private (Ugly).

Robert,

A universal integer is not a defined type.  You would want to
declare a type to accomplish instantiation using my generic
example.  It cannot be instantiated with a universal integer
or a universal float since it is a private type formal parameter.

I am not sure whether I actually answered your question.  Perhaps
someone else will have a different reading of it.

Regards,

Richard

-- =========== Code from my earlier post follows =================

>generic
>   type Number is private;
>   with function "+" (L, R : Number) return Number is <>;
>   -- all other operators similarly declared as generic parameters
>package Generic_Operators is end Generic_Operators;
>
>with Generic_Operators;
>generic
>  with package Operators is new Generic_Operators (<>);
>package Statistics is
>   ...
>end Statistics;
>
>which allows instantiation with any numeric type.  Also, there is a
>way to instantiate this with a non-numeric type that I published in
>an Ada Letters a couple of years ago.
>
>So, on this point, Chris, I am pretty much in agreement with you.
>
>Richard Riehle
>
>      P.S.  I apologize if my earlier reply was a bit to harsh.
>
>
>
>
>
>

RE: Help me to chose between ADA 95 and C++

[Richard D Riehle]

In article <NBBBJNOMKDIAJALCEFIJGELPDGAA.rleif@rleif.com>,
	"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote:

>Richard
>I was remarking on a standard private type in the specification of a
generic
>or any other package. If your numeric types are declared in the private
part
>of a package, you can not set them equal to the literal value of a number,

I am sure Matt Heaney will have some good things to say about this too.
The answer is that one must export the methods appropriate to any
private type.  If that type is a numeric, then methods for all of
its uses are necessary.

In my published example, I include the operators one would expect. I
also include some functions for auxiliary services.  Some of these
would be,

        type Number is private;

        function Set (To : Integer) return Number;
        function Zero_Equivalent return Number;
        function Unit_Increment return  Number;
        function Unit_Decrement return  Number;

In the opinion of many OO practitioners, one should only export 
services in the public part of a specification.  For example, even
the popular deferred constant, under this viewpoint, would be better
designed as a function returning a constant.  That makes it more
maintainable and defers information about the constant to the
package body.  

One of the benefits of Ada is its openess to multiple models of
object-oriented design.  Not every type needs to be value extensible.
Ada child packages, and rules of elementary types, provide a model
for method extensibility that has far less overhead than might
be found in a language where the only mechanism for extensibility
is inheritance.  

Hope this helps,

Richard

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <83b8il$i5k$1@nntp4.atl.mindspring.net> , Richard D Riehle 
<laoXhai@ix.netcom.com>  wrote:

> I am sure Matt Heaney will have some good things to say about this too.

Well, I have some things to say, but I'm not sure they qualify as
"good."


> The answer is that one must export the methods appropriate to any
> private type.  If that type is a numeric, then methods for all of
> its uses are necessary.

My advice is not to declare a numeric type as private.  In a sense, the
type is already private, so you're hiding a type whose representation is
already hidden.

For example, the floating point declaration

package P is

  type T is digits 8;

end P;

already has a "hidden" representation, which includes a sign bit,
mantissa, and exponent.  So hiding the floating point type behind yet
another wall, ie

package P is

  type T is private;
  <primitive ops>

private

  type Rep is digits 8;
  type T is new Rep;

end P;

doesn't seem to be buying you a whole lot.

(Note that the private derivation is there to keep public and private
namespaces separate.  Public operations are implemented by internally
converting the subprogram parameter from type T to type Rep, and then
using Rep's operations.)

Even an integer type has a "hidden" representation.  For example:

  type T is range 100_000 .. 100_255;
  for T'Size use 8;

forces T to have a biased representation.  Publicly, of course, you
refer to literal values in the stated range:

  O : T := 100_100;
  ...
  O := 100_111;

but internally the compiler is using a representation that has the range
0 .. 255.


>         type Number is private;
>
>         function Set (To : Integer) return Number;
>         function Zero_Equivalent return Number;
>         function Unit_Increment return  Number;
>         function Unit_Decrement return  Number;

You can do this without declaring a private type:

  type Number is new Integer;



> In the opinion of many OO practitioners, one should only export
> services in the public part of a specification.  For example, even
> the popular deferred constant, under this viewpoint, would be better
> designed as a function returning a constant.  That makes it more
> maintainable and defers information about the constant to the
> package body.

I agree that, for abstract data types, it's better to use a function
instead of a deferred constant, but for a different reason.  The problem
with constants is that they aren't inherited during a derivation.
Functions, because they're primitive operations, are inherited.


> One of the benefits of Ada is its openess to multiple models of
> object-oriented design.  Not every type needs to be value extensible.
> Ada child packages, and rules of elementary types, provide a model
> for method extensibility that has far less overhead than might
> be found in a language where the only mechanism for extensibility
> is inheritance.

Amen to that.  Many programmers using other languages (and incredibly,
many Ada programmers) don't appreciate how you can decouple abstractions
when you don't use inheritance.

For example, in a recent thread, someone had written:

with Semphores;  use Semaphores;
generic
  type Semaphore_Type is new Root_Semaphore_Type with private;
package Semaphore_Constrols_G is

  type Semaphore_Control (Semaphore : access Semaphore_Type'Class) is
    limited private;
...
end Semaphore_Controls;

This is wrong, because it unnecessarily couples the abstraction
Semaphore_Controls to the abstraction Semaphores.  Better is to simply
import the type as a formal private type:

generic
  type Semaphore_Type is limited private;
  with procedure Seize (Sema : in out Semaphore_Type) is <>;
  with procedure Release (Sema : in out Semaphore_Type) is <>;
package Semaphore_Controls is ...;

This can be used with *any* type that has the indicated operations.  The
operations don't even have to be named "seize" and "release".

There is no reason to create a hierarchy of semaphores, nor is there any
reason to marry semaphore controls to that particular hierarchy.


--
I see no good reasons why the views given in this volume should shock
the religious feelings of anyone.

Charles Darwin, The Origin of Species

Re: Help me to chose between ADA 95 and C++

[Richard D Riehle]

In article <3859abde_3@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:

>In article <83b8il$i5k$1@nntp4.atl.mindspring.net> , Richard D Riehle 
><laoXhai@ix.netcom.com>  wrote:
>
>> I am sure Matt Heaney will have some good things to say about this too.
>
>Well, I have some things to say, but I'm not sure they qualify as
>"good."

Whenever you say something like that, I know we are in for some
controversial commentary from you.  :-)
>
>My advice is not to declare a numeric type as private.  In a sense, the
>type is already private, so you're hiding a type whose representation is
>already hidden.

In general this is true.  From time to time it might be useful to
expand or contract the exported behavior for a particular numeric
type.  For example, I saw a design not long ago with this declaration,

       type Counter is private;
       function Initialize return Counter;
       function Increment return Counter;
       function Decrement return Counter;

where the full defintion was a integer type. The designer intended to 
prevent any operations on Counter except increment and decrement. For
this application, that was a reasonable approach and eliminated any of
the complications associated with a client doing more arithmetic than
necessary.  I can think of other circumstances where it would be
useful to hide the actual type definition and export a restricted set
of operations, or a special set of operations.  Moreover, it might be
useful to expand the set of exceptions for that type and add pre- and
post- conditions in the implementation of some operator/operation.  


>For example, the floating point declaration

   [ snip ]

I understand your argument for simply using the available numeric
types as defined in the language.  This is usually appropriate. Now
and then it is appropriate to take the design a little further with
private types.  Not always.  But it is nice that we can do this when
it is appropriate.

Your example, as follows would be overkill if one where doing nothing
but parroting all the primitive operations.  
>package P is
>
>  type T is private;
>  <primitive ops>
>
>private
>
>  type Rep is digits 8;
>  type T is new Rep;
>
>end P;

Suppose, however, that we want to do a little more than that.  
Suppose the Divide operation is modified as (contrived example):

    function "/"(L , R : T) return T is
        Result : T;
    begin
       if R = Zero then ...          -- raise some exception?
       elsif some-other-condition    -- raise some other exception 
       elsif even-another-condition  -- raise even-another-exception
       else
          Result := Division-operation
       end if;
       if Result is-in-some condition -- raise post-condition-exception
           -- potentially more tests
       else
          return Result;
       end if;
     end "*";
              
I fully understand the problems with this example, but I also recognize
that, in the absence of exportable pre- and post-conditions in Ada, we
have few options but to check for these within the code itself.  Under
these circumstances, I might want to write my own operators to ensure
conformity with rules that cannot be described through simple range
constraints.
>
>I agree that, for abstract data types, it's better to use a function
>instead of a deferred constant, but for a different reason.  The problem
>with constants is that they aren't inherited during a derivation.
>Functions, because they're primitive operations, are inherited.

I agree that this is an additional problem.  Deferred constants seem
to violate many of the principles of object-oriented programming.

I think we are once again in agreement on most points.  

Richard Riehle

Re: Help me to chose between ADA 95 and C++

[Matthew Heaney]

In article <83dsno$5v2$1@nntp2.atl.mindspring.net> , Richard D Riehle 
<laoXhai@ix.netcom.com>  wrote:

> In general this is true.  From time to time it might be useful to
> expand or contract the exported behavior for a particular numeric
> type.  For example, I saw a design not long ago with this declaration,
>
>        type Counter is private;
>        function Initialize return Counter;
>        function Increment return Counter;
>        function Decrement return Counter;
>
> where the full defintion was a integer type. The designer intended to
> prevent any operations on Counter except increment and decrement. For
> this application, that was a reasonable approach and eliminated any of
> the complications associated with a client doing more arithmetic than
> necessary.

But you can add and even subtract operations from a scalar type:

  type Counter is new Integer;

  function "+" (L, R : Counter) return Counter is abstract;

  function "-" (L, R : Counter) return Counter is abstract;

You can then use Counter'Succ and Counter'Pred.


> I can think of other circumstances where it would be
> useful to hide the actual type definition and export a restricted set
> of operations, or a special set of operations.  Moreover, it might be
> useful to expand the set of exceptions for that type and add pre- and
> post- conditions in the implementation of some operator/operation.

You can also replace operations:

  type Heading_Type_Base delta 1.0/2**(-16) range -720.0 .. 720.0;

  subtype Heading_Type is
    Heading_Type_Base range 0.0 .. Heading_Type_Base'Pred (360.0);

  function Predefined_Add
    (L, R : Heading_Type_Base) return Heading_Type_Base renames "+";

  function "+" (L, R : Heading_Type) return Heading_Type;

  function Predefined_Subtract
    (L, R : Heading_Type_Base) return Heading_Type_Base renames "-";

  function "-" (L, R : Heading_Type) return Heading_Type;

Now you can implement "+" and "-" to have wrap-around behaviour:

  H := 359.0;
  H := H + 2.0;  -- H = 1.0
  H := 5.0;
  H := H - 10.0;  -- H = 355.0


> Suppose, however, that we want to do a little more than that.
> Suppose the Divide operation is modified as (contrived example):
>
>     function "/"(L , R : T) return T is
>         Result : T;
>     begin
>        if R = Zero then ...          -- raise some exception?
>        elsif some-other-condition    -- raise some other exception
>        elsif even-another-condition  -- raise even-another-exception
>        else
>           Result := Division-operation
>        end if;
>        if Result is-in-some condition -- raise post-condition-exception
>            -- potentially more tests
>        else
>           return Result;
>        end if;
>      end "/";
>
> I fully understand the problems with this example, but I also recognize
> that, in the absence of exportable pre- and post-conditions in Ada, we
> have few options but to check for these within the code itself.

But pre- and post-condition checking is a separate issue from overriding
predefined operators of a scalar type.  We could declare your divide op
for a non-private type:

  type T is new Float;

  function Predefined_Divide (L, R : T) return T renames "/";

  function "/" (R, L : T) return T;


You may prefer to not use an infix operator at all:

  type T is new Float;

  function Div (Dividend, Divisor : T) return T;


In any case you're free to raise whatever exceptions are appropriate.

As far as pre- and post-condition checking goes, I prefer to check using
pragma Assert.  No, this is not an official standard, but it is a de
facto standard.  (There's even an AI to add this pragma to the
language.)

The benefit using a pragma is that the assertion check can be turned on
or off using switches, analogous to suppressing constraint checks.


> Under these circumstances, I might want to write my own operators to ensure
> conformity with rules that cannot be described through simple range
> constraints.

Agreed, but this doesn't mean you have to declare the type as private.


> I agree that this is an additional problem.  Deferred constants seem
> to violate many of the principles of object-oriented programming.

They have their place.  If I write an ADT for exclusive use within a
subsystem -- where I know no type derivation will occur -- then I'd
probably use a deferred constant.

However, if you write an ADT for general consumption, and you don't
really know who your clients are, then I'd use a function.  (Again,
because they might do some derivations, and we want the function to be
inherited.  Constants aren't inherited.)

This issue rears its ugly head for another reason.  If you use a
deferred constant, and elaboration of the constant requires nonstatic
initialization, then you won't be able to use pragma Preelaborate:

package Lists is

  pragma Preelaborate;  --illegal...

  type List_Type is private;

  Null_List : List_Type;
  ...
private
  type List_Type is new Controlled with
    record
      Head : Node_Access;
    end record;

  Null_List : constant List_Type := (Controlled with Head => null);
   -- ... because this is nonstatic

end Lists;


We'd like to use the strongest form of categorization pragma possible.
Above, we'd have to change down to pragma Elaborate_Body.

The solution is to declare Null_List as a primitive operation of the
type:

package Lists
  pragma Preelaborate;  -- legal ...
  type List_Type is private;

  function Null_List return List_Type;
    -- ... because this returns its value at run-time

private
  type List_Type is <as above>
end Lists;


> I think we are once again in agreement on most points.

Yes.

--
Creationists attempt to draw a line between evolutionary biology and the
rest of science by remarking that large-scale evolution cannot be
observed.  This tactic fails.  Large-scale evolution is no more
inaccessible to observation than nuclear reactions or the molecular
composition of water.

Abusing Science: The Case Against Creationism
Philip Kitcher

Re: Help me to chose between ADA 95 and C++

[Richard D Riehle]

In article <385bab78_3@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:


>But you can add and even subtract operations from a scalar type:
>
>  type Counter is new Integer;
>
>  function "+" (L, R : Counter) return Counter is abstract;
>
>  function "-" (L, R : Counter) return Counter is abstract;
>
>You can then use Counter'Succ and Counter'Pred.

I am aware of this fact, Matthew.  The example I posted has the
benefit of 1) enforcing information hiding,  2) a set of
operations with single, unambiguous usage, and 3) considerable
simplicity.  I suppose one could argue about this, but it would
be ultimately a matter of opinion rather than a matter of technical
superiority of one form over the other.

>
>You can also replace operations:
>
>  type Heading_Type_Base delta 1.0/2**(-16) range -720.0 .. 720.0;
>
>  subtype Heading_Type is
>    Heading_Type_Base range 0.0 .. Heading_Type_Base'Pred (360.0);
>
>  function Predefined_Add
>    (L, R : Heading_Type_Base) return Heading_Type_Base renames "+";
>
>  function "+" (L, R : Heading_Type) return Heading_Type;
>
>  function Predefined_Subtract
>    (L, R : Heading_Type_Base) return Heading_Type_Base renames "-";
>
>  function "-" (L, R : Heading_Type) return Heading_Type;
>
>Now you can implement "+" and "-" to have wrap-around behaviour:
>
>  H := 359.0;
>  H := H + 2.0;  -- H = 1.0
>  H := 5.0;
>  H := H - 10.0;  -- H = 355.0
>
Again, this is not new information.  It seems stylistically a little
excessive, but not obscene.  My original point was that, now and then
it is useful to be able to declare a numeric type as private.  Not 
always.  Simply that, it is nice to have that capability available.
>
>But pre- and post-condition checking is a separate issue from overriding
>predefined operators of a scalar type.  We could declare your divide op
>for a non-private type:
>
>  type T is new Float;
>
>  function Predefined_Divide (L, R : T) return T renames "/";
>
>  function "/" (R, L : T) return T;
>
>
>You may prefer to not use an infix operator at all:
>
>  type T is new Float;
>
>  function Div (Dividend, Divisor : T) return T;
>
This does not behave exactly as the example I posted.  Also, if I
plan to export my own division, I don't want to also export the
predefined version.  This would be a case where I would want a
private type to prevent anyone from using the predefined division.
>
>In any case you're free to raise whatever exceptions are appropriate.
>
Only if there is an opportunity to do so before actually using the
predefined operators.  That is exactly the point.
>
>As far as pre- and post-condition checking goes, I prefer to check using
>pragma Assert.  No, this is not an official standard, but it is a de
>facto standard.  (There's even an AI to add this pragma to the
>language.)
>
pragma Assert is a nice addition to some compilers.  As you note, it is
not part of the standard and not implemented in all compilers.  
>
>Agreed, but this doesn't mean you have to declare the type as private.
>
Maybe not, but declaring the type private ensures that I export only
the operators relevant to the abstraction intended.  It is not a matter
of _have to_ , it is a matter of what is appropriate under a particular
set of circumstances.  

Richard Riehle

Re: Help me to chose between ADA 95 and C++ (

[Ehud Lamm]

On Tue, 14 Dec 1999, Chris Powell wrote:

|Brian Rogoff wrote:
|
|> Of course, none of this is really OO, but I think OO is way overrated anyways.
|> Since you mention STL in the same paragraph as OO, I suppose I should ask
|> you what you mean by OO. Most people wouldn't consider the STL OO,
|> including its authors.
|
|Its true that the STL is not implemented using OO constructs, but it is
|conceptually OO, with the concept of a container base class defining
|methods for manipulating elements, which are overriden to work
|differently for specific container types and the abstraction of
|iterators which can work on any type of container... 


I hope you are saying this after reading Stepanov's view of OO. You can
find it in the interviews linked from my site. Makes for interesting
reading.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!