Subject: Re: [boost] [phoenix] Implementing phoenix::make_shared<T>(...)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-06-29 09:43:53
On Wednesday, June 29, 2011 02:31:56 PM you wrote:
> Hi, Thomas and other Boosters!
> I promised on #boost yesterday to try implementing make_shared<T>(...) for
> Boost.Phoenix. Well, I got the first version working, it was mostly a
> find-and-replace task to the existing phoenix::new_<T>(...) implementation.
> I put the modifications to the current Phoenix trunk version here:
Nice start, thanks for pulling that of. I think this will be a valuable
> First, the questions, then some remarks and ideas for improvement:
> 1) If I've understood correctly, you and Hartmut used Wave to generate the
> preprocessed headers. What command did you use for them? (Currently, I just
> added a false condition to the preprocessor #if's to fallback to the
> Boost.Preprocessor iteration.)
That is good enough for now.
For future reference, you need to change your working directory to
libs/phoenix/preprocess, adapt the wave.cfg to point to your correct system
headers, then run the wave tool. I usually invoke it with:
$ for i in `seq 10 10 50`; do wave -o - -DBOOST_PHOENIX_LIMIT=$i
> 2) Where would you put the new make_shared stuff? The first implementation
> resides below boost/phoenix/object, but I think we should use another
> directory for all the smart pointer stuff - especially if we're trying to
> support all of (boost|std::tr1|std)! How about the following pattern?
> boost/phoenix/smart_ptr/... for all Boost.SmartPtr support stuff
> boost/phoenix/tr1/... for TR1 support (alternatively,
> boost/phoenix/std/tr1) boost/phoenix/std/... for C++0x (with #ifdef guards
> checking against std version)
I just discussed this matter with Joel this morning. We came to the conclusion
we need to introduce the namespace boost::phoenix::std and maybe also
phoenix::std::tr1 where this make_shared and friend functions would live.
Additionnally the other stuff currently living in the boost::phoenix namespace
that belong to the STL module would need to be moved there.
The same will be done with the (currently undocumented) fusion namespace.
With that being said, I think there would need to be three make_shared_ptr
- boost::phoenix::make_shared_ptr // using boost::shared_ptr
- boost::phoenix::std::tr1::make_shared_ptr // using std::tr1::shared_ptr
- boost::phoenix::std::make_shared_ptr // using std::shared_ptr
and the same for the other flavours of smart pointers.
I think it makes sense to add a smart_ptr module. Thoughts?
> 3) To my pleasant surprise, I didn't need any hacks to create a functor of
> using a Phoenix construct like phx::make_shared<Child>(args), where Child
> inherits Parent. You'll find a working example in
> https://gist.github.com/1051564. Nevertheless, I think there's also a need
> for implementing the Phoenix versions of static_pointer_cast etc.
Yup. That makes sense. I am thinking that it might be possible to add this
behaviour to the already existing cast versions of phoenix.
> 4) Another feature worth implementing might be phoenix::make_unique<T>(...).
Which would construct a std::unique_ptr? Yes, as noted above i think it makes
sense to add lazy make_* functions for all standard and boost pointers
> 5) We also discussed about an API that allows you to make "deep" copies of
> pointed objects in Phoenix. I think it might already work using something
> if x is of type T, or
> if p points to T.
Right this will work. What i had in mind was an API that would allow to omit T
completely. But this would only make sense if new_ and friends will support it
too. Anyway, let's get the basic functionality that is symmetric to construct
and new_ inside trunk first and decide upon further actions later.
> 6) When we get this far, I'll promise help in the documentation effort too.
We definitely will, and I will get back to your offer :P
Besides documentation we also need unit tests ;)
Thanks for the work.