January 2014 - Boost - lists.preview.boost.org

[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

[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