PocketMatrix

<yoda voice>If you're app is allocating memory with enough frequency that you'd notice any difference between the two methods, you've got design problems that you should address first. </yoda voice>

Both operator new and malloc call HeapAlloc underneath and that is where the real work is. From a design standpoint if you're writing a C++ app where you're already using operator new to allocate memory for classes, you're better off using it to allocate buffers as well. This reduces the chance that you'll get confused in calling operator delete[] vs. free() when you go to destroy the buffer. It also makes it easier to override the memory allocator and track memory leaks and other sort of diagnostics if your app allocates/frees memory through a single point of code.

ok so what you guys said is basically(except I didnt talk or know about the heap alloc stuff digby explained) what I was thinking, but heres a question I got in response:

"And tell me how you deal with a malloc failure within a new call?"

I dont really know since I dont ever use malloc. I assume new handels this by itself and is one of the advantages. Anyone have any ideas?

There are a few different functions new calls when it fails. You can set these to your custom handlers if you wish to handle those types of errors. Otherwise, an exception is thrown.

Well everything has its place but gotos and globals are definitely not a way to proceeed when dealing with reasonable system.
Personally, I think C++ is the way to go when dealing with a typical user space application but the reality is that a lot of people are used to the "old" ways of doing things and are highly resistant to any change :-)

I still remember the days when everything was written in ASM not because performance reasons but rather due to memory limitations.
StephenC is right when it comes to use of new and malloc - as soon as the game loop is rolling, it is unwise to use these functions on a continuous basis on a PocketPC device.

On the other hand, while I can understand lack of threading , replacing loops with state driven code seems insane ...