Float that initializes to NaN

Hi! I want to make a class that works exactly like a float, only that it is initialized to NaN when the default constructor is called and if DEBUG is defined so that I can easily detect when I have an uninitialized float. Is there some simple way to do this? Thanks in advance!

I'm not sure if this is portable.

Code:

---

#ifdef DEBUG
float_var = std::sqrt(-1);
#endif

---

I assume you encapsulate a float variable.
If, on the other hand, you want to implement floating point numbers by yourself.. it is *much* more complicated and I have no idea.

[EDIT]
I just found out that there is a NAN macro in math.h .
So, "foo = NAN;" would be a better idea .

Thank you, that is one way to generate a NaN, yes. But the question was how to make the kind of class I described above.

Quote:

---

Originally Posted by then

Thank you, that is one way to generate a NaN, yes. But the question was how to make the kind of class I described above.

---

Just encapsulate a float variable and overload the operators.
(And possibly throw some exceptions within them.)
I don't think there is anything else to it.

I'm trying. So far I the class declaration looks like this:

Code:

---

template<typename T>
class base_safe_float
{
public:
    /* Constructors */
    base_safe_float(); // Default constructor
    template<typename T2> base_safe_float<T>(T2 s); // Copy conversion constructor

    /* Conversion operator */
    operator T() const;

    /* Assignment operators */
    template<typename T2> base_safe_float<T>& operator =(const T2&);
    template<typename T2> base_safe_float<T>& operator+=(const T2&);
    template<typename T2> base_safe_float<T>& operator-=(const T2&);
    template<typename T2> base_safe_float<T>& operator*=(const T2&);
    template<typename T2> base_safe_float<T>& operator/=(const T2&);

private:
    T v; /* Value */
};

---

I don't know if this is all constructors and operators I need to define. However, when I'm trying to use this, I'm getting errors like

Code:

---

error: operands to ?: have different types 'int' and 'ftype'

---

(ftype is typedefd as base_safe_float<float>)

It is complaining on the row

Code:

---

f = f < 0 ? 0 : f;

---

where f is a variable of type ftype. How can I get rid of this error without modifying the line that's generating it (since the line shouldn't generate the error)?

If the class is supposed to work exactly like a float (or as a double, depending on what the template argument is), I must find some way to get rid of all these compile errors.

don't forget about comparison (==, !=, <, >, <=, >=) operators

Quote:

---

Originally Posted by Elkvis

don't forget about comparison (==, !=, <, >, <=, >=) operators

---

Doesn't the compiler realize that it can just use the conversion operator and then compare a float against whatever it is I want to compare it against?

I don't think you can make that assumption, not to mention implicit conversion operators, while legal in the code, are not recommended, as you may get unexpected results.

I have the guts of a lightweight class that implements exactly enough to do this kind of thing already. I could have this made in about 10 minutes after work today. Might post back in about 10 hours with it.

Quote:

---

How can I get rid of this error without modifying the line that's generating it (since the line shouldn't generate the error)?

---

O_o

It should generate the error.

Both results of the conditional operator are required to be the same type or convertible to the same type. The compiler is not allowed to choose the conversion. If the conversion can be assumed because the types have an inheritance relationship the compiler will implicitly convert a child class reference to a parent class reference. If the relationship between types are not direct one or both types must be explicitly cast.

You need to explicitly cast the zero (an integer value) to type `T'.

Quote:

---

I don't think you can make that assumption, not to mention implicit conversion operators, while legal in the code, are not recommended, as you may get unexpected results.

---

There is no problem in this context. The type of conversion is directly related to the type held by the class. Without the conversion the class can't be used as a real `float' could be used even if every other operator is provided.

However, the other operators should still be provided. You can catch an uninitialized value without them; with them you can catch other semantic errors later.

Soma

Quote:

---

Originally Posted by phantomotap

O_o

---

I don't get this error when f just is a normal float, that is why a base_safe_float<float> shouldn't generate any error here either.

Quote:

---

Originally Posted by phantomotap

However, the other operators should still be provided. You can catch an uninitialized value without them; with them you can catch other semantic errors later.

Soma

---

Okay. I have already started to write the other operators but I deactivated them since I didn't think they would contribute anything to the class when I had the conversion operator. But there are really many operators, should I overload all of them?

Quote:

---

Originally Posted by iMalc

I have the guts of a lightweight class that implements exactly enough to do this kind of thing already. I could have this made in about 10 minutes after work today. Might post back in about 10 hours with it.

---

It would be interesting to see your implementation and if it differs something from my class (except from that my isn't finished yet).

Quote:

---

Originally Posted by then

It would be interesting to see your implementation and if it differs something from my class (except from that my isn't finished yet).

---

I would also like to see either/both of the implementations.

Tim S.

Quote:

---

I don't get this error when f just is a normal float, that is why a base_safe_float<float> shouldn't generate any error here either.

---

Your opinion is irrelevant.

You are simply wrong.

Code:

---

f < 0 ? 0 : f;

---

In this code that you posted the both results differ beyond what the compiler is allowed to infer.

The compiler can't simply choose because both are perfectly valid.

Code:

---

    f < 0 ? static_cast<ftype>(0) : f;

---

Code:

---

    f < 0 ? 0 : static_cast<float>(f);

---

These are both equally valid so the compiler is not allowed to choose.

Code:

---

(condition) ? (true_result) : (false_result);

---

You are still wrong if you are just trying to say "The compiler should convert the class instance because a conversion operator is available." The conversion operator isn't considered here because the isolated expression `false_result' assumes no specific type.

Code:

---

class OBase
{
};

class ODerived1:
    public OBase
{
};

class ODerived2:
    public OBase
{
};

int main()
{
    ODerived1 * lD1(0);
    ODerived2 * lD2(0);
    OBase * lB1(lD1);
    OBase * lB2(lD2);
    OBase * lB3((true) ? (lD1) : (lD2));
    return(0);
}

---

You are also wrong if you think the target variable type has anything to do with it. The type that the result of the condition operator expression may be assigned isn't considered by the compiler; the type of the expression must be fixed in isolation.

The upshot to all of this is that you must be explicit with respect to the types involved in a conditional operator expression. If you don't want to do this for whatever reason, you can't use the conditional operator; you would need to use a normal branch.

Soma

Quote:

---

Originally Posted by phantomotap

Your opinion is irrelevant.

You are simply wrong.

---

So you should have an opinion that is relevant but not me? And I don't know what it was I wrote that you think is wrong. It is easy to just ignore the rest of what you are writing when you start your post with two quite provoking/disparaging statements; you know that, right?

Apparently my compiler could chose between the two cases (although I don't know how it did it) and that is actually what matters to me. If it behaves in one way for float it should behave in the same way for the class I'm creating. I don't know what is correct behavior and which is not (which you seems to know), but I don't want it to change it when I switch type.

Quote:

---

It is easy to just ignore the rest of what you are writing when you start your post with two quite provoking/disparaging statements; you know that, right?

---

It is quite easy to write a newbie who says that some of his code "shouldn't generate any error" off as a fool or troll after having the error explained yet here I am still offering support.

Being a newbie, your opinions regarding how a C++ compiler should behave in relation to the standard is irrelevant. You don't like that? I don't care. Once you have more experience with why the code we are discussing is wrong you'll understand why it must be the way it is.

I don't think that the statement "base_safe_float<float> shouldn't generate any error here" is wrong; I know for a fact that it wrong; it is not an opinion. You don't like that? You'll just have to get over it; if you are going to be a programmer you'll always not understand a lot of things.

Quote:

---

Apparently my compiler could chose between the two cases and that is actually what matters to me.

---

Your compiler did no such thing. The conversion between `int' to `float' or `float' to `int' isn't at all the same situation. The compiler has rules to choose between those when considering an implicit conversion that form a "best fit" situation.

Quote:

---

If it behaves in one way for float it should behave in the same way for the class I'm creating.

---

No. It should not; I've told you why.

Quote:

---

I don't know what is correct behavior and which is not (which you seems to know), but I don't want it to change it when I switch type.

---

Then do what I told you to do and explicitly cast the zero result (preferably by `static_cast') of a `typedef'.

Soma

Quote:

---

It is easy to just ignore the rest of what you are writing when you start your post with two quite provoking/disparaging statements; you know that, right?

---

It is quite easy to write a newbie who says that some of his code "shouldn't generate any error" off as a fool or troll after having the error explained yet here I am still offering support.

Being a newbie, your opinions regarding how a C++ compiler should behave in relation to the standard is irrelevant. You don't like that? I don't care. Once you have more experience with why the code we are discussing is wrong you'll understand why it must be the way it is.

I don't think that the statement "base_safe_float<float> shouldn't generate any error here" is wrong; I know for a fact that it wrong; it is not an opinion. You don't like that? You'll just have to get over it; if you are going to be a programmer you'll always not understand a lot of things.

Quote:

---

Apparently my compiler could chose between the two cases and that is actually what matters to me.

---

Your compiler did no such thing. The conversion between `int' to `float' or `float' to `int' isn't at all the same situation. The compiler has rules to choose between those when considering an implicit conversion that form a "best fit" situation.

Quote:

---

If it behaves in one way for float it should behave in the same way for the class I'm creating.

---

No. It should not; I've told you why.

Quote:

---

I don't know what is correct behavior and which is not (which you seems to know), but I don't want it to change it when I switch type.

---

Then do what I told you to do and explicitly cast the zero result (preferably by `static_cast') of a `typedef'.

Soma

Something like this:

Code:

---

#ifndef NANFLOAT_H
#define NANFLOAT_H

#include <cmath>
#include <iostream>

template<typename T> class nanInit {
        T value;

public:
        nanInit() : value(sqrt(T(-1))) {} // I would optimise out the sqrt call in practice.
        nanInit(T inVal) : value(inVal) {}

        operator T() const { return retVal; }

        nanInit& operator +=(const nanInit &a)
        { return *this = value + a; }
        nanInit& operator -=(const nanInit &a)
        { return *this = value - a; }
        nanInit& operator *=(const nanInit &a)
        { return *this = value * a; }
        nanInit& operator /=(const nanInit &a)
        { return *this = value / a; }

        friend std::ostream& operator << (std::ostream &os, const nanInit &a)
        { return os << a.value; }
        friend std::wostream& operator << (std::wostream &wos, const nanInit &a)
        { return wos << a.value; }

        friend std::istream& operator >> (std::istream &is, nanInit &a)
        { return is >> a.value; }
        friend std::wistream& operator >> (std::wistream &wis, nanInit &a)
        { return wis >> a.value; }

        const nanInit operator + () const
        { return *this; }
        const nanInit operator - () const
        { return static_cast<nanInit>(-value); }

        const nanInit operator++ (int) {        // Post Increment operator
                nanInit result = *this;
                ++*this;
                return result;
        }
        const nanInit& operator++ ()        // Pre Increment operator
        { return *this = value+1; }
        const nanInit operator-- (int) {        // Post Decrement operator
                nanInit result = *this;
                --*this;
                return result;
        }
        const nanInit& operator-- ()        // Pre Decrement operator
        { return *this = value-1; }
};

#endif

---

To the best of my knowledge, this is everything you need and nothing you don't.

Aw nuts, I forgot the #ifdef DEBUG part around the constructor initialisation list of the default constructor.

phantomotap, I appreciate your support and you might be right about what you say, but if you want to help people you can't start by offending them.

Quote:

---

Originally Posted by iMalc

Something like this:

*Code*

To the best of my knowledge, this is everything you need and nothing you don't.

---

Thanks, it looks great. I haven't got time to try it out now, though, but I will definitely do it later.

Quote:

---

To the best of my knowledge, this is everything you need and nothing you don't.

---

Using two implicit conversions to implement the mathematics assignment operators is really freaking weird.

If you are going that far in the effort you can pretty much get the same behavior by change the implicit conversion to a reference and adding one for the constant reference.

Quote:

---

if you want to help people you can't start by offending them

---

O_o

That's somewhat interesting but I didn't start off in any way that could possibly be considered offensive.

Soma

Quote:

---

Originally Posted by phantomotap

Using two implicit conversions to implement the mathematics assignment operators is really freaking weird.

---

Yeah I guess it is. I had another class which made heavy use of the conversions because it needed to, and leaving them implicit seemed tidier in that case.
In this case though, I should have used a.value directly.

Oh and I changed my mind about the #ifdef part, it would of course be far better to put the conditional compilation macro around the typedef that either uses this template or a float directly.

I tried your class, iMalc, and everything seems to work like it does for floats or doubles, except from the ?: operator, just like for the class I defined.

Also, I had to change the return value for the conversion operator to value, since it returned retVal which was undefined. And to generate a NaN, on all machines that support IEEE floating point there is a macro defined in <math.h> called NAN that will do that (maybe that is what you would use in practice).

As of the problem with the ?: operator: I have the following code

Code:

---

ftype a = MIN(b - c, d);

---

where b, c and d are ftype objects, where ftype is defined as

Code:

---

typedef nanInit<float> ftype

---

and MIN is a macro defined as

Code:

---

#define  MIN(x, y)  ((x) <= (y) ? (x) : (y))

---

However, the code won't compile, and the message I'm getting from the compiler is:

Code:

---

error: operands to ?: have different types 'double' and 'pftype'

---

Converting d to float works but is bad, because the definition of ftype may change.

I may instead convert b - c back to ftype, so I have

Code:

---

ftype a = MIN(ftype(b - c), d);

---

which is better, because that code is independent of the definition of ftype.

However, my project is quite small and I have already had to change on 21 places in the code just becase I changed the definition of ftype from float to nanInit<float>. For larger projects, there could be a lot more work than this that would be necessary just for changing the typedef of ftype (or a corresponding typename), which kind of feels unnecessary. Is there really no way to get around this problem?

I think this has already been somewhat covered. You need to provide arguments that are the same type to ?:

I don't understand. I know Soma said that too, but I didn't have to provide arguments of the same type when ftype was defined as float, since I provided it with a float and an int and it worked. What's the difference here?