scope and/or parameters (beginner)

scope and/or parameters (beginner)

[fluffy_pink]

Hi,

My problem has to do with using the proper types of 
parameters and the distinctions between the formal and 
the actual ones, all of this in the context of wanting 
to pass a value two (2) levels down and then one (1) 
level back up. (Passing a value from a sub-program to 
one of its constituent sub-program is what I call 
passing that value one level down.) 

Here is what I have that doesn't work:
-----------------------------------------------------------
PROCEDURE One_Procedure
	   (	Second_Variable :	IN   The_Type;
		Third_Variable :	OUT  The_Type ) IS

--  types & sub-types: none ===========================
--  sub-programs ======================================

	PROCEDURE Internal_Procedure                  
		   (	One_Variable :		IN OUT  The_Type ) IS
	BEGIN
		One_Variable := One_Variable + A_Constant;
		-- What goes on here is not important.  The point
		-- Is that I am (want to) modify the value of
		-- "One_Variable" and bring its new value to
		-- "One_Procedure", as an IN OUT should be used.
	END Internal_Procedure;              

--  variables: none ===================================

BEGIN -- One_Procedure

	Internal_Procedure ( One_Variable => (QUESTION) );
	Third_Variable = Second_Variable + Another_Constant;
	-- More stuff goes here using "Third_Variable".
    
END One_Procedure;
-----------------------------------------------------------

In my main program I have declared the following variables:

	Var_2, Var_3 : The_Type;

In my main program I am calling "One_Proc�dure" with:

   One_Procedure
	(Second_Variable => Var_2, Third_Variable => Var_3);

If for "(QUESTION)" I use "Second_Variable" the compiler tells me that
for an OUT or an IN OUT I must have an actual parameter that **is a
variable***.  I don't understand why it tells me this.  Obviously, if
I use "Var_2", then it says that it cannot see "Var_2"; that I think I
understand.

How can I pass the value of Var_2 from my main program, into
One_Procedure, and then from One_Procedure into Internal_Procedure,
and then to make it come back out modified (IN OUT) so that it will
end up in One_Proc�dure ?  I don't want to use the modified value of
Var_2 (modified by Internal_Procedure) at the main program level; I
want to use it only in One_Proc�dure.

Thanks and forgive me if it's not clear.  I really tried.


Marc
--
What I really am is "fluffy", no "_dong",
no "_puff", no "_woo", no  nothing, just plain fluffy.

Re: scope and/or parameters (beginner)

[Matthew Heaney]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]

fluffy_pink@dsuper.net writes:

> Here is what I have that doesn't work:
> -----------------------------------------------------------
> PROCEDURE One_Procedure
> 	   (	Second_Variable :	IN   The_Type;
> 		Third_Variable :	OUT  The_Type ) IS
> 
> --  types & sub-types: none ===========================
> --  sub-programs ======================================
> 
> 	PROCEDURE Internal_Procedure                  
> 		   (	One_Variable :		IN OUT  The_Type ) IS
> 	BEGIN
> 		One_Variable := One_Variable + A_Constant;
> 		-- What goes on here is not important.  The point
> 		-- Is that I am (want to) modify the value of
> 		-- "One_Variable" and bring its new value to
> 		-- "One_Procedure", as an IN OUT should be used.
> 	END Internal_Procedure;              
> 
> --  variables: none ===================================
> 
> BEGIN -- One_Procedure
> 
> 	Internal_Procedure ( One_Variable => (QUESTION) );
> 	Third_Variable = Second_Variable + Another_Constant;
> 	-- More stuff goes here using "Third_Variable".
>     
> END One_Procedure;
> -----------------------------------------------------------
> 
> In my main program I have declared the following variables:
> 
> 	Var_2, Var_3 : The_Type;
> 
> In my main program I am calling "One_Proc�dure" with:
> 
>    One_Procedure
> 	(Second_Variable => Var_2, Third_Variable => Var_3);
> 
> If for "(QUESTION)" I use "Second_Variable" the compiler tells me that
> for an OUT or an IN OUT I must have an actual parameter that **is a
> variable***.  I don't understand why it tells me this.  Obviously, if
> I use "Var_2", then it says that it cannot see "Var_2"; that I think I
> understand.

The problem is that anywhere inside One_Procedure, the object
Second_Variable is a constant, because it's an in-mode parameter.

Yes, the object Var_2 is a variable, but One_Procedure doesn't know
this.  One_Procedure is looking at Var_2 via the formal parameter
Second_Variable, which is in-mode, and therefore is constant.


 
> How can I pass the value of Var_2 from my main program, into
> One_Procedure, and then from One_Procedure into Internal_Procedure,
> and then to make it come back out modified (IN OUT) so that it will
> end up in One_Proc�dure ?

Make the formal parameter Second_Variable mode in out, instead of mode
in.

Here's a little formula for formal parameter modes:

in      = object is treated as a constant
in out  = object is treated as a variable


> I don't want to use the modified value of Var_2 (modified by
> Internal_Procedure) at the main program level; I want to use it only
> in One_Proc�dure.

Then you have to make a local copy.
 

Re: scope and/or parameters (beginner)

[Corey Ashford]

fluffy_pink@dsuper.net wrote:
[snip]
> 
> If for "(QUESTION)" I use "Second_Variable" the compiler tells me that
> for an OUT or an IN OUT I must have an actual parameter that **is a
> variable***.  I don't understand why it tells me this.

"IN" parameters are considered read-only.  You've tried to pass it to
a procedure which may attempt to change its value - something that
isn't allowed to a read-only variable.  Treat "IN" parameters as
constants that are defined when the subprogram is invoked.

[snip]
> 
> How can I pass the value of Var_2 from my main program, into
> One_Procedure, and then from One_Procedure into Internal_Procedure,
> and then to make it come back out modified (IN OUT) so that it will
> end up in One_Proc�dure ?  I don't want to use the modified value of
> Var_2 (modified by Internal_Procedure) at the main program level; I
> want to use it only in One_Proc�dure.

[snip]

Well, you could change the definition of One_prog so that its
Second_Variable is of type "IN OUT The_Type", instead of just IN.  Then
you could call Inner_Procedure legally with Second_Variable.



- Corey

Re: scope and/or parameters (beginner)

[fluffy_doo]

On Mon, 05 Apr 1999 05:04:25 +0000, Corey Ashford 

> ...
>"IN" parameters are considered read-only.  You've tried to pass it to
>a procedure which may attempt to change its value - something that
>isn't allowed to a read-only variable.  Treat "IN" parameters as
>constants that are defined when the subprogram is invoked.
>
>[snip]

>Well, you could change the definition of One_prog so that its
>Second_Variable is of type "IN OUT The_Type", instead of just IN.  Then
>you could call Inner_Procedure legally with Second_Variable.
>
>- Corey

But that is part of my main objective: to have it as "IN" in the first
subprogram (One_Procedure), and then as "IN OUT" for the subprogram
one level below (Internal_Procedure).  It's just an exercise I've made
for myself to help me better understand the formal/actual parameter
manipulation.  I want Var_2 to remain unchanged at the main program
level.  Let's say I want to use that variable (its original value)
later in the program, in a subprogram called directly from the main
program, which is why I insist on having an "IN" parameter in
One_Procedure.

It looks like I am forced to declare a *new variable* in One_Procedure
to which I will give the value of Var_2 (Ex: modif_Var_2 := Var_2;),
and then send modif_Var_2 in Internal_Procedure to be modified and
brought back via its "IN OUT" parameter.

This exercise, in part learning to use "named" instead of "positional"
association, has allowed me to realize the following, I think :

	The fact that a sub-program is declared INSIDE another, as
	opposed to OUTSIDE of it, makes no difference from the point of
	view of the compiler.  As long as any call to a sub-program is
	made AFTER its declaration it is treated exactly the same way.

TRUE / FALSE ?

Thanks again.  How come the people in this group are so helpful and
straight forward, much more than in other groups I've frequented
before ?  Is this part of some organized campain with the purpose of
popularizing Ada ?  It is a if the people here were paid to do it and
truly enjoyed it on top of it !


Marc Galipeau
--
What I really am is "fluffy", no "_dong",
no "_puff", no "_woo", no  nothing, just plain fluffy.

Re: scope and/or parameters (beginner)

[Matthew Heaney]

fluffy_doo@dsuper.net writes:

> It looks like I am forced to declare a *new variable* in One_Procedure
> to which I will give the value of Var_2 (Ex: modif_Var_2 := Var_2;),
> and then send modif_Var_2 in Internal_Procedure to be modified and
> brought back via its "IN OUT" parameter.

Yes, that is what you have to do.

There is one advanced technique you can use to modify an in parameter,
and that is to use package System.Address_To_Access_Conversions.  That
is how the function Random is implemented for the random number
generators.

However, I'm telling you this so you know how to do it, in case you
happen to need it -- which should only be in rare circumstances.

There are a few examples of how to use this package in the ACM patterns
archive, described below.  (When using the archive, use the search
facility to perform a substring search, say, for the string
"address_to_access_conv".)


> Thanks again.  How come the people in this group are so helpful and
> straight forward, much more than in other groups I've frequented
> before ?  Is this part of some organized campain with the purpose of
> popularizing Ada ?  It is a if the people here were paid to do it and
> truly enjoyed it on top of it !

That about sums it up!


If you want more examples of Ada95 programming, then you can browse the
ACM patterns archive.

<http://www.acm.org/archives/patterns.html>
<mailto:patterns@acm.org>

You can subscribe to that list by sending a message (body)

subscribe patterns <your name>

to the ACM mailing list server.

<mailto:listserv@acm.org>

Re: scope and/or parameters (beginner)

[czgrr]

In article <370b0c99.1137352783@news.dsuper.net>,
  fluffy_doo@dsuper.net wrote:
> On Mon, 05 Apr 1999 05:04:25 +0000, Corey Ashford
[snip]
> This exercise, in part learning to use "named" instead of "positional"
> association, has allowed me to realize the following, I think :
>
> 	The fact that a sub-program is declared INSIDE another, as
> 	opposed to OUTSIDE of it, makes no difference from the point of
> 	view of the compiler.  As long as any call to a sub-program is
> 	made AFTER its declaration it is treated exactly the same way.
>
> TRUE / FALSE ?
The short answer:

For the usage you gave in your original message, yes it makes no difference.


The long answer, part 1:

It does make one important difference. In the same way as local variables are
not accessible outside the routine they are declared in, declaring a routine
inside another limits the scope (accessibility) of that routine.

An example. In the message you originally wrote, you make a call:

>    One_Procedure
> 	(Second_Variable => Var_2, Third_Variable => Var_3);

but if you tried to make the following call *in the same place*:

>    Internal_Procedure ( One_Variable => Var_3 );

it would not compile. If you wanted "Internal_Procedure" to be available in
the same places as "One_Procedure", you would have to declare it outside
"One_Procedure".


The long answer, part 2:

This business about calling something after its declaration, strictly, is
true. But in the sense I felt you were talking about it here, you could have
structured your code this way...

> PROCEDURE One_Procedure
> 	   (	Second_Variable :	IN   The_Type;
> 		Third_Variable :	OUT  The_Type ) IS
> --  sub-programs: none ================================
> BEGIN -- One_Procedure
> 	Internal_Procedure ( One_Variable => (QUESTION) );
> END One_Procedure;
>
> PROCEDURE Internal_Procedure
> 	( One_Variable : IN OUT  The_Type ) IS
> BEGIN
> 	One_Variable := One_Variable + A_Constant;
> END Internal_Procedure;

and still have been able to get this to compile. What you do is to put a
declaration for "Internal_Procedure" before that for "One_Procedure", of this
form:

> PROCEDURE Internal_Procedure
> 	( One_Variable : IN OUT  The_Type ) ;  -- NOTE the semi-colon

Then you can call "Internal_Procedure" at any point after this, irrespective
of where the actual code for it lies.

Of course, if you have written specs and bodies, this is exactly the same as a
declaration in the spec - you can think of a spec as coming "before" anything
in the body, and so you can call anything in a package's spec from anywhere
within that package.

Phew! Some more things to play with, eh?

HTH, czgrr.

--
My opinions, etc, are not necessarily those of my employer.
They might not even be right.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[fluffy_puff]

On Thu, 08 Apr 1999 10:24:29 GMT, czgrr <czgrr@my-dejanews.com> wrote:

>> 	The fact that a sub-program is declared INSIDE another, as
>> 	opposed to OUTSIDE of it, makes no difference from the point of
>> 	view of the compiler.  As long as any call to a sub-program is
>> 	made AFTER its declaration it is treated exactly the same way.

>The short answer:

>For the usage you gave in your original message, yes it makes no difference.
>
>The long answer, part 1:
>
>It does make one important difference. In the same way as local variables are
>not accessible outside the routine they are declared in, declaring a routine
>inside another limits the scope (accessibility) of that routine.

I should have said "as long as the sub-program called is 'visible' or
'within the scope' instead of 'declared before'".

>The long answer, part 2:
>
>This business about calling something after its declaration, ...

>Of course, if you have written specs and bodies, this is exactly the same as a
>declaration in the spec - you can think of a spec as coming "before" anything
>in the body, and so you can call anything in a package's spec from anywhere
>within that package.
>
>Phew! Some more things to play with, eh?



>HTH, czgrr.

Thanks for part 2.  We haven't, in my course, written *specs* and
*bodies*.  I'll soon enough learn the .ADS/.SPC and .ADB/.BDY files
relations.  All I've done so far is register an .ADS file and an .ADB
file in a Project to use the sub-programs they contain (a version of
the ANSI "Screen" package). 


Thanks again.

Marc
--
What I really am is "fluffy", no "_dong",
no "_puff", no "_woo", no  nothing, just plain fluffy.

Re: scope and/or parameters (beginner)

[dennison]

In article <7ei04q$o$1@nnrp1.dejanews.com>,
  czgrr <czgrr@my-dejanews.com> wrote:
> In article <370b0c99.1137352783@news.dsuper.net>,
>   fluffy_doo@dsuper.net wrote:
> > On Mon, 05 Apr 1999 05:04:25 +0000, Corey Ashford

> > 	The fact that a sub-program is declared INSIDE another, as
> > 	opposed to OUTSIDE of it, makes no difference from the point of
> > 	view of the compiler.  As long as any call to a sub-program is
> > 	made AFTER its declaration it is treated exactly the same way.
> >
> > TRUE / FALSE ?

> It does make one important difference. In the same way as local variables are
> not accessible outside the routine they are declared in, declaring a routine
> inside another limits the scope (accessibility) of that routine.

It was claimed here at work that nested subroutines should be avoided due to
the elaboration overhead whenever the outer routine is called. That sounds a
bit shaky to me. Is there a situation where there would be a runtime impact
of nesting subroutines?


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <7et4vr$sdj$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> It was claimed here at work that nested subroutines
> should be avoided due to the elaboration overhead
> whenever the outer routine is called. That sounds a
> bit shaky to me. Is there a situation where there would
> be a runtime impact of nesting subroutines?

Sounds dubious as a general claim, but there is one
situation in which you will see overhead in GNAT (GNU C)
and that is if you create an access to (use & on) the
nested procedure. In this case a trampoline is built in
the stack, and the overhead can be significant.

In GNAT (but not GNU C) it would be possible to eliminate
this overhead by using fat pointers, and that is on our
optimizations-that-would-be-nice-to-so-sometime list. A
quite long list, which does however, get entries taken
off it frequently for actual implementation.

But note that this overhead is ONLY if the address is
taken, not in the normal case!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[czgrr]

In article <7et4vr$sdj$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
[snip]
> It was claimed here at work that nested subroutines should be avoided due to
> the elaboration overhead whenever the outer routine is called. That sounds a
> bit shaky to me. Is there a situation where there would be a runtime impact
> of nesting subroutines?
Forgetting about nested subroutines for the moment...

From what I remember about how compilers work, when you call a routine, stack
is allocated for parameters, local variables, and the like. Run-time info for
the calling routine is saved. Implicit initialisation might also occur here.
This happens every time you make a procedure or function call. The reverse
(less work, but still work) occurs when the routine finishes.

If the local variables were declared globally, the space is taken once only
when the program is first run, or in fact might even allocated in part of the
executable itself. No implicit initialisations. There is still an overhead in
calling a routine, but it is less.

So there is a definite difference between the time taken to call a routine
with and without local variables, albeit very small.

Now, back to nested subroutines...

I would guess that the elaboration process works the same way. Every time a
routine is called, any elaborations for local declarations take place.

When you first run an executable, there is work going on before reaching the
first line of the main program which elaborates everything which is global in
all the packages. But this happens only once. So making as much as you can be
global will improve overall run-time performance (which I am not recommending
in the general case, BTW), and the amount of saving (i.e. worth it, not worth
it) depends on exactly what your program is doing and how it is structured.

In the end, I expect it's down to the compiler. The optimisation stage of a
good compiler may well completely eliminate any overhead from nested
subroutines, and using PRAGMA INLINE can reduce general calling overheads.

Incidentally, it is *definitely* worse to have local procedure or package
declarations which come about using NEW. I always make them global to the
calling package. Put them in a low level, frequently-called routine and it can
kill your performance, and that's from experience.

--
My opinions, suggestions, etc, are not necessarily those of my employer.
They might not even be right. Use at your own risk.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <7euskv$d91$1@nnrp1.dejanews.com>,
  czgrr <czgrr@my-dejanews.com> wrote:

snipped:
<<quite a bit of stuff based on guesses from "what he
  remembers about how compilers work". Quite a bit is
  wrong or at least misleading.>>

One comment in particular:

> So there is a definite difference between the time taken
> to call a routine with and without local variables,
> albeit very small.

This is plain wrong on many machines. There is no
difference. Furthermore, just because you don't WRITE
any local variables does not mean there are none in the
generated code.

>
> Now, back to nested subroutines...
>
> I would guess that the elaboration process works the same
> way. Every time a routine is called, any elaborations for
> local declarations take place.

Why on earth is a guess required? Yes this is true, but it
is simply a function of the language in question (go look
at the GNU C definition, or the Ada or Pascal standards
for example).

> When you first run an executable, there is work going on
> before reaching the first line of the main program which
> elaborates everything which is global in
> all the packages.

What this elaboration involves is highly language
dependent. For example, in C, there is no runtime
activity at all from this elaboration.

> But this happens only once. So making
> as much as you can be
> global will improve overall run-time performance

This is in general quite wrong. Access to local variables
on the stack is generally much more efficient than access
to global variables on modern architectures.

> Incidentally, it is *definitely* worse to have local
> procedure or package
> declarations which come about using NEW. I always make
> them global to the
> calling package. Put them in a low level,
> frequently-called routine and it can
> kill your performance, and that's from experience.

No, it is from a misreading of experience, local procedures
cannot affect performance in this manner in any reasonable
implementation.

Indeed since you cannot use "new" with procedures except
in a generic context it is not clear what you are talking
about at all.

Whether something needs to be global or local (in lifetime
or scope) is a logic issue in a program, and not an
efficiency issue that a programmer should worry about.

Programmers who molest their programs in the interests
of efficiency almost always get things wrong, and often
make things worse!

A little knowledge can be worse than none in this area.h

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[czgrr]

In article <7evbei$opm$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <whatever>, czgrr <czgrr@my-dejanews.com> wrote:
> > So there is a definite difference between the time taken
> > to call a routine with and without local variables,
> > albeit very small.
>
> This is plain wrong on many machines. There is no
> difference. Furthermore, just because you don't WRITE
> any local variables does not mean there are none in the
> generated code.
[snip]
> > So making as much as you can be
> > global will improve overall run-time performance
>
> This is in general quite wrong. Access to local variables
> on the stack is generally much more efficient than access
> to global variables on modern architectures.
>
[taken from the end of the post]
> Whether something needs to be global or local (in lifetime
> or scope) is a logic issue in a program, and not an
> efficiency issue that a programmer should worry about.
>
At the end of this post I have included some code. The output I get is also
listed, and you can clearly see a difference between the two sets of procedure
calls, with the only code difference being a variable declared locally or
globally. I admit the local version is not of much use!

Now the difference may be due to something to do with the machine, the
memory, the compiler, bind options, etc, but the point I was making is that
there *can* be a difference.

Yes, in an ideal world the programmer shouldn't have to worry about machine
implementations, but this is not an ideal world and if the application being
developed is real-time critical, the code given below could make the
difference between passing acceptance tests and failing.

I said this in my original post, and I say it again, I am not saying that
every variable, procedure, etc, should be made global just because it (may
be) quicker. Definitely not. Logic issues should determine whether
declarations are made local or global, but there are occasional circumstances
where practicalities must override the ideal logic. The code below is one of
them.

[snip]
> Indeed since you cannot use "new" with procedures except
> in a generic context it is not clear what you are talking
> about at all.

I was talking about generics, sorry, I jumped contexts there without
explaining. I tried what I was talking about on my compiler and, as you say,
it made no difference. However, several years ago when I was developing a
disk access package with lots of "NEW TEXT_IO.FLOAT_IO" kind of declarations,
it definitely made a difference putting them all together at the top of the
package rather than individually within each procedure where needed.

Again, it may have been the compiler, whatever. But it did matter, and I don't
believe that programmers should be unaware of these possibilities.

**********

Now, the code I was talking about...

PACKAGE temp IS
  max : INTEGER := 1e5 ;
  PROCEDURE global ( index : IN INTEGER ) ;
  PROCEDURE local ( index : IN INTEGER ) ;
END temp ;

-----

PACKAGE BODY temp IS
  big_array_global : ARRAY ( 1 .. max ) OF INTEGER ;

  PROCEDURE global ( index : IN INTEGER ) IS
  BEGIN
    big_array_global ( index ) := 0 ;
  END global ;

  PROCEDURE local ( index : IN INTEGER ) IS
    big_array_local : ARRAY ( 1 .. max ) OF INTEGER ;
  BEGIN
    big_array_local ( index ) := 0 ;
  END local ;

END temp ;

-----

WITH CALENDAR ;
WITH TEXT_IO ;
WITH temp ;

PROCEDURE main IS
  PACKAGE float_io IS NEW TEXT_IO.FLOAT_IO ( FLOAT ) ;

BEGIN
  float_io.PUT ( FLOAT ( CALENDAR.SECONDS ( CALENDAR.CLOCK ) ) ) ;
  TEXT_IO.PUT_LINE ( " Calling global..." ) ;
  FOR i IN 1 .. temp.max LOOP
    temp.global ( i ) ;
  END LOOP ;

  float_io.PUT ( FLOAT ( CALENDAR.SECONDS ( CALENDAR.CLOCK ) ) ) ;
  TEXT_IO.PUT_LINE ( " Calling local..." ) ;
  FOR i IN 1 .. temp.max LOOP
    temp.local ( i ) ;
  END LOOP ;

  float_io.PUT ( FLOAT ( CALENDAR.SECONDS ( CALENDAR.CLOCK ) ) ) ;
  TEXT_IO.PUT_LINE ( " Finished." ) ;
  DELAY ( 100.0 ) ;

END main ;

**********

I use ObjectAda Professional Edition version 7.1.1.543, on Windows NT 4.0 with
128MB memory. Output was...

3.67944E+04 Calling global...
3.67945E+04 Calling local...
3.68065E+04 Finished.

That is, 0.1 second (to nearest 0.1 second!) to do the global verison, 12.0
seconds to do the local version.

czgrr

--
My opinions, suggestions, etc, are not necessarily those of my employer.
They might not even be right. Use at your own risk.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[dennison]

In article <7f1jce$nt4$1@nnrp1.dejanews.com>,
  czgrr <czgrr@my-dejanews.com> wrote:
>
>
> In article <7evbei$opm$1@nnrp1.dejanews.com>,
>   Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> > This is in general quite wrong. Access to local variables
> > on the stack is generally much more efficient than access
> > to global variables on modern architectures.

> At the end of this post I have included some code. The output I get is also
> listed, and you can clearly see a difference between the two sets of procedure
> calls, with the only code difference being a variable declared locally or
> globally. I admit the local version is not of much use!

Nifty. But my question had to do with the scope of subprograms, not
vairables. For some reason the wisdom of reducing the scope of variables is
unchallenged, but the same logic applied to subprograms seems to be in doubt.

Personally I have other more philisophical reasons for avioding nesting
subprograms. But occasionaly it is called for, and the effeciency argument
seemed fascetious to me. I wanted to know if there is anything to it.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <7f1jce$nt4$1@nnrp1.dejanews.com>,
  czgrr <czgrr@my-dejanews.com> wrote:
> I use ObjectAda Professional Edition version 7.1.1.543,
> on Windows NT 4.0 with 128MB memory. Output was...
>
> 3.67944E+04 Calling global...
> 3.67945E+04 Calling local...
> 3.68065E+04 Finished.
>
> That is, 0.1 second (to nearest 0.1 second!) to do the
> global verison, 12.0 seconds to do the local version.

And that statement is ALL you can conclude from this
experiment, namely that on the particular compiler you
used, with this particular program, you get these
particular results. You can't conclude anything general
about even your particular implementation, let alone about
local and global variables in general.

There is absolutely NO reason to see any difference between
the local and global array accesses here, except that of
course a good compiler should completely and easily
eliminate the code for the local version all together,
since the array is dead, and it is easy to see that it is
dead.

You do have a dynamic frame in your local procedure (I
hope you understand the fundamental and critical difference
between a dynamic or static local frame), and this means
that there is a dynamic stack check in the local version
that is probably avoided in the global version.

GNAT gives the following results for this program:

 3.12079E+04 Calling global...
 3.12079E+04 Calling local...
 3.12079E+04 Finished.

i.e. neither case takes detectable time, which is what
you would expect. This particular test is deeply flawed
in several respects.

a) As I noted above, the local version is far too easy
to optimize away.

b) Even the global version is too attackable by an
optimizer.

c) linking the size of the array to the number of test
loops is conceptually wrong.

d) using calendar and time of day to measure CPU
performance is fundamentally flawed.

e) Your can't tell whether the result of your code is
from the call or the array access, so it is hard to
interpret the results.

f) You have not considered issues of optimization issues
etc in deciding how to run this benchmark.

We find that people who try to run their own timing tests
almost always make these kinds of mistakes. Writing
meaningful benchmark tests is VERY tough. Almost always
when someone reports some anomoly with GNAT timing from
some little test program they have written, the anomoly
is a direct consequence of an incorrectly written test.

So how come you saw such bizarre results from your
test run with Object Ada? There could be many reasons.

1) You have run into some strange anomoly in code
generation. This seems unlikely, but is possible,
12 seconds for the local case makes no sense. Let's
do some quick calculations:

   You are calling a routine only 100,000 times. In 12
   seconds, this means 10,000 calls/second, which on a
   slowish PC (you did not give the analysis platform)
   which gives you at least 200,000,000 instructions
   per second, probably more, something like 20,000
   instructions per call.

That of course is completely absurd. The expected time
for this execution should be in the region of 10-50
instructions per call at most, even with lousy
optimization, so you should be talking something like
1000 times that speed or in the range of 10-20
milliseconds for your test.

Nevertheless an anomoly is always possible. Suppose for
example, that the stack check for the local case involved
a system call to find the current task to get the stack
limit. That's unimaginably horrible, but strange things
have been seen.

You can of course look at the assembly language generated
by your compiler, to see if there is some such nasty
anomoly, but I would doubt this is the reason

2) Your setup or observations are flawed in some way.

3) The calendar mistake cost you meaningful results

4) Something else completely unrelated is wrong

The point is that you cannot draw ANY conclusions from a
test that is poorly written, and whose results you cannot
explain when they clearly make little sense.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[czgrr]

In article <7f23j5$4mu$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:
[Snip everything, just for space, really; read the post if you want details]

To quote Chandler from "Friends": "Can open, worms everywhere!"

You are correct, the test gives a very limited conclusion, it is flawed in
many ways, etc, etc. I did not intend that example to be suitable code, but
just to show my point - which it did, in that on *my* implementation, with
*my* setup and with the very example-specific code shown, I got a result
which was much different from yours, and which was not as expected.

However, and I say this as my last posting to this thread...

There is a large, real-time critical program which worked fine. Then it was
ported from one machine to another without any code changes and suddenly had
a serious performance problem. Moving locally declared, generic-based
packages to global scope, and also some large arrays, just like in the
example I gave, solved the problem, and that is all that was changed.

Now there are many factors, which you have touched upon in your last post,
which may have caused the problem, but this was "real" code, in a "real"
environment. I couldn't produce that exact code for you to try on your
machine because a) there would be too much of it, b) I do not own the
copyright, and anyway c) I don't work for that project any more. So I'm
afraid I/we will never know the exact or "true" reason for the difference in
performance.

But it worked. The problem was fixed by a single change without affecting
functionality. The customer and the project were happy. The code is more
portable as a result, because it depends just that little bit less on the
environment in which it is run.

And making the same change to the code on the original machine had no visible
effect on that, either, so why not code it like that to begin with? Ever
since then, when I have the same sort of situation with very large arrays,
etc, I always make them global. It is less logically correct, yes, it may not
be necessary *in that environment*, yes, but it had fixed a bug and I learned
from it.

And when someone on a discussion forum asks a related question, I give my
opinion, based on my experience, and that is all I can give. It is up to the
readers of this thread to make their own choice as to how they would code a
particular situation, and I have had my say, you have had yours, and that the
end of the story.

All the best,
czgrr

--
My opinions, suggestions, etc, are not necessarily those of my employer.
They might not even be right. Use at your own risk.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <7f46ij$vfo$1@nnrp1.dejanews.com>,
  czgrr <czgrr@my-dejanews.com> wrote:
> Ever since then, when I have the same sort of situation
> with very large arrays,
> etc, I always make them global. It is less logically
> correct, yes, it may not be necessary *in that
> environment*, yes, but it had fixed a bug and I learned
> from it.

You learned that a kludge that you did not understand
fixed a particular problem in a particular environment
for reasons that were unclear. Still if you have to kludge
to get something working, sometimes you have to (though
I would have investigated why this had the effect that
it did, you might have found for instance, that this
particular change by complete accident removed an Icache
conflict in a completely unrelated part of the program).

In the GNAT project, if we have to put in kludges of this
kind, we mark them with ??? which is a reminder to fix
them properly some time when we can figure out the proper
fix, or better understand the situation.

What you did wrong was to extend this observation in a way
completely unjustified by the observation, and then put a
nasty kludge in other programs, one which most certainly
may damage the structure (e.g. making things task unsafe
when they would otherwise be safe), and indeed likely
slowing down things.

When you make a change to your program that speeds things
up, you should not conclude ANYTHING unless you understand
WHY it sped things up.

Remember that this thread started with your completely
unjustified (and as it turns out unjustifiable) general
statement that global arrays were more efficient than
local arrays.

An equally valid statement would have been to note that
moving a declaration from line 345 to line 123 of the unit
fixed the efficiency problem, and then deciding that in
all units from now on, you will avoid the horribly
innefficient results of putting any declarations in line
345 of any unit.

Now, that's absurd, and you know enough to know it's
absurd, so you avoid this mistake. Well the conclusion
you drew is also absurd, you just don't know enough to
*know* that it is!

I will repeat, in my experience, the rumours and supposed
knowledge that many programmers have about what is and
what is not efficient are often vague, confused, or plain
wrong, and frequently result in contaminated less
maintainable code, and in many cases actually slow down
processing (as would the practice of making arrays global
on most machines).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert A Duff]

fluffy_doo@dsuper.net writes:

> It looks like I am forced to declare a *new variable* in One_Procedure
> to which I will give the value of Var_2 (Ex: modif_Var_2 := Var_2;),
> and then send modif_Var_2 in Internal_Procedure to be modified and
> brought back via its "IN OUT" parameter.

That's right.

The rule in some other languages (eg Pascal and C) is different -- in
those languages, a parameter acts just like a local variable, so you can
modify it, and it doesn't affect the caller's copy.  That's error prone,
which is why in Ada an 'in' mode parameter acts like a local *constant*.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <wcchfqkbddr.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> The rule in some other languages (eg Pascal and C) is
> different -- in those languages, a parameter acts just
> like a local variable, so you can modify it, and it
> doesn't affect the caller's copy.  That's error prone,
> which is why in Ada an 'in' mode parameter acts like a
> local *constant*.

To expand on Bob's point, there is a fundamental issue
here of binding. In Ada, a programmer knows that an IN
parameter is bound to the actual argument, so if you have
an IN parameter called Clunk, then throughout the code of
the procedure you know that Clunk is bound to this value.

In C or Pascal, if you see Clunk, it may or may not have
the value of the input parameter, you have to carefully
check the *dynamic* sequence of execution of the function
to see if there could have been any modifications.

Yes, it's slightly annoying to a writer who wishes to
minimize keystrokes to have to declare a variable where
a variable is needed, and initialize the variable with the
value of the parameter.

Too bad, we don't care about writers with slow fingers
in the Ada world. We are worried about the reader (e.g.
a maintenance programmer) coming to the program later,
and being able to make simple assumptions (in this case
that Clunk really is the input parameter) without
having to check.

For example, suppose we add a new rule to the interface.
It says, if all other verification tests pass, then the
parameter Clunk must be checked to make sure it does not
have the value 43, and if it does, then raise the
exception "End_Of_The_World".

This is a relatively easy modification, you just look
through the code to make sure you are past the validation
checks, and then you add:

    if Clunk = 43 then
       raise End_Of_The_World;
    end if;

You do nt have to worry about whether details of the
code you skipped reading carefully do or do not change
the value of Clunk.

A C programmer making the same choice would have two
approaches.

a) carefully check the code to see if clunk is modified.
This involves worrying about aliases (did someone do &
on clunk, and pass this to a routine that might use the
pointer to modify the value for example). Then if the
answer is no, put in the above code, with a big warning
message that no one must subsequently modify Clunk before
this point.

b) throw in an extra variable Clunk2, copy Clunk to Clunk2
at the start of the function. Put in a big warning that
Clunk2 should not be modified, and then check Clunk2 at
the appropriate point.

Which do you think would be chosen (I would guess neither,
C programmers (and programmers in general for that matter)
are not in the habit of putting big warnings in their code!

Robert Dewar


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Hyman Rosen]

Robert Dewar wrote:
> A C programmer making the same choice would have two
> approaches.
> ...
> Which do you think would be chosen (I would guess neither,

Correct. A C programmer would, of course, simply declare the
parameter as being 'const', then insert the test exactly as
you did in Ada.

Hmph. I'm surprised that you, of all people, are so parochial.
You usually aren't.

Re: scope and/or parameters (beginner)

[dennison]

In article <37149AE9.883147B6@prolifics.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> Robert Dewar wrote:
> > A C programmer making the same choice would have two
> > approaches.
> > ...
> > Which do you think would be chosen (I would guess neither,
>
> Correct. A C programmer would, of course, simply declare the
> parameter as being 'const', then insert the test exactly as
> you did in Ada.
>
> Hmph. I'm surprised that you, of all people, are so parochial.
> You usually aren't.

I don't think "const" exists in all versions of C. My old C reference book
(circa 1984) doesn't list it as a reserved word, or anywhere at all for that
matter. I suspect that means it did not exist in K&R C. Was it introduced in
ANSI C? In C++?

I don't look at too much C code myself, but the first time I ever saw "const"
in C source was about 3 months ago, and it was for a C++ capable compiler.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Hyman Rosen]

dennison@telepath.com wrote:
> I don't think "const" exists in all versions of C. My old C reference book
> (circa 1984) doesn't list it as a reserved word, or anywhere at all for that
> matter. I suspect that means it did not exist in K&R C. Was it introduced in
> ANSI C? In C++?
> 
> I don't look at too much C code myself, but the first time I ever saw "const"
> in C source was about 3 months ago, and it was for a C++ capable compiler.

I advise you to find a thread in this group related to Ada83, do the appropriate
substitutions, and apply it to yourself. As I said, I normally expect Robert
Dewar to know more about such things. He seldom goes off on diatribes against
other languages.

Re: scope and/or parameters (beginner)

[dennison]

In article <3714EEC5.689CCFBB@prolifics.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> dennison@telepath.com wrote:
> > I don't think "const" exists in all versions of C. My old C reference book
> > (circa 1984) doesn't list it as a reserved word, or anywhere at all for that
> > matter. I suspect that means it did not exist in K&R C. Was it introduced in
> > ANSI C? In C++?
> >
> > I don't look at too much C code myself, but the first time I ever saw
"const"
> > in C source was about 3 months ago, and it was for a C++ capable compiler.
>
> I advise you to find a thread in this group related to Ada83, do the
appropriate
> substitutions, and apply it to yourself. As I said, I normally expect Robert
> Dewar to know more about such things. He seldom goes off on diatribes against
> other languages.

I was asking a serious question I'd like to know the answer to. Perhaps it
would be better asked in a C group though.

If anyone wants me, I'll be off applying substitutions to myself...

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Hyman Rosen]

dennison@telepath.com wrote:
> I was asking a serious question I'd like to know the answer to. Perhaps it
> would be better asked in a C group though.
> 
> If anyone wants me, I'll be off applying substitutions to myself...

Sorry about that :-) But you know how you Ada guys get when people make
outmoded assumptions about your favorite language.

Anyway, const was in the ANSI C Standard, which was accepted in 1989.
The Rationale says that work on the Standard started in 1983, and also
says that const was borrowed from C++. So it appears that const started
showing up in C in the mid-1980s, around fifteen years ago. (As with C++,
implementations of near-Standard C arrived as drafts became available.)

Re: scope and/or parameters (beginner)

[dennison]

In article <37151A6D.FAA4ACA2@prolifics.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:

> Anyway, const was in the ANSI C Standard, which was accepted in 1989.
> The Rationale says that work on the Standard started in 1983, and also
> says that const was borrowed from C++. So it appears that const started
> showing up in C in the mid-1980s, around fifteen years ago. (As with C++,
> implementations of near-Standard C arrived as drafts became available.)

Hmmm. Like I said I have a fair amount of exposure to C on Unix platforms,
including an entire development project or two, and a few months ago was the
first I'd ever seen it. I guess the real lesson here is that there are an
awful lot of obsolete K&R C compilers (and code) still floating around.

Well...that and: I need to get a more up to date C reference.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <7f4sh1$h8l$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

> I guess the real lesson here is that there are an
> awful lot of obsolete K&R C compilers (and code) still
> floating around.

You also have to consider the knowledge base, i.e. do
programmers know all the relatively new stuff in the ANSI
C standard, and can they count on maintenance programmers
to know it.

When it comes to const, this is of course an important
feature, but it does not BEGIN to have become standard
practice in C code, and indeed virtually all API's I
have worked with seem to prefer to use #define in the
traditional manner to using const. This is not a decision
I approve of, I am merely making an observation, it takes
time for things to change.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Hyman Rosen]

Robert Dewar wrote:
> You also have to consider the knowledge base, i.e. do
> programmers know all the relatively new stuff in the ANSI
> C standard, and can they count on maintenance programmers
> to know it.
> 
> When it comes to const, this is of course an important
> feature, but it does not BEGIN to have become standard
> practice in C code, and indeed virtually all API's I
> have worked with seem to prefer to use #define in the
> traditional manner to using const. This is not a decision
> I approve of, I am merely making an observation, it takes
> time for things to change.

I don't think that the dearth of const in C code is because of lack
of knowledge. The problem with const is that it is infectious where
it is most needed, with respect to pointers. Once an object is const,
pointers to that object can not be passed as parameters to routines
which expect non-const pointers (unless casts are used). Unfortunately,
many APIs predate const, and so use non-const pointers even when they
do not modify the pointed-to data.

As far as const-vs.-#define, you cannot use const objects as parts of
constant expressions in C. (You can in C++.) The best way to declare
integer constants in C is through enum.

Re: scope and/or parameters (beginner)

[dennison]

In article <7f51r8$m5r$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <7f4sh1$h8l$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
>
> > I guess the real lesson here is that there are an
> > awful lot of obsolete K&R C compilers (and code) still
> > floating around.

> When it comes to const, this is of course an important
> feature, but it does not BEGIN to have become standard
> practice in C code, and indeed virtually all API's I
> have worked with seem to prefer to use #define in the
> traditional manner to using const. This is not a decision

As I said, I deal with a lot of C API's myself, and it was just 3 months ago
I came across my first one that used "const". So I guess now, 15 years after
its inception and 10 years after its release, I'm finally going to have to get
an ANSI C reference to be able to understand C code.

At this rate I won't need a C++ reference until 2007. :-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <37149AE9.883147B6@prolifics.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> Robert Dewar wrote:
>
> Correct. A C programmer would, of course, simply declare
> the parameter as being 'const', then insert the test
> exactly as you did in Ada.
>
> Hmph. I'm surprised that you, of all people, are so
> parochial. You usually aren't.

The "of course" here is mighty forced :-)

First, I have never *ever* seen C programmers routinely
write prototypes with const in them, as in

   int max (const int a, const int b) {

so to claim that it is standard practice, as implied by
your "of course" is really stretching things.

Second, please note that in C, if you *do* declare things
this way, the effect of assigning to the const object is
"undefined" according to the ANSI C standard, not illegal
but undefined!

Your compiler may be kind enough to give you a warning,
gcc does, but it is not even required to do this.

So (a) I think the claim that C programmers would of course
use the const keyword in this context is completely bogus
and (b) even if they do, it does not mean that the compiler
will reject attempts to assign to the "const" object.

perhaps the abbreviation of constant to const is best
interpreted as meaning that it is sort of constant, but
not very :-) :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Hyman Rosen]

Robert Dewar wrote:
>   Hyman Rosen <hymie@prolifics.com> wrote:
> > Correct. A C programmer would, of course, simply declare
> > the parameter as being 'const', then insert the test
> > exactly as you did in Ada.
> 
> The "of course" here is mighty forced :-)
> 
> First, I have never *ever* seen C programmers routinely
> write prototypes with const in them, as in
> 
>    int max (const int a, const int b) {
> 
> so to claim that it is standard practice, as implied by
> your "of course" is really stretching things.

It's not standard practice to do this because generally no one cares
if the parameter is modified. No C programmer thinks of such a parameter
as being an alias of some other object. If it was important to preserve
the value of the parameter throughout the function, then making it const
is the natural solution.

> Second, please note that in C, if you *do* declare things
> this way, the effect of assigning to the const object is
> "undefined" according to the ANSI C standard, not illegal
> but undefined!

Huh? I think you have a serious misunderstanding. An attempt to assign to
a const object is illegal, and any C compiler will prevent you from doing
this. What you are thinking of is an attempt to modify an object that is
declared const through an alias that is not. Naturally, it may be impossible
to detect such an attempt, so the standard makes the effect undefined. Here's
an example:

	void f(const int a)
	{
		int *p;

		a = 1;	/* Illegal assignment to constant */
		p = &a;	/* Illegal - const discarded */
		p = (int *)&b; /* Legal because of explicit cast */
		*p = 1; /* Undefined result, but compiler need not notice. */
	}
 
> perhaps the abbreviation of constant to const is best
> interpreted as meaning that it is sort of constant, but
> not very :-) :-)

C compilers routinely place const global data into readonly segments.
I assure you, they are quite constant!

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <37162593.73F3F640@prolifics.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> C compilers routinely place const global data into
> readonly segments. I assure you, they are quite constant!

Of course such an implementation is valid, undefined covers
a lot of ground, but please prove your assertion that
assignment to a const object is illegal, by specific
reference to the ANSI standard!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Hyman Rosen]

Robert Dewar wrote:
> Of course such an implementation is valid, undefined covers
> a lot of ground, but please prove your assertion that
> assignment to a const object is illegal, by specific
> reference to the ANSI standard!

(I'm working off an old Draft, so my sections may be off.)

3.3.16 Assignment Operators
Constraints
	An assignment operator shall have a modifiable lvalue
	as its left operand.

3.3.16.1 Simple assignment
	One of the following shall hold: ...
	* both operands are pointers to qualified or unqualified versions
	  of compatible types, and the type pointed to by the left has all
	  the qualifiers of the type pointed to by the right;

3.2.2.1 Lvalues and function designators
	A modifiable lvalue is an lvalue that ...
	does not have a const-qualified type, ...
	(including, recursively, any member of all contained
	structures or unions) ...

Re: scope and/or parameters (beginner)

[Rakesh Malhotra]

Hyman Rosen wrote:
> C compilers routinely place const global data into readonly segments.
> I assure you, they are quite constant!

Maybe most compilers do place const declarations into ROM however that
is not universally true.  If I remember correctly Embedded Systems
Programming (very recently) carried at least 4 consecutive issues on
this very topic : the different ways the keyword "const" can be used and
what it means under different circumstances.  In the articles (I think)
the author mentioned that "const" will often not do what it implies i.e.
the compiler/linker will not locate the so-called constant in ROM but in
RAM.

Re: scope and/or parameters (beginner)

[fluffy_dong]

On Tue, 13 Apr 1999 18:10:08 GMT, Robert A Duff
<bobduff@world.std.com> wrote:

>fluffy_doo@dsuper.net writes:
>
>> It looks like I am forced to declare a *new variable* in One_Procedure
>> to which I will give the value of Var_2 (Ex: modif_Var_2 := Var_2;),
>> and then send modif_Var_2 in Internal_Procedure to be modified and
>> brought back via its "IN OUT" parameter.
>
>That's right.
>
>The rule in some other languages (eg Pascal and C) is different -- in
>those languages, a parameter acts just like a local variable, so you can
>modify it, and it doesn't affect the caller's copy.  That's error prone,
>which is why in Ada an 'in' mode parameter acts like a local *constant*.
>
>- Bob

What I'm surprised about is not about a passage through a single
sub-program, but through two (2) of them in line, two levels down.  I
would have expected the IN parameter to protect the value against
modification only for the sub-program from which it was first passed
but not for the second one.  As it stands, if a variable is passed
down several sub-programs, it must keep the same passage mode
throughout the entire line.  I wonder why they made it this way.

It would have seemed logical to make it so that an IN passage from A
to B (only when B is declared INSIDE A) could have allowed an IN OUT
of the same variable from B to C (C being inside B) to modify the
value IN B BUT NOT IN A.  This would have avoided the additional
variable needed but would have still protected the variable's
integrity in A.  There would be no danger in inadvertantly affecting
it via another sub-program declared outside of A because both B and C
are declared inside A, and therefore not visible outside of it.

One significant change it would have made would have been that formal
parameters would behave differently depending on weather or not a
sub-program is declared inside another or not, which  I believe is not
the case now (in today's real world of Ada).  I have a feeling there
is a good reason, a more specific one, why it is the way it is.  If
it's not too complicated to explain, maybe someone can  try to tell
me.

Marc  
--
What I really am is "fluffy", no "_dong",
no "_puff", no "_woo", no  nothing, just plain fluffy.

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <37155f01.1945002895@news.dsuper.net>,
  fluffy_dong@dsuper.net wrote:
> What I'm surprised about is not about a passage through a
> single sub-program, but through two (2) of them in line,
> two levels down.

What I am surprised about is that you could think this :-)

(and I read what you said ...)

constant in Ada means constant, it does not mean
"constant, except that if you call a second level procedure
you are allowed to modify it"

!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[dennison]

In article <7f52vj$n90$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <37155f01.1945002895@news.dsuper.net>,
>   fluffy_dong@dsuper.net wrote:
> > What I'm surprised about is not about a passage through a
> > single sub-program, but through two (2) of them in line,
> > two levels down.
>
> What I am surprised about is that you could think this :-)
>
> (and I read what you said ...)
>
> constant in Ada means constant, it does not mean
> "constant, except that if you call a second level procedure
> you are allowed to modify it"

I suspect he was thinking something along the lines of:
My parameters are being passed via a copy method: "in out" is copy-in-copy-out
and "in" is just copy-in. Therefore there's no harm in allowing the *copy*
inside the ourter routine to be modified, since the modification will not be
copied out.

Of course the fallacy in that is that the Ada compiler (in most cases) is
perfectly free to choose to pass those parameters by reference instead of
copy. So if you rely on the copy mechanisim in order for your algorithm to
work, you will have to do the copying youself!


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[fluffy_dong]

On Thu, 15 Apr 1999 18:05:12 GMT, in comp.lang.ada you wrote:

>> What I am surprised about is that you could think this :-)
>>
>> (and I read what you said ...)
>>
>> constant in Ada means constant, it does not mean
>> "constant, except that if you call a second level procedure
>> you are allowed to modify it"

I know that and I am curious as to why the people who designed Ada
made it this way, as opposed to the way that I described.  If there is
no OUT then it would/should not matter what is done to the value
passed because it's not coming back.  It would/should be treated as an
idependent copy of the variable passed.  I know that is not the way it
works.  Why not? (Don't answer. It's been answered below.)

>I suspect he was thinking something along the lines of:
>My parameters are being passed via a copy method: "in out" is copy-in-copy-out
>and "in" is just copy-in. Therefore there's no harm in allowing the *copy*
>inside the ourter routine to be modified, since the modification will not be
>copied out.

That is exactly what I was thinking about.  (Keep in mind, that I
don't have much experience in programming: a bit of C++, a bit of
Visual Basic, and one Ada course I'm presently taking, only school.)

>Of course the fallacy in that is that the Ada compiler (in most cases) is
>perfectly free to choose to pass those parameters by reference instead of
>copy.

That's the answer I was looking for, perhaps obvious to some but not
to me.  It's a bit over my head but it is what I needed to know.
Before this I knew one and only one thing about compilers: they
translate  code into assembly language.  Now I know two things (about
the *Ada* compiler).

>So if you rely on the copy mechanisim in order for your algorithm to
>work, you will have to do the copying youself!

Thanks

Marc
--
What I really am is "fluffy", no "_dong",
no "_puff", no "_woo", no  nothing, just plain fluffy.

Re: scope and/or parameters (beginner)

[Robert Dewar]

In article <371c4201.2003123297@news.dsuper.net>,
  fluffy_dong@dsuper.net wrote:
> I know that and I am curious as to why the people who
> designed Ada made it this way, as opposed to the way that
> I described.  If there is
> no OUT then it would/should not matter what is done to
> the value passed because it's not coming back.

The reason, as has been explained is for readability and
safety of the code.

>  Therefore there's no harm in allowing the *copy*
>inside the ourter routine to be modified, since the
> modification will not be copied out.

Yes there is harm, this is confusing code, see my
previous post.

> >Of course the fallacy in that is that the Ada compiler
> >(in most cases) is perfectly free to choose to pass
> >those parameters by reference instead of
> >copy.

No, that's not the reason, and indeed for scalars, where
this is most likely to arise, the Ada compiler is NOT
free to pass by reference
>
> That's the answer I was looking for,

Maybe it is the answer you were looking for, but it is
not the right answer!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: scope and/or parameters (beginner)

[Fraser Wilson]

paene lacrimavi postquam Robert Dewar scribavit:

>Maybe it is the answer you were looking for, but it is
>not the right answer!

However, as a fringe benefit, it's rather nice.  I mean, the warning
"record passed by value," doesn't even exist in Ada.

Fraser.

Re: scope and/or parameters (beginner)

[Gautier.DeMontmollin]

> paene lacrimavi postquam Robert Dewar scribavit:

Non est <<scripsit>> ?  G.

Re: scope and/or parameters (beginner)

[Nick Roberts]

entabulavit?

Re: scope and/or parameters (beginner)

[fraser]

paene mihi mortem consisci postquam Gautier DeMontmollin scripsit:

>Non est <<scripsit>> ?  G.

Darn my imperfect memory.  You're right, of course, and let me just
say that this definitely wouldn't have happened in Ada.

Fraser.

Re: scope and/or parameters (beginner)

[Robert A Duff]

fluffy_dong@dsuper.net writes:

> I know that and I am curious as to why the people who designed Ada
> made it this way, as opposed to the way that I described.  If there is
> no OUT then it would/should not matter what is done to the value
> passed because it's not coming back.  It would/should be treated as an
> idependent copy of the variable passed.  I know that is not the way it
> works.  Why not? (Don't answer. It's been answered below.)

Even if all parameters were always passed by copy, the language
designers would *still* have made 'in' parameters constant inside the
called procedure.  Suppose I wanted an 'in out' parameter, but I forgot
to say 'in out'.  The Ada rule saves me, because when I assign the new
value to the parameter, I get a compilation error.  Note that it's
irrelevant whether the formal parameter is assigned by a direct
assignment statement, or by calling another procedure which in turn has
an 'in out' parameter.  (Constant means constant, and, like Robert, I'm
surprised that you would think passing it to another procedure would
somehow turn that off.)

Furthermore, constants generally make the code more readable, because if
you know something is constant, you don't have to worry about it
changing.  That's true of local variables, and it's just as true of
formal parameters.  So of course formal parameters should default to
being constant.  (If I had designed the language, I would have done the
same for local variables -- "X: Integer := 10;" would declare a
constant, and "X: var Integer := 10;" would declare a variable.)

And furthermore, the need to modify a parameter as a temp inside the
procedure is rare -- if you need to do that, it's no big deal to declare
a local variable and initialize it to the value of the parameter.  And
doing that makes it clear what's going on.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: scope and/or parameters (beginner)

[Larry Kilgallen]

In article <wccaew0o6bn.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:

> And furthermore, the need to modify a parameter as a temp inside the
> procedure is rare -- if you need to do that, it's no big deal to declare
> a local variable and initialize it to the value of the parameter.  And
> doing that makes it clear what's going on.

Sometimes examples are better.  We are really talking about:

	MY_GZORN_CODE : GZORN_CODE_TYPE := CALLER_GZORN_CODE;

and while I find myself doing this much more than Bob predicts,
it really has never been a problem.  I like the fact that it
points out those subprograms where I am "doing Pascal" :-).

Larry Kilgallen

Re: scope and/or parameters (beginner)

[Samuel Mize]

fluffy_dong@dsuper.net wrote:
>>fluffy_doo@dsuper.net writes:
>>
>>> It looks like I am forced to declare a *new variable* in One_Procedure
>>> to which I will give the value of Var_2 (Ex: modif_Var_2 := Var_2;),
>>> and then send modif_Var_2 in Internal_Procedure to be modified and
>>> brought back via its "IN OUT" parameter.
...
> What I'm surprised about is not about a passage through a single
> sub-program, but through two (2) of them in line, two levels down.  I
> would have expected the IN parameter to protect the value against
> modification only for the sub-program from which it was first passed
> but not for the second one.  As it stands, if a variable is passed
> down several sub-programs, it must keep the same passage mode
> throughout the entire line.  I wonder why they made it this way.

So that you can reason effectively about code, especially code that
calls the procedure.

If you see a procedure definition:

    procedure Xyzzy (Fee: in Integer; Fie: in out Integer);

You can call it knowing that the value of Fee won't be changed.

Also, as (IIRC) Robert Dewar explained, inside Xyzzy, you can reason
use Fee with confidence that it hasn't been altered, used as a scratch
variable, or whatever.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam