One big red flag that I see in all your explanations is that you always stick the * next to the name of the pointer. This hints at a classic misunderstanding beginners have with pointers. Notice how I always stuck the * next to the type in the declarations, not next to the variable name (it makes no difference in compilation, but it makes a difference when it comes to understanding it right). Understand this:
When you are not in a declaration, if you put the * next to the pointer's name, it will dereference the pointer, meaning it will fetch the value at the address stored in the pointer variable.
When you have a variable, and apply the & operator on it, it takes the address of the variable. The address of a variable is just a value, a temporary value, it is not a pointer variable, and it is certainly not the pointer variable from which the original variable was obtained by dereferencing with *. When you have something that is a value, but is not a variable, in C++ lingo, it is called an rvalue (because it is not a variable, you cannot store values in it, but since it is a value, you can assign that value to a variable, i.e. it can appear on the right-hand-side of an assignment).
>>and it will have the same effect as &*raiz=&*p;
No. As I said, that statement should not compile, has no sensible meaning, probably does nothing if it happens to compile on your crappy windows compiler, but it really is unknown what the effect of that statement is. So, no does not have the same effect as , because the latter has an unknown effect if any.
>>well, what I´m trying to do is to save the pointer of the root of my avl tree(*raiz) and then make all the modifications, and save the resulting tree in *raiz.
Then it would appear that the statement you are looking for is:
But, to be sure, you should explain how this function is called, how is the parameter passed on the call-site, and what you expect will happen to the parameter after the function is finished. It looks to me like you might find that pass-by-reference is what you need.
I am just starting to teach myself C++ and i have no coding experience so please bear with me on this if I ask you to explain your reasoning behind your response.
My code is:
Let me know what you all think.
Keep in mind that the "=" symbol is an assignment operator - NOT an equals sign. For example, if you write: do not get into the habit of saying x equals 10! That is not what's happening. In C++, this is a valid statement: but mathematically that would be incorrect, since x cannot be equal to itself PLUS one more. Always say, "x is assigned the value of 10", or "x gets 10". It will mess you up later if you always think of the "=" sign as an equals sign - it's not, it is an assignment operator.
Any variable, such as or or , is a name for a memory location. If we say, "x = 10;" then we are saying "Place the value of 10 into the memory location that we call x". So any variable is a container of sorts that can hold something, and obviously that is what is required on the left hand side of an assignment operator, right? An l-value is just that, a container of sorts (memory location) that can hold a value, and that must be what is placed on the left side of an assignment operator.
Imagine that you had 3 bank accounts, and they were named , and . And you had $50 in each account. Now, if you said to the bank teller: then in essence you would be saying to transfer the $50 in your ex account and place it into your sum + count account. ??? That doesn't make sense - left operand must be an l-value! But, if you said then you would be saying "Take the $50 from my sum account and the $50 from my count account and place both in my ex account. Now that makes sense, since ex is a proper l-value, ie., one that can hold a value. Sum + count cannot hold a value, it is not a memory location, but rather is just a temporary value that is used in the middle of a calculation, and is just transient in nature. (Sum + count) is an r-value, one that goes on the right side of an assignment operator. R-values are not containers of any sort, like a memory location, but rather are just temporary values that come up in the middle of a calculation, which are soon discarded. So r-values generally go into l-values, but you had them reversed.
Just a note for clarification: - here (sum + count) replaces the value in ex, it isn't added to the existing contents of .