5 ms·
That's why we have valgrind and glib. At the core, a good language shouldn't really have any of these things you say built in - they should be built on top of
by meaty 14y ago
That's why we have valgrind and glib.
At the core, a good language shouldn't really have any of these things you say built in - they should be built on top of the language itself.
- rayiner 14y agoHaving strings, containers, etc, not built into the language itself means that you can't practically use them. Libraries will all have their own incarnations, and as a result you get stuck dealing with the lowest common denominator of C arrays.
- oinksoft 14y agohttp://developer.gnome.org/glib/ http://developer.gnome.org/glib/ http://apr.apache.org/ http://apr.apache.org/ Choose one.
- mpyne 14y agoThat's kind of the point. Why do you have to choose? Why isn't it possible with the language and its standard libraries? What happens when you mix APR code with glib-using code?
- matthiasv 14y ago1. Because there is no standard defining that. 2. Because there is no standard defining that. 3. Nothing. Functions in both libraries are prefixed to avoid name clashes.
- mpyne 14y agoThe lack of standard for 1+2 is the complaint here. Prefixing in the libraries is a workaround to make it possible at all for their separate (but similar) basic types to co-exist, but the libraries shouldn't have to define sane basic types for these things. At most they should have to add extended operations. But because they don't, it must be reimplemented in each library that needs them, which adds to code size and semantic overhead. Which might be helpful is for a good basic type library to be created which could be a common dependency for each (perhaps host it on CCAN), but the fact that this would be needed at all is the base complaint.
- rayiner 14y agoThe problem is choice. If you're writing a library, no matter which containers you choose you'll have users that chose differently. So you either require full buy-in for your framework (like GTK does with GLIB) or you end up exposing the lowest common denominator of functionality (C strings and arrays).
- oinksoft 14y agoAnd so this buy-in occurs at the library level rather than the language level. One might see that as a good thing.
- rayiner 14y agoThose people would be wrong. When buy-in occurs at the library level, then the de-facto response is to fall back to the lowest common denominator, whatever that happens to be. In a language with standard containers, that lowest common denominator is a reasonable floor. Having containers in the standard library has basically zero downside aside from some perceived conceptual elegance. People who need custom containers can always define their own. People who just need to get a string from point A to point B, where A and B are libraries written by different people, can easily do so by falling back to the standard containers.
- dmpk2k 14y agoI agree with this so much. A few years ago I realized that my C code wasn't longer or harder to reason about than most higher-level languages (yes, that factors in the memory management and even error checking), except for one thing: those languages came with built-in resizable arrays and hash tables. I was grossly disappointed when the C11 revision had nothing about some default algorithm implementations in the standard library. If a C hacker needs something more specialized than those default containers, they can go write their own (they would have anyway), but for the rest of us it allows getting something reasonable off the ground relatively quickly. APR and Glib are nice in theory, but most software shouldn't require such dependencies. Also, every C hacker I've spoken to has a different opinion about the quality and usefulness of those two libraries; most dislike the two.