121–130 of 212 posts
Earlier quoted context omitted.
One in a million happens quite often if you're processing something like ~100k requests a second.
But it's extremely unlikely when you're processing 10 requests a week, such as might be the case for the web server in a consumer-grade router.
Earlier quoted context omitted.
>I think the article isn't obvious only to those who have a weak understanding of the language. Hi! Could you take a guess at what percentage of C programmers who write C professionally fit your definition of that (I realize you were being hasty in your phrasing, but still)? Obviously your answer should be betweeen 0% (no programmer who writes C professionally) and 100% (every programmer who writes C professionally.)…
I think less than 15% of professional C programmers have a weak understanding of the language. One only needs a basic understanding of pointer arithmetic to understand why `(&arr + 1) - arr` is the size of the array.
I very much doubt that 85% of C programmers know these things. It would be interesting to find out!
Earlier quoted context omitted.
One in a million happens quite often if you're processing something like ~100k requests a second.
But it's extremely unlikely when you're processing 10 requests a week, such as might be the case for the web server in a consumer-grade router.
Whether you use this method of getting the number of elements in an array or the more traditional sizeof method, please encapsulate the logic in a macro. Instead of writing either of these: size_t length = sizeof array / sizeof array[0]; size_t length = (&array)[1] - array; Define this macro instead: #define countof( array ) ( sizeof(array) / sizeof((array)[0]) ) Or if you must: #define countof( array ) ( (&(array))[…
Earlier quoted context omitted.
The problem you're latching on to I think is how the context for caculating a probability can vary. If it were really as likely as, say, the sun exploding that X happened then it would be of no use to expend time on X. BUT very often people speaking about the probability of events given suspicious constraints. While a memory allocation might not fail in most situations it will fail often in some situations. And a one…
That's why it's called one in a million...
Whether you use this method of getting the number of elements in an array or the more traditional sizeof method, please encapsulate the logic in a macro. Instead of writing either of these: size_t length = sizeof array / sizeof array[0]; size_t length = (&array)[1] - array; Define this macro instead: #define countof( array ) ( sizeof(array) / sizeof((array)[0]) ) Or if you must: #define countof( array ) ( (&(array))[…
Why a macro and not a static inline function?
The result you get with this trick is signed, while the result you get with sizeof is unsigned. Edit: Just to clarify, what you get is ptrdiff_t instead of size_t. So if array size is greater than PTRDIFF_MAX, you get undefined behavior [1]. [1] http://en.cppreference.com/w/c/types/ptrdiff_t
How likely do you run into array bigger than 2gb?
Earlier quoted context omitted.
I think less than 15% of professional C programmers have a weak understanding of the language. One only needs a basic understanding of pointer arithmetic to understand why `(&arr + 1) - arr` is the size of the array.
so you think 85% of programmers who write C can parse (&arr + 1) - arr to find the size of the array, without the use of the article? This is surprisingly high and I am pretty sure at least the majority of people who get paid to write C would fail that. Not because it's not the case that they "should" know it, but simply because it's possible to write C without knowing it, and some people do so. For example consider…
And what's wrong with learning something from an article? This is really not about pointer arithmetic at all. Rather it's about a particular use of C's near-infinitely composable type system.
Earlier quoted context omitted.
I'm not sure if it's a praise for C though. Arcane design and lack of clarity might be fun to decipher, but it's not something that you'd want to see in the programming language.
Understanding pointers and pointer arithmetic is fundamental to understanding c. Most books and courses would spend a considerable amount of time and effort to make sure the student understands that. So 'arcane' is the wrong word I think. You just need to get it, and really its no harder than, say context managers in python, or promises in js. Its not relevant at what 'level' those constructs are. They are novel in t…