Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Recursion, Yo
Date: Wed, 10 Apr 2024 13:42:14 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <uv61f6$v1jm$1@dont-email.me>
References: <uut24f$2icpb$1@dont-email.me> <uutqd2$bhl0$1@i2pn2.org>
 <uv2u2a$41j5$1@dont-email.me> <87edbestmg.fsf@bsb.me.uk>
 <uv4r9e$mdd3$1@dont-email.me> <uv5e3l$q885$1@dont-email.me>
 <uv5gfd$qum1$1@dont-email.me> <uv5lgl$s6uj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Apr 2024 12:42:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="509425d4a7e19d9832405743df5292cc";
	logging-data="1017462"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+/xaKY97xOrSbPGxWHegRA"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:f7LWSx5QbMAIOYqJW/fYs6v1i4c=
Content-Language: en-GB
In-Reply-To: <uv5lgl$s6uj$1@dont-email.me>
Bytes: 3767

On 10/04/2024 10:18, David Brown wrote:
> On 10/04/2024 09:52, Lawrence D'Oliveiro wrote:
>> On Wed, 10 Apr 2024 09:11:49 +0200, David Brown wrote:
>>
>>> It is not much used in practice, AFAIK.  For some cases the code
>>> generation for nested functions was fine and straight-forward.  In other
>>> cases, however, it required a trampoline generated on the stack, and
>>> that became a real pain once non-executable stacks came into fashion.
>>
>> That would be true of those other languages that require the feature, 
>> too.
>>
> 
> There may be other differences in the languages that reduce that effect 
> - or it could be a problem there too.  I don't know the details. 
> (Perhaps those on an Ada newsgroup would know better.)
> 
> The problem with trampolines comes about when you want to take the 
> address of the nested function and use that outside of the surrounding 
> function, while you also have variables captured by reference.
> 
>>> Nested functions were never as interesting for C++ as you already have
>>> better mechanisms for controlling scope and data access - classes and
>>> their methods, including nested classes.
>>
>> Python does both. Just because you have classes doesn’t mean functions
>> can’t be first-class objects, too.
> 
> True.  But Python is a very different language from C++.  In Python, not 
> only are functions objects in themselves, but so are classes (the 
> definition of the classes, rather than just instances).  Python is a lot 
> more "meta" than C++.
> 
> Basically, anything you could do with a nested function in gcc C you can 
> do in C++:
> 
> int sum_square(int x, int y) {
>      int square(z) {               // int z ??
>          return z * z;
>      }
>      return square(x) + square(y);
> }

That's not an interesting use of a local function! You can move square() 
outside, and it would still work, putting aside any clashes with 
existing names called 'square'.

The challenges of local functions are to do with accessing transient 
variables belonging to their enclosing function. Especially when a 
reference to the local function is called from outside the lexical scope 
of the enclosing function, with extra difficulties when the enclosing 
function is no longer active.



> int sum_square(int x, int y) {
>      auto square = [](int z) {
>          return z * z;
>      }
>      return square(x) + square(y);
> }

What's the significance of the '[]' here?