I'm trying to understand why sizeof(a)/sizeof(t) is inferior for getting the length of an array to sizeof(a)/sizeof(a[0]) if just as it's possible to have different types, my elements could also be of different lengths. so what makes dividing by the element size uniform?

  • 4
    To help people understand your question, please explain where a and t come from. Give multiple examples. In particular, explain what a and t would be, if someone passes in: (1) an array typedef, (2) an array instance, (3) a pointer. Please remember that most people do not have the same "K.N.King" book as yours. If your question depends on something from that book, be sure to explain it here. – rwong Apr 28 '20 at 5:46
  • If it is a C macro, give the definition of the macro, and give examples of how the macro is used. – rwong Apr 28 '20 at 5:48
  • An array contains elements of a single type. The size of a type is a constant. – Mat Apr 28 '20 at 6:34
  • I'm disappointed with the communities reception of this question. This is not asking us to write or explain code. – candied_orange Apr 28 '20 at 8:58
  • @candied_orange: nevertheless it is badly written and lacks any sign of improvement by the OP, though the question got some helpful comments. – Doc Brown Apr 28 '20 at 10:03

The difference between sizeof(a)/sizeof(t) and sizeof(a)/sizeof(a[0]) is that for the first one you need to supply two pieces of information (the array name and the type of its elements) while the second one needs only a single piece of information (the array name).

The more pieces of information you need to provide, the more chance there is that a mistake is made. To make matters worse, if a mistake is made in the element type of the array, there is no safety net to catch that mistake. You will just get incorrect results.

And a mistake does not mean only when the code initially gets written, but also when later on changes are mode to it.

Suppose you start out with

int arr[N];
array_length = sizeof(arr)/sizeof(int);

later on you find that int isn't the right type, because you also need to store fractional numbers, so you change it to double, but you forget the sizeof expression:

double arr[N];
array_length = sizeof(arr)/sizeof(int);

Now suddenly, the value of array_length is no longer correct. If you had written it as array_length = sizeof(arr)/sizeof(arr[0]);, then that mistake could not have happened.

  • It could be argued that a name change is far more likely than a type change. But a name change is an automated refactoring. Even if done by hand, a mistake would produce a compiler error. So I'm strongly in the a[0] camp. Code should welcome refactoring. – candied_orange Apr 28 '20 at 8:54
  • @candied_orange I personally prefer trimming it down to sizeof a / sizeof *a as I dislike senseless verbosity, not that it changes anything much. – Deduplicator Apr 29 '20 at 6:09
  • @Deduplicator I’ve heard that debased as well. Some like it short. Some think the long one makes it clearer that you’re looking at the size of an element. Personally I wish the whole thing was hidden behind a good abstraction. – candied_orange Apr 29 '20 at 6:13

Also consider the pros/cons from a reviewer point of view.

size_t a_size1 = sizeof(a)/sizeof(int);
size_t a_size2 = sizeof(a)/sizeof(a[0]);

The type definition of a may not be near these lines of code, perhaps in a .h file.

To check either line of code, we need to know if a is in fact an array and not a pointer. This is a binary consideration that is usually understood in review - not much cost.

Yet sizeof(int) obliges another check: does the type match? For the original coder, this is not much of issue and so may appear inconsequential. Yet for a reviewer who has cursory knowledge of the code, it is a tedious check.

This is a similar concern of @Bart van Ingen Schenau good answer, yet I wanted to emphasize the increased negative impact on reviewers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.