Peter Dimov wrote:
> From: "vladimir josef sykora" <[EMAIL PROTECTED]>
> > template <class Sequence>
> > struct foo {
> > };
> >
> > // usage example :
> > typedef boost::mpl::vector<...> types;
> > typedef foo<types> foo_types;
> > std::vector<foo_types> std_vect_foos;
> > std_vect_foos.push_back(foo<types>());
> >
> > When mpl::copy_backward is present (from boost/mpl/insert.hpp for
> example),
> > I get this error (gcc 3.2):
> >
> > `template<class
> > Sequence, class State, class BinaryOp> struct
> boost::mpl::copy_backward'
> > is
> > not a function,
> > conflict with `
> > template<class _BI1, class _BI2> _BI2
> std::copy_backward(_BI1, _BI1,
> > _BI2)'
> > in call to `copy_backward'
> >
> > Since std::copy_backward is found via ADL, I consider this IMHO a
> stringent
> > restriction to the use of mpl::insert & mpl::erase.
>
> This is a g++ specific "feature", or rather a combination of
> two "features".
>
> First, the standard library uses unqualified calls to standard library
> algorithms.
Yep. A bug, IMO.
>
> Second, argument dependent lookup finds class names (such as
> mpl::copy_backward.)
>
> Many people consider both to be defects.
In particular, see library active issue #225
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#225) and core
language issue #218
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#218).
Meanwhile, I am not sure what one can do about it besides switching to
another standard library implementation (e.g. STLPort). Well, I guess I can
"separate" MPL sequences from the algorithms by putting the later into a
nested 'impl' namespace and bringing them back through a 'using' directive
so they are not found via ADL when one mixes MPL sequences and STL:
namespace mpl {
template< typename T1 > struct vector {};
namespace impl {
template< typename Sequence, typename State, typename BinaryOp >
struct copy_backward
{
// ...
};
}
using namespace impl;
} // namespace mpl
int main()
{
std::vector<mpl::vector<int> > v;
v.push_back(mpl::vector<int>()); // OK, even on GCC
}
but I am not sure how reliable that would be. Hmm, it might even work.
Thoughts?
Aleksey
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
