swengtoo said:
I am familiar with allocation "in place" (placement new, etc.),
How is that relevant here?
> but the
idea of oveloading the delete operator to operate on stack objects
(automatic variables) was pretty new to me. After all, if the automatic
object is deleted automatically once it goes out of scope, why
complicate matters?
I am not sure where you're coming from about "complicating matters". You
started with 'auto_ptr' owning an automatic object, which is theoretically
allowed if that class defines 'delete' in a certain way. There is no
sense AFAIK to do that in a _real_life_ program. I've not encountered it
in my 10+ years of C++.
One could argue that I would want to implement something like that
exactly for the original idea that started this thread: letting an
auto_ptr point to an automatic variable. But then, is this the most
elegant solution to the "problem"?
What is <<the "problem">> you're referring to? It seems that allowing
'auto_ptr' to hold the address of an automatic variable is what is known
as "a solution in search of a problem". What would be the reason for you
to create an auto_ptr object and let it hold the address of an automatic
object?
> Are there other scenarios that would
mandate overriding delete to work on a stack object?
Since you are speaking hypothetically, anyway, here is one: I would
override 'new' and 'delete' and make them throw just to prohibit any
allocation of those objects in the free store. This is not usual by any
measures.
V