auto_ptr assignment crash with VC language extensions

[Diego Martins]

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

 

[amparikh]

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.

 

[rdilipk]

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.

 

[P.J. Plauger]

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

 

[VJ]

You can tell me to disable these damned extensions and stop
bothering....

format c:

and use anything else but windows

 

[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]

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

 

[P.J. Plauger]

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

 

[Diego Martins]

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?

 

[Bo Persson]

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

 

[peter koch]

Diego Martins skrev:

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