   When should pointers be really used?
  I understand the point of pointers, and I understand what they do etc. But when exactly should they be used? I was thinking of this when looking through my code, I relized that I use pointers alot in my code, but without a reason. Example, I have a player class, and reasonably speaking a players "Belt", and "Bag" won''t be shared by anyone but that player, right? Yet the contents of the bag can link to a map of individual items that can exist in a bag. That having been said, both the bag and the belt shouldn''t be pointers right? 
  the first reason to use pointer is to use dynamic memory allocation.so, it''s not wrong to use them in your code where you have such circumstances.antoher reason to use pointers is the situation, when you have to point onto different objects; in a list, where you have the current position indicated (if it''s not already indicated by an index)in my code i''m completely pointer-based, because i have a memory class which is responsible to manage all the memory.hope this helps.   DJSnow---this post is manually created and therefore legally valid without a signature ;  But for something like a player class, a player must have; Location, Bag, Belt, Stats, etc ... I''m not going to be sharing any of these types with other classes so there is no need to have them pointers right? ;  I generally use pointers because I know that I can keep track of them. I always find pointers easier to pass around should you ever find yourself needing to.I personally feel it''s a matter of coding practice, if you''re happy with the way you do it and it works, then carry on. ;  If you *know* what your object will contain at the moment it''s instanciated, and how many of it (Location, Bag, Belt, Stats, etc...), then you should not need to use pointers.Similar to DJSnow, there are 3 situations in which I use pointers.- When I need to actually point something in memory (setting the pointer with an instruction like SomeClass* ptr = &someObject; )- When an object or part of an object must be passed as a parameter to a function, or returned as the return value of a function.- When I need an array of a size that is unknown at compile time.  Then I use a couple of instructions like:    SomeClass* ptr ;    ptr = new SomeClass[someValue] ;Outside of those 3 particular situations, static memory suits my need 99% of the time. The highest sounds are hardest to hear. Going forward is a way to retreat. Great talent shows itself late in life. Even a perfect program still has bugs- The Tao of Programming ;>>But for something like a player class, a player must have; >>Location, Bag, Belt, Stats, etc ... >>I''m not going to be sharing any of these types with other >>classes so there is no need to have them pointers right? perhaps i don''t understand this, but it has nothing to do with each other: what do you mean by "sharing" ? please make this more clear.but, your above example, is a good situation; imagine a circumstance, where you have to load X players into your world from a file; you don''t know how much to load, unless you have looked in your config-file, for example - then you take this number out of the config-file, let us guess a "9", then you have to create 9 players; or 25, or 327; how would you achive this without using pointers ? thats the point. here pointersare the only way to do this (yes, excepting some other constructs, but we are talking about pointers).got it ? DJSnow---this post is manually created and therefore legally valid without a signature ;  Oh, I know that! What I mean by sharing is that the variables that the player class arn''t going to be common variables across other player classes, so there is no point in having them as pointers.What I am using pointers for are the multimaps that contain the items. I have a global item list, and I have an item list the player has(A bag), and items in the player item list are pointers to the items in the global item list(Items in the global item list will remain constant). ;  Once I tried to pass a pointer, but it was quite painful. 