On Wed, Aug 20, 2014 at 8:27 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 19/08/14 19:00, Beman Dawes wrote:
On Tue, Aug 19, 2014 at 11:55 AM, Peter Dimov
wrote: Beman Dawes wrote:
The intent was always to submit is_iterator to Boost, but we never got
around to it. Now I need it in Boost.Filesystem, so I'd rather see it go in type traits than just sticking it into boost/filesystem/detail.
Out of curiosity, why do you need it?
Like Howard, for SFINAE. The specific case is implementing the Filesystem TS, which in class path has this:
template <class Source> path(const Source& source);
Source can be a iterator to a NTCTS or a container. The value_type may be one of 5 char types, and may be the same or different from the value_type of the path. There are six path members templated on Source. I can reduce all that complexity to this implementation for the ctor, and then reused detail::append() to implement the five other member functions.
{ detail::append(source, m_pathname); }
detail::append() has four overloads. enable_if using is_iterator<> distinguishes which overload should be selected.
Why do you want to implement this with SFINAE?
Good question. The actual constructor needs SFINAE to avoid over-aggressive use as an automatic conversion, so it was on my mind, but there is no reason the implementation needs to use SFINAE.
SFINAE for many cases scales badly both in terms of code management and scalability.
Agreed.
You're better off using overloading or class template (partial) specialization inside the implementation of the library.
That occurred to me yesterday, and I'm in process of doing the implementation with tag dispatched overloads. The code looks much cleaner. But as far as this discussion is concerned, is_iterator (or maybe is_input_iterator) is needed to drive the tag selection, so the question remains whether to add it to type_traits or to filesystem/detail. IFAICS there is enough motivation and interest to make it worth adding to boost.type_traits, but John as maintainer has the final say on that. --Beman