- Boost - lists.boost.org

boost::system::error_code and std::error_code
by Vinícius dos Santos Oliveira 09 Jun '14

09 Jun '14

Is there any plans to add a conversion operator from boost::error_code to std::error_code or alike? I was designing a class that I'd like to be usable pleasantly with boost variant of error_code and C++11 variant of error_code, but my design was getting rather complicated (multiple inheritance, templates with no type deduction, ...) and I give up after I came to the make_error_code function, which would be called by the error_code constructor if is_error_code_enum was specialized (which was) and we cannot overload function based on return type (then would be difficult to make it work with boost::system::error_code and std::error_code). TL;DR: What the plans for migration from boost::system::error_code to std::error_code? -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 2

[modularization] Moving <boost/math/common_factor_ct.hpp> to TypeTraits
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, |moving boost/math/common_factor_ct.hpp to TypeTraits would remove the dependency from Interprocess, Pool and Variant to Math. | /interprocess/ <http://www.pdimov.com/tmp/report-6d1f271/interprocess.html> |<boost/math/common_factor_ct.hpp>| * from |<boost/interprocess/allocators/detail/node_pool.hpp>| /pool/ <http://www.pdimov.com/tmp/report-6d1f271/pool.html> |<boost/math/common_factor_ct.hpp>| * from |<boost/pool/pool.hpp>| /variant/ <http://www.pdimov.com/tmp/report-6d1f271/variant.html> |<boost/math/common_factor_ct.hpp>| || * from |<boost/variant/variant.hpp>| Vicente

4 8

core/swap tests appear in core?
by Peter Dimov 08 Jun '14

08 Jun '14

Does anyone know why the core/swap tests, which are in a separate Jamfile, core/test/swap/Jamfile.v2, and have their own line in status/Jamfile.v2, core/test/swap # test-suite core/swap still appear in http://www.boost.org/development/tests/develop/developer/core.html instead of on their own page, core/swap? When they were in utility they did appear on utility/swap: http://www.boost.org/development/tests/develop/developer/utility-swap.html Or, to be more precise, does anyone know how we can make them appear on their own page. :-)

4 5

QVM library
by Emil Dotchevski 08 Jun '14

08 Jun '14

I've updated the QVM library (which hasn't been reviewed yet), including minor changes plus a workaround for what appears to be a parsing bug in msvc-12: http://www.revergestudios.com/boost-qvm/ -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode P.S. Perhaps STL can confirm, I'm guessing that the MSVC bug was introduced by the added rvalue reference support, which interfered with the heuristics MSVC uses to attempt to successfully parse non-conformant code that doesn't use mandatory "typename". This can be seen for example in q.hpp, which used to contain functions like: template <class A,class B> typename enable_if_c< is_q<A>::value && is_q<B>::value, A &>::type operator-=( A & a, B const & b ) which I had to change to: template <class A,class B> typename enable_if< msvc_parse_bug_workaround::quats<A,B>, A &>::type operator-=( A & a, B const & b ) where namespace msvc_parse_bug_workaround { template <class A,class B> struct quats { static bool const value=is_q<A>::value && is_q<B>::value; }; }

2 1

[modularization] chrono/stopwatches
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

Hi, please, could you create a submodule for chrono/stopwatches, or just remove the directory of the files included on the chrono module, as it has not been really released. If this is not possible, I can remove the directory temporarily. Best, Vicente

1 0

[modularization] mpl -> utility dependency
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

The dependency mpl -> utility |<boost/utility/value_init.hpp>| from |<boost/mpl/for_each.hpp>||| |is there just for this line | // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. value_initialized<arg> x; Do we really need to use this value_initialized class to ensure initialization with current compilers? Vicente

2 1

[graph_parallel] Unpushed changes in develop
by Daniel James 08 Jun '14

08 Jun '14

Hi, The develop branch of the super project was manually updated to use a more recent commit that hadn't been pushed to develop. Unfortunately my script for updating the super project doesn't check for this situation and could reset the library to the older version from develop at an arbitrary point (it doesn't normally because it's incremental, but occasionally a non-incremental run will set everything to the current develop branch). So I pushed the current revision to develop. It's just a merge commit that doesn't actually change any code, so I assume it was an oversight that it wasn't pushed. I hope that's okay. Daniel

1 0

[parameter] Literate test, and other changes.
by Daniel James 08 Jun '14

08 Jun '14

Hi, Looking at parameter's history there are three groups of unmerged changes: - "literate" tests extracted from the documentation (plus some small documentation changes) - Stephen Kelly's changes removing workarounds for old compilers - a warning fix - https://github.com/boostorg/parameter/commit/b5e57e0024ae51f5e706eff50e8602… I think they're all okay to merge, although I'm not sure about the literate tests, does anyone know why they weren't merged earlier? They don't show up in the test results, although maybe they're not meant to. Daniel

1 1

Newer dependency report
by Peter Dimov 08 Jun '14

08 Jun '14

http://www.pdimov.com/tmp/report-b932921/module-overview.html http://www.pdimov.com/tmp/report-b932921/module-levels.html

1 0

[Fusion] Heterogeneous comparison rationale?
by Louis Dionne 08 Jun '14

08 Jun '14

Dear list, Is there a reason why Fusion does not support comparing objects of different types? For example, the following will trigger a compilation error inside the library because there is no operator==(int, X): struct X { }; assert(make_vector(1, 2) != make_vector(1, X{})); In the context of programming with heterogeneous types, one could reasonably argue that the above should compile and pass the assertion. Of course, then the library can't use operator== to compare objects internally, but that's an implementation detail. So I'm really looking for a rationale for that design decision and/or comments from people about which way they think it should be and why. Regards, Louis Dionne

1 0