[logicallee]

>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'm genuinely curious what you think! Thanks :)

[gragas]

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.

[logicallee]

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 embedded programmers who might not be specialists at all.

I very much doubt that 85% of C programmers know these things. It would be interesting to find out!

[psyc]

I can only speak for myself. I wrote C code for many years, a long time ago. I'm 100% certain that I never had occasion to use a "pointer to array" type. If you asked me a series of leading questions, like "Can you have a pointer to array of 10 ints?" and "What would happen if you increment that?" I would probably get the right answer, with low confidence. There's almost no way I would have thought of this way of getting the array size without reading something like this article.

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.

[logicallee]

yes; my thinking is that most people writing it today would be in the same category.

[maxlybbert]

I would hope a practicing programmer would realize that sizeof is a keyword and evaluated at compile time, and use that. I don't consider this article to be an example of something that you should consider putting in your codebase; but an investigation into some of the language's rules.

[clarry]

> I would hope a practicing programmer would realize that sizeof is a keyword and evaluated at compile time

I must nitpick. sizeof may or may not be evaluated at compile time. It is not possible to always evaluate it at compile time (see VLAs). The standard even includes an example of this:

         #include <stddef.h>
         size_t fsize3(int n)
         {
               char b[n+3];                  // variable length array
               return sizeof b;              // execution time sizeof
         }

          int main()
          {
                size_t size;
                size = fsize3(10); // fsize3 returns 13
                return 0;
          }

[maxlybbert]

You are correct. I forgot about variable length arrays.

[logicallee]

well, the title ("how to find size of an array in C without sizeof") certainly made it sound as though there was some use to this!