Smart Pointers : auto_ptr and array

Discussion in 'C++' started by mosfet, May 16, 2007.

  1. mosfet

    mosfet Guest

    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 ?
     
    mosfet, May 16, 2007
    #1
    1. Advertising

  2. mosfet

    Stefan Naewe Guest

    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
     
    Stefan Naewe, May 16, 2007
    #2
    1. Advertising

  3. * 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?
     
    Alf P. Steinbach, May 16, 2007
    #3
  4. mosfet

    dasjotre Guest

    On 16 May, 10:41, mosfet <> 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.
     
    dasjotre, May 16, 2007
    #4
  5. mosfet

    James Kanze Guest

    On May 16, 12:00 pm, "Alf P. Steinbach" <> 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:
    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
     
    James Kanze, May 16, 2007
    #5
  6. * James Kanze:
    > On May 16, 12:00 pm, "Alf P. Steinbach" <> 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?
     
    Alf P. Steinbach, May 19, 2007
    #6
  7. mosfet

    James Kanze Guest

    On May 19, 5:05 am, "Alf P. Steinbach" <> wrote:
    > * James Kanze:


    > > On May 16, 12:00 pm, "Alf P. Steinbach" <> 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:
    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
     
    James Kanze, May 19, 2007
    #7
  8. In article <>,
    James Kanze <> wrote:

    > On May 19, 5:05 am, "Alf P. Steinbach" <> wrote:
    > > * James Kanze:

    >
    > > > On May 16, 12:00 pm, "Alf P. Steinbach" <> 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/wg21/docs/papers/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/wg21/docs/papers/2005/n1856.html#20.4.5
    %20-%20Class%20template%20auto_ptr

    -Howard
     
    Howard Hinnant, May 25, 2007
    #8
  9. mosfet

    James Kanze Guest

    On May 25, 10:04 pm, Howard Hinnant <> wrote:
    > In article <>,
    > James Kanze <> 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/wg21/docs/papers/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/wg21/docs/papers/2005/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:
    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
     
    James Kanze, May 25, 2007
    #9
  10. In article <>,
    James Kanze <> wrote:

    > On May 25, 10:04 pm, Howard Hinnant <> wrote:
    > > In article <>,
    > > James Kanze <> 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/wg21/docs/papers/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/wg21/docs/papers/2005/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
     
    Howard Hinnant, May 26, 2007
    #10
  11. mosfet

    Jon Harrop Guest

    Jon Harrop, May 30, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. BekTek
    Replies:
    9
    Views:
    852
    Jonathan Turkanis
    Nov 29, 2004
  2. Siemel Naran

    auto_ptr<Derived> to auto_ptr<Base>

    Siemel Naran, Jan 10, 2005, in forum: C++
    Replies:
    2
    Views:
    1,561
    Dave Rahardja
    Jan 11, 2005
  3. MotoK
    Replies:
    59
    Views:
    1,835
    Keith Thompson
    Sep 15, 2006
  4. n2xssvv g02gfr12930

    Smart pointers and member function pointers

    n2xssvv g02gfr12930, Nov 26, 2005, in forum: C++
    Replies:
    3
    Views:
    472
    n2xssvv g02gfr12930
    Nov 27, 2005
  5. Sousuke
    Replies:
    9
    Views:
    1,157
    Bart van Ingen Schenau
    Mar 16, 2010
Loading...

Share This Page