[boost] Re: [range] update on ADL hooks

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-23 17:15:33

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:4241E71B.8060007_at_boost-consulting.com...
| Thorsten Ottosen wrote:
| > This changes the extension protocol
| > to overiding these three functions:
| >
| > range_adl_begin()
| > range_adl_end()
| > range_adl_size()
| >
| > Any comments before I commit?
| >
|
| There is a larger question of how to handle ADL customization points in
| general. I like the approach you're proposing, but I dislike the naming
| of the above functions. The "adl" can go, IMO,

yes, I would have liked that, but it turned out we clashed with
range_size<R>::type

| and there should be a
| "boost" in there somewhere. I suggest:
|
| boost_range_begin()
| boost_range_end()
| boost_range_size()
|
| In general, boost libraries that use ADL customization points should
| name the functions:
|
| boost_[library]_[function]()
|
| The idea is that these overloads are going to appear in users' code, in
| their namespace. From a maintenence standpoint, "boost_range_begin"
| announces more clearly that this function has to do with the Boost.Range
| library than "range_adl_begin".
|
| Comments?

I do like that convention for boost.range.
But it doesn't seem to apply to all ADL customization points;
for example, in the pointer container lib

new_clone()
delete_clone()

are found with ADL from within the
heap_clone_allocator:

template< class T >
T* heap_clone_allocator::allocate_clone( const T& r )
{ return new_clone(r); }

Free-standing functions seems to have slightly different
goals.

One consequence of using the name
boost_range_begin() is that the users code won't
work with the next standard library. I would like to retain
compatibility if possible.

-Thorsten