Re: How to program this in C++?

From:

Kai-Uwe Bux <jkherciueh@gmx.net>

Newsgroups:

comp.lang.c++

Date:

Thu, 08 Nov 2007 17:10:52 -0800

Message-ID:

<fh0c3j$sjm$1@murdoch.acc.Virginia.EDU>

Pavel Shved wrote:

On Nov 8, 11:58, Kai-Uwe Bux <jkherci...@gmx.net> wrote:

Pavel Shved wrote:

On 8 , 10:24, Kai-Uwe Bux <jkherci...@gmx.net> wrote:

a) public inheritance. That would expose the integer part of your
float to independent manipulation (essentially like making the integer
data member public, BadIdea(tm)). On top of that, you get into all
sorts of trouble with pointers to integer objects that now could point
to floats, and more importantly, your float type would match any
function

integer some_function ( integer const & )

which you probably don't want.

I think matching floats in integer funtions is the thing one likely
does want. That's done not by inheritance (which won't work in the
way you expect floats to act as integers), but by specifying user-
defined typecast rather.

I am not sure that I want floats to silently match integer functions.
Have a look at the return type. For a simple function like

  integer sqr ( integer const & i ) {
    return ( i*i );
  }

the result could be rather surprising when you feed in a float. Life will
get even more surprising if you also provide a conversion constructor
interger -> float. Then, you could do:

  float a = ...
  a = sqr( a );

and what you get is not exactly what you see.

I see the following: float variable is passed to an integer function
and i expect the same behaviour as with intrinsic C++ types. And i do
get it.

A problem is of course that you would need to remember exactly which
function are integer and which are not. When you see gcd() or sin(), it's
probably not a problem. But for something like sqr() it becomes more iffy;
and I don't even want to think about operators like a*b.

In fact, I don't think that mimicking the behavior of built-in numeric types
is that good an idea: (a) it's not feasible to copy their behavior exactly
because overload resolution and user-defined conversions behave different
from promotion and arithmetic conversion rules; and (b) even for the
built-in types it causes all sorts of headaches (like when you mix signed
and unsigned types).

Of course if you don't like this endeavour you may fix it
out, but i prefer writing intgrality-indepentent functions with
templates, like

template <typename T> T sqr (T const& _t)
{
return _t*_t;
}

I usually do the same.

, letting integers calculated with aid of floating algorithms fit to
greates-common-divisor function or something with no explicit conversions.

but I don't understand this part.

Best

Kai-Uwe Bux