- 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