Originally Posted by
EVOEx
I've thought about it before. But it should really be done.
I guess it is really a matter of contributing code. If CCAN works like CPAN, because everything is open source, people will come along and suggest things to you if they see room for improvement. The modules all have maintainers, and if that person has disappeared or lost interest, someone else is free to come along and pick up the responsibility. My understanding is that Boost works the same way, but boost is more dedicated to "one problem, one best solution" (??); some of the boost code gets added into the C++ standard.
With CPAN, there are often several libraries that serve the exact same purpose, but the structure of the API will usually be different. Also, there is no real purpose to "adding" them into perl by default or something. I think that's true with C as well, where keeping the standard minimal would be most people's preference.
Also, the lack of OO means a potentially more heterogenous approach to API structure (some perl mods do not use an OO interface, in which case there is usually an alternate one that does, or wraps the first one). Eg, I've been playing around with embedded structs instead of void pointers lately:
Code:
struct node {
void *data;
struct node *next;
}
If this were part of a simple linked list API, you now have to go node->data->member, having constructed your own struct for the data. If you just put the node pointers into your own struct, no library is possible.
Instead:
Code:
struct mystruct {
[members]
struct node link;
}
You save a level of indirection, but "node" cannot be a pointer, because you need to use offsetof(). That means the "delete" function in the API is incomplete, and there the user must do a little more setting things up. I kind of like this approach to genericism tho.
I guess the name CCAN is taken Is "Boost" an acronym?