使用VC语言扩展的auto_ptr分配崩溃 [英] auto_ptr assignment crash with VC language extensions
问题描述
我在使用auto_ptr<>
和VC 8.0编译代码时发现了一个严重的问题
考虑某种create（）函数
blahblah * create（）{return new blahblah; }
和漂亮的auto_ptr
auto_ptr< base_blahblahp;
int main（）{
....
p.reset（create（））;
//像往常一样使用p我们将免于泄漏:)
}
但如果我们将该行更改为
p = create（）;
WILL在VC 8上编译并可能引发访问冲突异常
您可以告诉我禁用这些该死的扩展并停止
烦恼....
哇，我多么希望..当然我不能禁用它们，因为许多Windows
标头取决于启用此功能： - （
是否有任何实用的方法可以摆脱这种情况？它更容易毁掉
a程序......
多么诅咒的延伸嘿？:)
谢谢
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_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
推荐答案
Diego Martins写道：
Diego Martins wrote:
我在使用auto_ptr<>
和VC 8.0编译代码时发现了一个严重的问题。
考虑某种create（）函数
blahblah * create（）{return new blahblah; }
和漂亮的auto_ptr
auto_ptr< base_blahblahp;
int main（）{
...
p.reset（create（））;
//像往常一样使用p我们将成为没有泄漏:)
}
但如果我们将该行更改为
p = create（）;
WILL在VC 8上编译并可能引发访问冲突异常
您可以告诉我禁用这些该死的扩展并停止
困扰....
哇，我多么希望..当然我不能禁用它们因为很多Windows
标头依赖于此功能启用:-(
有没有任何实用的方法可以摆脱这个？它更容易毁掉
a程序......
这个该死的延伸嘿嘿？:)
谢谢
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_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
复制构造函数可能有问题，我不确定但是
那么你可以禁用/ Za的语言扩展，但我不认为这与
有关。
话虽如此，如果你像这样直接初始化它会怎么样。 />
auto_ptr< sBasep（creates（））;
我认为重置是确保正确的指针是
初始化为auto_ptr对象的成员。
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.
Diego Martins写道：
Diego Martins wrote:
I在使用auto_ptr<>
和VC 8.0编译代码时发现了一个严重的问题
考虑某种create（）函数
blahblah * create（）{return new blahblah; }
和漂亮的auto_ptr
auto_ptr< base_blahblahp;
int main（）{
...
p.reset（create（））;
//像往常一样使用p我们将成为没有泄漏:)
}
但如果我们将该行更改为
p = create（）;
WILL在VC 8上编译并可能引发访问冲突异常
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
几天我有完全相同的问题前。如果你搜索档案
我的句柄（rdilipk）你会找到相关的帖子。 Victor Bazarov
在对Dinkumware进行一些研究后发布了一个冗长的解释
实现。
基本上这不是VC8特有的问题。你*不能*使用普通指针初始化
auto_ptr对象，使用赋值语法为
你这样做。
std： ：auto_ptr< Fooptr = new Foo;
将无效。
您需要这样做：
std :: auto_ptr< Fooptr（new Foo）;
请参阅Josuttis的C ++标准库第40页，作为解释为
为什么。
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.
" Diego Martins" < jo ******** @ gmail.com写信息
新闻：11 ********************* @ f16g2000cwb.googlegro ups.com ...
"Diego Martins" <jo********@gmail.comwrote in message
news:11*********************@f16g2000cwb.googlegro ups.com...
>我在使用auto_ptr<>
编译代码时发现了一个严重的问题VC 8.0
考虑某种create（）函数
blahblah * create（）{return new blahblah; }
和漂亮的auto_ptr
auto_ptr< base_blahblahp;
int main（）{
...
p.reset（create（））;
//像往常一样使用p我们将成为没有泄漏:)
}
但如果我们将该行更改为
p = create（）;
WILL在VC 8上编译并可能引发访问冲突异常
您可以告诉我禁用这些该死的扩展并停止
困扰....
哇，我多么希望..当然我不能禁用它们因为很多Windows
标头依赖于此功能启用:-(
有没有任何实用的方法可以摆脱这个？它更容易毁掉
a程序......
这个该死的扩展名是什么？:)
>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? :)
你可以禁用这个扩展名通过使auto_ptr_ref构造函数
显式，IIRC。 （这更像是编译器检查失败而不是故意尝试在库中扩展auto_ptr。）
PJ Plauger
Dinkumware，Ltd。
http://www.dinkumware.com
这篇关于使用VC语言扩展的auto_ptr分配崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
