I don't get why smart pointers are useful.

[Simon L]

Pointer mismanagement is a big cause of bugs in software that I work
on. I decided to invest a little time into
having a look at auto_ptr and other smart pointers but I don't see how
they'll save me making the same mistakes.


A typical use and source of buggy pointers is in a collection of
objects. My containers of choice, eg stl::vector
don't like auto_ptr so I've had to use some MFC template classes.

In this test app I don't see how my pointers are suddenly safe or
smart. Yes they transfer ownership, yes they
auto delete but what I was hoping (expecting) was that manipulation of
old (ie ownership transferred or cleaned)
auto_ptrs would be handled.

Use of the pointer selection -> on my old auto_ptr blows up my app.,
gaining me very little as far as I can see.

Is it that my demo. app. is too trivial to see the benefits? If I have
to wrap all use of my object in if( something !=null) then I've
gained nothing.

Thanks


class cNew
{
public:
cNew(int i, LPCTSTR pc)
{
iNew = i;
strcpy(cText , pc);
}
char* GetCNew(){return cNew;}
int iNew;
char cText[256];
};

CList<auto_ptr<sNew> , auto_ptr<sNew>& > m_Arr;

void CSTLTestDlg::OnBnClickedOk()
{

auto_ptr<sNew> aNew ( new cNew(1, CString("Hello World")));

AfxMessageBox( aNew->GetCNew() , MB_OKCANCEL );

m_Arr.AddTail( aNew );
//ownership of cNew passes to an auto_ptr in my List

AfxMessageBox( m_Arr.GetHead()->GetCNew() , MB_YESNO );
//seems to contain valid data

char* pcData = aNew->GetCNew();
//pcData is non null eg random memory

int iData = aNew->iNew;
//exception

m_Arr.RemoveAll();

OnOK();

}

 

[Vladislav.Lazarenko]

Pointer mismanagement is a big cause of bugs in software that I work
on. I decided to invest a little time into
having a look at auto_ptr and other smart pointers but I don't see how
they'll save me making the same mistakes.

Well designed smart pointers library will not allow you to make a
mistake. It is not a good idea to use std::auto_ptr template with
vector or any other collection that performs object copying.
std::auto_ptr will not manage this situation for you. Never.

Please take a loot at the following:

* Pointer Container - http://www.boost.org/doc/libs/1_35_0/libs/ptr_container/doc/ptr_container.html
* Boost Shared Pointer - http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/shared_ptr.htm

Hope you will find these links helpful.

- Vlady

 

[Noah Roberts]

Well designed smart pointers library will not allow you to make a
mistake. It is not a good idea to use std::auto_ptr template with
vector or any other collection that performs object copying.
std::auto_ptr will not manage this situation for you. Never.

Well, std::auto_ptr violates copy and assignment semantics. It therefor
CAN'T be used in a std::vector. You can attempt to, sure, but it will
not work and that's why.

 

[sk_usenet]

Well, std::auto_ptr violates copy and assignment semantics. It therefor
CAN'T be used in a std::vector. You can attempt to, sure, but it will not
work and that's why.

Yes, it is a case of undefined behavior.

 

[Vladislav.Lazarenko]

Well, std::auto_ptr violates copy and assignment semantics. It therefor
CAN'T be used in a std::vector. You can attempt to, sure, but it will
not work and that's why.

That's exactly what I am talking about. I use ptr_container for Boost
for these purposes or list of shared pointer if they should really be
shared

 

[Juha Nieminen]

Use of the pointer selection -> on my old auto_ptr blows up my app.,
gaining me very little as far as I can see.

Thus auto_ptr is the wrong tool in your case. You clearly want a
*shared* object, not a transferred one (which is what auto_ptr does).

The standard C++ libraries do not (yet) provide smart pointers for
shared objects, but eg. the boost library provides very good ones. You
should try them.

(And btw, trying to use auto_ptr with std::vector shouldn't even
compile. If your compiler compiled it anyways, it's broken.)

 

[Noah Roberts]

(And btw, trying to use auto_ptr with std::vector shouldn't even
compile. If your compiler compiled it anyways, it's broken.)

Why shouldn't it compile? Unless I'm mistaken, using std::auto_ptr in a
container is a conceptual violation, not a syntatic one. How would the
compiler even know? It would have to be using concepts or traits of
some sort and a bunch of metaprogramming. The standard library doesn't
do that yet since neither is part of the standard yet.

 

[Juha Nieminen]

Why shouldn't it compile? Unless I'm mistaken, using std::auto_ptr in a
container is a conceptual violation, not a syntatic one. How would the
compiler even know? It would have to be using concepts or traits of
some sort and a bunch of metaprogramming. The standard library doesn't
do that yet since neither is part of the standard yet.

Normally copy constructors take a const reference to the object to be
copied, while auto_ptr takes a non-const reference. If you try to copy a
const object like this, it will fail.

Of course it may be possible that some std::vector implementation
never uses 'const' anywhere, in which case it may happily compile
without error.