Is it safe to use malloc and it's derivatives with native C++ types? As sort of a learning experience I want to write my own stack class, first with integers, and I can't imagine how i'd write a dynamically sized array without using these functions. Are there, however, some alternative functions in C++?
malloc = new. free = delete. New will call a class's constructor, which malloc won't.
Always use new and not malloc.
There is no substitution for realloc, however. You will have to manually allocate more memory and copy over the old.
Originally Posted by Adak
As stated, it's "better" to use new/delete as those are the clean C++ way to do it.
However, the C++ standard allows (essentially) C89/C90 standard C, so you CAN use malloc/realloc/calloc if you really have a good reason (such as, you have 2000 lines of old C code that does EXACTLY what you need, and does it without any known problems - there's no reason to rewrite the memory allocation there to use new/delete).
Note also that mixing [as in, "allocate" with new and free using free(), or allocate with malloc and free with delete] the two forms is very likely to land you into serious trouble.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Malloc is left there for backwards compatibility, so if you are compiling or writing C code, of course you can / should use malloc. But for any C++ project, new/delete is the way to go.
That, I think, is what we want to point out.
You'd do it the same way the STL does.
i.e. Allocate a new array that's bigger than the old one (twice as big is probably a good idea); then copy everything to the new array; then delete the old array...
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
This sounds like a very good reason to use malloc() over new. If I'm working with a primitive type, and I am going to have a use for realloc() then I'll use malloc(). If not, then the only benefit of using new on primitive types is that you can call delete on a NULL, which you can't do with free().
I remember a thread from a while ago (maybe a year or two) where using malloc/realloc for dynamically sizing an array in C++ was discussed. I seem to recall there might have been other reasons given for not using realloc in this way, but I cannot remember them. You might consider searching for that thread to see if there is any more insight.
Edit: http://cboard.cprogramming.com/showthread.php?t=98330 is the one I'm thinking of. Looking through it reminded me, are you trying to use malloc/realloc as a premature optimization, or have you identified a place in your code where new causes a slowdown?
Last edited by Daved; 11-04-2008 at 12:22 PM.
Actually, it is safe to call free() on a null pointer too.
In this case, there is no benefit to using malloc/realloc/free since the next step would be to turn the class into a class template, upon which one would have to use new[] and delete[] anyway in order to accomodate non-POD types.
Then again, it should be possible to continue to use malloc/(realloc?)/free but with placement new and its associated weirdness hidden beneath the stack class template interface, but that may be yet a further step that the OP should not be concerned with at this point.
Also, consider implementing a vector class template, and then using that to implement a stack class template. This would be akin to how std::stack uses an underlying container.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Realloc many times does the same thing. Allocates new size. Copies over old data. Deletes old data.
But in C++, this is even further abstracted by the fact that typically we use std::vector and nor new/delete/new/delete.
I guess you could create a template container and specialize the primitive types to use realloc() and use new/delete for everything else, but I doubt you'd notice much performance benefit from doing it.
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
I got bored after seeing the conversation switching back and forth between senior members. I hope someone brought up the placement new operator at some point.
Example:
Code:myClass *x = new(malloc(sizeof(*x))) myClass;
Yes, but that is REALLY not a good idea except in very special cases.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Agreed 100%. Particularly when considering that there is a golden rule of C++ "Never call a destructor explicitly." And placement new is the only exception to that rule. You have to explicitely call the destructor or else the destructor will not be called upon freeing the block of memory.
And yet you post the code that goes against exactly that rule... Bored? Or just having fun?
