>>30(
>>28 here)
To begin with, I absolutely detest your use of the term ``expressiveness'', since its definition is so approximate and situation-dependent that it might as well be ``prettiness''. Clearly it is not the case that one is unable to write a Red-Black tree in C, so adding a library for Red-Black trees doesn't add any features to C. It's just that you don't have to look at
rbtree.c when you scan your source directory. To reduce
ad absurdum, you might as well just write your entire program, turn it into a library, and then state that you have improved upon the expressive power of C because now
#include <super/special.h>
int main(void)
{
return yay();
}is a fully-featured word processor in something like 75 bytes!
No. You have not changed the fundamental nature of a language, you are including some extra header files and linking against a library.
Anyway:
Firstly (and admittedly pettily), one thing I noticed as I haphazardly scanned Sglib's description was a statement that all of Sglib's variables begin and end with an underscore, so it's okay for them to use variables in their macros. For a library with the intent of being truly general-purpose, that's a [i]bad[/i] idea (N1124, which I have on hand, brings this up in section 7.1.3, but I know the point is repeated in other standards), and the author[s] should know this.
Secondly, the writer of this page came off as a bit of a crank. See
In opposition to many cake eaters from my university, I believe that ideas behind Sglib are good because of my former research on modern (and generic) programming languages and because of my current work on a refactoring browser for C.
A page about a data structure ``library''
* isn't the place to put snide comments about former classmates, well-deserved though that comment may be. That's not a condemnation of the code, but given the quality of other writings/projects I've seen from authors who made such comments, I was reluctant to trust the vague technical claims that this author makes. Still, this would not be significant in my overall choice to use the library, were I to make one.
I would say ``
Thirdly, the lack of a proper license is a bit worrying - if it's so simply licensed, the author should just put it under MIT/BSD/etc. and be done with it.'' if I cared about that, but I really don't. Somebody else might say it, though.
Thirdly, and this is the only reason that I would really end up making a decision based on (and note that I did not come to this conclusion from the initial overview page), the performance seems bizarre. There's an admirable focus on performance by offloading as much as possible to the preprocessor, but consider
SGLIB_LIST_LEN. Linear time? What the
fuck? If that's the price I have to pay for not linking against anything, no thank you.
* I use those quotes because I don't consider Sglib a library on technical grounds, and I'm not sure what to call a piece of off-the-shelf code that is not linked against.