[regex] MipsPro warnings in boost/regex/pending/static_mutex.hpp (1.33.0)
The mipspro build of regex gives repeated warnings in static_mutex.hpp: mipspro-C++-action bin/boost/libs/regex/build/libboost_regex.so/mipspro/debug/cpp_regex_traits.o cc-1460 CC: WARNING File = /tmp_mnt/netDISKS/cgi/IRIX4/cgi/vendor/library/boost/boost_1_33_0/boost/regex/pending/static_mutex.hpp, Line = 69 Function function "boost::scoped_static_mutex_lock::locked" is redeclared "inline" after being called. inline bool scoped_static_mutex_lock::locked()const ^ I fixed it by declaring both 'operator void const*()' and 'bool locked()' inline in all 3 sections of the header: diff -u -r1.1 -r1.2 --- boost/regex/pending/static_mutex.hpp 2005/08/12 17:26:18 1.1 +++ boost/regex/pending/static_mutex.hpp 2005/08/16 16:49:44 1.2 @@ -52,8 +52,8 @@ public: scoped_static_mutex_lock(static_mutex& mut, bool lk = true); ~scoped_static_mutex_lock(); - operator void const*()const; - bool locked()const; + inline operator void const*()const; + inline bool locked()const; void lock(); void unlock(); private: @@ -99,8 +99,8 @@ public: scoped_static_mutex_lock(static_mutex& mut, bool lk = true); ~scoped_static_mutex_lock(); - operator void const*()const; - bool locked()const; + inline operator void const*()const; + inline bool locked()const; void lock(); void unlock(); private: @@ -154,8 +154,8 @@ public: scoped_static_mutex_lock(static_mutex& mut, bool lk = true); ~scoped_static_mutex_lock(); - operator void const*()const; - bool locked()const; + inline operator void const*()const; + inline bool locked()const; void lock(); void unlock(); private: -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
The mipspro build of regex gives repeated warnings in static_mutex.hpp:
mipspro-C++-action bin/boost/libs/regex/build/libboost_regex.so/mipspro/debug/cpp_regex_traits.o cc-1460 CC: WARNING File = /tmp_mnt/netDISKS/cgi/IRIX4/cgi/vendor/library/boost/boost_1_33_0/boost/regex/pending/static_mutex.hpp, Line = 69 Function function "boost::scoped_static_mutex_lock::locked" is redeclared "inline" after being called.
inline bool scoped_static_mutex_lock::locked()const ^
I fixed it by declaring both 'operator void const*()' and 'bool locked()' inline in all 3 sections of the header:
hmm my fix was, to reorder the file a bit... basically swapping the order of deffinitions of the two functions. Kevin --- boost/regex/pending/static_mutex.hpp Tue Aug 16 08:57:19 2005 +++ include/boost-1_33/boost/regex/pending/static_mutex.hpp Fri Jan 21 17:22:16 2005 @@ -61,14 +61,14 @@ bool m_have_lock; }; -inline bool scoped_static_mutex_lock::locked()const +inline scoped_static_mutex_lock::operator void const*()const { - return m_have_lock; + return locked() ? this : 0; } -inline scoped_static_mutex_lock::operator void const*()const +inline bool scoped_static_mutex_lock::locked()const { - return locked() ? this : 0; + return m_have_lock; } } // namespace boost -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Kevin Wheatley wrote:
hmm my fix was, to reorder the file a bit... basically swapping the order of deffinitions of the two functions.
That works, too, but if someone modifies the file in the future, the ordering might change again. Apparently g++ doesn't care, so it would be easy for a developer to let the same kind of problem back into the code. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
That works, too, but if someone modifies the file in the future, the ordering might change again. Apparently g++ doesn't care, so it would be easy for a developer to let the same kind of problem back into the code.
I plan to declare them both class-inline as the fix, however I believe that your compiler is at fault here and that the original code was legal, so there's always the possibility of this occurring somewhere in Boost again, especially as no other compiler cares about this. John.
participants (2)
-
John Maddock -
Kevin Wheatley -
Richard Hadsell