Re: [boost] [type_traits] Interest in is_iterator type trait?

Subject: Re: [boost] [type_traits] Interest in is_iterator type trait?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2014-08-20 08:27:43

On 19/08/14 19:00, Beman Dawes wrote:
> On Tue, Aug 19, 2014 at 11:55 AM, Peter Dimov <lists_at_[hidden]> 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.