Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Dynamic Memory. Is this bad?

Author
Message
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 9th May 2010 14:00
This is strictly a C++ question, but I can't think of anywhere else to post this.

I'm trying to dynamically allocate memory. I figured I would have had this down by now, but apparently not.

Here is my code so far for adding an element to an array:


My question is... is it bad to be doing it this way? As far as I can tell I'm properly handling the allocated memory, but I'm not entirely sure if "delete" is indeed freeing up the previously used memory. Using this code, it runs fine for a little bit, but then I get an exception thrown on the "delete [] pParticles;" line stating "Access violation reading location 0xdad700f0."


Can someone tell me if I'm doing this wrong? Or better yet, another way that doesn't involve me downloading new classes and stuff?


The one and only,


JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 9th May 2010 16:37
I see a couple problems here, but to start with your first question; you have no error checking. It's entirely possible that you are trying to delete [] a NULL handle - which would give that error you describe. To fix it,



Also, there's no verification that the allocation even worked:



That's it for the error checking - rudimentary and basic, but should help find your problem. Sprinkle in a couple of assert() calls and you should be good to go...

Now, for the second question: I would use an std::vector<> instead. Of course, behind the scenes, its doing the same thing as you are currently doing (more or less) but your code is a lot easier to read and follow... Here's how I would rewrite your current function:




Finally, the last thing I see is this would be relatively slow because (as far as I can tell) each particle object is an instance not a pointer to an instance.

Here's why: When ever you try to copy one instance to another, you are unknowingly calling the object's constructor / destructor pair for each copy. Allocations and deallocations are slow by nature. You want to limit the number of times you do either (if at all possible), and the best way to do that would be to create the new particle as a pointer (new) - then you can just copy the address in memory from one-array to another w/o having to call the constructor / destructor for each particle every time you copy them.

With that in mind, here's how I would rewrite the std::vector form of the function (again, to alleviate the number of constructor / destructor calls)



I hope this helps,

JTK
Mireben
15
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 9th May 2010 16:54
Even if you can get your code to work without error messages, it's inefficient because every time it's copying the whole array twice. It could be done with one copy only. It would be even more efficient to reserve more space in advance and extend the array by 10 or 20 elements at a time, not one.

However, the std::vector already does all that. So I second what JTK said: use a vector.
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 10th May 2010 01:31
I initially wanted to use a vector, but whenever I tried to use a vector alongside using DarkGDK it would get Link errors about unresolved symbols relating to the "std".

If I could use vectors, I definitely would. Have either of you been able to get them to work while using DarkGDK?


The one and only,


Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 10th May 2010 01:37
Project->Properties->C/C++->code generation

Change runtime library from multi-threaded debug(/MTd) to multi-threaded(MT).

Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 10th May 2010 01:47
Where do you people learn these things? Maybe I can go there and not have to waste everyone's time with things like this.


That let it compile. Still unsure about whether it's working or not, but at least it's a step in the right direction. Thank you.


The one and only,


Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 10th May 2010 01:51
I think everyone posts with that same problem at some point, I did and branflakes told me. You need to do it if you use any of the standard library stuff.

JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 10th May 2010 02:07
Don't forget to include:



in all of the .cpp files that uses std:: anything (otherwise you have to add std:: in front of everything)...

JTK
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 10th May 2010 03:54
JTK, delete and delete[] are both guaranteed to work when passing 0/NULL as defined by the C++ standard, also, the 'new' calls used in every example on this thread will never return 0/NULL, if there is an allocation error then they will throw an exception.

Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 10th May 2010 04:29
In one of the pointer tutorials I read, if I use (nothrow) I can avoid an exception being thrown but will then need to check for the 0 pointer if allocation failed. This is correct?



The one and only,


Mireben
15
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 10th May 2010 08:48
It's correct, it's described in the C++ language specification book as well.

It just occurred to me that the access violation may not only be caused by the dynamic memory handling but also by something in the destructor of the particle class. For example, several particles using a pointer to the same memory area and trying to delete it multiple times. In that case you will have a problem with the vector as well, if you try to delete the particles in it. Examine that possibility too.
Plystire
21
Years of Service
User Offline
Joined: 18th Feb 2003
Location: Staring into the digital ether
Posted: 10th May 2010 12:01
Thanks guy, I got the vectors working and the particles are working just fine, albiet too many slow things down a lot. But being able to have 2000 active particles before a slowdown isn't too bad.


The one and only,


Login to post a reply

Server time is: 2024-07-07 02:04:15
Your offset time is: 2024-07-07 02:04:15