5

I am using the C++03 method to detect the presence of a function at compile time. I have to use this method rather than the void_t method even though I'm using C++14 because I have to support GCC 4.9, and it errors when using the void_t method (strangely only Ubuntu 14's GCC 4.9 has this problem, not Fedora's, but it's fixed across the board in GCC5+ AFAICT).

Specifically I am checking for the presence of operator<<(std::ostream&, const T&) so that I can have a pretty print function that takes any type. When the function gets called, you get the regular ostream output if the type supports it, and you get a fallback message about there being no implementation when the operator is not defined. Code at the bottom.

This has worked pretty well for me so far, until I ran into a type defined by a 3rd party library that I can't change. The type has implicit conversion operators to both bool and float. This means when the SFINAE check is done to see if s << t is valid I get a compiler error because s << t is ambiguous. In this case I'd prefer for it to just report there is no implementation like normal, rather than try to pick an implicit conversion. Is there a way to change the SFINAE check to make this possible? I have checked and the void_t method with GCC5 appears to do what I want (commented out in the code below), but I can't use it yet for the aforementioned reasons.

Test case:

#include <iostream>
#include <typeinfo>
#include <type_traits>

namespace detail {

    namespace has_ostream_operator_impl {
        typedef char no;
        typedef char yes[2];

        struct any_t {
            template<typename T> any_t( T const& );
        };

        no operator<<( std::ostream const&, any_t const& );

        yes& test( std::ostream& );
        no test( no );

        template<typename T>
        struct has_ostream_operator {
            static std::ostream &s;
            static T const &t;
            // compiler complains that test(s << t) is ambiguous
            // for Foo
            static bool const value = sizeof( test(s << T(t)) ) == sizeof( yes );
        };
    }

    template<typename T>
    struct has_ostream_operator :
        has_ostream_operator_impl::has_ostream_operator<T> {
    };

    // template<class, class = std::void_t<>>
    //     struct has_ostream_operator : std::false_type {};

    // template<class T>
    // struct has_ostream_operator<
    //     T,
    //     std::void_t<
    //         decltype(std::declval<std::ostream&>() << std::declval<const T&>())>>
    //     : std::true_type {};

}

template<class X>
std::enable_if_t<
    detail::has_ostream_operator<X>::value
    && !std::is_pointer<X>::value>
prettyPrint(std::ostream& o, const X& x)
{
    o << x;
}

template<class X>
std::enable_if_t<
    !detail::has_ostream_operator<X>::value
    && !std::is_pointer<X>::value>
prettyPrint(std::ostream& o, const X& x)
{
    o << typeid(x).name()
      << " (no ostream operator<< implementation)";
}

template<class X>
void prettyPrint(std::ostream& o, const X* x)
{
    o << "*{";
    if(x) {
        prettyPrint(o, *x);
    } else {
        o << "NULL";
    }
    o << "}";
}

struct Foo {
    operator float() const {
        return 0;
    }

    operator bool() const {
        return false;
    }
};

struct Bar {};

int main()
{
    Bar x;
    Foo y;
    prettyPrint(std::cout, 6); // works fine
    std::cout << std::endl;

    prettyPrint(std::cout, Bar()); // works fine
    std::cout << std::endl;

    prettyPrint(std::cout, x); // works fine
    std::cout << std::endl;

    prettyPrint(std::cout, &x); // works fine
    std::cout << std::endl;

//    prettyPrint(std::cout, y); // compiler error
    std::cout << std::endl;

    return 0;
}
Community
  • 1
  • 1
Joseph Garvin
  • 20,727
  • 18
  • 94
  • 165
  • 1
    For GCC <= 4.9 use [the following workaround](http://coliru.stacked-crooked.com/a/aafcc71f98311f93) – Piotr Skotnicki Dec 16 '15 at 17:06
  • The `void_t`/CWG1558 problem is trivial to work around. – T.C. Dec 16 '15 at 17:25
  • @PiotrSkotnicki oh nice, I didn't realize that. Make that an answer below and I'll accept. Although I would kind of like to know *why* the void_t version doesn't have this problem. It still invokes the operator... is declval's return type for some reason not implicitly convertible? – Joseph Garvin Dec 16 '15 at 17:56
  • @JosephGarvin it's explained [here](http://stackoverflow.com/q/25833356/3953764) – Piotr Skotnicki Dec 16 '15 at 17:58
  • @PiotrSkotnicki That explains why the workaround for void_t makes it work in GCC 4.9, but I'm asking why void_t doesn't error when implicit conversions make it ambiguous which overload to call while the original has_ostream_operator does. In fact if it doesn't take into account implicit conversions that would imply that sometimes the trait will be wrong. – Joseph Garvin Dec 16 '15 at 18:02
  • The `void_t` method checks "does this expression compile" (for some definition of "compile"). Your method checks "is there an `operator<<` that matches better than my crappy one". – T.C. Dec 17 '15 at 06:19

1 Answers1

4

Well, you don't have to use void_t (which is syntax sugar, anyway). Bog-standard expression SFINAE is supported by GCC 4.9:

template <typename, typename = void>
struct has_ostream_operator : std::false_type {};

template <typename T>
struct has_ostream_operator<T, decltype(void(std::declval<std::ostream&>() << std::declval<const T&>()))>
    : std::true_type {};

works fine on Wandbox's GCC 4.9.

Columbo
  • 60,038
  • 8
  • 155
  • 203
  • This looks identical to the void_t part of my snippet, which does not work in Ubuntu's GCC 4.9. Like I said it does work on Fedora's, so Ubuntu must have patched it or something. – Joseph Garvin Dec 16 '15 at 17:33
  • @JosephGarvin Have you tested this? It's hardly believable that GCC 4.9 on any distro whatsoever doesn't support such basic SFINAE; The bug seems directly related to the usage of `void_t` itself. – Columbo Dec 16 '15 at 17:34
  • yep, I tested it. I was dumbfounded myself. The error you get has to do with ostream overloads and ambiguity (but despite having that in common is *not* the same issue as in my post). So I don't think it's a void_t issue but some difference in iostream. – Joseph Garvin Dec 16 '15 at 17:37
  • @JosephGarvin Have you tested the exact code I posted via Wandbox? And it failed? (Also, you probably meant to say the error "I" (i.e. you) got, ...) – Columbo Dec 16 '15 at 17:42
  • testing with Wandbox doesn't help without knowing what distribution it's on. – Joseph Garvin Dec 16 '15 at 17:56
  • it would have been relevant (had you been using void_t) because if you read my question you would see GCC 4.9's behavior across Ubuntu/Fedora is inconsistent (so if Wandbox was running on Fedora it working on Fedora wouldn't have been news to me). But it's moot now, Piotr's workaround fixes it. – Joseph Garvin Dec 16 '15 at 18:07
  • Just compiled the version in Wandbox in my Ubuntu with gcc4.9 (Ubuntu 4.9.3-8ubuntu2~14.04) . Works fine, +1 (I use Ubuntu 14.04 LTS) – Lorah Attkins Dec 16 '15 at 18:09
  • @JosephGarvin Have you tested the *exact* code posted above? What are your command line options? `--version`? `-v`? Do they differ between boxes? – Yakk - Adam Nevraumont Dec 16 '15 at 19:25
  • @Yakk He hasn't tested anything, but he did delete the comment in which he apologizes for not noticing that I did in fact not use `void_t`. :-) – Columbo Dec 16 '15 at 19:27
  • @Yakk I didn't (intentionally) delete the comment, but it does seem to have disappeared :p I mistakenly thought his snippet was the same. That's why my comment about Ubuntu/Fedora says 'would have' been relevant. I did test the void_t version, which shows the weird distro difference, but not not Columbo's version since it's now moot due to Piotr's workaround. – Joseph Garvin Dec 16 '15 at 20:16
  • @JosephGarvin Well, actually, Piotr's workaround is effectively mine but superfluously bloated. – Columbo Dec 16 '15 at 20:29
  • @Columbo It appears that the core of Piotr's workaround is to re-implement a gcc working `void_t`, no? Everything else is dross? – Yakk - Adam Nevraumont Dec 16 '15 at 20:49
  • @Yakk Well yeah, but providing an own `void_t` implementation solely for this occasion instead of just writing `void` instead seems a bit... I dunno? – Columbo Dec 16 '15 at 22:16
  • Well, `decltype(void(` and `))` instead of `void_t<` and `>`. – Yakk - Adam Nevraumont Dec 17 '15 at 00:15
  • @Yakk To be precise, `decltype(void( ... ))` instead of `void_t`. – Columbo Dec 17 '15 at 00:19
  • I ended up using Piotr's workaround since just using void_t consistently is better code base wise, but I marked accepted since your answer is technically correct. – Joseph Garvin Dec 21 '15 at 17:11