3 ms·
And so this buy-in occurs at the library level rather than the language level. One might see that as a good thing.
by oinksoft 14y ago
And 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.