February 2009 - Boost - lists.boost.org

[c++0x][trunk testing] regression tests broken
by David Deakins 27 Feb '09

27 Feb '09

Looking at the output from our regression test system, it appears that the recent cpp0x changes have broken regression testing on the trunk. From a cursory review, it looks like some of the .cpp test files now mentioned in libs/config/test/all/Jamfile.v2 did not get merged over from branches/cpp0x. I noticed that the 'no_char16_t_pass.cpp' and 'no_char16_t_fail.cpp' files are missing, along with the char32 tests, the decltype tests, the extern template tests, the long long tests, and possibly more. Beman, do you have time to take a look at this and see which additional files need to be merged over? If not, I could probably take a look but not until tomorrow. And if this has already been noticed and mentioned, my apologies for the redundant post. Thanks, -Dave Deakins

1 0

Formal Review: Boost.RangeEx
by Thorsten Ottosen 26 Feb '09

26 Feb '09

Dear Developers and Users, It's my pleasure to announce that the review of Neil Groves' RangeEx library starts today and lasts until March 3, 2009. What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

6 12

Crash in boost::gregorian::from_simple_string in BOOST 1.36
by ak1mbox-boost＠yahoo.ca 26 Feb '09

26 Feb '09

Hello, I am using date_time library from Boost 1.36. When running this code: #include <boost/date_time/gregorian/gregorian.hpp> void RunDates() { boost::gregorian::date today(boost::gregorian::day_clock::local_day()); std::string todayString=boost::gregorian::to_simple_string(today); boost::gregorian::date todayFromString(boost::gregorian::from_simple_string(todayString)); } I get a reproducible crash when calling from_simple_string command on the last line of the function. Here is the backtrace: #0 0x961c9a12 in __gnu_debug::_Safe_iterator_base::_M_attach () #1 0x00003029 in __gnu_debug::_Safe_iterator_base::_Safe_iterator_base (this=0xbffff3ac, __seq=0x100698, __constant=false) at debug/ safe_base.h:89 #2 0x00006796 in __gnu_debug ::_Safe_iterator<std::_Rb_tree_iterator<std::pair<std::string const, unsigned short> >, __gnu_debug_def::map<std::string, unsigned short, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > > >::_Safe_iterator (this=0xbffff3ac, __i=@0xbffff35c, __seq=0x100680) at debug/safe_iterator.h:110 #3 0x000068a2 in __gnu_debug_def::map<std::string, unsigned short, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > >::find (this=0x100680, __x=@0xbffff4a4) at debug/ map.h:220 #4 0x00006f11 in boost::date_time::month_str_to_ushort<boost::gregorian::greg_month> (s=@0xbffff4a4) at date_parsing.hpp:68 #5 0x000071cb in boost::date_time::parse_date<boost::gregorian::date> (s=@0xbffff51c, order_spec=0) at date_parsing.hpp:142 #6 0x00007445 in boost::gregorian::from_simple_string (s=@0xbffff51c) at parsers.hpp:35 #7 0x00001f85 in RunDates () at /dates.cpp:18 #8 0x00001e18 in main (argc=1, argv=0xbffff568) at /main.cpp:8 The code was compiled on OSX, gcc version 4.0.1 (Apple Inc. build 5490) with Debug flags, I am linking against dynamic data_time library. Is this a known issue in 1.36 that was fixed in 1.38? going through the list of fixes did not uncover it. The same example compiled with release flags works without problems. I am not certain if this means that I am missing some defines or that release compile misses errors that debug catches. Any help with this is really appreciated! Thank you, Alex

1 0

Question about Spirit architecture
by Bernhard Merkle 26 Feb '09

26 Feb '09

Hi boost developers, The architecture for spirit is documented under http://www.boost.org/doc/libs/1_38_0/libs/spirit/classic/doc/organization.h… my question: should all modules of Core (scanner, primitives, composite, non_terminal) also be independent of each other ? so should they be independent subsystems or are they allowed to have dependencies (within the Core layer) ? thanks for your help kind regards, Bernhard.

3 5

[lambda] warning supression
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG The attached patch allows Lambda's tests to compile with warnings=all warnings-as-errors=on with gcc-4.3.0 msvc8.0express and msvc-9.0express. Ok to commit? In Christ, Steven Watanabe

3 2

[tuple] gcc warnings
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG I've tested the fix for #2388 and it looks ok. Okay to commit? In Christ, Steven Watanabe

3 2

best way to remove duplicates from forwardIterator [startIter, endIter]
by Sandeep Gupta 26 Feb '09

26 Feb '09

Hi, Given a collection in terms of [startIter, endIter] how can obtain [uniqBeginIter, uniqEndIter] that represents unique elements of the original container. I can always explicitly instantiate a set S of [startIter, endIter] and use [S.begin(), S.end()]. Is it possible to express this in terms of algorithms. Please note that I won't be able to use std::sort as startIter does not conform to RandomAccessIterator. Its a forward iterator. Thanks Sandeep

3 3

Re: [boost] [convert] Default Syntax Idea
by Vladimir.Batov＠wrsa.com.au 26 Feb '09

26 Feb '09

> From: "Stewart, Robert" <Robert.Stewart(a)sig.com> > I was thinking a bit about syntax for the default value for the > notional boost::convert() and kin. How about the following: > > int const i(3); > string const s("something"); > int const j(convert<int>(s) | 5); Yes, this idea is similar to int j = convert<int>(s).or_default(5); but does not introduce new vocabulary (my main hesitation). With the suggested op|, as I am reading it, it makes perfect reading just like I'd read English. And that is usually my criterion for an interface. So, I am voting 'yes'... in principle. See further below. > convert<DestType,SourceType>(SourceType) can return a type which > throws on failure in operator DestType(), but has an operator > |(SourceType) which returns a second type constructed with the > SourceType value. The second type provides its own operator > |(SourceType) which returns that value in its operator DestType() on failure. When the user does not want comprehensive result, it works. The problem as I see it is when the user wants the comprehensive report -- we return two different types, convert1<string, int> j1 = convert<string, int>(s); convert2<string, int> j2 = convert<string, int>(s) | 5; Sometimes I feel we need that as I might like to explicitly check if the call failed without relying on the default convert1<string, int> j1 = convert<string, int>(s) & boost::nothrow; convert2<string, int> j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Unless we convert both convert1 and convert2 to convert<string, int>::result as convert<string, int>::result j1 = convert<string, int>(s) & boost::nothrow; convert<string, int>::result j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Or we might simplify that as convert::result<int> j1 = convert::to<int>(s) & boost::nothrow; convert::result<int> j2 = convert::to<int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed The reason I am sticking 'to' in again is that I need the 'convert' as a namespace... or rather as a namespace-like structure: struct convert : mimic_namespace /*I have such a class*/ { template<class TypeOut> struct result { TypeOut value_; bool good_; }; struct internal_with_default { ... }; struct internal_with_no_default { ... }; template<class TypeOut, class TypeIn> internal_with_default<TypeOut, TypeIn> to(TypeIn const&); }; With namespace-like convert structure people will not be able to shortcut 'convert'. I.e. they'll always have to say convert::to which is darn close to convert_to with the advantage of having a dedicated namespace-like place instead of messing inside the boost namespace. Now it seems like I am back where I started. :-) > Returning a default value in lieu of an exception is a special case; > it ought not be treated like formatting. I have an impression that throwing/not-throwing and providing/not-providing the default have to be configured independently. Like I *might* need to throw even if I provide the default: direction dir = convert<string, direction>(str, direction::up) & boost::dothrow; Above I provide the default because I have to (direction does not have the def. ctor). However, I still *might* like to throw on failure. > Thus, while Boost. > Parameter might be appropriate to package the extra information > desired for formatting, I don't like the idea of writing "default_ = > 5" in the call, and I don't think ", 5" in the argument list is as > clear as it could be. I tend to agree with you on both. > The syntax above is obvious and concise while > being distinct from whatever may be done for formatting. You meant to say "laconic", right? Oh, just kidding. Thanks for pointing it out BTW. BTW, what do you think of convert<string, int>(s) & boost::dothrow; instead of convert<string, int>(s) >> boost::throw_t(); People seem to get put off by op>>. Best, V.

7 11

[optional_io] InputStreamable refinement
by Andrew Troschinetz 25 Feb '09

25 Feb '09

This is a spin off from the thread "[lexical_cast] A suggestion" While trying to get lexical_cast and optional to play nice I've run up against some problems with the InputStreamable solution for optional types in optional_io.hpp. The crux of the problem is that I think any given optional type should behave as much like the type it wraps as possible. For example I think this: stringstream sin ("1.2.3.4.5"); optional<double> token; while (sin >> token) cout << token << endl; Should have the same output as this: stringstream sin ("1.2.3.4.5"); double token; while (sin >> token) cout << token << endl; And that this shouldn't fail: stringstream sin ("test"); optional<string> token; sin >> token; // token shouldn't be empty The current InputStreamable solution for optional does not pass these tests. But that's not all, I also believe that there is room for even more improvement here! Since it's semantically valid to have an un- initialized optional type, I think failure to extract something off a stream should return an empty optional type _without_ setting the failbit on the stream. Here's a usage example that demonstrates what I mean by that: // output is "1 nan nan nan nan 5.5 nan nan nan nan nan nan nan -3.2 nan " istringstream sin (" 1 this 5.5 is a test -3.2 a"); optional<double> token; const double nan = numeric_limits<double>::quiet_NaN (); while (sin >> token) cout << token.get_value_or (nan) << " "; // output is "1 " istringstream sin (" 1 this 5.5 is a test -3.2 a"); double token; while (sin >> token) cout << token << " "; I did submit a ticket with the final comment proposing code that is (maybe?) a solution to this refinement. ( https://svn.boost.org/trac/boost/ticket/2659 ) Please pardon any guffaws I made in replies to that ticket, I'm still learning about the nuts and bolts of streams and boost as I go. However there is still one problem, and this brings us back to lexical_cast. Consider this example: int an_invalid_uint = -1; unsigned i = lexical_cast<optional<unsigned> > (an_invalid_uint).get_value_or (0); I believe we should expect this to store 0 in i, but instead it will throw a bad_lexical_cast exception even with my proposed revision to optional_io.hpp. A possible solution is a specialization for optional<Target> somewhere in lexical_cast.hpp that would replace code that looks something like this (pseudocode): do lexical_cast if failed to cast: throw exception With something like this: do lexical_cast if failed to cast: return optional<Target>() So is there any interest in this sort of refinement of optional's InputStreamable implementation or lexical_cast? -- Andrew Troschinetz Applied Research Laboratories

2 2

Extending asio (SCTP support)
by Hal Finkel 25 Feb '09

25 Feb '09

Hello, I've started implementing SCTP support in asio. I would like some feedback on what methodology is preferred. Although I had originally wanted to provide SCTP support as a pure add-on to the current framework, unfortunately, I don't think that can be done. For example, SCTP supports multi-homed endpoints, and the standard API provides a function sctp_bindx which can add and remove endpoint addresses from an active association (connection). While I can provide a subclass of socket_acceptor_service with this extended interface, there is no way of changing the wrapper (detail::reactive_socket_service) used to implement socket_acceptor_service's service_impl_type, and since socket_, protocol_, etc. are private members of detail::reactive_socket_service, I think that there is no way a subclass of socket_acceptor_service can access the underlying socket object. This seems to leave two options: 1. Patch the missing functionality into the existing classes. What worries me is that this approach does not seem to "scale" well with respect to the addition of new protocols. (what happens if someone needs TIPC support, for example). 2. Provide some kind of protocol-specific extension mechanism (templated base classes for example) for detail::reactive_socket_service and other such classes so that it is possible to provide protocol-specific extensions to the base asio interface. Does anyone have a preference on how I proceed? (or is there an option I've missed?) And if some extension mechanism is desired, is there a preference on the technique used for its implementation? Thank you in advance, Hal Finkel P.S. For anyone looking for a quick introduction to SCTP and its associated socket API, I've found HP's SCTP Programmer's Guide (http://docs.hp.com/en/5992-4578/index.html) to be pretty good.

2 2