|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-16 08:03:37
I've been thinking about this issue and wonder if the following
wouldn't solve the problem neatly for both conforming and
non-conforming compilers:
// whatever/foo.h
namespace whatever
{
class foo
{
...
};
// for conforming compilers
unspecified begin(foo const &) { ... };
...
}
// for non-conforming compilers
namespace boost { namespace range {
using whatever::begin;
} }
// boost/range/begin.hpp
namespace boost
{
inline template <T>
unspecified begin(T const & range_i)
{
using boost::range::begin;
return begin(range_i);
}
}
If the author of foo has no other need for begin(), then
whatever/foo.h could be done like this instead:
// whatever/foo.h
namespace whatever
{
class foo
{
...
};
}
namespace boost { namespace range {
unspecified begin(foo const &) { ... };
} }
If whatever::foo belongs to a user of Boost.Range that only uses
conforming compilers, then foo.h only needs to be:
// whatever/foo.h
namespace whatever
{
class foo
{
...
};
unspecified begin(foo const &) { ... };
...
}
If whatever::foo provides get_begin() instead, for whatever
reason, then foo.h becomes:
// whatever/foo.h
namespace whatever
{
class foo
{
...
};
unspecified get_begin(foo const &) { ... };
...
}
namespace boost { namespace range {
inline unspecified begin(foo const & foo_i)
{
return get_begin(foo_i);
}
} }
This approach provides a number of benefits:
- we can use the most obvious name, boost::range::begin, for the
point of customization
- benefits from ADL when supported
- Types in namespace std or built-in types (pointers) can be
retrofitted in boost::range and will work like everything else
(though you must include the appropriate header to get the
required boost::range::begin() overload)
- flexibility for those wishing to support Boost.Range
- non-conformance code can be excised easily later
Did I miss something?
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk