usenet@aristeia.com (Scott Meyers) wrote (abridged):
> I'm not a compiler writer, but I'd expect the most-derived destructor
> to call operator delete.

I'm not one either. The one time I looked at it, the operator delete() was
being invoked by the base class. I presumed that was because the derived
class didn't know if it was the /most/ derived class, and so that the
deletion code could be shared between all of the derived classes.

Anyway, it does affect the main point. Even if the overhead is a single
machine code instruction that loads a constant, it's still a cost that
brings no benefit to programs that doesn't use the size.

Incidently, what did you have in mind for the implementation to do in the
cases where the size is unknown and 0 passed? I'm thinking especially of
code like:

    struct Pod;
    void kill( Pod *p ) {
        delete p; // Pod is an incomplete type here.
    }

which can be well-defined behaviour. Would this just be a memory leak?

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:

> I'm not a compiler writer, but I'd expect the most-derived destructor to
> call operator delete.

struct A
{
     virtual ~A() = 0;
}

struct B : public A
{
     ~B() { }
}

int main()
{
     B b;
     A& a = b;
     a.~A();
}

If the destructor called operator delete here, it would do so on an
object allocated on automatic memory, hence invoking undefined behaviour.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mon, 08 Jan 2007 17:53:25 +0000, Mathias Gaunard wrote:

> Scott Meyers wrote:
>
>> I'm not a compiler writer, but I'd expect the most-derived destructor to
>> call operator delete.
>
> struct A
> {
>      virtual ~A() = 0;
> }
>
> struct B : public A
> {
>      ~B() { }
> }
>
> int main()
> {
>      B b;
>      A& a = b;
>      a.~A();
> }
>
> If the destructor called operator delete here, it would do so on an
> object allocated on automatic memory, hence invoking undefined behaviour.

That's easily solved. When generating the call to the destructor, the
compiler always knows wether operator delete should be called. The
implementor can pass an extra flag to the destructor wether to call
operator delete or not. In fact I know of two implementations that work
that way.

M4
--
Redundancy is a great way to introduce more single points of failure.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

loufoque@remove.gmail.com (Mathias Gaunard) writes:

> struct A
> {
>     virtual ~A() = 0;
> }
>
> struct B : public A
> {
>     ~B() { }
> }
>
> int main()
> {
>     B b;
>     A& a = b;
>     a.~A();
> }
>
> If the destructor called operator delete here, it would do so on an
> object allocated on automatic memory, hence invoking undefined
> behaviour.

[are we wandering off-topic into implementation specifics?]

the implementations i've looked at do in fact have the destructor
call the appropriate operator delete, but that call is conditional
upon a parameter passed by the compiler.  if we imagine the
B::~B() being translated to C, you'd see something like

        void __B_dtor(B* self, int do_delete)
        {
            __B_user_dtor(self);
            __B_cleanup(self);
            __A_dtor(self, 0);
            if (do_delete)
               __B_operator_delete(self);
        }

except the __B_* functions would probably just be inlined
code to execute the user define destructor, member cleanup,
and call the appropriate operator delete, respectively.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

pixi@bloodbath.burble.org (maurice barnum) wrote (abridged):
>         void __B_dtor(B* self, int do_delete)
>         {
>             __B_user_dtor(self);
>             __B_cleanup(self);
>             __A_dtor(self, 0);
>             if (do_delete)
>                __B_operator_delete(self);
>         }

And if both classes use the same operator delete(), and it doesn't require
a size, that can be shortened to:

         void __B_dtor(B* self, int do_delete)
         {
             __B_user_dtor(self);
             __B_cleanup(self);
             __A_dtor(self, do_delete);
        }

This is less code in the code segment, avoids repeating the test of
do_delete, and the final call is now a tail-call. In many cases (if
there's no __B_cleanup()) the whole thing can be optimised away and
__A_dtor used instead.

If operator delete() does need a size, it's not so simple, but I suspect
it's still quicker to make the size available to the base class than to
repeat the test and call. (Obviously if B introduces its own operator
delete, then it has to do the test and call; but further subclasses
needn't.)

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

loufoque@remove.gmail.com (Mathias Gaunard) wrote (abridged):
> However, you can allocate an object as Derived and delete it as Base.
> And sizeof(Derived) could be bigger than sizeof(Base).

That's also undefined behaviour, unless Base has a virtual destructor - in
which case the compiler can use the vtable to pass the (correct) size of
Derived. This situation is covered by the second rule in Scott's original
post:

      - For an expression E of class type, the same value that'd
      be passed to typeof(E)::operator delete taking a size_t.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> With a scheme like that, can't you use:
>
>     static char *s_top; // Initialise to heap somehow.
>
>     void *operator new( size_t sz ) {
>         void *result = s_top;
>         s_top += sz;
>         return result;
>     }
>
>     void operator delete( void *p ) {
>         if (p)
>             s_top = reinterpret_cast<char *>( p );
>     }


I can't think of any reason why this wouldn't work in this case.  Thanks
for the suggestion!

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> Figuring out what size to pass would have a cost. For classes with virtual
> functions, the cost would often involve indirecting through the vtable,

No, such indirection would be incurred in looking up the destructor, not
the operator delete.  Once you know the destructor (which you have to
look up anyway), you know the operator delete to call.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

lgalfaso@gmail.com (Lucas Galfaso) wrote (abridged):
> Can you please point me to the specific section where it is stated that
> this is undefined behavior. I am talking about a fundamental type, like
> int, not a class, not even a POD.

I don't have the final standard, but in the 1996 draft it's $5.3.5=20
[expr.delete]:

     3. In the first alternative (delete object), if the static type
     of the operand is different from its dynamic type, the static
     type shall be a base class of the operand=92s dynamic type and
     the static type shall have a virtual destructor or the behavior
     is undefined.

Also paragraph 2 says that the value deleted must be "a pointer to a=20
non-array object created by a new expression". Casting between pointers t=
o=20
fundamental types can change their values. It's even possible that=20
sizeof(void *) !=3D sizeof(int *). Some platforms represent int pointers=20
differently to char pointers and I believe a conforming compiler can keep=
=20
a char heap separate to the int heap.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:
 Please snip excess quoted content when replying.


===================================== END OF MODERATOR'S COMMENT

Scott Meyers wrote:
> wkaras@yahoo.com wrote:
> > Could they not write a template to call their stack alloc func,
> > placement new, and another template to explicitly call
> > desctructor, stack free func?
>
> Sure, but they'd have to explicitly pass the size, which they would not
> have to do if the compiler would pass it for them.  The interesting
> issue here is that this feature already exists for class-specific
> operator delete, so the question is why it doesn't or should also exist
> for global operator delete.
>

For deletion, yes.  Or, type_info could be extended to have a 'size'
member

// Ignore errors.

template <typename T>
T * my_new(void)
  {
    // Placement new.
    return(new (my_stack_alloc(sizeof(T))) T);
  }

template <typename T>
void my_delete(T *t)
  {
    t->~T();
    my_stack_free(t, typeid(*t).size());
  }

In order to be able to implement my_arr_delete,
we'd need a new library templated function
'dimension' that would return 0 when passed
a pointer to a non-newed object, othewise the
number of objects pointed to.

> >> Can someone explain to me why having the "normal" operator delete take a
> >> size_t is impractical?
> >
> > I think for this to make sense the delete [] operator would have to be
> > change
> > to require the dimension of the array, which I think I read in some
> > book
> > by Dr. Stroustrup was considered but rejected.
>
> The delete operator already has to have access to the number of elements
> in an array, at least for types with nontrivial destructors, so it could
> pass it through to operator delete, but I agree, the situation for
> operator delete[] is probably more complicated than for operator delete.
>
> Scott
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> lgalfaso@gmail.com (Lucas Galfaso) wrote (abridged):
> > Can you please point me to the specific section where it is stated that
> > this is undefined behavior. I am talking about a fundamental type, like
> > int, not a class, not even a POD.

> I don't have the final standard, but in the 1996 draft it's $5.3.5
> [expr.delete]:

>      3. In the first alternative (delete object), if the static type
>      of the operand is different from its dynamic type, the static
>      type shall be a base class of the operand?s dynamic type and
>      the static type shall have a virtual destructor or the behavior
>      is undefined.

That's unchanged in the latest draft (and presumably in all
versions between, including the official standard).

> Also paragraph 2 says that the value deleted must be "a pointer to a
> non-array object created by a new expression". Casting between pointers to
> fundamental types can change their values. It's even possible that
> sizeof(void *) != sizeof(int *). Some platforms represent int pointers
> differently to char pointers and I believe a conforming compiler can keep
> a char heap separate to the int heap.

I don't think so.  What happens if you replace the global
operator delete?  (On the other hand, while the standard says
that you can replace the global operator delete, it doesn't say
how, so presumably, an implementation could require a compiler
option when it is done, and generate different code in that
case.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> Dave Harris wrote:
> > With a scheme like that, can't you use:

> >     static char *s_top; // Initialise to heap somehow.

> >     void *operator new( size_t sz ) {
> >         void *result = s_top;
> >         s_top += sz;
> >         return result;
> >     }

> >     void operator delete( void *p ) {
> >         if (p)
> >             s_top = reinterpret_cast<char *>( p );
> >     }

> I can't think of any reason why this wouldn't work in this case.

Alignment.  But that's easy to fix (and may not be a problem, if
all of the allocated objects are of types which have a size
which is a multiple of the maximum alignment).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

usenet@aristeia.com (Scott Meyers) wrote (abridged):
> > Figuring out what size to pass would have a cost. For classes with
> > virtual functions, the cost would often involve indirecting through
> > the vtable,
>
> No, such indirection would be incurred in looking up the destructor,
> not the operator delete.  Once you know the destructor (which you have
> to look up anyway), you know the operator delete to call.

The destructor of the most-derived class knows what size to pass to
operator delete() at compile time. However, I wouldn't have thought that
destructor would be responsible for actually calling operator delete(), so
it would need to pass that information on to where-ever it is used. So
there's an additional cost over the non-virtual case.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> The destructor of the most-derived class knows what size to pass to
> operator delete() at compile time. However, I wouldn't have thought that
> destructor would be responsible for actually calling operator delete(), so
> it would need to pass that information on to where-ever it is used. So
> there's an additional cost over the non-virtual case.

I'm not a compiler writer, but I'd expect the most-derived destructor to
call operator delete.  It knows the correct size to pass, and I'm pretty
sure the lookup for the operator delete to call is done as if it were
called from insider the destructor, anyway (though it's probably not
specified in quite that way).

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

jam wrote:
> declare an empy  class whose public templated constructor deletes the
> pointer passed to it and who delares operator delete of its own which
> devices the second size_t param too.use the constructor of this class
> to delete pointers

I don't see how this can help.  The class's operator delete will work
only on pointers to objects of that type, not to random pointers (e.g.
to pointers to built-in types).

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers kirjoitti:
>=20
> I don't see how it's any more error-prone than the class-specific=20
> version of operator delete that takes a size.
>=20

Suppose we a pointer to some base class A and it actually points to an=20
object of derived class B that inherits from A:
---
A* a =3D new B;
delete a;
---
Suppose that A has a virtual destructor.
Then a class-specific delete operator in A with a size_t argument always=20
gets the correct size of the object to be deleted (sizeof (B) in this cas=
e).

If we had a size_t argument in the global delete operator it would=20
probably get sizeof(A) in the example above. However, it might be=20
possible to pass the correct runtime size of objects to global operator=20
delete for classes having virtual destructors.

--=20
Tommi H=F6yn=E4l=E4nmaa
s=E4hk=F6posti / e-mail: tommi.hoynalanmaa@iki.fi
kotisivu / homepage: http://www.iki.fi/tohoyn/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrew Koenig wrote:

> Many moons ago I tried to convince the C++ community that there would be
> much to gain from abandoning malloc/free, but I could never find anyone
> willing even to consider it seriously.

That's too bad.
malloc/free is seriously hurting C++.

We could also introduce a standard LIFO allocator, which just works in
most cases (when you don't need to transcend scope) and is way more
efficient.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <4591d812$0$13749$426a34cc@news.free.fr>, Mathias Gaunard
<loufoque@remove.gmail.com> writes
>Andrew Koenig wrote:
>
>> Many moons ago I tried to convince the C++ community that there would
>>be  much to gain from abandoning malloc/free, but I could never find
>>anyone  willing even to consider it seriously.
>
>That's too bad.
>malloc/free is seriously hurting C++.

It must be the time of the year because I am finding it very difficult
to understand how something I never use in C++ can be hurting C++. Could
one of you try to explain.

As far as I am concerned malloc/free is just there for compatibility
with C (as is, for example, the printf and scanf families of functions)

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

greghe@pacbell.net (Greg Herlihy) wrote (abridged):
> The global delete operator has no comparable back-up, there is no other
> delete routine that it can call to free the memory - global delete must
> free the block itself.

No, it can use malloc()/free(), in much the same way that the
class-specific delete operator uses the global one. I don't think you've
found a meaningful difference here.


> And in order to free the block, the global delete operator must know
> the size of the actual allocation; knowing just the requested size
> alone (the value of the size parameter) is not enough information
> to free the block.

This is not true, in general. Knowing the requested size is enough for
some implementations to deduce the allocated size. The original poster
gave an example.


> After all, the correctness of a program's memory management should
> not depend upon the faithful preservation of data points that are
> needlessly round-tripped through the user program, or so I would think.

I'm not sure what you mean here. If you allocate an object as int and
delete it as char, you have undefined behaviour, so the memory manager can
depend on the user not doing that sort of thing. And that's pretty much
the limit of the user's involvement. In the original post, the size
argument is determined by the compiler, not the user.

In any case it sounds like a quality of implementation issue. Passing the
size argument gives the memory manager more options. It can store its own
size and use the passed-in size as a check in debug builds. In release
builds it can either use its stored size to deallocate, or it can stop
storing the size and use the passed-in size instead. It can trade off
robustness against space efficiency. Why should the standard take these
choices away from the implementation?

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:

> I'm not sure what you mean here. If you allocate an object as int and
> delete it as char, you have undefined behaviour, so the memory manager can
> depend on the user not doing that sort of thing.

However, you can allocate an object as Derived and delete it as Base.
And sizeof(Derived) could be bigger than sizeof(Base).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

usenet@aristeia.com (Scott Meyers) wrote (abridged):
> The question arose recently when I was working with a team on an
> embedded project, and it became clear that (1) dynamically allocated
> memory was a reasonable design option for them and (2) they could
> guarantee that they'd delete objects in the inverse order in which
> they'd be allocated.  This meant that they could use a stack allocator,
> so calling operator new for an object of type T would simply increase
> the stack pointer by sizeof(T) (modulo alignment issues) and calling
> operator delete would simply decrease it by sizeof(T) (again modulo
> alignment issues).  Unfortunately, the global operator delete doesn't
> get the sizeof(T), and, unless I'm overlooking something, the only way
> to get it is to store it somewhere, which they didn't want to spend the
> memory to do.

With a scheme like that, can't you use:

    static char *s_top; // Initialise to heap somehow.

    void *operator new( size_t sz ) {
        void *result = s_top;
        s_top += sz;
        return result;
    }

    void operator delete( void *p ) {
        if (p)
            s_top = reinterpret_cast<char *>( p );
    }

(Ignoring alignment issues and error checking.) I think passing the size
to operator delete() would be a good idea, but I don't see why it is
necessary here.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

lgalfaso@gmail.com (Lucas Galfaso) wrote (abridged):
> Having that definition for an extra parameter for the global operator
> delete would be really a bad idea; The key is when you delete a void*.
> Say you have a pointer to a fundamental type, you cast it to void*, and
> you delete the casted pointer; What would you expect to happen?

That's already undefined behaviour, so anything can happen. The type
used in the delete expression must match the type in the new expression.

In practice I expect that the behaviour of most vendor implementations
will not change. They will simply ignore the passed size argument.

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> I can imagine specifying the global operator delete like this:

>    void operator delete(void *p, size_t sz);

> such that an expression "delete E" that ultimately yields a call to
> ::operator delete would pass sz as follows:
> - For an expression E of class type, the same value that'd be passed to
>    typeof(E)::operator delete taking a size_t.
> - For an expression E of non-class type T, sizeof(T).
> - For an expression E of type void*, 0 (zero), meaning "size unknown".

> Can someone explain to me why having the "normal" operator delete take a
> size_t is impractical?

I don't know that it's impractical.  But the implementation must
provide one signature, and it must be fixed, if you are to be
allowed to replace it.  (Otherwise, how would you know the
signature that needed to be replaced.)  The signature chosen was
the one without the second parameter.

The situation in the case of a class specific operator delete is
somewhat different, in that you are defining a new function,
which doesn't exist otherwise.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dave Harris wrote:
> lgalfaso@gmail.com (Lucas Galfaso) wrote (abridged):
> > Having that definition for an extra parameter for the global operator
> > delete would be really a bad idea; The key is when you delete a void*.
> > Say you have a pointer to a fundamental type, you cast it to void*, and
> > you delete the casted pointer; What would you expect to happen?
>
> That's already undefined behaviour, so anything can happen. The type
> used in the delete expression must match the type in the new expression.
>

Can you please point me to the specific section where it is stated that
this is undefined behavior. I am talking about a fundamental type, like
int, not a class, not even a POD.

Regards,
  Lucas Galfaso

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

usenet@aristeia.com (Scott Meyers) wrote (abridged):
> I can imagine specifying the global operator delete like this:
>
>    void operator delete(void *p, size_t sz);
>
> such that an expression "delete E" that ultimately yields a call to
> ::operator delete would pass sz as follows:
> - For an expression E of class type, the same value that'd be passed to
>    typeof(E)::operator delete taking a size_t.
> - For an expression E of non-class type T, sizeof(T).
> - For an expression E of type void*, 0 (zero), meaning "size unknown".
>
> Can someone explain to me why having the "normal" operator delete take
> a size_t is impractical?

Figuring out what size to pass would have a cost. For classes with virtual
functions, the cost would often involve indirecting through the vtable,
but even passing a constant 0 takes code to do.

Many heap implementations don't need the size. If they are based on
malloc(), for example. These implementations should not have to pay the
cost of a size_t argument they don't use.

It's hard to see how the cost can be optimised away, because we don't know
until link time whether the user has replaced operator delete() with one
which uses (or doesn't use) the size_t. The linker itself would have to
optimise (and then we have dynamic linking to think about).

-- Dave Harris, Nottingham, UK.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I'm sure I used to know this once upon a time, but why doesn't the
global operator delete take a size_t argument specifying the size of the
memory chunk being freed?  The ARM doesn't seem to say anything about
this design decision, and I don't know where else to look.

The question arose recently when I was working with a team on an
embedded project, and it became clear that (1) dynamically allocated
memory was a reasonable design option for them and (2) they could
guarantee that they'd delete objects in the inverse order in which
they'd be allocated.  This meant that they could use a stack allocator,
so calling operator new for an object of type T would simply increase
the stack pointer by sizeof(T) (modulo alignment issues) and calling
operator delete would simply decrease it by sizeof(T) (again modulo
alignment issues).  Unfortunately, the global operator delete doesn't
get the sizeof(T), and, unless I'm overlooking something, the only way
to get it is to store it somewhere, which they didn't want to spend the
memory to do.

I can imagine specifying the global operator delete like this:

   void operator delete(void *p, size_t sz);

such that an expression "delete E" that ultimately yields a call to
::operator delete would pass sz as follows:
- For an expression E of class type, the same value that'd be passed to
   typeof(E)::operator delete taking a size_t.
- For an expression E of non-class type T, sizeof(T).
- For an expression E of type void*, 0 (zero), meaning "size unknown".

Can someone explain to me why having the "normal" operator delete take a
size_t is impractical?

Thanks,

Scott




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> Can someone explain to me why having the "normal" operator delete take a
> size_t is impractical?
>

The answer is simple, there is nowhere to store this information, if
you need it, you store it. This is just another example of C++ of not
to make everybody pays for what just a few need.

Regards,
  Lucas

> Thanks,
>
> Scott
>
>
       ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Scott Meyers" <usenet@aristeia.com> wrote in message
news:12omt8jit7rl379@corp.supernews.com...

> I'm sure I used to know this once upon a time, but why doesn't the global
> operator delete take a size_t argument specifying the size of the memory
> chunk being freed?  The ARM doesn't seem to say anything about this design
> decision, and I don't know where else to look.
>
> The question arose recently when I was working with a team on an embedded
> project, and it became clear that (1) dynamically allocated memory was a
> reasonable design option for them and (2) they could guarantee that they'd
> delete objects in the inverse order in which they'd be allocated.  This
> meant that they could use a stack allocator, so calling operator new for
> an object of type T would simply increase the stack pointer by sizeof(T)
> (modulo alignment issues) and calling operator delete would simply
> decrease it by sizeof(T) (again modulo alignment issues).  Unfortunately,
> the global operator delete doesn't get the sizeof(T), and, unless I'm
> overlooking something, the only way to get it is to store it somewhere,
> which they didn't want to spend the memory to do.
>
> I can imagine specifying the global operator delete like this:
>
>   void operator delete(void *p, size_t sz);
>
> such that an expression "delete E" that ultimately yields a call to
> ::operator delete would pass sz as follows:
> - For an expression E of class type, the same value that'd be passed to
>   typeof(E)::operator delete taking a size_t.
> - For an expression E of non-class type T, sizeof(T).
> - For an expression E of type void*, 0 (zero), meaning "size unknown".
>
> Can someone explain to me why having the "normal" operator delete take a
> size_t is impractical?

It's another thing to get wrong. And it's a false economy not to want to
"spend the memory" to pack it with the allocated storage. You're storing
the information *somewhere*, in some form. Okay, maybe a thousand items
can all have the same compile-time constant size, which occupies just
a field in one instruction. If that's an important part of your size
budget, then you should be maintaining a LIFO array as a single block,
IMO, not demanding that a general heap truckle to your particular
needs.

We've had decades of experience with heap management by now, and the
learned wisdom is to let the heap maintain its own integrity as much
as possible. That has proved to be the best general mechanism.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

P.J. Plauger wrote:
> It's another thing to get wrong.

I don't see how it's any more error-prone than the class-specific
version of operator delete that takes a size.

 >  And it's a false economy not to want to
> "spend the memory" to pack it with the allocated storage. You're storing
> the information *somewhere*, in some form.

I don't believe this is the case;  see my reply to Lucas Galfaso's post.

 > Okay, maybe a thousand items
> can all have the same compile-time constant size, which occupies just
> a field in one instruction. If that's an important part of your size
> budget, then you should be maintaining a LIFO array as a single block,

The situation in question is strict LIFO allocation, but not all objects
are of the same size.  Hence the need for the deallocator to know how
big each allocation is.  Storing the size of each object is clearly
possible, but my contention is that it is not necessary, per my earlier
posts.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> I'm sure I used to know this once upon a time, but why doesn't the
> global operator delete take a size_t argument specifying the size of the
> memory chunk being freed?  The ARM doesn't seem to say anything about
> this design decision, and I don't know where else to look.

new is sure of the type, delete is not.

>
> The question arose recently when I was working with a team on an
> embedded project, and it became clear that (1) dynamically allocated
> memory was a reasonable design option for them and (2) they could
> guarantee that they'd delete objects in the inverse order in which
> they'd be allocated.  This meant that they could use a stack allocator,
> so calling operator new for an object of type T would simply increase
> the stack pointer by sizeof(T) (modulo alignment issues) and calling
> operator delete would simply decrease it by sizeof(T) (again modulo
> alignment issues).  Unfortunately, the global operator delete doesn't
> get the sizeof(T), and, unless I'm overlooking something, the only way
> to get it is to store it somewhere, which they didn't want to spend the
> memory to do.

Just use an allocator directly instead of new/delete.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Scott Meyers" <usenet@aristeia.com> wrote in message
news:12omt8jit7rl379@corp.supernews.com...

> I'm sure I used to know this once upon a time, but why doesn't the global
> operator delete take a size_t argument specifying the size of the memory
> chunk being freed?

Because if it did, what would it mean?

1) If it means "Free just this much memory and leave the rest unallocated",
then it becomes impossible to implement new/delete in terms of malloc/free.

2) If it can be ignored, which would appear to be necessary to use
malloc/free for allocation, then what's the point?

Many moons ago I tried to convince the C++ community that there would be
much to gain from abandoning malloc/free, but I could never find anyone
willing even to consider it seriously.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrew Koenig wrote:
> Because if it did, what would it mean?

The same thing it means for a per-class deallocator:  please deallocate
the chunk of memory pointed to by this pointer;  you can assume that the
size indicated is correct for the chunk.  (Actually, now that I look for
it, I can't find anything in the standard (at least not in 3.7.3.2 or
5.3.5 or 12.5) that specifies the semantics of the size_t argument.
I've always assumed it was the size of the chunk that should be
deallocated if UB was to be avoided.)

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 24, 4:28 am, a...@acm.org ("Andrew Koenig") wrote:
> "Scott Meyers" <use...@aristeia.com> wrote in messagenews:12omt8jit7rl379@corp.supernews.com...
>
> > I'm sure I used to know this once upon a time, but why doesn't the global
> > operator delete take a size_t argument specifying the size of the memory
> > chunk being freed?Because if it did, what would it mean?
>
> 1) If it means "Free just this much memory and leave the rest unallocated",
> then it becomes impossible to implement new/delete in terms of malloc/free.
>
> 2) If it can be ignored, which would appear to be necessary to use
> malloc/free for allocation, then what's the point?
>
> Many moons ago I tried to convince the C++ community that there would be
> much to gain from abandoning malloc/free, but I could never find anyone
> willing even to consider it seriously.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

I am an amatuer programmer who started from C.I am convinced now that
C++`s dynamic memory management mechanism can be much better than what
it is .I have got good ideas I do not know where to submit.It envolves
minamal backward compatible syntax corrections already implemented on
some platforms.I beleive that the couple keywords "new/delete" can be
decreased to one keyword ;in my suggestion a keyword for deleting is
unnecessary(this does not mean that dealocation will not take place).I
appreciate any advise.

regards
F Mehrabi

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Lucas Galfaso wrote:
 > Scott Meyers wrote:
 >> Can someone explain to me why having the "normal" operator delete take a
 >> size_t is impractical?

 > The answer is simple, there is nowhere to store this information, if
 > you need it, you store it. This is just another example of C++ of not
 > to make everybody pays for what just a few need.

One of us is missing something.  At class scope, operator delete may
take a size_t.  If it does, it's provided by the compiler, which
passes the size of the object.  The information is not "stored" in the
sense of a memory location holding the size -- the compiler passes a
constant.  If a pointer to a derived object via a base class pointer
is being deleted and the base destructor is not virtual, the wrong
size gets passed, but that's okay, behavior under those conditions is
undefined.

You can only delete three things: a pointer to a class type, a pointer
to a non-class type, and a void*.  My suggestion was that a global
operator delete taking a size_t could:

- For pointers to class types, get the same value that'd be passed to
   a class-specific operator delete taking a size.
- For a pointer p to a non-class type, sizeof(*p).
- for a void* pointer, zero.

None of these options requires storing anything anywhere.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> The question arose recently when I was working with a team on an
> embedded project, and it became clear that (1) dynamically allocated
> memory was a reasonable design option for them and (2) they could
> guarantee that they'd delete objects in the inverse order in which
> they'd be allocated.  This meant that they could use a stack allocator,
> so calling operator new for an object of type T would simply increase
> the stack pointer by sizeof(T) (modulo alignment issues) and calling
> operator delete would simply decrease it by sizeof(T) (again modulo
> alignment issues).  Unfortunately, the global operator delete doesn't
> get the sizeof(T), and, unless I'm overlooking something, the only way
> to get it is to store it somewhere, which they didn't want to spend the
> memory to do.

Could they not write a template to call their stack alloc func,
placement new, and another template to explicitly call
desctructor, stack free func?

> I can imagine specifying the global operator delete like this:
>
>    void operator delete(void *p, size_t sz);
>
> such that an expression "delete E" that ultimately yields a call to
> ::operator delete would pass sz as follows:
> - For an expression E of class type, the same value that'd be passed to
>    typeof(E)::operator delete taking a size_t.
> - For an expression E of non-class type T, sizeof(T).
> - For an expression E of type void*, 0 (zero), meaning "size unknown".
>
> Can someone explain to me why having the "normal" operator delete take a
> size_t is impractical?

I think for this to make sense the delete [] operator would have to be
change
to require the dimension of the array, which I think I read in some
book
by Dr. Stroustrup was considered but rejected.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> Can someone explain to me why having the "normal" operator delete take a
> size_t is impractical?

Since the implementation of a class-specific delete operator always has
the option of calling the global delete operator to perform the actual
deallocation, a class delete operator does have a good excuse for not
knowing the actual size of the block being deleted. Therefore, knowing
the size of the original allocation request very well could be
information that the class delete operator could not otherwise find out
on its own.

The global delete operator has no comparable back-up, there is no other
delete routine that it can call to free the memory - global delete must
free the block itself. And in order to free the block, the global
delete operator must know the size of the actual allocation; knowing
just the requested size alone (the value of the size parameter) is not
enough information to free the block. Even assuming that the value of
the size parameter is accurate in the first place. After all, the
correctness of a program's memory management should not depend upon the
faithful preservation of data points that are needlessly round-tripped
through the user program, or so I would think.

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

wkaras@yahoo.com wrote:
> Could they not write a template to call their stack alloc func,
> placement new, and another template to explicitly call
> desctructor, stack free func?

Sure, but they'd have to explicitly pass the size, which they would not
have to do if the compiler would pass it for them.  The interesting
issue here is that this feature already exists for class-specific
operator delete, so the question is why it doesn't or should also exist
for global operator delete.

>> Can someone explain to me why having the "normal" operator delete take a
>> size_t is impractical?
>
> I think for this to make sense the delete [] operator would have to be
> change
> to require the dimension of the array, which I think I read in some
> book
> by Dr. Stroustrup was considered but rejected.

The delete operator already has to have access to the number of elements
in an array, at least for types with nontrivial destructors, so it could
pass it through to operator delete, but I agree, the situation for
operator delete[] is probably more complicated than for operator delete.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> Lucas Galfaso wrote:
>  > Scott Meyers wrote:
>  >> Can someone explain to me why having the "normal" operator delete take a
>  >> size_t is impractical?
>
>  > The answer is simple, there is nowhere to store this information, if
>  > you need it, you store it. This is just another example of C++ of not
>  > to make everybody pays for what just a few need.
>
> You can only delete three things: a pointer to a class type, a pointer
> to a non-class type, and a void*.  My suggestion was that a global
> operator delete taking a size_t could:
>
> - For pointers to class types, get the same value that'd be passed to
>    a class-specific operator delete taking a size.
> - For a pointer p to a non-class type, sizeof(*p).
> - for a void* pointer, zero.
>
> None of these options requires storing anything anywhere.

Having that definition for an extra parameter for the global operator
delete would be really a bad idea; The key is when you delete a void*.
Say you have a pointer to a fundamental type, you cast it to void*, and
you delete the casted pointer; What would you expect to happen?

  Lucas

> Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> wkaras@yahoo.com wrote:
> > Could they not write a template to call their stack alloc func,
> > placement new, and another template to explicitly call
> > desctructor, stack free func?
>
> Sure, but they'd have to explicitly pass the size, which they would not
> have to do if the compiler would pass it for them.  The interesting
> issue here is that this feature already exists for class-specific
> operator delete, so the question is why it doesn't or should also exist
> for global operator delete.
>
> >> Can someone explain to me why having the "normal" operator delete take a
> >> size_t is impractical?
> >
> > I think for this to make sense the delete [] operator would have to be
> > change
> > to require the dimension of the array, which I think I read in some
> > book
> > by Dr. Stroustrup was considered but rejected.
>
> The delete operator already has to have access to the number of elements
> in an array, at least for types with nontrivial destructors, so it could
> pass it through to operator delete, but I agree, the situation for
> operator delete[] is probably more complicated than for operator delete.
>
> Scott
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

declare an empy  class whose public templated constructor deletes the
pointer passed to it and who delares operator delete of its own which
devices the second size_t param too.use the constructor of this class
to delete pointers

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]