5 ms·
Yes, actually people are deathly afraid of C thanks to other language inventor's excellent marketing against it. There's a few things that you need to really n
by zedshaw 15y ago
Yes, actually people are deathly afraid of C thanks to other language inventor's excellent marketing against it. There's a few things that you need to really nail to be good at C, and they're difficult things, but it's not "dangerous" like people keep claiming.
- irahul 15y agoC is difficult, yes. Dangerous - I don't know in what sense. I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C. The main issue with C is it takes some time before you are ready to take it head on. An experienced C programmers would have his repertoire of generic data structures library with time complexity guarantees (programs without hashes, expandable lists and operations on them are a pain), will know how to properly use function pointers to do that dependency injection thing other programmers are raving about, separate interface from implementation, know the build environment, know how to use structures and function pointer to build abstractions etc. But before that, C takes much work to produce little. For someone starting programming, the learning curve is steep. Or more like, the gratification is really, really delayed. It takes some time before he can take on a real world project(it does in the high level languages as well, but the initial progress is faster).
- praptak 15y ago"I manage to get more exceptions in my Python, Ruby code, owing to undefined variables or incorrect types, than I get segfaults in C." What happens when you don't get a clean segfault is what got C the "dangerous" reputation.
- irahul 15y agoIf you are developing, `gcc -g` while compiling(or CFLAGS += g), and loading the core with gdb does give a very good idea of what went wrong.
- praptak 15y agoIt is a lucky scenario when you actually get a core and one taken at the exactly right time. Unfortunately there are some pointer bugs that are hard to find even with Valgrind. Buffer overflows do not produce cores, they just sit there until a determined cracker makes use of them. And a dangling pointer might still access memory that looks valid both to OS and memcheck.
- antirez 15y agowhat I keep repeating about that is why the C standard guys don't freaking update the libc with a new version of the C standard? Deprecating the old silly stuff like strcat() (the libc is full of bad calls) and adding lists, hashes, btrees, good dynamic strings lib, and so forth. An huge step forward for C... without even touching the core language.
- irahul 15y agoA bit OT and not sure if you will see this. Seeing that you are the guy(or onof the guys) behind redis which is written in C, do you have any recommendations for generic data structures and operations on them? I personally have a trivial vector implementation which resizes when full, and a red-black tree implementation for associative arrays. Both of them work fine for my purpose - does the job, good locality of reference, generic over void*. I have seen glib but largely neglected it because I only need a very small part of it.
- burgerbrain 15y agoGit is a good place to rip that kind of stuff out of.
- JoshTriplett 15y agoThe negative connotations of the word aside, it seems perfectly reasonable to call C dangerous. Without that "danger", you couldn't write an OS kernel, a language runtime, or various other low-level code we need on our systems; on the other hand, when writing higher-level code that doesn't need that level of raw access, it seems useful to remove the possibility of a broad class of mistakes. See also Rusty Russell's rules about "easy to use versus hard to misuse". I find C easy enough to use, but also easy to misuse.
- burgerbrain 15y ago"Danger" minus the negative connotations is best pronounced "power".
- cturner 15y agogets()?
- burgerbrain 15y agoWith great power comes great responsibility. ;)