|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
I don't quite understand the confusion happening here...
Pointers are variables, just like an int / bool etc are. Variables hold values. Pointers are not magical or scary, they are just variables that hold a memory address. And, just like any variable, a pointer passed into a function will be passed by VALUE - the function gets a local copy of that variable. What does this mean for pointers?
Within our function, that memory address is still the same memory address of whatever we were pointing to. Its value is the same. If we dereference that pointer, we can meddle with the object it was 'aiming' at just like we normally can with pointers. However, if we change the value of the pointer in the function (the memory address it is 'aiming' at) those changes will NOT be echoed outside the function! Just like any other variable, if we pass a variable by value and then change its value those changes will be lost once the function ends. The pointer within the function will hold a new value (it will point at something new), while our original pointer outside the function will still hold its original value (it will still point to whatever it did before).
So, what do we do if we want a function to alter the VALUE of our pointer (alter the memory address it's aiming at)? Just like any other variable, if we want a function to change our original variable we either need to pass it by reference, or give a pointer to it. This is NO DIFFERENT for pointers (remember again that pointers are just normal variables that happen to hold a memory address).
I hope this helps.
|
On November 15 2012 19:15 Abductedonut wrote:Show nested quote +On November 15 2012 18:50 Tobberoth wrote:On November 15 2012 18:33 Abductedonut wrote:On November 15 2012 17:59 cowsrule wrote:
Care to elaborate on why those examples demonstrate the language is crap? I'd be interested in hearing that perspective based around the existence of pointers and references. Sure! I updated my post actually explaining the error instead of letting people figure it out for themselves for the newer programmers who come to this thread looking for advice/etc. Basically the idea is this. When you're learning C++ from the beginning, you're told that passing by reference (the &) for primitive types (int/char/float/double) is one way to make sure that you do not pass a copy of the variable to a function. That way, changes inside that function will actually change the variable permanently. Later on, you're introduced to pointers (the *) and you're told that passing by reference is really just pointers "in the background." And if you pass pointers (again, the *) of primitive types to a function, then the changes remain permanent. Now objects come along. Well, if I pass to a function a pointer to an object, shouldn't the changes I make to the object be permanent? That only makes sense, since passing pointers to primitives types made the changes permanent. However, that's not the case. Passing a pointer of an object passes that pointer by value (which does not even make sense). To make matters worse, structs are treated differently. So C++ in inconsistent in that sense. Why are my pointers to my objects being passed by value? Once you learn that, you "know" how to get around it but it still does not make logical sense. With C - C "classes" and primitive types are all treated the same way. You pass a pointer to a "class" or a primitive type, the changes are permanent. Wait, are you saying objects are passed by value by default in C++? (I haven't programmed C++ in a very long time). It seems to be logical that if you pass an object to a function, you would pass the pointer by value but that would be the same as passing the "object" by reference, so changes should be permanent. It seems weird to me that C++ would copy the whole object by default, just because a pointer to the object was sent by value (especially since it doesn't work like that in C#). No, that's not what I'm saying. Look, the POINTER ITSELF is passed by value. So modifications to the POINTER ( if the pointer is pointing to the object that originally called the function, changes WILL remain permanent in the object ). However, any changes made to the pointer will not be changed. Let me provide an example. Example: + Show Spoiler +
#include <cstdlib>
#include <iostream>
#include <string>
using namespace std;
class kitty
{
public:
int kittySize;
kitty();
kitty (const kitty& myKitty);
};
kitty::kitty ()
{
kittySize = 10;
}
kitty::kitty (const kitty& myKitty)
{
kittySize = -10;
}
void func(kitty*);
int main(int argc, char *argv[]
{
kitty *myAwesomeKitty = new kitty[1];
myAwesomeKitty->kittySize = 0;
func(myAwesomeKitty);
// Should this print as 0 or 10?
cout<<myAwesomeKitty->kittySize;
system("pause");
}
void func( kitty *myAwesomeKitty )
{
kitty myKitty;
myAwesomeKitty = &myKitty;
myAwesomeKitty->kittySize = 10;
}
Note in this case.. kittySize WILL BE PRINTED AS 0! Because we changed the VALUE of the pointer, any changes made to the pointers contents were discarded. Do you see how confusing this can get? *edit* Going to bed for now... I could see how my other post is confusing. No, the changes to the object itself are preserved if you DO NOT modify the value of the pointer. But any changes made to the pointer are discarded because the pointer itself is being passed by value Also, to the poster above me... thanks. I obviously don't know C++ when I pointed out the mistake of the original guy I quoted and proceeded to explain stuff to others. It's pretty easy to come in here and say "he doesn't know what he's talking about." If you're so great at C++ why don't you explain things?
That's what I expected, but how can you call this inconsistent? The pointer, which is comparable to an int containing a number which is an address to a point in memory, is passed by value. This is consistent, because primitive types are passed by value in C++. Confusing? Sure, if you don't understand what a pointer is and how C++ handles parameters, it might be surprising that changing the pointer itself has no permanent effect, while changing the object does. Surprising and slightly confusing? Sure. Inconsistent? No, I can't agree with that.
|
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others.
|
On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others.
Well, the problem is that you wrote that C++ is a trash language because it's inconsistent, which it isn't (at least in your example). It would be different if you wrote that C++ is a trash language because it's confusing to programmers who aren't very good at it.
|
On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others.
To follow on from Tobberoth, also the fact that you said this:
If you supply to a function a pointer to an object, the changes made to that object get reverted once you exit the function
Which is completely untrue.
|
On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others.
I'm intrigued to know what *should* happen in your last example-- what a non-confusing output would be (what Most Programmer expected).
|
On November 15 2012 19:52 Hairy wrote:Show nested quote +On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others. To follow on from Tobberoth, also the fact that you said this: Show nested quote +If you supply to a function a pointer to an object, the changes made to that object get reverted once you exit the function Which is completely untrue.
Yes you're right. That should be pointer. My bad. Will change that tomorrow once i'm not typing from a crappy phone =P Thanks for pointing that out to me.
|
On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others.
It is confusing to programmers who do not understand pointers, might be. But that does not make C++ shitty as you cannot make pointers in any other way for them to be internally consistent. So your C++ bashing is completely nonsensical.
|
On November 15 2012 19:54 Mstring wrote:Show nested quote +On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others. I'm intrigued to know what *should* happen in your last example-- what a non-confusing output would be (what Most Programmer expected).
You do realize most of the times when that mistake is made it's not in such a trivial and well written case, right?
Most programmers would expect the original objects size to change. When they not-so-obviously change the value of the pointer ( think after using something like strtok() ), it becomes hard to track. Most programmers have trouble with basic pointers to begin with... let alone passing pointers by value.
|
On November 15 2012 20:01 Abductedonut wrote:Show nested quote +On November 15 2012 19:54 Mstring wrote:On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others. I'm intrigued to know what *should* happen in your last example-- what a non-confusing output would be (what Most Programmer expected). You do realize most of the times when that mistake is made it's not in such a trivial and well written case, right? Most programmers would expect the original objects size to change. When they not-so-obviously change the value of the pointer ( think after using something like strtok() ), it becomes hard to track. Most programmers have trouble with basic pointers to begin with... let alone passing pointers by value.
I think that if you intend a parameter to be used for returning values you should use a reference or a const pointer. Then you can't make this mistake-- it won't compile.
Most Starcraft players can't cleanly execute a basic two base build; doesn't mean Starcraft sucks; everyone just sucks at it :D
|
Abductedonut, I really don't know what you're getting at,C++ is entirely consistent in the pointer/reference/value semantics and just like MString I'm very intrigued as to what you think should happen instead. Also, the examples you provide aren't idiomatic C++ anymore, you can't write some weird C with C++ mash and then blame C++ for how confusing it is. That's like writing Java code with block labels and abusing runtime exceptions for returning values and other shenanigans and then blame Java that it's confusing.
|
If you have a problem discerning betwenn an object and a pointer to an object you should not use a language that allows major fiddling with those things. It's really that simple. Furthermore, if you have problems discerning those very different things you really do not need the performance increase (if there is any at all considering how good compilers are these days) these options give you. Use a managed language instead.
Besides: the examples you gave are "C with classes" but in no way modern C++ code.
|
On November 15 2012 20:01 Abductedonut wrote:Show nested quote +On November 15 2012 19:54 Mstring wrote:On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others. I'm intrigued to know what *should* happen in your last example-- what a non-confusing output would be (what Most Programmer expected). You do realize most of the times when that mistake is made it's not in such a trivial and well written case, right? Most programmers would expect the original objects size to change. When they not-so-obviously change the value of the pointer ( think after using something like strtok() ), it becomes hard to track. Most programmers have trouble with basic pointers to begin with... let alone passing pointers by value.
I disagree with your assessment of what programmers find hard. Understanding pointers isn't hard. Memory management is a much more problematic area - as demonstrated nicely in your example where you forget to use delete.
Another issue is that people use pointers where they shouldn't. References should be used wherever possible instead of pointers, and where you do have pointers, you should probably be using shared_ptr / weak_ptr / scoped_ptr to make it clear who owns it, and eliminate problems with memory management.
There's also a problem with people using C style things in C++, and not using the much better options available. Why the hell would someone ever use strtok() when you have boost string algorithms, boost tokenizer, or even stringstreams and getline()?
|
On November 15 2012 19:56 mcc wrote:Show nested quote +On November 15 2012 19:40 Abductedonut wrote:
Guys... the point is not whether it makes sense to YOU or not. My point is that it's incredibly confusing to most programmers which thus leads to shitty/wrong code. Of course it's consistent with itself.
Also, i am not confused nor do i have a bad understanding of pointers. Read the thread. I'm trying to explain it to others. It is confusing to programmers who do not understand pointers, might be. But that does not make C++ shitty as you cannot make pointers in any other way for them to be internally consistent. So your C++ bashing is completely nonsensical.
Even more so because pointers are just one feature of the language, which, additionally, can (and should) be avoided a large majority of the time. In fact, thanks to templates and things like smart_ptr, if you start a project from scratch you only have a starting phase where you can write a basic framework for your project, make sure that the framework only deals with references when interfacing to the outside and from that point on you can literally code without seeing "type*" ever again, with the code looking much like Java code, just running a lot faster. And all of that without having to worry about leaking memory or undefined behaviour.
|
On November 15 2012 20:31 Schokomuesli wrote:
If you have a problem discerning betwenn an object and a pointer to an object you should not use a language that allows major fiddling with those things. It's really that simple. Furthermore, if you have problems discerning those very different things you really do not need the performance increase (if there is any at all considering how good compilers are these days) these options give you. Use a managed language instead.
Besides: the examples you gave are "C with classes" but in no way modern C++ code.
So if I did C_Player player;
Shade.OnLoad(&player, 0.5)
Then inside OnLoad
targetptr = target(name of the param of the passed object)
this->X = targetptr->X;
Should this not work? Because, it does not at the moment, and only with this function.
|
Just to get it right... What you are doing is:
{
(...)
C_Player player;
Shade.OnLoad(&player, 0.5f);
(...)
}
and inside Shade.OnLoad() you copy a value in player to a local variable in Shade, right? Furthermore: is the pointer you passed into OnLoad still valid when using it? In particular: do you use if after leaving the scope in which you created player (that is: the closing curly brace just below OnLoad ^)? Because after this brace, player does not exist anymore if you create it on the stack as you did in the example above...
If you do _excatly_ this:
{
C_Player player;
Shade.OnLoad(&player, 0.5f);
}
^and never again use anything inside Shade which refers to the pointer you passed you are fine and all of this should work.
If you do this:
{
{
C_Player player;
C_Player* player2 = new C_Player();
Shade.OnLoad(&player, 0.5f);
Shade.OnLoad(player2, 0.5f);
}
Shade.asdf1(); // asdf1 uses the pointer to player you passed /w onLoad before - this breaks
Shade.asdf2(); // asdf2 uses the pointer to player2 you passed /w onLoad before - this works because due to heap construction, the object player2 points to still exists...
}
This will not work... player does not exist anymore but you still have the adress where it used to reside before leaving the scope you created it in.
BTW, this is just guesswork without seeing the methods and the surrounding code...
|
+ Show Spoiler +On November 15 2012 22:07 Schokomuesli wrote:Just to get it right... What you are doing is:
{
(...)
C_Player player;
Shade.OnLoad(&player, 0.5f);
(...)
}
and inside Shade.OnLoad() you copy a value in player to a local variable in Shade, right? Furthermore: is the pointer you passed into OnLoad still valid when using it? In particular: do you use if after leaving the scope in which you created player (that is: the closing curly brace just below OnLoad ^)? Because after this brace, player does not exist anymore if you create it on the stack as you did in the example above... If you do _excatly_ this:
{
C_Player player;
Shade.OnLoad(&player, 0.5f);
}
^and never again use anything inside Shade which refers to the pointer you passed you are fine and all of this should work. If you do this:
{
{
C_Player player;
C_Player* player2 = new C_Player();
Shade.OnLoad(&player, 0.5f);
Shade.OnLoad(player2, 0.5f);
}
Shade.asdf1(); // asdf1 uses the pointer to player you passed /w onLoad before - this breaks
Shade.asdf2(); // asdf2 uses the pointer to player2 you passed /w onLoad before - this works because due to heap construction, the object player2 points to still exists...
}
This will not work... player does not exist anymore but you still have the adress where it used to reside before leaving the scope you created it in. BTW, this is just guesswork without seeing the methods and the surrounding code...
Thanks, but C_Player player is from C_Application.h and then implemented inside applications OnInit funktion. This should lead player to "die" at the end of the program, like every entity in my entitylist. I have tried making player dynamic, this did not work either. This is why I am confused atm.
|
^OK, then I have absolutely no clue... gl in finding the error, though...
|
On November 15 2012 22:27 Schokomuesli wrote:
^OK, then I have absolutely no clue... gl in finding the error, though...
Hehe thanks anyway 
|
On November 15 2012 22:22 Nausea wrote:+ Show Spoiler +On November 15 2012 22:07 Schokomuesli wrote:Just to get it right... What you are doing is:
{
(...)
C_Player player;
Shade.OnLoad(&player, 0.5f);
(...)
}
and inside Shade.OnLoad() you copy a value in player to a local variable in Shade, right? Furthermore: is the pointer you passed into OnLoad still valid when using it? In particular: do you use if after leaving the scope in which you created player (that is: the closing curly brace just below OnLoad ^)? Because after this brace, player does not exist anymore if you create it on the stack as you did in the example above... If you do _excatly_ this:
{
C_Player player;
Shade.OnLoad(&player, 0.5f);
}
^and never again use anything inside Shade which refers to the pointer you passed you are fine and all of this should work. If you do this:
{
{
C_Player player;
C_Player* player2 = new C_Player();
Shade.OnLoad(&player, 0.5f);
Shade.OnLoad(player2, 0.5f);
}
Shade.asdf1(); // asdf1 uses the pointer to player you passed /w onLoad before - this breaks
Shade.asdf2(); // asdf2 uses the pointer to player2 you passed /w onLoad before - this works because due to heap construction, the object player2 points to still exists...
}
This will not work... player does not exist anymore but you still have the adress where it used to reside before leaving the scope you created it in. BTW, this is just guesswork without seeing the methods and the surrounding code... Thanks, but C_Player player is from C_Application.h and then implemented inside applications OnInit funktion. This should lead player to "die" at the end of the program, like every entity in my entitylist. I have tried making player dynamic, this did not work either. This is why I am confused atm.
Then what exactly is strange in your program then? Explaining it in words is kind of hard to understand. You should post some code example. Btw. if your problem is that the pointer is slightly offset then that may be due to multiple inheritance if you use that. Don't let us puzzle, post a self contained example.
#include <iostream>
class Base{public: long padding;};
class Base2{};
class Derived : public Base, public Base2{};
int main(){
Derived d;
Derived *ptr = &d;
Base2 *bas = static_cast<Base2 *>(ptr);
if((void *)ptr != (void *)bas){
std::cout << "the wonders of multiple inheritance" << std::endl;
}
return 0;
}
|
|
|
|
|
|
EPT
