comp.lang.ada
 help / color / mirror / Atom feed
From: mbk@inls1.ucsd.edu (Matt Kennel)
Subject: Re: Memory overwrite?
Date: 1 Feb 1995 23:00:49 GMT
Date: 1995-02-01T23:00:49+00:00	[thread overview]
Message-ID: <3gp3r1$e0m@network.ucsd.edu> (raw)
In-Reply-To: D382Au.AB7@world.std.com

Robert A Duff (bobduff@world.std.com) wrote:
: In article <3gehlo$i05@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
: >But just the fact that you are using two different I's does not seem
: >to warrant a warning to me!

: This mistake is so common, I think it deserves a warning.  You've got
: nothing better to do, right?  ;-)

: If you have a variable that is never initialized (whether it's used or
: not), and an inner for loop index of the same name, that's when I would
: give a warning about not needing to declare the for loop index.  Of
: course, a variable never initialized (or used) might deserve a warning
: anyway, but if you just say "variable I never used", you will confuse
: someone who thought you needed to declare I outside the for loop.  To
: me, it seems friendy to give a more specific message in the for-loop
: case.

This is gettting a little off topic but...

Sather has an interesting take on this issue:  you can declare and
initialize variables anywhere an assignment is legal, but scopes are NOT
nested.  So if you try to do it again to the same identifier it will
complain and not allow it.

It allows you to "Put your declaration close to the use" (and thus lower the
chance of uninitialized variables, and minimize confusion over things
declared before there is any logical need or use for them) but lower the
chance of "calling different things the same name adding to confusion" that
a declaration close to use with nested scopes would often imply.

example:

loop
	e ::= collection.elt!;	-- return elements of collection in sequence.
	process(e);

-- a nested loop:
	loop
--	     e ::= something_else.elt!;	-- NOT LEGAL, redeclares "e".
	end;
end;


----

The "::=" means "declare static type of variable on left to be the
same as static type of right side, and then perform the assignment.

This is useful in situations like the above. You don't really
want to denote the type of "e".  All that you care is that "e" is compatible
with the return type of the "elt!" call so that it can hold/reference
a legal object.

What's wrong with declaring it explicitly?  Nothing. {You could have
said e:TYPE:= right_hand_side just as easily}.  Just that when you're
in the early stages of development where the actual types that will be
returned are undergoing big changes as the design evolves you don't 
have to spend time just mechanically changing the names of types in
a billion places.

: - Bob


cheers
Matt

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



  reply	other threads:[~1995-02-01 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-01-26 13:05 Memory overwrite? R.A.L Williams
1995-01-27 14:01 ` Robert A Duff
1995-01-28 22:49   ` Robert Dewar
1995-01-30 14:16     ` Robert A Duff
1995-02-01 23:00       ` Matt Kennel [this message]
1995-01-28  5:54 ` Robert Dewar
  -- strict thread matches above, loose matches on Subject: below --
1995-01-24 12:47 R.A.L Williams
1995-01-25 16:31 ` Robert A Duff
1995-01-25 19:01 ` Tucker Taft
1995-01-25 21:24 ` Robert Dewar
1995-01-30 17:06 ` Theodore E. Dennison
1995-02-01 12:25   ` Robert Dewar
1995-01-13  8:35 Rick Wouters
     [not found] ` <3fe5cp$fnq@theopolis.orl.mmc.com>
1995-01-18 18:20   ` Mark A Biggar
1995-01-20  5:19     ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox