EvanED wrote:The second thing is false, and it's not consistent, and I'll edit this post with more later.
Since there is more discussion I'll just post here. I have rethinked my position though and think that you're mostly right, I just don't think you phrased it very well.
Great Justice wrote:...arrays are equivalent to const pointers to their first element, it is indeed consistent.
That arrays and pointers to their first elements are the same is a somewhat dangerous misconception which I wish would go away completely. Given an array int arr
, it's really no more correct to say that arr
is equivalent to &arr
then it is to say that the integer 1
is equivalent to 1.0
. In both cases they have different types, and in both cases the former is implicitly converted to the latter in some situations. That it happens more often with arrays is true (from some reasonable perspective it happens with almost
everything you can do to an array), but fundamentally there's no difference between the two cases.
Now, if we ignore the particulars of your comment and the way you phrased it and look at your broader argument, I actually will believe that's the reason. If r
is a reference, then &r
actually evaluates to the address of r
's referent. So if arr
is an array of references, then &arr
is the address of the referent of the first element of the array. But then what's &arr+1
? Well... that's a bit harder. Under any reasonable evaluation rules, it would be the address of the referent of arr
plus the size of that referent. But that's not necessarily &arr
. In other words, arrays of references break the identity that &arr+k == &arr[k]
. That's pretty bad.
So good thinking.
Yakk wrote:sizeof(array)/sizeof(array) seems like a reasonable reason to avoid arrays of references. Not an unboundedly strong reason, but a non-trivial one.
I don't see why that's any more of a problem than sizeof(some_reference_variable). They could define the size of the array as the size of each element times the length. It might not agree with the actual storage space used, but that problem already exists with references.
letterX wrote:Well, in general, it seems that references really aren't first class objects in C++. They unfortunately make the programmer think that they're secretly a pointer, but the compiler is allowed to do pretty much anything with them (they have completely undefined values, and may not even exist as a value in the first place). Really, they're better off being treated as semantic sugar for compiler-voodoo than anything else.
Thinking of references as syntactic sugar for const pointers is perfectly fine. The compiler is often allowed to do anything it wants with, including optimize away, pointer variables too. The only real difference is that a reference's lvalue is the pointer's target, not the reference itself; in other words, you can't get the address of a reference itself. (This means that the one thing which you can do to absolutely guarantee that the compiler can't optimize away a pointer (i.e. take its address and do something observable with it) you can't do to a reference.)