Ada95 Strengths/Weaknesses.

Ada95 Strengths/Weaknesses.

[the middleman]

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)

Re: Ada95 Strengths/Weaknesses.

[Steve Doiel]

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)

Re: Ada95 Strengths/Weaknesses.

[J. David Bryan]

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

Re: Ada95 Strengths/Weaknesses.

[Marin David Condic]

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/

Re: Ada95 Strengths/Weaknesses.

[Hyman Rosen]

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;
}

Re: Ada95 Strengths/Weaknesses.

[Ed Falis]

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;
> }
> 
> 

Re: Ada95 Strengths/Weaknesses.

[Hyman Rosen]

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?

Re: Ada95 Strengths/Weaknesses.

[Ed Falis]

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

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[Preben Randhol]

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

Re: Ada95 Strengths/Weaknesses.

[bill]

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
 

Re: Ada95 Strengths/Weaknesses.

[Aidan Skinner]

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" 

Re: Ada95 Strengths/Weaknesses.

[Steve Doiel]

<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

Re: Ada95 Strengths/Weaknesses.

[Larry Kilgallen]

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

Re: Ada95 Strengths/Weaknesses.

[Preben Randhol]

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

Re: Ada95 Strengths/Weaknesses.

[Preben Randhol]

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

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[the middleman]

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)

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Alfred Hilscher]

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

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Gautier]

> 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/

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[David Botton]

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

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Larry Kilgallen]

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

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Alfred Hilscher]

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

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Gautier]

> 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/

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Ed Falis]

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

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[tmoran]

>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?

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Gautier]

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/

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Alfred Hilscher]

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

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Gautier]

> 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/

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[tmoran]

>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".

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Ehud Lamm]

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!

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ?

[Robert I. Eachus]

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...

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert I. Eachus]

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...

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Ted Dennison]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Alfred Hilscher]

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) ?

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Alfred Hilscher]

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".

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.

[Gautier]

> 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/

GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Larry Kilgallen]

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

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Gautier]

> 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.

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Robert Dewar]

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.

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Robert Dewar]

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.

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Larry Kilgallen]

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

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Robert Dewar]

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.

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Larry Kilgallen]

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

Re: GNAT listing file default names (was: Ada95 Strengths/Weaknesses)

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Ted Dennison]

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.

Re: Ada95 Strengths/Weaknesses.

[Simon Wright]

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).

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Pragma (was Re: Ada95 Strengths/Weaknesses.)

[Preben Randhol]

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

Re: Pragma (was Re: Ada95 Strengths/Weaknesses.)

[Preben Randhol]

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

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[p.obry]

<<
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.

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Richard D Riehle]

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
 

Re: Ada95 Strengths/Weaknesses.

[Gautier]

> (...) 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/

Re: Ada95 Strengths/Weaknesses.

[Ed Falis]

> > (...) 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

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Robert Dewar]

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.

Re: Ada95 Strengths/Weaknesses.

[Ray Blaak]

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.

Re: Ada95 Strengths/Weaknesses.

[David Starner]

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

Re: Ada95 Strengths/Weaknesses.

[Robert A Duff]

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.

Re: Ada95 Strengths/Weaknesses.

[Geoff Bull]

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.

Re: Ada95 Strengths/Weaknesses.

[the middleman]

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)

Re: Ada95 Strengths/Weaknesses.

[Robert A Duff]

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.

Re: Ada95 Strengths/Weaknesses.

[Geoff Bull]

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.