- Boost - lists.preview.boost.org

[range][algorithms] How about making the range algorithms pipeable as the range adaptors are?
by Viktor Sehr 28 Sep '13

28 Sep '13

It would be syntactically really nice if the stl-algorithms wrapped in boost range were pipeable, as with the adaptors, making it seamless to combine them in left-to-right statements For non-mutating algorithms I think it's an obvious evolvement const auto& max_pos = some_range | filtered(..) | max_element; const auto& num_elements = some_range | filtered(..) | count(42); ...instead of inside out as it is now const auto& max_pos = max_element(some_range | filtered(..)); const auto& num_elements = count(some_range | filtered(..), 42); For non-mutating algorithms it might not be an obvious solution, as the range beneath is modified, but I still think it should be possible boost::erase(my_vector | sort | unique); ...instead of boost::erase(unique(sort(my_vector)); *Implementation example with std::accumulate:* // Tag to be recognized by the global pipe operatortemplate <typename value_type>struct accumulate_argument_tag { accumulate_argument_tag(const value_type& value) : value_(value) {} const value_type& value_; }; struct accumulate_tag { // Put the regular algorithm as an operator() function where the first argument is the range template <typename range_type, typename value_type> value_type operator()(const range_type& range, const value_type& start) { return std::accumulate(std::begin(range), std::end(range), start); } // If no range is provided, return a tag which contains the argument, which can then be identified by the global pipe operator template <typename value_type> accumulate_argument_tag<value_type> operator()(const value_type& value) { return accumulate_argument_tag<value_type>(value); } };static accumulate_tag accumulate; // Global pipe operator which takes one argumenttemplate <typename range_type, typename value_type>value_type operator|(const range_type& range, const accumulate_argument_tag<value_type>& argument_holder) { return std::accumulate(std::begin(range), std::end(range), argument_holder.value_); } // Global pipe operator which can accept 'accumulate' without any parenthesis// (assuming that std::accumulate can be used without arguments)template <typename range_type>typename range_type::value_type operator|(const range_type& range, const accumulate_tag&) { return std::accumulate(std::begin(range), std::end(range), range_type::value_type(0)); } // Usage std::vector<int> vec;for(size_t i = 0; i < 135; ++i) vec.push_back(i);auto a = accumulate(vec, 0);auto b = vec | accumulate(0);auto c = vec | accumulate; /Viktor

6 10

Borland and metrowerks compiler requirements?
by Stephen Kelly 27 Sep '13

27 Sep '13

Hello, In the work I've done so far on removing ifdefs for obsolete compilers, some compilers which have come up a few times are __BORLANDC__ and __MWERKS__. I have never used either of those compilers. Can old versions of either of them be dropped at this point in boost trunk? Thanks, Steve.

8 29

"Remove obsolete MSVC checks" and _MSC_VER
by Peter Dimov 26 Sep '13

26 Sep '13

One general note about these changes. This: #if defined( _MSC_VER ) && _MSC_VER >= 1310 doesn't mean "compiler is MS VC++ 7.1". It means "compiler claims to support MSVC 7.1's features." Many Windows compilers define _MSC_VER for compatibility. I'm not positive that the removal of the _MSC_VER >= part would break something nowadays, but if it does, this would be why. I'd have left these alone; it's not clear what purpose removing the check is intended to serve, apart from breaking code. Actual MSVC-specific code is guarded by BOOST_MSVC and not _MSC_VER.

3 11

[Container] Memory leak from allocation of 0 sized memory
by Evan Wallace 26 Sep '13

26 Sep '13

I recently tracked down a major memory leak in a system that I am working on to a bug in Boost.Container. The bug is that the following code leaks memory: #include <boost/container/vector.hpp> int main() { while (true) { boost::container::vector<int> vec; boost::container::vector<int> vec2(vec); } } I have submitted a ticket to trac, but since this is a major issue and the release date for 1.55.0 is very soon, I am also posting to the mailing list. https://svn.boost.org/trac/boost/ticket/9166 For reference: the leaked memory is allocated in allocator_version_traits::allocation_command Evan Wallace

2 1

mpl broken after removal of nttp.hpp in 85956
by Jürgen Hunold 26 Sep '13

26 Sep '13

Hi Stephen, the message is: home/hunold/src/devel/boost/boost/mpl/aux_/nttp_decl.hpp:17:42: fatal error: boost/mpl/aux_/config/nttp.hpp: No such file or directory It seems that even nttp_decl.hpp is obsolete, as is only contains: // Obsolete. Remove. # define BOOST_MPL_AUX_NTTP_DECL(T, x) T x /**/ Maybe incomplete quick patch attached. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[type_traits][function_types] Discard param const qualification, bug or feature?
by Mostafa 26 Sep '13

26 Sep '13

Both the type_traits and function_types library discard parameter const-qualifiers when decomposing function types. Is this a bug or a feature? If a feature, then it's surprising enough behaviour that I think it warrants some documentation in both libraries. For the record, I'm using gcc 4.7.3 on Cygwin 1.7.22 in Windows 7, and here's a reproducible example of what I'm talking about: #include <boost/type_traits.hpp> #include <boost/function_types/parameter_types.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/int.hpp> #include <boost/mpl/assert.hpp> using namespace boost; typedef void (foo)(int const); int main() { typedef function_traits<foo>::arg1_type traits_deduced_type; BOOST_MPL_ASSERT(( is_same<traits_deduced_type, int> )); //Errors: //BOOST_MPL_ASSERT(( is_same<traits_deduced_type, int const> )); typedef boost::function_types::parameter_types<foo> ftypes_params; typedef boost::mpl::at<ftypes_params, boost::mpl::int_<0> >::type ftypes_deduced_type; BOOST_MPL_ASSERT(( is_same<ftypes_deduced_type, int> )); //Errors: //BOOST_MPL_ASSERT(( is_same<ftypes_deduced_type, int const> )); return 0; } Mostafa

5 10

Student and Internationaltickets for Meeting C++
by Jens Weller 26 Sep '13

26 Sep '13

Hello boost-community, a short update on the upcoming Meeting C++ Conference. There are 3 different discounts available - Student discount of 200 € - international guests 100 € - boost contributor* 100 / 50 € The discount works over a code, so you need to contact me, in order to be given your discount-code. The discount for boost contributors is 100 €, or additional 50 € if combined with one of the other discounts. More information on the Discounts: http://meetingcpp.com/index.php/newsreader/items/announcing-student-and-int… Meeting C++ 2013 Schedule: http://meetingcpp.com/index.php/schedule13.html General Information on the conf: http://meetingcpp.com/index.php/mcpp2013.html * you should have activly contributed to boost kind regards, Jens Weller

1 0

Re: [boost] Some patches to remove obsolete MSVC version checks
by Stephen Kelly 26 Sep '13

26 Sep '13

On 09/13/2013 01:35 PM, Stephen Kelly wrote: > Hi, > > I've attached patches to remove or simplify some ifdefs for MSVC > versions which are now obsolete. > > This is a followup to this thread: > > http://thread.gmane.org/gmane.comp.lib.boost.devel/243094 > (Removing old config macro and increasing compiler requirements., > 2013-07-29) > > The patches are most easily applied locally and reviewed with a git-svn > checkout and git am. > > I'll also apply to get SVN access so I can commit patches myself. FYI, I've started cherry-picking, re-reviewing and committing these patches. I'll keep the patches small and single-issue. I would appreciate post-commit review from anyone for any of them, as some of the ifdef chains are complex. Thanks, Steve.

2 2

BoostPro closing the doors and needing volunteers
by munsingh 25 Sep '13

25 Sep '13

Hello Boost Maintainers, I observed that BoostPro have closed doors and have made the project open source. I would like to volunteer for maintaining and enhancing the pre-build binaries and sources for boost pre-built installers. Kindly let me know what all is desired from a person who wishes to take up this activity. Thanks & Regards, Manish -- May the force be with you

2 1

VC12 RC: Compiler crash when mixing boost::synchronized_value, Boost.ptree and uniform initialization.
by Klaim - Joël Lamotte 25 Sep '13

25 Sep '13

Just for information, if that can help, I just reported this bug that I can only reproduce using boost::synchronized_value<boost::property_tree::ptree>::operator->() It's obviously a compiler problem but it might help adapting Boost code it if it is not fixed in time for VS2013 release: https://connect.microsoft.com/VisualStudio/feedback/details/802157/compiler… As said in the comments, I didn't find how to reproduce it in a simpler way.

1 0

Re: [boost] [thread] synchronized_value: value and move semantics
by Andrey Semashev 24 Sep '13

24 Sep '13

On Wed, Feb 20, 2013 at 10:02 PM, Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr> wrote: > > Hi, > > boost::synchronized_value (not released yet [1][2][3]) is based on [4]. > See below part of this paper adapted to the Boost.Thread interface. > > Currently boost::synchronized_value is in addition Copyable and Swappable. > I was wondering if it is worth adding value and move semantics to > synchronized_value. Making it EqualityComparable, LessThanComparable and > Movable if the underlying type satisfy these requirements will allow to > store them on a Boost.Container/C++11 container. > > Do you see something completely wrong with this addition? > Has some of you had a need for this? Could you share the context? > Sorry, I missed this discussion somehow. I've taken a quick look at the interface and have a few questions: 1. Why are there strict_lock_ptr and unique_lock_ptr? What are the differences and why we can't have one such ptr (presumably, unique_lock_ptr)? 2. I find value() and get() a bit confusing, since it is not apparent what is the difference between them. Maybe value() could be renamed to get_ref() or unsafe_get()? 3. Am I correct that having strict_lock_ptr/unique_lock_ptr acquired by calling synchronize() will not deadlock with operator-> when a non-recursive mutex is used?

5 11

Re: [boost] [Boost-users] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 24 Sep '13

24 Sep '13

So I eventually managed to fix the issue with interlocked.hpp and mingw-w64: both i686 and x86_64 now work. Attached is a patch against 1.54.0. Is it possible to include this in 1.55.0? Regards, Frédéric

3 17

Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a_release_2
by Renato Forti 23 Sep '13

23 Sep '13

Hi all, The docs and lib are updated! Please, send your comments. http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html PS: I want to take and ask for help, if any native english speaker can help me with the documentation! Please, contact: re.tf <at> acm.org Thanks

5 8

Referencing Boost.Iostreams in the documentation of a non-boost library
by Gene Panov 23 Sep '13

23 Sep '13

Boost Experts, I am a fan of Boost.Iostreams and I am referencing them several times in the documentation of a little library that I wrote and posted on Google Code under "New BSD license" (https://code.google.com/p/async-ostream/) Do I need to provide a full URL or copyright information or anything else to make such reference to Boost.Iostreams legally sound? Or shall I just switch to use Boost Software License instead to keep it simple? Thanks! Gene

3 2

Functionality for part 7(a) of Boost.IOStreams Roadmap
by Gene Panov 23 Sep '13

23 Sep '13

Boost Experts, I think I possibly addressed the "output" part of requirement 7(a) (Support for asynchronous and non-blocking I/O :: asio compatibility) from the Iostreams Roadmap https://svn.boost.org/trac/boost/wiki/IostreamsRoadmap in this library https://code.google.com/p/async-ostream/ Do you think it addresses that requirement from the roadmap? If yes, does it make sense if I make a patch for Boost.Iostreams to include those five files? Regards, Gene

1 0

[predef] [git] Do the tests need an explicit <dependency>
by Steven Watanabe 22 Sep '13

22 Sep '13

AMDG The property <dependency>$(BOOST_PREDEF_INCLUDE_ROOT)/boost/predef.hpp interferes with testing under the git layout, because this header is generated as part of the build. Is there a reason for it? The dependency should be found by the #include scanner. In Christ, Steven Watanabe

2 1

[config] Visual C++ 2013 RC support - variadic template failures
by Beman Dawes 21 Sep '13

21 Sep '13

I updated boost/config Visual C++ support yesterday to add Visual C++ 2013 RC support. But Mat Berchtold reported that signals2 tests then started to fail. I confirmed that 2013 RC tests were failing for signals2 and several of its dependencies, and narrowed it down to variadic templates so reverted to defining BOOST_NO_CXX11_VARIADIC_TEMPLATES for 2013 RC. --Beman

3 6

[Operators] empty_base should be untemplated?
by Andrew Ho 21 Sep '13

21 Sep '13

I've noticed about the empty_base class is that it's templated with type T, and I don't think it should be. Fyi, the empty_base class is there to turn multiple inheritance into a single inheritance chain (due to compiler deficiencies/object size bloat on at least Visual Studio). I don't see why this empty_base should be templated, and it would be better suited if it wasn't since all I can think it does is make the compiler work harder. Does anyone know why it was templated to begin with? Additionally, are we safe to change empty_base to be not use templates?

4 4

Boost reviews
by Edward Diener 21 Sep '13

21 Sep '13

I have not seen any new reviews of libraries for Boost in a long time. Is this because: * There are very few libraries on the review queue. * There are no people willing to act as review managers for library reviews. * Boost already has so many libraries that an effort has been made to slow down reviews to a great extent. * There is little interest for new Boost libraries in the community of developers who follow Boost. * The transition to git and ryppl is taking precedence before any new libraries will be reviewed. * There are not enough reviewers when a library does have a review in order to decide whether or not a library should be accepted into Boost. Or perhaps some combination of these possibilities. As someone who still would like to see my variadic data library be reviewed for possible acceptance into Boost I am most curious to know the reasons why no new libraries appear to be getting reviewed anymore.

5 7

[multi_index][intel-linux-14.0.0][repost] Help needed debugging initializer list support
by Joaquin M Lopez Munoz 21 Sep '13

21 Sep '13

Hi, Any kind soul can help with this? Reposting: The trunk version of Boost.MultiIndex introduces support for initializer list, which seems to work fine with regression tests except for intel-linux-14.0.0: http://tinyurl.com/pclssoe http://tinyurl.com/nzwzpu6 which spits error messages like this (replaced large chunks of text with *** for clarity): ../libs/multi_index/test/test_modifiers.cpp(230): error: no instance of overloaded function "boost::multi_index::detail::hashed_index<***>::insert [***]" matches the argument list argument types are: ({...}) object type is: employee_set_by_name i1.insert({{4,"Vanessa",20,9236},{5,"Penelope",55,2358}}); At first I thought this is failing because for it to work the compiler should not only support initializer lists but also C++11 unified initialization syntax, but I think this is not the problem because a) intel-linux-14.0.0 does indeed seem to support unified initialization syntax, since BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX is not listed in http://tinyurl.com/ndutn2w . b) the following test code also fails: s.assign({0,1,2,3,4,5}); with s a multi_index_container of ints, and this does not depend on unified initialization syntaxes. The error message here, FWIW, is different than before: ../libs/multi_index/test/test_copy_assignment.cpp(56): internal error: assertion failed: node_has_side_effects: bad node kind (shared/cfe/edgcpfe/il.c, line 20611) The tested code seems simple enough, for instance lines 271 and following of multi_index_container.hpp look like: #if !defined(BOOST_NO_CXX11_HDR_INITIALIZER_LIST) multi_index_container( std::initializer_list<Value> list, const ctor_args_list& args_list=ctor_args_list(), const allocator_type& al=allocator_type()) [...] and the ofending assign member function in sequenced_index.hpp is as innocent as: #if !defined(BOOST_NO_CXX11_HDR_INITIALIZER_LIST) void assign(std::initializer_list<value_type> list) { assign(list.begin(),list.end()); } #endif Besides, other libs with initializer list support such as Boost.SmartPtr and Boost.Unordered cope fine with this compiler. Clues? Any help much appreciated. Joaquín M López Muñoz Telefónica Digital

1 0

Policy about non-compliant standard headers
by Andrey Semashev 21 Sep '13

21 Sep '13

Hi, I was reported an issue with Boost.Log which fails to compile with Sun Pro compiler because it has non-compliant standard C headers. I was wondering if there is a policy or recommendation for dealing with this kind of problems. I know there is Boost.Compatibility [1] created exactly for this problem. There are many places I include C headers in my code, so relying on Boost.Compatibility would be an ideal solution for me so I don't have to cripple my code. However, I see that many libraries deal with missing std::C symbols themselves. Why do that and not leave it to Boost.Compatibility? By that I mean require users to add it in include path of the compiler. There is one more point to consider. The issue with the broken standard headers is a sign of an ancient compiler. And if the compiler vendor by 2011 (when Sun Studio 12.3 was released) doesn't manage to ship conforming 1998 headers, I'd still consider it an ancient compiler. Boost recently removed (removing?) support for ancient compilers. So, should I bother supporting this compiler at all? [1] http://www.boost.org/doc/libs/1_54_0/libs/compatibility/

3 7

Boost::Units - mapping from units object to something else
by david.hagood＠gmail.com 21 Sep '13

21 Sep '13

I'm looking at the Boost::Units classes to help eliminate a family of programming errors, but there is one thing that I'm having difficulty with: I have a collection of objects of my own type that pertains to units - these are of a fixed type, with instances per type of unit. I'd like to somehow be able to map from the units constants that Boost uses (e.g. boost:units:si:watts) into my objects (return the correct instance for "watts"). Obviously, there's going to be some hand coding to make that happen - it is unlikely to be possible to generate that mapping automatically. Ideally, what I'd like to do would be to have something like template <typename Unit> struct MyMapper { static const MyUnitInfo info; }; template <> const MyUnitInfo<boost::units::si::watts>::info(/*ctor parms for my type */); and do things like: MyMapper<boost::units::si::watts>::info to get the appropriate structure. However, since all the various Boost units are in a type hierarchy to express dimensionality, I'm at a loss how to compose a template to allow something like that to happen - it certainly isn't as straightforward as the above, since Boost units instances of varying types, not typenames. Likewise, just defining some form of map: std::map<???,MyUnitInfo> mymap = boost::assign::map_list_of (boost::units::si::watts,MyUnitInfo(/* my parms*/)) (boost::units::si::ohms,MyUnitInfo(...)); won't work as the types for the Boost constants are all different as far as I can see. Is there some base type all the Boost::Units constants extend, such that I could test for that?

3 3

Boost.Mock ?
by Mathieu Champlon 21 Sep '13

21 Sep '13

Hello, Would a library for mock objects be of interest ? The documentation can be found here : http://mat007.users.sourceforge.net/boost_mock/ An archive is also available for download there : http://sourceforge.net/projects/mat007.u/files/boost-mock.zip It's been converted from turtle (http://turtle.sourceforge.net/) which was mentioned on the mailing-list a couple of times in the past. There is a catch in that it needs Boost.Test from the release branch and doesn't compile with the trunk. The changes are minimal though and I can provide a patch if anyone is interested. Would the library be worth a review ? In the meanwhile I would be highly interested in any feedback ! Thank you, MAT.

4 4

Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a
by Renato Forti 20 Sep '13

20 Sep '13

Hi All, I have a new version of Boost.Application! In this release all requested features that boost users suggested (in boost user group) are addressed, based on release 1 and release 2, including: 1) Provide more "Boost Way" interface 2) Use Boost.Parameter to give flexibility for future extensions. 3) Access and change environment variables. 4) Simple class (shared_library) to allow use of dynamic libs as plug-in (extending application). 5) Wide string support (Windows). 6) Use Boost.System on Error Handling 7) Setup module for windows service installation. To install, download file: https://downloads.sourceforge.net/project/boostapp/Boost.Application_beta_3a .zip?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fboostapp%2F&ts=1379614495& use_mirror=master or https://sourceforge.net/projects/boostapp/files/ and copy application to your boost installation folder! You don't need build it, the lib is header only, but have some dependences. The documentation is still pretty bad, but it is the right place for you to start with lib! Please, send your questions, to: re.tf(a)acm.org Thanks -- Renato

5 7

[asio] Compilation failures on mingw
by Andrey Semashev 20 Sep '13

20 Sep '13

Hi, I'm seeing test failures on MinGW [1], which are probably caused by commit 85764 [2]. Could this be fixed? [1] <http://www.boost.org/development/tests/trunk/developer/MinGW-32%20jc-bell-c…> [2] <https://svn.boost.org/trac/boost/changeset/85764>

1 0