[Ranges] make_view: when will it be part of a release?
I recently had the need to produce from a vector<uint> a string representation (like for IPs) like "23.1.4.742.234.0". I thought that if only those were uints were strings I could boost::join them together. After a bit of searching the internet I found: make_view... very helpful, as indeed operating on iterators and containers only is a bit restrictive. So, first, I'd like to express my thanks for providing such helpful libraries (I love it how Boost.Bind and ASIO fit together, e.g.!). Great job everyone! Is there a better way to get to the string representation hinted to above? What I did is: #include <boost/view.hpp> // not yet part of Boost 1.37 // Helper to convert an uint to a std::string struct Stringer { std::string operator() (unsigned u) const { return boost::lexical_cast<std::string>(u); } }; boost::function<std::string(unsigned)> stringer = Stringer(); // way better than writing the loop by hand! std::string s = boost::join(boost::make_view(data_, stringer), "."); // Does not compile with gcc 4.2.1 // std::string s = boost::join(boost::make_view(data_, Stringer()), "."); Is there some existing class that makes my helper class Stringer unnecessary? (Can I use lexical_cast here w/o a helper class?) Is it possible to avoid putting the functor into a local Boost.Function variable? When will range_ex and make_view() be part of a Boost release? 1.38? (Please?) Best regards, and thank you -- Christoph Duelli
On Sunday 11 January 2009, Christoph Duelli wrote:
I recently had the need to produce from a vector<uint> a string representation (like for IPs) like "23.1.4.742.234.0".
You could also use Karma (part of the Spirit 2 library) for that job. See the included example. HTH, Chris #include <boost/assign/std/vector.hpp> // for 'operator+=()' #include <boost/spirit/include/karma.hpp> #include <cassert> #include <cstdlib> #include <vector> using namespace boost::assign; // bring 'operator+=()' into scope using namespace boost::spirit; using namespace boost::spirit::ascii; int main() { std::vector<int> v; v += 23, 1, 4, 742, 234, 0; std::string generated; bool success = karma::generate(std::back_inserter(generated), int_ % ".", // format description v // data ); assert(success && "23.1.4.742.234.0" == generated); return EXIT_SUCCESS; }
Chris Hoeppler wrote:
I recently had the need to produce from a vector<uint> a string representation (like for IPs) like "23.1.4.742.234.0".
You could also use Karma (part of the Spirit 2 library) for that job. See the included example. Thanks for the example. I thought that Karma might be used for that. (I try to stick to the "official boost releases", though. We can't update our customer's sites too often. Or even ask them to do it.)
I recently had the need to produce from a vector<uint> a string representation (like for IPs) like "23.1.4.742.234.0".
I thought that if only those were uints were strings I could boost::join them together.
After a bit of searching the internet I found: make_view... very helpful, as indeed operating on iterators and containers only is a bit restrictive.
So, first, I'd like to express my thanks for providing such helpful libraries (I love it how Boost.Bind and ASIO fit together, e.g.!). Great job everyone!
Is there a better way to get to the string representation hinted to above? What I did is:
#include <boost/view.hpp> // not yet part of Boost 1.37
// Helper to convert an uint to a std::string struct Stringer { std::string operator() (unsigned u) const { return boost::lexical_cast<std::string>(u); } };
boost::function<std::string(unsigned)> stringer = Stringer(); // way better than writing the loop by hand! std::string s = boost::join(boost::make_view(data_, stringer), "."); // Does not compile with gcc 4.2.1 // std::string s = boost::join(boost::make_view(data_, Stringer()), ".");
Is there some existing class that makes my helper class Stringer unnecessary? (Can I use lexical_cast here w/o a helper class?) Is it possible to avoid putting the functor into a local Boost.Function variable?
The Lambda lib is powerful in creating in-place unnamed function object, isn't it? Have you ever considered it?
When will range_ex and make_view() be part of a Boost release? 1.38? (Please?)
I also have interest to know the answer. B/Rgds Max
Max skrev:
I recently had the need to produce from a vector<uint> a string representation (like for IPs) like "23.1.4.742.234.0".
I thought that if only those were uints were strings I could boost::join them together.
After a bit of searching the internet I found: make_view... very helpful, as indeed operating on iterators and containers only is a bit restrictive.
So, first, I'd like to express my thanks for providing such helpful libraries (I love it how Boost.Bind and ASIO fit together, e.g.!). Great job everyone!
Is there a better way to get to the string representation hinted to above? What I did is:
#include <boost/view.hpp> // not yet part of Boost 1.37
// Helper to convert an uint to a std::string struct Stringer { std::string operator() (unsigned u) const { return boost::lexical_cast<std::string>(u); } };
boost::function<std::string(unsigned)> stringer = Stringer(); // way better than writing the loop by hand! std::string s = boost::join(boost::make_view(data_, stringer), "."); // Does not compile with gcc 4.2.1 // std::string s = boost::join(boost::make_view(data_, Stringer()), "."); Is there some existing class that makes my helper class Stringer unnecessary? (Can I use lexical_cast here w/o a helper class?) Is it possible to avoid putting the functor into a local Boost.Function variable?
The Lambda lib is powerful in creating in-place unnamed function object, isn't it? Have you ever considered it?
When will range_ex and make_view() be part of a Boost release? 1.38? (Please?)
I also have interest to know the answer.
The review is not scheduled exactly yet, but I'm the review manager ... I'm still awaiting some updates from Neil, but my guess is that the review will happen in february. -Thorsten
Hello Thorsten,
The review is not scheduled exactly yet, but I'm the review manager ... I'm still awaiting some updates from Neil, but my guess is that the review will happen in february.
Thanks for your information. B/Rgds Max
participants (5)
-
Chris Hoeppler -
Christoph -
Christoph Duelli
-
Max -
Thorsten Ottosen