[btrask]

I suspect this article made a lot of people feel stupid, or in other words, it taught us something. Sometimes the ego gets out of check.

I think the article is well-presented and educational.

[gragas]

>I think this article made a lot of people feel stupid

I don't think so. Anyone with a solid understanding of C understands pointer arithmetic. I think the article isn't obvious only to those who have a weak understanding of the language.

[jmspring]

There are many that have a weak understanding of the language.

I got asked some years back why I defaulted to C in some interview questions -- I grew up with the language, understand the nuances and many of the implementations.

It's now possible to make your way through a university education in CS without ever touching or understanding C. This is a problem.

[yzmtf2008]

Just because you grew up with C and know many of the details doesn't make it necessary for others to know that much, especially when the job doesn't call upon it. I grew up with C as well, but I understand it is possible to make meaningful contributions without understanding C.

[vostok]

> It's now possible to make your way through a university education in CS without ever touching or understanding C. This is a problem.

I did not study CS, but I had a number of CS modules/classes. LaTeX was the only programming language I recall using. Students with better handwriting could probably get away with not doing any programming at all.

It's not clear to me that this is a problem, but I imagine that the systems requirement of most CS programs will involve C.

For what it's worth, I default to python in interviews even though it's my least favorite out of the languages that I use frequently.

[ageofwant]

> I default to python in interviews even though it's my least favorite out of the languages that I use frequently.

Why is that ? I would image that you'd use the language you are most comfortable with and trust the most during an interview ? What makes Python a good 'interview' language but a less good bread and butter language for you ?

[vostok]

I find that python requires the least boilerplate code out of the most common programming languages. I mostly dislike it on aesthetic grounds.

I really like the modern incarnations of C++ and statically typed ML-influenced, but not necessarily ML-derived, languages.

There are many criticisms that one could make about R, but I like some of its lispier features.

[jonathankoren]

If he's listing LaTeX as a programming language and talking about how little programming he had, I suspect he's stuck with R or Matlab.

[spicyj]

TeX is a "real" programming language.

[jonathankoren]

If you're taking CS classes and boasting about how you don't know how to program, it is a problem.

[yzmtf2008]

In many more theoretical CS classes, programming is not a requirement.

[jonathankoren]

There's a word for that. It's "math".

[mjevans]

I don't think it /has/ to be C.

Having done even a semester of any type of assembly (not just part of a class) is probably enough. Other /low level/ languages like Forth (Imagine you /only/ had assembly, and wanted to build something a /little/ less painful) could probably work too.

[gragas]

>It's now possible to make your way through a university education in CS without ever touching or understanding C. This is a problem.

I suppose that this is the case. But really, to me this is article does not reveal anything beyond what I already knew from basic pointer arithmetic.

[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;
          }

[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!