delete POD array - on which platforms does it not work?

[Eberhard Schefold]

Re: delete POD array - on which platforms does it not work?

Martin T. wrote:

>Are you sure these don't mess up anything in VC8?

>
Yes, 100% sure.
>

>Anyway this question is braindead. You use delete[]
>for arrays and never free() with operator new.

>
This is question is quite valid. Indeed it becomes more valid with
answers such as this.

There are so many morons who are 100% sure that it's safe to pour
lighter fluid into a burning barbecue fire -- /although/ they've been
told otherwise. "Sissies", they say. They do it dozens of times, and
nothing bad happens. Then they'll do it once more and get a third-degree
burn, and some bystanders too.

I just don't get into the mindset of these people.

[Bo Persson]

Re: delete POD array - on which platforms does it not work?

Martin T. wrote:

Kai-Uwe Bux wrote:

>Martin T. wrote:
>>
>....

>>or does anyone know of a platform where it
>>will break for PODs?

>>
>It is undefined behavior on any platform. That makes it somewhat
>hard to produce a test case.
>>

>
Well, I am sure the standard says something about the outcome of a
delete[] for PODs ... ?
So, if the outcome of the free(new char[n]) is the same, one could
say it does not break in this specific implementation, right?
>
>

But you would have to have some explicit guarantees from the
implementor. Like Kai-Uwe says, we can never test for undefined
behavior, because it doesn't have to be consistent.


Bo Persson

[Bo Persson]

Re: delete POD array - on which platforms does it not work?

Triple-DES wrote:

On 2 Apr, 10:47, Juha Nieminen <nos...@thanks. invalidwrote:

>Martin T. wrote:

>>Krice wrote:
>>>On 2 huhti, 08:30, "Martin T." <0xCDCDC...@gmx .atwrote:
>>>>delete p; // will work on VC8
>>>>free(p); // will also work on VC8

>>

>>>Are you sure these don't mess up anything in VC8?

>>

>>Yes, 100% sure.

>>
>How can you be so sure? Are you sure that they don't, for example,
>leak memory? Did you use some kind of profiler to check this or
>something?

>
The _CrtDumpMemoryL eaks() function can be used when running under
the debugger. I too tried this, and was unable to produce a memory
leak on VC8.

How many times did you run the test, and under what conditions?

What if it only fails first Wednesday after a full moon on leap years,
and only if an important customer is watching. That's usually when
Undefined Behavior goes bad.

>
Without further evidence, I wouldn't go as far as saying that this
is 100% safe on VC8, but it would seem that the most trivial cases
are handled gracefully.
>

It actually does work, but just by chance. Usually new[] has to store
a count, so the system can later know how many times delete[] has to
call the destructor for the objects in the array. As a space
optimization, the count is not stored for objects without a
destructor, so by pure chance a char[10] object has the same layout as
any other 10 byte memory block.

Do you want to rely on this??


Bo Persson

[Default User]

Re: delete POD array - on which platforms does it not work?

Martin T. wrote:

Hi all!
>
char* p = new char[n]; // POD!
...
delete[] p; // std compliant
delete p; // will work on VC8
free(p); // will also work on VC8

How do you konw it works?




Brian

[stan]

Re: delete POD array - on which platforms does it not work?

Triple-DES wrote:

On 2 Apr, 10:47, Juha Nieminen <nos...@thanks. invalidwrote:

>Martin T. wrote:

Krice wrote:
>On 2 huhti, 08:30, "Martin T." <0xCDCDC...@gmx .atwrote:
>>delete p;   // will work on VC8
>>free(p);    // will also work on VC8

>>

>Are you sure these don't mess up anything in VC8?

>>

Yes, 100% sure.

>>
>  How can you be so sure? Are you sure that they don't, for example,
>leak memory? Did you use some kind of profiler to check this or something?

>
The _CrtDumpMemoryL eaks() function can be used when running under the
debugger. I too tried this, and was unable to produce a memory leak on
VC8.
>
Without further evidence, I wouldn't go as far as saying that this is
100% safe on VC8, but it would seem that the most trivial cases are
handled gracefully.

This certainly seems slightly more comfortable than "100% sure". That
level of confidence always sets off warning flags "100%" of the time :)

To be honest I'm not convinced that even this claim stands up very well.
How does optimizing, debugging, ... etc other environment changes impact
this outcome? I'm not asking for anyone to actually test this. I'm
personally willing to take the standard at it's word and consider it
undefined. From the first time I heard about it I've been adverse to
doing anything that might cause demons to fly out of my nose. My
children have moved back in with me and I'm already pressed for space.

I can't actually imagine why this question would ever come up. I can't
see any benefit from skirting the rules. Am I missing some possible
valid reason to investigate this?

[Triple-DES]

Re: delete POD array - on which platforms does it not work?

On 3 Apr, 04:53, stan <smo...@exis.ne twrote:

Triple-DES wrote:

[snip]

Without further evidence, I wouldn't go as far as saying that this is
100% safe on VC8, but it would seem that the most trivial cases are
handled gracefully.

>
This certainly seems slightly more comfortable than "100% sure". That
level of confidence always sets off warning flags "100%" of the time :)

Yes, and I guess I should moderate myself even further. What I should
have written was something along the lines of: Under certain
conditions, it is possible to write code in such a way that mixing
new[] / delete will not leak memory using VC8.

To be honest I'm not convinced that even this claim stands up very well.
How does optimizing, debugging, ... etc other environment changes impact
this outcome? I'm not asking for anyone to actually test this. I'm
personally willing to take the standard at it's word and consider it
undefined. From the first time I heard about it I've been adverse to
doing anything that might cause demons to fly out of my nose. My
children have moved back in with me and I'm already pressed for space.
>
I can't actually imagine why this question would ever come up. I can't
see any benefit from skirting the rules. Am I missing some possible
valid reason to investigate this?

My own reason for investigating this was that I wanted to convince the
OP that it was unsafe. Unfortunately, I haven't had any luck so far :)

DP

[Krice]

Re: delete POD array - on which platforms does it not work?

On 2 huhti, 15:41, "Martin T." <0xCDCDC...@gmx .atwrote:

The current version of the VC++ free edition is 2008

I'm using older version.

Care to explain how it breaks there

Heap corruption.

[Martin T.]

Re: delete POD array - on which platforms does it not work?

Triple-DES wrote:

On 3 Apr, 04:53, stan <smo...@exis.ne twrote:

>Triple-DES wrote:

[snip]

>>Without further evidence, I wouldn't go as far as saying that this is
>>100% safe on VC8, but it would seem that the most trivial cases are
>>handled gracefully.

>This certainly seems slightly more comfortable than "100% sure". That
>level of confidence always sets off warning flags "100%" of the time :)

>
Yes, and I guess I should moderate myself even further. What I should
have written was something along the lines of: Under certain
conditions, it is possible to write code in such a way that mixing
new[] / delete will not leak memory using VC8.
>

>To be honest I'm not convinced that even this claim stands up very well.
>How does optimizing, debugging, ... etc other environment changes impact
>this outcome? I'm not asking for anyone to actually test this. I'm
>personally willing to take the standard at it's word and consider it
>undefined. From the first time I heard about it I've been adverse to
>doing anything that might cause demons to fly out of my nose. My
>children have moved back in with me and I'm already pressed for space.
>>
>I can't actually imagine why this question would ever come up. I can't
>see any benefit from skirting the rules. Am I missing some possible
>valid reason to investigate this?

>
My own reason for investigating this was that I wanted to convince the
OP that it was unsafe. Unfortunately, I haven't had any luck so far :)
>

No convincing was needed, actually. :-)
I'm not going to do this, but having a clue as to *how* evil something
is can never hurt. Not to repeat it, but to know how urgent it is to fix
it should you encounter it.

thanks for your insights,
br,
Martin

[Paavo Helde]

Re: delete POD array - on which platforms does it not work?

"Martin T." <0xCDCDCDCD@gmx .atwrote in news:fsvuau$vct $1
@registered.mot zarella.org:

Have you ever compared the performance of std::vector<int >(n) vs. new
int[n] (in a release build, but without optimization?)
My results are somewhere factor 5 on VC8 (VS2005) in favor of new[].
I agree though - I do not use new[] except in the classes that hide it
from me.

Well, without optimization you don't get fast code, do you? As a side
note, I have sometimes needed to switch on debugging support for Release
builds, but I have never had a need to switch off optimization there. So
what is your (company's?) excuse for doing that?

Also note that beginning from VS2005 MS has had the checked iterators
idea which is on by default even in the Release builds. They claim the
cost is small, but it cannot be zero. So for fair comparisons you have to
switch this one off also be #define SECURE_SCL 0 in the appropriate place
of the code. Though this won't count for factor 5 you mentioned...

Also - technically the (2003) std does not guarantee that the memory of
std::vector is allocated contiguously, right?

De facto all std::vectors are continuous, now and in the future. There
are many more real problems to worry about than this one.

Regards
Paavo