- Boost - lists.boost.org

[future] @Tom -> review result?
by Tom Brinkman 14 Feb '09

14 Feb '09

>> One last sentence, we should not forget that the interface of the future >> library has already gone through the standard committe. It should work the other way around. Are we going to start picking through libraries that have already been standardized in Cx0 and begin adding them to boost? Not a good idea in my view. The interface is already available. Use it. But why go to the trouble of adding it as a top-level boost library to a library. What is so special about the futures library? Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that. Considering the way this review has floundered at this point, that is the best outcome that I can see. If we put it up for review again as top-level boost library, it will need to be fully documented, with samples and test cases. The library has been on the review boards for over a year. Plenty of time for these to have been added. //Tom

6 6

problems with iterator_adaptor after update to 1_38_0
by Oliver Kullmann 13 Feb '09

13 Feb '09

Hello, in the process of updating from 1_34_1 to 1_38_0 I get a lot of compiler errors all related to boost/iterator/iterator_adaptor.hpp; it's quite some time ago that I've written the code, and the compiler messages are cryptic as ever (using gcc version 4.12.0). The error messages all look like /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Boost/1_38_0+4.1.2/include/boost/iterator/iterator_adaptor.hpp:358: error: no match for ‘operator-’ in ‘((const boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries, boost::use_default, const OKlib::SATCompetition::SuperSeries&, boost::use_default>*)y)->boost::iterator_adaptor<Derived, Base, Value, Traversal, Reference, Difference>::base [with Derived = boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, Base = std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, Value = const OKlib::SATCompetition::SuperSeries, Traversal = boost::use_default, Reference = const OKlib::SATCompetition::SuperSeries&, Difference = boost::use_default]() - ((const boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries, boost::use_default, const OKlib::SATCompetition::SuperSeries&, boost::use_default>*)this)->boost::iterator_adaptor<boost::transform_iterator<FunctionHandling::First<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, boost::use_default, boost::use_default>, std::_Rb_tree_const_iterator<std::pair<const OKlib::SATCompetition::SuperSeries, OKlib::SATCompetition::SetResultNodesP*> >, const OKlib::SATCompetition::SuperSeries, boost::use_default, const OKlib::SATCompetition::SuperSeries&, boost::use_default>::m_iterator’ /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_bvector.h:182: note: candidates are: ptrdiff_t std::operator-(const std::_Bit_iterator_base&, const std::_Bit_iterator_base&) I believe there was a discussion on the boost iterator library lately, but I don't think there was a clear outcome. So perhaps somebody, just be seeing this, can guess what the problem could be. It is not yet clear to me where the above error really comes from (some templates and some macros are in the way), but perhaps something doesn't work with the following convenience adaptors: template <class Range> struct RangeFirstConst { typedef typename boost::range_const_iterator<Range>::type iterator; typedef typename IteratorFirst<iterator>::type iterator_first; typedef boost::iterator_range<iterator_first> type; }; template <class Range> struct RangeFirstMutable { typedef typename boost::range_iterator<Range>::type iterator; typedef typename IteratorFirstMutable<iterator>::type iterator_first; typedef boost::iterator_range<iterator_first> type; }; template <class Range> typename RangeFirstConst<Range>::type range_first(const Range& r) { typedef RangeFirstConst<Range> range_first_const; typedef typename range_first_const::type range; typedef typename range_first_const::iterator_first iterator; using boost::begin; using boost::end; return range(iterator(begin(r)), iterator(end(r))); } template <class Range> typename RangeFirstMutable<Range>::type range_first(Range& r) { typedef RangeFirstMutable<Range> range_first_mutable; typedef typename range_first_mutable::type range; typedef typename range_first_mutable::iterator_first iterator; using boost::begin; using boost::end; return range(iterator(begin(r)), iterator(end(r))); } range_first(range) is supposed to take a range over pairs, and return a range of the first components of the pairs. Would be glad about any comments. Oliver

2 1

Happy 100 libraries on Boost
by vicente.botet 13 Feb '09

13 Feb '09

Hi, Every body have remarqued that there are more and more libraries on Boost. Currently 94 lines on the page "boost_1_38_0/libs/libraries.htm#Alphabetically". And there are already 8 accepted and not yet included: * Property Tree Marcin Kalicinski May 20, 2006 * Time Series Eric Niebler August 17, 2007 * Forward (fast-track) Tobias Schwinger December 7, 2007 * Factory (fast-track) Tobias Schwinger December 21, 2007 * Floating Point Utilities Johan Råde Mars 8, 2008 * Thread-Safe Signals Frank Hess November 19, 2008 * Globally Unique Identifier Andy Tompkins November 29, 2008 * Constrained Value Robert Kawulak December 10, 2008 Which one will be the 100? And for which release (1.39 or 1.40)? Independently of which one will be the 100 I think that the Boost community can congratulate himself of his success. The 100 library delivery could be the occasion to celebrate this success on Boost. Any ideas? Best, Vicente _____________________ Vicente Juan Botet Escribá

1 0

[serialization] Bug with hash_map and Visual Studio 2008
by Raindog 13 Feb '09

13 Feb '09

The following conversation applies to VC9 also. http://thread.gmane.org/gmane.comp.lib.boost.user/12609/focus=12609 I fixed it using the same method suggested there but for the dinkumware.hpp configuration. (IE: Added a #define BOOST_HAS_HASH)

2 1

Re: [boost] [graph] updates
by Andrew Sutton 13 Feb '09

13 Feb '09

> > > Since nearly every algorithm requires a vertex index map in one way or > > another, these may as well be concepts. Also, its a convenient > documentary > > artifact that lets you write, "If your graph is not a *IndexMap, then you > > must provide an index map as an exterior property." > > Ah, interesting. That is helpful. It's part of a plan for generalized graph semantics framework, so we can discuss EdgeWeightedGraphs, NamedVertexGraphs, etc. Or, more specifically what to do when graphs don't model those concepts. > > Documentation for these features is forthcoming. Its part of my project > to > > (finally) migrate the BGL docs over to quickbook. There are tests for > most > > of these features - some are in progress - others are woefully inadequate > > and under development. Since I'm generally pretty busy, these will > probably > > materialize slowly. I'm aiming at 1.40. > > > Quickbook documentation for BGL would be *wonderful*. Perhaps someone > from the Boost Documentation project would like to help out (?). > They already have... somebody wrote an HTML to quickbook program :) I just have to dig out a reference to it. Plus, I have some of the quickbook framework built into the SOC project from 2007. Now if only I can get the toolchain to buil the docs correctly. Andrew Sutton andrew.n.sutton(a)gmail.com

3 3

[1.38.0] regexp compile error on Solaris 10 Sun Studio 11
by Paulo Moura Guedes 13 Feb '09

13 Feb '09

Hi, I had successfully compiled regexp library with boost_1_34_1 but with version boost_1_38_0 I'm getting this error: dmake -f sunpro.mak CC -c -O2 -I../../../ -o sunpro/libboost_regex/cregex.o ../src/cregex.cpp "../../..//boost/regex/v4/basic_regex_parser.hpp", line 379: Error: Could not find a match for std::distance<std::ForwardIterator, std::Distance>(const char*, const char*) needed in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: While instantiating "boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren()". "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_extended(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 126: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 106: Where: Instantiated from boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::do_assign(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 273: Where: Instantiated from non-template code. "../../..//boost/regex/v4/basic_regex_parser.hpp", line 379: Error: Formal argument x of type const std::pair<unsigned, unsigned>& in call to std::vector<std::pair<unsigned, unsigned> >::push_back(const std::pair<unsigned, unsigned>&) is being passed int. "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: While instantiating "boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren()". "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_extended(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 126: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 106: Where: Instantiated from boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::do_assign(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 273: Where: Instantiated from non-template code. "../../..//boost/regex/v4/basic_regex_parser.hpp", line 428: Error: Could not find a match for std::distance<std::ForwardIterator, std::Distance>(const char*, const char*) needed in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: While instantiating "boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_open_paren()". "../../..//boost/regex/v4/basic_regex_parser.hpp", line 255: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse_extended(). "../../..//boost/regex/v4/basic_regex_parser.hpp", line 126: Where: Instantiated from boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::parse(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 106: Where: Instantiated from boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char>>>::do_assign(const char*, const char*, unsigned). "../../..//boost/regex/v4/basic_regex.hpp", line 273: Where: Instantiated from non-template code. 3 Error(s) detected. *** Error code 3 dmake: Fatal error: Command failed for target `sunpro/libboost_regex/cregex.o' Any help appreciated. Regards, Paulo

3 4

[future] @Tom -> review result?
by Tom Brinkman 13 Feb '09

13 Feb '09

>> I realy think that freezing this library will have as consequence the freeze of at least these libraries: >> ThreadPool, AsynchronousExecutors, Threader/Joiner (both included for the moment in Interthreads), >> Active Object ... There is nothing keeping these other libraries from using "futures". Nothing is frozen. In fact, most utility libraries are added to boost by slipping them into other boost libraries. There is a certain priviledge to being a top-level boost library. It needs to be reserved for libraries that have received the appropriate amount of peer review. That cleary did not occur here. I agree that if a "review" does not generate enough reviews, than it should be scheduled again, with refined review criteria to attract more reviewers the next time. That is how I am inclined to proceed. Adding concurrent programming libraries to boost without lots and lots of peer review is a mistake. It is an extremely difficult subject. Unless persuaded otherwise, those will be the instructions that I will be giving the "Review Wizards". //Tom

2 1

[future] @Tom -> review result?
by Tom Brinkman 13 Feb '09

13 Feb '09

>> as Vicente lready ask - what is the result of the future review?! >> @Tom could you confirm that you are still working on the review summary? Yes, i'm still working on it. I've created a test framework that explores issues that I'm concerned about. For the most part, I'm more concerned about the bigger picture and how parralel programming is added to boost. There are many issues that will need to be considered. The story of parralel programming is still evolving and needs the input of many more people who have practical real world experience, particularly about task managment. Of course, you can still comment on how you would like to procceed. Unfortunately, as far as this review goes, I would have liked to see many more comments and reviews.

3 2

[iostreams] container_device
by Dmitry Vinogradov 13 Feb '09

13 Feb '09

I found it will be useful to have container_source/sink/device classes (from libs/iostreams/example/container_device.hpp) right inside the Iostreams library. What do you think about it?

3 2

Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
by a k 13 Feb '09

13 Feb '09

> From the user point the interface I'd like to propose might look like the > following: > > int i; > std::string s; > > 1) int i_from_s = boost::string::to<int>(s); // throws > 2) std::string s_from_i = boost::string::from<int>(i); > 3) bool s_is_i = boost::string::is<int>(i); Do you consider adding an extra parameter for locale, to get rid of dependency on the global one? Regards, &rzej

2 1