* Ada95 Strengths/Weaknesses. @ 1999-09-27 0:00 the middleman 1999-09-27 0:00 ` Steve Doiel ` (5 more replies) 0 siblings, 6 replies; 87+ messages in thread From: the middleman @ 1999-09-27 0:00 UTC (permalink / raw) I've been learning Ada95 for a year now. And although I don't have much experience of other languages I'd certainly say it was my favourite. In discussions with friends the abilities of Ada95 have cropped up. I was wondering if anyone could possibly point out the weaknesses and the strengths that Ada95 has when compared to other languages such as C so that I can finally set the record straight. Any comment would be appreciated. Thanx. -- ByeZeeBye the middleman Chuck(les) ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman @ 1999-09-27 0:00 ` Steve Doiel 1999-09-27 0:00 ` J. David Bryan ` (4 subsequent siblings) 5 siblings, 0 replies; 87+ messages in thread From: Steve Doiel @ 1999-09-27 0:00 UTC (permalink / raw) My opinion: Advantages of Ada95 Ada95 code will behave the same when compiled using compilers from different vendors. There are exceptions to this but the are rare. Tasking is defined as a part of the language. The compiler will catch many coding errors at compile time. The runtime will catch many programming errors with runtime checks. When an error occurs, the compiler or runtime system directs you to the source of the error. Advantage of C C is more "popular" so more is available in the way of tools and support. Disadvantages of Ada95 Less popular than "C", so fewer tools are available. Disadvantages of C C is a "tricky" language. A significant number of programming errors are not detected by the compiler or at runtime and result in programs that are unreliable. When an error occurs that causes a program to crash, it may be very expensive to track down the source of the error. My observations. I've used both. SteveD the middleman <charles.dand@yukyonline.co.yuky> wrote in message news:37EED7B8.245C0054@yukyonline.co.yuky... > I've been learning Ada95 for a year now. And although I don't have much > experience of other languages I'd certainly say it was my favourite. > In discussions with friends the abilities of Ada95 have cropped up. I > was wondering if anyone could possibly point out the weaknesses and the > strengths that Ada95 has when compared to other languages such as C so > that I can finally set the record straight. > > Any comment would be appreciated. > > Thanx. > -- > ByeZeeBye > the middleman > Chuck(les) ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman 1999-09-27 0:00 ` Steve Doiel @ 1999-09-27 0:00 ` J. David Bryan 1999-09-27 0:00 ` Marin David Condic ` (3 subsequent siblings) 5 siblings, 0 replies; 87+ messages in thread From: J. David Bryan @ 1999-09-27 0:00 UTC (permalink / raw) On Mon, 27 Sep 1999 03:34:32 +0100 in article <37EED7B8.245C0054@yukyonline.co.yuky>, charles.dand@yukyonline.co.yuky wrote... > >I was wondering if anyone could possibly point out the weaknesses and the >strengths that Ada95 has when compared to other languages such as C so >that I can finally set the record straight. See the "Ada vs. C/C++" page at: http://www.adaic.org/intro/c.html -- -- Dave Bryan NOTE: Due to unrelenting SPAM, I regret that I have been forced to post with an encoded address. Please ROT13 this message to obtain the reply address. Address also available at http://www.bcpl.net/~dbryan/mailto.html Cyrnfr ercyl gb guvf nqqerff: wqoelna@npz.bet ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman 1999-09-27 0:00 ` Steve Doiel 1999-09-27 0:00 ` J. David Bryan @ 1999-09-27 0:00 ` Marin David Condic 1999-09-27 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Preben Randhol 1999-09-27 0:00 ` David Starner ` (2 subsequent siblings) 5 siblings, 2 replies; 87+ messages in thread From: Marin David Condic @ 1999-09-27 0:00 UTC (permalink / raw) the middleman wrote: > I've been learning Ada95 for a year now. And although I don't have much > experience of other languages I'd certainly say it was my favourite. > In discussions with friends the abilities of Ada95 have cropped up. I > was wondering if anyone could possibly point out the weaknesses and the > strengths that Ada95 has when compared to other languages such as C so > that I can finally set the record straight. I'm sure there will be lots of comments with lists of Ada benefits over C. The only real benefit C has over Ada is that it is more popular and as a result you can find more tools & libraries in C. Other than popularity, there isn't anything that C does which Ada cannot do in (usually) a more safe, reliable, portable way. C is also a more terse and cryptic language which is something lots of programmers seem to like. They will describe it as "concise" and think of Ada as verbose. I don't consider this aspect of C to be an advantage - unless you've already worked the crossword puzzle, the word jumble puzzle and the crypto-puzzle in today's paper and still have not had your fill of puzzle solving ;-) On my web page (see trailer) I have started a page which compares Ada and C++ code examples to illustrate how different OODesign features are implemented in both languages. It isn't too far along just yet, but I anticipate it growing over the next several weeks. You may find it interesting to look at this comparison. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` Marin David Condic @ 1999-09-27 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Preben Randhol 1 sibling, 2 replies; 87+ messages in thread From: Hyman Rosen @ 1999-09-27 0:00 UTC (permalink / raw) Marin David Condic <condicma@bogon.pwfl.com> writes: > On my web page (see trailer) I have started a page which compares Ada and > C++ code examples to illustrate how different OODesign features are > implemented in both languages. It isn't too far along just yet, but I > anticipate it growing over the next several weeks. You may find it > interesting to look at this comparison. I found it very interesting. It crystalizes why so many people prefer to write in C++ rather than Ada! Aside from the verbosity of the Ada code (which is apparent even though the C++ equivalents aren't written idiomatically), notice that in the output code, it is necessary to repeat the types of the things being output, even though the ompiler already knows it! By the way, here's the C++ for your unimplemented third case - #include <iostream> #include <string> using namespace std; class SaveStuff { string name; int save; public: Save_Stuff(string n = string(), int s = 0) : name(n), save(s) { } void put(int x) { save = x; } int get() const { return save; } }; int main() { SaveStuff my_obj("My Object", 55); SaveStuff your_obj("Your Object", 55); my_obj.put(23); cout << "The value of my object is " << my_obj.get() << endl; your_obj.put(46); cout << "The value of your object is " << your_obj.get() << endl; } ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` Hyman Rosen @ 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Robert Dewar 1 sibling, 1 reply; 87+ messages in thread From: Ed Falis @ 1999-09-28 0:00 UTC (permalink / raw) On 27 Sep 1999 19:48:02 -0400, Hyman Rosen <hymie@prolifics.com> wrote: > Aside from the verbosity of the Ada code (which is apparent even though > the C++ equivalents aren't written idiomatically), notice that in the > output code, it is necessary to repeat the types of the things being > output, even though the ompiler already knows it! Not necessary. MDC is using a more verbose idiom than necessary to do the job. > > By the way, here's the C++ for your unimplemented third case - Not quite the same thing as he did. Below is Ada code that does what your C++ does. Let's not confuse style and substance (yes, it's still more verbose, partly because of multi-line routine definitions and your not using a header file). - Ed package Saver is type Save_Stuff (Name_Length: Natural) is private; function New_Save_Stuff (Str: String; Val: Integer) return Save_Stuff; procedure Put (S: in out Save_Stuff; X: Integer); function Get (S: Save_Stuff) return Integer; private type Save_Stuff (Name_Length: Natural) is record Name: String (1..Name_Length); Save: Integer; end record; end Saver; package body Saver is -- This is used because the C++ default access is private, right? function New_Save_Stuff (Str: String; Val: Integer) return Save_Stuff is begin return Save_Stuff'(Str'Length, Str, Val); end; procedure Put (S: in out Save_Stuff; X: Integer)is begin S.Save := X; end; function Get (S: Save_Stuff) return Integer is begin return S.Save; end; end Saver; with Saver; use Saver; with Ada.Text_Io, Ada.Integer_Text_Io; use Ada.Text_Io, Ada.Integer_Text_Io; procedure Main is My_Obj: Save_Stuff := New_Save_Stuff ("My Object", 55); Your_Obj: Save_Stuff := New_Save_Stuff ("Your Object", 55); begin Put (My_Obj, 23); Put ("The value of my object is "); Put (Get (My_Obj)); New_Line; Put (Your_Obj, 46); Put ("The value of your object is "); Put (Get (Your_Obj)); New_Line; end Main; > > #include <iostream> > #include <string> > > using namespace std; > > class SaveStuff > { > string name; > int save; > public: > Save_Stuff(string n = string(), int s = 0) : name(n), save(s) { } > void put(int x) { save = x; } > int get() const { return save; } > }; > > int main() > { > SaveStuff my_obj("My Object", 55); > SaveStuff your_obj("Your Object", 55); > > my_obj.put(23); > cout << "The value of my object is " << my_obj.get() << endl; > > your_obj.put(46); > cout << "The value of your object is " << your_obj.get() << endl; > } > > ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Ed Falis @ 1999-09-28 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Ed Falis 0 siblings, 1 reply; 87+ messages in thread From: Hyman Rosen @ 1999-09-28 0:00 UTC (permalink / raw) falis@ma.aonix.com (Ed Falis) writes: > On 27 Sep 1999 19:48:02 -0400, Hyman Rosen <hymie@prolifics.com> wrote: > > By the way, here's the C++ for your unimplemented third case - > Not quite the same thing as he did. Below is Ada code that does what > your C++ does. In what way (aside from from function announcement output) is my C++ code not the same as his Ada code? ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Hyman Rosen @ 1999-09-28 0:00 ` Ed Falis 0 siblings, 0 replies; 87+ messages in thread From: Ed Falis @ 1999-09-28 0:00 UTC (permalink / raw) On 28 Sep 1999 14:45:44 -0400, Hyman Rosen <hymie@prolifics.com> wrote: > falis@ma.aonix.com (Ed Falis) writes: > > On 27 Sep 1999 19:48:02 -0400, Hyman Rosen <hymie@prolifics.com> wrote: > > > By the way, here's the C++ for your unimplemented third case - > > Not quite the same thing as he did. Below is Ada code that does what > > your C++ does. > > In what way (aside from from function announcement output) > is my C++ code not the same as his Ada code? The destructor. Given what your code did, there was no need for all the infrastructure he put in place. There was certainly no need for adjust or finalize, and the effect of initialize was easily handled without deriving from controlled. Furthermore, since none of the C++ members were virtual, there was no need for a tagged type in this situation. He was, I believe, presenting a scaffolding for more situations where more complex resource management was necessary. It certainly wasn't in this situation. And as you can see, the verboseness was more a matter of idiom than necessity. - Ed ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Ed Falis @ 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Preben Randhol 1 sibling, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <t7vh8vx6fh.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> wrote: > Aside from the verbosity of the Ada code (which is apparent even though > the C++ equivalents aren't written idiomatically) verbosity is not necessarily a bad thing if it makes the code easier to read. , notice that in the > output code, it is necessary to repeat the types of the things being > output, even though the ompiler already knows it! Again, not necessarily a bad thing if it makes the code easier to read. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` Preben Randhol 1999-09-28 0:00 ` bill 0 siblings, 1 reply; 87+ messages in thread From: Preben Randhol @ 1999-09-28 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: | Again, not necessarily a bad thing if it makes the code | easier to read. True. Most bugs are discovered _reading_ through the source code rather than just testing the software. If one can read the code like a "book" it should be far easier to spot bugs than a language that has intricate syntactic rules. One language that is hard to read is Perl IMHO. C++ isn't easy either. One of the specification of the Ada language was that it should be easy to read (if I am not very mistaken). -- Preben Randhol [randhol@pvv.org] [http://www.pvv.org/~randhol/] "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" -- unknown ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Preben Randhol @ 1999-09-28 0:00 ` bill 1999-09-27 0:00 ` Aidan Skinner ` (3 more replies) 0 siblings, 4 replies; 87+ messages in thread From: bill @ 1999-09-28 0:00 UTC (permalink / raw) In article <m3ogenur2s.fsf@kiuk0156.chembio.ntnu.no>, Preben says... >True. Most bugs are discovered _reading_ through the source code >rather than just testing the software. programmers reading the code?? This is a new one. seriously, one of the biggest problems I see is that many programmers do NOT read the code. They try something, it failes, jump into the debugger, set up a test, buy new hardware, hire more testers, run a profiler, etc.. they do all that, except actualy EXAMINE the code ! How often do you see a programmer make a printout of their code, and go ask another programmer to code review the code with them? How often do you a programmer print their own code and look at it? I mean really look at it? Bill ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` bill @ 1999-09-27 0:00 ` Aidan Skinner 1999-09-28 0:00 ` Preben Randhol ` (2 subsequent siblings) 3 siblings, 0 replies; 87+ messages in thread From: Aidan Skinner @ 1999-09-27 0:00 UTC (permalink / raw) On 28 Sep 1999 08:24:54 -0700, bill@yy <bill@yy> wrote: >programmers do NOT read the code. They try something, it failes, jump >into the debugger, set up a test, buy new hardware, hire more testers, >run a profiler, etc.. they do all that, except actualy EXAMINE the code ! When I write code, I tend to try and break things up into smallest-possible steps, and use nested procedures with sensible names to describe what I want to do. I do this because then I can look at the lowest level of code and say "Yes, this is obviously correct" and then go one step up and do the same. I then write a test program, and then run that inside a debugger to make sure that everything is correct. >do you a programmer print their own code and look at it? I mean really I never print out my code. I very rarely print out *anything*. I much prefer looking at stuff on a monitor. But I'm weird like that. - Aidan -- "Every time I see her I want to geek..." "I say geek. If she runs then it was never meant to be. But if you talk about routers, TCP/IP and programming and she stays, she's yours until the counter flips" ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` bill 1999-09-27 0:00 ` Aidan Skinner @ 1999-09-28 0:00 ` Preben Randhol 1999-09-28 0:00 ` Larry Kilgallen 1999-09-28 0:00 ` Steve Doiel 3 siblings, 0 replies; 87+ messages in thread From: Preben Randhol @ 1999-09-28 0:00 UTC (permalink / raw) bill@yy writes: | seriously, one of the biggest problems I see is that many | programmers do NOT read the code. They try something, it failes, jump | into the debugger, set up a test, buy new hardware, hire more testers, | run a profiler, etc.. they do all that, except actualy EXAMINE the code ! If you look at serious corporations were the safety of the code is crucial (or at least have priority) you will find this proof reading. If you however look at corporations like Microsoft etc... it is doubtfully that they do. | How often do you see a programmer make a printout of their code, and | go ask another programmer to code review the code with them? How often | do you a programmer print their own code and look at it? I mean really | look at it? After starting to read my own code, I was amazed of how many bugs you can spot. I think somewhere between 60 to 80% would be a fair estimate*, at least that is my experience. * This is however depended on that the language _is_ "readable" -- Preben Randhol [randhol@pvv.org] [http://www.pvv.org/~randhol/] "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" -- unknown ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` bill 1999-09-27 0:00 ` Aidan Skinner 1999-09-28 0:00 ` Preben Randhol @ 1999-09-28 0:00 ` Larry Kilgallen 1999-09-28 0:00 ` Steve Doiel 3 siblings, 0 replies; 87+ messages in thread From: Larry Kilgallen @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sqmk6$1ck3@drn.newsguy.com>, bill@yy writes: > How often do you see a programmer make a printout of their code, and > go ask another programmer to code review the code with them? How often > do you a programmer print their own code and look at it? I mean really > look at it? Whether printed paper is the medium is an issue of local fashion, but many serious projects require another individual to sign off before code is checked in. Really serious projects do formal inspection with a team rather than a single individual reviewing the code. Larry Kilgallen ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` bill ` (2 preceding siblings ...) 1999-09-28 0:00 ` Larry Kilgallen @ 1999-09-28 0:00 ` Steve Doiel 3 siblings, 0 replies; 87+ messages in thread From: Steve Doiel @ 1999-09-28 0:00 UTC (permalink / raw) <bill@yy> wrote in message news:7sqmk6$1ck3@drn.newsguy.com... > In article <m3ogenur2s.fsf@kiuk0156.chembio.ntnu.no>, Preben says... > > >True. Most bugs are discovered _reading_ through the source code > >rather than just testing the software. > > programmers reading the code?? This is a new one. > > seriously, one of the biggest problems I see is that many > programmers do NOT read the code. They try something, it failes, jump > into the debugger, set up a test, buy new hardware, hire more testers, > run a profiler, etc.. they do all that, except actualy EXAMINE the code ! Actually I frequently print out and exammine source code. Although I can see your point. When I learned FORTRAN we used keypunch machines and punch cards. After putting together our deck we submitted our programs for a batch run. This run might not be complete as long as 3 hours. Sometimes I still amaze myself at my ability to distinguish a zero from an "O" when reviewing code. Along the same lines this is one of the reasons I prefer Ada. Just today one of my co-workers was struggling with a bug in a C program and asked for my assistance. His program was transferring data from one array to another: unsigned int idx; for( idx = beg; idx <= end; idx++ ) { dest[ j++ ] := src[ idx ]; } He needed to change the loop to store the data in the opposite order, so he changed the code to read: unsigned int idx; for( idx =end; idx >= beg; idx-- ) { dest[ j++ ] := src[ idx ]; } And then spent a few hours trying to figure out why the program "locked up". In case you missed it, when beg = 0, "idx >= beg" is always true for an unsigned integer (idx) so he had an infinite loop. Programmers are mortal. Had this program been written in Ada he could have spent these hours doing something productive. for idx in reverse beg .. endIdx loop dest( j ) := src( idx ); j := j + 1; end loop; BTW: There are loads of other tricky examples like this one. This is just one example of what I consider to be a strength of Ada when compared with C. SteveD ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` Marin David Condic 1999-09-27 0:00 ` Hyman Rosen @ 1999-09-28 0:00 ` Preben Randhol 1 sibling, 0 replies; 87+ messages in thread From: Preben Randhol @ 1999-09-28 0:00 UTC (permalink / raw) Marin David Condic <condicma@bogon.pwfl.com> writes: | I'm sure there will be lots of comments with lists of Ada benefits over C. | The only real benefit C has over Ada is that it is more popular and as a | result you can find more tools & libraries in C. Other than popularity, I wouldn't overstress this angle. A parallell example could be Windows vs. Linux. -- Preben Randhol [randhol@pvv.org] [http://www.pvv.org/~randhol/] "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" -- unknown ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman ` (2 preceding siblings ...) 1999-09-27 0:00 ` Marin David Condic @ 1999-09-27 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar ` (2 more replies) 1999-09-28 0:00 ` Geoff Bull 1999-09-28 0:00 ` Geoff Bull 5 siblings, 3 replies; 87+ messages in thread From: David Starner @ 1999-09-27 0:00 UTC (permalink / raw) In article <37EED7B8.245C0054@yukyonline.co.yuky>, the middleman wrote: >I've been learning Ada95 for a year now. And although I don't have much >experience of other languages I'd certainly say it was my favourite. >In discussions with friends the abilities of Ada95 have cropped up. I >was wondering if anyone could possibly point out the weaknesses and the >strengths that Ada95 has when compared to other languages such as C so >that I can finally set the record straight. Needless to say, it's very arguable. Here's my comparison vs. C & C++. Advantages vs. C++ * Better modularity support * Not locked into class=type pardigm * Built in tasking support * Strong typing for real * Large choice and fine control over types. (C & C++ offer at best a clumsy mechanism to chose one of the standard types.) * The libraries were written with module, exception and template support in mind (as opposed to C++ where many libraries were written before standard implementations of those were common, or for compilers that don't support them.) * Almost all Ada compilers are standard compliant (whereas few C++ compilers are totally standard compliant, and many lack major features (namespaces, templates). (Note that most C compilers _are_ ISO C compliant, one of the few advantages of C over C++). * Elegance. Ada is designed by a small team with a strong leader, and was updated from 83 to 95 by another small team with a strong leader. OTOH, C & C++ were grown languages, with gangly and arbitrary cruft everywhere, with C++ especially being designed by commitee. Additional Advantages vs. C * Any real modularity support * Object orientation, and the other aminaties of a modern language (exceptions, templates, etc) * Some saftey net against bugs (C compilers by default will let extremely questionable & machine depended code by.) Disadvatages vs. C++ * Type safety makes it harder for some stuff to get done - i.e. it's impossible to make a type look exactly like a number in Ada, but trivial in C++. * C++ includes several somewhat experimental features (template specilization, multiple inheritance) that Ada designers considered too experimental or specialized to add. Disadvantages vs. C & C++ * Large base of installed libraries. If you can find a Ada library that does what you need to do (not unlikely, but not as likely as for C or C++ - and it's probably a wrapper around a C library), it probably won't come precompiled and set up for your system, and it probably won't be installed on your user's system. * C compilers have a standardized interface. OTOH, you can distinuigsh Ada compilers by the required file names, and the interface is more variant. * C & C++ compilers will usually produce smaller and faster code, albeit usually less than an order of magnitude. David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` David Starner @ 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner ` (2 more replies) 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses the middleman 1999-09-28 0:00 ` Robert Dewar 2 siblings, 3 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7smp30$9aa1@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > * C compilers have a standardized interface. OTOH, you can > distinuigsh Ada compilers by the required file names Are there really Ada compilers that have "required file names"? Certainly GNAT does not have required file names. In fact, unlike the case in C, there is in GNAT a default file naming convention that means that, when you reference a spec, you can do it just using the unit name (unlike the case in C, where you have to mention the actual file name of a header file, which is unpleasant, since it means that when file names change from one system to another, you have to modify the sources). If you don't think this is a problem, you should have to deal with the 8+3 limitations in early DOS C compilers, a *real* pain!!!! If you are using your own file names, that do not correspond to the GNAT defaults, then you have to specify the file names, but this is done in a separate file, not in the source files themselves. So this to me is one place that Ada clearly wins over C, rather than loses. > * C & C++ compilers will usually produce smaller and faster > code, albeit usually less than an order of magnitude. Well an order of magnitude would be a catastrophe, but in fact the statement is just false. If your Ada compiler produces junk code, get another one. In the case of GNAT, the compiler uses exactly the same code generator as the GNU C compiler or the G++ compiler, so for comparable source code, you get identical object code. Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Gautier ` (4 more replies) 1999-09-28 0:00 ` Code size of Ada ? was " Alfred Hilscher 1999-09-28 0:00 ` GNAT listing file default names (was: Ada95 Strengths/Weaknesses) Larry Kilgallen 2 siblings, 5 replies; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sp8m9$a6e$1@nnrp1.deja.com>, Robert Dewar wrote: >In article <7smp30$9aa1@news.cis.okstate.edu>, > dstarner98@aasaa.ofe.org wrote: > >> * C compilers have a standardized interface. OTOH, you can >> distinuigsh Ada compilers by the required file names > >Are there really Ada compilers that have "required file names"? >Certainly GNAT does not have required file names. It cetianly has preferred file names, which are different from the preferred names of other compilers. >So this to me is one place that Ada clearly wins over C, rather >than loses. I guess I wasn't very clear. For most C compilers, I can say cc -o joebob joebob.c and it will work. This isn't true for Ada. There is no standaradized interface, and there's not even standard file names. >> * C & C++ compilers will usually produce smaller and faster >> code, albeit usually less than an order of magnitude. > >Well an order of magnitude would be a catastrophe, but in fact >the statement is just false. If your Ada compiler produces >junk code, get another one. In the case of GNAT, the compiler >uses exactly the same code generator as the GNU C compiler or >the G++ compiler, so for comparable source code, you get >identical object code. Check. I just recently hand converted a small game from C++ to Ada using G++ and GNAT respectively. The only changes besides that were going from 0 based indexing to 1 based, and dropping some debug code in the process. g++ *.cpp -o Alexis produces a binary with a size of 15,796 bytes. gnatmake alexis-char produces a binary with a size of 735,962 bytes. Some tweaks later (dynamic linking, no runtime checks, striping the files) produces a C++ binary of 12,568 bytes and an Ada binary of 51,124 bytes. Stripping out the random number library I had used from Mat Weber's Components (which cripples the program, but to be fair Mat Weber says it's redundant with Ada95, so I could probably remove it if I knew how) brings us down to 32,196, over twice the size of the original. So, since GNAT is junk, do you have another Ada compiler to recommend? David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner @ 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` p.obry ` (3 subsequent siblings) 4 siblings, 2 replies; 87+ messages in thread From: Gautier @ 1999-09-28 0:00 UTC (permalink / raw) > (...) over twice the size of the original. > So, since GNAT is junk, do you have another Ada compiler to recommend? GNAT is not junk, since the relation between source code & .exe size is never linear (in any language)! I reproduce a reply to a similar question: << The .exe size will be (roughly said...) AX+B, where X is the amount of instructions of _your_ program. AX is the object compiled code size. Dr Dewar just told that since the A does not depend on the front end (Ada, C, Pascal, Modula...) in the GCC system, AX will be the same in the different languages - provided that your source codes is the tightly equivalent! The B is the default library code that comes at linking and that one is bigger in Ada (richer conversions, exception handling, tasking, elaboration, ...?), so your .exe can be bigger. But B is a ``fixed cost''. >> In addition, a nice feature of GNAT is to allow cross-unit inlining (using the standard Ada features, modularity+inline pragma), so you can (but aren't obliged to) obtain object code that is bigger (bigger A) but also faster than with old languages where source codes don't know of each other... -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Gautier @ 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1 sibling, 2 replies; 87+ messages in thread From: Ed Falis @ 1999-09-28 0:00 UTC (permalink / raw) > > (...) over twice the size of the original. > I suppose there's one additional comment to make regarding the handling of the runtime library - the use of DLL's. It wasn't clear whether there were parts of the RTL of the other languages in DLL's. It's also possible to put the Ada RTL into a DLL (not sure about GNAT in this regard). - Ed ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Ed Falis @ 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1 sibling, 0 replies; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <1103_938536221@DZOG-CHEN>, Ed Falis wrote: >> > (...) over twice the size of the original. >> > >I suppose there's one additional comment to make regarding >the handling of the runtime library - the use of DLL's. It wasn't >clear whether there were parts of the RTL of the other >languages in DLL's. It's also possible to put the Ada RTL >into a DLL (not sure about GNAT in this regard). > >- Ed GNAT normally statically links to the RTL, a large part of the reason my first attempt produced such a large binary. But the Ada for Linux team has patches to let you dynamically link against GNAT's RTL, and the final result was dynamically linked (for both C++ and Ada). David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` David Starner @ 1999-09-29 0:00 ` Robert Dewar 1 sibling, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <1103_938536221@DZOG-CHEN>, falis@ma.aonix.com (Ed Falis) wrote: > > > (...) over twice the size of the original. > > > > I suppose there's one additional comment to make regarding > the handling of the runtime library - the use of DLL's. It wasn't > clear whether there were parts of the RTL of the other > languages in DLL's. It's also possible to put the Ada RTL > into a DLL (not sure about GNAT in this regard). Yes, indeed the runtime can be placed in a DLL, this makes executables smaller, at the expense of slight runtime inefficiency. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` Ed Falis @ 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1 sibling, 1 reply; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <37F0E771.7E394DE4@maths.unine.ch>, Gautier wrote: >> (...) over twice the size of the original. > >> So, since GNAT is junk, do you have another Ada compiler to recommend? This statement is out of context. > >GNAT is not junk, since the relation between source code & .exe size >is never linear (in any language)! > Dewar >> Starner >> * C & C++ compilers will usually produce smaller and faster >> code, albeit usually less than an order of magnitude. > >Well an order of magnitude would be a catastrophe, but in fact >the statement is just false. If your Ada compiler produces >junk code, get another one. In the case of GNAT, the compiler >uses exactly the same code generator as the GNU C compiler or >the G++ compiler, so for comparable source code, you get >identical object code. He basically said that if the Ada compiler did not produce code as small as the C++ compiler, then it was junk, and that GNAT in particular would produce the same code ("identical object code") as G++. I was merely calling him on that. David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner @ 1999-09-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <7sqq0h$8q61@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > He basically said that if the Ada compiler did not produce code > as small as the C++ compiler, then it was junk, and that GNAT > in particular would produce the same code ("identical object > code") as G++. I will repeat it, if you write identical corresponding source code in Ada and C++ you will get identical object code. But you need to know a LOT about both languages to write identical code. Almost always comparisons are flawed because of casual assumptions that things that are superficially similar are the same. For example, computing a sqrt in C++ is not the same as computing a sqrt in Ada, because in the latter case but not the former case there are rules about precision, handling of minus zeroes etc, which are just ignored in the former case. << I was merely calling him on that.>> But I am not sure you understood what I wrote, your posts so far indicate otherwise. For example, you apparently in your first attempt used different random number generators. That of course renders the comparison completely useless, since now you are simply measuring the size/performance of two random number generators, and that has nothing whatsoever to do with a language comparison. In fact the comparison you are attempting to do is extremely difficult and requires, as I note, a very extensive knowledge of the two languages. Now of course people writing casually without this knowledge will see varied results, and they may see one thing or they may see another, depending on somewhat arbitrary decisions they have made. If you like post just an excerpt from your program, e.g. one procedure written in Ada vs one function written in C++, and it may be illuminating. If the object code is not the same, then they clearly are not identical in the sense I am talking about above, so it may be instructive to explain WHY they are not identical Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Gautier @ 1999-09-28 0:00 ` p.obry 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar ` (2 subsequent siblings) 4 siblings, 1 reply; 87+ messages in thread From: p.obry @ 1999-09-28 0:00 UTC (permalink / raw) << So, since GNAT is junk, do you have another Ada compiler to recommend? >> Well with comments like that we are going to have a really big thread !!! And I find that comparing languages from the generated code size very strange, but you certainly have good reasons :-) Pascal. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` p.obry @ 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Richard D Riehle 0 siblings, 1 reply; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sqbfv$1tr$1@clnews.edf.fr>, p.obry@der.edf.fr wrote: ><< >So, since GNAT is junk, do you have another Ada compiler to recommend? >>> > >Well with comments like that we are going to have a really big thread !!! I'm sorry. It was getting late at night, and someone I thought was reasonable was "proving" that his language was perfect by tearing down my posts. And then he says that any compiler that doesn't produce code about the size of C++ is junk, and I knew that his compiler did that from a project I was working on recently. >And I find that comparing languages from the generated code size very >strange, but you certainly have good reasons :-) It's not a big thing. Occasionally you have to fit a program in a small space, like on a boot floppy. And it doesn't look good to have a small game - which could probably fit in under 4k with a brilliant enough programmer - to be 3/4 of a megabyte. David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner @ 1999-09-28 0:00 ` Richard D Riehle 0 siblings, 0 replies; 87+ messages in thread From: Richard D Riehle @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sqi8p$7pu1@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: >It's not a big thing. Occasionally you have to fit a program in a small >space, like on a boot floppy. And it doesn't look good to have a small >game - which could probably fit in under 4k with a brilliant enough programmer >- to be 3/4 of a megabyte. 1) Ada is not at its best when designing code for little programs. It is definitely advantageous when creating large-scale software that involves a team of programmers. C++, used correctly, also fits into that category. 2) Most Ada compilers create a program that includes a set of instructions that act as a "run time environment." The RTE supports a lot of execution time checking that is not typical of languages without an RTE. You can optimize away a lot of] this code. 3) GNAT has a version called GNORT which has no RTE. This will produce smaller code, but then you must include all the checking through selection operations within your code. Sometimes this is a good idea. Sometimes it is not. 4) Toy programs are never an acceptable medium for measuring or comparing programming languages or even development methods. If you decide to create a small program using object-oriented programming, I will build it just as fast and just as well using ad hoc methods. However, if we scale up the problem to a serious application, you will win in both understandability, maintainability, and completion of the job. I, however, will win the prize for consumption of over-the-counter anodyne products. Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` p.obry @ 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses Ted Dennison 4 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7spauv$a2g2@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > cc -o joebob joebob.c Right, and in Ada, e.g. using GNAT, you could say gcc -c -x ada joebob.c if you were in a sufficiently perverse mood ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner ` (2 preceding siblings ...) 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-30 0:00 ` Pragma (was Re: Ada95 Strengths/Weaknesses.) Preben Randhol 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses Ted Dennison 4 siblings, 2 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7spauv$a2g2@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > Check. I just recently hand converted a small game from C++ to Ada using > G++ and GNAT respectively. The only changes besides that were going from > 0 based indexing to 1 based, and dropping some debug code in the process. > g++ *.cpp -o Alexis produces a binary with a size of 15,796 bytes. gnatmake > alexis-char produces a binary with a size of 735,962 bytes. Obviously an apples-vs-oranges comparison >Some tweaks later > (dynamic linking, no runtime checks, striping the files) These are not tweaks, they are major changes! produces a C++ binary > of 12,568 bytes and an Ada binary of 51,124 bytes. Comparing the minimum sizes of trivial programs is not a terribly interesting operation, since it has almost nothing to do with real programs, but in practice if you really want to do it carefully, you can get the identical Ada and C++ object files. Of course you have to use identical libraries, not just corresponding ones, because the libraries in C++ and Ada definitely do not correspond. If you really want to waste more time tweaking, you might want to try pragma No_Run_Time and eliminate the GNAT runtime. But almost certainly you are still comparing apples and oranges, and the comparison is not particularly interesting. Stripping out the random > number library I had used from Mat Weber's Components (which cripples the > program, wait a moment, I thought you said the two programs were the same. Surely the C++ program did not use Mat Weber's component? You really have to compare identical things here. For example, the requirements on the random number generator in Ada are quite ferocious, much more so than in the case of C++. You need to use identical library routines to do a size comparison like this. > but to be fair Mat Weber says it's redundant with > Ada95, so I could > probably remove it if I knew how) brings us down to 32,196, over twice the > size of the original. But almost certainly it is not comparable to the original. If you like post the two pieces of code you compared. Quite often such postings reveal huge misconceptions in what is and is not comparable between the two languages. > So, since GNAT is junk, do you have another Ada compiler to > recommend? I don't think you need a new Ada compiler, I think you need more understanding about how to do a comparison like this in a meaningful manner. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1999-09-30 0:00 ` Pragma (was Re: Ada95 Strengths/Weaknesses.) Preben Randhol 1 sibling, 1 reply; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sr7a4$nc4$1@nnrp1.deja.com>, Robert Dewar wrote: >In article <7spauv$a2g2@news.cis.okstate.edu>, > dstarner98@aasaa.ofe.org wrote: >> Check. I just recently hand converted a small game from C++ to >Ada using >> G++ and GNAT respectively. The only changes besides that were >going from >> 0 based indexing to 1 based, and dropping some debug code in >the process. >> g++ *.cpp -o Alexis produces a binary with a size of 15,796 >bytes. gnatmake >> alexis-char produces a binary with a size of 735,962 bytes. > >Obviously an apples-vs-oranges comparison In some ways, yes, but it's a direct comparison of the most straightforward - the default - way of compiling. >produces a C++ binary >> of 12,568 bytes and an Ada binary of 51,124 bytes. > >Comparing the minimum sizes of trivial programs is not a >terribly interesting operation, since it has almost nothing >to do with real programs, One thing professionals seem to forget is that there are a whole lot more amateurs out there then there are professionals, and what the amateurs do is just as real as what the professionals do. Also, I may point that /bin holds 20 programs of this size (12K or less). They come very useful at times, and I wouldn't denigrate them as fake. >Of course you have to use identical libraries, >not just corresponding ones, because the libraries in C++ >and Ada definitely do not correspond. > >If you really want to waste more time tweaking, you might >want to try pragma No_Run_Time and eliminate the GNAT runtime. > >But almost certainly you are still comparing apples and oranges, >and the comparison is not particularly interesting. I don't know what you're comparing. I'm comparing the size of programs when I straightforwardly write it in language A and language B. >But almost certainly it is not comparable to the original. If >you like post the two pieces of code you compared. Quite often >such postings reveal huge misconceptions in what is and is not >comparable between the two languages. The programs are a little over 10K of source each. I don't feel that it would appropriate to post the whole thing to this newsgroup. ftp x8b4e53cd.dhcp.okstate.edu and get Alexis_Ada95.tgz & Alexis_C++.tar.gz if anyone really cares. >I don't think you need a new Ada compiler, I think you need more >understanding about how to do a comparison like this in a >meaningful manner. It was meaningful. Ringing the dinner bell and seeing how long it takes for the animals to show up may be awful if you want the theorical max speed of the animals (what you seem to be look for), but it's great if you want to see how long it take for the animals to show up when I ring the dinner bell (what I'm looking for.) David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner @ 1999-09-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <7srb3r$8a21@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > It was meaningful. No, sorry, from a technical point of view, the comparison was useless, since there are no valid conclusions that can be drawn from a comparison done in this way, other than program a is x long program b is y long Any attempt to generalize from this will be meaningless Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Pragma (was Re: Ada95 Strengths/Weaknesses.) 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner @ 1999-09-30 0:00 ` Preben Randhol 1999-09-30 0:00 ` Preben Randhol 1 sibling, 1 reply; 87+ messages in thread From: Preben Randhol @ 1999-09-30 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: | If you really want to waste more time tweaking, you might | want to try pragma No_Run_Time and eliminate the GNAT runtime. I get: hello.adb:3:01: warning: unrecognized pragma "No_Run_Time" -- Preben Randhol [randhol@pvv.org] [http://www.pvv.org/~randhol/] "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" -- unknown ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Pragma (was Re: Ada95 Strengths/Weaknesses.) 1999-09-30 0:00 ` Pragma (was Re: Ada95 Strengths/Weaknesses.) Preben Randhol @ 1999-09-30 0:00 ` Preben Randhol 0 siblings, 0 replies; 87+ messages in thread From: Preben Randhol @ 1999-09-30 0:00 UTC (permalink / raw) Preben Randhol <randhol@pvv.org> writes: | Robert Dewar <robert_dewar@my-deja.com> writes: | | | If you really want to waste more time tweaking, you might | | want to try pragma No_Run_Time and eliminate the GNAT runtime. | | I get: | | hello.adb:3:01: warning: unrecognized pragma "No_Run_Time" with gnat 3.11p -- Preben Randhol [randhol@pvv.org] [http://www.pvv.org/~randhol/] "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?" -- unknown ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner ` (3 preceding siblings ...) 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` Ted Dennison 1999-09-28 0:00 ` Simon Wright 4 siblings, 1 reply; 87+ messages in thread From: Ted Dennison @ 1999-09-28 0:00 UTC (permalink / raw) In article <7spauv$a2g2@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > I guess I wasn't very clear. For most C compilers, I can say > cc -o joebob joebob.c > and it will work. This isn't true for Ada. There is no standaradized > interface, and there's not even standard file names. actually, "cc -o whatever.fnord joebob.somethingotherthanc" will also work for most C compilers (assuming an OS that can handle that extension). And there is nothing other than convention that says that include files end in ".h". In fact, vxWorks merrily includes ".c" files in some of its supplied source code. I've seen other systems use other extensions (or none at all). Yuk. Also, once you take the time to learn the interface, every Ada compiler has a way to rebuild the entire system from sources in one command without having to manually track down the dependencies. Anyone who has ever tried to build a large "portable" C system can tell you that Ada has it all over C in this respect. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses Ted Dennison @ 1999-09-28 0:00 ` Simon Wright 0 siblings, 0 replies; 87+ messages in thread From: Simon Wright @ 1999-09-28 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > Also, once you take the time to learn the interface, every Ada compiler > has a way to rebuild the entire system from sources in one command > without having to manually track down the dependencies. Anyone who has > ever tried to build a large "portable" C system can tell you that Ada > has it all over C in this respect. True, I suppose, if you have just standard C or Ada, possibly in multiple directories. But as soon as you need OS dependencies (where are the Motif libraries? do you even _have_Motif libraries? etc ..) the language differences pale, in my experience (we use imake under these circumstances for a mixed Ada/C/C++ system). ^ permalink raw reply [flat|nested] 87+ messages in thread
* Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner @ 1999-09-28 0:00 ` Alfred Hilscher 1999-09-28 0:00 ` Gautier ` (2 more replies) 1999-09-28 0:00 ` GNAT listing file default names (was: Ada95 Strengths/Weaknesses) Larry Kilgallen 2 siblings, 3 replies; 87+ messages in thread From: Alfred Hilscher @ 1999-09-28 0:00 UTC (permalink / raw) Robert Dewar wrote: > > * C & C++ compilers will usually produce smaller and faster > > code, albeit usually less than an order of magnitude. > > Well an order of magnitude would be a catastrophe, but in fact > the statement is just false. If your Ada compiler produces > junk code, get another one. In the case of GNAT, the compiler > uses exactly the same code generator as the GNU C compiler or > the G++ compiler, so for comparable source code, you get > identical object code. > > Robert Dewar > > Sent via Deja.com http://www.deja.com/ > Before you buy. Ok, so can you please tell me what I'm doing wrong ? All my test (from a simple "Hello world" upto a TCP/IP program with tasks) generate much bigger exe-files (WIN/NT or OS/2) than the C, Pascal or Modula-2 compilers I've tried. I used the default settings. What switches are needed to generate the smallest possible code ? Regards, Alfred ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Code size of Ada ? was " Alfred Hilscher @ 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` David Botton 1999-09-29 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: Gautier @ 1999-09-28 0:00 UTC (permalink / raw) > Ok, so can you please tell me what I'm doing wrong ? All my test (from a > simple "Hello world" upto a TCP/IP program with tasks) generate much > bigger exe-files (WIN/NT or OS/2) than the C, Pascal or Modula-2 > compilers I've tried. I used the default settings. The .exe size will be (roughly said...) AX+B, where X is the amount of instructions of _your_ program. AX is the object compiled code size. Dr Dewar just told that since the A does not depend on the front end (Ada, C, Pascal, Modula...) in the GCC system, AX will be the same in the different languages - provided that your source codes is the tightly equivalent! The B is the default library code that comes at linking and that one is bigger in Ada (richer conversions, exception handling, tasking, elaboration, ...?), so your .exe can be bigger. But B is a ``fixed cost''. > What switches are > needed to generate the smallest possible code ? Generally pragma suppress_all plus optimizations. With GNAT: -gnatp -O2 or more... -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Code size of Ada ? was " Alfred Hilscher 1999-09-28 0:00 ` Gautier @ 1999-09-28 0:00 ` David Botton 1999-09-29 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: David Botton @ 1999-09-28 0:00 UTC (permalink / raw) try adding -largs -s David Botton Alfred Hilscher wrote in message <37F0D03C.DE4807D4@icn.siemens.de>... >Ok, so can you please tell me what I'm doing wrong ? All my test (from a >simple "Hello world" upto a TCP/IP program with tasks) generate much >bigger exe-files (WIN/NT or OS/2) than the C, Pascal or Modula-2 >compilers I've tried. I used the default settings. What switches are >needed to generate the smallest possible code ? > >Regards, >Alfred ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Code size of Ada ? was " Alfred Hilscher 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` David Botton @ 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Alfred Hilscher 2 siblings, 2 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <37F0D03C.DE4807D4@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > What switches are > needed to generate the smallest possible code ? > > Regards, > Alfred Well obviously you strip a module to reduce debug symbol size, and you go to dynamic linking of the GNAT library, but really the size of small programs is a rather insignificant issue these days when 100K of disk space costs 0.1 cents. The size of large programs is a concern, but measuring the size of hello world programs has nothing at all to do with the size of real programs, since what you are really concentrating on here is the default size of the minimal run-time library. This can be important in e.g. safety critical embedded applications, where the appropriate approach is to use the No_Run_Time facility of GNAT (GNORT) to eliminate the run time entirely. Note that the original note here worried about performance, which is of course a completely different issue, and it was really that issue which I was addressing, I simply can't get to excited about saving hundredths of cents worth of disk for the image of a hello world program :-) Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Robert Dewar @ 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Robert Dewar ` (2 more replies) 1999-09-29 0:00 ` Alfred Hilscher 1 sibling, 3 replies; 87+ messages in thread From: Larry Kilgallen @ 1999-09-29 0:00 UTC (permalink / raw) In article <7srnb9$2u3$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > The size of large programs is a concern, but measuring the > size of hello world programs has nothing at all to do with > the size of real programs, since what you are really > concentrating on here is the default size of the minimal > run-time library. > > This can be important in e.g. safety critical embedded > applications, where the appropriate approach is to use the > No_Run_Time facility of GNAT (GNORT) to eliminate the run > time entirely. > > Note that the original note here worried about performance, > which is of course a completely different issue, and it was > really that issue which I was addressing, I simply can't > get to excited about saving hundredths of cents worth of > disk for the image of a hello world program :-) Although many people have written small programs for test purposes, most of them run those programs in environments tuned for running much larger programs. In fact, if you run a trivial program on a capable operating system it will incur all sorts of overhead setting up for the possibility of multiple DLLs, etc. that are never needed for "Hello World". So a bare machine will indeed provide the most efficient environment for "Hello World", so long as your calculations value your own time as worth zero. For a truly efficient solution, use a pencil to write "Hello World" on a piece of paper and be done with it. Larry Kilgallen ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Larry Kilgallen @ 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Alfred Hilscher 2 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <1999Sep29.075617.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > For a truly efficient solution, use a pencil to write > "Hello World" on a piece of paper and be done with it. > > Larry Kilgallen I nominate this for most delightful post of the week :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Robert Dewar @ 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Alfred Hilscher 2 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <1999Sep29.075617.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > For a truly efficient solution, use a pencil to write > "Hello World" on a piece of paper and be done with it. > > Larry Kilgallen I nominate this for most delightful post of the week :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar @ 1999-09-29 0:00 ` Alfred Hilscher 1999-09-29 0:00 ` Ted Dennison ` (2 more replies) 2 siblings, 3 replies; 87+ messages in thread From: Alfred Hilscher @ 1999-09-29 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <7srnb9$2u3$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > > > The size of large programs is a concern, but measuring the > > size of hello world programs has nothing at all to do with > > the size of real programs, since what you are really > > concentrating on here is the default size of the minimal > > run-time library. > Although many people have written small programs for test > purposes, most of them run those programs in environments > tuned for running much larger programs. In fact, if you > run a trivial program on a capable operating system it will > incur all sorts of overhead setting up for the possibility > of multiple DLLs, etc. that are never needed for "Hello World". But - is it really necessary to include e.g. all tasking stuff in simple applications ? I for myself prefer tools that links only the really needed parts together. Fifteen years ago I already heared from Ada vendors that the code _must_ be bigger and slower because Ada is a powerful language. Maybe this is the reason why many people prefer "C". Regards, Alfred ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Alfred Hilscher @ 1999-09-29 0:00 ` Ted Dennison 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: Ted Dennison @ 1999-09-29 0:00 UTC (permalink / raw) In article <37F22BB1.F3524D60@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > needed parts together. Fifteen years ago I already heared from Ada > vendors that the code _must_ be bigger and slower because Ada is a > powerful language. Maybe this is the reason why many people prefer Bigger perhaps, but not slower. If you hear that from a vendor its just an excuse. Ada actually gives more information to the compiler than C and allows it to make more assumptions. There's no reason why an Ada compiler can't be made to produce *faster* code than a C compiler can. Of course in practice the difference is in the work put into the compiler's optimizer, not in language choice. Of course the user is not blameless in this either. If you don't routinely put constraint checks in your C code due to speed concerns, but don't bother to disable the constraint checks the Ada compiler automaticly gives you, then you have only youself to blame for the slowness that causes. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Alfred Hilscher 1999-09-29 0:00 ` Ted Dennison @ 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` Ed Falis 1999-09-30 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar 2 siblings, 2 replies; 87+ messages in thread From: Gautier @ 1999-09-29 0:00 UTC (permalink / raw) > But - is it really necessary to include e.g. all tasking stuff in simple > applications ? I share your point of view. Now the cost of hard disk space is low, but the single KB spared has important implications in terms of speed with cached memory processor. > I for myself prefer tools that links only the really > needed parts together. At least the Janus (RR Software) linkers do unused code trimming: it selects only used parts in each module. Note that this can be done only with strongly modular languages like Ada or Borland Pascals. A C linker will put together the entire object code files with needed and unneeded parts... Since GNAT uses a _C_ linker, this may be why your .exe is so big! [or aren't you using GNAT ?] But GNAT 3.11+ provides a source-level trimming tool (gnatelim)... Don't forget to strip the debug info, too. > Fifteen years ago I already heared from Ada > vendors that the code _must_ be bigger and slower because Ada is a > powerful language. Maybe this is the reason why many people prefer "C". Nowadays you can have powerful language _and_ speed (BTW for me speed is a necessary condition of computing power)... -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Gautier @ 1999-09-29 0:00 ` Ed Falis 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` tmoran 1999-09-30 0:00 ` Robert Dewar 1 sibling, 2 replies; 87+ messages in thread From: Ed Falis @ 1999-09-29 0:00 UTC (permalink / raw) On Wed, 29 Sep 1999 19:55:01 +0200, Gautier <Gautier.deMontmollin@Maths.UniNe.CH> wrote: > A C linker will put together the entire object code files with > needed and unneeded parts... > Since GNAT uses a _C_ linker, this may be why your .exe is so big! > [or aren't you using GNAT ?] I don't think this is a matter of using a "C" linker, but maybe one of using ld? On windows, both the Microsoft linker and the Phar Lap linker we use for embedded applications are smart enough to eliminate unreferenced code sections, for Ada or for other languages. This was nice, because we were able to jettison our own USE technology and create platform standard object modules there. - Ed Falis Aonix ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Ed Falis @ 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` tmoran 1 sibling, 0 replies; 87+ messages in thread From: Gautier @ 1999-09-29 0:00 UTC (permalink / raw) Ed Falis wrote: > I don't think this is a matter of using a "C" linker, but maybe one of > using ld? Rather... but ld, C, Unix... it's a little the same area (hum...) > On windows, both the Microsoft linker and the Phar Lap linker we > use for embedded applications are smart enough to eliminate > unreferenced code sections, for Ada or for other languages. Interesting! Do you know how it works ? By simulating execution and ``colouring'' used code ? Does it trim unused global variables or constants too ? Can it replace ld ? It would be interesting to know if such a low-level trimming is safe. E.g. can it detect tricky code address calculations (ASM/C-like) that would make an apparently unused code section used indeed ? -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Ed Falis 1999-09-29 0:00 ` Gautier @ 1999-09-29 0:00 ` tmoran 1 sibling, 0 replies; 87+ messages in thread From: tmoran @ 1999-09-29 0:00 UTC (permalink / raw) >On windows, both the Microsoft linker and the Phar Lap linker we >use for embedded applications are smart enough to eliminate >unreferenced code sections, for Ada or for other languages. Including tagged type primitive operations that will never be called? ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` Ed Falis @ 1999-09-30 0:00 ` Robert Dewar 1 sibling, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <37F25273.298DCBD6@Maths.UniNe.CH>, Gautier <Gautier.deMontmollin@Maths.UniNe.CH> wrote: > A C linker will put together the entire object code files with > needed and unneeded parts... No, this varies from system to system, a decent linker will remove unused control sections (for example this is done on AIX - IBM understands linkers ...) > Since GNAT uses a _C_ linker, this may be why your .exe is so > big! There is no such thing as a "C" linker, GNAT uses the system linker which may or may not have the capability of removing unused stuff. > But GNAT 3.11+ provides a source-level trimming tool (gnatelim)... Right, which trims in a system independent manner ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Alfred Hilscher 1999-09-29 0:00 ` Ted Dennison 1999-09-29 0:00 ` Gautier @ 1999-09-29 0:00 ` Robert Dewar 1999-09-30 0:00 ` Alfred Hilscher 2 siblings, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <37F22BB1.F3524D60@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > But - is it really necessary to include e.g. all tasking stuff in simple > applications ? No, of course not, and GNAT will certainly not include the tasking unless it is used. > I for myself prefer tools that links only the really > needed parts together. Of course, there are 500 units in the GNAT library, you get only the ones you want. There are however, some base units, e.g. basic exception handling, that are in all non-GNORT generated programs, because they are virtually always needed. > Fifteen years ago I already heared from Ada > vendors that the code _must_ be bigger and slower I can't imagine any Ada vendor saying that, it is nonsense. Also, let's be very careful not to obfuscate here, "bigger" and "slower" have nothing to do with one another. We have been exclusively talking about *size* of trivial programs here, absolutely no claim has substantiated about identical programs showing difference in speed performance! > because Ada is a > powerful language. Maybe this is the reason why many people > prefer "C". Well slower would be a concern, the fact that a hello world program uses 0.2 cents of disk space instead of 0.1 cents is a dubious concern. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Robert Dewar @ 1999-09-30 0:00 ` Alfred Hilscher 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar 0 siblings, 2 replies; 87+ messages in thread From: Alfred Hilscher @ 1999-09-30 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <37F22BB1.F3524D60@icn.siemens.de>, > Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > > Fifteen years ago I already heared from Ada > > vendors that the code _must_ be bigger and slower > > I can't imagine any Ada vendor saying that, it is nonsense. I know that this is nonsens (I worked in compiler development for about ten years). I think it a feeble excuse of some people to argue why their product is not as good as others. > Also, let's be very careful not to obfuscate here, "bigger" > and "slower" have nothing to do with one another. We have been I fully agree with you, nevertheeless I think that size is also a point for discussion. > exclusively talking about *size* of trivial programs here, > absolutely no claim has substantiated about identical programs > showing difference in speed performance! Once again, _I_ have never mentioned that I'm talking _only_ about trivial programs. Here my original text again: Ok, so can you please tell me what I'm doing wrong ? --> All my test (from a simple "Hello world" upto a TCP/IP program with tasks) >-- generate much bigger exe-files (WIN/NT or OS/2) than the C, Pascal or Modula-2 compilers I've tried. I used the default settings. What switches are needed to generate the smallest possible code ? > > because Ada is a > > powerful language. Maybe this is the reason why many people > > prefer "C". > > Well slower would be a concern, the fact that a hello world > program uses 0.2 cents of disk space instead of 0.1 cents > is a dubious concern. That the same argument I've got from M$. "If your system, fixpack, office... does not fitt on your disk - just buy a bigger one". Does that mean I should work harder to get more money for bigger disks, main memory, a faster processor ("oh, you still work with PII with 266 MHz, thats why Word need so much time to open your document"). because others do their work "quick and dirty" (sorry, I _don't_ think you do so). > Well slower would be a concern, the fact that a hello world What do you think about "Load time" ? Isn't it right that a smaller program is faster loaded than a bigger one ? Especially when loading is done via LAN. Regards, Alfred ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Alfred Hilscher @ 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar ` (2 more replies) 1999-09-30 0:00 ` Robert Dewar 1 sibling, 3 replies; 87+ messages in thread From: Gautier @ 1999-09-30 0:00 UTC (permalink / raw) > What do you think about "Load time" ? Isn't it right that a smaller > program > is faster loaded than a bigger one ? Especially when loading is done via > LAN. A remark, independent from the language/compiler/etc. question: For loading through a LAN you've better to compress the .exe's. Decompression is so fast that I compress even programs on HD. See e.g. http://www.nexus.hu/upx/ -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Gautier @ 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <37F358CF.F831AF@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote: > Decompression is so fast that I compress even programs on HD. As do tens of millions of Win 98 users quite routinely :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar @ 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <37F358CF.F831AF@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote: > Decompression is so fast that I compress even programs on HD. As do tens of millions of Win 98 users quite routinely :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar @ 1999-09-30 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <37F358CF.F831AF@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote: > Decompression is so fast that I compress even programs on HD. As do tens of millions of Win 98 users quite routinely :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Alfred Hilscher 1999-09-30 0:00 ` Gautier @ 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` tmoran 1999-09-30 0:00 ` Ehud Lamm 1 sibling, 2 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <37F349BB.B1F39ECF@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > Ok, so can you please tell me what I'm doing wrong ? --> All my test > (from a > simple "Hello world" upto a TCP/IP program with tasks) >-- generate much > bigger exe-files (WIN/NT or OS/2) than the C, Pascal or Modula-2 > compilers I've tried. Obviously a program using Ada tasks is in no way comparable to any C program. If you want to compare an Ada program to a C program using explicit thread calls, compare an Ada program using the same explicit thread calls, since Ada tasking semantics is at a totally different level. Once again, one has to see the exact code you are using. > I used the default settings. Well I trust for example that you made sure the executable was stripped, and of course you would have used -gnatp (since otherwise you are comparing run time checked code with code that is not run time checked). And of course you used -O2 since doing any kind of size or speed performance testing with the default -O0 is complete and utter nonsense. So if you are really saying that you used none of these switches, you are not even BEGINNING to do a sensible comparison. > What switches are > needed to generate the smallest possible code ? Well you probably want to kill inlining completely with -fno-inline for example, there are many switches for the compiler, you need to read the documentation thoroughly to answer a question like this. > > That the same argument I've got from M$. "If your system, fixpack, > office... does not fitt on your disk - just buy a bigger one". > Does that mean I should work harder to get more money for bigger > disks, main memory, a faster processor ("oh, you still work with PII > with 266 MHz, thats why Word need so much time to open your document"). You have a great tendency to obfuscate here by introducing completely irrelevant stuff and considering them together (just like you did with speed and space in your previous message). No one here is talking about main memory or a faster processor, so why did you introduce these red herrings. What we are talking about is that typically Ada programs have a slightly larger fixed overhead for the runtime, and that results in a trivial amount of extra disk usage (in the tenths of cents), for storing an Ada program. Since you can store hundreds of Ada programs in the space for a small video clip, this is really a non-issue. > What do you think about "Load time" ? Isn't it right that a smaller > program > is faster loaded than a bigger one ? Especially when loading is done via > LAN. First of all, I think that load time has nothing to do with the size of the executable file, or to be more accurate is not directly related to this size. Why not, because debugging information is not loaded unless you are debugging. Second, with todays disks, the small fixed overhead (20K or whatever) results in negligible differences in load time. Now if a comparable program of large size say took 4 megs instead of 2 megs, that would be a concern, but we have no data in this thread substantiating such a phenomenon, and all our experience, at least with GNAT, is that comparably written large programs are about the same size in Ada as in C. Seeing as there is a common code generator, it would be surprising if this were not the case. Now of course if you use high level constructs in Ada that have no analogy in C, you will pay a price. But that's always the case, programming at a higher semantic level almost always (not always, but almost) costs in space and time (if you don't like this, you can always write in machine language and save lots of time and space over high level languages like C :-) As I have noted before, doing meaningful comparisons between languages or compilers is not at all an easy task. The people doing it need to be thoroughly familiar with all the factors involved. If you are asking the question "what options do I use to get a minimum sized program", then you don't have the necessary knowledge to do the comparison. So, my first suggestion is thoroughly read BOTH the relevant Ada *and* C manuals (for all I know the C experiment is also fatally flawed -- certainly for instance using gcc with the default -O0 to compile C and reasoning about the result is nonsense). There are lots of fine points, for example, clearly if you are interested in space, you use -O2, *NOT* -O3. If you don't know why, go and look up what these switches do! This is not an easy area at all, and it is all too easy to do bogus experiments and be lead off in all sorts of invalid directions (we have had plenty of claims in the opposite direction, e.g. the absurd claim that it is impossible to write portable code in C ...) They are not helpful whichever bogus conclusion they lead to ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Robert Dewar @ 1999-09-30 0:00 ` tmoran 1999-09-30 0:00 ` Ehud Lamm 1 sibling, 0 replies; 87+ messages in thread From: tmoran @ 1999-09-30 0:00 UTC (permalink / raw) >like this, you can always write in machine language and save >lots of time and space over high level languages like C :-) A "Hello World" program written using Debug in a DOS window on W95 takes 20 bytes, 11 of which are "Hello World". ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` tmoran @ 1999-09-30 0:00 ` Ehud Lamm 1999-09-30 0:00 ` Robert Dewar 1 sibling, 1 reply; 87+ messages in thread From: Ehud Lamm @ 1999-09-30 0:00 UTC (permalink / raw) On Thu, 30 Sep 1999, Robert Dewar wrote: |Now of course if you use high level constructs in Ada that have |no analogy in C, you will pay a price. But that's always the |case, programming at a higher semantic level almost always |(not always, but almost) costs in space and time (if you don't |like this, you can always write in machine language and save |lots of time and space over high level languages like C :-) | I'd like to respond to this, even though it is a little off topic, even for this roving thread. I think the "almost always" claim is an overstatement - as I am sure Robert knows. Today's processors (esp. RISC, superscalar, bredictive brancing etc.) have many features that make writing good machine code for them quite hard. Good optimizing compilers, many times, outperform all but the most expert of programmers. Now surely, a programmer who fails to use the right compiler switches will also fail to produce good machine code by hand. Hand tuning machine code is hard. The abstraction mechanisms of HLL help you think more clearly about the actuall problem to be solved - getting to a better algorithm - and with the aid of a good compiler, tend to produce better results. (Not to mention all the other benefiets: less bugs, easier maint. etc.) In most cases I've seen sending someone to code in machine language (or let's be more realistic - Assembly language), won't bring faster programs - UNLESS that person has a verey good knowledge of how things really work in the first place. I had a student once, who always insisted on using shift (in his C code) instead of multiplication, when multiplying by two. I'll let you guess which C code produced faster object code, what optimization did (not to mention some funny run time checks I saw on one compiler...). The only way to convince him that (a) a negligable speed increase is not worth the obsufication and that (b) there isn't any speed increase anyway was to examine the assembly listing from the compiler. Alas a week later he had a new clever idea. I have a feeling he will never "get it." I wouldn't bet on Assembly, unless knowing the exact problem and programmer invovled. 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] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Ehud Lamm @ 1999-09-30 0:00 ` Robert Dewar [not found] ` <7t2e1l$lqt2@ftp.kvaerner.com> 0 siblings, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <Pine.A41.3.96-heb-2.07.990930154826.68392B-100000@pluto.mscc.hu ji.ac.il>, Ehud Lamm <mslamm@mscc.huji.ac.il> wrote: > On Thu, 30 Sep 1999, Robert Dewar wrote: > > |Now of course if you use high level constructs in Ada that have > |no analogy in C, you will pay a price. But that's always the > |case, programming at a higher semantic level almost always > |(not always, but almost) costs in space and time (if you don't > |like this, you can always write in machine language and save > |lots of time and space over high level languages like C :-) > | > > I'd like to respond to this, even though it is a little off topic, even > for this roving thread. I think the "almost always" claim is an > overstatement - as I am sure Robert knows. > Today's processors (esp. RISC, superscalar, bredictive brancing etc.) have > many features that make writing good machine code for them quite hard. First, we are a bit confusing two issues here. 1. The issue of high level semantic features (e.g. finalization, garbage collection, dynamic dispatching, slice assignments, etc) compared with writing low level equivalents but still at the C or low level Ada level. 2. The issue of machine language vs low level stuff, an issue which I am quite happy to comment on, but which has nothing at all to do with issue 1, which is what I *was* talking about. > Good optimizing compilers, many times, outperform all but the > most expert of programmers. People often say this, particularly those in the compiler field, but in my experience it is just plain wrong. There are many people who can write VERY tight assembly language which outperforms anything compilers can generate. The last time I was challenged on this, I gave as an example my program DASC for doing syntax checking on full Ada 83. This program is 12K bytes long and runs at several million lines a minute on a 25MHz 386 (I have no idea how fast it runs on a modern PC, I have not run it recently. Furthermore, the 12K is quite deceptive, since this program gives reasonable error messages, and half that space is used to hold error message text. A student of Paul Hilfinger's spent some time analyzing this program to find out why any reasonable attempt to duplicate its function in C was far bigger and far slower. The resulting paper was called "Galactic Optimization" as I remember, but I don't think it was ever published. Just today in my class on beginning 386 assembly language, we looked at code for a silly C function to add two integers. With perfectly straightforward assembler code we beat the best C compiler by a factor of 3. Why? Because the C compiler was crippled by adhering to an idiotic design for the calling sequence, whereas our assembler routine could use a sensible tailored calling sequence suitable for that particular procedure. I am certainly not advocating programming in assembly language. Far from it, in fact I think most people should not be allowed to attempt this under any circumstances given the junk I have seen. But this idea that optimizing compilers can do as well as competent assembler programmers, though a common one, is to me urban myth, not backed up by any careful studies. One often quoted figure is Bill Wolf's study showing that assembler was only 11% (or was it 7%) faster than Bliss. I asked him about this one day. Turns out what they did was take a program in Bliss, generate the assembler, and then ask a student to improve the assembler language. Hopeless methodology! One of the most striking things about writing in machine language is that the detailed low level instruction set design often dictates the data structures at a high level. An example: THe Alsys storage allocator for the x86 (I don't know if it is still in use for Object Ada or not) was written by me in x86 assembly language. The critical data structure was a word whose format was x yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy (where x was a bit showing if a block was in use, and yyyy was the length of the block in bytes divided by 2). This was chosen because a single shift instruction could a) double the value of yyyyy b) remove x from the word c) place x in a flag where it could easily be used Yes, it might be that a compiler with good local optimization (like gcc) could retrieve this kind of code if you specified the same data structure by elaborate pattern matching on a sequence of code saying something like siz = 2 * size_word.yyy; if size_word.x then ... but the point is that unless you are thinking at this ferocious low level, you would not come up with the data structure in the first place. In particular, I would choose a totally different data structure on the MIPS chip. > Now surely, a programmer who fails to use the right > compiler switches will also fail to produce good machine code by hand. > Hand tuning machine code is hard. The abstraction mechanisms of HLL help > you think more clearly about the actuall problem to be solved - getting to > a better algorithm Yes, of course, it is much harder work to use good algorithms in a lower level environment, and that is indeed an important effect, but for a competent assembler programmer this is not an issue, it just means you have to work harder. Certainly programming in assembly language is no excuse for using poor algorithms. - and with the aid of a good compiler, tend to produce > better results. Please justify this with actual data. > (Not to mention all the other benefiets: less bugs, easier maint. etc.) Yes, yes, yes, of course, no argument here. No one is arguing that things should be done at a lower level, not at all. I just take issue with the idea that we are not paying a price for it. Look we all know that programs these days are massively oversized. Remember the days when 10 people could share a 128K PDP-11 doing C compilations and edits under Unix, and get quite reasonable response time. Seems unthinkable now, right ... > In most cases I've seen sending someone to code in machine language (or > let's be more realistic - Assembly language) well of course from a programming point of view assembly language = machine language, no one programs in absolute, so when we talk about programming in machine language, we mean asm. , won't bring faster programs > - UNLESS that person has a verey good knowledge of how things really work in the first place. Of course you need to be a skilled assembly language programmer to take advantage. The above statement is a bit like saying that a Cessna pilot may not be able to make the New York to San Fran run any faster in an F15 unless he has a very good knowledge of how to fly an F15 ... > I had a student once, who always insisted on using shift (in his C code) > instead of multiplication, when multiplying by two. I'll let you guess > which C code produced faster object code I trust they were identical, or something is sadly wrong , what optimization did (not to > mention some funny run time checks I saw on one compiler...). Something must have been sadly wrong ... The only way > to convince him that (a) a negligable speed increase is not worth the > obsufication and that (b) there isn't any speed increase anyway was to > examine the assembly listing from the compiler. This really has nothing at all to do with the point I was making. > Alas a week later he had a new clever idea. > I have a feeling he will never "get it." You were really emphasizing the wrong thing to him. The issue is not whether or not it speeded things up, by far the more important point is that abstraction is more important than efficiency in almost all cases. > I wouldn't bet on Assembly, unless knowing the exact problem > and programmer invovled. I agree with the above statement. I still agree with it for any possible substitution of language, methodology, tools etc for the word Assembly in the above statement. It seems like your whole post was about assembler, but that makes it an odd non-sequitur, my post was nothing at all to do with the issue of high level languages vs assembly language. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
[parent not found: <7t2e1l$lqt2@ftp.kvaerner.com>]
[parent not found: <37F91D6E.58685CFE@mitre.org>]
[parent not found: <7tf7uo$h2b$1@nnrp1.deja.com>]
[parent not found: <37FBA978.A86762F1@mitre.org>]
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. [not found] ` <37FBA978.A86762F1@mitre.org> @ 1999-10-18 0:00 ` Robert Dewar 1999-10-19 0:00 ` Code size of Ada ? Robert I. Eachus 0 siblings, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-10-18 0:00 UTC (permalink / raw) In article <37FBA978.A86762F1@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > I think we are talking at cross-purposes here. On short sequences > both you and can generate the sequences we want in our minds, and > whether we write those fragments in assembly, or build them into the > compiler run-time libraries is immaterial. No, I was not talking about short sequences here. I have written many large programs in assembly in the past (probably I have written about half a million lines of delivered commercial assembly code). For an example of a fairly large program written in very aggressive assembly language throughout, about 20K SLOC, look at the 360 implemnetation of SPITBOL (note that is a COMPLETE, very fast SNOBOL-4 compiler which fits in about 80K bytes of code -- it compiles at many millions of lines a minute, using the TRT instruction extensively for lexical analysis). But I certainly do NOT recommend this style of programming, an ASM program of this size, written in this manner, is barely maintainable, and the number of people who can work with such programs is minimal. I think it is important to understand that using higher level languages does have a cost. The objective is to keep the cost at a reasonable level (many current Java implementations fail to meet this criterion). With current machines, we can afford to give up a small factor of inefficiency, but not a large factor :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? 1999-10-18 0:00 ` Robert Dewar @ 1999-10-19 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 87+ messages in thread From: Robert I. Eachus @ 1999-10-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > No, I was not talking about short sequences here. I have written > many large programs in assembly in the past (probably I have > written about half a million lines of delivered commercial > assembly code). For an example of a fairly large program > written in very aggressive assembly language throughout, about > 20K SLOC, look at the 360 implemnetation of SPITBOL (note that > is a COMPLETE, very fast SNOBOL-4 compiler which fits in about > 80K bytes of code -- it compiles at many millions of lines > a minute, using the TRT instruction extensively for lexical > analysis). > > But I certainly do NOT recommend this style of programming, > an ASM program of this size, written in this manner, is barely > maintainable, and the number of people who can work with such > programs is minimal. > > I think it is important to understand that using higher level > languages does have a cost. The objective is to keep the cost > at a reasonable level (many current Java implementations fail > to meet this criterion). With current machines, we can afford > to give up a small factor of inefficiency, but not a large > factor :-) I've written programs of that size in assembler as well, although the limiting factor used to be memory size. In fact I go back far enough that I started writing in machine code. I have a copy of the first assembler manual (GP--Generalized Programming--for the Univac I) in my attic, and it was a big step forward. My point was that programming that results in good generated code requires knowing exactly what constitutes good machine code, and that is a relatively rare skill these days. My style now, when I need this degree of efficiency is to write in a high level language and then fix any bogus code either in the compiler optimizer, by reorganizing the high-level code so that the compiler does find the correct idiom, or by writing some routines in assembler. For example, on one Ada 83 project, writing a seventeen instruction loop in a 25 KSLOC program as a code insert improved performance by 25%. Or for another example, in the random number generator I wrote, on most hardware computing U squared mod N, for U and N integer, can be done in two instructions (excluding moving the data into registers) even though the intermediate value is double word size. Writing this as a code insert can speed things up dramatically because a lot of the computational tricks used are no longer needed. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 87+ messages in thread
[parent not found: <7tf7uo <37FBA978.A86762F1@mitre.org>]
[parent not found: <5OkO3.2$1e.659@typhoon.nyu.edu>]
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. [not found] ` <5OkO3.2$1e.659@typhoon.nyu.edu> @ 1999-10-19 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 87+ messages in thread From: Robert I. Eachus @ 1999-10-19 0:00 UTC (permalink / raw) Richard Kenner wrote: > You seem to be characterizing Alpha as a hard-to-program chip, but I wouldn't > agree with that. Neither would I. > Some of the later models had complex enough multi-issue > rules that instruction scheduling was quite complex, but that's only > fairly recent. The problem with Alpha early on was simply that the original > DEC compilers generated appalling quality of code, but I did the original > GCC port to the Alpha and it wasn't a particularly hard port to do. As I remember it, the C compiler did generate appalling code, but most of the other early compilers were merely poor, characteristic of a new architecture. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen @ 1999-09-29 0:00 ` Alfred Hilscher 1999-09-29 0:00 ` Robert Dewar 1 sibling, 1 reply; 87+ messages in thread From: Alfred Hilscher @ 1999-09-29 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <37F0D03C.DE4807D4@icn.siemens.de>, > Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > > What switches are > > needed to generate the smallest possible code ? > > > > Regards, > > Alfred > > Well obviously you strip a module to reduce debug symbol size, > and you go to dynamic linking of the GNAT library, but really > the size of small programs is a rather insignificant issue > these days when 100K of disk space costs 0.1 cents. Simply replace "Disk" by "Ram". Or lets think about a program of 1.5 MB, how transfer it on floppy ? > The size of large programs is a concern, but measuring the > size of hello world programs has nothing at all to do with > the size of real programs, since what you are really > concentrating on here is the default size of the minimal > run-time library. As mentioned in my original article, I did the comparison not only with "Hello world" (you've read it) ? ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Alfred Hilscher @ 1999-09-29 0:00 ` Robert Dewar 1999-09-30 0:00 ` Alfred Hilscher 0 siblings, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <37F22A06.176CA9F6@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > Simply replace "Disk" by "Ram". Or lets think about a program > of 1.5 MB, how transfer it on floppy ? No one has mentioned programs that would not fit on a floppy. Please do NOT assume that because one Hellow world program was 10K and the other was 20K, that you have a factor of 2 difference, no, more likely you have a 10K difference, representing the basic overhead. So perhaps we are talking about a 1.32 MB program rather than 1.33. As I said earlier, the comparison figures are pretty useless you cannot generalize from them in this way. > > The size of large programs is a concern, but measuring the > > size of small programs has nothing at all to do with > > the size of larger, since what you are really > > concentrating on here is the default size of the minimal > > run-time library. > > As mentioned in my original article, I did the comparison not > only with "Hello world" (you've read it) ? But you only did it with small programs ... and almost certainly non-comparable programs at that ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` Robert Dewar @ 1999-09-30 0:00 ` Alfred Hilscher 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar 0 siblings, 2 replies; 87+ messages in thread From: Alfred Hilscher @ 1999-09-30 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Simply replace "Disk" by "Ram". Or lets think about a program > > of 1.5 MB, how transfer it on floppy ? > > No one has mentioned programs that would not fit on a floppy. > Please do NOT assume that because one Hellow world program > was 10K and the other was 20K, that you have a factor of > 2 difference, no, more likely you have a 10K difference, > representing the basic overhead. So perhaps we are > talking about a 1.32 MB program rather than 1.33. This is absolutely wrong. OK, you don't like the "Hello world", so let me show an other example. I've wrote a simple WEB-server for remote control of production maschines. The code that GNAT produces was more than 800K, the same with Modula was about 70K (10% !), both on WinNT. Oh, sorry, I remember, you don't like comparison with other languages. Well, I compiled the same with ObjectAda 7.1 and the total amout of code (with static linking) was 200K. Therefore I think, that there must be a way to produce smaller EXE-files with GNAT, too. And _this_ was the question of my original posting. Ok, ok. I understand. I do not pay lots of $$$ for support, therefore I will not be told the neccessary compileroptions <g>. But it does not matter, I prefer the Aonix tool anyway. > As I said earlier, the comparison figures are pretty useless > you cannot generalize from them in this way. Don't you think, it's a question of what was campared ? Yes, one single "Hello world" says nothing. But a few programs ranging from 4 lines up to 5000 should be a little representative. > > > The size of large programs is a concern, but measuring the > > > size of small programs has nothing at all to do with > > > the size of larger, since what you are really > > > concentrating on here is the default size of the minimal > > > run-time library. > > > > As mentioned in my original article, I did the comparison not > > only with "Hello world" (you've read it) ? > > But you only did it with small programs ... and almost > certainly non-comparable programs at that ... NO. See above. Please tell me _your_ definition of "small programms". ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Alfred Hilscher @ 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar 1 sibling, 0 replies; 87+ messages in thread From: Gautier @ 1999-09-30 0:00 UTC (permalink / raw) > This is absolutely wrong. OK, you don't like the "Hello world", > so let me show an other example. I've wrote a simple WEB-server > for remote control of production maschines. The code that GNAT > produces was more than 800K, the same with Modula was about > 70K (10% !), both on WinNT. Oh, sorry, I remember, you don't > like comparison with other languages. Well, I compiled the same > with ObjectAda 7.1 and the total amout of code (with static linking) > was 200K. Therefore I think, that there must be a way to produce > smaller EXE-files with GNAT, too. And _this_ was the question of > my original posting. Ok, ok. I understand. I do not pay lots of > $$$ for support, therefore I will not be told the neccessary > compileroptions <g>. But it does not matter, I prefer the Aonix > tool anyway. But you forget to precise some crucial details: - which Modula compiler, which options (switches) ? - which options on Aonix ? - which options on GNAT ? With your 800KB on GNAT it _smells_ like you forgot, in building the whole project: - optimization: -O2 -fomit-frame-pointer - suppress run-time checks: -gnatp - disabling every inlining - stripping debug code from .exe (there is a lot, appended to the .exe file) -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses. 1999-09-30 0:00 ` Alfred Hilscher 1999-09-30 0:00 ` Gautier @ 1999-09-30 0:00 ` Robert Dewar 1 sibling, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <37F343A5.A68B8321@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > This is absolutely wrong. OK, you don't like the "Hello > world", so let me show an other example. I've wrote a simple > WEB-server > for remote control of production maschines. The code that GNAT > produces was more than 800K, the same with Modula was about > 70K (10% !), both on WinNT. Are you sure you measured code size, and not executable size, or do you think they are the same? Of course they are not. If you don't know why, you need to find out (most likely you were comparing a stripped program with a non-stripped program, if you don't know what stripping is about, you need to find out!) > Oh, sorry, I remember, you don't > like comparison with other languages. That is invented and wrong. I think comparisons with other languages can be instructive IF DONE RIGHT! > Well, I compiled the same > with ObjectAda 7.1 and the total amout of code (with static linking) > was 200K. Therefore I think, that there must be a way to produce > smaller EXE-files with GNAT, too. Now you make it clear that you think that the EXE file contains only code. THis is a severe misconception. > And _this_ was the question of > my original posting. Ok, ok. I understand. I do not pay lots > of $$$ for support, therefore I will not be told the > neccessary compileroptions <g>. You could try reading the documentation. I know that this seems an amazing idea for most people these days, but you would be surprised how helpful this can be. All the options are clearly stated in the documentation, you don't need to pay $$$ for support to find that out. > But it does not matter, I prefer the Aonix > tool anyway. Fine, but I wonder from the above whether you are giving either tool a real chance if you don't read the documentation to find out the basic capabilities of the tools. > > As I said earlier, the comparison figures are pretty useless > > you cannot generalize from them in this way. > But a few programs ranging from > 4 lines up to 5000 should be a little representative. Not if you make fundamental methodology mistakes, like assuming that EXE size is the same as code size. > > But you only did it with small programs ... and almost > > certainly non-comparable programs at that ... > NO. See above. Please tell me _your_ definition of "small > programms". Well of course this is a bit irrelevant, since it is clear that your methodology is fatally flawed in two respects: 1. You are assuming that EXE file size is a measure of code size. This is true only under careful controlled conditions, which you have not established. 2. You are not using appropriate options (see GNAT and GCC documentation) to minimize executable size. It's always interesting to figure out what the default options should be for a compiler. We seriously considered making -O2 the default, just to deal with the case of people who did comparisons without the foggiest idea of what they were doing (reviewers can often be in this category for example). Deciding whether the run time library should by default be stripped is another such decision point. But ultimately we decided to choose the options in a manner appropriate to those who know what they are doing, and in a manner consistent with other gcc compilers. This inevitably leads to the kind of confused thinking that I am responding to here, but there is no way to get the defaults right for everyone, you really have to count on people reading the documentation and taking the effort to be come minimally aware of what is going on. I know this sounds a bit harsh and dismissive, but there really is no substitute for careful reading of the documentation. In particular, posting a brief message to CLA asking for help can often be worse than useless for two reasons: 1. There is often insufficient information given to figure out what the real problem is, so suggested solutions are to some other problem. 2. The blind leading the blind phenomenon. THere are a lot of posts to CLA that just give plain wrong, or more commonly incomplete information. If you ask a question for example about a particular GNAT option, you are quite likely to be answered by someone who also has not thoroughly read the documentation and therefore answers with incomplete knowledge. A note here: if you have a GNAT-specific question, you will almost always do better on the chat@gnat.com list. There you will find a lot of GNAT knowledgable folk who have given up reading CLA a long time ago (excessive noise to signal ratio :-) This does not mean that the above two problems do not exist there too, but you definitely will have a better shot. Still, there is a furniture store in NY whose motto is "An educated consumer is our best customer", and that applies here too. The more effort you make to learn about what is going on, in particular by thoroughly reading the documentation, the better off you will be. It is indicative of the problem that it is quite rare to see questions about the documentatation itself (what does it mean when it says bla bla bla). This is surprising, because surely the documenation is not perfect, and there must be parts that are not 100% clear. By the way, some people do read the documentation closely, and provide useful feedback by reporting errors, unclear stuff, omissions etc to report@gnat.com. Thanks to all who have helped in this way in the past, and thanks in advance to those who can help in the future to improve the documenation in this manner. Robert Dewar Ada Core Technologies P.S. Alfred, obviously there are some major issues like stripping, and compilation options to be addressed, but I suspect we will arrive back at the point of comparability of code. It would be quite helpful if you would respond to an earlier suggestion I made and post just a single C function Ada subprogram that you consider comparable. That way we have a specific example to discuss. Such a discussion could be considerably more helpful than the general thread so far. The code size of a program is closely related to the code size of the individual components ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Code size of Ada ? was " Alfred Hilscher @ 1999-09-28 0:00 ` Larry Kilgallen 1999-09-28 0:00 ` Gautier 1999-09-29 0:00 ` Robert Dewar 2 siblings, 2 replies; 87+ messages in thread From: Larry Kilgallen @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sp8m9$a6e$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > unlike the case in C, there is in GNAT a default file naming > convention that means that, when you reference a spec, you can Using that reference to source files as a jumping-off spot, let me ask a question about GNAT naming of _listing_ files that has always puzzled me (as a non-user). With DEC Ada, one has default/recommended source file names for specification and body of: MYPACKAGE_.ADA MYPACKAGE.ADA and the major benefit I see from that is you can use the same convention for two listing files that share a directory and both can have the standard listing extension: MYPACKAGE_.LIS MYPACKAGE.LIS So how do the listing files get named by default in GNAT ? Larry Kilgallen ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-28 0:00 ` GNAT listing file default names (was: Ada95 Strengths/Weaknesses) Larry Kilgallen @ 1999-09-28 0:00 ` Gautier 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar 1 sibling, 1 reply; 87+ messages in thread From: Gautier @ 1999-09-28 0:00 UTC (permalink / raw) > With DEC Ada, one has default/recommended source file names > for specification and body of: > > MYPACKAGE_.ADA MYPACKAGE.ADA (...) BTW one can put both specification and body in MYPACKAGE.ADA (DEC Ada 3.* at least), which I almost always do under DEC. An ideal (personal view...) naming for GNAT files would be .ads : spec. only .adb : body only .ada or .asb : spec. + body G. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-28 0:00 ` Gautier @ 1999-09-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <37F0B922.4F973BC0@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote: > > With DEC Ada, one has default/recommended source file names > > for specification and body of: > > > > MYPACKAGE_.ADA MYPACKAGE.ADA > (...) > > BTW one can put both specification and body in MYPACKAGE.ADA > (DEC Ada 3.* at least), which I almost always do under DEC. My gosh, you *almost always* put the spec and body in the same file??? that undermines one of the most important links between file structure and modular structure of your program. AQ&S specifically recommends putting one unit per file, and nearly all coding standards I am familiar with in Ada require this arrangement. > An ideal (personal view...) naming for GNAT files would be > .ads : spec. only > .adb : body only > .ada or .asb : spec. + body which is why we have not bothered to implement multiple units per file. First, it is quite tricky, because of the problem of instantiating from another unit in the current source file, but mostly it would not be used very much, because most Ada users prefer one unit per file anyway. We consider gnatchop a good enough solution for the small number of exceptions to this rule, so multiple units per file is low down on our enhancement list. Robert Dewar Ada Core Technologies By the way: in GNAT a compilation environment can contain a subunit and body with the same unit name (this is a new feature in GNAT 3.12), and that's QUITE a strange situation, where default file naming sure does not work! > > G. > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-28 0:00 ` GNAT listing file default names (was: Ada95 Strengths/Weaknesses) Larry Kilgallen 1999-09-28 0:00 ` Gautier @ 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <1999Sep28.074901.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > and the major benefit I see from that is you can use the same > convention for two listing files that share a directory and > both can have the standard listing extension: > > MYPACKAGE_.LIS MYPACKAGE.LIS > > So how do the listing files get named by default in GNAT ? Voice from the past? :-) Actually no, a voice from the VMS present :-) Listing file? what's that? Seriously, like most modern compilers GNAT does not provide an old style listing file. You can if you like ask for complete listing output, but this is generated to standard output, and is redirected as required (unlike the situation in VMS, redirection of this kind is very simple in Unix and DOS-like systems). So this simply is not an issue ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-29 0:00 ` Robert Dewar @ 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Robert Dewar 0 siblings, 1 reply; 87+ messages in thread From: Larry Kilgallen @ 1999-09-29 0:00 UTC (permalink / raw) In article <7srmd7$2dr$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > Listing file? what's that? Seriously, like most modern compilers > GNAT does not provide an old style listing file. You can if you > like ask for complete listing output, but this is generated to > standard output, and is redirected as required (unlike the > situation in VMS, redirection of this kind is very simple in > Unix and DOS-like systems). To me /LISTING=[MYDIR.LISTINGS] doesn't seem complex, but we digress. Are you saying that if I issue whatever is the GNAT command for: "Recompile it all for production and give me a full listing for the permanent record of exactly what machine instructions shipped to customers for each source line." the listing from all compilation units ends up in a single file ? Yes, I realize that for optimizing compilers the bit about "for each source line" is incredibly difficult for a human to trace, and one hopes to never need it, but it does happen. Larry Kilgallen ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-29 0:00 ` Larry Kilgallen @ 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-29 0:00 UTC (permalink / raw) In article <1999Sep29.074624.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > In article <7srmd7$2dr$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > > > Listing file? what's that? Seriously, like most modern compilers > > GNAT does not provide an old style listing file. You can if you > > like ask for complete listing output, but this is generated to > > standard output, and is redirected as required (unlike the > > situation in VMS, redirection of this kind is very simple in > > Unix and DOS-like systems). > > To me /LISTING=[MYDIR.LISTINGS] doesn't seem complex, but we digress. You miss the point, the above VMS quote is NOT about redirection, but about using a specific parameter. What I was saying was that in Unix and DOS-like systems, redirection is so easy that one tends to use it extensively. Since general redirection is not nearly so easy in VMS, it is less used. In GNAT, to get a "listing" file, we simply do -gnatl >mydir.listings which is pretty straightforward ... > Are you saying that if I issue whatever is the GNAT command > for: > > "Recompile it all for production and give me a full > listing > for the permanent record of exactly what machine > instructions > shipped to customers for each source line." > > the listing from all compilation units ends up in a single > file ? Trivial commands can put this in one file, many files etc etc, but the concept of a "listing file" as such is indeed an antiquated one, and you will not in general find modern compilers on modern systems providing this capability in a VMS-like way -- yes, yes, we know, you *like* the VMS capabilities in this area :-) > Yes, I realize that for optimizing compilers the bit about "for each > source line" is incredibly difficult for a human to trace, and one hopes > to never need it, but it does happen. A GNAT generated assembly file with embedded line number information will indeed give you the information you need, or alternatively you can use a tool like objdump to get the information you need. > > Larry Kilgallen > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-29 0:00 ` Robert Dewar @ 1999-09-29 0:00 ` Larry Kilgallen 1999-09-30 0:00 ` Robert Dewar 0 siblings, 1 reply; 87+ messages in thread From: Larry Kilgallen @ 1999-09-29 0:00 UTC (permalink / raw) In article <7stris$k6t$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > In article <1999Sep29.074624.1@eisner>, > Kilgallen@eisner.decus.org.nospam wrote: >> To me /LISTING=[MYDIR.LISTINGS] doesn't seem complex, but we > digress. > > You miss the point, the above VMS quote is NOT about > redirection, but about using a specific parameter. What I > was saying was that in Unix and DOS-like systems, redirection > is so easy that one tends to use it extensively. Since general > redirection is not nearly so easy in VMS, it is less used. I interpret this as saying that you dislike the VMS implementation of PIPE. Let me know if there is something more to it, but I (we) digress. > In GNAT, to get a "listing" file, we simply do > > -gnatl >mydir.listings > > which is pretty straightforward ... > Trivial commands can put this in one file, many files etc etc, I take it then that this is postprocessing, similar to what I read described as the Gnat Chop utility. > A GNAT generated assembly file with embedded line number > information will indeed give you the information you need, > or alternatively you can use a tool like objdump to get > the information you need. My presumption would be that the former method would include the line-numbered source (under some combination of qualifiers) but the objdump method would not. Is that correct ? Larry Kilgallen ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses) 1999-09-29 0:00 ` Larry Kilgallen @ 1999-09-30 0:00 ` Robert Dewar 0 siblings, 0 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-30 0:00 UTC (permalink / raw) In article <1999Sep29.180007.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > I interpret this as saying that you dislike the VMS implementation > of PIPE. Let me know if there is something more to it, but I (we) > digress. No, it is just that there is nothing as convenient as the > notation of Unix for redirection in VMS ... > > In GNAT, to get a "listing" file, we simply do > > > > -gnatl >mydir.listings > > > > which is pretty straightforward ... > > > Trivial commands can put this in one file, many files etc etc, > > I take it then that this is postprocessing, similar to what I > read described as the Gnat Chop utility. Well the basic listing command -gnatl >mydir-listings is entirely analogous to the special purpose qualifier you quoted, and no there is no post processing. If you want to put the listings all in one file, you would do -gnatl >>listings or some such > > > A GNAT generated assembly file with embedded line number > > information will indeed give you the information you need, > > or alternatively you can use a tool like objdump to get > > the information you need. > > My presumption would be that the former method would include the > line-numbered source (under some combination of qualifiers) but > the objdump method would not. Is that correct ? Actually it is the other way round, the assembly listing is the file passed to the assembler, and does not contain source. The objdump listing can optionally (use --source if I remember right) intersperse the line numbered source in the listing. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` the middleman 1999-09-28 0:00 ` Robert Dewar 2 siblings, 0 replies; 87+ messages in thread From: the middleman @ 1999-09-28 0:00 UTC (permalink / raw) Thanx to everyone who answered. It certainly helped me convince my friends that there is nothing wrong with me liking Ada95. -- ByeZeeBye the middleman Chuck(les) ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses the middleman @ 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` David Starner 2 siblings, 2 replies; 87+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7smp30$9aa1@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > * Type safety makes it harder for some stuff to get done - > i.e. it's impossible to make a type look exactly like a number > in Ada, That is just a false statement. Unchecked conversion allows you to do anything in this area you can do in C++. Yes, some uses of unchecked conversion in Ada are implementation dependent, but no more so or less so than the corresponding casts in C++. > but trivial in C++. Two comments: one, yes the syntax is trivial in C++, and this is something I would list as a disadvantage of C++, not an advantage. It is far too easy to break the type model in C++. > * C++ includes several somewhat experimental features > (template specilization, > multiple inheritance) that Ada designers considered too > experimental or > specialized to add. Well I think you need to give examples here. Many people would regard the multiple inheritance in C++ to be a disadvantage for three reasons: 1. The OO model is much cleaner if only single inheritance is used, so the semantics is much simpler. This is why many OO languages deliberately avoid supporting MI. 2. The MI model in C++ is one of several. Having a specific model built into the language is unhelpful if your problem is best handled by some different model. 3. In most C++ compilers, you pay a price in distributed overhead for this feature, even if you do not use multiple inheritance. > Disadvantages vs. C & C++ > * Large base of installed libraries. If you can find a Ada library that does > what you need to do (not unlikely, but not as likely as for C or C++ - and it's > probably a wrapper around a C library), it probably won't come precompiled and > set up for your system It seems far preferable to find libraries in source form, for many reasons! Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert A Duff 1999-09-28 0:00 ` David Starner 1 sibling, 1 reply; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sp914$ago$1@nnrp1.deja.com>, Robert Dewar wrote: >In article <7smp30$9aa1@news.cis.okstate.edu>, >> * C++ includes several somewhat experimental features >> (template specilization, >> multiple inheritance) that Ada designers considered too >> experimental or >> specialized to add. > >Well I think you need to give examples here. Many people would >regard the multiple inheritance in C++ to be a disadvantage for >three reasons: > >1. The OO model is much cleaner if only single inheritance is >used, so the semantics is much simpler. This is why many OO >languages deliberately avoid supporting MI. > >2. The MI model in C++ is one of several. Having a specific >model built into the language is unhelpful if your problem is >best handled by some different model. > >3. In most C++ compilers, you pay a price in distributed >overhead for this feature, even if you do not use multiple >inheritance. A clearer way to express my objections to your objections here is: you're viewing from the point of view of a language & compiler designer. From a programmer's standpoint, multiple inheritance can be a useful tool. And hence, to them, it is a disadvantage that you don't have MI in Ada. One minor problem in Ada that MI could help is the special Controlled classes. Either your base class is derived from it, or it isn't and that limits your subclasses. There's no way in Ada to add another 'special' base class without providing it Controlled and Uncontrolled versions, or something otherwise ugly or arbitrary. David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner @ 1999-09-29 0:00 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 1999-09-29 0:00 UTC (permalink / raw) dvdeug@x8b4e53cd. (David Starner) writes: > One minor problem in Ada that MI could help is the special > Controlled classes. Either your base class is derived from > it, or it isn't and that limits your subclasses. ... If your base class is not derived from controlled, it's easy enough to add controlledness by adding a *component* whose type is derived from controlled. There's no need to make everything controlled from the start, "just in case" you want a Finalize op somewhere down in the hierarchy. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner @ 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar 1 sibling, 1 reply; 87+ messages in thread From: David Starner @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sp914$ago$1@nnrp1.deja.com>, Robert Dewar wrote: >In article <7smp30$9aa1@news.cis.okstate.edu>, > dstarner98@aasaa.ofe.org wrote: >> * Type safety makes it harder for some stuff to get done - >> i.e. it's impossible to make a type look exactly like a number >> in Ada, > >That is just a false statement. Unchecked conversion allows you >to do anything in this area you can do in C++. Yes, some uses >of unchecked conversion in Ada are implementation dependent, >but no more so or less so than the corresponding casts in C++. This has nothing to do with what I was talking about. In C++, I can write class BigInt, assign integers to it and pass it to templates expecting numbers. In fact, I can sed s/int/BigInt/g and add include "bigint.h" to the top of all the files, and the programs will run the same (provided, of course, that BigInt follows the same semantics as int.) In Ada, I can't write a template that expects a integer type and pass a BigInt to it. I can't assign to it from universal integer. In Ada, BigInt can't masquarade as a number. >> but trivial in C++. > >Two comments: one, yes the syntax is trivial in C++, and this >is something I would list as a disadvantage of C++, not an >advantage. It is far too easy to break the type model in C++. It can be a disadvantage (which I discussed above, which above, which you snipped), but it can also be an advantage. > >> * C++ includes several somewhat experimental features >> (template specilization, >> multiple inheritance) that Ada designers considered too >> experimental or >> specialized to add. > >Well I think you need to give examples here. Many people would >regard the multiple inheritance in C++ to be a disadvantage for >three reasons: >1. The OO model is much cleaner if only single inheritance is >used, so the semantics is much simpler. This is why many OO >languages deliberately avoid supporting MI. > >2. The MI model in C++ is one of several. Having a specific >model built into the language is unhelpful if your problem is >best handled by some different model. > >3. In most C++ compilers, you pay a price in distributed >overhead for this feature, even if you do not use multiple >inheritance. #2 is the reason RMS doesn't like OO languages, because the inheritance model is only one of many, and he prefers to write his own. This could be extended to many of Ada's features (tasking, templates, exceptions, functions (why carry around all the extra baggage for recursion if you don't need it?)). Frankly, for all your scoffing at it, many people like and use MI. From a programmer's prospective, not having MI may be a big disadvantage. I did point this features out as experimental. >> Disadvantages vs. C & C++ >> * Large base of installed libraries. If you can find a Ada >library that does >> what you need to do (not unlikely, but not as likely as for C >or C++ - and it's >> probably a wrapper around a C library), it probably won't come >precompiled and >> set up for your system > >It seems far preferable to find libraries in source form, for >many reasons! Almost anything I download precompiled from Debian just works. If it doesn't, I've got someone to complain to. Frequently, I've downloaded programs and libraries, and deleted them after spending a few hours trying to get them to build. If I had to build many of the libraries on my system, many of them wouldn't be there. Secondly, my distribution of the C++ game (mentioned in my email about binary sizes) is 11K. My Ada distribution is 227K. This is because it uses the MW Components, and I prefer to say "just type make" than "go to http... and download this and install it here and do this ..." The only Ada library I would not ship with my program (and let the end user install it) is gtkada because I can hopefully rely on an rpm or deb being available. David Starner - dstarner98@aasaa.ofe.org ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` David Starner @ 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Ray Blaak 0 siblings, 1 reply; 87+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7spd4c$9ic2@news.cis.okstate.edu>, dvdeug@x8b4e53cd. (David Starner) wrote: > This has nothing to do with what I was talking about. In C++, I > can write class BigInt, assign integers to it and pass it to templates > expecting numbers. In fact, I can sed s/int/BigInt/g and add include "bigint.h" > to the top of all the files, and the programs will run the same (provided, > of course, that BigInt follows the same semantics as int.) In Ada, I can't > write a template that expects a integer type and pass a BigInt to it. I > can't assign to it from universal integer. In Ada, BigInt can't masquarade > as a number. Why not use a private generic type, and pass in a generic package containing the operators to be used (i.e. the realization of the signature for the type), seems quite straightforward. A little more work than in the C++ case, but you get a lot for this extra work (type safety and the contract model for generics). > > Frankly, for all your scoffing at it, many people like and use MI. From > a programmer's prospective, not having MI may be a big disadvantage. As I asked before, let's see examples. > I did point this features out as experimental. I don't regard it as experimental. It is well defined, fully standardized, and fairly widely used. I just think that it is poorly designed that's all. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Robert Dewar @ 1999-09-28 0:00 ` Ray Blaak 0 siblings, 0 replies; 87+ messages in thread From: Ray Blaak @ 1999-09-28 0:00 UTC (permalink / raw) In article <7spd4c$9ic2@news.cis.okstate.edu>, David Starner wrote: > This has nothing to do with what I was talking about. In C++, I can write > class BigInt, assign integers to it and pass it to templates expecting > numbers. In fact, I can sed s/int/BigInt/g and add include "bigint.h" to the > top of all the files, and the programs will run the same (provided, of > course, that BigInt follows the same semantics as int.) In Ada, I can't write > a template that expects a integer type and pass a BigInt to it. I can't > assign to it from universal integer. In Ada, BigInt can't masquarade as a > number. You might prefer C++'s ability for classes to work directly with integer literals, but Ada's "inability" to do this is not by accident, I believe, but rather result of a philosphical position. In C++, one can implicitly construct objects from any other object for which there is a constructor with the appropriate type as a parameter, e.g., BigInt I = 2; In Ada you cannot. The reason for this is "no implicit conversions". The reason for *that* is "less bugs". Everything you do to change something's type must be explicitly done. This makes all such changes visible in the source code, making what is actually happening easier to understand. It also prevents "accidental" conversions, which can happen quite a bit in C++ if one is not careful. I, in fact, generally prefer to see: BigInt I := CreateBigInt(2); and so usually prefer Ada's restriction. On the other hand, I have been in situations where we did want this implicit conversion, and justified it due to the cost of migrating an object to a new class type. We didn't want to break the mountains of old code, so with the appropriate constructor, a previously exposed raw information string was now implicitly converted into an appropriately encapsulated object. After a suitable migration period, we can remove the constructor, after which compiler errors will quickly point out the (hopefully) few remaining migrations needed. One of the great things about C++ is that you can control this. Don't supply the constructors, and the implicit conversions won't happen. In general, C++ done right can be just as correct as Ada. It is just that it is so easy to be lazy. If one does want to have Ada source looking closer to implicit conversions of literals, supply an appropriate definition of the unary "+" (as suggested elsewhere by Robert Dewar): function "+" (i : Integer) return BigInt; BigInt I := +2; -- 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] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman ` (3 preceding siblings ...) 1999-09-27 0:00 ` David Starner @ 1999-09-28 0:00 ` Geoff Bull 1999-09-29 0:00 ` the middleman 1999-09-28 0:00 ` Geoff Bull 5 siblings, 1 reply; 87+ messages in thread From: Geoff Bull @ 1999-09-28 0:00 UTC (permalink / raw) Ah! a troll for a language war. the middleman wrote: > > I've been learning Ada95 for a year now. And although I don't have much > experience of other languages I'd certainly say it was my favourite. > In discussions with friends the abilities of Ada95 have cropped up. I > was wondering if anyone could possibly point out the weaknesses and the > strengths that Ada95 has when compared to other languages such as C so > that I can finally set the record straight. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-28 0:00 ` Geoff Bull @ 1999-09-29 0:00 ` the middleman 1999-09-29 0:00 ` Robert A Duff 0 siblings, 1 reply; 87+ messages in thread From: the middleman @ 1999-09-29 0:00 UTC (permalink / raw) Geoff Bull wrote: > > Ah! a troll for a language war. Sorry! I was just wanting to make it clear to a friend that Ada was worthwhile learning. I didn't mean to start this war! -- ByeZeeBye the middleman Chuck(les) ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-29 0:00 ` the middleman @ 1999-09-29 0:00 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 1999-09-29 0:00 UTC (permalink / raw) the middleman <charles.dand@yukyonline.co.yuky> writes: > Sorry! > I was just wanting to make it clear to a friend that Ada was worthwhile > learning. I didn't mean to start this war! Such "wars" don't usually get out of hand unless they're cross-posted to the newsgroups belonging to both warring parties. ;-) ;-) - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada95 Strengths/Weaknesses. 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman ` (4 preceding siblings ...) 1999-09-28 0:00 ` Geoff Bull @ 1999-09-28 0:00 ` Geoff Bull 5 siblings, 0 replies; 87+ messages in thread From: Geoff Bull @ 1999-09-28 0:00 UTC (permalink / raw) the middleman wrote: > I > was wondering if anyone could possibly point out the weaknesses and the > strengths that Ada95 has when compared to other languages such as C This may be useful for you: http://www.adahome.com/Ammo/cpp2ada.html http://www.adaic.org/intro/ http://www.adaic.org/docs/flyers/choose-ada.html Where I work, the C++ programmers are always asking to buy more BoundsChecker licenses. With Ada, such a tool is rarely useful. Ditto for Java. ^ permalink raw reply [flat|nested] 87+ messages in thread
end of thread, other threads:[~1999-10-19 0:00 UTC | newest] Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-27 0:00 Ada95 Strengths/Weaknesses the middleman 1999-09-27 0:00 ` Steve Doiel 1999-09-27 0:00 ` J. David Bryan 1999-09-27 0:00 ` Marin David Condic 1999-09-27 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` Hyman Rosen 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Preben Randhol 1999-09-28 0:00 ` bill 1999-09-27 0:00 ` Aidan Skinner 1999-09-28 0:00 ` Preben Randhol 1999-09-28 0:00 ` Larry Kilgallen 1999-09-28 0:00 ` Steve Doiel 1999-09-28 0:00 ` Preben Randhol 1999-09-27 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` Ed Falis 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1999-09-28 0:00 ` p.obry 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Richard D Riehle 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert Dewar 1999-09-30 0:00 ` Pragma (was Re: Ada95 Strengths/Weaknesses.) Preben Randhol 1999-09-30 0:00 ` Preben Randhol 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses Ted Dennison 1999-09-28 0:00 ` Simon Wright 1999-09-28 0:00 ` Code size of Ada ? was " Alfred Hilscher 1999-09-28 0:00 ` Gautier 1999-09-28 0:00 ` David Botton 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Alfred Hilscher 1999-09-29 0:00 ` Ted Dennison 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` Ed Falis 1999-09-29 0:00 ` Gautier 1999-09-29 0:00 ` tmoran 1999-09-30 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar 1999-09-30 0:00 ` Alfred Hilscher 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` Robert Dewar 1999-09-30 0:00 ` tmoran 1999-09-30 0:00 ` Ehud Lamm 1999-09-30 0:00 ` Robert Dewar [not found] ` <7t2e1l$lqt2@ftp.kvaerner.com> [not found] ` <37F91D6E.58685CFE@mitre.org> [not found] ` <7tf7uo$h2b$1@nnrp1.deja.com> [not found] ` <37FBA978.A86762F1@mitre.org> 1999-10-18 0:00 ` Robert Dewar 1999-10-19 0:00 ` Code size of Ada ? Robert I. Eachus [not found] ` <7tf7uo <37FBA978.A86762F1@mitre.org> [not found] ` <5OkO3.2$1e.659@typhoon.nyu.edu> 1999-10-19 0:00 ` Code size of Ada ? was Re: Ada95 Strengths/Weaknesses Robert I. Eachus 1999-09-29 0:00 ` Alfred Hilscher 1999-09-29 0:00 ` Robert Dewar 1999-09-30 0:00 ` Alfred Hilscher 1999-09-30 0:00 ` Gautier 1999-09-30 0:00 ` Robert Dewar 1999-09-28 0:00 ` GNAT listing file default names (was: Ada95 Strengths/Weaknesses) Larry Kilgallen 1999-09-28 0:00 ` Gautier 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen 1999-09-29 0:00 ` Robert Dewar 1999-09-29 0:00 ` Larry Kilgallen 1999-09-30 0:00 ` Robert Dewar 1999-09-28 0:00 ` Ada95 Strengths/Weaknesses the middleman 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` David Starner 1999-09-29 0:00 ` Robert A Duff 1999-09-28 0:00 ` David Starner 1999-09-28 0:00 ` Robert Dewar 1999-09-28 0:00 ` Ray Blaak 1999-09-28 0:00 ` Geoff Bull 1999-09-29 0:00 ` the middleman 1999-09-29 0:00 ` Robert A Duff 1999-09-28 0:00 ` Geoff Bull
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox