what's wrong with std::auto_ptr<int> ptr(new int[100]);?

[meili100]

what's wrong with std::auto_ptr<int> ptr(new int[100]) ?

Seems it works....?

[King Mir]

The auto pointer destructor calls delete without brackets on the object it point's to. Delete without brackets can only be used on objects created by unbracketed new. An array is created with new[], and can only be deallocated by delete[]. Mismatching bracketed and unbracketed versions of new and delete is undefined behavior, and can result in crashes or memory leaks.

Even if it seems it works, doesn't mean it does, and even if it does, it's not portable.

[ChaosEngine]

as King Mir said, that is not a correct use of auto_ptr. the functionality you want is provided by std::vector

[iMalc]

Well for one, Compuware's DevPartner will bring up an error and tell you off.

It doesn't help the Microsoft header files have several such bugs. At least I came across several in the gdiplus headers recently.

[meili100]

Why didn't people implement auto_ptr with a "delete[]" in std::auto_ptr in the first place??? Since delete[] can be used for single pointer as well, for example:

	char * tmpi = new char;
	delete[] tmpi;

delete[] works well here, doesn't it?

[Bench82]

Why didn't people implement auto_ptr with a "delete[]" in std::auto_ptr in the first place??? Since delete[] can be used for single pointer as well, for example:

	char * tmpi = new char;
	delete[] tmpi;

delete[] works well here, doesn't it?

No - its undefined behaviour (Anything can happen). When memory is allocated with new, use delete, and when memory is allocated with new[], use delete[] - You can't mix and match these as you please.

Why exactly do you need an auto_ptr for a dynamically created array anyway? As someone else mentioned in this thread, you'd be better off using a std::vector

[KIBO]

The UB comes from that delete without brackets doesnt call destructors on all of the array right? So would it be safe to use auto_ptr on primitive types since they dont have a destructor?

char *s = new char[10];

delete s;

The memory s points to does get freed I'd say and no destructors need to be called

[brewbuck]

Why didn't people implement auto_ptr with a "delete[]" in std::auto_ptr in the first place???

Because, as has already been said, std::vector already provides exactly what you are looking for. There's no point providing two ways to do the same thing -- this isn't Perl, here.

[Daved]

This exact same question was just asked somewhere recently. The answer was the same then.

>> So would it be safe to use auto_ptr on primitive types since they dont have a destructor?
No. It's undefined behavior. The fact that destructors aren't called is only a possible (or perhaps likely) symptom. Since you cannot guarantee what will happen, it is not safe to do that. In addition, since there are generally better alternatives, there's no reason to try.

The only case where somebody might prefer an auto_ptr for arrays is if they actually want to take advantage of the copy semantics where ownership is transferred rather than a copy being made. I'm not sure if there is a smart array class with these same semantics available, but I believe it will be easier to do that with vectors in C++0x.

[CornedBee]

auto_array would be rather trivial to write. Copy the auto_ptr source, replace delete with delete[] and add an index operator.

Yes, it will be easier in C++09:

vector<int> other = std::move(source);