- Boost - lists.boost.org

next version dates
by Andy Tompkins 05 May '11

05 May '11

Hi, Has it been decided the dates relevant to the next version? I have only looked here (http://www.boost.org/development/index.html) and didn't see anything. I'm not trying to change / hurry or delay anything. I just want to start moving some changes from trunk to release, but I work slowly and want to start closer to the beginning of a release, not closer to the end of one. Regards, Andy Tompkins.

6 12

[foreach] Warning with gcc-4.6.0 and -Wconversion
by Philipp Reh 05 May '11

05 May '11

gcc-4.6.0 made Boost.foreach unusable in 1.46.1 because the rvalue detection no longer works. Now, there is a fix in trunk for it but it has a nasty side effect, namely a warning that is emitted whenever foreach is used with an rvalue and -Wconversion is turned on. Sadly, this warning cannot be ignored by including Boost with -isystem because the code is generated by a macro, obviously. Here is a simple program to reprdouce this: #include <boost/foreach.hpp> #include <iostream> #include <ostream> #include <vector> typedef std::vector< int > int_vector; int_vector const test() { int_vector ret(2, 2); return ret; } int main() { BOOST_FOREACH( int_vector::const_reference ref, test() ) std::cout << ref << '\n'; } This prints the following warning: test.cpp:21:2: warning: choosing ‘boost::foreach_detail_::rvalue_probe<T>::operator boost::foreach_detail_::rvalue_probe<T>::value_type() [with T = const std::vector<int>, boost::foreach_detail_::rvalue_probe<T>::value_type = const std::vector<int>]’ over ‘boost::foreach_detail_::rvalue_probe<T>::operator T&() const [with T = const std::vector<int>]’ [-Wconversion] test.cpp:21:2: warning: for conversion from ‘boost::foreach_detail_::rvalue_probe<const std::vector<int> >’ to ‘const int_vector’ [-Wconversion] test.cpp:21:2: note: because conversion sequence for the argument is better I would be glad if this could be fixed somehow because -Wconversion is a crucial warning option to me.

3 3

Boost.Locale and the standard "message" facet
by Vicente BOTET 05 May '11

05 May '11

Hi, I was wondering how Boost.Locale is related to the standard message facet which is used to translate messages. Note that the facet interface work with integer identifiers avoiding all the issues raised by the get_text/translate functions provided by Boost.Locale. Is there any reason Boost.Locale could not follow the standard design? What are the advantages of the Boost.Locale design? Best, Vicente

4 6

[config] Macro BOOST_NO_NOEXCEPT is required
by Takaya Saito (SubaruG) 05 May '11

05 May '11

http://thread.gmane.org/gmane.comp.lib.boost.devel/214978 I think the macro BOOST_NO_NOEXCEPT ( or BOOST_NO_0X_NOEXCEPT ) is required soon. How's the status now?

5 7

result_of overloaded member function?
by Arno Schödl 05 May '11

05 May '11

Hello, is there a way to get the result type of an overloaded member function? Something like: template< class T, class A > typename boost::result_of< T::func(A) >::type invoke( T& t, A& a ) { return t.func(a); } Thanks for help, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 3

[Convert] Not a review
by Phil Endecott 05 May '11

05 May '11

Dear All, I've not looked at this library in anything like enough detail to write a proper review, though I have followed a fair amount of the discussion both during the review and during previous discussions of a "better lexical_cast". My view comes down to this: there are zillions of different ways of doing this (both syntax and semantics) and no solution can keep everyone happy (as evidenced particularly by the previous discussions). But that doesn't matter, because every single C++ programmer is capable of writing their own conversion functions that work exactly how they want them to work, if they have the right building blocks. The building blocks are things like C's strto*(), etc. Personally, I prefer thin wrappers like these ones: template <typename ITER> long int strtol(ITER begin, ITER end) { ... } template <int N> long int strtol(const char (&s) [N]) { return strtol(&s[0],&s[N]); } inline long int strtol(std::string s) { return strtol(s.begin(),s.end()); } For variations on error policy I add words like "try", "must" or "maybe" to the function name; similarly for hex and other variations. But I don't suggest that these are going to suit other people. Why should we try to find a "one size fits all" solution to this problem? In my humble opinion, Boost does not need this functionality. Perhaps some of the lower-level "building blocks" would be useful, though - if things like strto*() are deficient. Regards, Phil.

3 4

Re: [boost] howto: boost.lambda + stl on VS 2010 (SP1) ?
by Peter Dimov 05 May '11

05 May '11

Raffi Enficiaud wrote: > To this point, I thought that using accumulate would be cleaner: > std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); std::accumulate takes a binary function. It doesn't do s += f(*i) as you seem to think, it does s = f(s, *i). So you should probably pass _1 + &_2->*&aa::second to it.

1 0

howto: boost.lambda + stl on VS 2010 (SP1) ?
by Raffi Enficiaud 04 May '11

04 May '11

Hi all, Sorry for bothering with this. I recently encountered some problems in using boost.lambda with Visual 2010 Express, and need some clues for solving the issue (there are many ways around of course). I simply want to accumulate the values of a std::map, and I thought using lambda to access the second member of the map iterator was appropriate. Here is the piece of code: typedef std::map<T1, unsigned short> m_t; m_t m ; // fill m double acc(0); std::for_each(m.begin(), m.end(), var(acc) += & _1->*& m_t::value_type::second); The last line does not compile on Visual (it does on GCC), I have to add a typedef: typedef typename m_t::value_type aa; std::for_each(m.begin(), m.end(), var(acc) += & _1->*& aa::second); Which one is "more correct" ? To this point, I thought that using accumulate would be cleaner: std::accumulate(m.begin(), m.end(), double(0), & _1->*&aa::second); But I have several compilation errors, and on the top of it: 1>(..)/boost-1_46_1\boost/lambda/detail/member_ptr.hpp(512): error C2296: '->*' : illegal, left operand has type 'const rt0 ' 1> boost/lambda/detail/member_ptr.hpp(622) : see reference to function template instantiation 'RET boost::lambda::detail::member_pointer_action_helper<true,false>::apply<RET,A ,B>(A &,B &)' being compiled 1> with 1> [ 1> RET=unsigned short &, 1> A=rt0, 1> B=rt1 1> ] I do not really understand what rt0/rt1 are. The former should be the iterator::value_type and the latter the pointer to member. Most of all, the call with accumulate looks very similar to the for_each one to me. So, is the problem between the keyboard and the chair ? Best, Raffi

1 0

[Block Pointer] make_block
by Phil Bouchard 04 May '11

04 May '11

Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… Is it time for a review? -Phil

7 23

[Spirit Karma] Mutable references formed by pass_container in Karma "repeat" tests
by Doug Gregor 04 May '11

04 May '11

There are a few Karma failures using the latest Clang due to the pass_container detail class forming mutable references: http://www.boost.org/development/tests/release/developer/output/dgregor2-bo… I know that at least some compilers (e.g., GCC) don't diagnose mutable references, but this code is ill-formed account to the standard. Someone want to take a shot at eliminating or factoring out the mutability to avoid these mutable references? - Doug

2 1