auto_ptr assignment crash with VC language extensions

Discussion in 'C++' started by Diego Martins, Nov 20, 2006.

  1. I just discovered a serious issue when compiling code using auto_ptr<>
    and VC 8.0

    consider some sort of create() function

    blahblah * create() { return new blahblah; }

    and a pretty auto_ptr


    auto_ptr<base_blahblah> p;

    int main() {
    ....
    p.reset(create());

    // use p as usual and we will be free of leak :)

    }

    but if we change that line to
    p = create();

    the WILL compile on VC 8 and may raise an access violation exception


    You can tell me to disable these damned extensions and stop
    bothering....
    Oww, how I wish.. Of course I can't disable them because many Windows
    headers depend on this feature enabled :-(

    Is there any practical way to get rid of this? It makes easier to ruin
    a program by accident...

    What a damned extension heh? :)


    thanks
    Diego Martins
     
    Diego Martins, Nov 20, 2006
    #1
    1. Advertising

  2. Diego Martins

    Guest

    Diego Martins wrote:
    > I just discovered a serious issue when compiling code using auto_ptr<>
    > and VC 8.0
    >
    > consider some sort of create() function
    >
    > blahblah * create() { return new blahblah; }
    >
    > and a pretty auto_ptr
    >
    >
    > auto_ptr<base_blahblah> p;
    >
    > int main() {
    > ...
    > p.reset(create());
    >
    > // use p as usual and we will be free of leak :)
    >
    > }
    >
    > but if we change that line to
    > p = create();
    >
    > the WILL compile on VC 8 and may raise an access violation exception
    >
    >
    > You can tell me to disable these damned extensions and stop
    > bothering....
    > Oww, how I wish.. Of course I can't disable them because many Windows
    > headers depend on this feature enabled :-(
    >
    > Is there any practical way to get rid of this? It makes easier to ruin
    > a program by accident...
    >
    > What a damned extension heh? :)
    >
    >
    > thanks
    > Diego Martins


    There could be a problem with the copy constructor, I am not sure but
    then you can disable language extensions with /Za but I dont think this
    is related to that.

    Having said that, what if you initialize it directly like this.

    auto_ptr<sBase> p(creates());

    I think the Reset is making sure that the correct pointer is
    initialized to the member of the auto_ptr object.
     
    , Nov 20, 2006
    #2
    1. Advertising

  3. Diego Martins

    Guest

    Diego Martins wrote:
    > I just discovered a serious issue when compiling code using auto_ptr<>
    > and VC 8.0
    >
    > consider some sort of create() function
    >
    > blahblah * create() { return new blahblah; }
    >
    > and a pretty auto_ptr
    >
    >
    > auto_ptr<base_blahblah> p;
    >
    > int main() {
    > ...
    > p.reset(create());
    >
    > // use p as usual and we will be free of leak :)
    >
    > }
    >
    > but if we change that line to
    > p = create();
    >
    > the WILL compile on VC 8 and may raise an access violation exception


    I had the exact same problem a few days ago. If you search the archive
    for my handle (rdilipk) you'd find the relevant post. Victor Bazarov
    posted a lengthy explanation after some research into Dinkumware
    implementation.

    Basically this is not a VC8 specific issue. You *cannot* initialize an
    auto_ptr object with an ordinary pointer using the assignment syntax as
    you do.

    std::auto_ptr<Foo> ptr = new Foo;

    will NOT work.

    You need to do:

    std::auto_ptr<Foo> ptr(new Foo);

    Refer page 40 of C++ Standard Library by Josuttis for an explanation as
    to the why.
     
    , Nov 20, 2006
    #3
  4. Diego Martins

    P.J. Plauger Guest

    "Diego Martins" <> wrote in message
    news:...

    >I just discovered a serious issue when compiling code using auto_ptr<>
    > and VC 8.0
    >
    > consider some sort of create() function
    >
    > blahblah * create() { return new blahblah; }
    >
    > and a pretty auto_ptr
    >
    >
    > auto_ptr<base_blahblah> p;
    >
    > int main() {
    > ...
    > p.reset(create());
    >
    > // use p as usual and we will be free of leak :)
    >
    > }
    >
    > but if we change that line to
    > p = create();
    >
    > the WILL compile on VC 8 and may raise an access violation exception
    >
    >
    > You can tell me to disable these damned extensions and stop
    > bothering....
    > Oww, how I wish.. Of course I can't disable them because many Windows
    > headers depend on this feature enabled :-(
    >
    > Is there any practical way to get rid of this? It makes easier to ruin
    > a program by accident...
    >
    > What a damned extension heh? :)


    You can disable this "extension" by making the auto_ptr_ref constructor
    explicit, IIRC. (It's more of a lapse in compiler checking than an
    intentional attempt to extend auto_ptr in the library.)

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, Nov 21, 2006
    #4
  5. Diego Martins

    VJ Guest

    Diego Martins wrote:
    >
    > You can tell me to disable these damned extensions and stop
    > bothering....


    format c:

    and use anything else but windows
     
    VJ, Nov 21, 2006
    #5
  6. wrote:
    > Diego Martins wrote:
    > > I just discovered a serious issue when compiling code using auto_ptr<>
    > > and VC 8.0
    > >
    > > consider some sort of create() function
    > >
    > > blahblah * create() { return new blahblah; }
    > >
    > > and a pretty auto_ptr
    > >
    > >
    > > auto_ptr<base_blahblah> p;
    > >
    > > int main() {
    > > ...
    > > p.reset(create());
    > >
    > > // use p as usual and we will be free of leak :)
    > >
    > > }
    > >
    > > but if we change that line to
    > > p = create();
    > >
    > > the WILL compile on VC 8 and may raise an access violation exception
    > >
    > >
    > > You can tell me to disable these damned extensions and stop
    > > bothering....
    > > Oww, how I wish.. Of course I can't disable them because many Windows
    > > headers depend on this feature enabled :-(
    > >
    > > Is there any practical way to get rid of this? It makes easier to ruin
    > > a program by accident...
    > >
    > > What a damned extension heh? :)
    > >
    > >
    > > thanks
    > > Diego Martins

    >
    > There could be a problem with the copy constructor, I am not sure but
    > then you can disable language extensions with /Za but I dont think this
    > is related to that.


    yeah! i run to /Za, but I can't include winnt.h anymore
    even winsock2.h no longer works with /Za (making my "portable" sockets
    code useless)

    > Having said that, what if you initialize it directly like this.
    >
    > auto_ptr<sBase> p(creates());


    this works nicely of course

    > I think the Reset is making sure that the correct pointer is
    > initialized to the member of the auto_ptr object.


    reset is the only way to replace the owned pointer. however, it is easy
    to do a mistake and use operator= instead (one must admit it is
    intuitive, therefore)

    I hate VC++ :(

    Diego Martins
    HP
     
    Diego Martins, Nov 22, 2006
    #6
  7. wrote:
    > Diego Martins wrote:
    > > I just discovered a serious issue when compiling code using auto_ptr<>
    > > and VC 8.0
    > >
    > > consider some sort of create() function
    > >
    > > blahblah * create() { return new blahblah; }
    > >
    > > and a pretty auto_ptr
    > >
    > >
    > > auto_ptr<base_blahblah> p;
    > >
    > > int main() {
    > > ...
    > > p.reset(create());
    > >
    > > // use p as usual and we will be free of leak :)
    > >
    > > }
    > >
    > > but if we change that line to
    > > p = create();
    > >
    > > the WILL compile on VC 8 and may raise an access violation exception

    >
    > I had the exact same problem a few days ago. If you search the archive
    > for my handle (rdilipk) you'd find the relevant post. Victor Bazarov
    > posted a lengthy explanation after some research into Dinkumware
    > implementation.
    >
    > Basically this is not a VC8 specific issue. You *cannot* initialize an
    > auto_ptr object with an ordinary pointer using the assignment syntax as
    > you do.
    >
    > std::auto_ptr<Foo> ptr = new Foo;
    >
    > will NOT work.
    >
    > You need to do:
    >
    > std::auto_ptr<Foo> ptr(new Foo);
    >
    > Refer page 40 of C++ Standard Library by Josuttis for an explanation as
    > to the why.


    the initialization is not the worst problem, as I posted before.
    furthermore VC 8 compiles copy-initalization and assignment to raw
    pointers if compiler extensions are allowed.

    in the real world, if we need to use VC (to build an Windows exe or a
    DLL, of course), we need compiler extensions enabled :(

    since we can't go away with this, do you know a safe way to redefine
    the auto_ptr interface in order to keep my foot intact?

    someone in this thread told to make auto_ptr_ref constructor explicit.
    how I can "edit" that?

    Diego Martins
    HP
     
    Diego Martins, Nov 22, 2006
    #7
  8. Diego Martins

    P.J. Plauger Guest

    "Diego Martins" <> wrote in message
    news:...

    > wrote:
    >> Diego Martins wrote:
    >> > I just discovered a serious issue when compiling code using auto_ptr<>
    >> > and VC 8.0
    >> >
    >> > consider some sort of create() function
    >> >
    >> > blahblah * create() { return new blahblah; }
    >> >
    >> > and a pretty auto_ptr
    >> >
    >> >
    >> > auto_ptr<base_blahblah> p;
    >> >
    >> > int main() {
    >> > ...
    >> > p.reset(create());
    >> >
    >> > // use p as usual and we will be free of leak :)
    >> >
    >> > }
    >> >
    >> > but if we change that line to
    >> > p = create();
    >> >
    >> > the WILL compile on VC 8 and may raise an access violation exception

    >>
    >> I had the exact same problem a few days ago. If you search the archive
    >> for my handle (rdilipk) you'd find the relevant post. Victor Bazarov
    >> posted a lengthy explanation after some research into Dinkumware
    >> implementation.
    >>
    >> Basically this is not a VC8 specific issue. You *cannot* initialize an
    >> auto_ptr object with an ordinary pointer using the assignment syntax as
    >> you do.
    >>
    >> std::auto_ptr<Foo> ptr = new Foo;
    >>
    >> will NOT work.
    >>
    >> You need to do:
    >>
    >> std::auto_ptr<Foo> ptr(new Foo);
    >>
    >> Refer page 40 of C++ Standard Library by Josuttis for an explanation as
    >> to the why.

    >
    > the initialization is not the worst problem, as I posted before.
    > furthermore VC 8 compiles copy-initalization and assignment to raw
    > pointers if compiler extensions are allowed.
    >
    > in the real world, if we need to use VC (to build an Windows exe or a
    > DLL, of course), we need compiler extensions enabled :(
    >
    > since we can't go away with this, do you know a safe way to redefine
    > the auto_ptr interface in order to keep my foot intact?
    >
    > someone in this thread told to make auto_ptr_ref constructor explicit.
    > how I can "edit" that?


    See C:\Program Files\Microsoft Visual Studio 8\VC\include\memory.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
     
    P.J. Plauger, Nov 23, 2006
    #8
  9. P.J. Plauger wrote:
    > "Diego Martins" <> wrote in message
    > > someone in this thread told to make auto_ptr_ref constructor explicit.
    > > how I can "edit" that?

    >
    > See C:\Program Files\Microsoft Visual Studio 8\VC\include\memory.
    >
    > P.J. Plauger
    > Dinkumware, Ltd.
    > http://www.dinkumware.com


    I refuse to edit M$ header files

    How will it prevent future errors when I deploy the sources to other
    sites or Visual C updates?

    :(
     
    Diego Martins, Nov 27, 2006
    #9
  10. Diego Martins

    Bo Persson Guest

    Diego Martins wrote:
    > P.J. Plauger wrote:
    >> "Diego Martins" <> wrote in message
    >>> someone in this thread told to make auto_ptr_ref constructor
    >>> explicit. how I can "edit" that?

    >>
    >> See C:\Program Files\Microsoft Visual Studio 8\VC\include\memory.
    >>
    >> P.J. Plauger
    >> Dinkumware, Ltd.
    >> http://www.dinkumware.com

    >
    > I refuse to edit M$ header files


    They aren't really MS files. If you look at the end, it says Copyright P.J.
    Plauger :)

    >
    > How will it prevent future errors when I deploy the sources to other
    > sites or Visual C updates?


    I would make a copy of that file, edit it, and put it in directory earlier
    in the include search list.

    And then add this procedure to the installation instruction for my
    application.


    Bo Persson
     
    Bo Persson, Nov 27, 2006
    #10
  11. Diego Martins

    peter koch Guest

    Diego Martins skrev:
    > P.J. Plauger wrote:
    > > "Diego Martins" <> wrote in message
    > > > someone in this thread told to make auto_ptr_ref constructor explicit.
    > > > how I can "edit" that?

    > >
    > > See C:\Program Files\Microsoft Visual Studio 8\VC\include\memory.
    > >
    > > P.J. Plauger
    > > Dinkumware, Ltd.
    > > http://www.dinkumware.com

    >
    > I refuse to edit M$ header files
    >
    > How will it prevent future errors when I deploy the sources to other
    > sites or Visual C updates?
    >

    I agree it is far from an optimal solution, but editing the headerfile
    will discover your errors at compile-time. So redeploying your code
    should not cause any errors. If your code is to be edited by others,
    you could make a note about the patch.

    /Peter
     
    peter koch, Nov 27, 2006
    #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. Siemel Naran

    auto_ptr<Derived> to auto_ptr<Base>

    Siemel Naran, Jan 10, 2005, in forum: C++
    Replies:
    2
    Views:
    1,557
    Dave Rahardja
    Jan 11, 2005
  2. Replies:
    3
    Views:
    474
    Stefan Strasser
    May 12, 2005
  3. Replies:
    1
    Views:
    400
    Donovan Rebbechi
    May 13, 2005
  4. George2

    auto_ptr assignment compile error

    George2, Mar 30, 2008, in forum: C Programming
    Replies:
    0
    Views:
    443
    George2
    Mar 30, 2008
  5. Sousuke
    Replies:
    9
    Views:
    1,151
    Bart van Ingen Schenau
    Mar 16, 2010
Loading...

Share This Page