Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

The C Containers Library

 
 
W Karas
Guest
Posts: n/a
 
      07-27-2012
On Friday, July 27, 2012 5:04:12 AM UTC-4, jacob navia wrote:
> I see what you mean, but the problem is that there is no separation from
>
> the container to the rest of the software...
>
>
>
> That means that any ch ange of the container structure that can't be
>
> hidden needs a complete recompilation of all the client software.
>
>
>
> OK, some containers like single linked lists could be easy to do
>
> bit others would be much more complex.
>
>
>
> The way the AI would look would need to be radically different
>
> too.
>
>
>
> I will wait till your address
>
>
>
> http://wkaras.webs.com/cavl_tree.html
>
>
>
> to see what you have in mind concerning the API.


This a valid disadvantages of instrusive containers. But in some cases they are outweighed by the advantages. The elements of intrusive containers can be the original ones, not copies. Elements are not restricted to being in the heap, or anywhere else. If the intrusive containers are designed toallow it, elements can be in multiple containers at once.

Again, to be clear, I am not saying you should not provide non-intrusive containers in your implementation. I'm saying split it into two layers, non-intrusive on top of intrusive, so users can use the bottom layer without the top when appropriate.
 
Reply With Quote
 
 
 
 
Alan Curry
Guest
Posts: n/a
 
      07-27-2012
In article <jusl42$fj4$(E-Mail Removed)>,
jacob navia <(E-Mail Removed)> wrote:
>Le 27/07/12 00:29, Alan Curry a 閏rit :
>> In article <jusat8$p3t$(E-Mail Removed)>,
>> jacob navia <(E-Mail Removed)> wrote:
>>> Le 26/07/12 22:52, James Kuyper a 閏rit :
>>>> On the other hand, someone as
>>>> unsympathetic as jacob is to the use of standardese is unlikely to
>>>> perform a good translation, so perhaps it is best if he doesn't even
>>>> try.
>>>
>>> Can you please translate that into plain english?
>>>
>>> Thanks

>>
>> ISO standards are written like legislation, not documentation. The
>> target audience isn't programmers who want to use the language; it's
>> lawyers who want to be able to officially place blame when something
>> goes wrong.
>>

>
>Have you read the RFCs?


Lots of them! RFCs are notably not published by ISO. They're more
readable, and also more redistributable (you can actually download the
official RFCs, not just drafts).

>
>They are written in a language anybody can understand. And they have
>less ambiguities than the C standard.
>
>My point is that even if you write specifications in a lawyer friendly
>language, they do not get better because of that. It is just that the
>people that can understand what they mean are less numerous since
>now you need to read standardese and correctly interpret it.


Yes, let's transfer control over the C language to IETF and it'll be
better

--
Alan Curry
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      07-28-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) 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.


You are attributing an unwarranted importance to a set of generic containers
while ignoring every other feature that is provided by C++. Even if the STL
wasn't added to the C++ standard, C++'s support for generic programming
would make it possible that anyone with a basic data structures course (or
even intro to programming) could easily develop their own generic data
structures. In fact, that's something that, in spite of the STL, some
people still do. In addition, some popular C++ toolkits still rely on their
own generic containers instead of the STL. So, I believe it is safe to say
that STL's role in decisions regarding migrations from C to C++ is a bit
overblown.


Rui Maciel
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      07-28-2012
讘转讗专讬讱 讬讜诐 砖讬砖讬, 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 veryimportant 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 tohandtune 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 was the point at whcih people stopped switching from C to C++, and started moving from C++ to other languages. C++ had a huge user base behind it and is still a popular language. But ever since STL it's been in decline..
I'm current programming under Qt. However I've deliberately written all thenon-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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      07-28-2012
Malcolm McLean <(E-Mail Removed)> writes:

> 讘转讗专讬讱 讬讜诐 砖讬砖讬, 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.


What's so cumbersome? For example:

vector<int> ia = {1, 2, 3, 4, 5, 6, 7, 8};
for (int i = 0; i < ia.size(); i++)
cout << ia[i] << "\n";

The C version is *more* cumbersome in my option. If you code the size
of the array separately you can avoid the sizeof ia / sizeof *is idiom,
but that make the code more fragile.

I deliberately used a Cish loop and access method rather the C++'s
neater "for each" construct:

for (int e: ia)
cout << e << "\n";

to make the comparison clearer.

<snip>
--
Ben.
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      07-28-2012
jacob navia <(E-Mail Removed)> wrote:
>
> By the way the proposal was accepted for discussion in the next meeting
> of the committee at Portland, October 22th to October 26th.


That's great, but I can tell you from experience that unless there's
somebody at the meeting to talk to the proposal and commit to following
up, that discussion is apt to be short and not very productive.
--
Larry Jones

I always send Grandma a thank-you note right away. ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin
 
Reply With Quote
 
W Karas
Guest
Posts: n/a
 
      07-28-2012
On Saturday, July 28, 2012 4:17:02 AM UTC-4, Rui Maciel wrote:
> W Karas 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.

>
>
>
> You are attributing an unwarranted importance to a set of generic containers
>
> while ignoring every other feature that is provided by C++. Even if the STL
>
> wasn't added to the C++ standard, C++'s support for generic programming
>
> would make it possible that anyone with a basic data structures course (or
>
> even intro to programming) could easily develop their own generic data
>
> structures. In fact, that's something that, in spite of the STL, some
>
> people still do. In addition, some popular C++ toolkits still rely on their
>
> own generic containers instead of the STL. So, I believe it is safe to say
>
> that STL's role in decisions regarding migrations from C to C++ is a bit
>
> overblown.
>
>
>
>
>
> Rui Maciel


Hmm, seems your underlying principle here is that a library that can be written in portable Standard C should not be a Standard library. I think thiswould make some sense if standard compliance were a simple yes/no thing, as this would be a barrier for the availability of C compilers on new architectures. But a compiler provider can simply market their compiler as "C Standard-compliant, except for xyz".

Or perhaps you are saying that the error-prone lack of type-checking in a Ctype-independent container library makes such a beast too risky to use. While there is validity to that point of view, the beast has already been let out of the cage by the presence of void pointers in the language.

Also note that your argument would imply that qsort() should not be a Standard library function.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      07-29-2012
Le 27/07/12 21:17, James Kuyper a 閏rit :
> jacob has proposed that some of those features be added, but not all of
> them; in any event that's not what this proposal is about.


Yes, in the library I have used C89, all C99 features are completely
optional.


> The
> Containers Library is a kludge


says James without the hint of an argument. It *must* be a kludge since
James says so.

> that attempts to work somewhat like STL,


No, since C and C++ are different languages with different approaches.

In C++ the solution to everything is to complexify the language without
bounds.

In C, complex software can be done with simpler tools if you program
carefully. That is why I like C. It allows you to build powerful
software with relatively simple tools. It appeals aesthetically,
I would say.

> without all of the C++-specific features that STL relies upon,


Exactly. Without all that huge machinery I arrive at very similar speeds
and features.


I find that great!

> and
> that's what's going to make this a difficult concept to sell to the
> committee.


I am not selling something. I would like to convince people though, but
I am not obtaining any personal gain with this work.

It is just that I like C.

jacob
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      07-29-2012
Le 28/07/12 23:46, (E-Mail Removed) a 閏rit :
> That's great, but I can tell you from experience that unless there's
> somebody at the meeting to talk to the proposal and commit to following
> up, that discussion is apt to be short and not very productive.


I am saving money but this will cost me about US$ 2000 in air plane
tickets, hotel costs, etc. I plan to stay only for a few days but even
with that it will very expensive...

jacob

 
Reply With Quote
 
Ansel
Guest
Posts: n/a
 
      07-29-2012

"jacob navia" <(E-Mail Removed)> wrote in message
news:jv1uhs$2oj$(E-Mail Removed)...
> Le 27/07/12 21:17, James Kuyper a 閏rit :


> No, since C and C++ are different languages with different approaches.
>
> In C++ the solution to everything is to complexify the language without
> bounds.
>
> In C, complex software can be done with simpler tools if you program
> carefully. That is why I like C. It allows you to build powerful
> software with relatively simple tools. It appeals aesthetically,
> I would say.
>
>> without all of the C++-specific features that STL relies upon,

>
> Exactly. Without all that huge machinery I arrive at very similar speeds
> and features.


Please post a side-by-side syntax comparison (STL vs. your CCL) of a few
easy container declarations and their usages. A comparison chart of features
comparing the two would be great also. A "strengths and weakeness" list of
both would be more nice info. If you throw-in an overall comparison
paragraph or two, you'd have the start to a "white paper" (maybe)! You'd
need performance and overhead comparisons then too and an objective
comparison of implementation characterisitcs beyond "and I did it without
huge machinery".

I don't think you can go to the conference and *not* compare against STL
even though you have a C-based product. Else you're going to get responses
like James gave you about it being kludgy -- you have to address that
("that" being that C gives one less clay to mold a container library with)
and try to alleviate those concerns so that no one even thinks to say that.
Your story needs to be not only convincing, but *compelling*.

Did you start with STL as a design and then subtract until you came up with
something similar that would work in C? If not, that may very well be a very
good exercise.


 
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