Re: [C++-sig] why does the "shared_ptr const&" silently become 0xCCCCCCCC
Hi,Roman:
I have tried adding call policy on my constructor, but I'm really no good at
this.
I have tried all the combinations below but none of them work:
- init const& >()[with_custodian_and_ward_postcall<0, 2>
>()]
- init const& >()[with_custodian_and_ward_postcall<1, 2>
>()]
- init const& >()[return_internal_reference<1,
with_custodian_and_ward<1, 2> >()]
- init const& >()[return_internal_reference<1,
with_custodian_and_ward<0, 2> >()]
Could you give some more advice on this?
P.S.:
I cannot modify the code back to use shared_ptr by value here, I have to
break cyclic reference. And I think weak_ptr is no good idea, if I lock it
60 times per second for each object, I guess it would be an impact on
performance.
On Wed, Mar 11, 2009 at 2:19 PM, Roman Yakovenko
wrote:
> 2009/3/11 ZaeX :
> > Hi, All:
> >
> > I used a "shared_ptr const&" to store a ref of A in B;
> > Well, the constructor of B seems ok, the share_ptr seems to be well
> > initialized;
> > but after the constructor, I found the the pointer silently become
> > 0x
> >
> > / below are the simplified class
> > definitions
> > class A{};
> >
> > class B
> > {
> > private:
> >shared_ptr const& m_ptr;
> > public:
> >B(shared_ptr const& ptr):m_ptr(ptr) {cout< >void ShowPtr(cout< > }
> > /// below are my exporting code
> >
> > class_ >("B", init const&>())
> >.def("ShowPtr", &B::ShowPtr)
> > ;
> > class_, noncopyable >("A")
> > ;
> > /// below are python code
> > a = A()
> > b = B(a) #cout output the ptr of a
> > b.ShowPtr() #cout output 0x
> >
> >
> > I'm quite confused by the behaviors here. Could you tell me what goes
> wrong?
>
> You have to bind lifetime argument to the lifetime of the created
> object:
> http://www.boost.org/doc/libs/1_38_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
>
> Constructors also have call policies and you can use them.
>
> Anyway, you will save to yourself a lot of time, if you will use
> shared_ptr by value. I suggest you to change your code.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> ___
> 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
Re: [C++-sig] [c++-sig] Making a Python tuple from a Boost.Fusion sequence
It seems very useful to me.
By the way, is there a simple way to iterate through a fusion sequence or
transformation of it with a python iterator?
Luca.
2009/2/27 Bruno Lalande
> Hello,
>
> The topic below was opened in the Boost development mailing list,
> where it's been pointed out to me that it fits better here.
>
> You can also read the thread archive:
> http://thread.gmane.org/gmane.comp.lib.boost.devel/186573
>
> Regards
> Bruno
>
>
> -- Forwarded message --
>
>
> Hello,
>
> I have written a little function that converts any Boost.Fusion
> sequence into a Python tuple (boost::python::tuple). If a sub-sequence
> is nested in the sequence, the result will also be a nested tuple (for
> instance, boost::make_tuple(0, std::make_pair(1, 2), 3) will give (0,
> (1, 2), 3) in Python).
>
> The source code is attached to this mail.
>
> The principle is that any sequence previously adapted to Boost.Fusion
> will become a tuple in Python. So, by including the right
> boost/fusion/adapted/xxx header, one can convert a pair, a tuple, a
> boost::array, and obviously any of the sequences provided by
> Boost.Fusion. For example:
>
> #include
> #include
> #include
> #include
> #include "make_tuple_from_fusion_sequence.hpp"
>
> using namespace boost::python;
>
> tuple from_sequence()
> {
> return make_tuple_from_fusion(
> boost::fusion::make_vector(
> 1,
> std::make_pair("first", "second"),
> 2,
> boost::make_tuple('a', 'b', 'c'),
> 3
> )
> );
> }
>
> BOOST_PYTHON_MODULE(mymodule)
> {
> def("from_sequence", &from_sequence);
> }
>
>
> In Python we get:
>
> >>> import mymodule
> >>> mymodule.from_sequence()
> (1, ('first', 'second'), 2, ('a', 'b', 'c'), 3)
>
>
> Is there any interest in adding this function into Boost.Python? If
> yes, I can write the doc and tests, clean the source and maybe improve
> the implementation (for example, I feel that I could avoid the use of
> m_iteration with a better use of Boost.Fusion...).
>
>
> Regards
> Bruno
>
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
--
Ing. Luca Secchi
Ass.to Turismo, Artigianato e Commercio
Servizio amministrativo e legale, del bilancio e degli affari generali
tel. interno 4312
tel. esterno 070/606 4312
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] GSoC and py3k support for Boost.Python
Hi, I have posted this to Boost development mailling list before and many people suggested me to repost here, so I did. I'm a student who has finished SWIG's Python 3.0 support in GSoC 2008. I'd like to contribute my knowledge of Python 3 migration to Boost.Python, by implementing Python 3 support for it as a Google Summer of Code 2009 project. Finally the users of Boost.Python would get py3k support smoothly. Also, you may suggest other useful features that Boost.Python currently lack, for example thread safety and PyFinalize support. I would like to take it as part of this project if possible. Any comment is welcome. And it would be great if you are willing to mentor this project. Thanks! -- Haoyu Bai ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote: > > 1. Thread safety > > 2. PyFinalize support > > 3. Easier methods to write to_python/from_python converters > > 4. Python 3.0 support > > 5. Ability to extend the fundamental PyTypeObject used by boost.python > > Thanks! Seems there's a lot of interesting. So would anyone willing to > mentor this? Sadly, I suspect that finding a mentor will be difficult (perhaps even more difficult than the actual project). Off the top of my head, the following folks come to mind: - Dave Abrahams - Stefan Seefeld - Ralf Grosse-Kunstleve - Roman Yakovenko You might try contacting them off list or on c++-sig (cc'ed on this email). > Also thanks Ravi for a list of features that may be candidates for > this project. I will dive into Boost.Python source code to see more > about these. I did not mean to imply that the features I requested should be part of your GSoC. Thread safety & PyFinalize support would each be worth a GSoC project just by themselves, IMHO. If you will be tackling python 3.0 support, it might be possible to combine it with greater support for embedding python since much of the work in both aspects would be about wrapping python C API for C++ programmers. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] GSoC and py3k support for Boost.Python
Haoyu Bai wrote: Hi, I have posted this to Boost development mailling list before and many people suggested me to repost here, so I did. I'm a student who has finished SWIG's Python 3.0 support in GSoC 2008. I'd like to contribute my knowledge of Python 3 migration to Boost.Python, by implementing Python 3 support for it as a Google Summer of Code 2009 project. Finally the users of Boost.Python would get py3k support smoothly. Also, you may suggest other useful features that Boost.Python currently lack, for example thread safety and PyFinalize support. I would like to take it as part of this project if possible. Any comment is welcome. Everybody wins here. Clearly this needs to get done, the sooner the better, a GSoC project sounds like a great way to get it done, and you sound like a great candidate for the job. I'd set the goal to be py3k support for the current boost::python feature set, keeping the other feature requests in mind. Maybe you'll get lucky and get some of these in along the way. If you have time left over, you can tackle them directly. Just my two cents. And it would be great if you are willing to mentor this project. 1. What are the responsibilities of the mentor(s)? 2. Do you need an individual mentor? Would a small group do? Would the general support of the mailing list work? -t ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] del dict[key] equivalent ?
Hi, I'm looking for a function in boost python ( C++ side ) to do the equivalent of del dict[key] but i can't find it . Thank you very much -- View this message in context: http://www.nabble.com/del-dict-key--equivalent---tp22462620p22462620.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
Re: [C++-sig] del dict[key] equivalent ?
William Marié wrote: Hi, I'm looking for a function in boost python ( C++ side ) to do the equivalent of del dict[key] but i can't find it . Thank you very much I think you want: boost::python::object obj; obj["where"].del(); -t ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
On 11 Mar 2009 at 13:42, Ravi wrote: > On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote: > > > 1. Thread safety > > > 2. PyFinalize support > > > 3. Easier methods to write to_python/from_python converters > > > 4. Python 3.0 support > > > 5. Ability to extend the fundamental PyTypeObject used by boost.python My thread safety patch is still working to my knowledge. It sure would be lovely to have it officially integrated. I'd also like to see PyFinalize working though maybe not "complete" in the sense of a total cleanup (just "good enough"). I would say that any GSoC project should choose *one* of the above rather than try combining them. Better to do one thing well and in stages than many things at once (unless you have loads of spare time!). I have been out of commission development-wise during the last few years as I have been undertaking some very time consuming academic study - hence I have been very quiet on here. However, I finally become free come this June and at long, long last I finally can return to my own self-directed study (but now I have a whole pile of bits of paper to officially say I can do what I was already capable of). I will certainly be updating my TnFOX library for sure anyway, and that means fresh Python bindings. > > Thanks! Seems there's a lot of interesting. So would anyone willing to > > mentor this? > > Sadly, I suspect that finding a mentor will be difficult (perhaps even more > difficult than the actual project). Off the top of my head, the following > folks come to mind: > - Dave Abrahams > - Stefan Seefeld > - Ralf Grosse-Kunstleve > - Roman Yakovenko > You might try contacting them off list or on c++-sig (cc'ed on this email). It's not /quite/ as easy as that ... Google want a mentoring organisation rather than just a mentor and it has to be an approved one. I could volunteer as mentor but I wouldn't qualify as I don't come with an organisation attached. I'd need an approved organisation to adopt me. > I did not mean to imply that the features I requested should be part of your > GSoC. Thread safety & PyFinalize support would each be worth a GSoC project > just by themselves, IMHO. If you will be tackling python 3.0 support, it > might > be possible to combine it with greater support for embedding python since > much > of the work in both aspects would be about wrapping python C API for C++ > programmers. As mentioned before, thread safety is actually fairly trivial as all the required work is already done. There is certainly some work involved in writing a test suite and making my patch much more generic as my patch was specifically designed to be diff-friendly to any Boost alterations, and it doesn't make for good code. I would be happy to mentor this project if we can find an approved mentoring organisation to adopt me. It certainly would be a good GSoC for a student programmer. PyFinalize() is likely just a hard slog in catching all the code paths you wouldn't expect. It's harder than thread safety, but doable as a GSoc. Adding Python 3.0 support ... I am afraid I have no idea as I've been out of the coding scene for two years now, but it does sound big and complex. But it's something I'm interested in though I'd be not much use as a mentor except as in general Boost.Python programming. So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't start mentoring till the start of June as I have my final project due then. But that fits the GSoC timetable just perfect. If you want to know more about my suitability, search this mailing list. HTH, Niall ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
I should add that the deadline for this appears to be tomorrow (the 12th). Niall On 11 Mar 2009 at 20:50, Niall Douglas wrote: > On 11 Mar 2009 at 13:42, Ravi wrote: > > > On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote: > > > > 1. Thread safety > > > > 2. PyFinalize support > > > > 3. Easier methods to write to_python/from_python converters > > > > 4. Python 3.0 support > > > > 5. Ability to extend the fundamental PyTypeObject used by boost.python > > My thread safety patch is still working to my knowledge. It sure > would be lovely to have it officially integrated. I'd also like to > see PyFinalize working though maybe not "complete" in the sense of a > total cleanup (just "good enough"). > > I would say that any GSoC project should choose *one* of the above > rather than try combining them. Better to do one thing well and in > stages than many things at once (unless you have loads of spare > time!). > > I have been out of commission development-wise during the last few > years as I have been undertaking some very time consuming academic > study - hence I have been very quiet on here. However, I finally > become free come this June and at long, long last I finally can > return to my own self-directed study (but now I have a whole pile of > bits of paper to officially say I can do what I was already capable > of). I will certainly be updating my TnFOX library for sure anyway, > and that means fresh Python bindings. > > > > Thanks! Seems there's a lot of interesting. So would anyone willing to > > > mentor this? > > > > Sadly, I suspect that finding a mentor will be difficult (perhaps even more > > difficult than the actual project). Off the top of my head, the following > > folks come to mind: > > - Dave Abrahams > > - Stefan Seefeld > > - Ralf Grosse-Kunstleve > > - Roman Yakovenko > > You might try contacting them off list or on c++-sig (cc'ed on this email). > > It's not /quite/ as easy as that ... Google want a mentoring > organisation rather than just a mentor and it has to be an approved > one. I could volunteer as mentor but I wouldn't qualify as I don't > come with an organisation attached. I'd need an approved organisation > to adopt me. > > > I did not mean to imply that the features I requested should be part of > > your > > GSoC. Thread safety & PyFinalize support would each be worth a GSoC project > > just by themselves, IMHO. If you will be tackling python 3.0 support, it > > might > > be possible to combine it with greater support for embedding python since > > much > > of the work in both aspects would be about wrapping python C API for C++ > > programmers. > > As mentioned before, thread safety is actually fairly trivial as all > the required work is already done. There is certainly some work > involved in writing a test suite and making my patch much more > generic as my patch was specifically designed to be diff-friendly to > any Boost alterations, and it doesn't make for good code. I would be > happy to mentor this project if we can find an approved mentoring > organisation to adopt me. It certainly would be a good GSoC for a > student programmer. > > PyFinalize() is likely just a hard slog in catching all the code > paths you wouldn't expect. It's harder than thread safety, but doable > as a GSoc. > > Adding Python 3.0 support ... I am afraid I have no idea as I've been > out of the coding scene for two years now, but it does sound big and > complex. But it's something I'm interested in though I'd be not much > use as a mentor except as in general Boost.Python programming. > > So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't > start mentoring till the start of June as I have my final project due > then. But that fits the GSoC timetable just perfect. > > If you want to know more about my suitability, search this mailing > list. > > HTH, > Niall > > > > ___ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [c++-sig] Making a Python tuple from a Boost.Fusion sequence
> By the way, is there a simple way to iterate through a fusion sequence or > transformation of it with a python iterator? Do you mean making it an indexing suite, like Boost.Python does for vectors and maps? I guess it would be possible by using the indexing_suite base class (never did that before though) but __setitem__ and __delitem__ operations could obviously not be defined since the structure of a fusion sequence is fixed. Bruno ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] why does the "shared_ptr const&" silently become 0xCCCCCCCC
2009/3/11 ZaeX :
> Hi,Roman:
>
> I have tried adding call policy on my constructor, but I'm really no good at
> this.
> I have tried all the combinations below but none of them work:
>
> init const& >()[with_custodian_and_ward_postcall<0, 2> >()]
> init const& >()[with_custodian_and_ward_postcall<1, 2> >()]
> init const& >()[return_internal_reference<1,
> with_custodian_and_ward<1, 2> >()]
> init const& >()[return_internal_reference<1,
> with_custodian_and_ward<0, 2> >()]
>
> Could you give some more advice on this?
> P.S.:
> I cannot modify the code back to use shared_ptr by value here, I have to
> break cyclic reference. And I think weak_ptr is no good idea, if I lock it
> 60 times per second for each object, I guess it would be an impact on
> performance.
I don't know for sure, how to solve this problem. I can propose
work-around, which may be will work for you.
In your case, you have to keep shared_ptr somewhere, until instance
of B will die. So, you already do some kind of memory management.
I suggest you to change your code as following:
struct no_delete_a{
void operator(A*){}
};
class A{};
class B
{
private:
shared_ptr const m_ptr;
public:
B(shared_ptr const& ptr):m_ptr(ptr.get(), no_delete_a() )
{cout
