* Help me to chose between ADA 95 and C++ @ 1999-11-26 0:00 Robert 1999-11-26 0:00 ` Andreas Winckler ` (3 more replies) 0 siblings, 4 replies; 67+ messages in thread From: Robert @ 1999-11-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 Help me to chose between ADA 95 and C++ Robert @ 1999-11-26 0:00 ` Andreas Winckler 1999-11-26 0:00 ` Harald Schmidt ` (2 subsequent siblings) 3 siblings, 0 replies; 67+ messages in thread From: Andreas Winckler @ 1999-11-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 Help me to chose between ADA 95 and C++ Robert 1999-11-26 0:00 ` Andreas Winckler @ 1999-11-26 0:00 ` Harald Schmidt 1999-11-26 0:00 ` Andreas Winckler 1999-12-04 0:00 ` Richard D Riehle 1999-11-26 0:00 ` Preben Randhol 1999-11-27 0:00 ` Lionel Draghi 3 siblings, 2 replies; 67+ messages in thread From: Harald Schmidt @ 1999-11-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 ` Harald Schmidt @ 1999-11-26 0:00 ` Andreas Winckler 1999-11-26 0:00 ` Florian Weimer 1999-12-04 0:00 ` Richard D Riehle 1 sibling, 1 reply; 67+ messages in thread From: Andreas Winckler @ 1999-11-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 ` Andreas Winckler @ 1999-11-26 0:00 ` Florian Weimer 0 siblings, 0 replies; 67+ messages in thread From: Florian Weimer @ 1999-11-26 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 ` Harald Schmidt 1999-11-26 0:00 ` Andreas Winckler @ 1999-12-04 0:00 ` Richard D Riehle [not found] ` <01bf3e32$0b9dc880$022a6282@dieppe> 1 sibling, 1 reply; 67+ messages in thread From: Richard D Riehle @ 1999-12-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
[parent not found: <01bf3e32$0b9dc880$022a6282@dieppe>]
* Re: Help me to chose between ADA 95 and C++ [not found] ` <01bf3e32$0b9dc880$022a6282@dieppe> @ 1999-12-10 0:00 ` Chris Powell 1999-12-13 0:00 ` Brian Rogoff ` (4 more replies) 0 siblings, 5 replies; 67+ messages in thread From: Chris Powell @ 1999-12-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-10 0:00 ` Chris Powell @ 1999-12-13 0:00 ` Brian Rogoff 1999-12-14 0:00 ` Chris Powell 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-13 0:00 ` Richard D Riehle ` (3 subsequent siblings) 4 siblings, 2 replies; 67+ messages in thread From: Brian Rogoff @ 1999-12-13 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-13 0:00 ` Brian Rogoff @ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Brian Rogoff 1999-12-14 0:00 ` Preben Randhol 1999-12-15 0:00 ` Richard Pinkall-Pollei 1 sibling, 2 replies; 67+ messages in thread From: Chris Powell @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell @ 1999-12-14 0:00 ` Brian Rogoff 1999-12-14 0:00 ` Preben Randhol 1 sibling, 0 replies; 67+ messages in thread From: Brian Rogoff @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Brian Rogoff @ 1999-12-14 0:00 ` Preben Randhol 1999-12-14 0:00 ` Stephen Leake 1 sibling, 1 reply; 67+ messages in thread From: Preben Randhol @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Preben Randhol @ 1999-12-14 0:00 ` Stephen Leake 1999-12-14 0:00 ` Tucker Taft 1999-12-15 0:00 ` Preben Randhol 0 siblings, 2 replies; 67+ messages in thread From: Stephen Leake @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Stephen Leake @ 1999-12-14 0:00 ` Tucker Taft 1999-12-15 0:00 ` Stephen Leake 1999-12-15 0:00 ` Preben Randhol 1 sibling, 1 reply; 67+ messages in thread From: Tucker Taft @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Tucker Taft @ 1999-12-15 0:00 ` Stephen Leake 0 siblings, 0 replies; 67+ messages in thread From: Stephen Leake @ 1999-12-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Stephen Leake 1999-12-14 0:00 ` Tucker Taft @ 1999-12-15 0:00 ` Preben Randhol 1 sibling, 0 replies; 67+ messages in thread From: Preben Randhol @ 1999-12-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-13 0:00 ` Brian Rogoff 1999-12-14 0:00 ` Chris Powell @ 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-21 0:00 ` Geoff Bull 1 sibling, 2 replies; 67+ messages in thread From: Richard Pinkall-Pollei @ 1999-12-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-15 0:00 ` Richard Pinkall-Pollei @ 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-21 0:00 ` Geoff Bull 1 sibling, 0 replies; 67+ messages in thread From: Richard Pinkall-Pollei @ 1999-12-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-15 0:00 ` Richard Pinkall-Pollei @ 1999-12-21 0:00 ` Geoff Bull 1999-12-21 0:00 ` Tucker Taft 1 sibling, 1 reply; 67+ messages in thread From: Geoff Bull @ 1999-12-21 0:00 UTC (permalink / raw) Richard Pinkall-Pollei wrote: > > Finally, > repeated studies have confirmed that it costs less to write and > maintain non-trivial Ada programs. References? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-21 0:00 ` Geoff Bull @ 1999-12-21 0:00 ` Tucker Taft 1999-12-22 0:00 ` Ted Dennison 0 siblings, 1 reply; 67+ messages in thread From: Tucker Taft @ 1999-12-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-21 0:00 ` Tucker Taft @ 1999-12-22 0:00 ` Ted Dennison 0 siblings, 0 replies; 67+ messages in thread From: Ted Dennison @ 1999-12-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-10 0:00 ` Chris Powell 1999-12-13 0:00 ` Brian Rogoff @ 1999-12-13 0:00 ` Richard D Riehle 1999-12-14 0:00 ` Chris Powell 1999-12-13 0:00 ` Marin D. Condic ` (2 subsequent siblings) 4 siblings, 1 reply; 67+ messages in thread From: Richard D Riehle @ 1999-12-13 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-13 0:00 ` Richard D Riehle @ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Simon Wright ` (6 more replies) 0 siblings, 7 replies; 67+ messages in thread From: Chris Powell @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell @ 1999-12-14 0:00 ` Simon Wright 1999-12-15 0:00 ` Chris Powell 1999-12-14 0:00 ` Larry Kilgallen ` (5 subsequent siblings) 6 siblings, 1 reply; 67+ messages in thread From: Simon Wright @ 1999-12-14 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Simon Wright @ 1999-12-15 0:00 ` Chris Powell 1999-12-15 0:00 ` Robert A Duff 0 siblings, 1 reply; 67+ messages in thread From: Chris Powell @ 1999-12-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-15 0:00 ` Chris Powell @ 1999-12-15 0:00 ` Robert A Duff 0 siblings, 0 replies; 67+ messages in thread From: Robert A Duff @ 1999-12-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Simon Wright @ 1999-12-14 0:00 ` Larry Kilgallen 1999-12-15 0:00 ` Robert A Duff 1999-12-14 0:00 ` Ray Blaak ` (4 subsequent siblings) 6 siblings, 1 reply; 67+ messages in thread From: Larry Kilgallen @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Larry Kilgallen @ 1999-12-15 0:00 ` Robert A Duff 2000-01-12 0:00 ` Richard Pinkall-Pollei 0 siblings, 1 reply; 67+ messages in thread From: Robert A Duff @ 1999-12-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-15 0:00 ` Robert A Duff @ 2000-01-12 0:00 ` Richard Pinkall-Pollei 0 siblings, 0 replies; 67+ messages in thread From: Richard Pinkall-Pollei @ 2000-01-12 0:00 UTC (permalink / raw) >> 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 ==----- ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Simon Wright 1999-12-14 0:00 ` Larry Kilgallen @ 1999-12-14 0:00 ` Ray Blaak 1999-12-14 0:00 ` Richard D Riehle ` (3 subsequent siblings) 6 siblings, 0 replies; 67+ messages in thread From: Ray Blaak @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell ` (2 preceding siblings ...) 1999-12-14 0:00 ` Ray Blaak @ 1999-12-14 0:00 ` Richard D Riehle 1999-12-14 0:00 ` Matthew Heaney 1999-12-15 0:00 ` Ted Dennison ` (2 subsequent siblings) 6 siblings, 1 reply; 67+ messages in thread From: Richard D Riehle @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Richard D Riehle @ 1999-12-14 0:00 ` Matthew Heaney 0 siblings, 0 replies; 67+ messages in thread From: Matthew Heaney @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell ` (3 preceding siblings ...) 1999-12-14 0:00 ` Richard D Riehle @ 1999-12-15 0:00 ` Ted Dennison 1999-12-20 0:00 ` Stefan Skoglund 1999-12-16 0:00 ` Pascal Obry 1999-12-21 0:00 ` Robert Dewar 6 siblings, 1 reply; 67+ messages in thread From: Ted Dennison @ 1999-12-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-15 0:00 ` Ted Dennison @ 1999-12-20 0:00 ` Stefan Skoglund 0 siblings, 0 replies; 67+ messages in thread From: Stefan Skoglund @ 1999-12-20 0:00 UTC (permalink / raw) 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 ?.) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell ` (4 preceding siblings ...) 1999-12-15 0:00 ` Ted Dennison @ 1999-12-16 0:00 ` Pascal Obry 1999-12-16 0:00 ` Rakesh Malhotra ` (2 more replies) 1999-12-21 0:00 ` Robert Dewar 6 siblings, 3 replies; 67+ messages in thread From: Pascal Obry @ 1999-12-16 0:00 UTC (permalink / raw) [-- 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" ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-16 0:00 ` Pascal Obry @ 1999-12-16 0:00 ` Rakesh Malhotra 1999-12-21 0:00 ` Geoff Bull 1999-12-16 0:00 ` Lutz Donnerhacke 1999-12-16 0:00 ` Aidan Skinner 2 siblings, 1 reply; 67+ messages in thread From: Rakesh Malhotra @ 1999-12-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-16 0:00 ` Rakesh Malhotra @ 1999-12-21 0:00 ` Geoff Bull 0 siblings, 0 replies; 67+ messages in thread From: Geoff Bull @ 1999-12-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-16 0:00 ` Pascal Obry 1999-12-16 0:00 ` Rakesh Malhotra @ 1999-12-16 0:00 ` Lutz Donnerhacke 1999-12-16 0:00 ` Aidan Skinner 2 siblings, 0 replies; 67+ messages in thread From: Lutz Donnerhacke @ 1999-12-16 0:00 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-16 0:00 ` Pascal Obry 1999-12-16 0:00 ` Rakesh Malhotra 1999-12-16 0:00 ` Lutz Donnerhacke @ 1999-12-16 0:00 ` Aidan Skinner 2 siblings, 0 replies; 67+ messages in thread From: Aidan Skinner @ 1999-12-16 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell ` (5 preceding siblings ...) 1999-12-16 0:00 ` Pascal Obry @ 1999-12-21 0:00 ` Robert Dewar 1999-12-21 0:00 ` Chris Powell 1999-12-21 0:00 ` Ted Dennison 6 siblings, 2 replies; 67+ messages in thread From: Robert Dewar @ 1999-12-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-21 0:00 ` Robert Dewar @ 1999-12-21 0:00 ` Chris Powell 1999-12-21 0:00 ` Ted Dennison 1 sibling, 0 replies; 67+ messages in thread From: Chris Powell @ 1999-12-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-21 0:00 ` Robert Dewar 1999-12-21 0:00 ` Chris Powell @ 1999-12-21 0:00 ` Ted Dennison 1999-12-21 0:00 ` Robert Dewar 1 sibling, 1 reply; 67+ messages in thread From: Ted Dennison @ 1999-12-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-21 0:00 ` Ted Dennison @ 1999-12-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 67+ messages in thread From: Robert Dewar @ 1999-12-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-10 0:00 ` Chris Powell 1999-12-13 0:00 ` Brian Rogoff 1999-12-13 0:00 ` Richard D Riehle @ 1999-12-13 0:00 ` Marin D. Condic 1999-12-13 0:00 ` DuckE 1999-12-14 0:00 ` Matthew Heaney 4 siblings, 0 replies; 67+ messages in thread From: Marin D. Condic @ 1999-12-13 0:00 UTC (permalink / raw) 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 ============================================================= ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-10 0:00 ` Chris Powell ` (2 preceding siblings ...) 1999-12-13 0:00 ` Marin D. Condic @ 1999-12-13 0:00 ` DuckE 1999-12-14 0:00 ` Matthew Heaney 1999-12-14 0:00 ` Matthew Heaney 4 siblings, 1 reply; 67+ messages in thread From: DuckE @ 1999-12-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-13 0:00 ` DuckE @ 1999-12-14 0:00 ` Matthew Heaney 0 siblings, 0 replies; 67+ messages in thread From: Matthew Heaney @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-10 0:00 ` Chris Powell ` (3 preceding siblings ...) 1999-12-13 0:00 ` DuckE @ 1999-12-14 0:00 ` Matthew Heaney 1999-12-14 0:00 ` Chris Powell 4 siblings, 1 reply; 67+ messages in thread From: Matthew Heaney @ 1999-12-14 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Matthew Heaney @ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Stephen Leake ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: Chris Powell @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell @ 1999-12-14 0:00 ` Stephen Leake 1999-12-23 0:00 ` Chris Powell 1999-12-14 0:00 ` Matthew Heaney 1999-12-14 0:00 ` Tucker Taft 2 siblings, 1 reply; 67+ messages in thread From: Stephen Leake @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Stephen Leake @ 1999-12-23 0:00 ` Chris Powell 0 siblings, 0 replies; 67+ messages in thread From: Chris Powell @ 1999-12-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Stephen Leake @ 1999-12-14 0:00 ` Matthew Heaney 1999-12-15 0:00 ` Hyman Rosen 1999-12-14 0:00 ` Tucker Taft 2 siblings, 1 reply; 67+ messages in thread From: Matthew Heaney @ 1999-12-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Matthew Heaney @ 1999-12-15 0:00 ` Hyman Rosen 0 siblings, 0 replies; 67+ messages in thread From: Hyman Rosen @ 1999-12-15 0:00 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Stephen Leake 1999-12-14 0:00 ` Matthew Heaney @ 1999-12-14 0:00 ` Tucker Taft 1999-12-14 0:00 ` Matthew Heaney 1999-12-23 0:00 ` Chris Powell 2 siblings, 2 replies; 67+ messages in thread From: Tucker Taft @ 1999-12-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Tucker Taft @ 1999-12-14 0:00 ` Matthew Heaney 1999-12-23 0:00 ` Chris Powell 1 sibling, 0 replies; 67+ messages in thread From: Matthew Heaney @ 1999-12-14 0:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 ` Tucker Taft 1999-12-14 0:00 ` Matthew Heaney @ 1999-12-23 0:00 ` Chris Powell 1999-12-27 0:00 ` Robert A Duff 1 sibling, 1 reply; 67+ messages in thread From: Chris Powell @ 1999-12-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-23 0:00 ` Chris Powell @ 1999-12-27 0:00 ` Robert A Duff 0 siblings, 0 replies; 67+ messages in thread From: Robert A Duff @ 1999-12-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 Help me to chose between ADA 95 and C++ Robert 1999-11-26 0:00 ` Andreas Winckler 1999-11-26 0:00 ` Harald Schmidt @ 1999-11-26 0:00 ` Preben Randhol 1999-11-26 0:00 ` Preben Randhol 1999-11-27 0:00 ` Lionel Draghi 3 siblings, 1 reply; 67+ messages in thread From: Preben Randhol @ 1999-11-26 0:00 UTC (permalink / raw) "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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 ` Preben Randhol @ 1999-11-26 0:00 ` Preben Randhol 0 siblings, 0 replies; 67+ messages in thread From: Preben Randhol @ 1999-11-26 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-11-26 0:00 Help me to chose between ADA 95 and C++ Robert ` (2 preceding siblings ...) 1999-11-26 0:00 ` Preben Randhol @ 1999-11-27 0:00 ` Lionel Draghi 3 siblings, 0 replies; 67+ messages in thread From: Lionel Draghi @ 1999-11-27 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* RE: Help me to chose between ADA 95 and C++
@ 1999-12-14 0:00 Robert C. Leif, Ph.D.
1999-12-15 0:00 ` Richard D Riehle
0 siblings, 1 reply; 67+ messages in thread
From: Robert C. Leif, Ph.D. @ 1999-12-14 0:00 UTC (permalink / raw)
To: comp.lang.ada
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* RE: Help me to chose between ADA 95 and C++ 1999-12-14 0:00 Robert C. Leif, Ph.D. @ 1999-12-15 0:00 ` Richard D Riehle 0 siblings, 0 replies; 67+ messages in thread From: Richard D Riehle @ 1999-12-15 0:00 UTC (permalink / raw) 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. > > > > > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* RE: Help me to chose between ADA 95 and C++ @ 1999-12-15 0:00 Robert C. Leif, Ph.D. 1999-12-16 0:00 ` Richard D Riehle 0 siblings, 1 reply; 67+ messages in thread From: Robert C. Leif, Ph.D. @ 1999-12-15 0:00 UTC (permalink / raw) To: comp.lang.ada 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. > > > > > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* RE: Help me to chose between ADA 95 and C++ 1999-12-15 0:00 Robert C. Leif, Ph.D. @ 1999-12-16 0:00 ` Richard D Riehle 1999-12-16 0:00 ` Matthew Heaney 0 siblings, 1 reply; 67+ messages in thread From: Richard D Riehle @ 1999-12-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-16 0:00 ` Richard D Riehle @ 1999-12-16 0:00 ` Matthew Heaney 1999-12-17 0:00 ` Richard D Riehle 0 siblings, 1 reply; 67+ messages in thread From: Matthew Heaney @ 1999-12-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-16 0:00 ` Matthew Heaney @ 1999-12-17 0:00 ` Richard D Riehle 1999-12-18 0:00 ` Matthew Heaney 0 siblings, 1 reply; 67+ messages in thread From: Richard D Riehle @ 1999-12-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-17 0:00 ` Richard D Riehle @ 1999-12-18 0:00 ` Matthew Heaney 1999-12-20 0:00 ` Richard D Riehle 0 siblings, 1 reply; 67+ messages in thread From: Matthew Heaney @ 1999-12-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ 1999-12-18 0:00 ` Matthew Heaney @ 1999-12-20 0:00 ` Richard D Riehle 0 siblings, 0 replies; 67+ messages in thread From: Richard D Riehle @ 1999-12-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Help me to chose between ADA 95 and C++ ( @ 1999-12-22 0:00 Ehud Lamm 0 siblings, 0 replies; 67+ messages in thread From: Ehud Lamm @ 1999-12-22 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2000-01-12 0:00 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-26 0:00 Help me to chose between ADA 95 and C++ Robert 1999-11-26 0:00 ` Andreas Winckler 1999-11-26 0:00 ` Harald Schmidt 1999-11-26 0:00 ` Andreas Winckler 1999-11-26 0:00 ` Florian Weimer 1999-12-04 0:00 ` Richard D Riehle [not found] ` <01bf3e32$0b9dc880$022a6282@dieppe> 1999-12-10 0:00 ` Chris Powell 1999-12-13 0:00 ` Brian Rogoff 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Brian Rogoff 1999-12-14 0:00 ` Preben Randhol 1999-12-14 0:00 ` Stephen Leake 1999-12-14 0:00 ` Tucker Taft 1999-12-15 0:00 ` Stephen Leake 1999-12-15 0:00 ` Preben Randhol 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-15 0:00 ` Richard Pinkall-Pollei 1999-12-21 0:00 ` Geoff Bull 1999-12-21 0:00 ` Tucker Taft 1999-12-22 0:00 ` Ted Dennison 1999-12-13 0:00 ` Richard D Riehle 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Simon Wright 1999-12-15 0:00 ` Chris Powell 1999-12-15 0:00 ` Robert A Duff 1999-12-14 0:00 ` Larry Kilgallen 1999-12-15 0:00 ` Robert A Duff 2000-01-12 0:00 ` Richard Pinkall-Pollei 1999-12-14 0:00 ` Ray Blaak 1999-12-14 0:00 ` Richard D Riehle 1999-12-14 0:00 ` Matthew Heaney 1999-12-15 0:00 ` Ted Dennison 1999-12-20 0:00 ` Stefan Skoglund 1999-12-16 0:00 ` Pascal Obry 1999-12-16 0:00 ` Rakesh Malhotra 1999-12-21 0:00 ` Geoff Bull 1999-12-16 0:00 ` Lutz Donnerhacke 1999-12-16 0:00 ` Aidan Skinner 1999-12-21 0:00 ` Robert Dewar 1999-12-21 0:00 ` Chris Powell 1999-12-21 0:00 ` Ted Dennison 1999-12-21 0:00 ` Robert Dewar 1999-12-13 0:00 ` Marin D. Condic 1999-12-13 0:00 ` DuckE 1999-12-14 0:00 ` Matthew Heaney 1999-12-14 0:00 ` Matthew Heaney 1999-12-14 0:00 ` Chris Powell 1999-12-14 0:00 ` Stephen Leake 1999-12-23 0:00 ` Chris Powell 1999-12-14 0:00 ` Matthew Heaney 1999-12-15 0:00 ` Hyman Rosen 1999-12-14 0:00 ` Tucker Taft 1999-12-14 0:00 ` Matthew Heaney 1999-12-23 0:00 ` Chris Powell 1999-12-27 0:00 ` Robert A Duff 1999-11-26 0:00 ` Preben Randhol 1999-11-26 0:00 ` Preben Randhol 1999-11-27 0:00 ` Lionel Draghi -- strict thread matches above, loose matches on Subject: below -- 1999-12-14 0:00 Robert C. Leif, Ph.D. 1999-12-15 0:00 ` Richard D Riehle 1999-12-15 0:00 Robert C. Leif, Ph.D. 1999-12-16 0:00 ` Richard D Riehle 1999-12-16 0:00 ` Matthew Heaney 1999-12-17 0:00 ` Richard D Riehle 1999-12-18 0:00 ` Matthew Heaney 1999-12-20 0:00 ` Richard D Riehle 1999-12-22 0:00 Help me to chose between ADA 95 and C++ ( Ehud Lamm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox