The result you get with this trick is signed, while the result you get with sizeof is unsigned.<p>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].<p>[1] <a href="http://en.cppreference.com/w/c/types/ptrdiff_t" rel="nofollow">http://en.cppreference.com/w/c/types/ptrdiff_t</a>
I'm surprised at all of the comments calling this stupid or pointless. The point is not that you should this trick in lieu of sizeof; the point is to shed light on a subtly of C arrays.
Author of the article here. There's no intention here to encourage people to use this in code (in fact the opposite). This article is more of a "Did you know cool shit like this exist?".
Whether you use this method of getting the number of elements in an array or the more traditional sizeof method, <i>please</i> encapsulate the logic in a macro.<p>Instead of writing either of these:<p><pre><code> size_t length = sizeof array / sizeof array[0];
size_t length = (&array)[1] - array;
</code></pre>
Define this macro instead:<p><pre><code> #define countof( array ) ( sizeof(array) / sizeof((array)[0]) )
</code></pre>
Or if you must:<p><pre><code> #define countof( array ) ( (&(array))[1] - (array) )
</code></pre>
And then you can just say:<p><pre><code> size_t length = countof(array);
</code></pre>
Edit: I used to call this macro 'elementsof', but it seems that 'countof' is a more common name for it and is a bit more clear too - so I'm going to run with that name in the future.
Interesting. I've been working with C for almost 30 years (first taught it to myself when I was 14) and never thought about the actual <i>type</i> of <i>array</i>.
For the completeness sake, the size of an array can also be computed via linker symbols, see for example: <a href="http://stackoverflow.com/questions/29901788/finding-the-last-variable-in-attribute-section" rel="nofollow">http://stackoverflow.com/questions/29901788/finding-the-last...</a>.<p>Same constraints apply (pointer arith).<p>I am not sure why this method, applied to ordinary arrays, would be preferred to sizeof (), but since we're shedding light here...<p>EDIT: pointer arith constraints only apply if we compute the difference (end - beg) in the C code. We could also do that in the linker script itself, and I don't recall whether or not C semantics of ptrdiff_t would be preserved in that case. Such preservation doesn't seem very probable to me, so potentially this method might allow to avoid overflows (or to move them much higher) -- to be checked in the 'ld' doc!
Despite the argument at the end, this is undefined behavior in the latest C specification. The code dereferences a pointer one past the last element.<p>C11 6.5.6/8:<p>If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated
While this is as interesting as any c arcana, I truly hope that people are not passing around pointers to arrays and then using sizeof(array)/sizeof(elem) to figure out how big they are, like they are stuck in a first year programming assignment that denies them the use of malloc, so they use C99 VLAs everywhere.
Why do we dereference the array pointer? Wouldn't that give us the value at the address when we just want the address? Also wouldn't the subtraction just give us a number of bytes and thus we'd still need to divide by sizeof(int))?
there is a classic mistake here... the idea that pointer arithmetic does not rely on sizeof.<p>that's the entire mystery opened and closed afaik. sure you can use some obscure notation if you like, but why not just use sizeof?
this is undefined behavior. &arr + 1 can overflow. There's no guarantee &arr isn't near memory end boundary. &arr + 1 is converted at compile time to rbp - X where X is an integer determined by the compiler similarly to how sizeof works.<p>Basically ptr + integer requires the compiler to determine the sizeof ptr's type.
Given how many bugs & errors stem from simple fails in range checks etc, I would much rather go with the tried and true way rather than use something "clever".<p>Quoting <a href="http://stackoverflow.com/a/16019052/1470607" rel="nofollow">http://stackoverflow.com/a/16019052/1470607</a><p><pre><code> Note that this trick will only work in places where `sizeof` would have worked anyway.</code></pre>
nice exposition to c array types.<p>in c++, a compile-time equivalent to sizeof would be:<p><pre><code> template<typename T, size_t N> size_t sz(T(&)[N]) { return N; }</code></pre>
C is such a boondoggle of a language... We're condemned to forever explore its every weird nook and cranny for historical reasons, rather than because it is the cleanest, best approach to things possible.
I haven't written C in a while, but I think this is pretty stupid. sizeof() is a compile-time thing in C, so it's substituted with a number by the time you get an executable. See:<p><a href="http://stackoverflow.com/questions/671790/how-does-sizeofarray-work" rel="nofollow">http://stackoverflow.com/questions/671790/how-does-sizeofarr...</a><p>I think this is effectively doing the same thing, but in a non-standard way; ie. I think `int n = (&arr)[1] - arr;` is substituted with the actual the number by the compiler the same way sizeof() would be, only noone will know wtf is going on.<p>Disclaimer: I didn't look at the generated code to confirm; I guess it could even be compiler/runtime dependent.