Overloads for tag dispatching (Was Re: [v3] doxygen style tweaks)

[Jonathan Wakely]

On Wed, Jul 21, 2004 at 01:51:18PM -0500, Benjamin Kosnik wrote:

> >As an aside, the std::find() entries just below those std::fill_n() ones
> >include the overloads used for despatching on the iterator_type tags;
> >should those overloads be in __gnu_cxx rather than std ?

To be clear - I mean the functions themselves, not just the docs.
And I should have said __gnu_internal, not __gnu_cxx.

> What's the URL?

http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespacestd.html#a159

Or include/bits/stl_algo.h line 201.

That is the std::find() overload taking a random_accesss_iterator_tag.
Since tag dispatching on iterator_category is an implementation detail,
not a requirement of the standard, I was wondering whether

template<typename RandomAccessIterator, typename Type>
  RandomAccessIterator find (RandomAccessIterator first,
                             RandomAccessIterator last, const Type &__val,
                             random_access_iterator_tag);
and
template<typename InputIterator, typename Type>
  InputIterator find (InputIterator first, InputIterator last,
                      const Type &__val, input_iterator_tag);

should be in __gnu_cxx, not std (and similarly for all tag dispatch
overloads in <algorithm>).

A user who accidentally called std::find() with 4 args, not 3, would get
a diagnostic saying there was no matching function, but would also get
something like this:

include/c++/3.4.1/bits/stl_algo.h:171:
note: candidates are: _InputIterator std::find(_InputIterator,
_InputIterator, const _Tp&, std::input_iterator_tag) [with
_InputIterator = int*, _Tp = int]
include/c++/3.4.1/bits/stl_algo.h:201:
note:                 _RandomAccessIterator
std::find(_RandomAccessIterator, _RandomAccessIterator, const _Tp&,
std::random_access_iterator_tag) [with _RandomAccessIterator = int*, _Tp
= int]

The extra diagnostic adds unnecessary noise, which wouldn't happen if
the overloads were in __gnu_internal or similar.

If the answer is that they should be in __gnu_internal, I'll prepare the
patch to move them (to apologise for making more work :)

jon

-- 
"We're doomed!"
	- C3PO