"Malcolm McLean" <regniztar@btinternet.com> wrote:

> "Chris Thomasson" <cristom@comcast.net> wrote in message

> > Types:
> > clc_slist, clc_slink
> > clc_dlist, clc_dlink
> >
> > API:
> > void* clc_slink_init(clc_slink*, clc_slink*);
> > void* clc_slink_next(clc_slink const*);
> > void* clc_slist_init(clc_slist*, clc_slink*);
> > void* clc_slist_head(clc_slist const*);
> > void* clc_slist_push(clc_slist*, clc_slink*);
> > void* clc_slist_pop(clc_slist*);
> > void* clc_dlink_init(clc_dlink*, clc_dlink*, clc_dlink*);
> > void* clc_dlink_next(clc_dlink const*);
> > void* clc_dlink_prev(clc_dlist const*);
> > void* clc_dlist_init(clc_dlist*, clc_dlink*, clc_dlink*);
> > void* clc_dlist_head(clc_dlist const*);
> > void* clc_dlist_tail(clc_dlist const*);
> > void* clc_dlist_push_head(clc_dlist*, clc_dlink*);
> > void* clc_dlist_push_tail(clc_dlist*, clc_dlink*);
> > void* clc_dlist_pop_head(clc_dlist*, clc_dlink*);
> > void* clc_dlist_pop_tail(clc_dlist*, clc_dlink*);
> > void* clc_dlist_pop(clc_dlist*);
> >
> 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

Richard Heathfield wrote:
> Tor Rustad said:
>
> <snip>
>
>> 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? :-)

What if, your brain needs reprogramming?

--
Tor <torust [at] online [dot] no>

Tor Rustad wrote:

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

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
news:471894bc.80128813@news.xs4all.nl...
> "Malcolm McLean" <regniztar@btinternet.com> wrote:
>
>> "Chris Thomasson" <cristom@comcast.net> wrote in message
>
[...]
>> 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.

Is that a trolling attempt or what?!

Peter Pichler said:

> Tor Rustad wrote:
>
>> 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".)

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

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?

--
Tor <torust [at] online [dot] no>

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Chris Thomasson" <cristom@comcast.net> wrote in message
news:BeydnfoU9ZbDnIjanZ2dnUVZ_t6onZ2d@comcast.com. ..
> 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....2427988fd2d7ba
>
> http://groups.google.com/group/comp....5b682969ce746d
>
>
> 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/~app...c/slist_h.html
http://appcore.home.comcast.net/~app...c/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" <cristom@comcast.net> wrote in message
news:i5adnb3W96L8VYvanZ2dnUVZ_uWlnZ2d@comcast.com. ..
> "Malcolm McLean" <regniztar@btinternet.com> wrote in message
> news:37ydnTyP4pHk4YvanZ2dneKdnZylnZ2d@bt.com...
>>
>> "Chris Thomasson" <cristom@comcast.net> wrote in message
>> news:w--dnVMAB78xyojanZ2dnUVZ_t6onZ2d@comcast.com...
> [...]
>> 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.

"Duncan Muirhead" <dmuir@csl.co.uk> wrote in message
news:pan.2007.10.18.19.03.11.674568@csl.co.uk...
> On Wed, 17 Oct 2007 21:52:40 -0700, jaysome wrote:
>
>> On Tue, 16 Oct 2007 17:06:41 -0700, "Chris Thomasson"
>> <cristom@comcast.net> wrote:
>>
>>>"William Ahern" <william@wilbur.25thandClement.com> wrote in message
>>
>> [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.

"Chris Thomasson" <cristom@comcast.net> wrote:

> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> > "Malcolm McLean" <regniztar@btinternet.com> wrote:
> >
> >> "Chris Thomasson" <cristom@comcast.net> wrote in message
> >
> >> 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.
>
> 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

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
news:471c7da6.336401460@news.xs4all.nl...
> "Chris Thomasson" <cristom@comcast.net> wrote:
>
>> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
>> > "Malcolm McLean" <regniztar@btinternet.com> wrote:
>> >
>> >> "Chris Thomasson" <cristom@comcast.net> wrote in message
>> >
>> >> 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.
>>
>> 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.

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

"Chris Thomasson" <cristom@comcast.net> wrote:

> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> news:471c7da6.336401460@news.xs4all.nl...
> > "Chris Thomasson" <cristom@comcast.net> wrote:
> >
> >> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> >> > "Malcolm McLean" <regniztar@btinternet.com> wrote:
> >> >
> >> >> "Chris Thomasson" <cristom@comcast.net> wrote in message
> >> >
> >> >> 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.
> >>
> >> 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.
>
> 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

Richard Bos wrote On 10/24/07 09:27,:
> "Chris Thomasson" <cristom@comcast.net> wrote:
>
>
>>"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
>>news:471c7da6.336401460@news.xs4all.nl...
>>
>>>"Chris Thomasson" <cristom@comcast.net> wrote:
>>>
>>>
>>>>"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
>>>>
>>>>>"Malcolm McLean" <regniztar@btinternet.com> wrote:
>>>>>
>>>>>
>>>>>>"Chris Thomasson" <cristom@comcast.net> wrote in message
>>>>>
>>>>>>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.
>>>>
>>>>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.
>>
>>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.

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 ;-)

--
Eric.Sosman@sun.com

"Eric Sosman" <Eric.Sosman@sun.com> wrote in message
news:1193238704.173294@news1nwk...
> Richard Bos wrote On 10/24/07 09:27,:
>> "Chris Thomasson" <cristom@comcast.net> wrote:
>>
>>
>>>"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
>>>news:471c7da6.336401460@news.xs4all.nl...
>>>
>>>>"Chris Thomasson" <cristom@comcast.net> wrote:
>>>>
>>>>
>>>>>"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
>>>>>
>>>>>>"Malcolm McLean" <regniztar@btinternet.com> wrote:
>>>>>>
>>>>>>
>>>>>>>"Chris Thomasson" <cristom@comcast.net> wrote in message
>>>>>>
>>>>>>>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.
>>>>>
>>>>>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.
>>>
>>>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.
>
> 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?

Chris Thomasson wrote On 10/24/07 17:44,:
> "Eric Sosman" <Eric.Sosman@sun.com> wrote in message
> news:1193238704.173294@news1nwk...
> [...]
>> 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?

You can. So can I, and I have (as I described in the
snipped portion). But the fact that complex things worth
packaging as library suites can be built from simpler
components does not imply that the components should also
be packaged that way.

--
Eric.Sosman@sun.com

Eric Sosman <Eric.Sosman@sun.com> wrote:

> Richard Bos wrote On 10/24/07 09:27,:
> > "Chris Thomasson" <cristom@comcast.net> wrote:
> >
> >>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.
>
> 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.

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

Actually, your view is not as different from mine as you think, since I
would include that in "a code library". That's why I specifically
included the word "code": if you can't paste it into your own code and
adapt it /instanter/, it's not flexible enough. For a simple linked
list, I, too, do not (usually) include separate functions for walking
it, though I do usually include ones for constructing and destructing
entries, and where useful, also one for creating a blank entry. But,
like you, not for walking the list.

Richard