201–210 of 396 posts
Is it possible for C to be a standalone skill, where ones job could be 100% programming in C, or do you need a lot of auxiliary knowledge outside of that?
I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…
> So in this sense, the quality of the C you write is really a reflection of you as a C programmer, not the shortcomings of the language. Can't you substitute "C" with just about anything in this sentence? It's all well and good to talk about how "beautiful" a language is, but when people are literally endangered because of totally preventable security vulnerabilities that don't happen in programs written in other la…
Earlier quoted context omitted.
Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->". The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.
This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t). Obviously, I just follow the convention when contributing to an existing project.
The author's use of register to avoid aliasing is something I hadn't heard before and seems like a good idea in some cases.
Beyond the learning C aspects, I really hope that some of the author's suggestions for language extensions are implemented.
Earlier quoted context omitted.
>The omission of assert() makes Go a non-starter. A small syntactic sugar you can trivially implement yourself makes Go a non-starter? Go doesn't include assert in the language because you're supposed to do better than assert. Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. Go prevents you from compiling with unused variables, and that combined with…
> Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. This is what he meant by misuse. Properly-used assertions are meant to document and check conditions that were thought to be impossible by the developer. Not just unlikely, or illegal, but impossible. If a condition is possible, and you check it with assert, that's a bug.
Earlier quoted context omitted.
Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->". The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.
This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t). Obviously, I just follow the convention when contributing to an existing project.
The range of indexable array elements is not only constrained by the unsigned type size_t, but also by the signed type ptrdiff_t, so you could always go with the latter instead of the non-ISO ssize_t.
I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…
>enjoying the danger This is a hilariously bad attitude for any software that other people will use. When software crashes, people lose work and time. When software has vulnerabilities, bad guys take advantage of them and build stronger botnets. "The danger" isn't like wiping out when you're pulling a stunt; "the danger" is wasting the good guys' time and empowering bad guys. >There is a lot of great code written in…
I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…
I remember reading some of ID's engine code and admiring how well I could follow it and know what's going on. With C++ and other OO languages, it's much harder.
Don't get me wrong, I'm not going to write my next web app in C, and there's some obvious benefits to the features that C++ offers, but C++ ain't beautiful.
Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.
I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.
For someone who studied basic C/C++ in university and is interested in hacking around in C, should I read this over K&R?
Don't skip K&R. Probably read both. They're both pretty short. A really, really good one is Advanced Programming in the Unix Environment. But, it's pretty expensive.
K&R is a great resource which covers a lot beyond the syntax, but is obviously dated from the standard's perspective.