🚀 go-pugleaf

In article <1993Jan26.224107.9187@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (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,         maxtal@extro.ucc.su.oz.au
|> 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
|> ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------


--- Charles Reindorf