 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
RenjithMohan
Guest
|
 Posted: Sun Sep 24, 2006 10:05 pm Post subject: delete operator again |
 |
|
I have a seemingly simplistic question. I would like to know why the
array delete operator is not automatically invoked.
We all know that the compiler has to do some bookkeeping in order to
free the entire block of memory. There was a dispute in the standard
whether the size of the array must be specified in the [] syntax.
Finally it was decided that since it is error prone, it should be
avoided.
If that is the case why cant the syntax be further simplified and
automatically invoke the correct form of the delete operator?.
Like if for example I have
class A;
A* pArr = new A[10];
and I say
delete pArr ; //automatically invoke operator delete [] ;
It should automatically invoke the array delete operator since the
nature of the type(whether it is an array or a simple pointer ) can be
determined from the declaration.
This way we can have just one form of the delete syntax eventhough
there are multiple forms of the operator.
This could be like overloading processor finding the correct function,
but only simpler.
You could of course cook up more complicated scenarios like array of
polymorphic types etc. But the point remains the same . It is just a
race between the normal form and array form of delete of the type.
Since the nature of the type is always given why cant the compiler
guess to call the correct form ?.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Frederick Gotham
Guest
|
| Posted: Mon Sep 25, 2006 12:14 am Post subject: Re: delete operator again |
|
|
RenjithMohan posted:
| Quote: | Like if for example I have
class A;
A* pArr = new A[10];
and I say
delete pArr ; //automatically invoke operator delete [] ;
It should automatically invoke the array delete operator since the
nature of the type(whether it is an array or a simple pointer ) can be
determined from the declaration.
|
No, it can't. The following two objects have exactly the same type:
int *p1 = new int;
int *p2 = new int[5];
| Quote: | This way we can have just one form of the delete syntax eventhough
there are multiple forms of the operator.
This could be like overloading processor finding the correct function,
but only simpler.
|
int main()
{
int *p = new int;
delete p;
p = new int[5];
delete [] p;
}
| Quote: | You could of course cook up more complicated scenarios like array of
polymorphic types etc. But the point remains the same . It is just a
race between the normal form and array form of delete of the type.
Since the nature of the type is always given why cant the compiler
guess to call the correct form ?
|
Because the nature of the type is _not_ always given. You'd need something
like:
template<class T>
struct DynamPtr {
T *p;
enum AllocType { sole, array } type;
};
template<class T>
void Delete(DynamPtr<T> const &dp)
{
DynamPtr<T>::sole == dp.type ? delete dp.p : delete [] dp.p;
}
int main()
{
DynamPtr<int> p;
p.p = new int; p.type = DynamPtr<int>::sole;
Delete(p);
p.p = new int[5]; p.type = DynamPtr<int>::array;
Delete(p);
}
--
Frederick Gotham
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Maxim Yegorushkin
Guest
|
| Posted: Mon Sep 25, 2006 12:27 am Post subject: Re: delete operator again |
|
|
RenjithMohan wrote:
| Quote: | I have a seemingly simplistic question. I would like to know why the
array delete operator is not automatically invoked.
We all know that the compiler has to do some bookkeeping in order to
free the entire block of memory.
|
Not the compiler. The bookkeeping is done by the allocator, and which
one is used may not be known until run-time. One example is hoard
allocator, which can replace the standard one for your platform at
application load time.
Compiler only has to know how many destructors to invoke when delete is
invoked. For delete this number is always one, no need to store the
number somewhere, for delete[] this number is a variable and has to be
stored somewhere, usually along with the array.
This might have been a part of the reason why there are two forms of
delete. Storing the number of elements when only one object is
allocated might have been deemed unnecessary.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Andrew Koenig
Guest
|
| Posted: Tue Sep 26, 2006 7:48 pm Post subject: Re: delete operator again |
|
|
"RenjithMohan" <renjithmohan (AT) hotmail (DOT) com> wrote in message
news:1159115530.906259.219530 (AT) m7g2000cwm (DOT) googlegroups.com...
| Quote: | I have a seemingly simplistic question. I would like to know why the
array delete operator is not automatically invoked.
|
At the time we implemented the feature, we felt it necessary to allow an
implementation to accept:
int* p = new int;
free(p);
because we expected that some people would write library routines that would
return dynamically allocated memory, and users of those routines would not
always know whether new or malloc was the allocation mechanism.
This desire for compatibility meant that it was impossible to store the
number of elements in an array as part of the array itself. Instead, we
arranged for new to store array sizes in a separate data structure.
However, the overhead (both time and space) associated with that data
structure argued against using it for single elements. Hence a compromise:
Use the data structure for arrays but not scalars.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
