check for property 'mutable iterator' #921
Conversation
|
please disregard so far, VS2017 passes the tests, but none of the compilers on Travis 😞 May be their library implementation is not SFINAE friendly when it comes to |
DanielaE
force-pushed
the
feature/property-mutable-iterator
branch
2 times, most recently
from
a9e3fa8
to
58d0416
Compare
|
The hostility towards SFINAE was indeed the killer! Now MSVC, gcc, and clang are happy campers again 😄 |
DanielaE
force-pushed
the
feature/property-mutable-iterator
branch
2 times, most recently
from
bdd8eb5
to
1943b5c
Compare
include/fmt/format.h
Outdated
| template<typename... Ts> | ||
| struct void_ { typedef void type; }; | ||
|
|
||
| template <typename T, typename Enable = void_<>::type> |
There was a problem hiding this comment.
Why void_<>::type and not just void? A comment might be good if this is required.
There was a problem hiding this comment.
Well spotted, this is no longer necessary !
include/fmt/format.h
Outdated
| struct void_ { typedef void type; }; | ||
|
|
||
| template <typename T, typename Enable = void_<>::type> | ||
| struct it_category { typedef int type; }; |
There was a problem hiding this comment.
Do I understand correctly that int is arbitrary here and anything that is not std::output_iterator_tag would do? Why not use void? =)
There was a problem hiding this comment.
Well, void cannot be used as an argument type to a function call. I've settled on std::false_typenow.
| struct it_category<const T*> { typedef int type; }; | ||
|
|
||
| template <typename T> | ||
| struct it_category<T, typename void_<typename T::iterator_category>::type> { |
There was a problem hiding this comment.
So this is basically a SFINAE detection of presence of T::iterator_category? A comment would be nice as well.
There was a problem hiding this comment.
Yeah, I've added a comment to make this clear.
| class is_output_iterator { | ||
| //check for mutability | ||
| template <typename U> | ||
| static decltype(*(internal::declval<U>())) test(std::input_iterator_tag); |
There was a problem hiding this comment.
Why not just return const char&?
There was a problem hiding this comment.
Because dereferencing the iterator is the whole gist of all of this kaboodle. This returns either a const or a non-const refererence. The iterator traits give no clue - in particular with regard to const_iterator type members, and everything else fails on VS2013 as it's extra-finicky with expression-SFINAE.
There was a problem hiding this comment.
Makes sense. I was confused by the use of input_iterator_tag in the write context, but since iterator tags form a class hierarchy it makes sense now.
DanielaE
force-pushed
the
feature/property-mutable-iterator
branch
from
1943b5c
to
7b6e67d
Compare
|
Merged, thanks! |
constrain the
OutputItfunction parameters to be models ofmutable iterators.