"Pointers make my head spin" etc ...

Whandall:
I think it is treated the same way, because
myRF24.write(myArray, 1);is only a shortcut for

myRF24.write(&myArray[0], 1);

OK. Then my question is why didn't they make it so that the same shortcut works with the simple variable myVar? (i.e. so the & is not needed)

...R

There is no shortcut in the myVar case, because there is no myVar[0].

Robin2:
OK. Then my question is why didn't they make it so that the same shortcut works with the simple variable myVar? (i.e. so the & is not needed)

This has been covered fairly extensively above, but to summarize:

the standard conversion for arrays is needed to access array elements. This is because the subscripting operator works with pointers (not actually an array specific operator)

The expression E1[E2] is identical (by definition) to *((E1)+(E2))

Its identical form (second one listed above) shows that either E1 or E2 must be a pointer as it is dereferenced to access the value.

The code below is accessing the second element of the array two different ways using the subscripting operator, showing that at least one operand must be a pointer:

int array[5];

int a = array[1];

int b = 1[array];




So even though an implicit array to pointer conversion may seem strange, **it is in fact needed to access elements of arrays**.
...
An **array is [u]unrelated[/u] to 'ordinary' variables**, and it has its own features just as primitive types have their own standard "integral conversions".
...
And why does an 'int' not do casting like this by default? Well that is because it **does not make sense**, is illogical, and is **unrelated to an array**.
...
There are no inconsistencies here. I'm confused as to why you trying so hard to connect two [u]**unrelated**[/u] things.
...
These aren't inconsistencies, its **a flawed approach comparing two dissimilar things**.

And one more to the pile from Whandall:

There is no shortcut in the myVar case, because there is no myVar[0].

So as you can see, there is no array logic in 'simple' variables, because they aren't arrays. The array functionality is there because it is required, as I have mentioned above.

Your shortcut that you cannot understand why it isn't available to a standard variable makes no sense, why, because the choice is ambiguous: Do you return a pointer, or the actual int. With an array id (without subscript) all you have is a pointer to the first element, as an array reference and array pointer are not compatible and ignored.

pYro_65:
Your shortcut that you cannot understand why it isn't available to a standard variable makes no sense, why, because the choice is ambiguous: Do you return a pointer, or the actual int. With an array id (without subscript) all you have is a pointer to the first element, as an array reference and array pointer are not compatible and ignored.

Thanks.

That makes some sense.

It has taken a long time :slight_smile: :slight_smile:

...R

Robin2:
Thanks.

That makes some sense.

It has taken a long time :slight_smile: :slight_smile:

...R

lol, glad to be of service.

On further reflection I think I still have the same problem.

Based on your explanation I can understand why there is a need to use &myVar so as to make it clear that it is the address that is needed rather than the value.

However if the system was consistent you would also be required to use &myArray when you want the address of the array. Using myArray with neither an & nor a subscript should cause an error.

(Keep in mind that this is a language that prides itself on being pernickety)

...R

Robin2:
However if the system was consistent you would also be required to use &myArray when you want the address of the array. Using myArray with neither an & nor a subscript should cause an error.

That is how you get an address of an array!

But that is the problem, it is a pointer to an array not a pointer to the first element. If you used a subscript operator like (&myArray)[3] you are attempting to access an array of arrays. Each index moves the pointer the length of the entire array - and is valid in some circumstances (multidimensional arrays).

The biggest point to mention here is 'myArray' is not returning a pointer to the variable, but an element - a closed concept only for arrays. '&myArray' and '&myInt' are both returning pointers to the variable you are using. Which is consistent use of the address-of operator.

If you dereference the pointer returned by '&myArray' and '&myInt' you return to the original variable. Whereas dereferencing the pointer provided by 'myArray' you get a reference to an element, which has nothing to do with the array.

If the rules you mentioned were in place, there would be no way to access the elements of a variable without some ugly code which converts the array pointer to a primitive pointer, then using pointer arithmetic to move along raw bytes.

((char*)(&myArray))[ 4 ];

This method is quite ugly, and breaks the strict typing elements. It allows you to completely disregard the type of the array, and has no size information associated with it. The array might not even be a char type.

And as for consistency, the way array's are accessed in C++ is consistent with 90% of other languages that use arrays. The parts that differ are because C++ has the concept of pointers, which many languages do not.

Another point is in reality, 'myArray' and 'myInt' are both expressions returning a reference to themselves. I think what you were saying is inconsistent, is actually there, it is just not as obvious. The code below shows this:

  int array[10];
  int (&arrRef)[10] = array;

  int value;
  int &valRef = value;

The reason why an array can cast is because it has a built in conversion. This concept can be described with a struct:

The code below will not work because a pointer and object are not compatible.

struct Foo{
  char *ptr;
};

void setup() {

  Foo foo;
  char *ptr = foo;
}

void loop(){}

However adding a conversion operator, like what arrays have built in, then it can:

struct Foo{
  //Conversion operator
  operator char*(){ return ptr; }
  char *ptr;
};

void setup() {

  Foo foo;
  char *ptr = foo;
}

void loop(){}

And, after a good night's sleep I am less convinced of the logic in the piece I quoted in Reply #40.

I don't really see why the choice would be ambiguous - why would I want the address of a simple variable? If it is a simple variable just assume I want the value.

There could be a special "add on" for those folks who really do want the address of a simple variable.

...R

Robin2:
I don't really see why the choice would be ambiguous - why would I want the address of a simple variable? If it is a simple variable just assume I want the value.

Exactly! That is what happens now.

You were originally asking:

I know that an array will cast to a pointer. What I don't understand is why a simple variable will not also cast to a pointer?

You have answered this yourself: "why would I want the address of a simple variable? If it is a simple variable just assume I want the value.".

And if you checkout the two lines above the first code box in my last post, you'll see that this behavior is consistent!

The ambiguity I mentioned would happen if a variable could return a value, or pointer when used in a pointer expression. This is because a pointer and a pointer can be added together (pointer arithmetic), but a pointer and an integral type can also be added together - so if the conversion you proposed was introduced, which one do you use... the pointer or value?

This is not the case with an array as only the pointer conversion is compatible. An array type cannot be cast to any other type except a reference to its own type. The ambiguity appears when there are two or more conversions which are compatible with the type being converted to (C++ is allowed to implicitly cast once for anything if there is an appropriate conversion available).

See Reply #33 :slight_smile:

We have wasted enough bandwith and server storage on this.

...R

Robin2:
See Reply #33 :slight_smile:

We have wasted enough bandwith and server storage on this.

...R

Hmmm, it doesn't seem like you really know what you are trying to explain.

Why don't you do a big favor and justify these two statements you have made, then possibly your other wavelength may come to light:

I know that an array will cast to a pointer. What I don't understand is why a simple variable will not also cast to a pointer?

and

why would I want the address of a simple variable? If it is a simple variable just assume I want the value.

?????? Seriously what is going on, I'm quite intrigued!

All of your posts repeat the same thing over and over, then you answer your own question. If you wrote the wrong thing, this isn't a different wavelength, it is bad communication.

Why don't you try and explain what your gripe is in more than two sentences.
Or if you are waiting for people to simply agree with you, regardless of how many logical explanations are put forward, then you are simply just trolling (in which case you don't really agree with what you are writing).

Don't worry about bandwidth, the forum admin certainly don't, did you know that an open forum page checks for new alerts every 10 seconds. Multiply this by everyone online, and a few posts really are insignificant.

I would really like to know what the hidden meaning is in your quotes:

However if the system was consistent you would also be required to use &myArray when you want the address of the array. Using myArray with neither an & nor a subscript should cause an error.

Answered here

OK. Then my question is why didn't they make it so that the same shortcut works with the simple variable myVar? (i.e. so the & is not needed)

Answered here & here & here

I know that an array will cast to a pointer. What I don't understand is why a simple variable will not also cast to a pointer?
...
it makes even less sense for the compiler not to also cast an ordinary variable name to a pointer when it is "used in an expression that accepts a pointer as an operand"

Answered here & here & here & by yourself

I think the difference between us is that you are describing HOW C/C++ works whereas I am asking WHY does it work like that (because it seems to me to be inconsistent).

Another way that this "inconsistency" could be avoided would be if it was necessary to do an explicit cast to a pointer for an Array as well as for a simple variable.

And this is answered in pretty much every post in response to your questions. The reasons explaining this contain both how C++ works and why it works this way. I have also explained the consequences of why it wouldn't work if things were how you'd prefer.

Simply, what you would like to see, you yourself have given a reason as to why adding the functionality you would like is silly regardless of how consistent you think it could be. And I have given compelling evidence as to why things wouldn't work if we removed what you don't like.

To go back to the title - my head is spinning :slight_smile: :slight_smile:

...R

Robin2:
To go back to the title - my head is spinning :slight_smile: :slight_smile:

...R

It sure is. When you get yourself straightened out, feel free to join an intelligent discussion.

Avoiding the question I asked at the top of my last post is credible evidence you are just trolling, and have been caught out in it by answering your own irrationality.

See my comment at the bottom of Reply #28.

...R

Oh children ... behave now! :slight_smile:

Amen.

I am waiting for the sun to emerge from the mist - it is forecast to appear soon.

Let me try to re-present my question.

In Reply #35 I said

If I want to use this function call
bool RF24::write( const void * buf, uint8_t len)
I can do it like this

myRF24.write(myArray, 1);

or

myRF24.write(&myVar, 1);

Would it be possible to have written the C/C++ compiler so that these would both work

myRF24.write(myArray, 1);

or

myRF24.write(myVar, 1);

...R

I learned Forth before I learned C, which has pointers and is less complicated than C++ so it's been easier for me. Forth uses addresses without extra packaging.

int x;

int y[] = { 0,1,2,3,4 };

The difference between x and y is that x is a variable and y is an array of variables.
They shouldn't be treated the same.

int z = 7;

z += x;
z += y; // trying to treat array y the same as variable x, should z now == 17?

However I can treat x and y[0] pretty much the same which makes sense since both are ints.

x = 4;
y[0] = 4;

To stop the spinning I think that the spinners should learn how memory works, what addresses are and then proceed to how they are used in whatever language has them spinning.

Most confusion is due to either unknown or misunderstood knowledge. First thing to do is to clarify your understanding. I live in a country where so many people consider their ignorance as some kind of sacred, I see the need for clarity all around me every day.

Reply #54 does not deal with the question I posed in Reply #53

I am not asking for an explanation of how the language works. Rather I am asking could one aspect of it have been done differently if the original designers had been minded to?

As far as I can see the compiler will be perfectly well aware that myVar is a simple variable and could make the reasonable assumption that I am only interested in the value at that memory location.

...R

Perhaps you need caffeine or new glasses.

The difference between x and y is that x is a variable and y is an array of variables.
They shouldn't be treated the same.[\quote]

is not "how the language works".