October 2013 - Boost - lists.boost.org

[filesystem] fix recur_dir_itr_imp::increment(system::error_code* ec) in 1.54.0
by claudio.bley＠gmail.com 19 Dec '13

19 Dec '13

Hi. What's happening to the filesystem library? It seems there's no progress on any tickets in the bug tracker? Referring to https://svn.boost.org/trac/boost/ticket/6821#comment:5 Could we get this fix into 1.54.0, please? BTW, sorry for any confusion - I "managed" to comment on the wrong ticket... https://svn.boost.org/trac/boost/ticket/5403 would've been more appropriate, I guess. Claudio -- Claudio

3 4

RFC: edit_distance / edit_alignment library
by Erik Erlandson 18 Dec '13

18 Dec '13

Boost Community, I cooked up a library that provides a pair of functions: edit_distance() and edit_alignment(). The library currently lives here: https://github.com/erikerlandson/edit_distance Some short example programs are here: https://github.com/erikerlandson/edit_distance/tree/master/examples A few example expressions: // the edit distance (aka levenshtein distance) unsigned dist = edit_distance("abc", "bcd"); // using a custom cost function for insertion, deletion, substitution unsigned dist = edit_distance("abc", "bcd", custom_cost_function()); // accepts arbitrary sequences, ranges, range adaptors unsigned dist = edit_distance(as_vector("abc"), as_list("bcd") | boost::adaptors::reversed); // obtain the edit distance and the list of the edit operation codes (in output iterator) unsigned dist = edit_alignment("abc", "bcd", std::ostream_iterator<edit_opcode>(std::cout, "")).second; // adaptors to add edit operation costs and sequence elements to the edit operation output unsigned dist = acquire<elements>(acquire<costs>(edit_alignment))("abc", "bcd", std::ostream_iterator<boost::tuple<edit_opcode, unsigned, char, char> >(std::cout, "")).second; I'm interested in community feedback on whether these would be a useful addition to boost::algorithms. I envision these as the first additions to an eventually-larger library of other kinds of string distances, dynamic programming, and other algorithms for sequence alignment.

4 17

[exception][range] boost/range/size_type.hpp + unexpected dependenciies Exeception -> Units -> Algorithms -> Range -> Concepts
by Vicente J. Botet Escriba 28 Nov '13

28 Nov '13

Hi, The regression test signal this error Test output: MinGW-w64-4.5 jc-bell.com - thread - async__async_p / gcc-mingw-4.5.4 Rev 85699 / Mon, 16 Sep 2013 13:58:07 +0000 Compile [2013-09-16 17:53:55 UTC]:fail "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -mthreads -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "F:\boost\GCC\trunk\results\boost\bin.v2\libs\thread\test\async__async_p.test\gcc-mingw-4.5.4\debug\threading-multi\sync\futures\async\async_pass.o" "..\libs\thread\test\sync\futures\async\async_pass.cpp" In file included from ../boost/range/size.hpp:21:0, from ../boost/range/functions.hpp:20, from ../boost/range/iterator_range_core.hpp:28, from ../boost/range/iterator_range.hpp:13, from ../boost/algorithm/string/replace.hpp:16, from ../boost/units/detail/utility.hpp:25, from ../boost/exception/detail/type_info.hpp:19, from ../boost/exception/detail/object_hex_dump.hpp:15, from ../boost/exception/to_string_stub.hpp:16, from ../boost/exception/info.hpp:16, from ../boost/exception/detail/exception_ptr.hpp:20, from ../boost/exception_ptr.hpp:9, from ../boost/thread/future.hpp:28, from ..\libs\thread\test\sync\futures\async\async_pass.cpp:29: ../boost/range/size_type.hpp:80:5: error: expected ';' before '}' token ../boost/range/size_type.hpp:80:5: error: expected ';' before '}' token ../boost/range/size_type.hpp:87:5: error: expected ';' before '}' token ../boost/range/size_type.hpp:87:5: error: expected ';' before '}' token BOOST_RANGE_CONCEPT_ASSERT((boost::SinglePassRangeConcept<T>)) This is surely due to a changeset on Boost.Range (85690?). Maybe an inclusion to Concepts is missing. Could the maintainer take a look? What is more surprising is the chain of dependencies the inclusion of boost/exception_ptr.hpp conveys. Exeception -> Units -> Algorithms -> Range -> Concepts. Is there a way to break these dependencies? Best, Vicente

4 8

Code to address requirement 7(a) of IOStreams Roadmap
by Gene Panov 26 Nov '13

26 Nov '13

Colleagues, I posted this before, but didn't get answers to some questions so far. I think I addressed the "output" part of requirement 7(a) from the IOStreams Roadmap: https://svn.boost.org/trac/boost/wiki/IostreamsRoadmap in this library: https://code.google.com/p/async-ostream/ Does anyone mind if I create a patch for Boost.IOStreams to add those five files and ask the maintainer (or volunteers) for feedback? Regards, Gene

5 14

VC2013 1.55 beta failures
by Olaf van der Spek 20 Nov '13

20 Nov '13

Hi, Building 1.55 beta keeps failing on VC2013 RC. Trunk fails too IIRC. compile-c-c++ bin.v2\libs\date_time\build\msvc-12.0\debug\link-static\threading-multi\gregorian\greg_month.obj greg_month.cpp C:\VC\boost_1_55_0b1\boost/iterator/detail/facade_iterator_category.hpp(166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' C:\VC\boost_1_55_0b1\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/detail/facade_iterator_category.hpp(193) : see reference to class template instantiation 'boost::mpl::eval_if<boost::detail::is_iterator_category<CategoryOrTraversal>,boost::mpl::identity<boost::forward_traversal_tag>,boost::detail::facade_iterator_category_impl<CategoryOrTra versal,ValueParam,Reference>>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/iterator_facade.hpp(104) : see reference to class template instantiation 'boost::detail::facade_iterator_category<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/iterator_facade.hpp(620) : see reference to class template instantiation 'boost::detail::iterator_facade_types<Value,CategoryOrTraversal,Reference,Difference>' being compiled with [ Value=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , CategoryOrTraversal=boost::forward_traversal_tag , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & , Difference=ptrdiff_t ] C:\VC\boost_1_55_0b1\boost/token_iterator.hpp(40) : see reference to class template instantiation 'boost::iterator_facade<boost::token_iterator<TokenizerFunc,Iterator,Type>,Type,boost::forward_traversal_tag,const Type &,ptrdiff_t>' being compiled with [ TokenizerFunc=char_separator_type , Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>> , Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ] C:\VC\boost_1_55_0b1\boost/date_time/date_parsing.hpp(132) : see reference to class template instantiation 'boost::token_iterator<TokenizerFunc,Iterator,Type>' being compiled with [ TokenizerFunc=char_separator_type , Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>> , Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ] C:\VC\boost_1_55_0b1\boost/date_time/gregorian/parsers.hpp(30) : see reference to function template instantiation 'date_type boost::date_time::parse_date<boost::gregorian::date>(const std::string &,int)' being compiled with [

13 52

[git help] GitHub boostorg library authentication
by Beman Dawes 19 Nov '13

19 Nov '13

To test the modular boost docs I'm writing, I did this: git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers cd libs/system git checkout develop # did a simple edit of one file git commit -a -m "my bug fix" git push origin develop Everything ran as expected until the last step, which resulted in this: Username for 'http://github.com': That's a problem. Authentication needs to happen automatically. What steps did I miss? Thanks, --Beman

6 11

Re: [boost] Improving Documentation
by Andrew Hundt 19 Nov '13

19 Nov '13

On Thu, Oct 10, 2013 at 12:20 AM, Robert Ramey <ramey(a)rrsd.com> wrote: > Jeff Flinn wrote: > > On 10/9/2013 12:41 PM, Robert Ramey wrote: > >> Daryle Walker wrote: > >>>> From: ramey(a)rrsd.com > > I wish this thread had come up 3-4months ago. Unlike you I couldn't > > grok the docs to use multi-array as a back end to a Qt table where I > > needed > > to support run time row/col insertion/deletion. I was under time > > constraints and found it much easier to build my own facilities. I'm > > not sure whether it was due to docs or design. > > Well, I did come to understand it pretty well. But I really have to > say I spent a LOT of time poring over the documentation, experimenting > etc. The oddest thing to me is that now it seems easy to me and I > can't figure out what I spent the time on - we're talking a few days. > I had the same experience (only worse) with units library. Actually > I have this experience with almost every boost library I use. This > brings up the whole question of documentation of boost libraries > and in fact documentation of computer libraries in general. I've spent > a lot of time thinking about this lately. I feel we've been too lax in > accepting libraries after the review whose documentation isn't up > to some minimum standard (not that we have a standard). > > Robert Ramey > +1 Every boost library I've used has been great once I've understood it. However, I have trouble getting some very smart people on my team to use existing boost tools because they find it confusing, and they also have a tough time finding the functionality they need. I believe this is a documentation problem. For example, a number of people I know were surprised when I told them that the /libs folder contains examples and unit tests for every library. The documentation doesn't seem to consistently provide links and explanations of each. I believe I spent months as a user before I found the libs folder. I'll take boost.container.static_vector, as an additional example. I contributed to it so it seems like a decent choice. Here are the two most easily accessible links in Boost.Container for documentation of static_vector: http://www.boost.org/doc/libs/1_54_0/doc/html/container/non_standard_contai… The first link contains the first block of text about static_vector I expect one would run into, and there isn't even a link to the class documentation! http://www.boost.org/doc/libs/1_54_0/doc/html/boost_container_header_refere… This second link is the typical header documentation throughout boost. When I first started using boost it was months before I realized that in these header synopsis I could click on the words of the class to see the full documentation of that class, in this case "static_vector". Much of the time I just felt confused and lost. I think this is indicative of a layout and user interface that needs some improvement. Now, perhaps I should blame myself for this in the static_vector case and fix it, but it is indicative of the general documentation problems. One example of C++ documentation I have found that I've actually been happy with is cppreference.com. If you look at their front page they have many of the major classes, and with one click you are in there reading what you want to know, with examples at the bottom of every page. It is actually entertaining that they mention boost documentation in their FAQ as follows: Why is the material here limited to the standard C and C++? > In short, we chose quality over quantity. Some boost libraries<http://www.boost.org/> could > also be candidates for inclusion though. While their tutorials are very > good, the *reference* documentation is often very inflexible and > inconvenient. So, is there anything we can do about it? I remember a couple of years ago Boost had a "Bug Sprint" with the goal of closing lots of open tickets. Perhaps we should do a "documentation sprint"? Here is an interesting article about writing good documentation that also contains links to other solid articles that I recommend checking out: http://stevelosh.com/blog/2013/09/teach-dont-tell/ Cheers! Andrew Hundt

13 63

[git] [modular boost] Switchover schedule proposal
by Beman Dawes 19 Nov '13

19 Nov '13

The showstoppers other than documentation have been cleared from the conversion issues list. That includes the issues blocking documentation, so doc work is underway again. The 1.55 release is scheduled for November 4, and as of the moment it doesn't look like that will sip much if at all. I'm assuming that we want to reopen svn branches/release for a week or so after 1.55 ships as some developers would like to merge pending changes to branches/before the switchover. That would mean an actual switchover starting about November 11. It seems to me we need approximately a week after svn is made read-only and the final conversion run is done to verify the correctness of the conversion. During that time it seems to me that it would be unwise for developers to make git commits since if a serious problem was discovered we might decide to rerun the conversion process, wiping out the git repos. At that point (roughly November 18, we would go totally live and developers could resume their work, now using git and modular boost. Comments, --Beman

10 33

Patch in Ticket #9212 (Broken links to C++ standard papers)
by Michel Morin 13 Nov '13

13 Nov '13

Jonathan Wakely pointed out "Broken links to C++ standard papers" issue and attached a patch in #9212. ( https://svn.boost.org/trac/boost/ticket/9212 ) Though this patch is a large Boost-wide patch, it's very simple so I think someone can commit it to every library at once. Regards, Michel

4 9

[containers] Are there flat_map/set and stable_vector proposals at work?
by Klaim - Joël Lamotte 10 Nov '13

10 Nov '13

All is in the title: I would like to know if flat_map, flat_set and stable_vector have been proposed for inclusion in the C++ standard library, or if there are works going on to write such a proposal. I find that I use a bit more flat associative containers than tree-based standard associative containers in all my recent projects, and I think that having option in the standard to choose one or the other would be very useful for a lot of devs.

5 20