NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/cplus/1882

Text File | 1992-12-21 | 6.1 KB | 125 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!mcsun!julienas!jussieu!shiva.jussieu.fr!kriss
From: [e-mail] (Christophe GROSJEAN)
Subject: Re: C++ already *has* nested functions SO WHAT'S THE BEEF?
In-Reply-To: [e-mail]'s message of Mon, 21 Dec 1992 08:09:52 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (Le Facteur)
Nntp-Posting-Host: rock.ibp.fr
Reply-To: [e-mail]
Organization: Laboratoire MASI, Paris, France.
References: <[e-mail]>
Date: Mon, 21 Dec 1992 17:21:01 GMT
Lines: 110

In article <[e-mail]> [e-mail] (Ronald F. Guilmette) writes:

>   You see, C++ already provides nested functions.  I believe that even the
>   people who are bemoaning the lack of nested function in C++ are probably
>   aware of this fact (or would be if they thought about it for a moment)
>   and that in fact what we have here is a failure to communicate clearly.

Indeed C++ provide several ways of simulating nested functions,
the tricks to make it works has basically the 3 problems you
pointed out.


>       o    We have to "invent" an otherwise useless and unnecessary
>           containing struct, union, or class type in order to be
>           able to nest functions.
>
>       o    Due to the (silly?) prohibition against defining a function
>           member of a block-local struct, union, or class type outside
>           of (and after) its "parent" type, and due to the (silly?)
>           rule that says that all functions defined *within* a class
>           are implicitly `inline', our nested functions are always
>           necessarily `inline' (when using this technique for nesting)
>           even if we do not want them to be.
>
>       o    Last but not least, although nested functions can legally
>           reference *most* names of *most* kinds of things declared
>           in a containing scope (including one local to a containing
>           function) there is one small and mildly annoying exception
>           to this general rule... i.e. we cannot access `auto' and
>           `register' *objects* declared within a containing local
>           scope.  Note that we *can* however reference the tags of
>           enum, struct, union, and class, types, names declared in
>           typedef statements, names of enumerators, function names,
>           and names of static and extern objects which are declared
>           in the containing (block) scope.


But, there is more to say about them :

>   For my part, I would be satisfied if the ANSI/ISO C++ committee(s) would
>   add "nested functions" to C++ in such a way that the first two problems
>   on my list above could be eliminated.  But note that this could be done
>   with only a single minor syntax change (to allow function *definitions*
>   as well as function *declarations* within a local block) and one minor
>   semantic change, i.e. disallowing the mention of any name of a locally
>   declared function (except those declared `extern') in any context other
>   than a call to the given function.  These two minor changes would solve
>   the problems I'm concernd with, and they would be relatively easy and
>   painless for implementors to implement.  Also, just as importantly, they
>   would not add materially to the already horrendous complexity of the
>   language (which is already a terrible burden for all those who would try
>   to learn this language).

Well, i merely agree with you on this, the effect would be to make a
nested function declaration simpler.

>   So why do people insist on attacking (and defeating) the third minor
>   problem listed above (regardless of costs)?

>   Well, it appears that some people have this mental model of "nested
>   functions" left over from the days when they programmed in Pascal, where
>   *anything* in a containing scope could be accessed directly.  Sadly, these
>   folks don't seem to "get" the fundamental idea which made C into the big
>   success that it is today... i.e. that it is *good* when potentially
>   expensive run-time actions (e.g. indirection through some number of
>   "static link" pointers) are made *explicit* to the programmer so that he
>   or she will be more aware of the potential effects these things may have
>   upon run-time performance.

Modula-2, as I saw it (I didn't tried *all* compilers) has no reason to envy C,
and particularly not the efficiency. However, scope rules are *perfectly*
consistent. So much for the idea of C success strongly related to its efficiency.
I use (and like) C and C++, and that's not a point. But it still seems strange
to me that you speak about *explicit indirection* when C++ obviously go
the other way (first step : passing vars by reference with &, second step :
virtual functions). I got the feeling that C++ is often confusing about data storage
and concepts.

>   Obviously, I have a strong disagreement with the folks who would (for the
>   sake of eliminating a very minor restriction which only makes a difference
>   in rare cases anyway) "hack" the language mercilessly (and thereby cause
>   yet another headache for implementors).

About the first and second problem, it seems easy enough to change,
but I think it could make the difference beetween a used feature and
an unused one (as I see it now !).

I don't think the third restriction you pointed out is a minor one.
For one reason : local static vars already have another meaning !
Those vars are initialized only *once* when you first execute the
containing function ! If you modify them the new value will stuck.

Doesn't matter in most cases. But it's a powerfull source of bugs
whenever you use recursive functions. What I say is that the problem
with static functions is not that they are statically allocated :
no problem if I have space enough, but that they are initialized only
once and won't be preserved in recursive call.

I can do what I want copying values beetween automatic and static vars,
but a *user* of a library expecting a function as an argument should'nt
bother about that, not saying that king of things is very error prone.

I would be perfectly happy with a *local* keyword meaning the value
is stored in a static var, but is saved before calls and initialised
every time my function is called : does it seem a difficult thing to do ?

I need it, I'm no maniac !

Best, regards