NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/std/cplus/2024

Text File | 1993-01-11 | 6.5 KB | 120 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!mcsun!julienas!jussieu!shiva.jussieu.fr!kriss
From: [e-mail] (Christophe GROSJEAN)
Subject: Re: Use of nested functions (Was: Proposal for default scope)
In-Reply-To: [e-mail]'s message of Sun, 10 Jan 1993 02:34:40 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (Le Facteur)
Nntp-Posting-Host: trot.ibp.fr
Reply-To: [e-mail]
Organization: Laboratoire MASI, Paris, France.
References: <[e-mail]> <[e-mail]>
Date: Mon, 11 Jan 1993 11:14:27 GMT
Lines: 105

In article <[e-mail]> [e-mail] (Greg Noel) writes:

>   There's a difference between hiding a lot of grungy detail and intrinsic
>   inefficiency.  If the compiler filling in the grungy details is what is
>   causing the inefficiency, the programmer can always replace it with something
>   more efficient.  If it's inefficient because of something required by the
>   language, that's not possible.

As others pointed out, nested functions requires innefficiency only when needed.
In a word : if you don't use it no cost for you. That's not the case if this
feature is not in the language. Then you must pay two times :
    - not as efficient implementation as built-in ones (even with very good code)
    - much difficulty to write your code, so NOBODY else but you can use
    libraries using non standard function calls (to emulate nested functions)

The evident consequence is that without nested functions inside the language,
I will change my programming style to be level with language inadequacies.

>   It's curious---I posted my original article to try to start a discussion
>   about how something like modules or packages could be added to C++ as
>   seamlessly as possible, because I see that as something that the language
>   doesn't handle well and needs badly.  But most of the responses have been
>   from people who reacted to one throw-away clause as a disparagement of
>   nested functions, which is not what I intended at all.

Packages would indeed be usefull. But that's not what I miss most right now.
I feel there is already many ways to achieve this with classes.
Is it not the goal of encapsulation ?

>   Personally, I'd prefer to let those who feel passionately about nested
>   functions debate this point.  As it is, I'm mooting a point about which
>   I don't care very much.  In my thirty years of experience, including using
>   languages that provided them, I've only wanted nested functions a few
>   times---and I've _never_ wanted to take the address of one.  If I don't
>   use them and if they don't cause me any inefficiency, then I don't really
>   care if they are present or not.

I only have fourteen years of programming. But what I can say is that when
I hadn't used OO languages, I never cared much about nested functions.
I won't miss them in Lisp, C, Pascal or Modula.

But I can't do without them for OO Programming. Programming in Smalltalk,
Ptitloo (lisp with an object interface) and Weird-Looking Mering IV, what
I miss most is decent containers. Let's explain.

My actual problem is making part of my local context be seen by a function.
Wich I can't call myself, cause it's called indirectly either by a system
C function (like qsort), or by a class library.

Making the context of a call seeable by a library is necessary in order
to make clean containers. What I mean by clean containers is containers
that can handle iterations internally, not externally using another class
(iterators) as it is generally done in C++.

The two approches are not equivalent. Iterators give control back to users
at each element in order to execute the user's code. Even if in much cases
it works fine, it doesn't with complex structures or heavily parallelized
archithectures.

What I'm saying is : is I don't give back the control to users at each step
    - I can do recursive calls very easily (to walk trees for instance)
    - I can make the iteration parallel in my library, may be I will have
    to hack machine code *inside* my container library, but users don't care
    this can't be done with iterator classes.

*BUT* to write a clean iterator, I need something to iterate : a function call.
This function is provided by user, so it MUST be easy to write, still its
interface is fixed by the container  (generally it takes an element of DATA),
and finally this function have generally to see external world.

You can achieve thoses three goals with nested functions. No other C++ hack
would do. The main problem is with simplicity, the other two, you can do.
What I call simplicity in my lab is, *as C as possible*. Many peoples are
eager to compile with C++ in order to reuse libraries written by others,
but not much are really wanting to learn OOP. Creating instances, they can
manage. Nested functions too (some C compilers as gnu C already has nested
functions). OO Design is to much. Nested functions would be a clean way to
write clean, efficien, perfectly encapsulated containers with iterators for
these people. I could adapt my libraries on parallel computers without
having them to change their code.

Ok, this use of nested functions is not perfectly clean in OO Design,
what should be perfect is a brand new class of functions...
functions that are really instances of a class, with a context,
an initialisation member, a return adress, etc.
If you think of it, it's nearly what a compiler would do in order to
implement nested functions.

This kind of class functions I can do in C++, but it's not simple to create
them. Terminal users won't use them... if I can't shorten their declaration.
I could do it with a better preprocessor... but preprocessor has'nt evolded.
It's still the good old C preprocessor, whose initial purposes are mostly
obsolete with C++. It's not well adapted with other purposes, as simplifying
specific class declarations. But that's another point.

>   On the other hand, there are literally hundreds of times I've wanted to
>   have a helper function that was not externally visible.  In C, a static
>   function provides most of the functionality I want, while in C++ it's
>   all but impossible.  If C++ wants to be considered a ``better'' language
>   than C, that's something that will have to be addressed.

Agreed... is it not still a problem of the number of line you have to write to
do what you want ? Efficiency is not even half of a language IMO, reusability
and clean interface (merely *short* semantic, minimalise the number of tokens
you must type to express yourself) is the other half.