Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

utwo007

malloc or new?

This topic is 6074 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Believe it or not, I actually want to know the answer to this question, so don''t start a flame war! I just want to know what is best for reserving large amounts of data on the heap. Which would be better? char * buffer[50] = new char; --or-- char buffer; buffer = (char *)malloc(sizeof(char)); The keyword new makes a whole lot more sense to me, but I consistently see people opting for malloc(). Why is that? P.S. >> Don''t make fun of my code examples. I''m a newbie programmer and I''m doing this by memory. ---signature--- People get ready. I''m ready to play.

Share this post


Link to post
Share on other sites
Advertisement
Well there are differences between the two.

1. new only works in c++, malloc works in both C/C++.
1b. you do not have to typecast the return of malloc in c btw.

2. new calls malloc to get memory. This causes in new being slower, but it is often neglibible.

3. new call''s the cooresponding constructor for the class if you are constructing a class. This is very useful, since malloc only reserves memory.

Each has its advantage. If you use new for everything your not hurting yourself so don''t worry about using malloc. Personally I started programming with C so i tend to use more of C''s libraries over the STL out of habit. Use whatever feels more comfortable.

- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
quote:
Original post by utwo007
Believe it or not, I actually want to know the answer to this question, so don''t start a flame war!

new is better because it is type safe and can also call constructors. new can also be overloaded (so can malloc though), but new is an operator, so it can be overloaded on a per-class basis which allows you to call it with impunity. You can use _set_new_handler() to specify what happens should memory allocation fail... the list goes on.

That''s not to say that malloc isn''t good; it is. But new''s better.

quote:
The keyword new makes a whole lot more sense to me, but I consistently see people opting for malloc(). Why is that?

Old habits die hard. Many C programmers never learn to use C++ properly or fully. I was told to drop C very early in my programming experience and got right into C++, so I generally resist C methods unless its a necessary tradeoff.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
That''s not to say that malloc isn''t good; it is. But new''s better.



I have to disagree with you Oluseyi. I pointed out differences between the two, and malloc is always faster then new. Also on some platforms (Cell Phones, Old Consoles) you can not program games in C++, C or ASM is the only option.

We shouldn''t be trying to steer him towards OOP C++. Whatever''s best for the job is always the best sollution. I''ve become a huge fan of C++ lately after working on my past 2 games using C, but i realize both languages have their advantages. Same with OOP, OOP is great, but its not always the best sollution to the problem, or the game. My goal of my game is my game, and not a programming philosophy.



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
I use new almost exclusively, but have had occasion to use malloc. Just remember, if you use new, you have to match with delete (not free). And you must match malloc with free, not delete.

The real issue in memory allocation is its use. If you are going to allocate and free a lot of objects/memory blocks, you need to think about memory fragmentation. Fragmentation happens when memory gets ''sliced up'' into pieces. If some (not all) of the pieces are freed, you get ''islands'' of allocated memory in the midst of unallocated memory. Then, when you want another large block, it might not be able to use any of the ones you freed because they are not big enough (remember, you get a contiguous set of memory when you ask for a block). The result is that it appears as if more and more memory is being used, but in reality it is just being fragmented.

So, you need to take that into consideration if you are going to do a lot of memory allocation and deallocation. If so, you might want to consider writing or using specialty memory allocation methods. For example, if you were going to allocate and deallocate a large number of fixed size structures, you might write a ''memory pool'' class that creates a large pool of memory, and doles out fixed size pieces on request. It would have to track those pieces, and handle deallocation, etc. In such a class, you might use ''malloc'' to allocate the pools.

Sorry for the long aside, but it is something to consider later on. You may not need it now, but someday in the future

Share this post


Link to post
Share on other sites
quote:
Original post by OldGuy
I use new almost exclusively, but have had occasion to use malloc. Just remember, if you use new, you have to match with delete (not free). And you must match malloc with free, not delete.


Actually that''s not always the case. Because delete just calls free, you can mix and match, as long as your not dealing with classes. If you call new on a class, you must call it on delete, free will not work. If you were to call new using the syntax:
  
char *foo = new char[50];

and called free on foo, it would be valid and work. Of course that''s making your code more unreadible so you shouldn''t do it
quote:

For example, if you were going to allocate and deallocate a large number of fixed size structures, you might write a ''memory pool'' class that creates a large pool of memory, and doles out fixed size pieces on request. It would have to track those pieces, and handle deallocation, etc. In such a class, you might use ''malloc'' to allocate the pools.


Funny you mention that, I just wrote one of those two days ago . Not terribly usefull because once you define the size of the node, it can''t be modified, but who knows it may come in handy in the future. I imagine using a memory manager that some company built would be a much better sollution, since they have guys who have spent years studying garbage collection which I can only understand the raw basics.



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites
quote:
Original post by BaShildy
new calls malloc to get memory.


quote:

Because delete just calls free ...


Are you absolutely sure about that? IIRC, the C++ standard does not guarantee that this is the case.

Share this post


Link to post
Share on other sites
The standard doesn''t garuantee it. It particular cases it works, but not is not portable, and is generally considered a dumb thing to do. Delete implementations will often store stuff before the pointer they return (in addition to what malloc stores).

If you''re using a C++ compiler to write C++ code, I can''t think of a reason not to use new over malloc. There is little performance difference between the two - both are written to handle the general case and target mid-sized allocations. If you need to new/malloc small objects and want the allocations efficent in both space and time you need your own custom allocator (and a memory pool of some-sort).

Any performance reason to choose malloc over new, leads you to choose the system-specific memory allocators (AllocHeap, IIRC, on Win32) to retrieve 4k pages.

50 (or 1) chars is rather small

Share this post


Link to post
Share on other sites
Thanks for the replies!

I think I got a good feeling for both sides of the coin, so you can let this thread die if you want. I look forward to the day when I can give as much to these forums as I take. Hehe.

---signature---
People get ready.
I''m ready to play.

Share this post


Link to post
Share on other sites
What i was saying earlier was not guaurenteed by the standard so you shouldn''t do it. Magmai Kai Holmlor is right in that it will lead to problems when porting. Gotta side with Magmai on this one, if your that worried about performance, its better to go with system-specific memory allocators.

You can test the free/delete new/malloc thing on your own and it''ll probably work. But things that probably work end up biting your ass months into a project

- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!