continued new and malloc

[SpS]

Well, you didn't specify how it didn't work, but on one of my compilers, there's a run-time assertion if the allocation size exceeds a certain limit, and 4294967295 is beyond that limit. Such an assertion throws up a dialog box and aborts the program, which could look like an uncaught exception. You're probably seeing something like that, and because the assertion stops the program before malloc returns, no about of testing the return value will save you.

yaa this is what was happening...i searched net for run time assertion...and found a macro ndebug

and i used it like this

#ifndef NDEBUG
const bool ndebug=false;
#else
const bool ndebug=true;
#endif

but still it gives the same dialog box....is there any way to switch it off

and 1 more thing...Is there any limit to no of posts in a thread..because previous thread(new and malloc) was closed after 15 replies

[Narue]

>but still it gives the same dialog box....is there any way to switch it off
The way it's supposed to work is that you define NDEBUG and it disables debugging assertions. Will it work in this case? I doubt it, because if there is a hardcoded limit in your memory manager that doesn't allow the full range of size_t, disabling assertions will only cause the program to mysteriously crash instead of give you a friendly error message. I don't imagine that the implementation would allow you to do it.

Okay, that explanation is really a cop out. Your standard libraries (of which malloc is a part) are probably not source code. They're more likely to already be compiled to object code so that you don't have to wait for the entire standard library to be compiled when you run a simple program. NDEBUG only affects source code because it's a function of the preprocessor. Object code isn't affected, so the assertion technically can't be removed unless you replace malloc with your own implementation.

If you have a source reference for your compiler (Visual C++ 6 has the option of placing source code files for the standard library in a CRT folder, but I haven't tried it with newer versions yet) then you can look up malloc and see where the assertion is.

>Is there any limit to no of posts in a thread..because previous thread(new and malloc) was closed after 15 replies
No, there's no limit that we're likely to reach. But I'll close a thread if it looks like it might errupt into a flame war.

[SpS]

NDEBUG only affects source code because it's a function of the preprocessor. Object code isn't affected, so the assertion technically can't be removed unless you replace malloc with your own implementation.

Actualy nice