Sign in to follow this  
skulldrudgery

Is this a memory leak?

Recommended Posts

Bob Janova    769
I imagine so, as there is now no way to free the memory allocated by the first call. That's nothing to do with the size of memory you're getting, by the way.

Share this post


Link to post
Share on other sites
Kalazart    148
Yes. You are not deleting after repositioning your ponter to the newly created memory block. Doesn't matter if it is a bigger or smaller number: the memory isn't reused when you do new unless you have deleted it.

Share this post


Link to post
Share on other sites
skulldrudgery    253
So, I should delete the allocated memory before I resize it, then set it to NULL (or can I just new it again without setting it to NULL?).

And thanks for the snappy responses.

Share this post


Link to post
Share on other sites
tychon    652
You can just new it after a delete. You set it to NULL when you don't plan on reusing it, but wish to safeguard against accidentally trying to do so later on.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
It is faster to use malloc and realloc, then to delete and new.

Share this post


Link to post
Share on other sites
tychon    652
Quote:
Original post by Anonymous Poster
It is faster to use malloc and realloc, then to delete and new.


Except for the whole not handling object constructors and destructors.

Share this post


Link to post
Share on other sites
CTar    1134
Quote:
Original post by Anonymous Poster
It is faster to use malloc and realloc, then to delete and new.


But a very bad idea, for many reasons. Also for POD-types the performance is most likely the same and for non-POD types malloc and realloc wont work properly.

Share this post


Link to post
Share on other sites
Kalazart    148
Malloc: allocates memory -- O(c)
New: allocates memory, calls constructor for every element -- O(n)

GCC (don't know if others compilers do this) has an awsome facility when it comes to allocating POD or non POD types.

It checks if the type is POD or not and, then, you get to call different functions by using a dummy argument: one function has __false_type (for non POD) and the other has __true_type (for POD).


#include <bits/type_traits.h> // for __false_type and __true_type
#include <stdlib.h> // for malloc
#include <stdexcept> // for std::bad_alloc

#define verif_POD_type(__type__) typename __type_traits<__type__>::is_POD_type()

template <class Type>
void __allocate_aux(Type *ptr, unsigned int size, __false_type) // isn't POD
{
try {
ptr = new Type[size];
}
catch(std::bad_alloc ex) {
// do error stuff
}
}

template <class Type>
void __allocate_aux(Type *ptr, unsigned int size, __true_type) // is POD
{
ptr = (Type*)(malloc(sizeof(Type)*size));

if(!ptr) {
// do error stuff
}
}

template <class Type>
inline void allocate(Type *ptr, unsigned int size)
{
__allocate_aux(ptr,size,verif_POD_type(Type));
}




You can do the same with deleting.

Share this post


Link to post
Share on other sites
Spoonbender    1258
Quote:

bar *foo;



foo = new bar [100];

foo = new bar [10];

Think of foo as a letterbox or something. It just holds the address to something so others can reach it, nothing else.
So first, you store the address of your bar[100] array. Then you store the address of your bar[10] array. Since the variable only holds one address, the first one will be lost. It doesn't matter what each address points to. Whether the first points to something bigger than the latter or vice versa, or whether they're even valid addresses doesn't matter. When you assign to foo, all you do is store a new address, and throw away the old one. Nothing is done to the objects pointed to by the addresses.

So yes, it's a memory leak. You have no way of retrieving the address of your bar[100] array because the only place you stored the address has been overwritten.

Quote:

It is faster to use malloc and realloc, then to delete and new.

If you use malloc instead of new because "it's faster", you need help. There are plenty of reasons for using one or the other, and some are even valid, but performance shouldn't be one of them. For one thing, it's *much* faster to just avoid having to call malloc/new in those performance-critical parts of the code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this