> >>>>> "BG" == Bill Gibbons <bgibbons@taligent.com> writes:
>
>     BG> In article <1994May27.141734.20391@oracle.us.oracle.com>,
>     BG> bconnor@whisk.NoSubdomain.NoDomain (Brett Connor) wrote:
>
>     >> What is the latest thinking in the working paper about an exception
>     >> being thrown from a constructor?  Who is responsible for delete'ing
>     >> the memory if it was new'd ?  Are any compilers close to supporting
>     >> this ?
>
>     BG> The implementation must arrange to delete the allocated memory.
>     BG> This was clarified in March.
>
>     BG> However, it's assumed that a "placement" new may not allocate
>     BG> memory, so the delete is only called during exception handing when
>     BG> the ordinary variant of "new" is used:
>
>     BG> The working paper says nothing about other variants of "new",
>     BG> except that there are two places where the rules are written with
>     BG> the assumption that these variants might not allocate memory: in
>     BG> exception handling cleanup, and in the restriction on deleting
>     BG> arrays allocated with placement new.
>
>     BG> This is probably wrong; other variants of operator new should
>     BG> probably be assumed to be allocating.
>
> Yup.  For example, what about a form that allows you to allocate memory
> from alternate heaps:
>
>    void *operator new (size_t, Heap &) ;
>
>   Foo *foo = new (myHeap) Foo() ; // exception thrown
>
> In this case, we would want to free the memory allocated for 'foo' from
> the heap 'myHeap'.  This may be of even greater concern if the heap in
> question is very small, or is persistent, etc.
>
> Still, I am not sure that any *assumptions* should be made at all about
> the various placement forms of new().  Why not make it explicit by adding
> syntax to the new declaration to specify whether delete should be called
> (sans destructor).
>
>    void *operator new (size_t, Heap &) delete_on_exception ;
>
> or simply:
>
>    void *operator new (size_t, Heap &) delete ;
>
> BTW, this is of more than passing interest to me since I have actually
> written and use alternate heap classes.

What happened to the idea of having the compiler call the matching operator
delete if an exception is thrown? I suppose you define your own appropriate

 void operator delete(void *, Heap &);

which is just the right thing to do. I seem to recall there was a mention of
allowing the overloading of operator delete   in the same manner. If so, the
rule could become simple indeed, even for arrays - when an exception occures
in a constructor called via some 'new' operator, the compiler looks for the
matching operator delete operator and calls it to free the data. If the
matching operator is not defined, the compiler does nothing. What's wrong
with that?

     Oren Ben-Kiki.

--
Life is tough and the hard ships are many.

In article <CBARBER.94Jun3104624@apricot.bbn.com>, cbarber@bbn.com (Christopher Barber) writes:
|> >>>>> "BG" == Bill Gibbons <bgibbons@taligent.com> writes:
|>
|>     BG> In article <1994May27.141734.20391@oracle.us.oracle.com>,
|>     BG> bconnor@whisk.NoSubdomain.NoDomain (Brett Connor) wrote:
|>
|>     >> What is the latest thinking in the working paper about an exception
|>     >> being thrown from a constructor?  Who is responsible for delete'ing
|>     >> the memory if it was new'd ?  Are any compilers close to supporting
|>     >> this ?
|>
|>     BG> The implementation must arrange to delete the allocated memory.
|>     BG> This was clarified in March.
|>
|>     BG> However, it's assumed that a "placement" new may not allocate
|>     BG> memory, so the delete is only called during exception handing when
|>     BG> the ordinary variant of "new" is used:
|>
|>     BG> The working paper says nothing about other variants of "new",
|>     BG> except that there are two places where the rules are written with
|>     BG> the assumption that these variants might not allocate memory: in
|>     BG> exception handling cleanup, and in the restriction on deleting
|>     BG> arrays allocated with placement new.
|>
|>     BG> This is probably wrong; other variants of operator new should
|>     BG> probably be assumed to be allocating.
|>
|> Yup.  For example, what about a form that allows you to allocate memory
|> from alternate heaps:
|>
|>    void *operator new (size_t, Heap &) ;
|>
|>   Foo *foo = new (myHeap) Foo() ; // exception thrown
|>
|> In this case, we would want to free the memory allocated for 'foo' from
|> the heap 'myHeap'.  This may be of even greater concern if the heap in
|> question is very small, or is persistent, etc.
|>
|> Still, I am not sure that any *assumptions* should be made at all about
|> the various placement forms of new().  Why not make it explicit by adding
|> syntax to the new declaration to specify whether delete should be called
|> (sans destructor).
|>
|>    void *operator new (size_t, Heap &) delete_on_exception ;
|>
|> or simply:
|>
|>    void *operator new (size_t, Heap &) delete ;
|>
|> BTW, this is of more than passing interest to me since I have actually
|> written and use alternate heap classes.
|>
|> - Chris
|> --
|> Christopher Barber
|> (cbarber@bbn.com)


I agree wholeheartedly with Chris (and if his suggestion is not accepted)
then with Bill.

In low-level operating system work multiple heaps with different
characteristics is usually required.  Overloading new is a wonderful
way to go.  We ran into the "exception thrown by constructor" problem
some time ago.  Originally, our compiler ALWAYS freed the storage, which
was clearly wrong for true "placement" new.  The compiler quickly changed
to only free the storage for the default new, but not for any of the
"placement" forms.  This left us with storage leaks.

I would very much like to see the ability to declare whether the compiler
should free storage for each operator new.  Lacking that, I would like
to see the compiler free storage for all operator new's except the standard
placement new.

--

Mike Corrigan
corrigan@vnet.ibm.com

In article <1994May27.141734.20391@oracle.us.oracle.com>,
bconnor@whisk.NoSubdomain.NoDomain (Brett Connor) wrote:

> Forgive me if this has been answered recently - I can't find any
> reference to it.
>
> What is the latest thinking in the working paper about an exception
> being thrown from a constructor?  Who is responsible for delete'ing
> the memory if it was new'd ?  Are any compilers close to supporting
> this ?
>
> Thanks
>
> Brett

The implementation must arrange to delete the allocated memory.  This
was clarified in March.

However, it's assumed that a "placement" new may not allocate memory,
so the delete is only called during exception handing when the ordinary
variant of "new" is used:

    void * operator new(size_t);          // usual
    void * operator new(size_t, void *);  // in new.h; non-allocating
    void * operator new(size_t, int);     // not known if allocating

    struct T { T() { throw 5; } };

    void f(void *mem) {
        new T;         // (1) operator delete is called during cleanup
        new (mem) T;   // (2) operator delete is NOT called
        new (mem,1) T; // (3) operator delete is NOT called
    }

The first two cases are easy: the working paper already says that
the first variant of "new" is allocating, and the second variant is
non-allocating.

The working paper says nothing about other variants of "new", except
that there are two places where the rules are written with the
assumption that these variants might not allocate memory:  in exception
handling cleanup, and in the restriction on deleting arrays allocated
with placement new.

This is probably wrong; other variants of operator new should probably
be assumed to be allocating.  Then operator delete would be called
in case 3 (but still not in case 2).

I will be advocating this position at the July standards meeting.


Bill Gibbons
bgibbons@taligent.com

>>>>> "BG" == Bill Gibbons <bgibbons@taligent.com> writes:

    BG> In article <1994May27.141734.20391@oracle.us.oracle.com>,
    BG> bconnor@whisk.NoSubdomain.NoDomain (Brett Connor) wrote:

    >> What is the latest thinking in the working paper about an exception
    >> being thrown from a constructor?  Who is responsible for delete'ing
    >> the memory if it was new'd ?  Are any compilers close to supporting
    >> this ?

    BG> The implementation must arrange to delete the allocated memory.
    BG> This was clarified in March.

    BG> However, it's assumed that a "placement" new may not allocate
    BG> memory, so the delete is only called during exception handing when
    BG> the ordinary variant of "new" is used:

    BG> The working paper says nothing about other variants of "new",
    BG> except that there are two places where the rules are written with
    BG> the assumption that these variants might not allocate memory: in
    BG> exception handling cleanup, and in the restriction on deleting
    BG> arrays allocated with placement new.

    BG> This is probably wrong; other variants of operator new should
    BG> probably be assumed to be allocating.

Yup.  For example, what about a form that allows you to allocate memory
from alternate heaps:

   void *operator new (size_t, Heap &) ;

  Foo *foo = new (myHeap) Foo() ; // exception thrown

In this case, we would want to free the memory allocated for 'foo' from
the heap 'myHeap'.  This may be of even greater concern if the heap in
question is very small, or is persistent, etc.

Still, I am not sure that any *assumptions* should be made at all about
the various placement forms of new().  Why not make it explicit by adding
syntax to the new declaration to specify whether delete should be called
(sans destructor).

   void *operator new (size_t, Heap &) delete_on_exception ;

or simply:

   void *operator new (size_t, Heap &) delete ;

BTW, this is of more than passing interest to me since I have actually
written and use alternate heap classes.

- Chris
--
Christopher Barber
(cbarber@bbn.com)

Forgive me if this has been answered recently - I can't find any
reference to it.

What is the latest thinking in the working paper about an exception
being thrown from a constructor?  Who is responsible for delete'ing
the memory if it was new'd ?  Are any compilers close to supporting
this ?

Thanks

Brett