Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #105584 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-03-08 10:04 -0800 |
| Last post | 2017-03-13 06:13 -0700 |
| Articles | 8 on this page of 108 — 20 participants |
Back to article view | Back to comp.lang.c
lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 10:04 -0800
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-08 18:20 +0000
Re: lambda functions in C Chad <cdalten@gmail.com> - 2017-03-08 11:12 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 11:36 -0800
Re: lambda functions in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-08 20:43 +0000
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-08 21:55 +0100
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 13:18 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 12:44 -0800
Re: lambda functions in C Chad <cdalten@gmail.com> - 2017-03-08 13:03 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 11:33 -0800
Re: lambda functions in C scott@slp53.sl.home (Scott Lurndal) - 2017-03-08 20:46 +0000
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-08 13:25 -0800
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 13:55 -0500
Re: lambda functions in C supercat@casperkitty.com - 2017-03-10 11:09 -0800
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 14:51 -0500
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-10 19:19 +0000
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 14:53 -0500
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-11 14:17 +0000
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-11 06:55 -0800
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-11 07:05 -0800
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-08 13:55 -0800
Re: lambda functions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-08 23:41 +0000
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 05:03 -0800
Re: lambda functions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-09 14:06 +0000
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-09 14:20 +0000
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 08:07 -0800
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-09 21:50 +0100
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-09 23:38 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-09 22:46 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 08:39 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-10 08:03 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 09:22 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-10 19:24 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 23:23 +0100
Re: lambda functions in C Ike Naar <ike@iceland.freeshell.org> - 2017-03-11 18:02 +0000
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-09 20:48 -0500
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 08:57 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 11:26 -0500
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 17:53 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 13:17 -0500
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-11 17:11 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 00:38 -0800
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 10:23 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 11:37 -0500
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 09:07 -0800
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 13:22 -0500
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 10:47 -0800
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-10 14:57 -0500
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-10 12:26 -0800
Re: lambda functions in C Chad <cdalten@gmail.com> - 2017-03-10 12:49 -0800
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 23:32 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-11 12:26 -0500
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-11 17:17 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 10:26 -0800
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-11 19:48 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 12:02 -0800
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 09:14 +1300
Re: lambda functions in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-11 15:44 -0500
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 09:51 +1300
Re: lambda functions in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-11 16:11 -0500
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 22:21 +0100
Re: lambda functions in C jameskuyper@verizon.net - 2017-03-11 13:36 -0800
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 23:48 +0100
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 11:55 +1300
Re: lambda functions in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-11 18:34 -0500
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 15:23 +1300
Re: lambda functions in C BartC <bc@freeuk.com> - 2017-03-12 11:42 +0000
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 13:49 +0100
Re: lambda functions in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-12 10:56 -0700
Re: lambda functions in C jameskuyper@verizon.net - 2017-03-11 15:30 -0800
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-12 00:37 +0100
Re: lambda functions in C Keith Thompson <kst-u@mib.org> - 2017-03-11 17:23 -0800
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 14:32 +0100
Re: lambda functions in C Gareth Owen <gwowen@gmail.com> - 2017-03-12 07:22 +0000
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 11:10 +1300
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-12 11:08 +1300
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 00:17 +0100
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 14:14 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-12 09:54 -0400
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 15:10 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-12 08:08 -0700
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-12 16:49 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-12 14:28 -0400
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-13 00:03 +0100
Re: lambda functions in C Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-12 19:15 -0400
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 18:18 +0100
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-12 10:42 -0700
Re: lambda functions in C David Brown <david.brown@hesbynett.no> - 2017-03-12 20:53 +0100
Re: lambda functions in C supercat@casperkitty.com - 2017-03-10 07:09 -0800
Re: lambda functions in C supercat@casperkitty.com - 2017-03-10 08:56 -0800
Re: lambda functions in C GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-10 08:49 +0100
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 04:12 -0800
Re: lambda functions in C Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2017-03-09 10:38 +0100
Re: lambda functions in C Siri Cruise <chine.bleu@yahoo.com> - 2017-03-09 08:48 -0800
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 09:45 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 09:51 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 09:50 -0800
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 11:08 -0800
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-10 08:22 +1300
Re: lambda functions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-09 12:12 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 11:29 -0800
Re: lambda functions in C Siri Cruise <chine.bleu@yahoo.com> - 2017-03-09 13:33 -0800
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 13:42 -0800
Re: lambda functions in C Ian Collins <ian-news@hotmail.com> - 2017-03-10 11:02 +1300
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-09 14:30 -0800
Re: lambda functions in C Siri Cruise <chine.bleu@yahoo.com> - 2017-03-09 15:07 -0800
Re: lambda functions in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 21:45 +0100
Re: lambda functions in C Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 06:13 -0700
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-03-09 11:29 -0800 |
| Message-ID | <80a72bf8-6944-41cc-bdaf-ac0655f36b25@googlegroups.com> |
| In reply to | #105681 |
On Thursday, March 9, 2017 at 4:09:06 PM UTC-3, Malcolm McLean wrote:
> On Thursday, March 9, 2017 at 5:50:30 PM UTC, Thiago Adams wrote:
> > On Thursday, March 9, 2017 at 1:48:56 PM UTC-3, Siri Cruise wrote:
> > > In article
> > > Thiago Adams wrote:
> > >
> > > > When a C++ lambda doesn't have any capture of variables
> > > > ( the [] part ) it is convertible to normal function pointer.
> > >
> > > A closure requires some kind of garbage collection.
> >
> > You can have captures in C/C++ without garbage collection.
> >
> > For instance.
> > I have in C or C++ an actor object with a queue of tasks.
> > Each task is a closure.
> >
> > The list of tasks is the owner of each the closure.
> > When the task is complete the lifetime of that closure ends
> > and the memory is released in a deterministic way.
> > As I explained before, the function that delete the capture
> > is the function that does the closure job.
> >
>
> You can do it like this
>
> struct mylocals
> {
> int a;
> int b;
> int c;
> }
>
> double lambda(void *ctx)
> {
> mylocals * loc = ctx;
>
> return (loc->a + loc->b)/(loc->c);
> }
>
> void caller(void)
> {
> struct mylocals locals;
>
> ....
> passedlambda(lambda, &mylocals);
> }
>
> void passedlambda(double (*fptr)(void *ctx), void *ctx)
> {
> double x = (*fptr)(ctx);
>
> ....
> }
>
> But what you can't do is then store the closure for use later.
Yes you can. Just store void* (heap) and the function pointer.
But, we don't need to store anything for algorithms like the
sample above.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2017-03-09 13:33 -0800 |
| Message-ID | <chine.bleu-E5B5C8.13333609032017@news.eternal-september.org> |
| In reply to | #105678 |
In article <fc09b65f-a033-42fd-8229-6d1b50e17fa7@googlegroups.com>,
Thiago Adams <thiago.adams@gmail.com> wrote:
> On Thursday, March 9, 2017 at 1:48:56 PM UTC-3, Siri Cruise wrote:
> > In article
> > Thiago Adams wrote:
> >
> > > When a C++ lambda doesn't have any capture of variables
> > > ( the [] part ) it is convertible to normal function pointer.
> >
> > A closure requires some kind of garbage collection.
>
> You can have captures in C/C++ without garbage collection.
func f, g;
{
int *array = malloc(2*sizeof(int));
array[0] = 1; array[1] = 2;
f = int(void){return array[0];};
g = int(int k){array[0] += 1; return array[k];
}
....f()....g(0)....g(1)....f()....
f = 0;
....g(0)....g(1)....
g = 0;
Reference the same heap array in two closures and remove all other references to
the array. As long as the closures exist, the array remains active. As long as
one closure exist, the array remains active. But once both closure are removed,
the array becomes garbage.
You need some kind of garbage collection, such heap mark/sweep or reference
count, or very unnatural rules that make the closures as usuable as the current
data pointer.
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-03-09 13:42 -0800 |
| Message-ID | <a9cf5635-17d3-45e7-a60d-a18130e5b6c5@googlegroups.com> |
| In reply to | #105697 |
On Thursday, March 9, 2017 at 6:34:00 PM UTC-3, Siri Cruise wrote:
> In article ,
> Thiago Adams wrote:
>
> > On Thursday, March 9, 2017 at 1:48:56 PM UTC-3, Siri Cruise wrote:
> > > In article
> > > Thiago Adams wrote:
> > >
> > > > When a C++ lambda doesn't have any capture of variables
> > > > ( the [] part ) it is convertible to normal function pointer.
> > >
> > > A closure requires some kind of garbage collection.
> >
> > You can have captures in C/C++ without garbage collection.
>
> func f, g;
> {
> int *array = malloc(2*sizeof(int));
> array[0] = 1; array[1] = 2;
> f = int(void){return array[0];};
> g = int(int k){array[0] += 1; return array[k];
> }
> ....f()....g(0)....g(1)....f()....
> f = 0;
> ....g(0)....g(1)....
> g = 0;
>
> Reference the same heap array in two closures and remove all other references to
> the array. As long as the closures exist, the array remains active. As long as
> one closure exist, the array remains active. But once both closure are removed,
> the array becomes garbage.
>
> You need some kind of garbage collection, such heap mark/sweep or reference
> count, or very unnatural rules that make the closures as usuable as the current
> data pointer.
You can have a shared array with reference counting for instance.
In C++ words std::shared_ptr<std::vector<int>>
No garbage collector.
The same can be done in C if necessary.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-10 11:02 +1300 |
| Message-ID | <eie1obF2lpvU4@mid.individual.net> |
| In reply to | #105698 |
On 03/10/17 10:42 AM, Thiago Adams wrote: > On Thursday, March 9, 2017 at 6:34:00 PM UTC-3, Siri Cruise wrote: >> >> Reference the same heap array in two closures and remove all other references to >> the array. As long as the closures exist, the array remains active. As long as >> one closure exist, the array remains active. But once both closure are removed, >> the array becomes garbage. >> >> You need some kind of garbage collection, such heap mark/sweep or reference >> count, or very unnatural rules that make the closures as usuable as the current >> data pointer. > > You can have a shared array with reference counting for instance. > In C++ words std::shared_ptr<std::vector<int>> > No garbage collector. > The same can be done in C if necessary. C doesn't have automatic object destruction, so you'd have to keep tabs on things manually. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-03-09 14:30 -0800 |
| Message-ID | <f3192434-04c5-491f-997e-bf4c712d4781@googlegroups.com> |
| In reply to | #105698 |
On Thursday, March 9, 2017 at 6:42:11 PM UTC-3, Thiago Adams wrote:
> On Thursday, March 9, 2017 at 6:34:00 PM UTC-3, Siri Cruise wrote:
> > In article ,
> > Thiago Adams wrote:
> >
> > > On Thursday, March 9, 2017 at 1:48:56 PM UTC-3, Siri Cruise wrote:
> > > > In article
> > > > Thiago Adams wrote:
> > > >
> > > > > When a C++ lambda doesn't have any capture of variables
> > > > > ( the [] part ) it is convertible to normal function pointer.
> > > >
> > > > A closure requires some kind of garbage collection.
> > >
> > > You can have captures in C/C++ without garbage collection.
> >
> > func f, g;
> > {
> > int *array = malloc(2*sizeof(int));
> > array[0] = 1; array[1] = 2;
> > f = int(void){return array[0];};
> > g = int(int k){array[0] += 1; return array[k];
> > }
> > ....f()....g(0)....g(1)....f()....
> > f = 0;
> > ....g(0)....g(1)....
> > g = 0;
> >
> > Reference the same heap array in two closures and remove all other references to
> > the array. As long as the closures exist, the array remains active. As long as
> > one closure exist, the array remains active. But once both closure are removed,
> > the array becomes garbage.
> >
> > You need some kind of garbage collection, such heap mark/sweep or reference
> > count, or very unnatural rules that make the closures as usuable as the current
> > data pointer.
We just diverge in what we call garbage collector.
For deterministic destruction (ref count) I don't call
it garbage collector.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2017-03-09 15:07 -0800 |
| Message-ID | <chine.bleu-F1558A.15075009032017@news.eternal-september.org> |
| In reply to | #105698 |
In article <a9cf5635-17d3-45e7-a60d-a18130e5b6c5@googlegroups.com>,
Thiago Adams <thiago.adams@gmail.com> wrote:
> > You need some kind of garbage collection, such heap mark/sweep or reference
---------
> > count, or very unnatural rules that make the closures as usuable as the
-----
> > current
> > data pointer.
>
> You can have a shared array with reference counting for instance.
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-11 21:45 +0100 |
| Message-ID | <oa1ngf$7ml$1@dont-email.me> |
| In reply to | #105584 |
Le 08/03/2017 à 19:04, Thiago Adams a écrit :
>
> One feature I miss from C++ is lambdas expressions.
>
> In C++, we can create a function pointer like this:
>
> int (*F)(int) = [](int i) -> int
> {
> return i * 2;
> };
>
> F(1);
>
> and also pass it as a function argument.
>
> void F2(int (*F)(int));
>
> F2([](int i) -> int
> {
> return i * 2;
> });
>
> When a C++ lambda doesn't have any capture of variables
> ( the [] part ) it is convertible to normal function pointer.
>
> This feature could be added as it is into the C language.
> The generated code is an internal linkage anonymous function.
>
What about
int anonymousFunction1(int i)
{
return i*2;
}
int (*F2)(int);
F2 = anonymousFunction1;
> This is a kind of feature I would add in my C' extensions.
>
> My question is what would be the syntax for C? Like C++?
>
What's wrong with the current syntax? It should be fairly easy to write
a macro to shorten the typing or have a keyboard shortcut in the IDE.
> I think the possible syntax for C could be something similar
> of struct initializer.
>
>
> typedef struct{
> int x;
> int y;
> } Point;
>
> void F(Point pt){}
>
> Point pt = { .x = 1, .y = 2};
> F((Point){ .x = 1, .y = 2});
>
And why not
Point NewPoint(int x,int y);
????
Why make it obfuscated when we can write it clearly like that?
> Using an similar syntax:
>
> int (*F)(int) = int (*)(int i){ return 2*i; }
>
> F2(int (*)(int i)
> { return 2*i;
> });
>
> What do think?
Maybe, but that looks fairly incomprehensible to do the same thing...
> Do you see any problem to parse this?
No, the problem is not parsing.
I just do not see what this obfuscated syntax brings as improvement.
> Would you prefer the C++ syntax?
>
I would prefer the C syntax.
> I assume everyone would agree that this feature is useful.
> If not, why?
>
I do not see what do you want to do, i.e. a practical application of
that syntax.
Or such.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-03-13 06:13 -0700 |
| Message-ID | <505ca0ae-f3b2-4e10-a42a-b0db2d0eb0fa@googlegroups.com> |
| In reply to | #105823 |
On Saturday, March 11, 2017 at 5:45:51 PM UTC-3, jacobnavia wrote:
> Le 08/03/2017 à 19:04, Thiago Adams a écrit :
> >
> > One feature I miss from C++ is lambdas expressions.
> >
> > In C++, we can create a function pointer like this:
> >
> > int (*F)(int) = [](int i) -> int
> > {
> > return i * 2;
> > };
> >
> > F(1);
> >
> > and also pass it as a function argument.
> >
> > void F2(int (*F)(int));
> >
> > F2([](int i) -> int
> > {
> > return i * 2;
> > });
> >
> > When a C++ lambda doesn't have any capture of variables
> > ( the [] part ) it is convertible to normal function pointer.
> >
> > This feature could be added as it is into the C language.
> > The generated code is an internal linkage anonymous function.
> >
>
> What about
>
> int anonymousFunction1(int i)
> {
> return i*2;
> }
>
> int (*F2)(int);
>
> F2 = anonymousFunction1;
For just one callback the advantage is not so big.
>
> > This is a kind of feature I would add in my C' extensions.
> >
> > My question is what would be the syntax for C? Like C++?
> >
>
> What's wrong with the current syntax? It should be fairly easy to write
> a macro to shorten the typing or have a keyboard shortcut in the IDE.
One motivation for this syntax is for asynchronous functions.
Let's say I have 3 asynchronous functions (Connect, Login, Read)
They are asynchronous and they call a callback function when they
finished.
So, Connect will call a callback after the connection is read and so on.
Then I need to login. When the login is complete I can call Read.
Now I want to create a function that does all the steps in one.
Read2(const char* url,
const char* user,
const char* password,
const char* nameOfValueToRead,
void (*Callback)(ValueFromRead value, void*p))
{
}
Try to write this function using the current C syntax.
You will have 3 anonymous functions and more anonymous structs
for capture.
The problem is like if we have to pass arguments always given
a name to then.
void F(int i, double d);
//imagine if this syntax was not allowed.
F(1, 2) ;
Would you ask what is is the problem in to have two variables?
Or.. this is not a problem because we can do it today.
int dummy_int = 1;
int dummy_double = 2;
F(dummy_int, dummy_double);
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web