[RangeEx] Range & RangeEx
RangeEx appears to have the functionality I'm seeking, which is the std algorithms overloaded for ranges, but there's few things I'm not clear about. I've downloaded the range_ex.zip archive from the vault, but I'm not clear if it replaces or extends Boost.Range. Am I now able to write things like #include <vector> #include <iostream> #include <iterator> #include <boost/range.hpp> void f( vector<int> const & v ) { using namespace std; using namespace boost; copy( v, ostream_iterator<int>( cout, " " ); }
On Fri, Sep 12, 2008 at 1:13 PM, Robert Jones <robertgbjones@gmail.com>wrote:
RangeEx appears to have the functionality I'm seeking, which is the std algorithms overloaded for ranges, but there's few things I'm not clear about.
I've downloaded the range_ex.zip archive from the vault, but I'm not clear if it replaces or extends Boost.Range. Am I now able to write things like
I intend the Boost.RangeEx proposal to replace Boost.Range.
#include <vector> #include <iostream> #include <iterator> #include <boost/range.hpp>
void f( vector<int> const & v ) { using namespace std; using namespace boost; copy( v, ostream_iterator<int>( cout, " " ); }
This sort of thing should work, but of course it's missing closing parenthesis as posted. If you have any problems at all please let me know so that I can remedy them. I'm not getting much feedback suggesting bugs, but I am getting some feedback suggesting possible improvements to performance particularly with respect to the range adaptors and chained range algorithms. I hope this helps, Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Sep 12, 2008 at 1:28 PM, Neil Groves <neil@grovescomputing.com> wrote:
This sort of thing should work, but of course it's missing closing parenthesis as posted.
So it is - no worries, that wasn't real code, just text in an email. My ignorance is a little more basic I'm afraid, more to do with the mechanics of 'installing' range_ex. If I take the zip from the vault and unzip in the same directory as my client code I end up with Range_Ex directory, and the path to range.hpp is Range_Ex/boost/range/range.hpp whereas my client code has an include directive of #include "boost/range.hpp" so using a command line of g++ -IRange_Ex mycode.cpp doesn't find the range_ex range.hpp header. Is this how I'm supposed to be doing it? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org
On Fri, Sep 12, 2008 at 1:41 PM, Robert Jones <robertgbjones@gmail.com>wrote:
On Fri, Sep 12, 2008 at 1:28 PM, Neil Groves <neil@grovescomputing.com> wrote:
This sort of thing should work, but of course it's missing closing parenthesis as posted.
So it is - no worries, that wasn't real code, just text in an email.
My ignorance is a little more basic I'm afraid, more to do with the mechanics of 'installing' range_ex.
I am not aware of an official procedure for installing libraries from the Vault. So I just made up my own for Boost.RangeEx. What I do is: 1. rename the boost/range folder to boost/_range. 2. copy the range_ex code into the boost folder so it becomes the boost/range library that is found when building. It isn't possible to have both versions in the same application since this would violate the One Definition Rule. Once you have done this you should not need to set any additional compile switches or adjust anything else in your build. Of course, once the Boost.RangeEx has been reviewed and hopefully accepted it'll become part of Boost. This works for me with g++ 4.4 and MSVC 8 and 9
If I take the zip from the vault and unzip in the same directory as my client code I end up with Range_Ex directory, and the path to range.hpp is
Range_Ex/boost/range/range.hpp
whereas my client code has an include directive of
#include "boost/range.hpp"
so using a command line of
g++ -IRange_Ex mycode.cpp
doesn't find the range_ex range.hpp header.
Is this how I'm supposed to be doing it?
Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Sep 12, 2008 at 1:52 PM, Neil Groves <neil@grovescomputing.com> wrote:
I am not aware of an official procedure for installing libraries from the Vault. So I just made up my own for Boost.RangeEx. What I do is:
Ok that's great. It's a little more 'homespun' than I'd thought, but as long as I know it's not meant to just work out-of-the-box I can muddle through. If fact I don't have write access to the existing Boost include files, hence I need to use the compile line argument - but's that my problem! One other point - the header files seem to support far more algorithms than the documentation suggests. Is it just that the docs lag behind somewhat? - Rob.
On Fri, Sep 12, 2008 at 2:08 PM, Robert Jones <robertgbjones@gmail.com>wrote:
On Fri, Sep 12, 2008 at 1:52 PM, Neil Groves <neil@grovescomputing.com> wrote:
I am not aware of an official procedure for installing libraries from the Vault. So I just made up my own for Boost.RangeEx. What I do is:
Ok that's great. It's a little more 'homespun' than I'd thought, but as long as I know it's not meant to just work out-of-the-box I can muddle through. If fact I don't have write access to the existing Boost include files, hence I need to use the compile line argument - but's that my problem!
One other point - the header files seem to support far more algorithms than the documentation suggests. Is it just that the docs lag behind somewhat?
Yes the docs still need to be updated. I really must get that sorted out soon. I appreciate that the lag in documentation is rather pants. Sorry, Neil Groves
- Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Sep 12, 2008 at 2:11 PM, Neil Groves <neil@grovescomputing.com> wrote:
Yes the docs still need to be updated. I really must get that sorted out soon. I appreciate that the lag in documentation is rather pants.
Sorry, Neil Groves
No worries, :), I'm just glad you do it at all! - Rob.
I'm reading algorithm.hpp. I'm puzzled about one thing. There are overloads of lots of algs, such as find. 1 template<typename Rng,typename Val> inline BOOST_DEDUCED_TYPENAME boost::range_iterator<Rng>::type find(Rng & rng,Val const & val) { return std::find(boost::begin(rng),boost::end(rng),val); } 2 template<typename Rng,typename Val> inline BOOST_DEDUCED_TYPENAME boost::range_iterator<const Rng>::type find(Rng const & rng,Val const & val) { return std::find(boost::begin(rng),boost::end(rng),val); } I'm puzzled what's different between 1, where Rng is "const T", vs 2, where Rng is "T"? In other words, why do we need both? The only thing that seems different is "boost::begin(rng)", but that's already overloaded for const.
AMDG Neal Becker wrote:
I'm reading algorithm.hpp. I'm puzzled about one thing.
There are overloads of lots of algs, such as find.
1 template<typename Rng,typename Val> inline BOOST_DEDUCED_TYPENAME boost::range_iterator<Rng>::type find(Rng & rng,Val const & val) { return std::find(boost::begin(rng),boost::end(rng),val); }
2 template<typename Rng,typename Val> inline BOOST_DEDUCED_TYPENAME boost::range_iterator<const Rng>::type find(Rng const & rng,Val const & val) { return std::find(boost::begin(rng),boost::end(rng),val); }
I'm puzzled what's different between 1, where Rng is "const T", vs 2, where Rng is "T"? In other words, why do we need both? The only thing that seems different is "boost::begin(rng)", but that's already overloaded for const.
If only the Rng& version were provided it would be impossible to pass a rvalue range to find. If only the const Rng& version were provided, we would always add const even when it isn't needed (I'm not sure that this matters for find, since it is a non-mutating algorithm, though) In Christ, Steven Watanabe
If only the Rng& version were provided it would be impossible to pass a rvalue range to find. If only the const Rng& version were provided, we would always add const even when it isn't needed (I'm not sure that this matters for find, since it is a non-mutating algorithm, though)
The Rng& version is needed because if you pass in a mutable range, you may want a mutable iterator as return value. Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229
on Sat Sep 13 2008, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
Neal Becker wrote:
I'm reading algorithm.hpp. I'm puzzled about one thing.
There are overloads of lots of algs, such as find. 1 template<typename Rng,typename Val> inline BOOST_DEDUCED_TYPENAME boost::range_iterator<Rng>::type find(Rng & rng,Val const & val) { return std::find(boost::begin(rng),boost::end(rng),val); }
2 template<typename Rng,typename Val> inline BOOST_DEDUCED_TYPENAME boost::range_iterator<const Rng>::type find(Rng const & rng,Val const & val) { return std::find(boost::begin(rng),boost::end(rng),val); }
I'm puzzled what's different between 1, where Rng is "const T", vs 2, where Rng is "T"? In other words, why do we need both? The only thing that seems different is "boost::begin(rng)", but that's already overloaded for const.
If only the Rng& version were provided it would be impossible to pass a rvalue range to find. If only the const Rng& version were provided, we would always add const even when it isn't needed (I'm not sure that this matters for find, since it is a non-mutating algorithm, though)
FWIW, the property map version of find doesn't have this problem. Property maps have the potential to eliminate lots of ugliness associated with const/mutable accesses. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Sep 12, 2008 at 1:52 PM, Neil Groves <neil@grovescomputing.com> wrote:
What I do is:
1. rename the boost/range folder to boost/_range. 2. copy the range_ex code into the boost folder so it becomes the boost/range library that is found when building.
Looking at this in a little more detail, I notice you rename boost/range, but not boost/range.hpp, so I presume boost/range.hpp is unchanged in Range_Ex, and hence not even present in the zip? - Rob.
On Fri, Sep 12, 2008 at 2:13 PM, Robert Jones <robertgbjones@gmail.com>wrote:
On Fri, Sep 12, 2008 at 1:52 PM, Neil Groves <neil@grovescomputing.com> wrote:
What I do is:
1. rename the boost/range folder to boost/_range. 2. copy the range_ex code into the boost folder so it becomes the boost/range library that is found when building.
Looking at this in a little more detail, I notice you rename boost/range, but not boost/range.hpp, so I presume boost/range.hpp is unchanged in Range_Ex, and hence not even present in the zip?
The boost/range.hpp I have not edited, simply because I didn't need to inorder to fully test the work I have been doing. I believe the boost/range.hpp will forward to a variety of files. I have to confess that I have not tested using the boost/range.hpp include. Please let me know how it goes. It is something I should be supporting. I personally try to include files more specifically by including boost/range/... Neil Groves
- Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Arno Schödl -
David Abrahams -
Neal Becker -
Neil Groves -
Robert Jones -
Steven Watanabe