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? SFINAE for many cases scales badly both in terms of code management and scalability. You're better off using overloading or class template (partial) specialization inside the implementation of the library.