144

When I try to use float as a template parameter, the compiler cries for this code, while int works fine.

Is it because I cannot use float as a template parameter?

#include<iostream>
using namespace std;

template <class T, T defaultValue>
class GenericClass
{
private:
    T value;
public:
    GenericClass()
    {
        value = defaultValue;
    }

    T returnVal()
    {
        return value;
    }
}; 


int main()
{
    GenericClass <int, 10> gcInteger;
    GenericClass < float, 4.6f> gcFlaot;

    cout << "\n sum of integer is "<<gcInteger.returnVal();
    cout << "\n sum of float is "<<gcFlaot.returnVal();

    return 0;       
}

Error:

main.cpp: In function `int main()':
main.cpp:25: error: `float' is not a valid type for a template constant parameter
main.cpp:25: error: invalid type in declaration before ';' token

main.cpp:28: error: request for member `returnVal' in `gcFlaot',
                    which is of non-class type `int'

I am reading "Data Structures for Game Programmers" by Ron Penton, the author passes a float, but when I try it it doesn't seem to compile.

Filip Roséen - refp
  • 62,493
  • 20
  • 150
  • 196
yokks
  • 5,683
  • 9
  • 41
  • 48

11 Answers11

152

THE SIMPLE ANSWER

The standard doesn't allow floating points as non-type template-arguments, which can be read about in the following section of the C++11 standard;

14.3.2/1      Template non-type arguments      [temp.arg.nontype]

A template-argument for a non-type, non-template template-parameter shall be one of:

  • for a non-type template-parameter of integral or enumeration type, a converted constant expression (5.19) of the type of the template-parameter;

  • the name of a non-type template-parameter; or

  • a constant expression (5.19) that designates the address of an object with static storage duration and external or internal linkage or a function with external or internal linkage, including function templates and function template-ids but excluding non-static class members, expressed (ignoring parentheses) as & id-expression, except that the & may be omitted if the name refers to a function or array and shall be omitted if the corresponding template-parameter is a reference; or

  • a constant expression that evaluates to a null pointer value (4.10); or

  • a constant expression that evaluates to a null member pointer value (4.11); or

  • a pointer to member expressed as described in 5.3.1.


But.. but.. WHY!?

It is probably due to the fact that floating point calculations cannot be represented in an exact manner. If it was allowed it could/would result in erroneous/weird behavior when doing something as this;

func<1/3.f> (); 
func<2/6.f> ();

We meant to call the same function twice but this might not be the case since the floating point representation of the two calculations isn't guaranteed to be exactly the same.


How would I represent floating point values as template arguments?

With C++11 you could write some pretty advanced constant-expressions (constexpr) that would calculate the numerator/denominator of a floating value compile time and then pass these two as separate integer arguments.

Remember to define some sort of threshold so that floating point values close to each other yields the same numerator/denominator, otherwise it's kinda pointless since it will then yield the same result previously mentioned as a reason not to allow floating point values as non-type template arguments.

Community
  • 1
  • 1
Filip Roséen - refp
  • 62,493
  • 20
  • 150
  • 196
  • 67
    The C++11 solution is ``, described by §20.10 as "Compile-time rational arithmetic". Which cuts right to your example. – Potatoswatter Jul 17 '12 at 10:45
  • 1
    @Potatoswatter afaik there isn't any method in the STL to convert a float into numerator/denominator using ``? – Filip Roséen - refp Jul 17 '12 at 11:16
  • This may have some relevance: http://stackoverflow.com/questions/95727/how-to-convert-floats-to-human-readable-fractions – Gearoid Murphy Nov 25 '12 at 17:54
  • 4
    This doesn't really give a convincing explanation. The whole *point* of floating-point is that it does represent values exactly. You're free to treat the numbers you have as approximations to something else, and it's often useful to do so, but the numbers themselves are exact. – tmyklebu Jan 22 '15 at 14:25
  • @tmyklebu I changed the wording some time ago, but I forgot to send you a PING about it; are you more satisfy with the usage of *"that floating point calculations cannot be represented in an exact manner"* - instead of saying that floating points in themselves cannot be exact (since, as you point out, that is a bit misleading) – Filip Roséen - refp Oct 09 '15 at 16:10
  • 5
    @FilipRoséen-refp: All floating-point numbers are exact. Floating-point arithmetic is well-defined on every target I know of. Most floating-point operations produce floating-point results. I can appreciate the committee not wanting to force compiler implementors to implement the target's possibly-bizarre floating-point arithmetic, but I don't believe "the arithmetic is different from integer arithmetic" is a good reason to forbid floating-point template arguments. It's an arbitrary restriction at the end of the day. – tmyklebu Oct 10 '15 at 04:37
  • 1
    @tmyklebu I'm not sure how that applies to the standard. Is floating-point arithmetic well-defined by the standard? If not, that every target you know of has a well-defined implementation is immaterial. – iheanyi Jan 19 '16 at 20:16
  • 7
    @iheanyi: Does the standard say what `12345 * 12345` is? (It *does* allow `int` template parameters even though it doesn't specify the width of a signed int or whether that expression is UB.) – tmyklebu Jan 26 '16 at 02:36
  • ratio (rational number) is a subset of float (real number) in mathematics. However, it is important to remember not to use float or double as non-type template parameter. – Kemin Zhou Jun 20 '19 at 22:39
  • 2
    @KeminZhou I see this misconception everywhere. Floats are NOT real numbers. Not even close. In fact, they are a subset of the rationals (easily provable). There is a strict injection of every floating point number to the rationals. – jeremyong Oct 07 '19 at 23:13
  • 2
    @tmyklebu False. 1. High-level languages do not necessarily map the floating-point values to exact notion of the numbers, even not mathematical one. For example, the Scheme language defines the concept of _inexact_ numbers, which are implemented based on floating-point values in almost every practical implementations. (And R6RS even defines _flonums_.) C++ does not define the model of "C++ number", but since it conforms to LIA-1(ISO/IEC 10967), there is room to be inexact even in the representation, unless IEC 60559 is followed. – FrankHB Dec 14 '21 at 18:36
  • 2
    2. The certainty of your exactness depending on the definition of the target. For example, given x87 is a popular target, your assumption is simply invalid: sometimes 80287 behaves differently to 80387 onward. 3. Compiler options can easily turns out lots of incompatible floating-point implementations, which may incur unpredicatable behavior by design. For example, the GCC manual states "rounding is unpredictable" for -mfpmath=sse+387, so -fexcess-precision=standard makes no sense. – FrankHB Dec 14 '21 at 18:36
  • 4. Finally, to implement every details of floating-point arithmetic correctly is HARD. There are tons of hardware not strictly conforming to the standard in corner cases, but you may neglect the bugs before you're bitten. – FrankHB Dec 14 '21 at 18:36
  • 1
    @jeremyong Only finite floating-point numbers are in the subset of rational numbers. Typically, floating-point numbers include infinite values, which are NOT real numbers, but _hyperreals_. And floating-point _datum_ can encode various NaN (Not a Number) values. Moreover, +0.0 and -0.0 can be different floating-point numbers, but mathematically equal. – FrankHB Dec 14 '21 at 18:51
  • @FrankHB well put, upvoting. – Filip Roséen - refp Mar 10 '22 at 03:31
42

The current C++ standard does not allow float (i.e. real number) or character string literals to be used as template non-type parameters. You can of course use the float and char * types as normal arguments.

Perhaps the author is using a compiler that doesn't follow the current standard?

Filip Roséen - refp
  • 62,493
  • 20
  • 150
  • 196
  • 9
    Please provide a link to or copy of relevant section from the standard – thecoshman Jul 17 '12 at 08:37
  • 2
    @thecoshman the relevant section of the standard + more information is available in my (newly posted) answer. – Filip Roséen - refp Jul 17 '12 at 10:10
  • 1
    In C++11, it is, just about, possible to use a character string literal as a template non-type parameter. If your template takes a character pack `template`, then the string literal can be converted into such a pack at compile time. Here is a [demo on ideone](http://ideone.com/QvXuYf). (Demo is C++14, but it's easy to port it back to C++11 - `std::integer_sequence` is the only difficulty) – Aaron McDaid Jul 20 '15 at 20:05
  • Note that you can use `char &*` as a template parameter if you define the literal somewhere else. Works pretty well as a workaround. – StenSoft Jul 29 '15 at 10:11
39

Just to provide one of the reasons why this is a limitation (in the current standard at least).

When matching template specializations, the compiler matches the template arguments, including non-type arguments.

By their very nature, floating point values are not exact and their implementation is not specified by the C++ standard. As a result, it is difficult to decide when two floating point non type arguments really match:

template <float f> void foo () ;

void bar () {
    foo< (1.0/3.0) > ();
    foo< (7.0/21.0) > ();
}

These expressions do not necessarily produce the same "bit pattern" and so it would not be possible to guarantee that they used the same specialization - without special wording to cover this.

Richard Corden
  • 21,389
  • 8
  • 58
  • 85
  • 25
    This is almost an argument to ban floats entirely from the language. Or, at a minimum, ban the `==` operator :-) We already accept this inaccuracy at runtime, why not at compile time too? – Aaron McDaid Aug 04 '15 at 10:45
  • 3
    Agree with @AaronMcDaid , this is not much of an argument. So you need to be careful in the definition. So what? As long as it works for stuff you get from constants, it's already quite the improvement. – einpoklum Mar 26 '16 at 23:20
  • 2
    C ++20 now allows for float (an other object types) as non-type template parameters. Still C++20 does not specify the float implementation. This shows that einpoklum and Aaron have a point. – Andreas H. Jul 08 '20 at 11:15
21

Indeed, you can't use float literals as template parameters. See section 14.1 ("A non-type template-parameter shall have one of the following (optionally cv-qualified) types...") of the standard.

You can use a reference to the float as a template parameter:

template <class T, T const &defaultValue>
class GenericClass

.
.

float const c_four_point_six = 4.6; // at global scope

.
.

GenericClass < float, c_four_point_six> gcFlaot;
moonshadow
  • 86,889
  • 7
  • 82
  • 122
  • 11
    You can. but it doesn't do the same thing. You can't use the reference as a compile-time constant. –  Feb 02 '10 at 10:17
17

Starting with C++20 this is possible.

This also gives the answer to the original question:

Why can't I use float value as a template parameter?

Because nobody implemented it in the standard yet. There is no fundamental reason.

In C++20 non-type template parameters can now be floats and even class objects.

There are some requirements on class objects (they must be a literal type) and fulfil some other requirements to exclude the pathological cases such as user defined operator == (Details).

We can even use auto

template <auto Val>
struct Test {
};

struct A {};
static A aval;
Test<aval>  ta;
Test<A{}>  ta2;
Test<1.234>  tf;
Test<1U>  ti;

Note that GCC 9 (and 10) implements class non-type template parameters, but not for floats yet.

Andreas H.
  • 5,557
  • 23
  • 32
14

Wrap the parameter(s) in their own class as constexprs. Effectively this is similar to a trait as it parameterizes the class with a set of floats.

class MyParameters{
    public:
        static constexpr float Kd =1.0f;
        static constexpr float Ki =1.0f;
        static constexpr float Kp =1.0f;
};

and then create a template taking the class type as a parameter

  template <typename NUM, typename TUNING_PARAMS >
  class PidController {

      // define short hand constants for the PID tuning parameters
      static constexpr NUM Kp = TUNING_PARAMS::Kp;
      static constexpr NUM Ki = TUNING_PARAMS::Ki;
      static constexpr NUM Kd = TUNING_PARAMS::Kd;

      .... code to actually do something ...
};

and then use it like so...

int main (){
    PidController<float, MyParameters> controller;
    ...
    ...
}

This allows the compiler to guarantee that only a single instance of the code is created for each template instantiation with the same parameter pack. That gets around all the issues and you are able to use floats and doubles as constexpr inside the templated class.

Andrew Goedhart
  • 937
  • 9
  • 17
  • If C++20 is an option, the intent can be made even clearer here by passing a struct or class instance by value into the template (as shown in https://stackoverflow.com/a/60244416/6177253) so `typename TUNING_PARAMS` could be replaced with `MyParameters params` within the template arguments. This could be useful to make sure that only the correct type defining needed params is passed. Perhaps a reference could also be passed, in which case subclasses might be passed also..? – saxbophone Nov 09 '20 at 16:48
6

If you are ok to have a fixed default per type you can create a type to define it as a constant and specialize it as needed.

template <typename T> struct MyTypeDefault { static const T value; };
template <typename T> const T MyTypeDefault<T>::value = T();
template <> struct MyTypeDefault<double> { static const double value; };
const double MyTypeDefault<double>::value = 1.0;

template <typename T>
class MyType {
  public:
    MyType() { value = MyTypeDefault<T>::value; }
  private:
    T value;
 };

If you have C++11 you can use constexpr when defining the default value. With C++14, MyTypeDefault can be a template variable which is a bit cleaner syntactically.

//C++14
template <typename T> constexpr T MyTypeDefault = T();
template <> constexpr double MyTypeDefault<double> = 1.0;

template <typename T>
class MyType {
  private:
    T value = MyTypeDefault<T>;
 };
Matthew Fioravante
  • 1,478
  • 15
  • 19
2

You can always fake it...

#include <iostream>

template <int NUM, int DEN>
struct Float
{
    static constexpr float value() { return (float)NUM / (float)DEN; }
    static constexpr float VALUE = value();
};

template <class GRAD, class CONST>
struct LinearFunc
{
    static float func(float x) { return GRAD::VALUE*x + CONST::VALUE; }
};


int main()
{
    // Y = 0.333 x + 0.2
    // x=2, y=0.866
    std::cout << " func(2) = "
              << LinearFunc<Float<1,3>, Float<1,5> > ::func(2) << std::endl;
}

Ref: http://code-slim-jim.blogspot.jp/2013/06/c11-no-floats-in-templates-wtf.html

Ashley Smart
  • 2,098
  • 2
  • 13
  • 7
  • 3
    A `float` != rational number. The two are very separate ideas. One is calculated via a mantissa & an exponent, the other is, well, a rational - not every value representable by a rational is representable by a `float`. – Richard J. Ross III Jun 08 '13 at 17:52
  • 3
    @RichardJ.RossIII A `float` is very definitely a rational number, but there are `float`s that aren't representable as ratios of two `int`s. The mantissa is an Integer, and the 2^exponent is an Integer – Caleth Jun 16 '17 at 12:29
2

The other answers give good reasons why you probably do not want floating point template parameters, but the real deal breaker IMO is that equality using '==' and bitwise equality are not the same:

  1. -0.0 == 0.0, but 0.0 and -0.0 are not bitwise equal

  2. NAN != NAN

Neither kind of equality is a good cancidate for type equality: Of course, point 2. makes using == invalid for determining type equality. One could use bitwise equality instead, but then x != y does not imply that MyClass<x> and MyClass<y> are different types (by 2.), which would be rather strange.

Matthieu
  • 25
  • 5
  • There are already enumerators (with the same underlying integer value) able to be template arguments and they are not identical in the sense of type equivalence, so your first point is not an issue. – FrankHB Dec 14 '21 at 18:13
1

If you don't need the double to be a compile-time constant, you can pass it in as a pointer:

#include <iostream>

extern const double kMyDouble = 0.1;;

template <const double* MyDouble>
void writeDouble() {
   std::cout << *MyDouble << std::endl; 
}

int main()
{
    writeDouble<&kMyDouble>();
   return 0;
}
0

If you only want to represent a fixed precision, then you can use a technique like this to convert a float parameter into an int.

For example an array with a growth factor of 1.75 could be created as follows assuming 2 digits of precision (divide by 100).

template <typename _Kind_, int _Factor_=175>
class Array
{
public:
    static const float Factor;
    _Kind_ * Data;
    int Size;

    // ...

    void Resize()
    {
         _Kind_ * data = new _Kind_[(Size*Factor)+1];

         // ...
    }
}

template<typename _Kind_, int _Factor_>
const float Array<_kind_,_Factor_>::Factor = _Factor_/100;

If you dont like the representation of 1.75 as 175 in the template argument list then you could always wrap it in some macro.

#define FloatToIntPrecision(f,p) (f*(10^p))

template <typename _Kind_, int _Factor_=FloatToIntPrecision(1.75,2)>
// ...
  • it should be `...::Factor = _Factor_/100.0;` otherwise it will be integer division. – alfC Nov 06 '14 at 00:19