float/double equality in template definition without rtti

[Andy Venikov]

That's what I meant. With "rules out any chance for inlining", I

actually meant "rules out any chance for inlining in this place". Where
called directly, the function can indeed be inlined.

Sorry for misunderstanding. I interpreted your original comment as if
inlining wouldn't be possible at all for that function.

Right, but it can be inlined even when called through a pointer, which a
reglar function can't.

I don't think I understand you. When you pass a pointer to an object instead
of the pointer to a function, you still have to call operator() through
the object's pointer. It means no inlining is possible for that particular
call. Then how having a functor is better than a pointer to a function?


Andy.

 

[Howard]

I like that slip-up. So would the solution be implemented in, say, breast
implants?

sorry: silizium

Since your post is in English (and not German), wouldn't the correct term be
"silicon"? I doubt many English-speaking folk know the term "silizium".


-Howard

 

[Rolf Magnus]

I don't think I understand you. When you pass a pointer to an object
instead of the pointer to a function, you still have to call
operator() through the object's pointer. It means no inlining is
possible for that particular call.

It doesn't call the function through the pointer to the object. It just
calls the function using a regular function call (or inline) with the
pointer to the object as a hidden parameter.
However, this is only true for non-virtual functions. Virtual functions
would usually need to be called through a vtable pointer.

 

[E. Mark Ping]

The Links seem to be a good source of information and I will spend
some time on reading the articles. Thank you very much.

You're welcome. And oh:

A: Because it makes the message harder to read.

Q: Why shouldn't I top post?

That means, there doesn't exist "the solution" of the float/double
equality problem but the solution depends on the problem to be solved
- did I get it right ?

Yes.

(Side note: In my opinion this is a defective compiler. This kind of
warning may be useful in a Lint-style tool, but IMO doesn't belong in
a compiler.)

template <class Type>
inline bool areEqual(const Type &a, const Type &b) {
if ( std::numeric_limits<Type>::is_integer ) {
//...
} else {
//...
}
}

Our compiler at least optimized the "if" statement away. If that
isn't the case for you, template specialization may be a solution.

Also, you may be able to overload a template function using
Int2Type< std::numeric_limits<Type>::is_integer >.

I highly recommend reading Andrei Alexandrescu's "Modern C++ Design"
if you go down this path.

If the warning is specious, I recommend disabling it. Otherwise,
you're going to spend a lot of effort on an unnecessary adventure.

 

[E. Mark Ping]

Maybe, but I'd say those would be very rare.

It depends on the problem domain. It can be very common in the work I
do. In particular, the following case:

float a,b;

a = SomeGnarlyCalcultion();
b = a;
....
....

if (b == a)
{
}

is a situation in which (b == a) must be true IIRC.

Then explain in a few words where testing for equality is useful and
where it isn't, and why.

He's explained in detail in several articles. You may have noticed
that I referenced some of his articles elsewhere. I suggest you read
them before quizzing him on his knowledge of FP.

 

[Pete Becker]

I don't think I understand you. When you pass a pointer to an object instead
of the pointer to a function, you still have to call operator() through
the object's pointer.
Right.

It means no inlining is possible for that particular
call.

If operator() isn't virtual it doesn't matter whether the call is
through a pointer, a reference, or a named object. The compiler sees the
full code, and can inline it.

 

[Pete Becker]

That means, there doesn't exist "the solution" of the float/double equality problem but the solution depends on the problem to be solved - did I get it right ?

Absolutely right.