Pointer Questions?

Yes, the reason is that you have to. Assigning '5' to a pointer, just doesn't work. The pointer would be pointing at whatever is stored at '5', which could be anything. Do *not* do that.

A reason to use new when you could use a non-pointer, would be to dynamically create something. Let's say that you have a file like so:

numberOfInts 51 2 3 4 5

And you want to read in numberOfInts and then load in that number of ints. While you *could* use an std::vector, list, etc., that might be overkill. Instead you can go like so:

int *pLoadedInts;pLoadedInts = new int[numberOfInts];

I'm confused here. I'm assuming your global vector is a std::vector, in which case you could just use g_vecInt.push_back(5), couldn't you? Why are the pointers in there at all?

Plus, don't you need to dereference that int pointer when you assign to it? It should be *pNewInt = 5, I believe. Even so, you shouldn't be assigning values to a dereferenced pointer if it hasn't been assigned memory already, that can lead to Bad Things.

If I'm incorrect, could you post some more code to give this a better context?

There are six lines of code, all of them incorrect in any imagineable context.

I have the feeling that you just haven't studied pointers as much as you should. You don't understand what '*', 'new', or 'delete' do. So, go back to your book and start reading.

Thanks

I was just wondering:
1)
If I have a class that is 20 Bytes. And I create a pointer to the class, eg
CObject *newObject=new cObject;
Is the memory allocated so far 4 Bytes or 4 + 20 Bytes, because surely the pointer is pointing to something that takes 20 Bytes of memory.

2)
If I have a global vector full of pointers to objects and I need to clear the vector list each frame (using delete) and add to the list each frame (new), would it be better to not use pointers in this case? , eg
CObject newObject=5;
g_vecInts.push_back(newObject);

Cause then I can just clear it using .Clear()

I have to agree with mikeman, but to answer your questions:
1) Yes, calling new will allocate 20 bytes for you.
2) In a general sense, it's not a good idea to re-allocate a lot of memory per frame. You'd be better of allocating once at the start of your application, and then overwriting the values per frame, thus re-using the memory.

Quote:

Original post by utilae CObject newObject=5; g_vecInts.push_back(newObject);

Even if your compiler should be smart enough to just create the object in place, I would use g_vecInts.push_back(CObject(5)); (though with just 20bytes it hardly hurts to copy it around a bit).

That is assuming you REALLY have to create and destroy all that stuff every frame. But even then, chances are the vector will keep the memory (or at least a good bit of it) reserved, if in doubt, you could try g_vecInts.resize(0) instead of clear() (never looked at the implementation, might be just the same).

But based on that completely weird stuff in your first post I would agree to learn more about pointers and dereferencing them before any of the above should even remotely matter to you.

Quote:

Original post by utilae //So I could use new, but then I have to use 'delete' to delete it: *** Source Snippet Removed *** //I can also not use 'new'. I don't have to remember to use 'delete': *** Source Snippet Removed *** Any disadvantage when not using 'new'?

It depends what you want to store in the Standard Linked List/Vectors. If you want to store the pointers (a.k.a. the memory addresses of your objects so you can use reference) then yes you need to use new, if you want to store your objects in stl directly then no.

A:


Or with pointers

B:


In case of A the memory is being copied over and so yes this maybe un-efficient but it is not really important if your not copying over the data every frame.

Quote:

Original post by mikeman There are six lines of code, all of them incorrect in any imagineable context. I have the feeling that you just haven't studied pointers as much as you should. You don't understand what '*', 'new', or 'delete' do. So, go back to your book and start reading.

Quoted for emphasis.

And once you understand pointers, avoid using them as much as possible. That's not further rebuke - it's an important design principle. Even experts don't much around with more complexity than is needed; you don't write code to prove your skill, but to get the job done - and getting the job done *cleanly* is how you prove your competence.

Here is code that illustrates the problem you're trying to illustrate:



The way you handle it is not to create it. There is no other real option, because pointers have no concept of what they are pointing at, whether the memory is dynamically allocated, whether they 'own' the pointed-at thing or anything else. The best way to not create the problem, normally, is to store objects rather than pointers in the vector. The next best way is to use some kind of smart pointer. Because these are objects, they can track the necessary info, and also provide an interface that lets you treat them like pointers. Failing that, you need to have some kind of policy of "pointer ownership".