🚀 go-pugleaf

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.

>
>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).


-- 
;----------------------------------------------------------------------
        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 --------