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.
>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.
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.
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.
> 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.
> 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 ?
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.
>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.
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!
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.
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.
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 they way in which they model and solve real problems in context.
So 'lack of clarity' is really due to misunderstanding the context and problem space the langue was made to operate in.
I'm squinting very suspiciously at these comments suggesting this is about "pointer arithmetic". This is really about the little-used fact that you can have a "pointer to array of size N" type.
For hobby programming I work the minimalism of C, but then I also enjoy assembler. If I'm doing something more task-oriented then I prefer to use languages like js or python.
I don't mean here to compare different classes of languages. Even within systems programming languages, C has a lot of things that could be (and are) done better today.
What I meant is, that modern systems programming languages (like Rust for example) can avoid various issues by using all that was learned in programming languages design until today. C can't do that since it's stuck with its legacy requirements. This is quite an objective downside, and not just a matter of taste.
Name a language and someone will point out WTFs and subtle issues you might have never considered. The problem is the same when designing a language: computers think best with a large set of simple rules, humans think best with a small set of complicated rules, each having exceptions and different tiers of complexity for different levels of each developer's understanding.
I find C somewhat logical, but it has an easy-to-learn simplified version of itself that can be learned before re-reading the spec to complete your understanding of the language.
Sure, any language can have hard to understand parts or things that aren't designed the best way. But C is pretty old language. Creators of programming languages learned quite a lot since it was made, so they can avoid repeating known mistakes and can use newer design ideas. I.e. the quality of new languages can improve since they stand on the shoulders of giants.
>> humans think best with a small set of complicated rules
? I'd reword that to say humans are more entertained by a small set of complicated rules. Simple rules are easy for humans, but they can be boring.
However, in reality here, we're comparing apples to oranges. The instruction set for a computer is it's language. Asking a computer to speak English - that's our (humans') language, and with the tables turned, one could ask whether the computer thought better in English or Chinese, and the answer may be different but still meaningless.
Not all languages have equal wartiness. PHP and JavaScript are built on a swamp of inconsistencies whereas Haskell has a core axiomatic language. Scheme is fairly clean.
C evolved in a different age and is fraught with undefined behavior.
personally the issue i take with this article is that it displays an opinion that is counterproductive to learning (imo).
rather than calling out that pointer arithmetic implicitly relies on 'sizeof' in order to be useful, its treated like some kind of magic. i.e. i don't think it points out the not subtle but rather obvious connection, and instead distracts from it...
I think the article is well-presented and educational.