Hi there,
I got a bug report that the following code doesn't compile:
#include
template class boost::shared_ptr<int>;
int main(int, char**) {}
The errors this gives under GCC 4.9 are as follows:
In file included from /usr/include/boost/shared_ptr.hpp:17:0,
from /usr/include/boost/tr1/memory.hpp:56,
from foo3.cc:1:
/usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access<T>::type boost::shared_ptr<T>::operator[](std::ptrdiff_t) const [with T = int; typename boost::detail::sp_array_access<T>::type = void; std::ptrdiff_t = long int]':
foo3.cc:2:23: required from here
/usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive]
return px[ i ];
This in particular is with boost 1.54. The problem is however present
on master as well, where it also gives more errors relating to
boost/core/demangle.hpp that I didn't look into.
I went ahead to do some investigation in case the issue ends up being
trivial. We can't use enable_if to disable a particular member
function. Not unless it's a template. Making it a template would lead
to a code like this:
template ::type>, U>::type>
boost::detail::sp_array_access< T >::type operator[] (etc. etc.);
... which is not C++98, and I don't have ideas how to C++98-ify it while
also having it do what we want without breaking API. (The indirection
through U may not be necessary, I'm not in fact sure, but that doesn't
change anything.)
One way that I can see is extracting element_type * px to a base class
(say, boost::detail::sp_operator_at) that either does or does not define
operator[] (which would then use the px). But that implies some amount
of code motion, and not knowing what your position would be, I didn't
want to blindly go ahead and start moving stuff around.
So, would a patch to the effect described above be possibly acceptable?
Thanks,
Petr.
