Disable a function by throwing error at compile-time with template class using traits

Question

I have a class, let's call it Foo with several methods:

template<typename T>
class Foo {
public:
   Foo()               { /* ... */ }
   bool do_something() { /* ... */ }

   // This method should be callable only if:
   // std::is_floating_point<T>::value == true
   void bar() { 
      // Do stuff that is impossible with integer
   }
};

I would like to be able to construct both Foo<double> and Foo<int> But I don't want to allow calls to bar() when the type T is not a floating point type. I also want the error to be generated at compile-time and not at the run-time. So, what I want is:

Foo<double> a;
a.bar();                        // OK
Foo<int> b;
bool res = b.do_something();    // OK
b.bar();                        // WRONG: compile error

I tried a lot of things with enable_if (with posts like this or this one) but I can't use anymore the int type with Foo. For example:

typename std::enable_if<std::is_floating_point<T>::value>::type
bar() { /* ... */ } 

main.cpp:112:28:   required from here
foo.h:336:5: error: no type named ‘type’ in ‘struct std::enable_if<false, void>’
 bar() {

How can I constrain the use of bar() to floating point types but allow integer type to use in other places?

@Appleshell functions can't be partially specialized. If you were referring to the class/struct then it's another story. — Marco A., May 09 '14 at 19:56
No, I just want the function to be callable with floating numbers, whatever the type after :-) — Maxime Lorant, May 09 '14 at 19:57
@Marco Yes, implementing `bar` only in the floating point specialization of `Foo`. — Appleshell, May 09 '14 at 19:58

score 13 · Accepted Answer · answered May 09 '14 at 19:56

13

void bar() { 
   static_assert(std::is_floating_point<T>::value,
                 "this method can only be called for floating-point Foos!");
   // do stuff
}

answered May 09 '14 at 19:56

Brian Bi

111,498
10
176
312

probably the cleanest way to do it – Marco A. May 09 '14 at 19:59
Indeed, works like a charm :-) Will be accepted in few minutes (SO limitations..) – Maxime Lorant May 09 '14 at 20:00
2

@MaximeLorant the only issue with this is that `bar` participates in overload resolution. If there was another override of `bar`, this one might still be preferred, and then accidentally called. Note that the naive SFINAE solutions also fail to work. – Yakk - Adam Nevraumont May 09 '14 at 20:13
I won't have subclasses nor other `bar`methods in my case, so it won't be a problem. But good to note for other googlers. – Maxime Lorant May 09 '14 at 20:16

Yakk - Adam Nevraumont · Answer 2 · 2014-05-09T21:07:15.457

The basic solution is to use a static_assert within the body of bar. This generates an error if and only if someone tries to call it. It does not, however, block people from finding it, and the error is "late" in that it doesn't enable SFINAE detection of the existence of bar.

As an alternative to static_assert, you can use SFINAE to conditionally allow bar to participate in overload resolution, and possibly block it from being found to be called at all. You have to be careful, because the SFINAE must theoretically have a specialization that compiles (otherwise your program is ill-formed with no diagnosis required), and it only works on a template method.

private:
  struct blocked {};
public:
  template<typename Unused=void, 
           typename=typename std::enable_if< 
                                     std::is_same<Unused, blocked>::value ||                            
                                     std::is_floating_point<T>::value 
                                           >::type>
  void bar() {
    // code
  }

This blocks the method bar from being considered during overload resolution, rather than making selecting it an error. This is a subtle difference, but matters a lot if bar is overridden.

which is pretty obtuse. In C++1y with concepts lite, requires clauses are supposed to do the right thing within a template without the above obtuse stuff.

In practice, the blocked type is probably not needed, as I am not aware of a compiler that actually enforces the ill-formedness of a template that has no valid specializations. That clause is probably there to allow future revisions to do more checking prior to instantiation.

The final method I can think of involves a CRTP base class that specializes based on the trait you want to create/destroy bar based on.

template<typename D, bool test>
struct maybe_bar {};
template<typename D>
struct maybe_bar<D, true> {
  D* self() {
    static_assert( std::is_base_of< maybe_bar, D >::value, "CRTP failure" );
    return static_cast<D*>(this);
  }
  D const* self() const{
    static_assert( std::is_base_of< maybe_bar, D >::value, "CRTP failure" );
    return static_cast<D const*>(this);
  }
  void bar() {
    // use self() in here to get at your this pointer instead of this
  }
};

then at the point of use:

template<typename T>
struct my_type:maybe_bar<T, std::is_floating_point<T>::value> {
};

and bar is conditionally created or not.

This is less obtuse, but more verbose, and it places the implementation seriously out-of-line with the rest of the class body.

Nice alternative but the syntax is a bit verbose compared to @Brian and not that straightforward to understand... Thanks for the contribution though :) — Maxime Lorant, May 09 '14 at 20:36
@MaximeLorant yep. If you don't need the "blocking overload resolution", this isn't a good idea. Made it more complete, with all 4 solutions I am aware of. — Yakk - Adam Nevraumont, May 09 '14 at 21:02
What's the point of the `self()` function? Is it just to prevent other instantiations of `maybe_bar`? Couldn't you just put it inside a `detail` namespace or something instead? — Brian Bi, May 09 '14 at 21:27
@Brian CRTP means that we are a parent of our type `my_type`. But we probably want access to the member data of `my_type`. `self()` encapsulates both a check that `maybe_bar,true>` is a parent of `my_type` (which can guard against some typos), **and** does the `static_cast` to get ourselves as a `my_type` instead of a type with no useful state inside of it. Look up the CRTP if you are interested, `self()` is a relatively standard method when you use the CRTP. — Yakk - Adam Nevraumont, May 09 '14 at 23:54

Disable a function by throwing error at compile-time with template class using traits

2 Answers2

Linked