Printable View
I was wondering if there is anything wrong with using malloc in a C++ program. I also remember reading a thread some time ago about making a "renew" operator similiar to realloc. If you are using a block of memory and want to change the size frequently without using a temporary block to copy data, I think using malloc is better because you can then use realloc. But is realloc really any faster? Maybe it just does the copying behind the scenes, especially if the block is not able to fit.
There are dozens of different ways to solve this particular problem. C++ std::vector does indeed solve this particular problem, but it does in effect do the same thing as realloc(), and I doubt that it's MORE efficient than using realloc in the cases where realloc and vector solves the same problem.
Another solution would be to allocate (with whatever method) larger blocks in for example a linked list. If you know that you will have thousands of entries, but it may grow to lots more, you may allocate blocks of for example 4000 (or just under 4096, to allow the block to be a multiple of 4096 bytes with room for a header block with links and other admin) entries, and then link them together.
But the initial thought should probably be to use vector.
--
Mats
When using vectors, reserve() can be used if you know in advance the exact maximum memory capacity needed, and the "swap trick" can be used to trim the capacity to the actual size of the vector, if you don't know the final size in advance. Together these give the same control over memory use as malloc()/realloc().
http://www.informit.com/guides/conte...lus&seqNum=268
Technically there's nothing wrong with using malloc() in C++, as long as you only use it on PODs. Once you get into objects, you have to use new, otherwise the constructor won't be called. I've seen C++ code that uses malloc() for char* strings and new for objects. I consider it very bad code though, because when it comes time to delete the pointers, you'll be in a whole lot of trouble if you accidentally call delete with malloc()'ed memory or free() with new'ed memory. That sort of code comes from people who think they're smarter than their compilers and are trying to optimized code that probably doesn't need to be optimized to begin with.Quote:
Originally Posted by MacNilly
The use of malloc in C++ certainly isn't inheritably bad, but it is discouraged. I really see no need to use malloc at all in C++.
You mean beside a trivial implementation of a new() operator? ;-)Quote:
Originally Posted by Elysia
--
Mats
If you override new, you probably want to use something else rather than malloc seeing as it does the same thing as new... so no ;) If I override new, I'm looking for something more like VirtualAlloc or something.
Unless the purpose of overriding new is not to change the function, but to track allocations and deallocation, of course.
Malloc can also be used for the explicit purpose of using realloc, in the rare cases that such an optimization may be worthwhile.
thanks for all the replies; the swap() trick was particularly helpful.
But then you probably wouldn't override new but make your own allocation/deallocation function...Quote:
Originally Posted by King Mir
Though you may be right. One small plus for malloc inside C++.
If you're doing that with objects, malloc()/realloc() probably isn't a good idea because realloc() will move memory if there isn't enough space. Moving objects without destructing & reconstructing them is probably a bad thing. In my earlier posts on the same subject I found a Windows specific way using HeapAlloc() & HeapReAlloc(). HeapReAlloc() has an option to expand or fail rather than expand or move the memory - realloc() doesn't have that option.Quote:
Originally Posted by Elysia