In article qtu@symiserver.symantec.com, Patrick Hoonhout <phoonhout@symantec.com> writes:
>
>>|> If so, then what is the purpose of the following paragraph from 5.3.4?  (I
>>|> can't make sense of it in any case.)
>>|>
>>|>   The way the object was allocated determines how it is freed:  if it is
>>|> allocated by ::new, then it is freed by ::delete, and if it is an array,
>>|> it is freed by delete[] or ::delete[] as appropriate.
>>|>
>>|> What does it mean and is it a restriction on programs or implementations?
>>|>
>>
>
>It's pointing out that an array of class objects are deleted with the
>::operator delete() and not T::operator delete(). An array of class
>objects are allocated with ::operator new(), not T::operator new(), even
>if T::operator new() is supplied.

Your comments reflect what the ARM says, but not the draft C++ standard.

The C++ Committee voted (in 1991, I believe) to add operator new[]
and operator delete[] to the language to allow user-specified
allocation and deallocation for arrays (including class-specific
operator new[] and operator delete[]).


---
Steve Clamage, stephen.clamage@eng.sun.com

>|> If so, then what is the purpose of the following paragraph from 5.3.4?  (I
>|> can't make sense of it in any case.)
>|>
>|>   The way the object was allocated determines how it is freed:  if it is
>|> allocated by ::new, then it is freed by ::delete, and if it is an array,
>|> it is freed by delete[] or ::delete[] as appropriate.
>|>
>|> What does it mean and is it a restriction on programs or implementations?
>|>
>

It's pointing out that an array of class objects are deleted with the
::operator delete() and not T::operator delete(). An array of class
objects are allocated with ::operator new(), not T::operator new(), even
if T::operator new() is supplied.

Patrick Hoonhout
Symantec C++ tech Support

In article <sdouglass-1205951310530001@193.131.176.202>, sdouglass@armltd.co.uk (scott douglass) writes:
|> In the ARM (5.3.3) if class T has a member 'void* T::operator new(size_t)', then
|>    'new T' will allocate using 'T::operator new(size_t)' and
|>    '::new T' will allocate using the global '::operator new(size_t)'.
|> 'delete e' and '::delete e' are similar.
|>
|> In the draft std this distinction seems to have been removed although the
|> '::new' syntax is still allowed.  Are 'new T' and '::new T' now
|> equivalent?

I seriously doubt it.  I suspect that somewhere there is a blanket statement
that operator functions are looked up and resolved the usual way.  (Actually,
I suppose the simple, master description of name lookup and resolution must
be held to apply unless otherwise noted).

This means that the specific rule mentioned above is simply redundant.

|> If so, then what is the purpose of the following paragraph from 5.3.4?  (I
|> can't make sense of it in any case.)
|>
|>   The way the object was allocated determines how it is freed:  if it is
|> allocated by ::new, then it is freed by ::delete, and if it is an array,
|> it is freed by delete[] or ::delete[] as appropriate.
|>
|> What does it mean and is it a restriction on programs or implementations?
|>

Ack, you're right, that is ambiguous.

--
swf@elsegundoca.attgis.com  sarima@netcom.com

The peace of God be with you.

In the ARM (5.3.3) if class T has a member 'void* T::operator new(size_t)', then
   'new T' will allocate using 'T::operator new(size_t)' and
   '::new T' will allocate using the global '::operator new(size_t)'.
'delete e' and '::delete e' are similar.

In the draft std this distinction seems to have been removed although the
'::new' syntax is still allowed.  Are 'new T' and '::new T' now
equivalent?

If so, then what is the purpose of the following paragraph from 5.3.4?  (I
can't make sense of it in any case.)

  The way the object was allocated determines how it is freed:  if it is
allocated by ::new, then it is freed by ::delete, and if it is an array,
it is freed by delete[] or ::delete[] as appropriate.

What does it mean and is it a restriction on programs or implementations?

Thanks for any reply,
       --scott

In article 1205951310530001@193.131.176.202, sdouglass@armltd.co.uk (scott douglass) writes:
>In the ARM (5.3.3) if class T has a member 'void* T::operator new(size_t)', then
>   'new T' will allocate using 'T::operator new(size_t)' and
>   '::new T' will allocate using the global '::operator new(size_t)'.
>'delete e' and '::delete e' are similar.
>
>In the draft std this distinction seems to have been removed although the
>'::new' syntax is still allowed.  Are 'new T' and '::new T' now
>equivalent?

No. Section 12.5, "Free Store", describes how member allocation and
deallocation functions are selected, if present. Section 5.3.4, "New",
says the "appropriate" allocator/deallocator is selected, and describes
the non-member function case.

>  The way the object was allocated determines how it is freed:  if it is
>allocated by ::new, then it is freed by ::delete, and if it is an array,
>it is freed by delete[] or ::delete[] as appropriate.
>
>What does it mean and is it a restriction on programs or implementations?

This looks to me like a glitch in the wording. In any event, it is attempting
to describe what happens when you write
 delete ptr; // or delete [] ptr;
Section 1.1, "Scope", says that this standard specifies requirements on
"processors", not on programs. (This is different from what the C standard
says, and was the subject of considerable debate in the C++ Committee.)
---
Steve Clamage, stephen.clamage@eng.sun.com