- Boost - lists.preview.boost.org

[regex] diagnosis and fix for #9544
by Peter A. Bigot 05 Jan '14

05 Jan '14

Trac rejected my comment because it has links in it, so here's the relevant information. This issue arose as of [http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=197248 GCC SVN commit 197248] which implements [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3582.html N3582]. It occurs because the [http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/parser.c?r1=197248&r2=197247&pa… change on line 4109] preserves parentheses at the front end (with that change reverted, gcc works correctly). This is now [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681 PR C++/59681]. The fix in GCC is not trivial, so I've just made [https://github.com/boostorg/regex/pull/1 pull #1] so the trivial fix for boost (remove the parens) can be applied.

1 0

Request for comments on super-project workflow doc
by Beman Dawes 04 Jan '14

04 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 Comments welcome! Thanks, --Beman

6 11

Removing _1 from the global namespace (again)
by Peter Dimov 04 Jan '14

04 Jan '14

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace. This will, however, break many things all around Boost (to say nothing about the outside world), as a quick grep can readily reveal. And, consequently, it will generate a certain amount of work for the maintainers of the affected libraries that, from their point of view, can appear unnecessary. So I'll need a certain amount of community consensus before going ahead and breaking everyone's code. :-)

14 15

[git] How to create a new submodule from existing submodule components?
by Beman Dawes 04 Jan '14

04 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 the Proposed assert submodule and Super-project workflow on their threads. Thanks, --Beman

3 5

[git-help] Doc. Suggestion: How to setup a custom boost "distribution"
by Klaim - Joël Lamotte 04 Jan '14

04 Jan '14

This is a suggestion for documentation, that "could" not be a good idea, I'm not totally sure. The goal would be to provide a simple recipe to setup a boost super-repo fork that would contain only a specific set of libraries, chosen by the user. I believe it would be of interest to a lot of companies that consider using boost but don't want to have to use the whole package. As Ryppl isn't ready yet, I was thinking that just providing a way to do it using the fork would already be helpful. It would also allow some people to provide a well tested custom distribution that would be easy to keep up to date. I expect people to experiment such things (I think I will at some point). The goal is NOT to resolve dependencies, or detect dependencies issues. It would be only to show that you can strip down the count of libraries if you wish in your own fork. The user will have to deal with dependency issues on his own, which is ok in a lot of cases, I assume. However, I'm not a specialist and I will not have time to try my idea immediately so I would like to ask if the following process is enough to do achieve the goal: 1. fork boost super-repo (clone locally, clone on your own server, or use the github fork button); 1.1. optionally, switch to a company or project-specific branch name; 2. in the fork, to remove libraries you don't want: 2.1. go in the root directory and edit the '.gitmodules' file 2.2. in this file, you will see each library module defined as follow: [submodule "any-library"] path = libs/any-library url = ../any-library.git fetchRecurseSubmodules = on-demand 2.3. locate and remove these declarations of each library you want to remove from the fork. 2.4. save the file. 3. commit the change 4. [git pull ?] 5. compile boost as usual. I'm not sure about the 4th point, but I think an operation is necessary so that git removes the library directories in the local clone. If these instructions are correct (once 4 is confirmed) and complete and are considered useful, maybe putting them somewhere in the doc would be worthwhile. Thoughts?

3 3

[git] mode and whitespace changes remaining between develop and master
by Nathan Ridge 04 Jan '14

04 Jan '14

Hello, I am trying to follow the instructions for "Establishing a merge point after SVN Conversion" [1] for the Boost.Range library. After cherry-picking all the commits to develop that have not been merged to master, onto master (all locally, I have not pushed anything yet), I am finding that there are still some mode and whitespace differences between master and develop (see the diff at the bottom of the message). I cannot find the commits that are responsible for these changes - is it safe to just ignore them? Thanks, Nate [1] https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint diff --git a/include/boost/range.hpp b/include/boost/range.hpp old mode 100755 new mode 100644 diff --git a/include/boost/range/adaptor/strided.hpp b/include/boost/range/adaptor/strided.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/adaptor/transformed.hpp b/include/boost/range/adaptor/transformed.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/algorithm_ext/is_sorted.hpp b/include/boost/range/algorithm_ext/is_sorted.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/detail/demote_iterator_traversal_tag.hpp b/include/boost/range/detail/demote_iterator_traversal_tag.hpp old mode 100644 new mode 100755 diff --git a/include/boost/range/detail/implementation_help.hpp b/include/boost/range/detail/implementation_help.hpp old mode 100644 new mode 100755 index 1f7d163..ca12fa4 --- a/include/boost/range/detail/implementation_help.hpp +++ b/include/boost/range/detail/implementation_help.hpp @@ -21,13 +21,13 @@ #include <wchar.h> #endif -namespace boost +namespace boost { namespace range_detail { template <typename T> inline void boost_range_silence_warning( const T& ) { } - + ///////////////////////////////////////////////////////////////////// // end() help ///////////////////////////////////////////////////////////////////// @@ -36,7 +36,7 @@ namespace boost { return s + strlen( s ); } - + #ifndef BOOST_NO_CWCHAR inline const wchar_t* str_end( const wchar_t* s, const wchar_t* ) { @@ -51,7 +51,7 @@ namespace boost ; return s; } -#endif +#endif template< class Char> inline Char* str_end( Char* s ) @@ -64,7 +64,7 @@ namespace boost { return boost_range_array + sz; } - + template< class T, std::size_t sz> inline const T* array_end( const T BOOST_RANGE_ARRAY_REF()[sz] ) { @@ -74,7 +74,7 @@ namespace boost ///////////////////////////////////////////////////////////////////// // size() help ///////////////////////////////////////////////////////////////////// - + template< class Char> inline std::size_t str_size( const Char* const& s ) { @@ -96,7 +96,7 @@ namespace boost } } // namespace 'range_detail' - + } // namespace 'boost' diff --git a/include/boost/range/iterator.hpp b/include/boost/range/iterator.hpp index 4ba9122..2966bdf 100644 --- a/include/boost/range/iterator.hpp +++ b/include/boost/range/iterator.hpp @@ -25,46 +25,46 @@ namespace boost { -#if BOOST_WORKAROUND(BOOST_MSVC, == 1310) - - namespace range_detail_vc7_1 - { - template< typename C, typename Sig = void(C)> - struct range_iterator - { - typedef BOOST_RANGE_DEDUCED_TYPENAME - mpl::eval_if_c< is_const<C>::value, - range_const_iterator< typename remove_const<C>::type>, - range_mutable_iterator<C>>::type type; - }; +#if BOOST_WORKAROUND(BOOST_MSVC, == 1310) - template< typename C, typename T> - struct range_iterator< C, void(T[])> - { - typedef T* type; - }; - } - -#endif + namespace range_detail_vc7_1 + { + template< typename C, typename Sig = void(C)> + struct range_iterator + { + typedef BOOST_RANGE_DEDUCED_TYPENAME + mpl::eval_if_c< is_const<C>::value, + range_const_iterator< typename remove_const<C>::type>, + range_mutable_iterator<C>>::type type; + }; + + template< typename C, typename T> + struct range_iterator< C, void(T[])> + { + typedef T* type; + }; + } + +#endif template< typename C> struct range_iterator { #if BOOST_WORKAROUND(BOOST_MSVC, == 1310) + + typedef BOOST_RANGE_DEDUCED_TYPENAME + range_detail_vc7_1::range_iterator<C>::type type; + +#else - typedef BOOST_RANGE_DEDUCED_TYPENAME - range_detail_vc7_1::range_iterator<C>::type type; - -#else - - typedef BOOST_RANGE_DEDUCED_TYPENAME - mpl::eval_if_c< is_const<C>::value, + typedef BOOST_RANGE_DEDUCED_TYPENAME + mpl::eval_if_c< is_const<C>::value, range_const_iterator< typename remove_const<C>::type>, range_mutable_iterator<C>>::type type; - -#endif + +#endif }; - + } // namespace boost #endif

2 1

[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