however, in the ms-world in general and using vc++ 6.0 in particular
i wonder if it is "ok" to call delete on such allocated memory?
maybe different heaps are used by malloc/free vs new/delete on some
platforms and implementations on which it would be a disaster to delete
strdup:ed memory. but my question is specific to win2000 and vc++6.0.
thank you,
/tom
Even if it happened to work, why would you want to do it? Follow the
rules, or you're guaranteed to run into trouble down the road even if it
appears to work now.
Any reason you're using strdup() instead of just using std::string?
--
Be seeing you.
The delete of strdup:ed memory is one obvious source of error that I have
caught. I wonder if it in practice is a real source of error.
Other stuff in project where I have observed misuse of the memory is
deleting an array with the scalar delete instead of delete []. However,
this works in VC6 and is not the real cause of the access violations and
memory leaks.
Another one that I've caught was the allocation of a a CComObject on
the stack. Now, this was causing real problems with the application.
However, more sources of memory issues reamins to be resolved...
/Tom
>hi,
For a char* array of length > 0 allocated with malloc, free, delete
and delete[] are equivalent by default under MSVC6, with both debug
and release CRTs (determined by examining source code). Obviously
overriding global operator new/delete, etc. will cause major problems.
Tom
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>> Even if it happened to work, why would you want to do it? Follow the
>> rules, or you're guaranteed to run into trouble down the road even if it
>> appears to work now.
>>
>> Any reason you're using strdup() instead of just using std::string?
>I agree with you. The reason I'm asking is because I've been tossed in
>on an existing project which have several and severe problems with the
>memory management.
Ouch. Been there, done that! I don't envy you. The last time it happened
to me, the best thing to do was to just throw out the code.
Unfortunately that's not always an option, but it sure felt good. :)
>The delete of strdup:ed memory is one obvious source of error that I have
>caught. I wonder if it in practice is a real source of error.
>
>Other stuff in project where I have observed misuse of the memory is
>deleting an array with the scalar delete instead of delete []. However,
>this works in VC6 and is not the real cause of the access violations and
>memory leaks.
Have you tried Boundschecker or a similar product? That should be able
to help you track down this, and much more. You can get a free 14 day
eval copy.
--
Be seeing you.
>> Even if it happened to work, why would you want to do it? Follow the
>> rules, or you're guaranteed to run into trouble down the road even if it
>> appears to work now.
>>
>> Any reason you're using strdup() instead of just using std::string?
>>
>I agree with you. The reason I'm asking is because I've been tossed in
>on an existing project which have several and severe problems with the
>memory management.
>
>The delete of strdup:ed memory is one obvious source of error that I have
>caught. I wonder if it in practice is a real source of error.
>
>Other stuff in project where I have observed misuse of the memory is
>deleting an array with the scalar delete instead of delete []. However,
>this works in VC6 and is not the real cause of the access violations and
>memory leaks.
It will be for types with non-trivial destructors:
#include <iostream>
struct A
{
~A()
{
std::cout << "~A\n";
}
};
int main()
{
A* aptr = new A[10];
delete aptr;
}
That will either crash, or just print ~A once rather than 10 times.
download the standard debugger package
http://www.microsoft.com/whdc/ddk/debugging/
and the enable full pageheap on your application
c:\>gflags -i YourApp.exe +hpa
and then run your application in the debugger.
For memory leaks you can use the UMDH.exe tool from the same package
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Tom" <som...@microsoft.com> wrote in message
news:AoQPb.4622$zm5....@nntpserver.swip.net...