Look what I caught! was re:Ada paper critic

Look what I caught! was re:Ada paper critic

[Alderson, Paul A.]

Here's what I caught on my troll:

1.) People who missed the point (maybe intentionally) of the big
    chain of package names you end up with in some Ada packages.

The point here is if your company has a policy against using
"uses" in their code, then you have to:

   A.) Use a renames
   B.) Use the fully specified name.
   C.) Ignore the standard and use use.

Now if you use a rename, then you introduce more work for the
code reviewer (remember code is written once and looked at many
times).  Yes it is a small diversion, which only extends the
search a few seconds further.

If you use the fully specified name the reviewer can immediately
start searching the Ada code for that package (not file).

Now why did the company forbid "use"?  Probably because it leads
to possible errors and isn't being precise...which is why they chose
Ada.

For those who couldn't get past the case, change the case to your
liking and continue.

2.) People assumed I was the one that had the problems with using
    global variables (even though the globals referred to were
    actually package variables) and etc.

If one lives in the Ada industry long enough you will find that
much of the embedded code written with Ada uses package variables
extensively.  Why?  Mostly because pushing and popping things
on and off stacks is time consuming.  Secondly ...wait I'll
make this point #3...

3.) Many people in this group seem to have a "write the code
    and never look at it again" attitude.  Writing code is only
    one small aspect of the software development life cycle.
    When you start looking at verification on Level-A systems
    the use of certain software structures becomes iffy.  For
    example if you don't use ANY global variables (You know
    because global variables are bad!)  Then one must insure
    that the stack will not collide with heap or code space.
    If you take some time to think about this, you'll not be
    so quick to say globals are bad!

    This brings up my discussion on why not being able to tell
    an array from a function is a problem.  From the writing
    of the code its nice to be able to change your mind on
    the implementation of a function to array.  But then again
    why are you changing something like this?  This is an
    indication that proper design was not followed.  And
    again the code will be viewed many more times than written
    (hopefully anyway).  So when reviewing and testing this
    code one will see that:

      x := a.y(z);  -- Purposefully descriptive names.
      And we know z's range and if we knew it was an array
      we could easily set values within "a.y".  Unfortunately
      we can't tell this with this language and have to
      again perform the ole search of the code to find out what
      a.y is.  Needlessly....  Yes its only a few seconds....

    I concede that replacing a function with and array would be
    nice on the development end.  Unfortunately when you do this
    and the verification occurs (level - A) now all those tests
    magically break and strangely enough the code didn't change!
    Now what would have been a simple search and replace by the
    developer is now a big search and destroy mission by the
    verification team.

4.) Some missed the point I was making about how Ada was not
    designed to be purely a high level language.  The point
    that Ada uses integers is that an integer (no matter what
    the size) is a hardware notion.  The language does allow
    for pure ranges, but yet keeps its feet firmly tied to the
    hardware.  Again how many instances do you really need
    the full range of an int?  Rarely...so why did the type
    ever exist?  My guess is because at the time of its design
    it was too far reaching to simply declare ranges and
    making the compiler figure out the appropriate size.
    The point here is that Ada is still tied to the hardware.
    The pre-emptive counter point here was knowing people
    would say they didn't have to use integers but are just
    an option.  Which is why I said people didn't need to
    use pointers in C either, yet it is scrutinized for its
    pointer problem (Rightfully so).

5.) Yet another argument was that the language can help keep
    bad programmers from doing bad things.  I must agree
    100% on this and simply say that Ada doesn't do nearly
    enough to do this.  Yes...other languages are even worse.
    The danger here is that MANY people believe Ada is
    really good at preventing bad things from happening.
    It prevents some of them, but really if redesigned could
    be leaps and bounds better.

    (Yes I'm criticizing Ada in a vacuum...I don't care how
     evil other languages are...I want it right dammit!)

6.) Because I criticize the language people immediately think
that I'm saying another language is "better" than Ada.  The original
poster simply asked for the bad things about Ada.  I posted them...
and yes while no other language offers as much, we have a long way
to go.

7.) Ada isn't taught anymore people...Its a general statement.
    Your suppose to get the idea behind it.  For those
    who are 100% literal.  Ada is no longer being taught at
    as many institutes of learning as it had been.  In fact
    very few places continue to teach it.  If trends continue
    as they are, Ada will be completely phased out from public
    learning institutions in the near future.  Latin is a dead
    language, yet it is taught.  Is it really "taught" however?

8.) People seem to miss the point that no matter how great the
    language is, if it has crappy compilers, crappy debugging
    and a crappy IDE's then its going to be a interesting blip
    on the software radar screen that fades out fast.  The
    language itself can help with easy development of these
    tools.  Was it Ada's fault for the lack of these tools or
    other issues?  No idea...

9.) Gimpel Lint - Very good piece of software for C programmers.
      Style, pointer checks, type checks....
      Can't do run-time checks - which if your language is
      designed right from the start you don't need....
      (No main stream language exists YET that will allow
       static analysis, thus eliminating run time checks.)

10.) Just because I like having lists of ten! 8)

And you thought you were SOOOOO RIGHT.  Turns out you were only MOSTLY
RIGHT!  SO THERE!  8)

Re: Look what I caught! was re:Ada paper critic

[Darren New]

"Alderson, Paul A." wrote:
>       (No main stream language exists YET that will allow
>        static analysis, thus eliminating run time checks.)

Nor is it ever likely to, methinks. Certainly not a general purpose
language, and very certainly not a language capable of real-time work.  See,
there's this thing called "the halting problem"....

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Look what I caught! was re:Ada paper critic

[Vinzent Hoefler]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote:

>Here's what I caught on my troll:

 :-)

>1.) People who missed the point (maybe intentionally) of the big
>    chain of package names you end up with in some Ada packages.
>
>The point here is if your company has a policy against using
>"uses" in their code, then you have to:
>
>   A.) Use a renames
>   B.) Use the fully specified name.

Like in SPARK.

>   C.) Ignore the standard and use use.

And get "use"d to be fired. ;)

>Now if you use a rename, then you introduce more work for the
>code reviewer (remember code is written once and looked at many
>times).  Yes it is a small diversion, which only extends the
>search a few seconds further.

Still, it would depend on *how* you do it.

>2.) People assumed I was the one that had the problems with using
>    global variables (even though the globals referred to were
>    actually package variables) and etc.
>
>If one lives in the Ada industry long enough you will find that
>much of the embedded code written with Ada uses package variables
>extensively.  Why?  Mostly because pushing and popping things
>on and off stacks is time consuming.

That thing hasn't anything to do with Ada. If you are forced to use
global variables because of efficiency requirements, you'll be forced
to use them in *any* language.

>3.) Many people in this group seem to have a "write the code
>    and never look at it again" attitude.

I got another impression from most Ada program(mer)s I've seen. My
personal experience shows me that the *hurry, hurry fast, if it works,
I'll never look at it again* approach is more wide-spread in other
languages.

>  Writing code is only
>    one small aspect of the software development life cycle.

About 10%, if not even less, I'd say.

>    This brings up my discussion on why not being able to tell
>    an array from a function is a problem.  From the writing
>    of the code its nice to be able to change your mind on
>    the implementation of a function to array.  But then again
>    why are you changing something like this?  This is an
>    indication that proper design was not followed.

No. A design you have can be implemented in at least 10 different
ways. The design says very little about its implementation.

>      x := a.y(z);  -- Purposefully descriptive names.
>      And we know z's range and if we knew it was an array
>      we could easily set values within "a.y".  Unfortunately
>      we can't tell this with this language and have to
>      again perform the ole search of the code to find out what
>      a.y is.

Well, hmm. Surely I miss something, but how can "y" be a function
here?

>  Needlessly....  Yes its only a few seconds....

Well, considering how many of those few seconds I already hang around
with C++ code to see how this or that function is declared and if it
changes something, this sounds funny. In C++ I can even overload the
[] operator, this changes the whole world.

>    I concede that replacing a function with and array would be
>    nice on the development end.  Unfortunately when you do this
>    and the verification occurs (level - A) now all those tests
>    magically break and strangely enough the code didn't change!

Well, try to place a simple "virtual" in C++ code at appropriate
declarations of a class and strangely see, that although the code has
not changed at all, it completely f***s up.

In Ada the semantic does not change, if you switch the declaration
from an array to a function or vice versa unless you do very nasty
things.

>    Now what would have been a simple search and replace by the
>    developer is now a big search and destroy mission by the
>    verification team.

Well, when does verification occur in the *normal* case? I'd guess at
the end of a development phase. And I'd guess, the verification must
occur again, if some of the code was changed.

>4.) Some missed the point I was making about how Ada was not
>    designed to be purely a high level language.  The point
>    that Ada uses integers is that an integer (no matter what
>    the size) is a hardware notion.

Not really. Just that 'range is implementation defined. It says
"nothing" about the hardware.

>  The language does allow
>    for pure ranges, but yet keeps its feet firmly tied to the
>    hardware.

Oh well. What other kind of integers can you imagine? We use
programing languages to program computers and computers *are* still
hardware. And if I imagine a machine which only knows floating point
registers, I'd guess, the meaning of Integer would be the same still
although the hardware representation might be totally different.

>  Again how many instances do you really need
>    the full range of an int?  Rarely...so why did the type
>    ever exist?

For type compatibility reasons, I'd guess. Ada knows *sub*types. So
you need a base type at least. Well, you could say, ok, so let the
programmer define the base type, but that also means, he has to
implement the arithmetic operations on that type. And how to do that
if you don't have a type on where those operations are defined?

>  My guess is because at the time of its design
>    it was too far reaching to simply declare ranges and
>    making the compiler figure out the appropriate size.

Well, the compiler normally does this. If the standard integer size is
16-bit and you declare a range of 0 .. 100_000 the compiler will
probably implement is as a 32-bit value (or maybe 24 bits or so...).
In the case of a range of 0 .. 10_000 the compiler will *probably*
implement is as the most effective hardware abstraction - in 16 bit.
But nothing stops the compiler from implementing it in 14 bits. So it
is really not any view on the hardware in the language in that case.
The compiler simply assures you that your range will fit in the chosen
representation.

With "for ... use" you are still able to override this (normally
hidden) behaviour if you *have to* rely on a specific implementation.
Still this declaration then should work on another machine with
another default integer size in the *same* way.

So I can't see no really hardware specific thing here. Perhaps one:
Ada might rely on the machine to actually have integers at all.

So it's certainly the wrong language for quantum probability computers
or so... ;-)

>    The point here is that Ada is still tied to the hardware.

That's simply wrong. Yes, the *compiler* normally tries to use the
most effective representation on the specific hardware. And no, this
hasn't anything to do with Ada being *tied* to hardware.

>    The pre-emptive counter point here was knowing people
>    would say they didn't have to use integers but are just
>    an option.

Well, IMO you shouldn't use pure Integers without a good reason. They
aren't good for anything other than deriving types *from* it. :-)
What's wrong with specifying a range or even a modular type?

>  Which is why I said people didn't need to
>    use pointers in C either, yet it is scrutinized for its
>    pointer problem (Rightfully so).

Well, look at the C runtime library and tell me, how many functions
you could use without using pointers? Not to mention the nasty "array"
thing...

>5.) Yet another argument was that the language can help keep
>    bad programmers from doing bad things.  I must agree
>    100% on this and simply say that Ada doesn't do nearly
>    enough to do this.

To this one I might agree. Although I'm still sometimes struggling
with the compiler what's right. Damn, I *know*, I can assign this type
of variable to another one, why is the compiler preventing me from
doing this? ;-)

So actually it does even prevent me from doing the right things if I
don't express them the right way. I like that, no wonder, why this
language is called after a woman. ;-)

>    (Yes I'm criticizing Ada in a vacuum...I don't care how
>     evil other languages are...I want it right dammit!)

That's simple: *Do* it right.

This is possible in either language, yes. The good thing with Ada is
that the possibility to do it right has a greater probability. :-)
 
>6.) Because I criticize the language people immediately think
>that I'm saying another language is "better" than Ada.  The original
>poster simply asked for the bad things about Ada.  I posted them...

You can do bad things in Ada, yes. But some of the things you said,
can't be prevented in any (procedurale) language. And some were simply
wrong.

>7.) Ada isn't taught anymore people...Its a general statement.

But even with this stated generality: It's wrong.

>8.) People seem to miss the point that no matter how great the
>    language is, if it has crappy compilers, crappy debugging
>    and a crappy IDE's then its going to be a interesting blip
>    on the software radar screen that fades out fast.

Well, gcc has no IDE at all and I would state that it is one of the
most widely used compilers in the world. And if the rumours are right,
gcc3.1 does surprisingly include Ada95 (again?).

>  The
>    language itself can help with easy development of these
>    tools.  Was it Ada's fault for the lack of these tools or
>    other issues?  No idea...

Well, I can't see the lack of tools. Might be there are less tools
than for C or Java or $WHATEVER but in the end it simply boils down to
using *one* tool. Actually *two*: an editor and a compiler. :-)

>9.) Gimpel Lint - Very good piece of software for C programmers.

Well, so it seems you need a *post*-processor to verify you did the
right thing. And my question: how widely used is *that* one?

>      Can't do run-time checks - which if your language is
>      designed right from the start you don't need....

No. Its not a long time ago (was it in c.l.a.?) I read that C arrays
are one element more on the right and left side because this becomes
handy in using some algorithms that intentionally might get out of
bounds. Such a design should make the code easier to write. Well, do
you call that *right*? I would not.

>      (No main stream language exists YET that will allow
>       static analysis, thus eliminating run time checks.)

It might be not possible at all, if you need data from a given
environment or user out of the computer's small world.

>10.) Just because I like having lists of ten! 8)
>
>And you thought you were SOOOOO RIGHT.  Turns out you were only MOSTLY
>RIGHT!  SO THERE!  8)

Well, I don't *think* I'm right. I *know* I am. 8-) ;-)


Vinzent.

Re: Look what I caught! was re:Ada paper critic

[Darren New]

Vinzent Hoefler wrote:
> No. Its not a long time ago (was it in c.l.a.?) I read that C arrays
> are one element more on the right and left side because this becomes
> handy in using some algorithms that intentionally might get out of
> bounds. 

You're probably thinking of what I said, which was that a pointer into an
array is allowed to be increased to point off the end of the array by one
element, but you can't access it. Not because it might intentionally get out
of bounds, but because you do things like

while (*s++ == 0) ;

meaning that you never *reference* the pointer when it's out of bounds, but
you do point out of bounds. You don't necessarily get to point two out of
bounds, tho.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Look what I caught! was re:Ada paper critic

[Hyman Rosen]

Darren New wrote:
> You're probably thinking of what I said, which was that a pointer into an
> array is allowed to be increased to point off the end of the array by one
> element, but you can't access it. You don't necessarily get to point two
 > out of bounds, tho.

Right, only one past the end is permitted. As you say, this is used in
algorithms which march a pointer through an array and find it convenient
to post-increment, as in the traditional copying loop of strcpy:

	strcpy(char *to, char *from) { while (*to++ = *from++); }

In C++, this approach has been adopted by the STL algorithms. Whenever
they need to operate on a sequence of elements, that sequence is specified
by a half-open range of iterators, [begin, end), which mirrors the pointer
approach, and in fact pointers are valid iterators, so that STL algorithms
can be used on simple arrays. For example, copy is

	template<typename T> T copy(T begin, T end, T to)
	{ while (begin != end) *to++ = *begin++; return to; }

Re: Look what I caught! was re:Ada paper critic

[Vinzent Hoefler]

Darren New <dnew@san.rr.com> wrote:

>Vinzent Hoefler wrote:
>> No. Its not a long time ago (was it in c.l.a.?) I read that C arrays
>> are one element more on the right and left side because this becomes
>> handy in using some algorithms that intentionally might get out of
>> bounds. 
>
>You're probably thinking of what I said, which was that a pointer into an
>array is allowed to be increased to point off the end of the array by one
>element, but you can't access it.

Ok. Thanks for clarifying that. I was quite confused, because hell a
lot of C code (including the little pieces I already did) wouldn't
have worked at all then.


Vinzent.

Re: Look what I caught! was re:Ada paper critic

[Marin David Condic]

Have you ever heard of *anyone* being fired for violating a coding standard?
:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Vinzent Hoefler" <JeLlyFish.software@gmx.net> wrote in message
news:3d0e5750_2@news.bluewin.ch...
>
> And get "use"d to be fired. ;)
>

Re: Look what I caught! was re:Ada paper critic

[Vinzent Hoefler]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>Have you ever heard of *anyone* being fired for violating a coding standard?
>:-)

Mmh. Good point. More it seems, permanently and strictly violating a
coding standard tends to become the new coding standard after all...
:-D


Vin"Yes, I *hate* Hungarian notation. It's braindead."zent.

Re: Look what I caught! was re:Ada paper critic

[Kevin Cline]

Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3d0e5750_2@news.bluewin.ch>...
 
> I got another impression from most Ada program(mer)s I've seen. My
> personal experience shows me that the *hurry, hurry fast, if it works,
> I'll never look at it again* approach is more wide-spread in other
> languages.

Other languages are used by for-profit companies in competitive markets.

Ada tends to be used for long term one-of-a-kind development projects
being paid for by governmental agencies.
>...
> Well, considering how many of those few seconds I already hang around
> with C++ code to see how this or that function is declared and if it
> changes something, this sounds funny. In C++ I can even overload the
> [] operator, this changes the whole world.

You can overload the function-call operator too.  Both are very useful
in the right situation.

>...
> No. Its not a long time ago (was it in c.l.a.?) I read that C arrays
> are one element more on the right and left side because this becomes
> handy in using some algorithms that intentionally might get out of
> bounds. Such a design should make the code easier to write. Well, do
> you call that *right*? I would not.

Knowing so little about C and C++ I would think you would be
more reluctant to criticize them.  A C array does not contain
"one element more" on either side.  The standard allows setting
a pointer to the next element after the end of an array, but
such a pointer can not be dereferenced.

Re: Look what I caught! was re:Ada paper critic

[Vinzent Hoefler]

kcline17@hotmail.com (Kevin Cline) wrote:

>Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3d0e5750_2@news.bluewin.ch>...
> 
>> I got another impression from most Ada program(mer)s I've seen. My
>> personal experience shows me that the *hurry, hurry fast, if it works,
>> I'll never look at it again* approach is more wide-spread in other
>> languages.
>
>Other languages are used by for-profit companies in competitive markets.

Well, might be.

>Ada tends to be used for long term one-of-a-kind development projects
>being paid for by governmental agencies.

Well. I have not seen a lot of Ada code from such projects now. I can
only refer to the things I have seen and for me Ada looked
substantially better even if written by a non-professional than the
average C/C++ code from experienced people who should know much better
how to write readable code.

So *for me* it seems that the Ada-language seems to encourage people
of using a more readable style.

>> Well, considering how many of those few seconds I already hang around
>> with C++ code to see how this or that function is declared and if it
>> changes something, this sounds funny. In C++ I can even overload the
>> [] operator, this changes the whole world.
>
>You can overload the function-call operator too.  Both are very useful
>in the right situation.

ACK. So "()" vs. "[]" changes nothing. You will *always* have to take
a look at the declaration if you want to know for sure.

>> No. Its not a long time ago (was it in c.l.a.?) I read that C arrays
>> are one element more on the right and left side because this becomes
>> handy in using some algorithms that intentionally might get out of
>> bounds. Such a design should make the code easier to write. Well, do
>> you call that *right*? I would not.
>
>Knowing so little about C and C++ I would think you would be
>more reluctant to criticize them.

*grr* Shall I be able to repeat the C++ language reference out of my
mind before qualifying to state about the language? IMO, I have done
enough things in C and even C++ that I consider me being able to spot
the points that made *my* life harder with that language. I have heard
a lot of silly things about Ada from people who didn't even ever seen
Ada code and I've seen a lot of silly things in C that turned out to
be true. So please let me the right to state things that might not be
correct about a language I'm quite used to without ever falling in
love with it.

The thing is I do substantially better code in C since I've did my
first readings about Ada. Especially after reading the Q&S. Is there
anything comparable for C++ available for free? I know a lot of people
I would give it to...

>  A C array does not contain
>"one element more" on either side.  The standard allows setting
>a pointer to the next element after the end of an array, but
>such a pointer can not be dereferenced.

Well. It *can*. With undefined results. These "undefined results" I
have come over too often really pissed me off. And hence, it was not
*my* code. I just had to *maintain* it.


Vin"Ok, I'll get a little drink from my "Buffer Overflow" glass from
thinkgeek now. :-)"zent.

Re: Look what I caught! was re:Ada paper critic

[Wes Groleau]

> >  A C array does not contain
> >"one element more" on either side.  The standard allows setting
> >a pointer to the next element after the end of an array, but
> >such a pointer can not be dereferenced.

The standard does?  But most compilers ignore this, right?

Or is the some other explanation why it's so @#$%@#$% easy
to get a segmentation fault in C ?

Or did I completely misunderstand the statement?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Look what I caught! was re:Ada paper critic

[Darren New]

Wes Groleau wrote:
> 
> > >  A C array does not contain
> > >"one element more" on either side.  The standard allows setting
> > >a pointer to the next element after the end of an array, but
> > >such a pointer can not be dereferenced.
> 
> The standard does?  But most compilers ignore this, right?

The pointer can be dereferenced, of course, but it's "undefined behavior".
In other words, the programmer shouldn't do this, because the compiler is
allowed to enforce that you don't. Of course, most C compilers implement
pointers as raw addresses, so it's generally hard to make sure you're doing
the Right Thing that way.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Look what I caught! was re:Ada paper critic

[Wes Groleau]

> > > >"one element more" on either side.  The standard allows setting
> > > >a pointer to the next element after the end of an array, but
> > > >such a pointer can not be dereferenced.
> >
> > The standard does?  But most compilers ignore this, right?
> 
> The pointer can be dereferenced, of course, but it's "undefined behavior".

> Actually, what the C standard says is that if you have a pointer just after
> the end of an array, then the result of dereferencing that pointer is
> "unpredictable". Such dereferences can cause segmentation fault, trash some

That's what I thought.  The original claim was in error.
The correct statement is "such a pointer should not be dereferenced"

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Look what I caught! was re:Ada paper critic

[Darren New]

Wes Groleau wrote:
> That's what I thought.  The original claim was in error.
> The correct statement is "such a pointer should not be dereferenced"

Well, alternately, "on some compilers, such a pointer will flag a
programming error if dereferenced". I've used (for example) C interpreters
that carried around more than just raw addresses, for obvious reasons.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Look what I caught! was re:Ada paper critic

[Frank J. Lhota]

Actually, what the C standard says is that if you have a pointer just after
the end of an array, then the result of dereferencing that pointer is
"unpredictable". Such dereferences can cause segmentation fault, trash some
other memory, or do nothing at all. Any of these outcomes is consistent with
the standard. It's up to the programmer to avoid this behaviour.

Really, all the standard requires is that the compiler can generate a
pointer (not a corresponding object!) just past the right end of the array.
In others words, if we define

    PLANET solar_system[ 9 ];
    PLANET *past_pluto = solar_system + 9;

Then all the standard requires is that past_pluto can be computed, and that
it will compare correctly with pointers to other elements in solar_system,
e.g.

    ( past_pluto > solar_system + 0 ) &&
    ( past_pluto > solar_system + 1 ) &&
    ( past_pluto > solar_system + 2 ) &&
    ...
    ( past_pluto > solar_system + 8 )

That's all that's required. Access *past_pluto, and you're on your own.

Also, the standard only requires a valid pointer to the point just after the
end of an array; no similar rule applies to the beginning of the array. For
example, if you declare

    PLANET *before_mercury = solar_system - 1;

then the standard does NOT require that before_mercury compare meaningfully
with the addresses of the solar_system elements. Of course, the result of
dereferencing before_mercury is unpredictable.

Re: Look what I caught! was re:Ada paper critic

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> Also, the standard only requires a valid pointer to the point just after the
> end of an array; no similar rule applies to the beginning of the array. For
> example, if you declare
> 
>     PLANET *before_mercury = solar_system - 1;
> 
> then the standard does NOT require that before_mercury compare meaningfully
> with the addresses of the solar_system elements.

Really?  I thought the above was OK.  The STL of C++ depends heavily on
this idiom.  Is this a difference between C and C++?  If so, what's the
rationale (in C)?

- Bob

Re: Look what I caught! was re:Ada paper critic

[Hyman Rosen]

Robert A Duff wrote:
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
>>Also, the standard only requires a valid pointer to the point just after the
>>end of an array; no similar rule applies to the beginning of the array. For
>>example, if you declare
>>    PLANET *before_mercury = solar_system - 1;
>>then the standard does NOT require that before_mercury compare meaningfully
>>with the addresses of the solar_system elements.
> 
> Really?  I thought the above was OK.  The STL of C++ depends heavily on
> this idiom.  Is this a difference between C and C++?  If so, what's the
> rationale (in C)?

It's not OK, and the STL never uses this idiom. The
STL uses half-open intervals [begin,end) where the
begin iterator points to the start of the sequence
being manipulated, and the end iterator points to
one past the end of the sequence being manipulated,
and the canonical STL algorithm loop is

	while (begin != end) { operate_on(*begin++); }

The "one past the end" pointer can be logical instead
of physical, depending on the underlying container, but
the algorithms don't care. For example, suppose I wish
to copy a sequnce of integers from standard input into
a vector. I can do it this way

#include <iostream>
#include <vector>
#include <iterator>
#include <algorithm>
using namespace std;
int main()
{
	vector<int> v;
	copy(
	/* begin */ istream_iterator<int>(cin),
	/* end   */ istream_iterator<int>(),
	/* to    */ back_insert_iterator(v)
	);
}

The istream_iterator<int>() reprsents a logical past-the-end
iterator for reading from an input stream. A real input stream
iterator will compare equal to that one once it has tried to
read past the end-of-file on the input stream.

The code one writes for something like copy (copy itself is
part of the standard library) is completely ignorant of these
shenaningans. It looks like a simple pointer loop -

	template<typename II, typename OI>
	OI copy(II begin, II end, OI to)
	{
		while (begin != end)
			*to++ = *begin++;
		return to;
	}

The various iterator types have overloaded operators which
implement their behavior. For example, incrementing an
istream_iterator causes it to read the next object from
the input stream. Dereferencing the iterator returns that
object.

Re: Look what I caught! was re:Ada paper critic

[Matthew Heaney]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3D10E366.2010303@mail.com...
> Robert A Duff wrote:
> >
> > Really?  I thought the above was OK.  The STL of C++ depends heavily on
> > this idiom.  Is this a difference between C and C++?  If so, what's the
> > rationale (in C)?
>
> It's not OK, and the STL never uses this idiom. The
> STL uses half-open intervals [begin,end) where the
> begin iterator points to the start of the sequence
> being manipulated, and the end iterator points to
> one past the end of the sequence being manipulated,
> and the canonical STL algorithm loop is
>
> while (begin != end) { operate_on(*begin++); }

STL iterators are a generalization of normal pointers.

It is true that you can't address the element "before" the start of the
array, because the compiler can allocate the array at the base of a segment,
which doesn't have a "before" address.

To iterate in reverse, and use a sentinel allowing you to fall off the
beginning of the sequence to terminate the iteration, the STL uses a reverse
iterator which is implemented as a wrapper around a normal, forward iterator
(which you can always recover using the base() member function of the
reverse iterator class).

You don't really use roaming pointers in Ada; rather, you use an array
object and a separate index.  You never index the array prior to the first
element of the array (nor past the last element, for that matter), but of
course the value of the index can have a value the preceeds the T'First of
the array.

This has precedent in Ada; for example, you often see string searches
implemented this way:

   function Find (S : String; C : Character) return Natural;

Here, the function returns the value 0 to indicate that the character C
wasn't found in array (string) S.

In Charles, I have generalized the STL iterator behavior, such that you're
allowed to have an iterator that designates the element "before" the start
of the sequence.

The Front iterator value has the sense of Index_Subtype'Pred
(Array_Object'First), and the Back iterator value has the sense of
Index_Subtype'Succ (Array_Object'Last).  The First and Last iterators have
their traditional sense.

The complete mapping is:

   Charles      STL
   --------      ---
   Front        <no analog>
   First          begin()
   Last          iter = end(), --iter;
   Back        end()

The loop above can be written as:

declare
   I : Iterator_Type := First (C);
   J : constant Iterator_Type := Back (C);
begin
   while I /= J loop
      E := Element (I);
     <do something with E>
      I := Succ (I);
   end loop;
end;

Of course, it's often simpler to just use a passive iterator, similer to an
STL algorithm:

declare
   procedure Process (E : T) is
   begin
      <do something with E>
   end;

   procedure Iterate is new Generic_Select_Elements (Process);
begin
   Iterate (First (C), Back (C));
end;

In C++, (non-const) iterators return T&.  You don't have reference types in
Ada, but you can accomplish something very similar using access types.  All
the containers in Charles have a generic operation for returning an access
type designating the container element (which are always aliased).

For example, given a subprogram like this:

procedure Do_Something (E : in out T);

then you can do this:

type T_Access is access all T;
for T_Access'Storage_Size use 0;

function To_Access is new Generic_Element (T_Access);

I : Iterator_Type := First (C);
J : constant Iterator_Type := Back (C);

while I /= J loop
   declare
      E : Element_Type renames To_Access (I).all;
   begin
      Do_Something (E);
   end;

   I := Succ (I);
end loop;

which is exactly analogous to this STL fragment:

void do_something(t& e);

iterator i = c.begin();
const iterator j = c.end();

while (i != j)
{
   t& e = *i;
   do_something(e);
   ++i;
}


> The "one past the end" pointer can be logical instead
> of physical, depending on the underlying container, but
> the algorithms don't care.

That's also true in Charles.  For example, the copy algorithm spec looks
like this:

generic

   type Source_Type is private;

   type Target_Type (<>) is limited private;

   with procedure Assign
     (Target : in Target_Type;
      Source : in Source_Type) is <>;

   with procedure Succ (Source : in out Source_Type) is <>;

   with procedure Succ (Target : in out Target_Type) is <>;

   with function "=" (L, R : Source_Type) return Boolean is <>;

procedure Charles.Algorithms.Generic_Copy
  (First, Back : in     Source_Type;
   Target        : in out Target_Type);

You don't have automatic instantiation in Ada as you have in C++, but you
don't really need it.  An instantiation of the algorithm above would look
like this:

declare
   procedure Assign (T : P1.Iterator_Type; S : P2.Iterator_Type) is
   begin
      Replace_Element (T, By => Element (S));
   end;

   procedure Copy is
      new Generic_Copy
        (P2.Iterator_Type;
         P1.Iterator_Type);  --everything else defaults

   I : P1.Iterator_Type := First (C2);
begin
   ...
   Copy (First (C1), Back (C1), I);
end;

This is why reverse iterators aren't needed, either.  All you need to do to
iterate over the source in reverse is supply a different function as the
generic actual:

declare
   procedure Assign (T : P1.Iterator_Type; S : P2.Iterator_Type) is
   begin
      Replace_Element (T, By => Element (S));
   end;

   procedure Copy is
     new Generic_Copy
      (P2.Iterator_Type;
       P1.Iterator_Type,
       Assign,
       Pred);   -- this line is different

   I : P1.Iterator_Type := First (C2);
begin
   ...
   Copy (Last (C1), Front (C1), I);   --this is dif't too
end;

Of course, it's usually simpler to just use a passive iterator:

declare
   I : P1.Iterator_Type := First (C2);

   procedure Process (E : T) is
   begin
      Replace_Element (I, By => E);
      I := Succ (I);
   end;

   procedure Iterate is
     new P2.Generic_Reverse_Select_Elements (Process);
begin
   Iterate (First (C1), Back (C1));
end;

You can even iterate over the target container in reverse using this
technique:

declare
   I : P1.Iterator_Type := Last (C2);

   procedure Process (E : T) is
   begin
      Replace_Element (I, By => E);
      I := Pred (I);
   end;

   procedure Iterate is
      new P2.Generic_Select_Elements (Process);
begin
   Iterate (First (C1), Back (C1));
end;


> The code one writes for something like copy (copy itself is
> part of the standard library) is completely ignorant of these
> shenaningans. It looks like a simple pointer loop -
>
> template<typename II, typename OI>
> OI copy(II begin, II end, OI to)
> {
> while (begin != end)
> *to++ = *begin++;
> return to;
> }


The copy algorithm in Charles is implemented this way:

procedure Charles.Algorithms.Generic_Copy
  (First, Back : in     Source_Type;
   Target      : in out Target_Type) is

   Source : Source_Type := First;
begin
   while Source /= Back loop

      Assign (Target, Source);

      Succ (Source);

      Succ (Target);

   end loop;
end Charles.Algorithms.Generic_Copy;

which is basically the same as in the C++ example above.

You can get the latest version of Charles at my home page:

http://home.earthlink.net/~matthewjheaney/charles-20020923.zip

I'll probably submit a paper to the Ada-Europe conference about Charles.

Re: Look what I caught! was re:Ada paper critic

[Robert A Duff]

Wes Groleau <wesgroleau@despammed.com> writes:

> > >  A C array does not contain
> > >"one element more" on either side.  The standard allows setting
> > >a pointer to the next element after the end of an array, but
> > >such a pointer can not be dereferenced.
> 
> The standard does?  But most compilers ignore this, right?
> 
> Or is the some other explanation why it's so @#$%@#$% easy
> to get a segmentation fault in C ?

I think the statement that the standard "can not be dereferenced" is
correct, if you interpret it to mean "any program that does so does not
conform to the C standard".  The reason it's "so @#$%@#$% easy..." is
that the C standard does not require compilers to detect programs that
violate the C standard in this way (and many other ways).  The Fortran
and Pascal standards take the same attitude: compilers are not required
to detect non-conforming programs.  The Ada standard of course requires
such detection in most cases, which is a huge advantage of Ada.

- Bob

Re: Look what I caught! was re:Ada paper critic

[Ted Dennison]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message news:<mailman.1024335422.31035.comp.lang.ada@ada.eu.org>...
> Here's what I caught on my troll:
> 
> 1.) People who missed the point (maybe intentionally) of the big
>     chain of package names you end up with in some Ada packages.
> 
> The point here is if your company has a policy against using
> "uses" in their code, then you have to:
> 
>    A.) Use a renames
>    B.) Use the fully specified name.
>    C.) Ignore the standard and use use.


This honestly sounds like someone who hasn't used the language a whole
lot. The idiom one should adopt in "no use" code is to make the
package name part of the object's name, rather than tacking on extra
stuff to an object's name to differentiate it from objects in other
packages (the typical C approach). If you choose your names wisely,
then you loose nothing by using the fully-specified object name
(perhaps some "_"s change to "."s).

One of the reasons a lot of newbies don't get this for a while is that
the ARM sets a really bad example with its object naming. And yes, the
result is unspeakably ugly. Shame on the ARM writers.

> 3.) Many people in this group seem to have a "write the code
>     and never look at it again" attitude.  Writing code is only

A week ago I would have disagreed, but today I think you are right.
However, we try to educate them when they pop up. :-)

>     This brings up my discussion on why not being able to tell
>     an array from a function is a problem.  From the writing

An array is just a built-in mapping function. There's no reason you
need to know how the mapping function is implemented, unless you *do*
want to check the implementation for errors (in which case you'd have
to check anyway).


>     of the code its nice to be able to change your mind on
>     the implementation of a function to array.  But then again
>     why are you changing something like this?  This is an

  o Because some new factor arose that made the mapping dynamic
instead of static. (Perhaps in version 2, the customer requested more
control over the mapping).
  o Because another factor has been added that makes it not a simple
lookup (but you can perhaps default out all but one of the parameters,
leaving most user's code untouched).
  o Because you are using extreme programming techniques, so you start
with a simple array lookup to get things running, then later replace
it with the complicated mapping function.


> 8.) People seem to miss the point that no matter how great the
>     language is, if it has crappy compilers, crappy debugging
>     and a crappy IDE's then its going to be a interesting blip
>     on the software radar screen that fades out fast.  The

Then why is Microsoft still in the compiler business? Their C++
compiler totally sucks (worst error messages ever). Their IDE might be
somewhat nice now, but it sure didn't start out that way.