4 ms·

> So because you don't use C commonly Where did you get that idea? The author talks about writing C libraries that depend on GTK+, GLib, APR, D-Bus, and the l

by sigil 15y ago

> So because you don't use C commonly Where did you get that idea? The author talks about writing C libraries that depend on GTK+, GLib, APR, D-Bus, and the like. There's no way in hell I'd write a C library that depends on that stuff. Above some layer, C is no longer the right tool for the job; you're better off switching to C++ or to a dynamic language. From the author's examples I see no appreciation for this fact.

burgerbrain 15y ago
The author talks about conventions for C libraries in general. Among other things, it advocates not reinventing the wheel. Sound advice. Pretty much the entire reason we have libraries at all in the first place. I'm still not seeing a reasoned explanation of why you should be forced to re-implement linked lists, hash tables, red-black trees, etc. It's great and all that your C code is simple enough to get by just using arrays, but some of use need a bit more. These elementary data-structures are hardly anything to be afraid of using in C, particularly when someone's already implemented them for you. What in the world could be the harm in pulling in some handy string buffer functions? It's not as though dynamic linking is a black art. Furthermore, you completely disregard anyone who either 1) is unable to use something besides C, and 2) people who chose to use C because they enjoy it. That's why you are language trolling.
- sigil 15y ago
  The author talks about conventions for C libraries in general. Among other things, it advocates not reinventing the wheel. All fine things. The author has some good points on C library design. I have no problem with C (which I use heavily in both my startups), or with C libraries (which I've published, see my github), nor do I need a lecture on the benefits of reuse. Your imagination seems to be running wild here. My problem is with the author's notion of reuse. Specifically, his lack of appreciation for the flipside: dependencies. We are told to write C libraries that in turn depend on GLib, GTK+, APR, and the like. As a consumer of C libraries, there is no way I'm going to be happy about pulling in GTK+ just to use a library that does Unicode manipulation. (His example, I'm not even making this up.) That's what I meant by "middleware libraries" in my original comment. I like C libraries that do one thing and do it well, without adding unnecessary transitive dependencies. So, using C at the "lowest layer" of the dependency graph? Absolutely, all for it. I'm still not seeing a reasoned explanation of why you should be forced to re-implement linked lists, hash tables, red-black trees, etc. You shouldn't re-implement them. Use C++. STL has had fast, stable implementations of these for years. Destructors + exceptions (the only really useful parts of C++ imho) save you boatloads of nasty C code of the form: int foo() { hashtable *h = hashtable_new(); ... if (err1) { hashtable_free(h); return err1; } ... if (err2) { hashtable_free(h); return err2; } ... if (h) hashtable_free(h); return 0; } Or the almost equally repulsive int foo() { hashtable *h = hashtable_new(); ... if (err = error1) goto error; ... if (err = error2) goto error; ... error: if (h) hashtable_free(h); return err; } Any large, layered C program using dynamic data structures inevitably fills up with this (error prone!) junk. Don't like C++? Need a special data structure not in STL? Fine, use C. Hell, I've forked and contributed to a trie implementation in C [1] because I needed it in one project, and there were no quality implementations in C++. It worked out nicely because the program was small and the error prone junk (above) was minimal. Another option is to write your app in a high level interpreted language to begin with, using whatever data structures they provide, and rewrite the critical path in C. I've been doing this like crazy recently [2] [3] [4]. Furthermore, you completely disregard anyone who either 1) is unable to use something besides C, and 2) people who chose to use C because they enjoy it. I enjoy C as much as the next person, I hope I've clarified that. I also work in embedded contexts where C is the only option -- in one case, an AVR microcontroller with 8K of program memory. Do I still sometimes wish it was possible to program it in lisp or some other higher level language, like the JPL guys did when they debugged a space probe 100 million miles away [5]? Hell yeah I do. [1] https://github.com/acg/critbit https://github.com/acg/critbit [2] https://github.com/acg/lwpb https://github.com/acg/lwpb [3] https://github.com/acg/python-percentcoding https://github.com/acg/python-percentcoding [4] https://github.com/acg/python-flattery https://github.com/acg/python-flattery [5] http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html
  - deleted 15y ago
    [deleted]
  - burgerbrain 15y ago
    I stand by my point remains that an effective "don't use C" in a discussion about C is trolling, intentional or not. And I've got to say, although I avoid Glib like the plague myself (unrelated, severe quality issues with their event loop stuff a few years ago that I still have flashbacks of...) I've never found myself inconvenienced by other people's code using it or the like. It takes what... a minute to grab it? Shitty error handling capabilities are hardly relevant here, you'll have that with any quantity of C code.
  - deleted 15y ago
    [deleted]

by sigil 15y ago

burgerbrain 15y ago

The author talks about conventions for C libraries in general. Among other things, it advocates not reinventing the wheel. Sound advice. Pretty much the entire reason we have libraries at all in the first place. I'm still not seeing a reasoned explanation of why you should be forced to re-implement linked lists, hash tables, red-black trees, etc. It's great and all that your C code is simple enough to get by just using arrays, but some of use need a bit more. These elementary data-structures are hardly anything to be afraid of using in C, particularly when someone's already implemented them for you. What in the world could be the harm in pulling in some handy string buffer functions? It's not as though dynamic linking is a black art. Furthermore, you completely disregard anyone who either 1) is unable to use something besides C, and 2) people who chose to use C because they enjoy it. That's why you are language trolling.

sigil 15y ago
The author talks about conventions for C libraries in general. Among other things, it advocates not reinventing the wheel. All fine things. The author has some good points on C library design. I have no problem with C (which I use heavily in both my startups), or with C libraries (which I've published, see my github), nor do I need a lecture on the benefits of reuse. Your imagination seems to be running wild here. My problem is with the author's notion of reuse. Specifically, his lack of appreciation for the flipside: dependencies. We are told to write C libraries that in turn depend on GLib, GTK+, APR, and the like. As a consumer of C libraries, there is no way I'm going to be happy about pulling in GTK+ just to use a library that does Unicode manipulation. (His example, I'm not even making this up.) That's what I meant by "middleware libraries" in my original comment. I like C libraries that do one thing and do it well, without adding unnecessary transitive dependencies. So, using C at the "lowest layer" of the dependency graph? Absolutely, all for it. I'm still not seeing a reasoned explanation of why you should be forced to re-implement linked lists, hash tables, red-black trees, etc. You shouldn't re-implement them. Use C++. STL has had fast, stable implementations of these for years. Destructors + exceptions (the only really useful parts of C++ imho) save you boatloads of nasty C code of the form: int foo() { hashtable *h = hashtable_new(); ... if (err1) { hashtable_free(h); return err1; } ... if (err2) { hashtable_free(h); return err2; } ... if (h) hashtable_free(h); return 0; } Or the almost equally repulsive int foo() { hashtable *h = hashtable_new(); ... if (err = error1) goto error; ... if (err = error2) goto error; ... error: if (h) hashtable_free(h); return err; } Any large, layered C program using dynamic data structures inevitably fills up with this (error prone!) junk. Don't like C++? Need a special data structure not in STL? Fine, use C. Hell, I've forked and contributed to a trie implementation in C [1] because I needed it in one project, and there were no quality implementations in C++. It worked out nicely because the program was small and the error prone junk (above) was minimal. Another option is to write your app in a high level interpreted language to begin with, using whatever data structures they provide, and rewrite the critical path in C. I've been doing this like crazy recently [2] [3] [4]. Furthermore, you completely disregard anyone who either 1) is unable to use something besides C, and 2) people who chose to use C because they enjoy it. I enjoy C as much as the next person, I hope I've clarified that. I also work in embedded contexts where C is the only option -- in one case, an AVR microcontroller with 8K of program memory. Do I still sometimes wish it was possible to program it in lisp or some other higher level language, like the JPL guys did when they debugged a space probe 100 million miles away [5]? Hell yeah I do. [1] https://github.com/acg/critbit https://github.com/acg/critbit [2] https://github.com/acg/lwpb https://github.com/acg/lwpb [3] https://github.com/acg/python-percentcoding https://github.com/acg/python-percentcoding [4] https://github.com/acg/python-flattery https://github.com/acg/python-flattery [5] http://www.flownet.com/gat/jpl-lisp.html http://www.flownet.com/gat/jpl-lisp.html
- deleted 15y ago
  [deleted]
- burgerbrain 15y ago
  I stand by my point remains that an effective "don't use C" in a discussion about C is trolling, intentional or not. And I've got to say, although I avoid Glib like the plague myself (unrelated, severe quality issues with their event loop stuff a few years ago that I still have flashbacks of...) I've never found myself inconvenienced by other people's code using it or the like. It takes what... a minute to grab it? Shitty error handling capabilities are hardly relevant here, you'll have that with any quantity of C code.
- deleted 15y ago
  [deleted]