August 2014 - Boost - lists.boost.org

[vmd] Library review
by Matt Calabrese 31 Aug '14

31 Aug '14

Design: As a set of utility macros, there is not too much to be said. The macros that are presented are generally useful and fill some needs that are encountered when doing preprocessor metaprogramming. Implementation: I admittedly haven't examined the implementation itself too closely, but I have used the library in practice with both clang and gcc without problems on a considerably large preprocessor project (~50k lines preprocessor programming), albeit a few years ago. Documentation: I read through the entirety of the documentation and it is fairly good at describing some of the problems faced when doing preprocessor metaprogramming, such as the lack of truly being able to detect emptiness and the implementation weaknesses of certain non-compliant preprocessors. That said, I feel like it focuses a lot on the hairiness of the preprocessor and not enough on the functionality that the library itself provides. For example, the tuple-related macros (being able to deal with something that is a tuple with more tokens after the tuple, for instance) are very useful in preprocessor metaprogramming, but the documentation doesn't do much to explain why. As well, while what to expect from expansion of the macros is described, examples are absent. To be more specific, take these two bits of the documentation: BOOST_VMD_BEGIN_TUPLE http://htmlpreview.github.io/?https://raw.githubusercontent.com/eldiener/va… BOOST_VMD_AFTER_TUPLE http://htmlpreview.github.io/?https://raw.githubusercontent.com/eldiener/va… Although the macros are described, a set of examples could go a long way. For instance something as simple as the following can go quite a long way: BOOST_VMD_AFTER_TUPLE( (int a, float b, char c) const ) // yields: const The above both more directly shows what you can expect from the macro and also may better explain the usefulness. To people experienced with [ab]using the preprocessor, why you want to use these macros is often obvious, but most people are not very familiar with preprocessor metaprogramming and I think the docs sort of need to be aware of that. Examples and a motivation explaining why the particular set of macros provided is important. Perhaps what might be best is to start the documentation with a tutorial that takes the user through the uses that come up in practice when I.E. designing a simple EDSL through preprocessor metaprogramming. Usage: Years ago I used the VMD library when developing [not a boost lib] Boost.Generic. Prior to VMD being around, I had hand-rolled much of the functionality into Boost.Generic that VMD provides, though I very quickly stopped caring about VC++ support. When VMD was in the boost sandbox, I swapped out everything I could with invocations to VMD's macros and it freed me of the maintenance burden of trying to support noncompliant compilers. Needless to say, VMD "just worked" and I find it likely that other people who use the preprocessor in these ways would find VMD just as useful as I have. For my project I was testing with both GCC and Clang and had no problems with anything that VMD provided. Domain familiarity: I've done an embarrassingly large amount of preprocessor metaprogramming and, again, I find this library useful. ===== Overall, I'd say that this library should make it into boost. The biggest thing that it lacks is motivation in documentation, lack of examples, and a practical tutorial, but these should be able to be added before the library would make it into a release. Other than that, I do think there might be some way to roll this into Boost.Preprocessor, but I have no strong feelings on the matter and it's really up to Paul. So this a +1 from me, as long as the documentation gets some improvement. -- -Matt Calabrese

2 1

[conceptcheck] Document using namespace boost.
by Mostafa 31 Aug '14

31 Aug '14

I'm not unfamiliar with Boost.ConceptCheck, though I've used it very infrequently. So, like all familiar but infrequently used libraries I skip to the examples to jog my memory as to their usage. Invariably, if the examples or the tutorial are not complete then I end up repeating past mistakes. This is the case with Boost.ConceptCheck library. All the examples on this page: http://www.boost.org/doc/libs/1_56_0/libs/concept_check/using_concept_check… (which is the quick 5 minute introduction on how to use ConceptCheck) assume some previous "using namespace boost;" declaration, yet that is not documented on that particular page or any previous page. Can this be fixed to save new and infrequent users of the library unneeded head-scratching and wasted time? (I can open a trac ticket if that helps.) Thanks.

1 0

[config] BOOST_NO_CXX11_HDR_FUNCTIONAL and VC++10
by Edward Diener 31 Aug '14

31 Aug '14

While BOOST_NO_CXX11_HDR_FUNCTIONAL is not defined for VC++10 my tests show that std::ref in VC++10 is broken in a very simple case. Here is the code for that case: // test_vc10_refwrapper.cpp #include <functional> class p_functor_class_char { public: p_functor_class_char() : data('A') {} char operator()() { return data; } private: char data; }; void main() { p_functor_class_char pfcc; std::function<char ()> sf(std::ref(pfcc)); } which for VC++10 gives: > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxcallobj(13) : error C2440: 'return' : cannot convert from 'void' to 'char' > Expressions of type void cannot be converted to other types > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(65) : see reference to function template instantiation '_Ret std::tr1::_Callable_obj<_Ty>::_ApplyX<_Rx>(void)' being compiled > with > [ > _Ret=char, > _Ty=std::tr1::reference_wrapper<p_functor_class_char>, > _Rx=char > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(64) : while compiling class template member function 'char std::tr1::_Impl_no_alloc0<_Callable,_Rx>::_Do_call(void)' > with > [ > _Callable=_MyWrapper, > _Rx=char > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(386) : see reference to class template instantiation 'std::tr1::_Impl_no_alloc0<_Callable,_Rx>' being compiled > with > [ > _Callable=_MyWrapper, > _Rx=char > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxfunction(369) : see reference to function template instantiation 'void std::tr1::_Function_impl0<_Ret>::_Reset0o<_Myimpl,_Fty,std::allocator<_Ty>>(_Fty,_Alloc)' being compiled > with > [ > _Ret=char, > _Fty=std::tr1::reference_wrapper<p_functor_class_char>, > _Ty=std::tr1::_Function_impl0<char>, > _Alloc=std::allocator<std::tr1::_Function_impl0<char>> > ] > c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\functional(126) : see reference to function template instantiation 'void std::tr1::_Function_impl0<_Ret>::_Reset<std::tr1::reference_wrapper<_Ty>>(_Fty)' being compiled > with > [ > _Ret=char, > _Ty=p_functor_class_char, > _Fty=std::tr1::reference_wrapper<p_functor_class_char> > ] > test_vc10_refwrapper.cpp(15) : see reference to function template instantiation 'std::tr1::function<_Fty>::function<p_functor_class_char>(std::tr1::reference_wrapper<_Ty>)' being compiled > with > [ > _Fty=char (void), > _Ty=p_functor_class_char > ] With VC++11 and VC++12 this has been fixed. Using boost::function and boost::ref there are no problems in VC++10. I realize that this might not really be an issue in Boost but I was still wondering if this is a known problem with any Boost developers. I ran into it during tests, where I was letting BOOST_NO_CXX11_HDR_FUNCTIONAL determine whether to use std or boost versions of the functionality in the C++11 <functional> header.

1 0

[review] [vmd] Last day of review period - reviewers needed
by Steven Watanabe 30 Aug '14

30 Aug '14

AMDG The limited amount of feedback has been generally positive, but I haven't seen any full reviews, yet. If anyone is planning to review the library, please let me know. In Christ, Steven Watanabe

3 2

Trac getting spammed
by John Maddock 30 Aug '14

30 Aug '14

We seem to be getting more than the usual amount of spam on the Trac recently, I've deleted quite a few, but I bet there are others I haven't seen. Latest is https://svn.boost.org/trac/boost/ticket/10358 Anyone any ideas for blocking these guys? Thanks, John.

9 13

Problem with BOOST_NO_CXX11_VARIADIC_TEMPLATES in gcc.hpp
by Richard Hadsell 30 Aug '14

30 Aug '14

I think I found a problem in config/compiler/gcc.hpp in Boost 1.56.0. I was trying to come up with a workaround for a bug having to do with variadic templates, when compiling with g++ 4.5.1 (on Linux Fedora 14). Modifying line 160 to turn on BOOST_NO_CXX11_VARIADIC_TEMPLATES for g++ versions earlier than 4.7 had not effect. I discovered that the version test in line 160 has no effect, because it is in a block (lines 153-164) that only pertains to g++ 4.2 or earlier, if compiled with -std=c++0x. The block for versions 4.3 and later (lines 145-151) always define BOOST_HAS_VARIADIC_TMPL and never BOOST_NO_CXX11_VARIADIC_TEMPLATES. I think that is a mistake, at least partially, because proposal N2555 is only supported in version 4.4. At any rate, someone should look at these lines and make some sense of them. The GCC support table shows general support for variadic templates in 4.3 and support for N2555 (with a long name) in 4.4. Furthermore, the bug that produces a message like this: "sorry, unimplemented: cannot expand 'Args ...' into a fixed-length argument list" was only fixed in g++ 4.7.0 (according to a bug report). That issue could also use a guard macro, as was done in one of the boost libraries ( BOOST_CONTAINER_UNIMPLEMENTED_PACK_EXPANSION_TO_FIXED_LIST). -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

4 8

[exception] Demangling support not merged to master?
by Andrey Semashev 30 Aug '14

30 Aug '14

Hi, Sadly, I discovered that the support for type name demangling in Boost.Exception did not make it into 1.56. It's still not merged to master. The tests look green, could this change be merged to master?

2 3

[move] boost::move incorrect documentation?
by Mostafa 30 Aug '14

30 Aug '14

Here http://www.boost.org/doc/libs/1_56_0/doc/html/boost/move_idp159681920.html it states: "This function provides a way to convert a reference into a rvalue reference in compilers with rvalue references. For other compilers converts T & into ::boost::rv<T> & so that move emulation is activated." But in <boost/move/utility.hpp> I see: template <class T> inline typename ::boost::move_detail::enable_if_c < enable_move_utility_emulation<T>::value && !has_move_emulation_enabled<T>::value, T&>::type move(T& x) { return x; } Therefore shouldn't the above be: "This function provides a way to convert a reference into a rvalue reference in compilers with rvalue references. For other compilers if T is Boost.Move enabled type then it converts T & into ::boost::rv<T> & so that move emulation is activated, else it returns T &."

2 1

Boost Build and -Wall
by Emil Dotchevski 29 Aug '14

29 Aug '14

I see that in Boost Build <warnings>on translates to -Wall. What value do I specify for <warnings> to get the compiler-default warnings level? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 4

Boost Build Qt5 support on MACOSX?
by Emil Dotchevski 29 Aug '14

29 Aug '14

Hello, I downloaded Qt and installed it into its default location on mac os x, then tried to initialize it with: using qt5 : /users/<user_name>/Qt/5.3/clang_64 ; I don't know if the above is the correct way to initialize the qt5 support, but I get bad include directories, e.g. #include <QtGui/QWindow> won't work. Searching the Qt directories reveals that the file QWindow is found under Qt/5.3/clang_64/lib/QtGui.framework/Versions/5/Headers. So what is the right way to do this? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0