Pre-Alpha CLC Standard Container API Proposal...

[Duncan Muirhead]

[snip]

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/queue.h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/tree.h

Wow; Thats a lot of macros!

Indeed.

What strikes me as curious is the reason why the authors of this code
decided to use macros instead of functions (in this day and age, you
should never choose to use macros over functions, especially since we
have inline capability with the C99 standard).

Macros are arguably prodigiously harder to maintain than functions.
Macros lead to increased code size compared to functions. The only
reason I can think of for using macros over functions is speed--and
that is only acceptable if it has been shown that:

<snip>

I guess the consideration was nothing to do with speed, but rather to
provide polymorphism without resorting to void*s.

 

[Szabolcs Nagy]

Header:
http://cvs.savannah.gnu.org/viewvc/...oot=pspp&revision=1.5&content-type=text/plain

i expected much briefer api
imho
find_equal
find_if
find_adjacent
(and a few more)
is not needed if a simple way is provided to walk through the list
it seems to designed with c++ stl in mind, but that's not a desired
approach here imho

(who would use find_if(arr, len, pred) when we can 'for(..) if
(pred(arr)) ..' which is much more flexible)

also a linkedlist with locking would be more attractive (eg for
multithread comminication queue)
(so there are practical aspects, not just the academic pure form of
datastructures)

 

[Ben Pfaff]

i expected much briefer api
imho
find_equal
find_if
find_adjacent
(and a few more)
is not needed if a simple way is provided to walk through the list
it seems to designed with c++ stl in mind, but that's not a desired
approach here imho

You're not required to use every function in the API. Certainly
'for' statements are superior to such functions in many cases.

also a linkedlist with locking would be more attractive (eg for
multithread comminication queue)

I really don't expect that it will ever be possible to get
everyone in comp.lang.c to agree on a single API for anything,
let alone for anything as complicated as a linked list.

 

[Tor Rustad]

Tor Rustad said:

Chris Thomasson wrote:

[...]

So far, it only has single/double linked list. Before I post any more
implementations, I want to see if we can agree on their API's.

sorry, I didn't look

Any thoughts?

If I needed this, I would rather look at the Linux kernel sources.

Indeed. And I'd rather gnaw off my own leg than look at the Linux kernel
sources (again).

The advantage of looking there, is that several clever people actually
have used the this API, so it will be more mature than something homegrown.

The generated doc is available e.g. here:

http://www.gelato.unsw.edu.au/~dsw/public-files/kernel-docs/kernel-api/

 

[Richard Heathfield]

Tor Rustad said:

The advantage of looking there, is that several clever people actually
have used the this API, so it will be more mature than something
homegrown.

I thought you weren't keen on clever people?

 

[Richard Bos]

Firstly, why not make that

ll_pop()
ll_next();

Finally, do we need singly linked lists? You seem to be doubling the size of
the api for no added functionality.

And thus is demonstrated amply, and twice, why a "one size fits all"
library belongs in C++, and _not_ in C.

Richard

 

[Tor Rustad]

Tor Rustad said:



I thought you weren't keen on clever people?

What if, your brain needs reprogramming?

 

[Peter Pichler]

What if, your brain needs reprogramming?

What if your punctuation needs fixing? ;-)

(I happen to agree with you, BTW. I know the difference between clever
and "clever".)

 

[Chris Thomasson]

And thus is demonstrated amply, and twice, why a "one size fits all"
library belongs in C++, and _not_ in C.

Is that a trolling attempt or what?!

 

[Richard Heathfield]

Peter Pichler said:

What if your punctuation needs fixing? ;-)

(I happen to agree with you, BTW. I know the difference between clever
and "clever".)

I wish I did. Then I might have a fighting chance of understanding what
Tor's point is, because it still escapes me, all this way into the thread.

 

[Tor Rustad]

Richard Heathfield wrote:

[...]

I wish I did. Then I might have a fighting chance of understanding what
Tor's point is, because it still escapes me, all this way into the thread.

Could we keep our childish "pissing match", in a single thread?

 

[Richard Heathfield]

Tor Rustad said:

Richard Heathfield wrote:

[...]

I wish I did. Then I might have a fighting chance of understanding what
Tor's point is, because it still escapes me, all this way into the
thread.

Could we keep our childish "pissing match", in a single thread?

(a) Clearly I appear to have cross-threaded, for which I apologise;
(b) I didn't realise it was a match (of any kind).

 

[Chris Thomasson]

Here is some example code for a container API for this group to use:

http://appcore.home.comcast.net/web/


as-per the following posts:

http://groups.google.com/group/comp.lang.c/msg/422427988fd2d7ba

http://groups.google.com/group/comp.lang.c/msg/8b5b682969ce746d


So far, it only has single/double linked list. Before I post any more
implementations, I want to see if we can agree on their API's.

This has nothing to do with the API, however, I was wondering how many
people use something similar to the build compile-time macro-function
library (e.g., define macros; include common file to invoke) my code uses;
refer to the:


_______________________
#if ! defined(CLC_SLIST_H)
#define CLC_SLIST_H()(slist.h, clc, (clc_slist, clc_slink))
#define CLC_SYS_BUILD()(include, prolog, CLC_SLIST_H)
#include "sys/build.h"
/*********************************************************************/
[...]

/*********************************************************************/
#define CLC_SYS_BUILD()(include, epilog, CLC_SLIST_H)
#include "sys/build.h"
#endif
_______________________

prolog/epilog boilerplate-code in the include files:


http://appcore.home.comcast.net/~appcore/web/clc/slist_h.html
http://appcore.home.comcast.net/~appcore/web/clc/dlist_h.html


?


I find that using automated compile-time build function gives me some useful
capabilities. For instance, I can modify a single code-base (e.g., build
function impl) to effect behavior of every include file in project. Lets say
that you wanted to introduce a two new header files that you wanted to be
called at the beginning, and end of every header in your project? You would
normally have to add them manually. Well, if your using automated build
function that supports prolog/epilog, you just have to append a couple of
macros to the appropriate file.

 

[Chris Thomasson]

news:[email protected]... [...]
Firstly, why not make that

ll_pop()
ll_next();

etc.

No one wants to write out all those words. Remember that quite often
these calls will be used in expressions. A for loop with three four-word
identifiers will rapidly get unreadable.

Is this better: [...]

?

How many people like the condensed api names better? I think I should change
the API before I graduate its status from rough-draft stage to pre-alpha.

 

[Chris Thomasson]

[snip]

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/queue.h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/tree.h

Wow; Thats a lot of macros!

Indeed.

What strikes me as curious is the reason why the authors of this code
decided to use macros instead of functions (in this day and age, you
should never choose to use macros over functions, especially since we
have inline capability with the C99 standard).

Macros are arguably prodigiously harder to maintain than functions.
Macros lead to increased code size compared to functions. The only
reason I can think of for using macros over functions is speed--and
that is only acceptable if it has been shown that:

<snip>

I guess the consideration was nothing to do with speed, but rather to
provide polymorphism without resorting to void*s.

Sure. However, C is C; no polymorphism needed indeed.

 

[Richard Bos]

Is that a trolling attempt or what?!

No. When I troll (which is very rarely, and even rarer here on c.l.c), I
at least _try_ to make it a funny troll. The above was quite serious. I
believe that this whole attempt is misguided, and that this thread
neatly shows why.

Richard

 

[Chris Thomasson]

No. When I troll (which is very rarely, and even rarer here on c.l.c), I
at least _try_ to make it a funny troll. The above was quite serious. I
believe that this whole attempt is misguided, and that this thread
neatly shows why.

Are you saying that basically any generic container library in C is
misguided crap?

 

[Richard Bos]

Are you saying that basically any generic container library in C is
misguided crap?

I wouldn't necessarily call it crap, but I expect every good programmer
to have something like the above in his code libraries anyway, and adapt
it where necessary for the project at hand. If you have a fixed, (semi-)
Standard ADT library, adapting it becomes that much harder. Generic is
good; but generic and (essentially) unchangeable is not.

Richard

 

[Eric Sosman]

Richard Bos wrote On 10/24/07 09:27,:

I wouldn't necessarily call it crap, but I expect every good programmer
to have something like the above in his code libraries anyway, and adapt
it where necessary for the project at hand. If you have a fixed, (semi-)
Standard ADT library, adapting it becomes that much harder. Generic is
good; but generic and (essentially) unchangeable is not.

My view is a little different: Every good programmer's
bag of tools will contain useful gadgetry for tasks the
language's built-in capabilities do not support well enough,
but will not contain silly tools that just duplicate what
the language already provides. Tools that don't add value
are, well, not valuable.

A linked-list library strikes me as a silly tool. The
basic pointer manipulations are trivial, and easily written
in open code. Also, open-coded versions offer type safety
that `void*' loses; open-coded versions are easily tailored
to special circumstances -- heck, open-coded versions are
more convenient to use than the proposals I've seen floated
here thus far. That was the point of my mockery a while
ago, when I proposed API's for array access and for integer
arithmetic: Why duplicate what the language already provides?

I'm not against container API's per se. My own toolbox
contains (among other things) a skip-list and a hash table,
both of which I use now and then. But these tools offer
something more than just draping identifiers over one or
two operators: Their machinery is not difficult, but it is
somewhat larger than one would like to write and rewrite at
each use. They add value, offsetting the costs of lost type
safety and lost transparency. IMHO, a plain linked list API
offers no gains to make up for its losses. An API that offers
linked lists "with benefits" could be worth while, but just
replacing `while ((p = p->next) != NULL)' is not (and it's
difficult to divorce the "benefits" from the context in
which the API is used).

So go ahead and write whatever API's please you, but
(1) I think effort spent on such a trivial task is effort
wasted, and (2) for any substantive task you will *never* see
the end of the API design debates c.l.c. can generate ;-)

 

[Chris Thomasson]

Richard Bos wrote On 10/24/07 09:27,:

My view is a little different: Every good programmer's
bag of tools will contain useful gadgetry for tasks the
language's built-in capabilities do not support well enough,
but will not contain silly tools that just duplicate what
the language already provides. Tools that don't add value
are, well, not valuable.

A linked-list library strikes me as a silly tool.

[...]

Why can't you use the simplistic linked-list api to build larger, more
complex data-structures?