469,572 Members | 1,199 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,572 developers. It's quick & easy.

auto_ptr assignment crash with VC language extensions

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_blahblahp;

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

Nov 20 '06 #1
10 1684

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_blahblahp;

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

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

Nov 20 '06 #2
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_blahblahp;

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<Fooptr = new Foo;

will NOT work.

You need to do:

std::auto_ptr<Fooptr(new Foo);

Refer page 40 of C++ Standard Library by Josuttis for an explanation as
to the why.

Nov 20 '06 #3
"Diego Martins" <jo********@gmail.comwrote in message
news:11*********************@f16g2000cwb.googlegro ups.com...
>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_blahblahp;

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
Nov 20 '06 #4
VJ
Diego Martins wrote:
>
You can tell me to disable these damned extensions and stop
bothering....
format c:

and use anything else but windows
Nov 21 '06 #5

am******@gmail.com 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_blahblahp;

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

Nov 22 '06 #6

rd*****@gmail.com 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_blahblahp;

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<Fooptr = new Foo;

will NOT work.

You need to do:

std::auto_ptr<Fooptr(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

Nov 22 '06 #7
"Diego Martins" <jo********@gmail.comwrote in message
news:11*********************@k70g2000cwa.googlegro ups.com...
rd*****@gmail.com 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_blahblahp;

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<Fooptr = new Foo;

will NOT work.

You need to do:

std::auto_ptr<Fooptr(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
Nov 23 '06 #8

P.J. Plauger wrote:
"Diego Martins" <jo********@gmail.comwrote 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?

:(

Nov 27 '06 #9
Diego Martins wrote:
P.J. Plauger wrote:
>"Diego Martins" <jo********@gmail.comwrote 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

Nov 27 '06 #10

Diego Martins skrev:
P.J. Plauger wrote:
"Diego Martins" <jo********@gmail.comwrote 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

Nov 27 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

14 posts views Thread by Andrew | last post: by
10 posts views Thread by red floyd | last post: by
23 posts views Thread by Jeff | last post: by
18 posts views Thread by Dilip | last post: by
10 posts views Thread by dragoncoder | last post: by
9 posts views Thread by dragoncoder | last post: by
39 posts views Thread by Andre Siqueira | last post: by
4 posts views Thread by james.lawton | last post: by
17 posts views Thread by Ankur Arora | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.