0
#include <bits/stdc++.h>
using namespace std;
  
int main()
{
    int  arr[] = {1, 2, 3, 4, 5, 6};

    int size = *(&arr + 1) - arr;

    cout << "Number of elements in arr[] is ";
         << size;

    return 0;
}
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Anujeet Kunturkar
  • 1
  • There have been debates on SO whether `*(&arr + 1)` is actually legal or Undefined Behavior. It is a bit ambiguous, so best not to rely on it at all. Also, see [Why should I not #include ?](https://stackoverflow.com/questions/31816095/) – Remy Lebeau Oct 09 '21 at 01:17
  • 1
    Not much to debate, it's 100% UB (dereferencing a past-the-end pointer). It's just that a compiler would have to go out of its way to make it do something other than result in a pointer past-the-end of `arr`. – Ken Wayne VanderLinde Oct 09 '21 at 01:45
  • @RemyLebeau The standard defines "undefined" as (essentially) "the standard specifies no constraints on the behaviour". On that basis, defereferencing one past the end of an array is undefined *by definition*. The debates on SO are language lawyer wankery - in language-lawyer-land something is "not undefined" (e.g. unspecified, implementation-defined, etc) if the standard doesn't explicitly say "is undefined" or language lawyers think it *feasible* to introduce constraints in a future update of the standard (including cases where such a *proposal* to modify the standard was rejected). – Peter Oct 09 '21 at 02:10

0 Answers0