What would happen if boost::shared_ptr is reset to an address in the stack
Hi, The following program runs well in my system. However, if I change 1 to 0, it will terminate at the line with "delete". Does this mean that boost::shared_ptr can tell if the pointer is from the stack or the heap and does different things based on where the pointer is from? Thanks, Peng #include <iostream> #include <boost/shared_ptr.hpp> int main() { #if 1//try change this to 0 int a[100]; boost::shared_ptr<int> p(a); std::cout << std::endl; #else int a[100]; delete a; // would terminate here std::cout << std::endl; #endif }
on Tue Oct 16 2007, "Peng Yu" <pengyu.ut-AT-gmail.com> wrote:
Hi,
The following program runs well in my system. However, if I change 1 to 0, it will terminate at the line with "delete". Does this mean that boost::shared_ptr can tell if the pointer is from the stack or the heap and does different things based on where the pointer is from?
No. The termination is just an expression of the fact that you invoked undefined behavior by passing an illegal argument to delete.
Thanks, Peng
#include <iostream> #include <boost/shared_ptr.hpp>
int main() { #if 1//try change this to 0 int a[100]; boost::shared_ptr<int> p(a); std::cout << std::endl; #else int a[100]; delete a; // would terminate here std::cout << std::endl; #endif }
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On 10/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Tue Oct 16 2007, "Peng Yu" <pengyu.ut-AT-gmail.com> wrote:
Hi,
The following program runs well in my system. However, if I change 1 to 0, it will terminate at the line with "delete". Does this mean that boost::shared_ptr can tell if the pointer is from the stack or the heap and does different things based on where the pointer is from?
No. The termination is just an expression of the fact that you invoked undefined behavior by passing an illegal argument to delete.
Thanks, Peng
#include <iostream> #include <boost/shared_ptr.hpp>
int main() { #if 1//try change this to 0 int a[100]; boost::shared_ptr<int> p(a); std::cout << std::endl; #else int a[100]; delete a; // would terminate here std::cout << std::endl; #endif }
I don't think my question was completely answered. Do you means reseting shared_ptr with an array from the stack is not defined? Or it is defined and shared_ptr can figure out it is from the stack and do not delete it? Thanks, Peng
reseting shared_ptr with an array from the stack is not defined? Or it is defined and shared_ptr can figure out it is from the stack and do not delete it?
Try to pass "a" to a boost::shared_ptr<int> that isn't on the stack and try it :) You may just be lucky this gets popped while "a" is still there. Is that your question?
From: "Peng Yu" <pengyu.ut@gmail.com> Reply-To: boost-users@lists.boost.org To: boost-users@lists.boost.org Subject: Re: [Boost-users] What would happen if boost::shared_ptr is resetto an address in the stack Date: Tue, 16 Oct 2007 14:26:33 -0500
On 10/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Tue Oct 16 2007, "Peng Yu" <pengyu.ut-AT-gmail.com> wrote:
Hi,
The following program runs well in my system. However, if I change 1 to 0, it will terminate at the line with "delete". Does this mean that boost::shared_ptr can tell if the pointer is from the stack or the heap and does different things based on where the pointer is from?
No. The termination is just an expression of the fact that you invoked undefined behavior by passing an illegal argument to delete.
Thanks, Peng
#include <iostream> #include <boost/shared_ptr.hpp>
int main() { #if 1//try change this to 0 int a[100]; boost::shared_ptr<int> p(a); std::cout << std::endl; #else int a[100]; delete a; // would terminate here std::cout << std::endl; #endif }
I don't think my question was completely answered. Do you means reseting shared_ptr with an array from the stack is not defined? Or it is defined and shared_ptr can figure out it is from the stack and do not delete it?
Thanks, Peng _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_________________________________________________________________ Get a FREE Web site and more from Microsoft Office Live Small Business! http://clk.atdmt.com/MRT/go/aub0930004958mrt/direct/01/
On 10/16/07, Mike Marchywka <marchywka@hotmail.com> wrote:
reseting shared_ptr with an array from the stack is not defined? Or it is defined and shared_ptr can figure out it is from the stack and do not delete it?
Try to pass "a" to a boost::shared_ptr<int> that isn't on the stack and try it :) You may just be lucky this gets popped while "a" is still there. Is that your question?
I'm not talking about whether shared_ptr is in the stack or not. I'm talking about 'a'. In my example, 'a' is in the stack, I pass its address to reset shared_ptr. I'm asking whether this is legal code, that is to ask whether the behavior is defined. Or the program does not crash is just because I'm lucky, but it may crash in other platform or for the binary code generated from other compiler?
on Tue Oct 16 2007, "Peng Yu" <pengyu.ut-AT-gmail.com> wrote:
On 10/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Tue Oct 16 2007, "Peng Yu" <pengyu.ut-AT-gmail.com> wrote:
Hi,
The following program runs well in my system. However, if I change 1 to 0, it will terminate at the line with "delete". Does this mean that boost::shared_ptr can tell if the pointer is from the stack or the heap and does different things based on where the pointer is from?
No. The termination is just an expression of the fact that you invoked undefined behavior by passing an illegal argument to delete.
Thanks, Peng
#include <iostream> #include <boost/shared_ptr.hpp>
int main() { #if 1//try change this to 0 int a[100]; boost::shared_ptr<int> p(a); std::cout << std::endl; #else int a[100]; delete a; // would terminate here std::cout << std::endl; #endif }
I don't think my question was completely answered. Do you means reseting shared_ptr with an array from the stack is not defined?
Yes, that's true unless you also supply a custom deleter that has legal semantics. "delete a" is illegal unless a is dynamically allocated. However, it's not what I mean. I mean that "delete a" is undefined when a is a stack array. It's even not legal when it's a heap array allocated via "a = new int[SIZE]"; for that you'd need "delete[] a" (which also doesn't work when a is a stack array). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Peng Yu:
I don't think my question was completely answered. Do you means reseting shared_ptr with an array from the stack is not defined? Or it is defined and shared_ptr can figure out it is from the stack and do not delete it?
It's undefined. shared_ptr cannot figure it out automatically. If you really need to store the address of a stack object in a (short-lived) shared_ptr, you need to tell it to not call 'delete' by using a null deleter. http://boost.org/libs/smart_ptr/sp_techniques.html#static
Peng Yu wrote:
Hi,
The following program runs well in my system. However, if I change 1 to 0, it will terminate at the line with "delete". Does this mean that boost::shared_ptr can tell if the pointer is from the stack or the heap and does different things based on where the pointer is from?
Thanks, Peng
Hi Peng, No, shared_ptr still calls delete on 'a', which is undefined behavior. Undefined behavior means just that: it is totally undefined what will happen. It could crash, or continue merrily along, or anything else. The following may show you what is going on better. If you put a breakpoint (for VS 7.1) in boost/checked_delete.hpp in the checked_delete(T * x) function, you'll see that it does call delete. (It will also call delete in your original function, it just does it when p goes out of scope, which is at the end of main.) #include <iostream> #include <boost/shared_ptr.hpp> int main() { int a[100]; boost::shared_ptr<int> p(a); p.reset(); // calls delete here std::cout << std::endl; } David
participants (5)
-
David Abrahams -
David Walthall -
Mike Marchywka -
Peng Yu -
Peter Dimov