Hi,
I copied the code and tried again, and find out that this 0xcccccccc
problem would still occur at debug build,
and when I switched to Release build, the 'b.ShowPtr()' gave a wrong
address.
But since this code is correct at your side, I think it's possibly because
the precompiled boost.python lib I linked to is not compatible with
something at my environment. [ vc2008 sp1 + python 2.5.4 +
boost_python-vc90-mt-1_36.dll ]
So I think I should compile the boost.python in my environment first then
try it again.
P.S.:
Maybe I went wrong with the shared_ptr in my design, please give me some
advice on my design:
I got a 'class Manager' which contains a std::set of shared_ptr<Entity>;
and 'class Entity' has a auto_ptr<StateMachine> as member
and 'class StateMachine' needs shared_ptr<Entity> as member variable to
access some functions outside.
So, in order to break cyclic reference, I make the StateMachine to own a
'shared_ptr<Entity> const&', I think it's kind of reasonable.
On Thu, Mar 12, 2009 at 5:50 PM, athor <thor...@gmail.com> wrote:
>
> Hi,
> I just tried your example and could not reproduce the "feature". I made a
> few minor modifications like fixing typos and adding a cout statement in
> the
> constructor of A but nothing that should affect the result.
>
> A few things that could cause you problems:
> * Passing shared_ptr by reference and keeping refs to shared_ptrs is just
> as
> bad as passing standard pointers. You never know when it's deallocated.
> Passing by value could help (as already mentioned).
>
> * auto_ptr is rather scary. It transfers the responsibility for
> deallocating
> the memory whenever it is copied. I have no idea what the effects could be
> in a python environment. I'd suggest using shared_ptr instead.
>
> Here's my code if you want to look for any differences:
> -----------------------------------------------------
> struct A
> {
> A()
> {
> cerr << "Creating A" << endl;
> }
> };
>
> class B
> {
> private:
> shared_ptr<A> const& m_ptr;
> public:
> B(shared_ptr<A> const& ptr):m_ptr(ptr)
> {
> cerr << "Creating B" << endl;
> cerr << m_ptr.get() << endl;
> }
>
> void ShowPtr() const
> {
> cout << m_ptr.get() << endl;
> }
> };
>
> BOOST_PYTHON_MODULE(pylib)
> {
>
> class_<B, auto_ptr <B> >("B", init<shared_ptr<A> const&>())
> .def("ShowPtr", &B::ShowPtr);
>
> class_<A, shared_ptr<A>, noncopyable >("A");
> }
> ----------------------------------------------------
> from pylib import *
> a = A() # Creating A
> b = B(a) # Creating B, 0xABCDE
> b.ShowPtr() # 0xABCDE
>
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22471472.html
> Sent from the Python - c++-sig mailing list archive at Nabble.com.
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
--
Time is mana, we must hurry
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
