• ranjit_ bh hotmail.com (3/3) Mar 13 2003 what is the need for the concept of nested functions?
• Walter (8/11) Mar 13 2003 You can see some examples in:
• C. Sauls (22/23) Apr 22 2003 Well I don't know about anyone else, but I've been using the heck out of
• Derek Parnell (19/23) Apr 22 2003 Another way of asking this questions is "what problem does 'nested
• Ilya Minkov (17/20) Apr 25 2003 In C i would sometimes find out i have a couple of similar lines in a

ranjit_ bh hotmail.com writes:

what is the need for the concept of nested functions?
also in all class objects are by reference does this not include the possibilty
of accidental corruption of dat. 

"Walter" <walter digitalmars.com> writes:

<ranjit_ bh hotmail.com> wrote in message
news:b4q17a$isb$1 digitaldaemon.com...
 what is the need for the concept of nested functions?

You can see some examples in:

www.digitalmars.com/d/pretod.html
www.digitalmars.com/d/ctod.html
www.digitalmars.com/d/cpptod.html


 also in all class objects are by reference does this not include the

possibilty
 of accidental corruption of dat.

I don't understand what the issue is there.

"C. Sauls" <ibisbasenji yahoo.com> writes:

<ranjit_ bh hotmail.com> wrote in message
news:b4q17a$isb$1 digitaldaemon.com...
 what is the need for the concept of nested functions?

Well I don't know about anyone else, but I've been using the heck out of
them.  Take example function Foo()... now say there are two utility
functions used by Foo() to wrap some recurring activity: Bar() and Baz();

In C++ I would have declared them such as:

UINT uFoo_Bar(UINT x, UINT y);
UINT uFoo_Baz(UINT x, char y);
UINT Foo(UINT x, UINT y, char z);

Simple enough, sure... but note the ugly names on the utility functions,
used to avoid symbol conflicts.  In D, I get to toss the ugly names, and
declare these three functions as:

uint Foo(uint x, uint y, char z)
{
    uint Bar(uint x, uint y) { ... }
    uint Baz(uint x, uint y) { ... }
    ...
}

The avoidance of ugly naming alone seems to make it useful to me.  Plus the
encapsulation of Foo's functionality entirely within itself, by making the
utilities internal.

--C. Sauls

Derek Parnell <derek.parnell no.spam> writes:

On Thu, 13 Mar 2003 13:31:22 +0000 (UTC), ranjit_ <bh hotmail.com> wrote:

 what is the need for the concept of nested functions?

Another way of asking this questions is "what problem does 'nested 
functions' solve?".

The common usage for nested functions is to clarify the written code for 
the human reader. It can do this by allowing the author to write only one 
copy of otherwise repeated code. The concept may also be used to highlight 
a specific algorithm used by the enclosing function, without causing scope 
issues.

For example, a routine might need a specialized 'maximum' function. By 
isolating this special function inside its calling routine, the author can 
make sure that the reader is alerted to it in a convenient manner. Also, if 
this special function(algorithm) is needed multiple times in the enclosing 
routine, the code becomes easier to read, due to the fact that repeating 
code is replaced by a call to the special function. All this happens 
without causing scope clashes with other routines.

Smart compilers may even inline these nested functions.

 also in all class objects are by reference does this not include the 
 possibilty
 of accidental corruption of dat.

Yes it does. Such is life.

-- 
Derek

Ilya Minkov <midiclub 8ung.at> writes:

ranjit_ wrote:
 what is the need for the concept of nested functions?

In C i would sometimes find out i have a couple of similar lines in a
function, so i would write a macro to shorten them and reduce the
probability of a typing mistake. Then i would undefine in
t at the end of a function. That IS UGLY. And you sometimes can't
encapsulate this common parts into a separate function, since you need
implicit acess to local variables, and passing them would make your code
even uglier!

That's where nested functions are handy. Also consider that a
preprocessor is to be avoided/ isn't directly available with D.

 also in all class objects are by reference does this not include the
 possibilty of accidental corruption of dat.

Sure. But the D's object design is to make inheritance safe, which is
also supported by implicitly virtual methods. Now, consider the
alternative: you make objects stack-handled. This means that whenever
you pass an object elsewhere, which is a descendant of declared type, it
gets truncated and dies with a painful death. And you get Montezuma's 
Revenge.

-i.