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

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

The C Containers Library

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

Contents

  The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-08 21:53 +0200
    Re: The C Containers Library aftnix <aftnix@gmail.com> - 2012-07-26 13:13 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:31 +0200
        Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-28 17:46 -0400
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 02:05 +0200
            Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-30 14:48 -0400
            Re: The C Containers Library Phil Bradby <nospam@nospam.com> - 2012-08-01 21:00 +0000
              Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-01 23:18 +0200
              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-02 00:48 -0700
                Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 07:00 -0400
                  Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-02 13:27 +0200
                    Re: The C Containers Library Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-08-02 20:27 +0000
                  Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-02 05:13 -0700
                  Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-02 14:26 -0700
                    Re: The C Containers Library Kenneth Brody <kenbrody@spamcop.net> - 2012-08-03 10:47 -0400
          Re: The C Containers Library Noob <root@localhost> - 2012-07-29 09:58 +0200
            Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:31 -0600
              Re: The C Containers Library Noob <root@localhost> - 2012-07-30 09:45 +0200
                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:10 -0700
            Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-30 14:54 -0400
      Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-26 16:52 -0400
        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:56 +0200
          Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-26 22:29 +0000
            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 01:50 +0200
              Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-27 22:28 +0000
            Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-29 06:31 -0700
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:26 -0600
                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:21 -0700
                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:27 -0600
                    Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-02 16:43 +0100
                      Re: The C Containers Library Ansel <lateknightdev@gmail.com> - 2012-08-02 17:07 -0700
                        Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-03 22:21 +0100
                          Re: The C Containers Library Ansel <lateknightdev@gmail.com> - 2012-08-03 15:43 -0700
                            Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-04 06:32 +0200
                              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-04 01:52 -0700
                                Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:36 -0600
                                  Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-05 08:36 +0200
                                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 01:28 -0600
                                      Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-05 11:31 +0200
                                        Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 03:48 -0600
              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-04 03:41 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 01:55 +0200
    Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 13:45 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:53 +0200
        Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 18:46 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 10:59 +0200
            Re: The C Containers Library gwowen <gwowen@gmail.com> - 2012-07-27 03:39 -0700
            Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 11:34 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 11:04 +0200
            Re: The C Containers Library W Karas <wkaras@yahoo.com> - 2012-07-27 13:10 -0700
    Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 18:54 -0700
      Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-27 10:25 -0400
        Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 11:28 -0700
          Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-27 15:17 -0400
            Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 13:00 -0700
            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 02:02 +0200
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-28 22:08 -0600
                Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 08:46 +0200
                  Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-29 07:43 +0000
                    Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 09:59 +0200
                      Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-29 06:43 -0700
                      Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-29 17:27 +0000
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 20:56 +0200
                          Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-30 00:07 +0000
                          Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:07 -0600
                        Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-29 11:58 -0700
                          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 22:06 +0200
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 22:23 +0200
                          Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-30 00:13 +0200
                            Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:13 -0600
                              Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 01:10 -0700
                                Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 02:57 -0600
                                  Re: The C Containers Library Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-07-30 15:47 +0000
                                  Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 13:01 -0700
                                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 04:53 -0700
                                  Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 13:04 -0700
                                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:11 -0600
                                    Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 06:52 -0400
                                  Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 06:46 -0400
                          Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-30 00:41 +0100
                            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-30 09:45 +0200
                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-29 23:05 -0600
                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-29 22:52 -0600
                    Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 04:56 -0700
                      Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:07 -0600
                    Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-30 17:49 +0200
          Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-28 09:17 +0100
            Re: The C Containers Library W Karas <wkaras@yahoo.com> - 2012-07-28 15:17 -0700
              Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-29 11:10 +0100
          Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-28 06:51 -0700
            Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-28 17:23 +0100
              Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-30 13:40 -0700
                Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-31 00:24 +0200
            Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-31 00:05 +0200
            Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-31 00:53 +0100
              Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-31 09:24 +0200
              Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-02 14:45 -0700
                Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-03 22:31 +0100
                  Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 00:01 +0200
                    Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-03 23:45 +0100
                      Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:47 -0600
                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:41 -0600
                    Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-07 10:24 +0100
                      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-07 15:30 +0200
                        Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-07 15:35 +0100
                          Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 12:40 -0700
                            Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 00:07 +0100
                              Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 17:31 -0700
                                Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 03:14 +0100
                                  Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-08 05:22 -0700
                        Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 12:36 -0700
                      Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-08 02:26 -0700
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-08 17:25 +0200
              Re: The C Containers Library 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-03 16:04 -0700
    Re: The C Containers Library SG <s.gesemann@gmail.com> - 2012-08-04 04:52 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 18:42 +0200
        Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 19:17 +0000
          Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 19:22 +0000
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 22:14 +0200
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-05 00:15 +0200
            Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 23:13 +0000
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:53 -0600

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

#24237

Ben Bacarisse wrote:
> jacob navia <jacob@spamsink.net> writes:
> <snip>
>> This means that C++ has become such a complex software construct that
>> it is impossible for its creator (Mr Bjarne Stroustrup) to fully
>> understand the consequences of a language enhancement.
>
> In informal contexts like this I'd say it's perfectly acceptable to
> say "Bjarne Stroustrup", but if you're going to give him a title,
> give him the right one.  He has a PhD from Cambridge, and holds the
> College of Engineering Chair in Computer Science at Texas A&M
> University.  Using "Mr" could be misconstrued.
>

Credentials vs. substance. PhD: one who followed the path of knowing more 
and more about less and less? I do not accept credentials as proof of 
ability. How could one escape the awful "mind think" by being sheltered in 
institutional processes all the time?

Food for thought. 

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

#24236

jacob navia wrote:

> In all my life as a programmer I have tried to keep things SIMPLE.
> That is why I like (and use) the C language. C is a language that
> can be understood in full by a person.
>

C: such utter simplicity, that it is simply incorrect (i.e., violates the 
principle of KISS-but-not-simpler-than-required).
C++: such utter complexity that it leads to incorrect code.

Pick your poison I guess. 

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

#24344

jacob navia wrote:

> Le 03/08/12 23:31, Rui Maciel a écrit :
>>
>> Again, where do you base your assertion that C++ is in decline since
>> 2003? Do you actually base your assertion on any tangible evidence or did
>> you made that up?
>>
> 
> I would not say that c++ is in "the decline" but there are some
> developments that are noteworthy.
> 
> 1) After several YEARS of work, the creator of the language declares
> that he is unable to add a new feature to the language.
> 
> This means that C++ has become such a complex software construct that
> it is impossible for its creator (Mr Bjarne Stroustrup) to fully
> understand the consequences of a language enhancement. This shows
> us the level of complexity reached by C++.

Could you provide a source for that quote?  Stroustrup, in his FAQ, doesn't 
refer to that.  In fact, there is a section that covers the addition of new 
features to C++, and the only criticism that he makes is that it isn't a 
good idea to add "every feature that someone considers a good idea", and 
that it isn't easy to remove older features from C++.

http://www.stroustrup.com/C++11FAQ.html#what-features


> 2) Undeterred by this fact, the new standard piles up yet another thick
> software layer into the already brittle edifice. Lambdas, and other
> esoteric constructs add more complexity as if increasing the
> number of language constructs and their unforeseen interactions
> was a good thing!

What's wrong with lambdas?  All they do is essentially provide syntactic 
sugar to either define a function object or a simple function.

http://www.stroustrup.com/C++11FAQ.html#lambda

Personally, I find lambdas to be an invaluable addition to the language 
just for a single reason: they'll replace function-like macros in a 
significant number of applications.


<snip/>

> 4) All C++ programmers (besides Bjarne) use a portion of the huge
> language since it is not possible to fit every detail of that into a
> human brain.
> 
> This means that only the overlapping portions of the language can be
> understood by all of them, and a proliferation of "C++ subsets" starts
> that makes communication between programmers more difficult.

I don't see how this can be seen as a problem.  For example, just because we 
have a set of tools in our toolbelt it doesn't mean we should be forced to 
use every single one of them whenever we need to pick up a screw driver.

In addition, I don't see there is a problem if we don't need to use a 
feature provided by the language.  For example, function pointers aren't 
necessarily present in every C program, and not using them isn't exactly a 
problem.  So, why should it be a problem if, with some other programming 
language, a project doesn't use a specific language feature?


> In all my life as a programmer I have tried to keep things SIMPLE.
> That is why I like (and use) the C language. C is a language that
> can be understood in full by a person.
> 
> Yes, I know. You will tell me that the complexity is in the language
> instead of in every program that uses the language and that a complex
> language simplifies programs. Yes, I do KNOW that.
> 
> But there is a point of diminishing returns where you add complexity to
> the language trying to be all things to everyone and you end up with
> being a complexity monster for everyone.
> 
> I know that you like C++ Rui, and I hope you do not feel personally
> attacked since I am talking about a computer (machine) language.
>
> We tend to get attached to languages because of other philosophical
> reasons. For instance the fact that I like small and simple computer
> languages comes from my beliefs that "small is beautiful" from my youth,
> and many other things that are more or less completely irrelevant here.
> 
> Let's try to put all that baggage aside and discuss in a rational
> manner.

I didn't felt personally attacked.  Far from it.  And if, for some reason, I 
was forced to choose which language, between C and C++, would be removed 
from the world, I would gladly keep C around instead of C++.

Yet, just because someone prefers to use C instead of some other language it 
doesn't grant them the right to throw around absurd claims, even if those 
claims are posted to comp.lang.c.  No matter how someone prefers C over C++, 
claims such as "the STL made the syntax for just declaring an array and 
stepping through it too cumbersome" are just blatantly wrong and completely 
detached from reality.  There are plenty of issues that affect each 
language, and we don't help anyone or anything if the only criticism we are 
able to muster comes in the form of made up nonsense.


Rui Maciel

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

#24349

Le 07/08/12 11:24, Rui Maciel a écrit :
> What's wrong with lambdas?  All they do is essentially provide syntactic
> sugar to either define a function object or a simple function.

There is nothing wrong with lambdas as such. What is wrong is trying to 
add yet a layer of sugar to a cake that is 80% sugar already!

Lambdas can be replaced by function pointers or classes. Classes retain 
also state during calls (using some private variable) and they are
already well tested. Function pointers also.

Yes, lambdas (anonymous functions) are handy, but the problem is that
they add MORE complexity to an already extremely complex product.

Each feature in isolation looks reasonable and justified. When you
add them up, however, problems arise.

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

#24350

jacob navia <jacob@spamsink.net> writes:

> Le 07/08/12 11:24, Rui Maciel a écrit :
>> What's wrong with lambdas?  All they do is essentially provide syntactic
>> sugar to either define a function object or a simple function.
>
> There is nothing wrong with lambdas as such. What is wrong is trying
> to add yet a layer of sugar to a cake that is 80% sugar already!

That's a catchy phrase, but adding one metaphor to another does not
always make sense.  Syntax is called "sugar" when it improves things --
in this case by making a construct simpler.  It not obviously true that
adding simplifying syntax is wrong, even when you have a lot of it.  I
think the case needs be made, feature by feature, not by saying "we've
got too much sugar already".

> Lambdas can be replaced by function pointers or classes. Classes
> retain also state during calls (using some private variable) and they
> are
> already well tested. Function pointers also.
>
> Yes, lambdas (anonymous functions) are handy, but the problem is that
> they add MORE complexity to an already extremely complex product.

C++'s lambdas are not closures (I am sure you know this) so they don't
add any new concepts.  They do, however, greatly simplify what you'd
have to write in their place.  In my view, they pay their way.

> Each feature in isolation looks reasonable and justified. When you
> add them up, however, problems arise.

That depends on how they are organised.  When language features are
piled on top of each other, you can get great complexity.  Mathematics
is an example of this.  Many, many, layers are needed to understand
something like "a Hamel basis of an infinite-dimensional Banach space is
uncountable" because the notions involved all build on top of other
notions that are themselves far from basic.  C++ is not like that.  The
features don't, in general, build one on top of one another.  It is
broad and shallow rather than narrow and deep.  Yes, there is a lot to
learn, but you don't really need to learn it all.  Just as I'd use a
broad library like Java's with a reference manual next to me, I would
not commit to memory every aspect of C++.  You need to know what's
there, but you don't need to know all the details.

I'm not denying that C is much simpler than C++; it is; much, much,
simpler, but that simplicity comes at a price which is not always worth
paying.  It would be, if C++ were unmanageable, but I don't feel it is.

I would be great to be able to start again.  Inside modern C++ there is
a great programming language struggling to get out, but that language
would never have become popular, and the C++ we have now can't be
trimmed back without breaking it.

-- 
Ben.

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

#26078

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> C++'s lambdas are not closures (I am sure you know this) so
> they don't add any new concepts.

Forgive my ignorance - how are lambdas different from closures?
I know a lot about closures, but only a little about C++ lambdas.


> They do, however, greatly simplify what you'd have to write in
> their place.  In my view, they pay their way.

Based on the little I already know about them, I'm inclined
to agree.

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

#26098

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> C++'s lambdas are not closures (I am sure you know this) so
>> they don't add any new concepts.
>
> Forgive my ignorance - how are lambdas different from closures?
> I know a lot about closures, but only a little about C++ lambdas.

Then I'm sure the difference is just one of interpreting the term.

The main point, for me, is that C++ lambdas are not simply a piece of
code that can refer to the environment being "closed over".  They don't
treat the environment in a uniform way as a closure would.  For example:

  struct S { int i; };
  enum { name = 42; };
  int i;
  auto l = []{ S s = {name}; };

The lambda body can refer to 'S' and 'name' (and, incidentally, all
'global' names like functions and file-scope object names) but it can't
refer to 'i' unless we specify either a default or an explicit capture
mode (by reference or by copy).

C++'s "capture by copying" is very useful, but it's not at all what a
"plain" closure does (thought you can get the same effect easily enough
using closures).  Capture by reference is very close, except for two
things: the non-uniform treatment of the environment I've already
mentioned, and the fact that the capture has no effect on the lifetime
of the object referenced.

Now this last point could be argued because C++ is simply not that sort
of language.  It has no garbage collection, so there is no solution but
to treat captured references like any other, but it limits what you can
do in non-trivial ways.

<snip>
-- 
Ben.

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

#26108

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> C++'s lambdas are not closures (I am sure you know this) so
>>> they don't add any new concepts.
>>
>> Forgive my ignorance - how are lambdas different from closures?
>> I know a lot about closures, but only a little about C++ lambdas.
>
> Then I'm sure the difference is just one of interpreting the term.
>
> The main point, for me, is that C++ lambdas are not simply a piece of
> code that can refer to the environment being "closed over".  They don't
> treat the environment in a uniform way as a closure would.  For example:
>
>   struct S { int i; };
>   enum { name = 42; };
>   int i;
>   auto l = []{ S s = {name}; };
>
> The lambda body can refer to 'S' and 'name' (and, incidentally, all
> 'global' names like functions and file-scope object names) but it can't
> refer to 'i' unless we specify either a default or an explicit capture
> mode (by reference or by copy).
>
> C++'s "capture by copying" is very useful, but it's not at all what a
> "plain" closure does (thought you can get the same effect easily enough
> using closures).  Capture by reference is very close, except for two
> things: the non-uniform treatment of the environment I've already
> mentioned,

This part is what I'm confused about.  If there's a default
by-reference capture mode, how is the treatment of the
environment non-uniform?  My assumption is that giving
a default capture mode of reference affects all variables
in the outer environment the same way (obviously types and
enum's are different, but that doesn't matter since they
can't change).

> and the fact that the capture has no effect on the lifetime
> of the object referenced.  [snip elaboration]

I get that, this difference is the one I was expecting,
and was wondering what other differences there might be.

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

#26115

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> C++'s lambdas are not closures (I am sure you know this) so
>>>> they don't add any new concepts.
>>>
>>> Forgive my ignorance - how are lambdas different from closures?
>>> I know a lot about closures, but only a little about C++ lambdas.
>>
>> Then I'm sure the difference is just one of interpreting the term.
>>
>> The main point, for me, is that C++ lambdas are not simply a piece of
>> code that can refer to the environment being "closed over".  They don't
>> treat the environment in a uniform way as a closure would.  For example:
>>
>>   struct S { int i; };
>>   enum { name = 42; };
>>   int i;
>>   auto l = []{ S s = {name}; };
>>
>> The lambda body can refer to 'S' and 'name' (and, incidentally, all
>> 'global' names like functions and file-scope object names) but it can't
>> refer to 'i' unless we specify either a default or an explicit capture
>> mode (by reference or by copy).
>>
>> C++'s "capture by copying" is very useful, but it's not at all what a
>> "plain" closure does (thought you can get the same effect easily enough
>> using closures).  Capture by reference is very close, except for two
>> things: the non-uniform treatment of the environment I've already
>> mentioned,
>
> This part is what I'm confused about.  If there's a default
> by-reference capture mode, how is the treatment of the
> environment non-uniform?  My assumption is that giving
> a default capture mode of reference affects all variables
> in the outer environment the same way (obviously types and
> enum's are different, but that doesn't matter since they
> can't change).

The term "the outer environment" needs some clarification.  A lambda has
access to (and can change) a variable declared at file scope even when
you have no capturing specified:

  int i = 0;
  void f()
  {
      int j; // for later...
      auto l = []{i = 42;};
      l();
  }

Calling f() changes i.  The capturing only applies to automatic objects.

When you say "if there's a default by-reference capture mode" do you
mean that you are only really asking about lambdas that use that mode
because it's not a default mode for all lambdas?  The one above, for
example, can't access j.  Changing [] to [&] allows it access to j, but
has no effect on it's access to i (so far as I know).  Using [=] has the
effect of making a read-only copy of j, but leaves i writable.

If you know what's going on under the hood, it all makes a reasonable
amount of sense, but it's probably a little odd-looking if you don't.
I'd find it fiddly to explain to someone, whereas the idea of a closure
is really very straight forward.

>> and the fact that the capture has no effect on the lifetime
>> of the object referenced.  [snip elaboration]
>
> I get that, this difference is the one I was expecting,
> and was wondering what other differences there might be.

It's a mixed bag, really.  The form [](args){body} is not really a
closure at all (it's just an anonymous function pointer) but
[&](args}{body} is pretty much indistinguishable from a closure.  The
[=](args){body} form is a curious thing that's, well, curious (but
useful).

-- 
Ben.

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

#26134

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [..somethin..]
>
> [... snip detailed explanation of C++ lambdas ...]
>
> It's a mixed bag, really.  The form [](args){body} is not really a
> closure at all (it's just an anonymous function pointer) but
> [&](args}{body} is pretty much indistinguishable from a closure.  The
> [=](args){body} form is a curious thing that's, well, curious (but
> useful).

Excellent explanation.  Turns out I wasn't as confused as I
thought I was, but I wouldn't have known that without your
comments (or possibly a lot of work on my part looking for
the information elsewhere).  Thank you for taking the time
to explain it all.

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

#26077

jacob navia <jacob@spamsink.net> writes:

> Le 07/08/12 11:24, Rui Maciel a @C3{A9}crit :
>> What's wrong with lambdas?  All they do is essentially provide syntactic
>> sugar to either define a function object or a simple function.
>
> Lambdas can be replaced by function pointers or classes.
> Classes retain also state during calls (using some private
> variable) and they are already well tested.  Function pointers
> also.

Lambdas have another important property, specifically being able
to reference variables outside of the lambda but local to the
calling environment (ie, function/method body) where the lambda
is defined/created.  Neither classes nor function pointers do
this.  It can be simulated, clumsily, with classes, and still
more clumsily using function pointers.  But, why stop there?  All
this can be simulated without lambdas, classes, or even function
pointers, using just regular pointers, structs, and functions.
Personally, I prefer the convenience of closures (which I have
used in various different contexts) or (probably) lambdas, which
I can only speculate about since I haven't used C++ lambdas
specifically.

Incidentally, for C-like languages, it is possible to implement a
lambda-like construct in such a way that they are interchangeable
with function pointers.  That is, a function being called couldn't
tell whether it is getting a pointer-to-function or a closure (or
lambda) instance as one of its pointer-to-function parameters (and
ditto for variables).  The D language does this.  So rather than
complexifying a language, this unification results (to my way of
thinking, anyway) in a simplification.  Granted, the language has
gotten somewhat bigger, but programs get smaller - there is a
significant power in being able to put together easily a local
function body and send the function off somewhere to get some
work done in a generalized context.

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

#24371

On Aug 7, 10:24 am, Rui Maciel <rui.mac...@gmail.com> wrote:
> jacob navia wrote:
> > Le 03/08/12 23:31, Rui Maciel a écrit :

<snip>

> > I would not say that c++ is in "the decline" but there are some
> > developments that are noteworthy.
>
> > 1) After several YEARS of work, the creator of the language declares
> > that he is unable to add a new feature to the language.
>
> > This means that C++ has become such a complex software construct that
> > it is impossible for its creator (Mr Bjarne Stroustrup) to fully
> > understand the consequences of a language enhancement. This shows
> > us the level of complexity reached by C++.
>
> Could you provide a source for that quote?

I assume Jacob is referring to "Concepts". And it isn't really
a quote but an interpretation of what happened. This is
Bjarne Stroustrup on the subject

http://www.devx.com/cplus/Article/42448/0/page/1

it appear they *did* underestimate the difficulty of the task.
But design's like that; you don't know how how hard it
is until you've done it.

> Stroustrup, in his FAQ, doesn't
> refer to that.  In fact, there is a section that covers the addition of new
> features to C++, and the only criticism that he makes is that it isn't a
> good idea to add "every feature that someone considers a good idea", and
> that it isn't easy to remove older features from C++.
>
> http://www.stroustrup.com/C++11FAQ.html#what-features

that's a list of what they added. Not what they declined to add.

<snip>

> > 4) All C++ programmers (besides Bjarne) use a portion of the huge
> > language since it is not possible to fit every detail of that into a
> > human brain.
>
> > This means that only the overlapping portions of the language can be
> > understood by all of them, and a proliferation of "C++ subsets" starts
> > that makes communication between programmers more difficult.
>
> I don't see how this can be seen as a problem.  For example, just because we
> have a set of tools in our toolbelt it doesn't mean we should be forced to
> use every single one of them whenever we need to pick up a screw driver.

yes but if I read someone else's code I have to understand all the
features they use. And their subset may not match my subset. (actually
it's usually the other way around I have to be careful with certain
features to avoid baffling other people)

> In addition, I don't see there is a problem if we don't need to use a
> feature provided by the language.  For example, function pointers aren't
> necessarily present in every C program, and not using them isn't exactly a
> problem.  So, why should it be a problem if, with some other programming
> language, a project doesn't use a specific language feature?

C++ is a much larger language. I think most people agree on what the
commonly used core of C is. Function pointers are good example of
something that some people may find esoteric.

With C++ some people avoid exceptions or templates or the STL.
You may not consider it sane but it happens.

<snip>

> [...] just because someone prefers to use C instead of some other language it
> doesn't grant them the right to throw around absurd claims, even if those
> claims are posted to comp.lang.c.  No matter how someone prefers C over C++,
> claims such as "the STL made the syntax for just declaring an array and
> stepping through it too cumbersome" are just blatantly wrong and completely
> detached from reality.

I was wondering where that came from. Because if you really love
arrays
C++ lets you use them. Does he mean the initialisation of a
std::vector?

Stepping through an array (or a vector) doesn't have to be cumbersome.
In fact in C++11 (or whatever) I believe its quit elegant.

> There are plenty of issues that affect each
> language, and we don't help anyone or anything if the only criticism we are
> able to muster comes in the form of made up nonsense.

the Concepts thing was a bit of a disaster and template Meta
Programming
scares the crap out of me.

I love RAII (automatic cleanup) and the STL containers. If I have to
debug one more half-arsed implementaion of a linked list...

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

#24377

Le 08/08/12 11:26, Nick Keighley a écrit :
> I assume Jacob is referring to "Concepts". And it isn't really
> a quote but an interpretation of what happened. This is
> Bjarne Stroustrup on the subject

You are right. Concepts are needed in C++, because if not there is no 
way to build templates with argument checking. There was a discussion 
about that in the C++ standardization committee in France, and people 
agreed that concepts were needed. Because if they don't exist things are 
proposed like "static if" that try to test template arguments for validity.

But after years of work by brilliant people they couldn't. And I am not
blaming them. The complexities of adding such a feature are just staggering.

Personally I think that there is another way. Compile time functions 
should replace templates. But that is another discussion.

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

#24182

Rui Maciel於 2012年7月31日星期二UTC+8上午7時53分41秒寫道：
> Malcolm McLean wrote:
> 
> 
> 
> > When STL first came out I thought that maybe it was the end of C. The STL
> 
> > containers did provide runtime performance and encapsulation that you had
> 
> > to handtune C to match. But actually the result was the reverse. I think
> 
> > it was because STL made the syntax for just declaring an array and
> 
> > stepping through it too cumbersome. 
> 
> 
> 
> Could you provide an example where you demonstrate how declaring an array 
> 
> and iterating through it is "too cumbersome"?
> 
> 
> 
> 
> 
> > That was the point at whcih people
> 
> > stopped switching from C to C++, and started moving from C++ to other
> 
> > languages. 
> 
> 
> 
> Is it a personal opinion or is there any basis for that assertion?
> 
> 
> 
> 
> 
> > C++ had a huge user base behind it and is still a popular
> 
> > language. But ever since STL it's been in decline. 
> 
> 
> 
> The only time I ever heard of any real world complain regarding the STL was 
> 
> from people involved in game programming, whose complaints were somewhere 
> 
> between worries that some STL implementations might have efficiency issues 
> 
> and ignorance on the programmer's behalf.[1]  Other than this, I believe you 
> 
> will be hard-pressed to find a C++ programmer who doesn't employ the STl in 
> 
> his code.
> 

I think the vector module  in C++ is good for beginners. 


It is a list of objects that can be expanded or shrinked automatically.
( How this feature is implemented is another question.)

But I have to point out that if the length of the list is changed 
in nontrival loops or a loop of a loop, then it's the programmar's
job to be sure that no bad side effects will happen.

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

#24199

Am Sonntag, 8. Juli 2012 21:53:07 UTC+2 schrieb jacob navia:
> [...]
> "The C Containers Library"
> [...]

I just skimmed the PDF and noticed this on page 42:

   int function(void)
   {
      char listSpace[iList.Sizeof(NULL)];
      iList.Init(listSpace);
   }

I think this qualifies as an alignment issue.

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

#24215

Le 04/08/12 13:52, SG a écrit :
> Am Sonntag, 8. Juli 2012 21:53:07 UTC+2 schrieb jacob navia:
>> [...]
>> "The C Containers Library"
>> [...]
>
> I just skimmed the PDF and noticed this on page 42:
>
>     int function(void)
>     {
>        char listSpace[iList.Sizeof(NULL)];
>        iList.Init(listSpace);
>     }
>
> I think this qualifies as an alignment issue.
>

Yes. I have added a paragraph after that code:

Problems with the above construct could arise because of the alignment 
requirements of the platform
where the library is running. Instead of a char as the type
of the buffer, it is better to use a slightly more complicated 
expression to ensure correct alignment. For instance:

     size_t s = (sizeof(void *)+iList.Sizeof(NULL))/sizeof(void *);
     void *listSpace[s];

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

#24218

On 2012-08-04, jacob navia <jacob@spamsink.net> wrote:
> Le 04/08/12 13:52, SG a ?crit :
>> Am Sonntag, 8. Juli 2012 21:53:07 UTC+2 schrieb jacob navia:
>>> [...]
>>> "The C Containers Library"
>>> [...]
>>
>> I just skimmed the PDF and noticed this on page 42:
>>
>>     int function(void)
>>     {
>>        char listSpace[iList.Sizeof(NULL)];
>>        iList.Init(listSpace);
>>     }
>>
>> I think this qualifies as an alignment issue.
>>
>
> Yes. I have added a paragraph after that code:
>
> Problems with the above construct could arise because of the alignment 
> requirements of the platform
> where the library is running. Instead of a char as the type
> of the buffer, it is better to use a slightly more complicated 
> expression to ensure correct alignment. For instance:
>
>      size_t s = (sizeof(void *)+iList.Sizeof(NULL))/sizeof(void *);
>      void *listSpace[s];

It looks like the formula

    (sizeof(void *)+iList.Sizeof(NULL)) / sizeof(void *);

wastes sizeof(void*) bytes if iList.Sizeof(NULL) is a multiple of
sizeof(void*). I think the intention of the formula is to compute
iList.Sizeof(NULL) rounded upward to the next multiple of sizeof(void*),
and if that is the case,

    (sizeof(void*) - 1 + iList.Sizeof(NULL)) / sizeof(void*);

would suffice.

A slightly more serious issue is that this only fixes the alignment
problem if it is guaranteed that the alignment requirements for a
header structure are not stricter than the alignment requirements
of a void*.

If the type of the header structure were known to the program,
there would be a simpler solution:

  /* assuming the type of header structure is HEADER_STRUCTURE_TYPE */
  HEADER_STRUCTURE_TYPE headerspace;
  iList.Init(headerspace);

which would have the additional advantage that it doesn't use a
variable length array, so it would work with a pre-C99 compiler.

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

#24219

On 2012-08-04, Ike Naar <ike@faeroes.freeshell.org> wrote:
> If the type of the header structure were known to the program,
> there would be a simpler solution:
>
>   /* assuming the type of header structure is HEADER_STRUCTURE_TYPE */
>   HEADER_STRUCTURE_TYPE headerspace;
>   iList.Init(headerspace);

Sorry, that should probably be

    iList.Init(&headerspace);

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

#24220

Le 04/08/12 21:17, Ike Naar a écrit :
> (sizeof(void*) - 1 + iList.Sizeof(NULL)) / sizeof(void*);

Yes, you are right. I corrected that. Thanks.

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

#24224

Le 04/08/12 21:17, Ike Naar a écrit :
> If the type of the header structure were known to the program,
> there would be a simpler solution:

Yes, but that would break the complete separation between the 
implementation and the specifications. As it is now, a complete change 
in the inner structure of the containers doesn't need even a 
recompilation in user code since all the data types are completely 
hidden. This is a very strong requirement of the libray and I have done 
everything to ensure that all containers data types are compeletly 
opaque to user code.

This is much stronger "private" definition than in C++ where you have 
the possibility of accessing the inner structure of the container 
because they are specified in the stl headers. Here you do not have
any information about the internals.

I will provide with the library a small program that prints all those
sizes building a header file:

#include <containers.h>
int main (void)
{
    printf("#define CCL_iList_SIZE\t%d\n",iList.Sizeof(NULL));
    printf("#define CCL_iDictionary_SIZE\t%d\n",
                                      iDictionary.Sizeof(NULL));
    printf("#define CCL_iVector_SIZE\t%d\n",iVector.Sizeof(NULL));
    // ...
}

This file is stable between releases of the library but must be rebuilt 
at each release and client code that uses it must be rebuilt.

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

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

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

csiph-web