Re: [boost] [Better Enums] More complete release - feedbackrequested

Subject: Re: [boost] [Better Enums] More complete release - feedbackrequested
From: Anton Bachin (antonbachin_at_[hidden])
Date: 2015-06-12 12:18:33

> On Jun 12, 2015, at 09:30, Peter Dimov <lists_at_[hidden]> wrote:
> 
>> But the compiler is able to instantiate those eagerly if a type argument is specified (char) that does not depend on the outer template parameter.
> 
> It is. What I meant was: <snip>
> 
> template <class Ch, class Tr, class Enum>
> inline std::basic_ostream<Ch, Tr>&
> operator <<(std::basic_ostream<Ch, Tr>& os, const Enum& value)
> {
>   return os << value.template _to_basic_string<Ch>();
> }
> 
> You'll have to define _to_basic_string for char, wchar_t, char16_t and char32_t if you want to cover all cases, of course.
> 
> If you want to restrict yourself to char-based streams:
> 
> template <class Tr, class Enum>
> inline std::basic_ostream<char, Tr>&
> operator <<(std::basic_ostream<char, Tr>& os, const Enum& value)
> {
>   return os << value._to_string();
> }

Ah, cool, yes. As long as I only actually support char streams, this looks
almost like an eta-expansion. I was able to use it on std::string as well
(std::basic_string<Char>), and replaced the reference to ios_base::failbit with
std::basic_istream<Char, Tr>::failbit, because ios_base has no template
parameters. This makes the function bodies much cleaner - thanks! It also
reminds me to deal with non-char streams.

I still need hide<> (now renamed) on the return types, however, for SFINAE, to
prevent ambiguity. Actually, this had made operator << a sort of degenerate
case, since both the function header and body depend on the parameter Enum,
so the extra parameters Ch and Tr are not necessary until I have
_to_basic_string<>.

Best,
Anton