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 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
* 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?
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
* 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?
"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
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
>> 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
"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
"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? ...
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
by: Douglas Peterson |
last post by:
class Allocator
{
public:
virtual void * Alloc(size_t) = 0;
virtual void * Free(void*) = 0;
};
class Object
{
public:
|
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...
|
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
>>...
|
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);...
|
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...
|
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 -...
|
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...
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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....
|
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...
| |