Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The C Containers Library

Reply
Thread Tools

The C Containers Library

 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-08-2012
Ben Bacarisse <> writes:

> Tim Rentsch <> 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.
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      09-09-2012
On Saturday, July 28, 2012 4:51:24 PM UTC+3, Malcolm McLean wrote:
> בת×ריך ×™×•× ×©×™×©×™, 27 ביולי 2012 19:28:19 UTC+1, מ×ת W Karas:
> > On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:
> >
> > The STL containers have been a big driver of adoption of C++ in
> > place of C. A powerful C container library (which this appears
> > to be) would be very important to maintaining C as a viable
> > alternative. So it should not be that big of a challenge.
> >

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


That is unfortunately true. The STL was standardized in head-over-heels
hurry. So its interface is not too uniform and it does confuse novices.
Also lot of things were lacking in it. C++2011 takes decent leap
to make standard library lot more complete and useful.

> That was the point at whcih people stopped switching from C to C++,
> and started moving from C++ to other languages.


1998? There did come languages to what to switch. Most popular ones
PHP, Javascript and Java (~1995), C# and Python (~2000). It is all good.
Not everything is worth writing in C or C++. Also some did regret the
move. Visual Basic for example is mostly dead now.

> C++ had a huge user base behind it and is still a popular language.
> But ever since STL it's been in decline.


That decline will not happen. What actually competes with C or C++?
Most useful things are written either in C or in C++. So nothing
competes with those languages.

> I'm current programming under Qt. However I've deliberately written
> all the non-GUI elements of the program in C. Even the C++ elements
> aren't really C++, because Qt preprocesses them to make the signals
> and slots mechanism work. C++ doesn't provide the flexiblity to do
> this natively.


That is nonsense. QT was designed 1991. C++ did not contain templates
back then. They have later taken templates to use. Maybe they will
templatize the signals and slots too one day.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are sequence containers not a subset of general containers? Sebastian Mach C++ 5 10-06-2012 07:54 PM
C library containing implementations of associative containers. Morten C Programming 3 05-07-2008 02:24 PM
Containers of iterators vs. containers of references clark.coleman@att.net C++ 7 01-25-2008 01:37 PM
Library exposing STL containers Bob C++ 2 07-26-2006 02:04 AM
Questions about destructors on std library containers Ross Boylan C++ 12 02-13-2004 03:03 AM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57