473,325 Members | 2,785 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

delete[] of POD

int *p;
p = new int[10];

void *q = (void*)p;
delete[] q;

Is this valid if p is guaranteed to be a POD? (don't ask why... there is a
reason I need this. Clearly I will create p in function, use p in another
function that know what type p is and delete p in a function that for
simplicity won't know what p is)

Reading the MSDN it seems that

"The global operator delete function, if declared, takes a single argument
of type void *, which contains a pointer to the object to deallocate. The
return type is void (operator delete cannot return a value). Two forms exist
for class-member operator delete functions:"

so it should be ok But this is the MSDN guide :-)

--- bye
Oct 25 '05 #1
10 2215
MaxMax wrote:
int *p;
p = new int[10];

void *q = (void*)p;
delete[] q;

Is this valid if p is guaranteed to be a POD? (don't ask why... there is a
reason I need this. Clearly I will create p in function, use p in another
function that know what type p is and delete p in a function that for
simplicity won't know what p is)

Reading the MSDN it seems that

"The global operator delete function, if declared, takes a single argument
of type void *, which contains a pointer to the object to deallocate. The
return type is void (operator delete cannot return a value). Two forms exist
for class-member operator delete functions:"

so it should be ok But this is the MSDN guide :-)

--- bye


operator delete[] has a void* as parameter in the standard, so you're fine.

--
Regards,

Ferdi Smit (M.Sc.)
Email: Fe********@cwi.nl
Room: C0.07 Phone: 4229
INS3 Visualization and 3D Interfaces
CWI Amsterdam, The Netherlands
Oct 25 '05 #2
* Ferdi Smit:
MaxMax wrote:
int *p;
p = new int[10];

void *q = (void*)p;
delete[] q;

Is this valid if p is guaranteed to be a POD? (don't ask why... there is a
reason I need this. Clearly I will create p in function, use p in another
function that know what type p is and delete p in a function that for
simplicity won't know what p is)

Reading the MSDN it seems that

"The global operator delete function, if declared, takes a single argument
of type void *, which contains a pointer to the object to deallocate. The
return type is void (operator delete cannot return a value). Two forms exist
for class-member operator delete functions:"

so it should be ok But this is the MSDN guide :-)


operator delete[] has a void* as parameter in the standard, so you're fine.


Sorry, that's an incorrect inference.

The standard defines this as Undefined Behavior, and in case somebody should
not see that implication, it states that explicitly for void* in note 73:

[context: delete array] "... an object cannot be deleted using a pointer of
type void* because ...".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Oct 25 '05 #3
Alf P. Steinbach wrote:

operator delete[] has a void* as parameter in the standard, so you're fine.

Sorry, that's an incorrect inference.

The standard defines this as Undefined Behavior, and in case somebody should
not see that implication, it states that explicitly for void* in note 73:

[context: delete array] "... an object cannot be deleted using a pointer of
type void* because ...".


I think that refers to an array of void which is impossible (size 0, a
similar reason to why an (empty) instantiated object has size at least
1); and thus you can't delete[] a true void*. But in max's case the
underlying data is in fact of another type (int*). The operator delete[]
takes a void*, so whatever pointer you pass it, it will be cast to a
void* first before the operator runs anyway.

--
Regards,

Ferdi Smit (M.Sc.)
Email: Fe********@cwi.nl
Room: C0.07 Phone: 4229
INS3 Visualization and 3D Interfaces
CWI Amsterdam, The Netherlands
Oct 25 '05 #4
* Ferdi Smit:
Alf P. Steinbach wrote:

operator delete[] has a void* as parameter in the standard, so you're fine.

Sorry, that's an incorrect inference.

The standard defines this as Undefined Behavior, and in case somebody should
not see that implication, it states that explicitly for void* in note 73:

[context: delete array] "... an object cannot be deleted using a pointer of
type void* because ...".


I think that refers to an array of void which is impossible (size 0, a
similar reason to why an (empty) instantiated object has size at least
1); and thus you can't delete[] a true void*.


There is no such thing as a "true void*" ;-) Except the nullpointer of void*
type, in which case you have no object to be deleted.

But in max's case the
underlying data is in fact of another type (int*). The operator delete[]
takes a void*, so whatever pointer you pass it, it will be cast to a
void* first before the operator runs anyway.


That doesn't matter. The compiler can't infer the size or type of the array
elements statically. The standard couldn't be more clear on this issue: it's
Undefined Behavior.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Oct 25 '05 #5
"Ferdi Smit" <Fe********@cwi.nl> wrote in message news:Io********@cwi.nl

I think that refers to an array of void which is impossible (size 0, a
similar reason to why an (empty) instantiated object has size at least
1); and thus you can't delete[] a true void*. But in max's case the
underlying data is in fact of another type (int*). The operator
delete[] takes a void*, so whatever pointer you pass it, it will be
cast to a void* first before the operator runs anyway.


You need to distinguish between delete[] and operator delete[], which are
easily confused.

delete[] does two things:

1. it calls the destructor for the objects in the array, and then
2. it calls operator delete[] to deallocate memory.

Once the destructor has run, the object no longer exists and hence it is not
surprising that operator delete[] is given a void* pointer. To see the
effect of using delete[] with a void* pointer, run the following:

#include <iostream>

class Test
{
public:
~Test()
{
std::cout << "Destructor called\n";
}
};

int main()
{
Test *ptest = new Test[4];
void * ptr = (void*)ptest;
delete [] ptr;
return 0;
}

The result of this is undefined, but I predict with reasonable confidence
that the destructor will not be called. If, by contrast, you call delete[]
on ptest, then the destructor will be called.

Of course, if your array members don't have destructors, then you may get
away with calling delete[] on a void* pointer. There is no guarantee,
however. The behaviour is undefined.

--
John Carson

Oct 25 '05 #6
John Carson wrote:
You need to distinguish between delete[] and operator delete[], which are
easily confused.

delete[] does two things:

1. it calls the destructor for the objects in the array, and then
2. it calls operator delete[] to deallocate memory.

Once the destructor has run, the object no longer exists and hence it is
not
surprising that operator delete[] is given a void* pointer. To see the
effect of using delete[] with a void* pointer, run the following:

#include <iostream>

class Test
{
public:
~Test()
{
std::cout << "Destructor called\n";
}
};

int main()
{
Test *ptest = new Test[4];
void * ptr = (void*)ptest;
delete [] ptr;
return 0;
}

The result of this is undefined, but I predict with reasonable confidence
that the destructor will not be called. If, by contrast, you call delete[]
on ptest, then the destructor will be called.

Of course, if your array members don't have destructors, then you may get
away with calling delete[] on a void* pointer. There is no guarantee,
however. The behaviour is undefined.


Ah, alright. Then this time I stand corrected :) (arrays are evil anyway :P)

--
Regards,

Ferdi Smit (M.Sc.)
Email: Fe********@cwi.nl
Room: C0.07 Phone: 4229
INS3 Visualization and 3D Interfaces
CWI Amsterdam, The Netherlands
Oct 25 '05 #7
>> Of course, if your array members don't have destructors, then you may get
away with calling delete[] on a void* pointer. There is no guarantee,
however. The behaviour is undefined.

So, if I know I'm working with a POD, can I directly use the operator
delete? POD don't have destructors.

--- bye
Oct 29 '05 #8
"MaxMax" <no**@none.com> wrote in message
news:n2********************@twister2.libero.it...
: >> Of course, if your array members don't have destructors, then you
may get
: >> away with calling delete[] on a void* pointer. There is no
guarantee,
: >> however. The behaviour is undefined.
: So, if I know I'm working with a POD, can I directly use the
operator
: delete? POD don't have destructors.

Not if you want your code to be portable and standards-compliant.

Let me restate what was written above about this being undefined
behavior:
you can do it for a POD, and it is even likely to work as you expect
on
your platform/compiler. However, code that uses this trick will not
be portable, and will behave unexpectedly on some other platform,
or when you port your code to a new version of your compiler.

In other words: don't do it.
Allocated memory always must be disposed in a way that strictly
matches the allocation method.

--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact
form
Brainbench MVP for C++ <> http://www.brainbench.com
Oct 29 '05 #9
"Ivan Vecerina" <IN*****************@ivan.vecerina.com> wrote in message
news:dj**********@news.hispeed.ch...
"MaxMax" <no**@none.com> wrote in message
news:n2********************@twister2.libero.it...
: >> Of course, if your array members don't have destructors, then you
may get
: >> away with calling delete[] on a void* pointer. There is no
guarantee,
: >> however. The behaviour is undefined.
: So, if I know I'm working with a POD, can I directly use the
operator
: delete? POD don't have destructors.

Not if you want your code to be portable and standards-compliant.

Let me restate what was written above about this being undefined
behavior:
you can do it for a POD, and it is even likely to work as you expect
on
your platform/compiler. However, code that uses this trick will not
be portable, and will behave unexpectedly on some other platform,
or when you port your code to a new version of your compiler.

In other words: don't do it.
Allocated memory always must be disposed in a way that strictly
matches the allocation method.


Seeing how this is POD, couldn't you just call
delete q;
as the destructors don't need to be called?

OP question:
int *p;
p = new int[10];

void *q = (void*)p;
delete[] q;

Is this valid if p is guaranteed to be a POD? ...
Oct 31 '05 #10
Jim Langston wrote:
Seeing how this is POD, couldn't you just call
delete q;
as the destructors don't need to be called?
The standard makes no such exception for POD types.

OP question:
int *p;
p = new int[10];

void *q = (void*)p;
delete[] q;

Is this valid if p is guaranteed to be a POD? ...


It's never valid. You must pass delete[] the exact same
type and value you got from new [].

The only time you can pass something to delete that's a
different type than what was new is for the single object
case where you have a base class pointer with a derived
destructor. Even then you can't use void*. It has to
be a base class, not any pointer you converted.
Nov 1 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Dave | last post by:
Hello all, In the code below, I see the following output: base::operator new(size_t, int) base::base() base::~base() base::operator delete(void *) In the case of an exception being thrown...
1
by: Nimmi Srivastav | last post by:
There's a rather nondescript book called "Using Borland C++" by Lee and Mark Atkinson (Que Corporation) which presents an excellent discussion of overloaded new and delete operators. In fact there...
3
by: Nimmi Srivastav | last post by:
There's a rather nondescript book called "Using Borland C++" by Lee and Mark Atkinson (Que Corporation) which presents an excellent discussion of overloaded new and delete operators. I am...
1
by: Douglas Peterson | last post by:
class Allocator { public: virtual void * Alloc(size_t) = 0; virtual void * Free(void*) = 0; }; class Object { public:
2
by: Dave | last post by:
Hello all, I'd like to find a source on the web that discusses, in a comprehensive manner and in one place, everything about new / delete. It should include overloading operator new, the new...
3
by: silver360 | last post by:
Hello, I'm trying to create a basic Heap manager and i have some question about new/delete overloading. The following code give me this output : >> $./heap >> registered : 0x804d098 >>...
9
by: rohits123 | last post by:
I have an overload delete operator as below ////////////////////////////////// void operator delete(void* mem,int head_type) { mmHead local_Head = CPRMemory::GetMemoryHead(head_type);...
10
by: jeffjohnson_alpha | last post by:
We all know that a new-expression, foo* a = new foo() ; allocates memory for a single foo then calls foo::foo(). And we know that void* p = ::operator new(sizeof(foo)) ; allocates a...
15
by: LuB | last post by:
I am constantly creating and destroying a singular object used within a class I wrote. To save a bit of time, I am considering using 'placement new'. I guess we could also debate this decision -...
29
by: =?Utf-8?B?R2Vvcmdl?= | last post by:
Hello everyone, I remembered delete is implemented through operator overloading, but I am not quite clear. Could anyone recommend some links about how delete is implemented so that I can...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.