[multi_array] Warnings on upgrade to 1.34.1
This reindex function in multi_array/view.hpp is apparently being compiled with BOOST_NO_SFINAE not being defined. template <class BaseList> #ifdef BOOST_NO_SFINAE void #else typename disable_if<typename boost::is_integral<BaseList>::type,void >::type #endif reindex(const BaseList& values) { boost::function_requires< detail::multi_array::CollectionConcept<BaseList> >(); boost::detail::multi_array:: copy_n(values.begin(),num_dimensions(),index_base_list_.begin()); origin_offset_ = this->calculate_indexing_offset(stride_list_,index_base_list_); } I am getting the following error, because naturally there is no return statement. /usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp: In member function `boost::disable_if<boost::is_integral<BaseList>::type, void>::type boost::detail::multi_array::const_multi_array_view<T, NumDims, TPtr>::reindex(const BaseList&)': /usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp:89: warning: no return statement in function returning non-void Is there a fix for this? Shouldn't there be another #ifdef with a return statement? How do I know if I should define BOOST_NO_SFINAE? Sincerely, Mark Ruzon
Hi Mark, Do you have a small example program that exhibits the problem that you are having? thanks, ron On Aug 16, 2007, at 12:38 PM, Mark Ruzon wrote:
This reindex function in multi_array/view.hpp is apparently being compiled with BOOST_NO_SFINAE not being defined.
template <class BaseList> #ifdef BOOST_NO_SFINAE void #else typename disable_if<typename boost::is_integral<BaseList>::type,void >::type #endif reindex(const BaseList& values) { boost::function_requires< detail::multi_array::CollectionConcept<BaseList> >(); boost::detail::multi_array:: copy_n(values.begin(),num_dimensions(),index_base_list_.begin ()); origin_offset_ = this->calculate_indexing_offset(stride_list_,index_base_list_); }
I am getting the following error, because naturally there is no return statement.
/usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp: In member function `boost::disable_if<boost::is_integral<BaseList>::type, void>::type boost::detail::multi_array::const_multi_array_view<T, NumDims, TPtr>::reindex(const BaseList&)': /usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp:89: warning: no return statement in function returning non-void
Is there a fix for this? Shouldn't there be another #ifdef with a return statement? How do I know if I should define BOOST_NO_SFINAE?
Sincerely, Mark Ruzon
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ronald Garcia <garcia <at> cs.indiana.edu> writes:
Hi Mark,
Do you have a small example program that exhibits the problem that you are having?
thanks, ron
On Aug 16, 2007, at 12:38 PM, Mark Ruzon wrote:
This reindex function in multi_array/view.hpp is apparently being compiled with BOOST_NO_SFINAE not being defined.
template <class BaseList> #ifdef BOOST_NO_SFINAE void #else typename disable_if<typename boost::is_integral<BaseList>::type,void >::type #endif reindex(const BaseList& values) { boost::function_requires< detail::multi_array::CollectionConcept<BaseList> >(); boost::detail::multi_array:: copy_n(values.begin(),num_dimensions(),index_base_list_.begin ()); origin_offset_ = this->calculate_indexing_offset(stride_list_,index_base_list_); }
I am getting the following error, because naturally there is no return statement.
/usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp: In member function `boost::disable_if<boost::is_integral<BaseList>::type, void>::type boost::detail::multi_array::const_multi_array_view<T, NumDims, TPtr>::reindex(const BaseList&)': /usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp:89: warning: no return statement in function returning non-void
Is there a fix for this? Shouldn't there be another #ifdef with a return statement? How do I know if I should define BOOST_NO_SFINAE?
Sincerely, Mark Ruzon
_______________________________________________ Boost-users mailing list Boost-users <at> lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ron, It took a few weeks, but I have something small and repeatable: #include <boost/multi_array.hpp> int main() { } Put this in a file called go.cpp. Then compile with: g++32 -g -Wall -c go.cpp -o go.o -I/usr/include/c++/boost_1_34_1 where g++32 -v yields: Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --disable-libgcj --host=x86_64-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3) and this is a 64-bit machine: Linux blah.blah.com 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 09:40:21 EST 2007 x86_64 x86_64 x86_64 GNU/Linux You ought to get the same error listed below. Thanks, Mark Ruzon
Hi Mark, Here's an experiment for you: Could you try changing the line below to: disable_if<typename boost::is_integral<BaseList>,void >::type (that is, remove the '::type' from 'is_integral<BaseList>::type') and let me know if that changes anything. There appears to be a bug in your version of gcc, but I don't have a copy of it to experiment with. Cheers, ron On Aug 27, 2007, at 7:35 PM, Mark Ruzon wrote:
Ronald Garcia <garcia <at> cs.indiana.edu> writes:
Hi Mark,
Do you have a small example program that exhibits the problem that you are having?
thanks, ron
On Aug 16, 2007, at 12:38 PM, Mark Ruzon wrote:
This reindex function in multi_array/view.hpp is apparently being compiled with BOOST_NO_SFINAE not being defined.
template <class BaseList> #ifdef BOOST_NO_SFINAE void #else typename disable_if<typename boost::is_integral<BaseList>::type,void
::type #endif reindex(const BaseList& values) { boost::function_requires< detail::multi_array::CollectionConcept<BaseList> >(); boost::detail::multi_array:: copy_n(values.begin(),num_dimensions(),index_base_list_.begin ()); origin_offset_ = this->calculate_indexing_offset (stride_list_,index_base_list_); }
I am getting the following error, because naturally there is no return statement.
/usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp: In member function `boost::disable_if<boost::is_integral<BaseList>::type, void>::type boost::detail::multi_array::const_multi_array_view<T, NumDims, TPtr>::reindex(const BaseList&)': /usr/include/c++/boost_1_34_1/boost/multi_array/view.hpp:89: warning: no return statement in function returning non-void
Is there a fix for this? Shouldn't there be another #ifdef with a return statement? How do I know if I should define BOOST_NO_SFINAE?
Sincerely, Mark Ruzon
_______________________________________________ Boost-users mailing list Boost-users <at> lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ron,
It took a few weeks, but I have something small and repeatable:
#include <boost/multi_array.hpp>
int main() { }
Put this in a file called go.cpp. Then compile with:
g++32 -g -Wall -c go.cpp -o go.o -I/usr/include/c++/boost_1_34_1
where g++32 -v yields:
Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --disable-libgcj --host=x86_64-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3)
and this is a 64-bit machine:
Linux blah.blah.com 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 09:40:21 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
You ought to get the same error listed below.
Thanks, Mark Ruzon
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ronald Garcia <garcia <at> cs.indiana.edu> writes:
Hi Mark,
Here's an experiment for you:
Could you try changing the line below to: disable_if<typename boost::is_integral<BaseList>,void >::type
I tried your fix, Ron, and it didn't change the error at all. Any other suggestions? Thanks, Mark Ruzon
participants (3)
-
Mark Ruzon
-
Mark Ruzon
-
Ronald Garcia