Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #105584 > unrolled thread

lambda functions in C

Back to article view | Back to comp.lang.c

Contents

  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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#105866

On Sunday, March 12, 2017 at 2:13:10 PM UTC, GOTHIER Nathan wrote:
> On Sun, 12 Mar 2017 09:54:22 -0400
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
> > Malcolm is in the U.K., where automobile use is much lower than here in
> > the United States.  OTOH, bicycles are much more popular.
> 
> Not to mention that United States is the country of fat consumers by 
> choice while the urbanization is comparable to the UK.
> 
You need a car in much of the USA. In London it's mainly a nuisance -
you can't commute in because there's nowhere to park in central London -
so you need a pass which gives you unlimited free Tube (public transport)
travel. Thus the marginal cost of the car journey is far higher than
the marginal cost of the Tube journey. Then whilst there's a case for
cars going to the supermarket, the days of the big weekly shop where 
Mum bought food for the week for the family are gone.

Cars haven't "run their course", David Brown is right there. We're 
just slightly past peak car. Total car journeys fell for the first 
time ever in the recession of 2008. Whilst its back up, population
has also increased. They'll slowly be edged out, however. I don't
one but I cheat a bit because I use my father's for occasional 
necessary use.

https://www.parliament.uk/documents/commons-committees/transport/POST-briefing-on-peak-car.pdf

[toc] | [prev] | [next] | [standalone]

#105869

On Sun, 12 Mar 2017 08:08:35 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> You need a car in much of the USA. In London it's mainly a nuisance -
> you can't commute in because there's nowhere to park in central London -
> so you need a pass which gives you unlimited free Tube (public transport)
> travel. Thus the marginal cost of the car journey is far higher than
> the marginal cost of the Tube journey. Then whilst there's a case for
> cars going to the supermarket, the days of the big weekly shop where 
> Mum bought food for the week for the family are gone.

I don't believe that the majority of United States citizens is living in the
desert even though the territory is vast. Most of them are urban rather
than rural and there are shops in every street corner to eat all day long.

You're right the cost of owning an individual car is high but not really higher
than public transports with hidden cost paid by taxes. Using an individual car
may not be good for the environnment or relevant with a little effort,
nevertheless the active pullution stem from the human life while the passive
pollution stem from the planet activity.

Actually nobody can really know if the climate change is natural or artificial,
thus pretending to save the planet (not humanity) with political measures is a
scam.


> Cars haven't "run their course", David Brown is right there. We're 
> just slightly past peak car. Total car journeys fell for the first 
> time ever in the recession of 2008. Whilst its back up, population
> has also increased. They'll slowly be edged out, however. I don't
> one but I cheat a bit because I use my father's for occasional 
> necessary use.
> 
> https://www.parliament.uk/documents/commons-committees/transport/POST-briefing-on-peak-car.pdf

In fact, you still need a car because communist transport is not freedom or
reliable. However, you have the chance to count on your family whereas
capitalists would prefer to sell you an individual car sleeping in the garage
all day long after destroying your roots.

[toc] | [prev] | [next] | [standalone]

#105881

On 3/12/2017 10:10 AM, GOTHIER Nathan wrote:
> On Sun, 12 Mar 2017 09:54:22 -0400
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
>> Malcolm is in the U.K., where automobile use is much lower than here in
>> the United States.  OTOH, bicycles are much more popular.
> 
> Not to mention that United States is the country of fat consumers by choice
> while the urbanization is comparable to the UK.
> 
> https://en.wikipedia.org/wiki/Urbanization_by_country
> http://i.imgur.com/eRhICfG.jpg
> 

You have obviously never been to the United States.  But that's just
another example of your stoopidity.

Just FYI - I took my wife to breakfast this morning.  14 miles one way.
And yes, we are in the middle of a major metro area.  The closest
breakfast restaurant is about 3 miles away - no public transportation.
The one I took her to was nicer, though.

Around here, 10-15 miles each way for work is not unusual, and some
people drive 50 miles or more each way.  Again, not much for public
transportation.

No, you have absolutely no clue.  But that's just another thing you have
no clue about.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#105893

On Sun, 12 Mar 2017 14:28:31 -0400
Jerry Stuckle <jstucklex@attglobal.net> wrote:


> You have obviously never been to the United States.  But that's just
> another example of your stoopidity.

Insults won't make you smarter than you think you are...

 
> Just FYI - I took my wife to breakfast this morning.  14 miles one way.
> And yes, we are in the middle of a major metro area.  The closest
> breakfast restaurant is about 3 miles away - no public transportation.
> The one I took her to was nicer, though.

And your idol won't make United States as great as it never was...

 
> Around here, 10-15 miles each way for work is not unusual, and some
> people drive 50 miles or more each way.  Again, not much for public
> transportation.
> 
> No, you have absolutely no clue.  But that's just another thing you have
> no clue about.

Indeed, I may have no clue you actually live in the middle of nowhere if not
your rage. Don't forget your vaccine old man...

[toc] | [prev] | [next] | [standalone]

#105894

On 3/12/2017 7:03 PM, GOTHIER Nathan wrote:
> On Sun, 12 Mar 2017 14:28:31 -0400
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
> 
>> You have obviously never been to the United States.  But that's just
>> another example of your stoopidity.
> 
> Insults won't make you smarter than you think you are...
>

No insult, Nathan.  Just the truth.

>  
>> Just FYI - I took my wife to breakfast this morning.  14 miles one way.
>> And yes, we are in the middle of a major metro area.  The closest
>> breakfast restaurant is about 3 miles away - no public transportation.
>> The one I took her to was nicer, though.
> 
> And your idol won't make United States as great as it never was...
> 

It will be even greater than it ever has been.

>  
>> Around here, 10-15 miles each way for work is not unusual, and some
>> people drive 50 miles or more each way.  Again, not much for public
>> transportation.
>>
>> No, you have absolutely no clue.  But that's just another thing you have
>> no clue about.
> 
> Indeed, I may have no clue you actually live in the middle of nowhere if not
> your rage. Don't forget your vaccine old man...
> 

How about Washington, DC?  Not really the "middle of nowhere".

I just call stoopid trolls like you exactly what you are.  But no rage
here - idiots like you aren't worth it.

So once again - I've been to the UK as well as several other countries
in Europe.  I know what I'm talking about.  How many times have you been
to the U.S.?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#105873

On 12/03/17 14:54, Jerry Stuckle wrote:
> On 3/12/2017 9:14 AM, David Brown wrote:
>> On 11/03/17 21:02, Malcolm McLean wrote:
>>> On Saturday, March 11, 2017 at 6:48:47 PM UTC, David Brown wrote:
>>>> On 11/03/17 19:26, Malcolm McLean wrote:
>>>>> On Saturday, March 11, 2017 at 4:17:51 PM UTC, David Brown wrote:
>>>>>> On 10/03/17 21:26, Malcolm McLean wrote:
>>>>>>
>>>>>> I have to ask - to what are you referring as "/the/ important
>>>>>> problem in software design" ?
>>>>>>
>>>>>> The important problem is how to achieve behaviour (which we know
>>>>>> computers are capable of), to time and in a form which is usable
>>>>>> by our clients / customers / fans.
>>>>
>>>> Ah, so the single major problem in software design today is how to do
>>>> good software design?
>>>>
>>>> Your claim is a bit like telling us that "Bicycles are getting really
>>>> popular now.  Why now?  Because cars have run their course - no one now
>>>> believes they solve the important problem in transportation."  The
>>>> important problem in transportation being transporting things.
>>>>
>>> Yes,, but it's true enough to say that bicycles are getting really
>>> popular now, because cars have run their course - congestion, pollution,
>>> danger to pedestrians.
>>
>> I suppose you must be using the phrase "run their course" in a different
>> way from everyone else.  Horse-drawn carriages have run their course -
>> they are very rarely bought or used these days.  Cars are extremely
>> popular, both for using existing cars and as a choice for new
>> transportation uses.  They have /not/ "run their course", by any stretch
>> of the imagination.
>>
>
> Malcolm is in the U.K., where automobile use is much lower than here in
> the United States.  OTOH, bicycles are much more popular.
>

I know.  I am from the UK (Scotland) myself and did not consider the 
situation in the USA.  But even in bike friendly countries like the 
Netherlands, no one would consider cars as having "run their course".

>>>
>>> However C++ software projects very frequently do fail. You don't get
>>> a workable product before time and money run out. Of course projects
>>> built with C can also fail, but it's not at all clear that the "++"
>>> in C++ actually indicates that the success rate is greater.
>>
>> C++ is not an OOP language - it is a "multi-paradigm language".  It
>> started life from adding OOP features to C (to go along with the
>> existing procedural programming), but it also supports generic
>> programming and steadily more functional programming - as well as the
>> original procedural or imperative programming.
>>
>
> You can do true OOP in C++, so in that respect it is an OOP language.
> No, you don't HAVE to do OOP, but that does not mean it is not an OOP
> language.

C++ is a language that has lots of features to support OOP, so yes, it 
is an OOP language in that respect.  My point is that it is not /only/ 
an OOP language.  Malcolm seems to equate C++ and OOP, which is wrong.

>
>> Software projects in general often fail (at least to some extent).  I
>> know of no correlation between the choice of language and the risk of
>> failure showing that the language itself and/or the use of OOP is to blame.
>>
>
> Software projects fail for a number of reasons.  I've been involved with
> several large C++ projects over the years which have had great success.
> At the same time, I've been involved with some C projects which have failed.

Agreed.  As long as you make a decent choice of language for a project, 
then it is unlikely to be the language itself that determines success or 
failure.

[toc] | [prev] | [next] | [standalone]

#105875

On Sunday, March 12, 2017 at 5:18:58 PM UTC, David Brown wrote:
>
> C++ is a language that has lots of features to support OOP, so yes, it 
> is an OOP language in that respect.  My point is that it is not /only/ 
> an OOP language.  Malcolm seems to equate C++ and OOP, which is wrong.
> 
I might seem to but I don't. A common reason for going from C to C++
was to use OOP, but nowadays the automatic memory cleanup (I won't
call it garbage collection because it works in a  different way) and
bounds-checking is maybe a bigger draw.
>
> Agreed.  As long as you make a decent choice of language for a project, 
> then it is unlikely to be the language itself that determines success or 
> failure.
>
Some C projects fail and some C++ projects succeed. So implementation
language is not the only factor. That doesn't make it irrelevant. 

[toc] | [prev] | [next] | [standalone]

#105885

On 12/03/17 18:42, Malcolm McLean wrote:
> On Sunday, March 12, 2017 at 5:18:58 PM UTC, David Brown wrote:
>>
>> C++ is a language that has lots of features to support OOP, so yes, it
>> is an OOP language in that respect.  My point is that it is not /only/
>> an OOP language.  Malcolm seems to equate C++ and OOP, which is wrong.
>>
> I might seem to but I don't. A common reason for going from C to C++
> was to use OOP, but nowadays the automatic memory cleanup (I won't
> call it garbage collection because it works in a  different way) and
> bounds-checking is maybe a bigger draw.

There are many, many reasons why one might want to go from C to C++. 
OOP is one of those, but it is far from the only one.  Several people in 
this group have said they prefer to use a C++ compiler to compile their 
C code, because it does better type checking - it is not uncommon to use 
C++ simply as "a better C".  Features such as better "const", function 
overloading, and namespaces are not OOP, but they make C++ a more 
flexible language for procedural programming than C.

It is, however, fair to say that OOP /used/ to be a more significant 
reason to pick C++, as it took a while for the language, the tools, the 
idioms, and the programmers to be good at generic programming, and now 
some functional programming.

>>
>> Agreed.  As long as you make a decent choice of language for a project,
>> then it is unlikely to be the language itself that determines success or
>> failure.
>>
> Some C projects fail and some C++ projects succeed. So implementation
> language is not the only factor. That doesn't make it irrelevant.
>

There is nothing but your claim and your conflation of C++ and OOP to 
indicate that it /is/ relevant - at least in the C vs. C++ context. 
(I'd agree that picking "whitespace" as the project language would make 
it likely to fail.)

[toc] | [prev] | [next] | [standalone]

#105722

On Thursday, March 9, 2017 at 7:48:40 PM UTC-6, Jerry Stuckle wrote:
> LISP still has it's place, and is still used in some circles.
> additionally, it provides the basic concepts for many languages.  And I
> would consider a language that is still used after almost 60 years to be
> quite successful.  How many other languages can you say have done that?

LISP demonstrated a new storage paradigm which may not have been practical at
the time, but has become the primary--if not only--storage paradigm used in
21st century programming languages.  Calling it a failure would be like
calling the Wright Brothers' leading-canard biplane (Flyer) a failure, since
leading-canard biplanes have been almost completely replaced by tail-
stabilized monoplanes.

[toc] | [prev] | [next] | [standalone]

#105729

On Friday, March 10, 2017 at 9:09:45 AM UTC-6, supe...@casperkitty.com wrote:
> LISP demonstrated a new storage paradigm which may not have been practical at
> the time, but has become the primary--if not only--storage paradigm used in
> 21st century programming languages.

I meant to say that in many 21st-century programming languages it is
essentially the only paradigm, that not that people aren't still developing
languages which use other paradigms.

[toc] | [prev] | [next] | [standalone]

#105710

On 9 Mar 2017 23:05:44 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> >Thus he's right, LISP isn't very successful in the real world.
> 
>   Success means to make loads of money /and/ pass on your genes.
> 
>   Everything that has been introduced into mainstream programming
>   languages since the 50s came from LISP.
> 
>   Garbage collection, lambdas and closures, metaprogramming,
>   run-time typing, recursion, constructors (CONS), eval,
>   you name it. JavaScript is a kind of LISP in Java syntax.
> 
>   So LISP was very successful (one cannot make a statement about
>   the money part, though, because a programming language does not
>   have a bank account; but at least there's Paul Graham.)
> 

Money is a carrier of value. If LISP is evaluated to zero in the software
industry, it means the language isn't very successful in providing a tool to
write good code by any human being.

[toc] | [prev] | [next] | [standalone]

#105657

On Wednesday, March 8, 2017 at 6:55:13 PM UTC-3, Malcolm McLean wrote:
> On Wednesday, March 8, 2017 at 6:04:26 PM UTC, Thiago Adams wrote:
> > One feature I miss from C++ is lambdas expressions.
> > 
> 
> > This feature could be added as it is into the C language.
> > The generated code is an internal linkage anonymous function.
> > 
> > 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++?
> > 
> Baby X makes extensive use of lambdas.
> 
> The rule is to always pass back a context pointer to the callback.
> So a Baby X button does not just execute a function, it executes
> a function with user-provided context. That means that it scales up,
> typically the context is the structure that provides state for
> the dialog. If it's an OK button it sets the OK flag before
> terminating, if a cancel button the OK flag is cleared. We can
> then have many dialogs doing different things and even two instances
> of the same dialog (e.g. a colour picker)  in the same program.
> 
> The only disadvantage is the the lamda's closure is not automatically
> destroyed when the function pointer goes out of use. Unfortunately
> destructors are not easy to add to C. But that one little detail can 
> in no way justify the complexity of C++.

I managed the lifetime of the variable captures depending if the 
lambda is executed-once or not.
For those executed once, typically I have one important rule.
The callback is _ALWAYS_ called and the callback is 
responsible for free the capture variables that are 
on the heap.

typedef void (*Callback)(int result, void* capture);

voif DoAsync(Callback callback, void* capture);

The result reports success, failure or cancel.
The capture is deleted doesn't matter the result. 

Using this pattern I can have just the pair 
[function pointer, void *data] to represent the lambdas
and it's not necessary to have an extra function pointer
that knows how to free data. the callback is at the same 
time the callback + the destructor of *data.
In case I want to call many times the same callback I also
can use a especial result that is "this is the destructor call"
and the callback will delete the data only for this especial result.

[toc] | [prev] | [next] | [standalone]

#105648

Thiago Adams <thiago.adams@gmail.com> writes:

> One feature I miss from C++ is lambdas expressions.
[...]
> This feature could be added as it is into the C language.
> The generated code is an internal linkage anonymous function.
>
> 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++?

Apple's Grand Central Dispatch uses something similar. It's called
"blocks" (!).

https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html

It seems they have proposed adding this to the standard.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf

-- Alain.

[toc] | [prev] | [next] | [standalone]

#105670

In article <da2ac707-2a39-41c2-9ac4-20c4811318e8@googlegroups.com>,
 Thiago Adams <thiago.adams@gmail.com> 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.

-- 
:-<> 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]

#105676

On Thursday, March 9, 2017 at 4:48:56 PM UTC, Siri Cruise wrote:
> In article <da2ac707-2a39-41c2-9ac4-20c4811318e8@googlegroups.com>,
>  Thiago Adams <thiago.adams@gmail.com> 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.
> 
Not really. A destructor is not garbage-collected, it is triggered when
the object reaches the end of its lifetime. In C that has to be done by
hand, which means passing in two function pointers, the pointer to the
lambda function, and the pointer to the destructor for the closure.

Baby X doesn't do that, the number of times it's actually needed is too 
small to justify the complexity.

[toc] | [prev] | [next] | [standalone]

#105679

On Thursday, March 9, 2017 at 2:45:18 PM UTC-3, Malcolm McLean wrote:
[...]
> > A closure requires some kind of garbage collection.
> > 
> Not really. A destructor is not garbage-collected, it is triggered when
> the object reaches the end of its lifetime. In C that has to be done by
> hand, which means passing in two function pointers, the pointer to the
> lambda function, and the pointer to the destructor for the closure.

I use the same function for both in many cases. (call once closure)

[toc] | [prev] | [next] | [standalone]

#105678

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.

[toc] | [prev] | [next] | [standalone]

#105681

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.

[toc] | [prev] | [next] | [standalone]

#105682

On 03/10/17 08:08 AM, 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.


How would you pass that to something like qsort?


-- 
Ian

[toc] | [prev] | [next] | [standalone]

#105685

On Thursday, March 9, 2017 at 7:22:55 PM UTC, Ian Collins wrote:
> On 03/10/17 08:08 AM, Malcolm McLean wrote:
> 
> > But what you can't do is then store the closure for use later.
> 
> 
> How would you pass that to something like qsort?
> 
qsort is misdesigned. It doesn't take a context pointer. Generally
that doesn't matter, because as is common with most advanced programming
constructs, what it is actually used for is providing  a trivial
comparison operator on a filed of a structure, usually. But just
occasionally you want to sort a list of integer indices into an
array rather than the array itself. That's impossible without making the
array global, which can be very undesirable.

Context pointers can be and frequently are null.

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web