🚀 go-pugleaf

Hi,

Nico Josuttis (nico@bredex.de) wrote:
: In a tutorial a student asked a very good question i think:
: How can auto_ptr imagine which delete to use.

This is simple: 'auto_ptr' is to be used for non-array objects only.
The requirements for the pointer 'p' stored in an 'auto_ptr' is, that
you can apply 'delete p' (see lib.auto.ptr.cons).

: Consider:
:  int* p = new int;
: and
:  int* p = new int[10];
: should result in different delete operations.
: But if I let auto_ptr do the job, how does it know
: which one to use?

It knows because you are supposed to guarantee that you don't store a
pointer to an array object in the 'auto_ptr'.

: Isn't it a BIG design problem ?

Not really. You are not supposed to do many allocations of array
objects anyway: Use 'vector' instead. It is, however, a security
problem: A user might get trapped into the idea that an 'auto_ptr' can
be used for both array and non-array object. Especially, as there is no
equivalent for array objects (e.g. 'auto_array_ptr'). BTW, note that
the access methods for 'auto_ptr' are not very well suited to be used
for arrays:  E.g. the subscript operator is missing rendering the use
of 'auto_ptr' for array objects useless.

: Reading the DWP it calls delete (without [])
: what would be wrong in many cases since
: using new for arrays is probaly made very often.

Probably not, as there are several aspects which render newing built-in
arrays as quite dangerous. A much better alternative is using 'vector'
(or some other array class where 'vector' is not suitable).

: I fear we need two kind of auto_ptr, don't we?

If there are more than one kind of 'auto_ptr' I insist on having at
least four kinds of 'auto_ptr', i.e. for

  - non-array objects allocated with 'new T(...)'
  - array objects allocated with 'new T[]'
  - raw memory objects allocated with 'operator new()'
  - raw memory array objects allocated with 'operator new[]()'

I guess there are much more. You might want to have a look at the
article I wrote to the thread "auto_ptr problems" in
comp.lang.c++.moderated: There I present an implementation of
'auto_ptr' which makes use of a framework where both the resources to
be managed (the pointer types I mentioned above plus resources like
files, locks, windows, etc.) and the style of the management (like for
'auto_ptr', reference counting, and other styles) can be varied
independently.
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl/
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]