Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Smart Pointers : auto_ptr and array

Reply
Thread Tools

Smart Pointers : auto_ptr and array

 
 
mosfet
Guest
Posts: n/a
 
      05-16-2007
Hi,

Let's say I have a vector of auto_ptr defined like this :

vector< auto_ptr<T> > v;

is it allowed ?
Is there any side effects ?

If it's not a good idea, how can I fix this ?
 
Reply With Quote
 
 
 
 
Stefan Naewe
Guest
Posts: n/a
 
      05-16-2007
On 5/16/2007 11:41 AM, mosfet wrote:
> Hi,
>
> Let's say I have a vector of auto_ptr defined like this :
>
> vector< auto_ptr<T> > v;
>
> is it allowed ?
> Is there any side effects ?


No. Not allowed. Might not compile. Don't !

> If it's not a good idea, how can I fix this ?


std::vector<boost::shared_ptr<T> > v;


S.
--
Stefan Naewe
stefan dot naewe at atlas-elektronik dot com
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-16-2007
* mosfet:
>
> vector< auto_ptr<T> > v;
>
> is it allowed ?


No, because auto_ptr is not copyable, and a good compiler will complain.


> Is there any side effects ?


Yes, if it compiles.


> If it's not a good idea, how can I fix this ?


Use e.g. boost::shared_ptr.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
dasjotre
Guest
Posts: n/a
 
      05-16-2007
On 16 May, 10:41, mosfet <(E-Mail Removed)> wrote:
> Hi,
>
> Let's say I have a vector of auto_ptr defined like this :
>
> vector< auto_ptr<T> > v;
>
> is it allowed ?


NO. read http://www.ddj.com/dept/cpp/184403719

> Is there any side effects ?
> If it's not a good idea, how can I fix this ?


use boost/TR1 shared_ptr instead.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-16-2007
On May 16, 12:00 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * mosfet:


> > vector< auto_ptr<T> > v;


> > is it allowed ?


> No, because auto_ptr is not copyable, and a good compiler will
> complain.


> > Is there any side effects ?


> Yes, if it compiles.


I'm no longer very sure about this---the specification of
auto_ptr seems to change each time I look---but wasn't the
motivation behind its use of auto_ptr_ref, or whatever,
precisely so that trying to instantiate std::vector on one
couldn't compile?

--
James Kanze (Gabi Software) email: http://www.velocityreviews.com/forums/(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-19-2007
* James Kanze:
> On May 16, 12:00 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> * mosfet:

>
>>> vector< auto_ptr<T> > v;

>
>>> is it allowed ?

>
>> No, because auto_ptr is not copyable, and a good compiler will
>> complain.

>
>>> Is there any side effects ?

>
>> Yes, if it compiles.

>
> I'm no longer very sure about this---the specification of
> auto_ptr seems to change each time I look---but wasn't the
> motivation behind its use of auto_ptr_ref, or whatever,
> precisely so that trying to instantiate std::vector on one
> couldn't compile?


You're asking more than I currently know. I probably did know that at
one time, and I think Howard Hinnant knows. The auto_ptr_ref trick
enables construction from a temporary (into a copy constructor with
non-const formal arg), but what its main motivation was...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-19-2007
On May 19, 5:05 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * James Kanze:


> > On May 16, 12:00 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> >> * mosfet:


> >>> vector< auto_ptr<T> > v;


> >>> is it allowed ?


> >> No, because auto_ptr is not copyable, and a good compiler will
> >> complain.


> >>> Is there any side effects ?


> >> Yes, if it compiles.


> > I'm no longer very sure about this---the specification of
> > auto_ptr seems to change each time I look---but wasn't the
> > motivation behind its use of auto_ptr_ref, or whatever,
> > precisely so that trying to instantiate std::vector on one
> > couldn't compile?


> You're asking more than I currently know. I probably did know that at
> one time, and I think Howard Hinnant knows. The auto_ptr_ref trick
> enables construction from a temporary (into a copy constructor with
> non-const formal arg), but what its main motivation was...


It may even date before his time.

I know that auto_ptr went through at least three versions before
the first CD, and IIRC, auto_ptr_ref was originally introduced
because the British national body threatened to vote no on the
standard unless something was done to prevent instantiation of a
container on an auto_ptr. Since then: the version in the 2003
version of the standard is significantly different than that in
the 1998, so it continued to move after I stopped looking.

About all I know is that today, I can generally use it for the
purposes I want it for, with just about any compiler. Which is
considerable progress.

--
James Kanze (Gabi Software) email: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
Howard Hinnant
Guest
Posts: n/a
 
      05-25-2007
In article <(E-Mail Removed). com>,
James Kanze <(E-Mail Removed)> wrote:

> On May 19, 5:05 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> > * James Kanze:

>
> > > On May 16, 12:00 pm, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> > >> * mosfet:

>
> > >>> vector< auto_ptr<T> > v;

>
> > >>> is it allowed ?

>
> > >> No, because auto_ptr is not copyable, and a good compiler will
> > >> complain.

>
> > >>> Is there any side effects ?

>
> > >> Yes, if it compiles.

>
> > > I'm no longer very sure about this---the specification of
> > > auto_ptr seems to change each time I look---but wasn't the
> > > motivation behind its use of auto_ptr_ref, or whatever,
> > > precisely so that trying to instantiate std::vector on one
> > > couldn't compile?

>
> > You're asking more than I currently know. I probably did know that at
> > one time, and I think Howard Hinnant knows. The auto_ptr_ref trick
> > enables construction from a temporary (into a copy constructor with
> > non-const formal arg), but what its main motivation was...

>
> It may even date before his time.


<nod> It does.

> I know that auto_ptr went through at least three versions before
> the first CD, and IIRC, auto_ptr_ref was originally introduced
> because the British national body threatened to vote no on the
> standard unless something was done to prevent instantiation of a
> container on an auto_ptr. Since then: the version in the 2003
> version of the standard is significantly different than that in
> the 1998, so it continued to move after I stopped looking.
>
> About all I know is that today, I can generally use it for the
> purposes I want it for, with just about any compiler. Which is
> considerable progress.


See the latest working draft:

http://www.open-std.org/jtc1/sc22/wg...2007/n2284.pdf

for the latest change in the continually evolving auto_ptr:

It's deprecated.

Currently the best write up I have on auto_ptr, why it is deprecated,
and its replacement unique_ptr (which *will* work in containers) is:

http://www.open-std.org/jtc1/sc22/wg...56.html#20.4.5
%20-%20Class%20template%20auto_ptr

-Howard
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-25-2007
On May 25, 10:04 pm, Howard Hinnant <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed). com>,
> James Kanze <(E-Mail Removed)> wrote:


> > About all I know is that today, I can generally use it for the
> > purposes I want it for, with just about any compiler. Which is
> > considerable progress.


> See the latest working draft:


> http://www.open-std.org/jtc1/sc22/wg...2007/n2284.pdf


> for the latest change in the continually evolving auto_ptr:
>
> It's deprecated.


> Currently the best write up I have on auto_ptr, why it is deprecated,
> and its replacement unique_ptr (which *will* work in containers) is:


> http://www.open-std.org/jtc1/sc22/wg.../n1856.html#20...
> %20-%20Class%20template%20auto_ptr


So you invent a new name for something which serves more or less
the same purpose.

Just curious, but why the new name? Are there any legal uses of
auto_ptr that won't work exactly the same with unique_ptr? And
if not, why not call it auto_ptr, assuming that that doesn't
break any working code? (I use auto_ptr a lot in multithreaded
programs, even when I'm also using the Boehm collector.)

--
James Kanze (Gabi Software) email: (E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
Howard Hinnant
Guest
Posts: n/a
 
      05-25-2007
In article <(E-Mail Removed) om>,
James Kanze <(E-Mail Removed)> wrote:

> On May 25, 10:04 pm, Howard Hinnant <(E-Mail Removed)> wrote:
> > In article <(E-Mail Removed). com>,
> > James Kanze <(E-Mail Removed)> wrote:

>
> > > About all I know is that today, I can generally use it for the
> > > purposes I want it for, with just about any compiler. Which is
> > > considerable progress.

>
> > See the latest working draft:

>
> > http://www.open-std.org/jtc1/sc22/wg...2007/n2284.pdf

>
> > for the latest change in the continually evolving auto_ptr:
> >
> > It's deprecated.

>
> > Currently the best write up I have on auto_ptr, why it is deprecated,
> > and its replacement unique_ptr (which *will* work in containers) is:

>
> > http://www.open-std.org/jtc1/sc22/wg.../n1856.html#20...
> > %20-%20Class%20template%20auto_ptr

>
> So you invent a new name for something which serves more or less
> the same purpose.


The new name exists because unique_ptr is not an exact superset of the
auto_ptr syntax. If it were, , we could just fix auto_ptr instead of
deprecating it and introducing a new name.

> Just curious, but why the new name?


Read the link. At the top of the read is the reason for deprecating
auto_ptr and substituting in unique_ptr as the replacement. If we could
simply reengineer auto_ptr without breaking existing code we would. But
we can't.

> Are there any legal uses of
> auto_ptr that won't work exactly the same with unique_ptr? And
> if not, why not call it auto_ptr, assuming that that doesn't
> break any working code?


From the paper:

> However because unique_ptr does not move from lvalues with copy syntax, it is
> not a 100% source-compatible drop in replacement for auto_ptr. If it were, we
> could just fix auto_ptr instead of deprecating it and introducing a new class
> template.




> (I use auto_ptr a lot in multithreaded
> programs, even when I'm also using the Boehm collector.)


And that is the reason auto_ptr has been deprecated, not removed, from
the standard. We understand that it is heavily used and must remain in
the standard for now. Deprecation doesn't mean non-standard. It merely
means that you are put on notice that it might be removed from a future
standard (say in 2019).

Within that decade ahead of us, I hope that most uses of auto_ptr will
be able to migrate to unique_ptr. But that migration will, in some
cases, require more than just renaming auto_ptr to unique_ptr. The link
points out the breakage under this migration:

> However copy semantics is disabled with unique_ptr:
>
> auto_ptr<int> ap1(new int);
> auto_ptr<int> ap2 = ap1; // ok, but unsafe implicit move
>
> unique_ptr<int> up1(new int);
> unique_ptr<int> up2 = up1; // compile time error: illegal access to
> // private copy constructor
>
> If you really want to transfer ownership from the lvalue unique_ptr, you move
> from it just as you would any other type:
>
> unique_ptr<int> up1(new int);
> unique_ptr<int> up2 = move(up1); // ok, explicit move


In the interim auto_ptr and unique_ptr will coexist in the standard.
unique_ptr will support a superset of the functionality of auto_ptr, but
with slightly different syntax when "copying" (actually moving) from
lvalues.

-Howard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
explicit auto_ptr<T>::auto_ptr(T*) ? Sousuke C++ 9 03-16-2010 11:54 AM
Smart Pointers: Is there something similar to smart pointers in C? MotoK C Programming 59 09-15-2006 07:03 PM
Smart pointers and member function pointers n2xssvv g02gfr12930 C++ 3 11-27-2005 10:51 AM
auto_ptr<Derived> to auto_ptr<Base> Siemel Naran C++ 2 01-11-2005 04:45 AM
Which is preferable std::auto_ptr or boost's smart pointer? BekTek C++ 9 11-29-2004 06:37 PM



Advertisments