 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Understanding Pointers: A Game Developer's Approach |
|
 |
Narkster Member since: 4/5/2001 From: Misasipey, USA |
|||
 Posted - 11/21/2002 6:26:44 PM |
||||
| so can a pointer also be defined as an instance of an object? |
||||
|
||||
|
Ecko Member since: 9/7/2000 From: Etiwanda, USA!!!!!!! |
|||
 Posted - 11/21/2002 6:33:18 PM |
||||
no a pointer can be defined as something that points to an instance of an object  |
||||
|
||||
|
Drizzt DoUrden Member since: 8/19/2001 From: Parsippany, NJ, United States |
|||
 Posted - 11/21/2002 6:57:07 PM |
||||
| Very cool article... just in time, too! I've been wondering what exactly the -> did, and I always wondered why when I said "what's the point of using pointers?" a bunch of people said "Duh, artificial intelligence would be nothing without them!!" I see how this is true, in an RTS, this would be a great method of storing those 10 to 10000 enemies ^_^ (although there's probably still more to it). Also very well written and everything is explained well. It's the worst thing when the author tries to explain topics you don't understand with other new words you don't understand. Any words that the author assumed someone may not have known were defined simply and the article continued quickly. Great article, especially for all of the people who are trying to figure out what the heck pointers are for! ------------------------------ Have a r0xx0r 1337 day plx! |
||||
|
||||
|
doogle Member since: 11/21/2001 From: Christchurch, New Zealand |
|||
 Posted - 11/21/2002 7:44:06 PM |
||||
| Hey, good article. It cleared up my pointer/array questions. I used to just make random changes to how I declare/use my dynamic arrays until it compiles/doesn't throw errors. Thanks |
||||
|
||||
|
NETWARRIOR Member since: 11/23/2002 From: USA |
|||
 Posted - 11/23/2002 2:25:06 AM |
||||
| Hi, I would like to point out an error in visual c++ 6 sp5 or maybe other compilers as well, about initializing a pointer like: "char *pBuf = 0;" During several debugging sessions with applications such as a game engine, id3 editor, and game design tools, i've noticed that some of my pointers are never really initialized to zero (null), instead they are initialized to 0 on the first 2-bytes, so it looked something like on the variable debugging list: "pBuf | 0x00000003" This caused major errors when testing if allocation already happened. I suggest initializing a pointer like: "char *pBuf = 0L;" The L forces casting the zero as a long (4-bytes). Other than that, good job on the article. |
||||
|
||||
|
zithowa Member since: 11/8/2002 From: USA |
|||
 Posted - 11/23/2002 3:06:53 PM |
||||
| Ah, pointers. I've been confused about these things for a while, glad there's an article about them on gamedev for my eating pleasure =[ ]. Anyway, I have a question about 'deleting pointers.' Do you ever delete a pointer, or just the object it points to? consider this example: int * intPointa=new int[4]; int pointerToIntPointa=intPointa; //does this work anywayż now how do I delete the intPointa pointer, but not the object it points to? I believe pointerToIntPointa now points to the int array as well, and if for some reason I feel a need to delete the first pointer, how do I do it? |
||||
|
||||
|
ZealousElixir Member since: 6/20/2001 From: Huntsville, USA |
|||
|
Posted - 11/23/2002 9:10:39 PM |
||||
quote: I believe the second line will cause a conversion error of some sort (I don't think they're recognized as differing levels of indirection, or maybe that's not even what they are). What you're saying is 'assign the address which this pointer contains to an int' (note that pointerToIntPointa is NOT a pointer). So, you're basically just going to have the memory address in int format if you can even make that assignment (which you certainly can with an explicit typecast), but except for demonstration purposes, why would you? You don't delete the pointer, but you delete the memory at the pointer by means of the pointer. When you allocate memory, the memory address of a block of a given size is stored in the pointer. When you call delete, the data that was transparently stored about this pointer (including the number of elements in the array) at the time of the allocation is used to free the memory back to the heap. I think you were also asking if you can do something like this: int *intArray = new int[64]; int someInt = intArray[20]; ...and then delete someInt here? Not necessary, but you'll have to delete intArray at some point. Note that the second above line is equivalent to int someInt = *(intArray+20); I probably should've gone into the mechanics of pointers more deeply, but there are better resources out there. As for everyone who has said they liked the article, given suggestions, and asked questions, thank you (and you're welcome  )Peace, Warren 'zealouselixir' Moore Author of "UP:AGDA" //email me.//zealouselixir software.//msdn.//n00biez.// miscellaneous links [edited by - zealouselixir on November 23, 2002 9:12:06 PM] |
||||
|
||||
|
ZealousElixir Member since: 6/20/2001 From: Huntsville, USA |
|||
 Posted - 11/23/2002 9:26:25 PM |
||||
quote: Wow. Thanks for the tip. edit: Likely not necessary. See a few posts down. [edited by - zealouselixir on November 25, 2002 5:58:32 PM] |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 11/25/2002 3:10:49 PM |
||||
| I'd initialize my pointers to the C macro NULL if I were you, if only for compatibility. i.e: <data type> *<variable name> = NULL; |
||||
|
||||
|
Bile Member since: 1/29/2002 From: Canada |
|||
|
Posted - 11/25/2002 4:42:15 PM |
||||
| Hey, cool article, but I wonder if someone could clear something up for me. I have noticed in some sample code that occasionally a function will take a pointer-to-a-pointer to an object as an argument, such like CreateSomeObject(**Object) The **Object is expected to be a NULL pointer, and the function allocates the object on the heap and stores a reference into *Object. What purpose does the ** serve? Why can't the function just accept *Object as an argument? Has anyone else seen this? Thanks for any insights! |
||||
|
||||
|
ZealousElixir Member since: 6/20/2001 From: Huntsville, USA |
|||
 Posted - 11/25/2002 5:56:48 PM |
||||
quote: To clarify the above concerns. Were there any issues directly related to the usage of 0, or did you just have pointer problems which you speculated to be related to 0? quote: The argument to use NULL or 0 has been going on for awhile now. There's so much conflicting information out there, I'd have to actually read the standard to make sure, but I'm almost certain that NULL is not a standard macro. I've seen it defined as both (void *)0 (which gives C++ trouble because of strict typing) and 0. Let's be reasonable. The value for a null pointer is guaranteed by the standard to be 0, immutably, forever. Why would you favor a longer, potentially dangerous, and likely deprecated macro? Peace, ZE. //email me.//zealouselixir software.//msdn.//n00biez.// miscellaneous links [edited by - zealouselixir on November 25, 2002 5:57:13 PM] |
||||
|
||||
|
Miserable Member since: 4/26/2002 From: Lennoxville, Canada |
|||
|
Posted - 11/25/2002 6:08:33 PM |
||||
quote: Yes, certainly, and it can't just accept *Object because that's something completely different. *Object is a pointer to an object. **Object is a pointer to a pointer to an object, as you already noted. This is useful in various contexts, notably when you need to assign to the pointer (the pointer is passed by value, so if you assign something to it, only the local copy is changed; this way, you can assign a new value to the parameter, e.g. *Object=&SomeObject - notice that *Object dereferences the pointer-to-pointer to a pointer ...), or when you're dealing with multidimensional arrays (I'll leave examples to those better qualified to give them). |
||||
|
||||
|
Bile Member since: 1/29/2002 From: Canada |
|||
|
Posted - 11/26/2002 4:48:48 AM |
||||
| Thanks Miserable, honestly, I didn't even think of the by-value issue...now that you've mentioned it, it makes perfect sense! |
||||
|
||||
|
doogle Member since: 11/21/2001 From: Christchurch, New Zealand |
|||
|
Posted - 11/28/2002 6:26:45 AM |
||||
I swear I am sooo close to total understanding  I want to have a dynamic array of objects that will come and go, eg. at the start there will be no objects in the array, but then some will be added in along the way, and some deleted. I have declared the array like so: Object *o; o = new Object[MAX_OBJECTS]; Questions: a) Did this create MAX_OBJECTS number of Objects already? Or do I have to add them in like this: (o + 3) = new Object(); or something b) How do I find out if an array index does not contain an object (if the answer to question (a) is no)? I hope that made sense, its too late for logical thinking thanks BTW this should be the offical pointer thread :D |
||||
|
||||
|
ZealousElixir Member since: 6/20/2001 From: Huntsville, USA |
|||
 Posted - 11/28/2002 3:52:04 PM |
||||
| Okay. Object *o; o = new Object[MAX_OBJECTS]; o now points to an array of MAX_OBJECTS Objects. They have been fully initialized (via the default constructor) and exist in memory (on the heap, aka the free store). You may now use them just like "real" (static) Objects, for example: o[1].HitPoints = SomeValue; etc. So the answer to question (a) is yes. Question (b) is trickier, because "checking if an object exists" at a memory location can be risky. Here's an example: int *intarray = new int[8]; if(*(intarray+9)) *(intarray+9) = 15; There's nothing terribly wrong with the first two lines (actually, I'm not sure if reading the value of an element beyond an array's bounds is undefined or not. I suspect it is, but it doesn't cause a crash). The third line, however, will almost certainly cause a crash, because you're attempting to assign to a memory location beyond your allocated memory. Not sure if that answered your question. Feel free to ask further questions. Also, I don't assert that everything I've said is true. Corrections are welcome. Peace, ZE. //email me.//zealouselixir software.//msdn.//n00biez.// miscellaneous links |
||||
|
||||
|
doogle Member since: 11/21/2001 From: Christchurch, New Zealand |
|||
|
Posted - 11/28/2002 6:59:44 PM |
||||
| Hmmmmm ok. So what I have done is already create an array of actual objects. What I wanted to do was create a pointer to an array that I could add/delete objects to later. How would I do this then? |
||||
|
||||
|
ZealousElixir Member since: 6/20/2001 From: Huntsville, USA |
|||
|
Posted - 11/28/2002 9:36:34 PM |
||||
| Look into how std::vector and linked lists work. |
||||
|
||||
|
doogle Member since: 11/21/2001 From: Christchurch, New Zealand |
|||
|
Posted - 11/28/2002 11:20:52 PM |
||||
| ok thanks. |
||||
|
||||
|
NETWARRIOR Member since: 11/23/2002 From: USA |
|||
|
Posted - 12/1/2002 5:58:44 PM |
||||
| Continuing with assigning a pointer to 0L... First of all you got to remember that certain compilers specifically visual c++ 6 is something like 75% ansi-c. So even if the c++ standard say 0 (zero) will work when initializing pointers, visual c++ on the other hand does not follow this standard but instead implements a "NULL" keyword which may NOT be compatiable with OTHER compilers. I just find it easier and safer typing 0L instead of NULL or 0. btw, i heard micro$oft will be releasing a service pack next year for vc++6 and vc# that will up their ansi-c standard to 90%. Hopefully zero will work. Bye. |
||||
|
||||
|
ZealousElixir Member since: 6/20/2001 From: Huntsville, USA |
|||
 Posted - 12/1/2002 11:15:07 PM |
||||
| You still haven't told about any specific problems you've had with using 0 as the null pointer. I hesitate to believe that such a thing would be overlooked in Microsoft's implementation, but I'd gladly eat my words if it could be proven otherwise. Think about this though: the bit pattern of 0 as a literal constant is all 0s in bit form. Therefore, it makes little sense that assigning constant literal 0 to a pointer would result in it being set to anything but all 0s, UNLESS there was an aspect of the implementation which allowed for a pointer being viewed as null even when its value wasn't literally null. Peace, ZE. //email me.//zealouselixir software.//msdn.//n00biez.// miscellaneous links  |
||||
|
||||
|
NETWARRIOR Member since: 11/23/2002 From: USA |
|||
|
Posted - 12/3/2002 6:31:30 PM |
||||
| Alright, details... I begin rebuilding my milkshape3d model loader by extracting all graphic api specific code (which was opengl) and put it into it's own module because i was going to build a direct3d ms3d version and i didn't want to double code a ms3d loader. The d3d ms3d module didn't work on several test runs...program crashed because of an invalid memory pointer. Completely at random executions during debugging, i've notice that sometimes certain pointers like "m_pVertices" which was initialized to zero "0" during class construction, was instead holding "0x00000003" or "0x00000006". Now in order to prevent memory leaks, I test my pointers for null like: "if (!p)" which is the same as... "if (p == 0)" & "if (p == NULL)". But because my pointer holds a non-null address, allocation is skipped and an invalid pointer is accessed. Later on that day I discovered "0L" always made the value of my pointer: "0x00000000" when debugging. The next day I went through several different code modules where i initialized pointers to "0"...and guess what?! At random times during debugging, they came up as "0x00000003"!! So i changed all pointers initialized from "0" to "0L" and even tested my code over several times and "0L" works. Thinking more about it, this might not even be a compiler problem but maybe a CPU problem because i have a athlon btw, i had my old C programming teacher look at it...couldn't figure it out and then he came to the conclusions, "this must be a microsoft bug." NET |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
