[move] Build failures in develop
Hi, I'm seeing lots of build errors that originate from Boost.Move, such as: In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_function<void ()> > >' : T::type ~~~^~~~ See the full error logs: http://www.boost.org/development/tests/develop/developer/output/marshall-mac... http://www.boost.org/development/tests/develop/developer/output/teeks99-08b-... http://www.boost.org/development/tests/develop/developer/output/teeks99-test... I didn't change Boost.Log for quite some time, so there seems to have been some breaking change. Could this be fixed?
El 30/09/2014 9:33, Andrey Semashev escribió:
Hi,
I'm seeing lots of build errors that originate from Boost.Move, such as:
In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_function<void ()> > >' : T::type
move_detail::is_rv is an implementation detail, and it previously inherited from integral_constant (inheriting with a "type" member) to just holding static const bool = xxx to minimize dependencies. I will add a workaround, but if you really need that trait, let's move it to the top namespace so that everyone knows it's an interface trait. Best, Ion
On Tuesday 30 September 2014 20:10:41 Ion Gaztañaga wrote:
El 30/09/2014 9:33, Andrey Semashev escribió:
Hi,
I'm seeing lots of build errors that originate from Boost.Move, such as:
In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_ function<void ()> > >'
: T::type
move_detail::is_rv is an implementation detail, and it previously inherited from integral_constant (inheriting with a "type" member) to just holding static const bool = xxx to minimize dependencies.
Ah, right. Since it's an implementation detail I've added a workaround on my side. Are other (public) traits changed this way? If so, that can cause breakage similar to is_rv<>.
I will add a workaround, but if you really need that trait, let's move it to the top namespace so that everyone knows it's an interface trait.
I think I needed it to implement some special constructor logic, which I could not achieve with conventional Boost.Move interface. I can't remember the exact use case I had in mind when I wrote that code. I use that trait to disable templated constructor overloads from being instantiated on rv<> wrappers. Perhaps that would be generally useful.
Le 30/09/14 20:32, Andrey Semashev a écrit :
On Tuesday 30 September 2014 20:10:41 Ion Gaztañaga wrote:
El 30/09/2014 9:33, Andrey Semashev escribió:
Hi,
I'm seeing lots of build errors that originate from Boost.Move, such as:
In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_ function<void ()> > >'
: T::type move_detail::is_rv is an implementation detail, and it previously inherited from integral_constant (inheriting with a "type" member) to just holding static const bool = xxx to minimize dependencies. Ah, right. Since it's an implementation detail I've added a workaround on my side.
Are other (public) traits changed this way? If so, that can cause breakage similar to is_rv<>.
I will add a workaround, but if you really need that trait, let's move it to the top namespace so that everyone knows it's an interface trait. I think I needed it to implement some special constructor logic, which I could not achieve with conventional Boost.Move interface. I can't remember the exact use case I had in mind when I wrote that code.
I use that trait to disable templated constructor overloads from being instantiated on rv<> wrappers. Perhaps that would be generally useful.
Hrr, Boost.Thread uses it also. Vicente
Le 01/10/14 00:09, Ion Gaztañaga a écrit :
El 01/10/2014 0:02, Vicente J. Botet Escriba escribió:
Hrr, Boost.Thread uses it also.
I've pushed a patch that recovers ::type to move_detail::is_rv
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Thanks Ion,
sorry for using private interfaces. I will see what I can done from my side. Vicente
El 01/10/2014 0:38, Vicente J. Botet Escriba escribió:
Le 01/10/14 00:09, Ion Gaztañaga a écrit :
El 01/10/2014 0:02, Vicente J. Botet Escriba escribió:
Hrr, Boost.Thread uses it also.
I've pushed a patch that recovers ::type to move_detail::is_rv
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Thanks Ion,
sorry for using private interfaces. I will see what I can done from my side.
No problem, I'll make it public for 1.58. Do you agree? Ion
On Wed, Oct 1, 2014 at 3:08 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 01/10/2014 0:38, Vicente J. Botet Escriba escribió:
sorry for using private interfaces. I will see what I can done from my side.
No problem, I'll make it public for 1.58. Do you agree?
That would be great. Thanks, Ion. Just post here if we need to change our code to use the public version.
participants (3)
-
Andrey Semashev
-
Ion Gaztañaga
-
Vicente J. Botet Escriba