Using auto_ptr<> with array

Question

I'm using auto_ptr<> which uses an array of class pointer type so how do I assign a value to it.

e.g. auto_ptr<class*> arr[10];

How can I assign a value to the arr array?

Phenocryst

So do you want array of auto_ptr to type or auto_ptr of array of type? Big difference. – Lucier

i need a auto_ptr which points to the array of class pointer. – Phenocryst

Answer 1

You cannot use auto_ptr with array, because it calls delete p, not delete [] p.

You want boost::scoped_array or some other boost::smart_array :)

Glyoxaline

There is an edge case with zero-length arrays that does work with auto_ptr. – Merriott

@0A0D: No, that's not true. int * a = new a[0] HAS TO be deleted with delete [] a, not delete a, therefore, having an AP to that will result in UB – Glyoxaline

@Armen: From 5.3.4 [expr.new], paragraph 7: When the value of the expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements. The pointer returned by the new-expression is non-null. [Note: If the library allocation function is called, the pointer returned is distinct from the pointer to any other object.] – Merriott

@0A0D: Yes. How does that imply that you can delete it with delete rather than delete[]? – Glyoxaline

@Armen: It doesn't other than refuting the statement that you cannot use auto_ptr with array, because you can. It just takes some work :) and that auto_ptr with zero-length arrays is totally legal. – Merriott

@0A0D: No, it is illegal to have an auto_ptr to an array of 0 length (illegal as in Undefined Behavior). The reason is as simple as this: if a pointer has been returned via call to new[], deleting it with mere delete results in UB - no exceptions. – Glyoxaline

@0A0D let us continue this discussion in chat – Glyoxaline

Answer 2

If you have C++0x (e.g. MSVC10, GCC >= 4.3), I'd strongly advise to use either a std::vector<T> or a std::array<T, n> as your base object type (depending on whether the size is fixed or variable), and if you allocate this guy on the heap and need to pass it around, put it in a std::shared_ptr:

typedef std::array<T, n> mybox_t;
typedef std::shared_ptr<mybox_t> mybox_p;

mybox_p makeBox() { auto bp = std::make_shared<mybox_t>(...); ...; return bp; }

Healing

Answer 3

Arrays and auto_ptr<> don't mix.

From the GotW site:

Every delete must match the form of its new. If you use single-object new, you must use single-object delete; if you use the array form of new, you must use the array form of delete. Doing otherwise yields undefined behaviour.

I'm not going to copy the GotW site verbatim; however, I will summarize your options to solve your problem:

1. Roll your own auto array

   1a. Derive from auto_ptr. Few advantages, too difficult.

   1b. Clone auto_ptr code. Easy to implement, no significant space/overhead. Hard to maintain.

2. Use the Adapter Pattern. Easy to implement, hard to use, maintain, understand. Takes more time / overhead.
3. Replace auto_ptr With Hand-Coded EH Logic. Easy to use, no significant space/time/overhead. Hard to implement, read, brittle.
4. Use a vector<> Instead Of an Array. Easy to implement, easy to read, less brittle, no significant space, time, overhead. Syntactic changes needed and sometimes usability changes.

So the bottom line is to use a vector<> instead of C-style arrays.

Merriott

Answer 4

As everyone said here, don't mix arrays with auto_ptr. This must be used only when you've multiple returns where you feel really difficult to release memory, or when you get an allocated pointer from somewhere else and you've the responsibility to clean it up before existing the function.

the other thing is that, in the destructor of auto_ptr it calls delete operator with the stored pointer. Now what you're passing is a single element of an array. Memory manager will try to find and free up the memory blocks allocated starting from the address you're passing. Probably this might not be existing heap where all allocations are maintained. You may experience an undefined behavior like crash, memory corruption etc. upon this operation.

Truss