Conditionally compile a conversion operator based on numeric template parameter

Question

I have a template <bool P> class Foo with lots of code in it. I want to be able to convert Foo<true>'s into Foo<false>'s, i.e. have an operator Foo<false>() method. But the compiler doesn't like such a method existing for Foo, it only likes it for Foo<true>, and gives a warning about how the "operator will not be called for implicit or explicit conversions" (GCC 5.4.x)

It doesn't seem like I can use SFINAE for this: std::enable_if works with types; and a value-variant I tried out (where the true case has a value rather than a type member) didn't help either.

How can I get this operator to only be compiled for Foo<false> (other than specializing Foo<false> different and duplicating all of my code)?

My best attempt so far has been:

template <bool P> class Foo {
    // etc. etc.
    template <bool OtherValue>
    operator Foo<OtherValue>()
    {
        static_assert(OtherValue, "You should not be using this conversion!");
        // conversion code here
        return Foo<false>(args,go,here);
    }
}

@André - That doesn't solve the issue, really. It only makes sure the compiler will complain over duplicate definitions when `foo` is copied (assuming a copy c'tor is also present). — StoryTeller - Unslander Monica, Oct 24 '17 at 10:02
@André: I didn't think I could get the ctor to only exist for `Foo`. But - that's an idea, I suppose. — einpoklum, Oct 24 '17 at 10:13

Vittorio Romeo · Answer 1 · 2017-10-24T10:15:12.170

How can I get this operator to only be compiled for Foo<false> (other than specializing Foo<false> different and duplicating all of my code)?

template <bool P> 
struct Foo 
{
    template <bool P2 = P, typename = std::enable_if_t<P2 == true>>
    operator Foo<false>()
    {
        return {};
    }
};

Using P2 = P delays the evaluation of the enable_if_t to when the conversion operator is actually being used (instead of class instantiation).

If we tried to simply write:

template <typename = std::enable_if_t<P == true>>
operator Foo<false>()
{
    return {};
}

std::enable_if_t<P == true> would be evaluated during Foo<P>'s instantiation as there is no substitution occurring when the member functions are instantiated. The substitution is happening when Foo is instantiated - therefore SFINAE cannot take place (as there isn't any overload resolution set yet).

By adding a bool P2 = P default parameter, we delay substitution to the instantiation of the conversion operator. This happens during overload resolution, so SFINAE can take place.

This answer explains it better than I can: https://stackoverflow.com/a/13401982/598696

Ah, how sneaky of you! But why is the evaluation delayed? Can you elaborate a bit more on that? — einpoklum, Oct 24 '17 at 10:05

score 3 · Answer 2 · answered Oct 24 '17 at 09:59

3

Your best attempt is actually not far off. You need to turn the conversion operator into a template so that SFINAE could work. Just enforce it only for the case P is true:

template<bool P>
struct foo {
    template<bool V = P, std::enable_if_t<V>* = nullptr>
    operator foo<false>() {
        return {};
    }
};

The operator is a template with all parameters having default arguments. So it can be used. However, since the check is on V, we delay the verification of the operator until overload resolution. Then SFINAE eliminates it.

answered Oct 24 '17 at 09:59

StoryTeller - Unslander Monica

165,132
21
377
458

Isn't it better to @VittorioRomero's trick rather than having pointers pop up? – einpoklum Oct 24 '17 at 10:12
@einpoklum - Define "better"? It's the same trick. Vittorio's version relies on failure in the argument, while this one relies on failure in the parameter. In the general case (not this one), a cheeky programmer can supply a type explicitly to get around a check (there's no way to do it with conversion operators however). But if the the parameter fails, an attacker has no recourse. So TL;DR: in this case it doesn't matter, in the general case I prefer to SFINAE on the parameter. I wrote this one by instinct. – StoryTeller - Unslander Monica Oct 24 '17 at 10:15

score 1 · Answer 3 · answered Oct 24 '17 at 10:24

1

You might use an helper struct and specilization to externalize your operator:

template <bool P> class Foo; // Forward declaration

template <bool P> struct FooConverterHelper {}; // False case: no conversion operator

template <> struct FooConverterHelper<true>
{
    operator Foo<false>();
};


template <bool P> class Foo : public FooConverterHelper<P>
{
    // Lot of stuff.
};

// Implementation of you conversion operator
FooConverterHelper<true>::operator Foo<false>()
{
    //auto* that = static_cast<Foo<true>*>(this); // If needed

    return Foo<false>{};
}

Demo

answered Oct 24 '17 at 10:24

Jarod42

203,559
14
181
302

I like it. Though spreading the definition around so much can be a pain on readability. +1 – StoryTeller - Unslander Monica Oct 24 '17 at 10:31
That's "cheating"... of course I do whatever I want in another struct - there I don't have any restrictions. I want this conversion operator for silent conversions the users of my library won't notice. – einpoklum Oct 24 '17 at 10:39
@StoryTeller: the other way, having `struct Foo : FooCommon {opearator Foo() {/**/}}; struct Foo : FooCommon{};` would avoid that. but it would be "cheating" even more. – Jarod42 Oct 24 '17 at 11:07

Conditionally compile a conversion operator based on numeric template parameter

3 Answers3

Linked