«

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();

}

On Apr 14, 6:38 pm, Simon L <silang...@hotmail.com> wrote:
> 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...container.html
* Boost Shared Pointer - http://www.boost.org/doc/libs/1_35_0...shared_ptr.htm

Hope you will find these links helpful.

- Vlady

wrote:
> On Apr 14, 6:38 pm, Simon L <silang...@hotmail.com> wrote:
>> 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.

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.

"Noah Roberts" <> wrote in message
>> On Apr 14, 6:38 pm, Simon L <silang...@hotmail.com> wrote:
>>> 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.
>
> 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.

--
http://techytalk.googlepages.com

On Apr 14, 7:53 pm, Noah Roberts <u...@example.net> wrote:
> Vladislav.Lazare...@gmail.com wrote:
> > On Apr 14, 6:38 pm, Simon L <silang...@hotmail.com> wrote:
> >> 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.
>
> 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

Simon L wrote:
> 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.)

Juha Nieminen wrote:

> (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.

Noah Roberts wrote:
> Juha Nieminen wrote:
>
>> (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.

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.