NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/std/cplus/2125

Text File | 1993-01-27 | 4.2 KB | 89 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!enterpoop.mit.edu!ira.uka.de!slsvaat!us-es.sel.de!reindorf
From: [e-mail] (Charles Reindorf)
Subject: Re: Use of nested functions
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 27 Jan 93 09:40:29 GMT
Lines: 77

In article <[e-mail]>, [e-mail] (John MAX Skaller) writes:
|> In article <[e-mail]> [e-mail] (Charles Reindorf) writes:
|> >On the subject of "trampolenes" in the implementation of nested functions,
|> >this >presumably means the following appraoch:
|> >
|> >Some people say that they "don't like" trampolenes, but don't seem to give any
|> >reason for it.
|>
|>     Separation of code and data is an important machine
|> principle for safety. Some machines (all the good ones :-) do not
|> allow executing things in the data area.
|>
|>     Trampolines feel a bit like the Cobol ALTER statement:
|> dangerous hacks.
|>
|> >The main objection I can see is that on some operating systems
|> >you are not allowed to do any run-time code generation.
|>
|>     Some OS may not grant the user the priviledges required
|> to generate and execute code on the fly. This is because
|> it is close to 'self-modifying' code, which is not
|> generally considerd very safe.
|>
|> >But there again, in
|> >these architectures there do exist other,
|> >addmittedly less efficient workarounds
|> >to this problem, surely.
|>
|>     Such as? I would LOVE to hear of one that did not require
|> the standard C/C++ function pointers to double in size.

The whole issue is surely a matter dealt with heavily by PASCAL implementations. I suspect
that some implementations (e.g. MS-DOS ones) use trampolenes whereas others use double-size
function pointers. The question is, are C++ implementors ready to tackle the matter. My
feeling is that it adds a great deal of extra power to the language in return for the
penalty. However, I also understand that there is already a greaty deal on the plate for
the C++ standardisation committee. That's my 2 cents worth.

|>
|> >
|> >Other people talk about "bound" functions which presumably means that given an
|> >object a of class A with member function f, then "a.f" can be regarded as a new
|> >function (whose pointer can be taken) with a non member-function signature. The
|> >only way I can see of using a trampolene appraoch for this situation is to place
|> >the trampolene for the function a.f into the object a itself. This increases
|> >the memory overhead for function a. In fact, the compiler would have to do
|> >this by default for every member function of a, because it won't know in
|> >advance which will be bound (without ghastly extensions to the language). This
|> >surely makes member function closures an impracticable and unworkable addition
|> >to the language?
|> >
|>
|>     No, one can just leave it up to the user to delete the
|> trampoline---as for other dynamically allocated objects. It is not
|> as 'safe' as puting the trampoline in the object (or a pointer thereto),
|> but even that isnt safe (the trampoline could still be called
|> after it was deleted --- very nasty crash following, perhaps sometime
|> later).

This idea sounds very messy to me (to say the least). Can you describe the mechanism
for this in the language? My contention here would be : it's really not worth the
trouble. This sort of problem can be solved in other ways: If you have nested functions,
they can sometimes be used to forward the callback and otherwise you are likely best off
using a pointer to an abstract base class in preference to a pointer to a bound function.
There may be examples around where neither of these two approaches are suitable. Does
anybody know of any?

|>
|>
|> --
|> ;----------------------------------------------------------------------
|>         JOHN (MAX) SKALLER,         [e-mail]
|>     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
|> ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------


--- Charles Reindorf