Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I'm trying to code an overloaded version of the operator 'new' that handles errors by itself (writing an error message for a few seconds then quitting). Surely some of the knowledgeable posters here have solved this common problem before, so could you please post your solution? A lot of people have that problem and having a "standard" solution would help a lot, I think. No need to reinvent the wheel...

what kind of error are you trying to handle on new()?
My suggestion is to check the void* returned by new (NULL? -> Malloc Error) outside of the new body code.
Other semantic errors shall be checked on the constructor (after you got a successful new() *void return).

what kind of error are you trying to handle on new()?
My suggestion is to check the void* returned by new (NULL? -> Malloc Error) outside of the new body code.
Other semantic errors shall be checked on the constructor (after you got a successful new() *void return).

What I hoped to do was to handle memory allocation problems (ie. not enough memory) directly in the overloaded new operator. That way, I'd be 100% sure that every memory allocation was checked and I wouldn't have to bloat my code with error-checking all over the place. With some more research, however, it seems it simply cannot be done in Brew (if only because you can't quit synchronously -- which I think is pretty stupid -- and because you can't use exceptions). So I had to resort to using macros to hide the bloat a bit... but otherwise it's still checking all over the place for allocation error and skipping code after one.

What I hoped to do was to handle memory allocation problems (ie. not enough memory) directly in the overloaded new operator. That way, I'd be 100% sure that every memory allocation was checked and I wouldn't have to bloat my code with error-checking all over the place. With some more research, however, it seems it simply cannot be done in Brew (if only because you can't quit synchronously -- which I think is pretty stupid -- and because you can't use exceptions). So I had to resort to using macros to hide the bloat a bit... but otherwise it's still checking all over the place for allocation error and skipping code after one.

I use the following strategies for my brew application.
1. Use our custom memory management unit. You can find many allocator code over the net along with source code, which can be used without much licensing problem.
2. We have overloaded new and delete operators.
3. We use couple of macros, which will call the new, and do log memory allocation report. This logging can be turned off easily by using another macro.
ruben

I use the following strategies for my brew application.
1. Use our custom memory management unit. You can find many allocator code over the net along with source code, which can be used without much licensing problem.
2. We have overloaded new and delete operators.
3. We use couple of macros, which will call the new, and do log memory allocation report. This logging can be turned off easily by using another macro.
ruben