- Boost - lists.preview.boost.org

[MPL] true_type,false_type versus true_,false_
by Erik Erlandson 04 Jan '14

04 Jan '14

I've been using true_type and false_type in some of my interfaces, for example: https://github.com/erikerlandson/edit_distance/blob/master/include/boost/al… However it seems as though true_ and false_ are more compatible with MPL logic functions. Is there any particular reason to use one over the other? Would it be preferable to use true_ and false_?

2 1

[regression] OK to merge? Should tools/regression be a submodule?
by Beman Dawes 04 Jan '14

04 Jan '14

* The directory tools/regression/src/report was missing from svn branches/release, so it is also missing from modular boost master. Although I haven't checked, that probably means the are other unmerged changes in develop. OK to merge develop to master (after suitable testing?) * Should tools/regression be a submodule? Does anyone remember why it remains a part of the super-project? If we are going to convert tools/regression to a submodule, should we do it now or wait until the dust settles? --Beman

5 11

Re: [boost] [AFIO] Callback API
by Bjorn Reese 03 Jan '14

03 Jan '14

Moving the discussion from boost-users to boost-dev, and thus the full context is quoted. On 12/21/2013 01:53 AM, Niall Douglas wrote: > On 20 Dec 2013 at 19:16, Bjorn Reese wrote: > >>> Can you suggest something? I honestly can't think of anything simpler >>> which also provides strong write ordering guarantees. >> >> I have not given this much thought so consider the following a >> brainstorm. > > We really ought to move this off boost-users ... but we'll see how it > goes. > >> I am thinking about an API that uses handles that looks more like Asio >> sockets. Write ordering can be handled, not by batching operations >> together, but rather calling the next write operation from the callback >> of the previous operation (Asio-style.) This will not always yield good >> performance, but oftentimes that is less relevant. If you need >> performance, then the "advanced" dispatcher API is available. >> >> So there could be a file handle (and directory handle) class for file >> (directory) manipulation calls, which hides all the details of the >> dispatcher etc. >> >> class file_handle >> { >> public: >> void read(buffer, read_callback); >> void write(buffer, write_callback); >> // and so on >> }; >> >> class directory_handle >> { >> public: >> void create(name, create_callback); // uses file(single) or dir(single) >> void remove(name, remove_callback); // uses rmdir(single) >> void watch(name, watch_callback); // directory monitoring >> // and so on >> }; > > I'm struggling to see the merit in such an approach - it would be > incredibly verbose and complex to write even simple solutions, > because i/o on files is not like sockets, *especially* that you > almost never must strongly order i/o across a sequence of multiple > sockets, but that is a very common case with files e.g. during ACID. First, it follows a pattern that is familiar to Asio users. So rather than you being the only one who can write applications on top of Afio, you get a broader community who are already familiar with the callback approach. Second, you can more easily combine it with Asio socket code to create compound services that mixes socket and file access. For instance, a peer-to-peer file distribution mechanism. > AFIO tries to help users to not write callbacks except when > necessary, but if you do want a user defined callback you simply > chain a call() or completion() operation to the item whose completion > you want called back upon. > > The idea is, you see, that you subclass the async_io_dispatcher class > with additional completion handlers, and use those as building blocks > for further subclasses of async_io_dispatcher. That hopefully gets > people to break up their callbacks into reusable completion handlers, > and saves people writing and debugging code. > Before you say "this should be in the documentation", yes it should > and will be after Paul gets his directory monitoring implementation > working. I'm thinking that will form the fourth section in the > beginner's tutorial - how to modularise and make reusable the > normally bespoke glue code which makes up traditional callbacks. It > might actually be worth adding a section 3b which shows how the naïve > approach in 3a is a very stupid idea :) > > As much as this sort of operation dependency graph based design works > well for its niche, I agree there is a swathe of code which ends up > looking like the find in files implementation, and for that hopefully > fibers will make look much more sane. I am not arguing against the current API. Instead, I am arguing for the addition of a more familiar Asio-style callback API. I have no trouble with a fiber-enchanced API (similar to Asio with coroutines.)

3 5

[MSM] Additional template arguments for process_event
by Juan Carlos Franzoy 03 Jan '14

03 Jan '14

The short question is: Would it be possible/convenient that boost::msm::back::state_machine::process_event receive more template parameters? template< class Event, typename... ARGS > process_event( const Event& event, ARGS&&... args ); args been forwarded to transition actions? I've been searching in boost.development mailing list archives and didn't see this question before. The need of additional template parameters is based on the fact that ARGS may not be defined at the moment of the state_machine isntantiation. Note: I would love to notice that I am wrong, and all this is an unnecessary complication, please let me know if that is the case. Thanks for reading. The long story follows: I am trying to use MSM for the first time. I am evaluating the factibility and convenience of a library to try to make easier the construction of protocol stacks over Boost.Asio. Protocol stack layers are often Finite State Machines. The idea is that the user of the library would program reusable 'layers' and use a library facility called LayerLinker to links the layers. For example this is a simplified pseudocode: template< typename STACK, int POSITION > class LayerLinker { typedef ... layer_t; typedef LayerLinker<STACK,POSITION+1> upper_linker_t; typedef LayerLinker<STACK,POSITION-1> lower_linker_t; layer_t layer_; upper_linker_t *up_; lower_linker_t *low_; public: LayerLinker( boost::asio::io_service& ios ) : layer_{ios} {} template<class EVENT> void processUpstreamEvent( const EVENT& ev ) { layer_.processUpstreamEvent( *this /* let the layer know my type */, ev ); } // similar for processDownstreamEvent() // Called by layer_ to send an event to the upper layer template<class EVENT> void sendUpstreamEvent( const EVENT& ev ) { if ( up_ ) { up_->processUpstreamEvent( ev ); } } // similar for sendDownstreamEvent() }; struct MyTopLayer { typedef ... my_fsm_t; my_fsm_t myFsm_; public: template<class LINKER, class EVENT> void processUpstreamEvent( LINKER& linker, const EVENT& ev ) { // in transition actions the FSM can send events to upper layers. myFsm.process_event( ev, linker /* additional parameter here */ ); } // similar to processDownstreamEvent }; // similar for MyMiddleLayer and MyBottomLayer int main() { typedef boost::mpl::vector<MyTopLayer,MyMiddleLayer,MyBottomLayer> stack_t; boost::asio::io_service ios; LayerLinker<stack_t, 0> topLinker{ios}; LayerLinker<stack_t, 1> middleLinker{ios}; LayerLinker<stack_t, 2> bottomLinker{ios}; topLinker.setLowerLinker( middleLinker ); middleLinker.setUpperLinker( topLinker ); middleLinker.setLowerLinker( bottomLinker ); bottomLinker.setUpperLinker( middleLinker ); topLinker.processDownstreamEvent( InitEvent{} ); ios.run(); } // from asio callbacks borromLinker.processUpstreamEvent( ReadEvent{...} ); Although I could make it without extra parameters to process_event, it is basically a workaround. THANKS A LOT for reading 95 lines. Juan Carlos Franzoy

2 1

[assert] Proposed assert submodule
by Beman Dawes 02 Jan '14

02 Jan '14

The release managers with help from Peter Dimov have been developing super-project workflow documentation. See https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow In that discussion, Peter wrote: >Hi everyone, > >As a first step of moving Boost.Assert out of Utility and into its own submodule, >I've extracted its files (along with the history) into a test repository of mine: > > https://github.com/pdimov/assert > >If you consider its contents acceptable, please let me know what should the procedure >be for moving this repository into boostorg and making it a proper submodule. I've take the liberty of moving this discussion to the main list for wider input on three questions. Please respond on this thread to the question asked in the subject line, and comment on "How to create a new submodule from existing submodule components" and Super-project workflow on their threads. Thanks, --Beman

1 0

[Trac] Captcha not working - blocking contributions
by Alexander Lamaison 02 Jan '14

02 Jan '14

I tried to include some code in a ticket (#9531, to be precise) and Trac tried to make me complete a captcha to prove I'm not spam. However, the captcha doesn't appear: https://drive.google.com/file/d/0B-RwWpWIiF0VRXVjTE5nM0VHekE/edit?usp=shari… Any ideas? Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

1 1

[Boost.Container] documentation problems
by John M. Dlugosz 01 Jan '14

01 Jan '14

A slightly old version of the flat_map documentation <http://www.boost.org/doc/libs/1_49_0/doc/html/boost_container_header_refere…> defines flat_map's Pred wrong: template<typename Key, typename T, typename Pred = std::less< std::pair< Key, T> >, typename A = std::allocator<T> > class flat_map; It should be std::less<Key>. Why do I care about a slightly old version, you might ask? Well, the current version doesn't seem to document it at all! If I go to the "latest version" link, <http://www.boost.org/doc/libs/1_55_0/doc/html/boost_container_header_refere…> doesn't show any definition for flat_map itself, just for comparison operators and other non-member templates. I can't find any means of navigating into the actual documentation for the class members, assuming it still exists. This is generally true for the other containers on that web page.

2 1

[git] Bumping git version requirement to 1.7.10
by Beman Dawes 01 Jan '14

01 Jan '14

https://svn.boost.org/trac/boost/wiki/Git/GitHome documents Boost's version requirement for Git, currently at 1.7.3. The regression scripts are using the clone --single-branch option, which became available at git 1.7.10, so we are planning to bump the version requirement. Done anyone have a problem with this? --Beman

6 11

[urgent] Testing help needed..
by Rene Rivera 31 Dec '13

31 Dec '13

I finally have the changes to the regression scripts sufficiently complete that I've managed to do a few minimal cycles of regression testing from the git repos. I now need some help in various ways: 1. General testing.. I need some of the regular testers to do runs with their setups with the new scripts. To test I suggest starting from a new testing location. And follow the usual instructions except get the run.py script from < https://raw.github.com/boostorg/boost/develop/tools/regression/src/run.py>. The options are exactly the same as the SVN version of the scripts (the --tag is mapped to master or develop as needed). If you run patch scripts you will have to adjust paths for the new arrangement. In particular the boost tree is now checked out to <testing-root>/boost_root. 2. Non-nix testing.. I don't have the time or resources available to check if the scripts and git invocations work on Windows. I need one person to test and likely make changes to the regression script to do the right things on Windows. Testing should be the same as above. But doing changes locally and testing them is challenging. The procedure I use is (as shell commands): > mkdir testing-dev > cd testing-dev > link <BOOST_DEVELOP>/tools/regression/src/run.py run.py > ln -s < BOOST_DEVELOP>/tools/regression/xsl_reports xsl_reports > ln -s < BOOST_DEVELOP>/tools/regression/src tools_regression_src > ./run.py --runner=<RUNNER_NAME> --skip-script-download --use-local That lets you edit the regression.py and run.py scripts in your local develop checkout. The options make it skip most of the run.py code, but otherwise make it behave as the regular testing except using your local changes. If you need to test changes to run.py in the normal use case you will have to commit+push the changes and then test. 3. Report generation.. It seems that the reports are failing to get generated for some reason. I suspect that the new scripts putting the git commit SHAs as the tested version number are messing up the results generation. I need someone familiar with the result generation to fix this. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

4 6

[Boost][Proto] BOOST_PROTO_USE_NORMAL_RESULT_OF seems incorrectly defined
by Hui Li 31 Dec '13

31 Dec '13

In proto/proto_fwd.hpp, based on how the macro BOOST_PROTO_USE_NORMAL_RESULT_OF is used, it's meant to be defined when the compiler supports c++11 decltype and implements N3276, for example, BOOST_PROTO_RESULT_OF is boost::result_of when BOOST_PROTO_USE_NORMAL_RESULT_OF is defined. However, its definition seems incorrect, and is inconsistent with the comments next to it. #ifdef BOOST_NO_CXX11_DECLTYPE_N3276 ^^^^^^ should this be #ifndef ? # // Proto can only use the decltype-based result_of if N3276 has been # // implemented by the compiler. # // See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf # ifndef BOOST_PROTO_USE_NORMAL_RESULT_OF # define BOOST_PROTO_USE_NORMAL_RESULT_OF # endif #endif Am i missing something here? Hui

2 2

Versioning of individual modules
by Peter A. Bigot 31 Dec '13

31 Dec '13

Forked from Re: [boost] [git] tagging in modules Context below. Guided questions follow the quoted context. On 12/30/2013 11:02 AM, Beman Dawes wrote: > On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot <pab(a)pabigot.com> wrote: > >> Not relevant to the original thread, but since I just noticed it: >> >> git-push by default does not push tags: you need to specifically ask for >> the tag to be pushed (by name), or use --tags. So this sequence does >> nothing visible: >> >> git tag -a 1.2 >> git push >> >> Personally I'd prefer if tag symbols were a little more informative than >> "1.2", and followed a pattern that places them in a namespace reserved for >> the module, such as timer-1.2. Because tags aren't normally pushed, >> they're useful for individual developers to use as markers. However, >> git-pull will automatically retrieve tags attached to commits that are >> fetched unless --no-tags is given, so if a repository (from boostorg, or >> another developer) defines (or moves) a tag it might overwrite your local >> tag without warning. So it's important to know what tags you can expect >> might conflict with those in a remote repository to avoid conflicts. >> > Updated: > > https://svn.boost.org/trac/boost/wiki/StartModWorkflow#Releasetags > <https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea…> > https://svn.boost.org/trac/boost/wiki/StartModMaint > #Lightweightlibraryrelease<https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea…> > > >> I'd also really like to see any module that uses internal versioning also >> provide a mechanism by which code can determine which version is being >> used. E.g., for the above there ought to be a <boost/timer/version.hpp> >> header which has: >> >> #define BOOST_TIMER_VERSION_MAJOR 1 >> #define BOOST_TIMER_VERSION_MINOR 2 >> >> Otherwise I'm not seeing any value for module-level version tags in the >> repository. Matter of taste, though. >> > While I'm sympathetic, we should get comments and buy in from library > maintainers before recommending this. Are a lot of libraries already doing > something similar? If so, what? And do we follow Rene's suggestion and > recommend Predef? Could you please start a separate discussion with a > subject that let's maintainers know this is affects them? Thanks! > > There is a tangentially related issue: The git and modular boost related > docs are being developed without any reference to or updating of existing > developer documentation. We need to get that underway. Ditto web site > changes. > > >> I would expect, on superproject release, that each module would continue >> to receive a boost-X.Y tag marking the module commit that corresponds to >> the submodule SHA1 used for the release. This is another reason to make >> sure module-level tags are clearly distinguished (lest somebody think the >> tag corresponds to a boost version rather than a module version). >> > Sounds about right, but we would need to work out the mechanics. Who does > the tagging? A script release managers run? General questions related to this topic: *) When a module pushes to master, must all commits that appear directly on the master branch be considered "stable" or is it only necessary that the HEAD always be stable? The context for this is actually in "[git] avoiding fast forward merges" at http://lists.boost.org/Archives/boost/2013/12/210110.php. It's primarily a superproject decision but module maintainers should be aware of it. *) Should all modules be assigned version numbers, or may module "releases" be unversioned master commits that "inherit" the Boost version when incorporated into a release? My opinion: Don't bother unless there's clear evidence that the module will be shipped or used outside of a versioned Boost installation. *) If a module has a module-specific version number, should it be expected to provide that version number in a standard location and name so that preprocessor directives interrogate and adapt user code based on it? What mechanism should be used for this? My opinion: Absolutely. If the module is named timer (sorry I keep picking on that module), then I would like to see: #include <boost/timer/version.hpp> define a macro BOOST_TIMER_VERSION which has an ordinal integer value that may be used in comparisons in preprocessor conditionals to select available features. I support Rene Rivera's suggestion to use the BOOST_VERSION_NUMBER macro from Boosts.Predef to accomplish this. Of course, if no modules need module-level versioning, this won't be necessary. *) What syntactic format should be used for git tags that record version numbers? My opinion: If the module is named timer, and the version number is 1.2, the tag timer-1.2 would be created and pushed to the boostorg timer repository by the timer maintainer. *) By what process is the superproject version associated with the commit on the master branch that is selected for a given Boost release? My opinion: If the Boost release is 1.56, every module incorporated into that release has a boost-1.56 tag created, identifying the master branch commit that is incorporated into the release. This tag would be added by the release manager when the superproject is tagged using a trivial "git submodule foreach git tag boost-1.56" in the superproject master branch followed by "git submodule foreach push origin boost-1.56" after sanity checks. Other inputs? Peter

2 3

[git-help] clone asks for passphrase for every library
by Nathan Ridge 30 Dec '13

30 Dec '13

Hello, I'm trying out git + modular boost for the first time. When I try to clone the repository as described here [1], I run into a problem where the recursive clone process asks me for my SSH key's passphrase for every submodule (library) that it is checking out. Is there a way to avoid this? Thanks, Nate [1] https://svn.boost.org/trac/boost/wiki/TryModBoost

4 4

[GIL] Pixel Layout Padding?
by TONGARI J 30 Dec '13

30 Dec '13

Hi there, The current gil::pixel design has a deficiency that you can't specify the align of pixel, for example, you can't have an RGBX pixel in GIL where X is padding. An alternative is to introduce a dummy channel for X, but that doesn't seem to be a good idea as we don't want to mess up the color space. So, maybe it'd be better to extend the current design, say, pixel<ChannelValue, Layout>, to something like pixel<ChannelValue, Layout, Align>. Then we can specify RGBX as pixel<uint8_t, rgb_layout_t, 4>, or XRGB as pixel<uint8_t, rgb_layout_t, -4> where minus means left justify. Ideas?

3 11

[git-help][urgent] How do I ignore an upstream change to one file?
by Rene Rivera 30 Dec '13

30 Dec '13

When I attempt to do an update of the boost superproject I get and error: Froggy:develop grafik$ git pull error: Your local changes to the following files would be overwritten by merge: tools/regression/src/regression.py Please, commit your changes or stash them before you can merge. Aborting Froggy:develop grafik$ I know I've made changes. I also know I don't want to throw away my changes. I also know that I don't want to merge the upstream changes to that one file. Hence.. How do I do a pull and have git ignore the upstream of only that file? (i.e. throw away the upstream changes because I know that my changes supersede them) Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

8 13

[git] New doc page: Cautions and Suggestions
by Beman Dawes 30 Dec '13

30 Dec '13

https://svn.boost.org/trac/boost/wiki/GitCautions\ Corrections, comments, and suggestions welcome. --Beman

2 2

[git] Post svn conversion merge point instructions moved
by Beman Dawes 30 Dec '13

30 Dec '13

The post svn conversion merge point instructions have been moved to a separate page. See https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint A set of preparatory steps suggested by Peter Dimov have been added. I'm unsure how Peter's prep steps interact with the actual merge point instructions. Particularly, what SHA is used for the merge point? Please take a look, and then suggest corrections or clarifications. Thanks, --Beman

2 2

[range] Should html docs be checked in?
by Mostafa 30 Dec '13

30 Dec '13

Can the maintainer(s) of range answer this question that came up in the documentation ML: On Sat, 28 Dec 2013 02:09:06 -0800, Daniel James <daniel(a)calamity.org.uk> wrote: > On 28 December 2013 00:15, Mostafa <mostafa_working_away(a)yahoo.com> > wrote: >> >> If html files, or any other files for that matter, are auto-generated >> then >> why are they included in the repo? The reason I ask because this >> difference >> in boostbook version causes a lot of extraneous noise when I do a git >> status. Instead of the three html files I was expecting to be modified >> when >> I changed a qbk file there are 153 extra html files that show up as >> modified. > > For many libraries they aren't. It's up to the library maintainer how > they're managed. What you can do is rebuild the documentation from a > clean checkout and commit that, then later edits shouldn't result in > so many changes.

5 9

[test] still broken in release
by Tim Blechmann 30 Dec '13

30 Dec '13

hi all, i've reported an issue before that boost.test in the release branch is pretty broken. *all* tests of the boost.heap testsuite segfault like this: --Program received signal SIGSEGV, Segmentation fault. 0x00000000005f4975 in boost::unit_test::test_suite::add (this=0x8cefa0, tu=0x9, expected_failures=0, timeout=0) at ../../../boost/test/impl/unit_test_suite.ipp:139 139 m_members.push_back( tu->p_id ); (gdb) bt #0 0x00000000005f4975 in boost::unit_test::test_suite::add (this=0x8cefa0, tu=0x9, expected_failures=0, timeout=0) at ../../../boost/test/impl/unit_test_suite.ipp:139 #1 0x00000000005fda9c in boost::unit_test::ut_detail::test_init_caller::operator() (this=0x8d4e08) at ../../../boost/test/impl/framework.ipp:96 #2 0x00000000006031a2 in boost::unit_test::ut_detail::invoker<int>::invoke<boost::unit_test::ut_detail::test_init_caller> (this=0x7fffffffc36f, f=...) at ../../../boost/test/utils/callback.hpp:42 #3 0x0000000000603071 in boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::ut_detail::test_init_caller>::invoke (this=0x8d4e00) at ../../../boost/test/utils/callback.hpp:89 #4 0x000000000060e03d in boost::unit_test::callback0<int>::operator() (this=0x7fffffffcfc0) at ../../../boost/test/utils/callback.hpp:118 #5 0x000000000060de8a in boost::detail::do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (tr=..., F=...) at ../../../boost/test/impl/execution_monitor.ipp:281 #6 0x000000000060d1a8 in boost::execution_monitor::catch_signals (this=0x7fffffffcfd0, F=...) at ../../../boost/test/impl/execution_monitor.ipp:885 #7 0x000000000060d262 in boost::execution_monitor::execute (this=0x7fffffffcfd0, F=...) at ../../../boost/test/impl/execution_monitor.ipp:1211 #8 0x00007ffff7b0bf33 in boost::unit_test::framework::init (init_func=0x4e3f30 <init_unit_test()>, argc=1, argv=0x7fffffffd198) at ../../../boost/test/impl/framework.ipp:268 #9 0x00007ffff7b22267 in boost::unit_test::unit_test_main (init_func=0x4e3f30 <init_unit_test()>, argc=1, argv=0x7fffffffd198) at ../../../boost/test/impl/unit_test_main.ipp:177 #10 0x00000000004e3f62 in main (argc=1, argv=0x7fffffffd198) at ../../../boost/test/unit_test.hpp:59 -- boost.test in trunk works fine, though ... i wonder, will it eventually be merged to release? tim

7 28

[test] Interest in 'hamcrest'-style checks?
by Jared Grubb 29 Dec '13

29 Dec '13

I recently read "Modern C++ Programming with Test-Driven Development", and I really enjoyed this book and highly recommend it. One of the styles I saw for the first time was "hamcrest"-style assertions. ("Hamcrest" is an anagram of "matchers"; also see http://en.wikipedia.org/wiki/Hamcrest.) For a quick idea, imagine there is a BOOST_CHECK_THAT macro that looks like this: (excuse my choice of names here, we can pick better ones if people like the idea) BOOST_CHECK_THAT( str, IsEqualTo(expStr) ); BOOST_CHECK_THAT( str, HasSubstring(needleStr) ); BOOST_CHECK_THAT( str, Not(HasSubstring(badStr)) ); BOOST_CHECK_THAT( vec, Contains(42) ); Comparing them to current boost::test assertions, usually the two are directly equivalent, and it's just a matter of style. At first, I was unconvinced of a need for this. However, there are a few scenarios where the hamcrest-style actually are really helpful: BOOST_CHECK_THAT(vec, Any(Contains(42), Contains(-42)) ); BOOST_CHECK_THAT(str, All(StartsWith("abc"), HasSubstring("lmnop"), EndsWith("xyz")) ); BOOST_CHECK_THAT(count, All(GE(0), LT(10)) ); BOOST_CHECK_THAT(vec, HasSubsequence(otherVec) ); BOOST_CHECK_THAT(vec, Sorted(IsEqualTo({1, 2, 3})) ); BOOST_CHECK_THAT(optionalStr, Any(IsEqualTo(boost::none), Deref(IsEqualTo("str"))); Sure, almost all of this is already doable: BOOST_CHECK_EQUAL_COLLECTIONS( /* sorry, but I really dislike this one :) */ ); BOOST_CHECK( std::count(vec.begin(), vec.end(), 42) && std::count(vec.begin(), vec.end(), -42) ); And, yes, you can create a helper functors today: BOOST_CHECK( Contains(vec, 42) && Contains(vec, -42) ); But hamcrest still gives these advantages over even that: * Dont repeat yourself: -- the value under test appears only once in the check expression; this is really helpful if you want to test an expression ("future.get()") that can only be called once * Better diagnostics: -- when something fails, you can get a detailed error (eg: "blah does not contain the element blah" or "str does not start with blah") -- when you have "Any" conditions, "errors" get squashed if some other condition passes, but all are shown if none pass -- composed tests can provide nested diagnostics; eg: for All(A, Any(B,C)), you'd get something like "'...A...' is true, but none of { '...B...' , '...C...' } are true", but spread over many lines -- and even with indentation if we want * Intentional Asymmetry: Is it BOOST_CHECK_EQ(expected, actual) or (actual, expected)? It really doesnt matter in the end, but a message like "expected 34, got 33" is actually kinda nice. Putting the value under test at the start creates an asymmetry that helps guide the user to put the values in the "right" order. * Composability * Extendibility: once the facility is there, its actually really easy to write more ("CanLockMySemaphoreType(timeout)") I wasnt able to find any discussion on boost's list for this, so I thought I'd bring it up. As for difficulty, implementing the examples above is actually already quite easy using boost::test predicates, and the extra macro would be fairly simple to implement. Almost all the work would be in creating the library of matchers, which is the fun part :) What do you think? Jared

5 11

[TortoiseGit] Screen shots becoming available + submodule update bug
by Beman Dawes 29 Dec '13

29 Dec '13

I've started to post screen shots of TortoiseGit performing the various operations described in "Getting Started with Modular Boost Library Maintenance". See https://svn.boost.org/trac/boost/wiki/TortoiseGitLibMaint Since each screen shot takes a bit of time and effort, I'd like to hear the opinions from some from TortoiseGit users as to whether or not the screen shots seem worthwhile. I particularly wanted to get a screen shot of a submodule update, but hit a bug in TG's "Submodule update...". It was reported yesterday, and the TG folks have already identified the problem as a bug in a library named libgit2, and reported that to the libgit2 folks, citing the boost super-project as the test case. The libgit2 folks have already created a pull request with a patch, so let's hope the fix reaches us reasonably soon. --Beman

2 1

[boost.test] Correct usage?
by Philip Bennefall 29 Dec '13

29 Dec '13

Hello, I just started writing unit tests for a large project that I am involved in, and boost.test has been absolutely fantastic to work with so far. True the documentation could be clearer, but as far as functionality I am very much impressed with the library. I have a question though. I read the following: http://lists.boost.org/Archives/boost/2011/10/186439.php This concerns me. What is the status here? When I build boost_1_54_0, in my stage/lib directory I see: libboost_test_exec_monitor-vc100-mt-s-1_54.lib My test cases look as follows: #define BOOST_TEST_MODULE MyProgram #include <boost/test/unit_test.hpp> BOOST_FIXTURE_TEST_SUITE(basic_operations, basic_memory_logger) BOOST_AUTO_TEST_CASE( some_test ) { // ... // Using BOOST_REQUIRE_EQUAL, BOOST_CHECK_EQUAL, BOOST_CHECK, BOOST_REQUIRE_EQUAL_COLLECTIONS and friends here. } BOOST_AUTO_TEST_SUITE_END() My questions are: 1. Are all these macros still supported and not depricated? 2. Is the structure correct? Am I depending on something depricated? Am I including the right header? I am linking with the library mentioned above (via auto-linking), which is why I am concerned about deprication. Thanks in advance for any clarification on this. Kind regards, Philip Bennefall

3 2

[phoenix] how do i achieve this type of extension of phoenix
by Hui Li 28 Dec '13

28 Dec '13

I want to extend the phoenix library with my own expressions in a specific way. Would appreciate any help!! Thanks! The code below is what i want to achieve, with the intended behavior specified in the comments. The goal is to first build an expression (the expr0), and later bind some value to certain nodes and turn them into different types of nodes with internal states (expr1) but preserve the structure of the expression tree, and also be able to modify the internal states of those nodes. My question is, how to define myplus, mymult, myinit, and myreset to make it work? using boost::phoenix::arg_names::arg1; using boost::phoenix::arg_names::arg2; using boost::phoenix::arg_names::arg3; // how should i define myplus, mymult and myinit, so that // expr1 is arg1 + myplus_f<double>(3.0)(1,arg2) + mymult_f<double>(3.0)(2,arg3) auto expr0 = arg1 + myplus(1,arg2) + mymult(2,arg3); auto expr1 = myinit( expr0, 3.0 ); // evaluate expr1 with actual arguments double r = expr1(1,2,3); // modify the internally held values of myplus_f<double>(3.0) and mymult_f<double>(3.0) // so that expr1 becomes equivalent to arg1 + myplus_f<double>(5.0)(1,arg2) + mymult_f<double>(5.0)(2,arg3) myreset(expr1, 5.0); // evaluate with new value members of myplus_f and mymult_f double r2 = expr1(1,2,3); myplus_f and mymult_f are defined as follows: template < typename T > struct myplus_f { T value; explicit myplus_f(const T& v):value(v){} void reset(const T& new_value) { value = new_value; } template < typename Lhs, typename Rhs > auto operator()(const Lhs& lhs, const Rhs& rhs) const -> decltype(value+lhs+rhs) { return value + lhs + rhs; } }; template < typename T > struct mymult_f { T value; explicit mymult_f(const T& v):value(v){} void reset(const T& new_value) { value = new_value; } template < typename Lhs, typename Rhs > auto operator()(const Lhs& lhs, const Rhs& rhs) const -> decltype(value*lhs*rhs) { return value * lhs * rhs; } };

2 1

Getting Started with Modular Boost Library Maintenance
by Beman Dawes 27 Dec '13

27 Dec '13

I've been pecking away at "Getting Started with Modular Boost Library Maintenance". See https://svn.boost.org/trac/boost/wiki/StartModMaint I'd appreciate comments and corrections. One of the questions that came up was how to number releases for individual libraries. Say Boost.System wants to do a release before the next full Boost release ships. What do I call it? How do I document it? How do I tag it? Strawman proposal ------------------------ * Call it "Boost.System 1.55.1 Point Release". * Document it via the "readme" file that GitHub pesters you to add. Contents would give the title of the release and the release notes. * Create a gh-pages branch with the same release notice. * Tag it 1.55.1 Comments? --Beman

11 26

[Config] Failure with Clang-3.4 in C++14 mode
by Ben Pope 27 Dec '13

27 Dec '13

"clang++-3.4" -c -x c++ -std=c++1y -stdlib=libc++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/config/test/config_test.test/clang-linux-3.4~c14_libc++/debug/config_test.o" "../libs/config/test/config_test.cpp" In file included from ../libs/config/test/config_test.cpp:76: ../libs/config/test/boost_no_constexpr.ipp:37:3: error: no viable conversion from 'const boost_no_cxx11_constexpr::A' to 'int' X<a> xx; // OK: unique conversion to int ^ ../libs/config/test/boost_no_constexpr.ipp:27:14: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_constexpr::A', but method is not marked const constexpr operator int() { return val; } ^ ../libs/config/test/boost_no_constexpr.ipp:28:14: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_constexpr::A', but method is not marked const constexpr operator long() { return 43; } ^ In file included from ../libs/config/test/config_test.cpp:231: ../libs/config/test/boost_no_cxx11_user_lit.ipp:64:15: error: invalid operands to binary expression ('const boost_no_cxx11_user_defined_literals::my_literal' and 'boost_no_cxx11_user_defined_literals::my_literal') return ((a == my_literal(0x23)) && (b == my_literal(9))) ? 0 : 1; ~ ^ ~~~~~~~~~~~~~~~~ ../libs/config/test/boost_no_cxx11_user_lit.ipp:22:19: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_user_defined_literals::my_literal', but method is not marked const constexpr bool operator==(const my_literal& a) { return val == a.val; } ^ ../libs/config/test/boost_no_cxx11_user_lit.ipp:64:42: error: invalid operands to binary expression ('const boost_no_cxx11_user_defined_literals::my_literal' and 'boost_no_cxx11_user_defined_literals::my_literal') return ((a == my_literal(0x23)) && (b == my_literal(9))) ? 0 : 1; ~ ^ ~~~~~~~~~~~~~ ../libs/config/test/boost_no_cxx11_user_lit.ipp:22:19: note: candidate function not viable: 'this' argument has type 'const boost_no_cxx11_user_defined_literals::my_literal', but method is not marked const constexpr bool operator==(const my_literal& a) { return val == a.val; } ^ ^ 6 warnings and 3 errors generated. Looks like a simple fix of marking the members const. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3598.html http://www.boost.org/development/tests/trunk/developer/output/BP%20x86_64%2… Ben

2 2

[boostbook] Unsupported doc elements.
by Mostafa 27 Dec '13

27 Dec '13

I was perusing Robert Ramey's very informative blincubator.com when I ran across this: "Though BoostBook specifies a large collection of tags to characterize documentation elements, the large majority of these are not used by Boost library documentation It seems that that they've been included in the hopes of being available for future use. This would be OK except for the fact that the attaching all these tags to one's documentation would be a huge job - which would yield no benefit with the current document preparation system. It's not clear from the BoostBook documentation which tags are used/useful and which should not be bothered with. This leaves one with questions about under what circumstances each tag should be used." Is the situation involving unsupported documentation elements still true? If so, can someone knowledgeable with the issue in the least identify which elements are supported and which are not? Any clarification appreciated, Mostafa

2 1