a CPAN for C

[m]

for the C language is there something like CPAN is for Perl ?
if this is asking too much then maybe a list of commonly used
libraries for C ? for both Linux and Windows, not necessarily(but
hopefuly) portable ?

also, I've seen in many places C code that re-implements over and over
and over linked lists, is this a rite of passage or isn't there any
standard implementation of a linked list ?

 

[Seebs]

also, I've seen in many places C code that re-implements over and over
and over linked lists, is this a rite of passage or isn't there any
standard implementation of a linked list ?

There is no standard implementation, because different implementations
have different goals.

-s

 

[Frank]

There is no standard implementation, because different implementations
have different goals.

I think that's slightly mis-stated. With C, there are many
implementations at any given time, as opposed to perl, where there are
many implementations as it evolves but only one implementation at a
given time.

I have big hopes for clc's wiki, but any cpan-like proxy would have to
be sorted by implementor: dinkumware, gcc, Intel.

 

[Frank]

Quite a few such libraries exist. SDL is often mentioned in this kind of
context.

But having a C library is *a lot* different from having something that
came down from c-pan.

 

[jacob navia]

m a écrit :

for the C language is there something like CPAN is for Perl ?
if this is asking too much then maybe a list of commonly used
libraries for C ? for both Linux and Windows, not necessarily(but
hopefuly) portable ?

also, I've seen in many places C code that re-implements over and over
and over linked lists, is this a rite of passage or isn't there any
standard implementation of a linked list ?

I am trying to design and implement a standard container library
for C.

I report about it regularly in this newsgroup.

 

[Tom St Denis]

C's CPAN is sometimes referred to as "the Internet". Unfortunately, a
lot of non-C stuff has managed to creep in, but the Internet remains a
tremendous resource for C programmers.

Hehehe, that made me chuckle. Thanks for the early morning [post-
coffee] laugh.

When I was a teen in the 90s I was a fan of PCGPE and SWAG. Though
SWAG was pascal related I found porting the algorithms to C to not be
that hard. Of course this was a tad pre-popular internet days so
these sort of resources were geared to be the sort of things you can
download off a BBS and then browse offline. If I recall for SWAG you
could download modules into a reader and then browse through the
various articles written for it (on all sorts of topics). It was a
dream for a starting programmer to have access to all sorts of code
even if it was at times poorly written and buggy...

Tom

 

[Kaz Kylheku]

There is no standard implementation, because different implementations
have different goals.

But there are M implementations and N goals, where M >> N.

 

[Flash Gordon]

m a écrit :

I am trying to design and implement a standard container library
for C.

I suspect it will never meet the requirements for the stuff I work on
which needs linked lists, or most of the stuff I've done in the past
which needed them.

I don't need the complexities introduced by some of your design
decisions, such as your decision to make it so generic (I know exactly
what I need, and it will never need to swap to being a tree or hash or
whatever). I've got something far simpler which was debugged years ago
which has everything needed for what it is used for.

Other peoples requirements are not the same as mine! For a start, your
requirements are different!

I report about it regularly in this newsgroup.

You are posting C code, so it's completely topical.

 

[Flash Gordon]

m a écrit :

I am trying to design and implement a standard container library
for C.

I suspect it will never meet the requirements for the stuff I work on
which needs linked lists, or most of the stuff I've done in the past
which needed them.

I don't need the complexities introduced by some of your design
decisions, such as your decision to make it so generic (I know exactly
what I need, and it will never need to swap to being a tree or hash or
whatever). I've got something far simpler which was debugged years ago
which has everything needed for what it is used for.

Other peoples requirements are not the same as mine! For a start, your
requirements are different!

I report about it regularly in this newsgroup.

You are posting C code, so it's completely topical.

 

[Seebs]

But there are M implementations and N goals, where M >> N.

Yeah.

But since one of the most common goals is "I want it embedded in the
data structures I'm already using", it's probably reasonable. Also,
lists are super easy to implement.

I still remember, though, back in 1990 or so, really struggling to
implement lists once.

-s

 

[Flash Gordon]

m a écrit :

I am trying to design and implement a standard container library
for C.

I suspect it will never meet the requirements for the stuff I work on
which needs linked lists, or most of the stuff I've done in the past
which needed them.

I don't need the complexities introduced by some of your design
decisions, such as your decision to make it so generic (I know exactly
what I need, and it will never need to swap to being a tree or hash or
whatever). I've got something far simpler which was debugged years ago
which has everything needed for what it is used for.

Other peoples requirements are not the same as mine! For a start, your
requirements are different!

I report about it regularly in this newsgroup.

You are posting C code, so it's completely topical.

 

[Kaz Kylheku]

Yeah.

But since one of the most common goals is "I want it embedded in the
data structures I'm already using", it's probably reasonable. Also,
lists are super easy to implement.

Also, the goal formula ``I want to implement it myself'' actually gives rise
to N unique goals, due to the multiple instantiation of the ``myself''
variable.

 

[jacob navia]

Flash Gordon a écrit :

jacob navia wrote:

I suspect it will never meet the requirements for the stuff I work on
which needs linked lists, or most of the stuff I've done in the past
which needed them.

But... you are not forced to use that. It is for people that want to
use linked lists without bothering to reinvent the wheel again.

I don't need the complexities introduced by some of your design
decisions, such as your decision to make it so generic (I know exactly
what I need, and it will never need to swap to being a tree or hash or
whatever).

OK. Then go onusing your lists. I mean, what I want is that newcomers
(and oldtimers) that do NOT feel like reimplementing a binary search
tree, or a double linked list from scratch can use a standard package
that is immediately usable, comes with source code, and can be adapted
at will.

I've got something far simpler which was debugged years ago
which has everything needed for what it is used for.

Fine with me.

 

[Ian Collins]

I suspect it will never meet the requirements for the stuff I work on
which needs linked lists, or most of the stuff I've done in the past
which needed them.

I think you are missing the point. There were scores of container
libraries for C++ when the STL came along. Those who had their own
carried on using them, most of those who didn't, picked the STL. That's
how libraries become "standard": they exist and people start using them.

I don't need the complexities introduced by some of your design
decisions, such as your decision to make it so generic (I know exactly
what I need, and it will never need to swap to being a tree or hash or
whatever). I've got something far simpler which was debugged years ago
which has everything needed for what it is used for.

I don't know whether Jacob will achieve this (within the bounds of
standard C), but being generic is one of the reasons behind the C++ STL.
The beauty of the STL design is most users never see the complexity
behind this, they just use the containers "as is". I fear C's inherent
transparency will make this hard for Jacob to achieve.

 

[Nick]

But there are M implementations and N goals, where M >> N.

There are, but as there are a number of different ways of doing
fundamental things, this sort of thing will tend to happen.

Take a "real" string library. There are at least two very different
design approaches here. In one the thing still looks like a C string
(it has the extra information held in memory "left" of the pointer). In
the other the pointer is to a structure.

The first is easier to pass to the existing library functions, but the
address can change when the size changes (and so keeping pointers to
strings around for a while is risky). If a normal string is passed to
the new functions horrible things will happen.

The second is just a bit fiddly to pass to the existing library
functions, but the address is unchanging so copies can hang around. If
you try to pass a normal string to the new functions the compiler will
object. Accessing the contents involves an additional indirection
compared with the first approach - costing small amounts of time and
memory.

It's far from clear to me which of these is "right". I've done the
latter, another contributor here the former.

Ditto there are two major ways (at least, again) to do generic
containers. Are they structures with a void pointer, or are they little
structures that can be embedded in your own?

But whichever you choose, the moment you build on this (say anywhere
that generates a string of unknown length - reading, character set
conversion, (de)compression etc) you then have a library to do that
which is dependent on the first, so you need one of these for each.

With, say, 4 major binary design decisions to be made, that gives you 16
implementations (and, of course, 16 sets of goals).

 

[Nick]

C's CPAN is sometimes referred to as "the Internet". Unfortunately, a
lot of non-C stuff has managed to creep in, but the Internet remains a
tremendous resource for C programmers.

If we were doing it now though, a more distinctive name for use in
searches would be a good idea!

 

[jacob navia]

Nick a écrit :

Ditto there are two major ways (at least, again) to do generic
containers. Are they structures with a void pointer, or are they little
structures that can be embedded in your own?

My proposal gives you both. If you declare the size of your
data to be sizeof(void *) you do not store anything in the library
container but a pointer. You manage the data and there are no copies.
If you declare the data size to be the size of your actual data,
it is the library that copies the data, and manages the memory.

Very simple to use.

Since source code is available you can use it for your own structures
as well.

 

[Tom St Denis]

I am trying to design and implement a standard container library
for C.

I report about it regularly in this newsgroup.

Write the library for C90 and release it under LGPL and maybe I might
care about it.

If the library requires lcc-win32 extensions and is proprietary you
can keep it.

Tom

 

[Marco]

Write the library for C90 and release it under LGPL and maybe I might
care about it.

If the library requires lcc-win32 extensions and is proprietary you
can keep it.

Tom

Totally agree - if not written in standard C (unfortunately that still
means C90 today) then most folks just won't want it

 

[Tom St Denis]

Totally agree - if not written in standard C (unfortunately that still
means C90 today) then most folks just won't want it

Nothing wrong with C90. Only thing I borrow from C99 is long long. I
think that VLA and mid-block declarations are bad coding practice.
I'd settle for his library being C99 though.

My suggestion that it be C90 was because I suspect it's being written
for his compiler which isn't 100% ISO compatible.

Tom