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