[fusion] C++0x support?
Hello is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? If noone is up to adding support for this to fusion, my collegues and me would love to implement it. Thank you
Ein Held wrote:
Hello
is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? If noone is up to adding support for this to fusion, my collegues and me would love to implement it.
Wow, that's an offer I cannot refuse :-) Currently, John Fletcher is playing around with Variadic versions of Fusion tuples. It's a good idea to coordinate all efforts towards 0x. Tell me what you have in mind. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
on Tue Feb 17 2009, Ein Held <mrhelt-AT-yahoo.de> wrote:
Hello
is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? If noone is up to adding support for this to fusion, my collegues and me would love to implement it.
I'd be very happy for anyone who wants to push this stuff along to do so. Doug Gregor and I have proposed a couple of sessions for BoostCon where we get down and dirty with Boost code and C++0x features, to actually try to move some of these components along. So if those sessions are accepted, this will be very synergistic. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I'd be very happy for anyone who wants to push this stuff along to do so. Doug Gregor and I have proposed a couple of sessions for BoostCon where we get down and dirty with Boost code and C++0x features, to actually try to move some of these components along. So if those sessions are accepted, this will be very synergistic.
This may be a little off topic, but I am (along with a number of our students) trying building a set of C++0x libraries to experiment with the use of new language features and their impact library design. Part of this has been a small-adaptation of the MPL to variadic templates, which we're using to implement extended class and algorithm policies (along the lines Boost.Math). I think we have is an interesting start, but it's more like a first draft than anything else. Definitely still a learning processd, but like I said (and am now emphasizing) - experimental :) If anybody is interested, I would be more than happy to elaborate and/or open up the svn repo. Andrew Sutton andrew.n.sutton@gmail.com
On 02/18/09 20:06, Andrew Sutton wrote: [snip]
use of new language features and their impact library design. Part of this has been a small-adaptation of the MPL to variadic templates, which we're
Would the existing variadic template adaptation of mpl in the boost vault be helpful? It's in mpl-vt.zip here: http://www.boostpro.com/vault/index.php?&directory=variadic_templates The .zip contains: c++committee/VariadicTemplatesExperiences.txt indicating how complete the conversion was. I would be interested in helping. I'd alos like to figure out why at least some of mpl and fusion could be merged, in particular the tuple templates. There's an example tuple implementation in the .zip file which attempts this. I've got various other versions lying around which make use of the aligned_types.2.zip in the the same vault directory. The reason for those versions is to achieve the space saving required by some persons: http://lists.boost.org/Archives/boost/2002/01/23881.php However, since it used metaprogramming so much, I figured it couldn't compete with the boost_pp version currently in fusion (the fusion::vector).
Would the existing variadic template adaptation of mpl in the boost vault be helpful?
That's a good question. I had no idea that even existed. I'll take a look tomorrow morning. I'll also open up the repo for read access. I'm not sure that the goals for my project align perfectly with those of the Boost libraries so the design and implementation are a little different that those of the MPL. Besides, the students to do some of their own work :) why at least some of mpl and fusion could be merged, in
particular the tuple templates.
Being the author and maintainer of neither, I'm not sure I can postulate a good answer. Andrew Sutton andrew.n.sutton@gmail.com
On 02/19/09 08:59, Andrew Sutton wrote: [snip]
I'll also open up the repo for read access.
Good. I'll have a look and see if it might give me some ideas for how to improve what's in the vault. Of course I *should* provide a rationalization for the implementation, but I'm a bit lazy :(
I'm not sure that the goals for my project align perfectly with those of the Boost libraries so the design and implementation are a little different that those of the MPL.
One goal of the mpl design was to minimize compilation time since that can take so long with templates. The mpl book: http://www.boostpro.com/mplbook/ contains a whole appendix C on the subject. AFAICT, that's why mpl uses a lot of boost_pp programing. I'm guessing compilation time is not that important in your project. Besides, variadic templates are supposed to minimize compile times cause by defining variadic templates: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html
Besides, the students to do some of their own work :)
I'm not sure what you mean. Do you mean that it's possible that each student might have a different goal than Boost's; consequently, the design of their library might be different than mpl's? Could these students maybe provide a description of their goals and how they differ from mpl's (of course I'm not sure: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/index.html has what you'd consider a description of the mpl goals; hence, maybe there's no way the students could describe the differences.)
why at least some of mpl and fusion could be merged, in
particular the tuple templates.
Being the author and maintainer of neither, I'm not sure I can postulate a good answer.
Sure. I've been trying to figure an answer myself for quite some time. I just thought maybe another viewpoint might help.
Besides, the students to do some of their own work :)
I'm not sure what you mean. Do you mean that it's possible that each student might have a different goal than Boost's; consequently, the design of their library might be different than mpl's? Could these students maybe provide a description of their goals and how they differ from mpl's (of course I'm not sure:
http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/index.html
has what you'd consider a description of the mpl goals; hence, maybe there's no way the students could describe the differences.)\
That's not quite what I meant. I was trying to make the point that I'm hesitant about accepting contributions because the students' work is being evaluated as part of independent studies or undergraduate research. Hence, they need to do their own work. This will probably change towards the end of the summer. As for design goals... one of the nice things about running an experimental project is that you don't have to operate under the same constraints as established products. Outside of generic and usable (readable, writeable, and expressive?) the goals themselves are quiet fluid. Again, as the project becomes more established (and god forbid, we develop a user base :), we'll have to adopt a real philosophy. Andrew Sutton andrew.n.sutton@gmail.com
I'll also open up the repo for read access.
Good. I'll have a look and see if it might give me some ideas for how to improve what's in the vault. Of course I *should* provide a rationalization for the implementation, but I'm a bit lazy :(
I had to reshuffle some resources. The svn repository is here: http://tinyurl.com/awvksj, and its corresponding trac is here: http://tinyurl.com/c768jo. My lightweight variadic mpl is in core/include/origin. Send me an email off-list I botched the configuration and you can't get access. If, for some reason, you want to build parts of the library, you'll need an svn build of GCC. Enjoy :) Let me know if you have any questions. Andrew Sutton andrew.n.sutton@gmail.com
on Fri Feb 20 2009, Andrew Sutton <andrew.n.sutton-AT-gmail.com> wrote:
I'll also open up the repo for read access.
Good. I'll have a look and see if it might give me some ideas for how to improve what's in the vault. Of course I *should* provide a rationalization for the implementation, but I'm a bit lazy :(
I had to reshuffle some resources. The svn repository is here: http://tinyurl.com/awvksj, and its corresponding trac is here: http://tinyurl.com/c768jo. My lightweight variadic mpl is in core/include/origin. Send me an email off-list I botched the configuration and you can't get access.
If, for some reason, you want to build parts of the library, you'll need an svn build of GCC.
Enjoy :) Let me know if you have any questions.
Will you be at BoostCon this year? It would be great to have your participation in our C++0x-ification workshops. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Will you be at BoostCon this year? It would be great to have your participation in our C++0x-ification workshops.
I'd love to attend, but I doubt that I'll be able to wrangle enough funding to cover even a fraction of the cost. So, probably not. Andrew Sutton andrew.n.sutton@gmail.com
participants (5)
-
Andrew Sutton -
David Abrahams -
Ein Held -
Joel de Guzman -
Larry Evans