Hi Ion, A few things I noticed looking through move.hpp in the sandbox 1. you static_cast in one direction but reinterpret_cast in the other. Why? 2. I think move_iterator's operator-> return type is wrong; maybe make the pointer type be the underlying iterator type instead? 3. I think its operator[] can be wrong for some iterators. See http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/iterator_facade.html#... 4. bool-valued traits should be derived from an MPL integral constant, e.g. template <class T> struct is_whatever : mpl::bool_< (some compile-time expression ) > {}; Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams escribió:
Hi Ion,
A few things I noticed looking through move.hpp in the sandbox
1. you static_cast in one direction but reinterpret_cast in the other. Why?
A bug was reported for SunPro with static_cast producing an infinite loop: http://lists.boost.org/Archives/boost/2009/02/149069.php
2. I think move_iterator's operator-> return type is wrong; maybe make the pointer type be the underlying iterator type instead?
I'll try it.
3. I think its operator[] can be wrong for some iterators. See http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/iterator_facade.html#...
Ok, I'm quite lost to find a proper solution, what do you suggest?
4. bool-valued traits should be derived from an MPL integral constant, e.g.
template <class T> struct is_whatever : mpl::bool_< (some compile-time expression ) > {};
Ok, Best, Ion
on Mon Sep 07 2009, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:
David Abrahams escribió:
Hi Ion,
A few things I noticed looking through move.hpp in the sandbox
1. you static_cast in one direction but reinterpret_cast in the other. Why?
A bug was reported for SunPro with static_cast producing an infinite loop:
I don't think that's a good enough reason to have them be different. Yeah, we're over the line in forming these invalid references but at least I'd like to be able to point to the pointer round-tripping rules and say we got that part right. In this case we might even be better off with C-style casts.
3. I think its operator[] can be wrong for some iterators. See http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/iterator_facade.html#...
Ok, I'm quite lost to find a proper solution, what do you suggest?
You could always use iterator_adaptor to build this puppy :-) It solves this problem as well as possible. Otherwise, just return value_type instead of reference. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Mon Sep 07 2009, David Abrahams <dave-AT-boostpro.com> wrote:
Hi Ion,
A few things I noticed looking through move.hpp in the sandbox
Also, I wonder if the algorithms in move.hpp shouldn't use move_iterator and dispatch to the ones in std::? As it is, they'll miss optimizations that may be in the library such as loop unrolling, and this seems like a good opportunity to offload code and maintenance work. The rvalue-enabled libstdc++ has still further optimizations, e.g. using memcpy where with move_iterators wrapped around pointers to PODs, etc., but while that's an efficiency win, trying to do something like that would also increase your code size, so maybe you don't want to. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7 Sep 2009, at 22:56, David Abrahams wrote:
on Mon Sep 07 2009, David Abrahams <dave-AT-boostpro.com> wrote:
Hi Ion,
A few things I noticed looking through move.hpp in the sandbox
Also, I wonder if the algorithms in move.hpp shouldn't use move_iterator and dispatch to the ones in std::? As it is, they'll miss optimizations that may be in the library such as loop unrolling, and this seems like a good opportunity to offload code and maintenance work.
The rvalue-enabled libstdc++ has still further optimizations, e.g. using memcpy where with move_iterators wrapped around pointers to PODs, etc., but while that's an efficiency win, trying to do something like that would also increase your code size, so maybe you don't want to.
Very sorry I haven't looked at move.hpp, I'll try to if I had time. I'd hoped the move simulation would, in a compiler which supported everything natively, just use proper rvalue-references and the compiler's rvalue-aware standard library and containers, so it could be used just as a bridge until rvalue support was standard. Is that not the case? Chris
participants (3)
-
Christopher Jefferson -
David Abrahams -
Ion Gaztañaga