x.sin() versus sin(x)

Hello,

I have the following code:

<code>
class X {
___ sin();
}

X sin( X ) { return sin( y, x ); }
</code>

Then what should X::sin() do and return? Should it do the same, that is
sin( y, x ) and return y, or should it do sin( x, x ), that is compute the
sine of itself and store it in itself?

I am stuck in choosing either of these, so I would like to know your
opinion on this, and/or some examples of classes which have both these
functionalities.

Thanks in advance for any reply.

Regards,

Franky B.

franky.backeljauw@ua.ac.be

wrote in message news:< ca.ua.ac.be>...
> Hello,
>
> I have the following code:
>
> <code>
> class X {
> ___ sin();
> }
>
> X sin( X ) { return sin( y, x ); }
> </code>
>
> Then what should X::sin() do and return? Should it do the same, that is
> sin( y, x ) and return y, or should it do sin( x, x ), that is compute the
> sine of itself and store it in itself?
>
> I am stuck in choosing either of these, so I would like to know your
> opinion on this, and/or some examples of classes which have both these
> functionalities.
>
> Thanks in advance for any reply.
>
> Regards,
>
> Franky B.


Your code isn't compilable. I cannot even understand what you ask.
What is sin(y, x)? Never heared of a sine that has two arguments.
Moreover, why reinventing the wheel? The standard libraries come with
a sin function. Please clarify.

Dan Cernat

The sin function should *return* its result, not store it in an output
parameter. It should be defined something like this:

float sin( float x );

or

double sin( double x );


I see no reason it should be a member of a class, either. The sin function
operates on a single value and returns a single value, so there's no reason
to have it a class member. But if, for some reason, you needed such a
function, then it should still return the result, not store it in a
parameter.

-Howard

P.S., what's with the three leading underscores before the function name?
And where's the return type?

Howard

On Mon, 8 Sep 2003, Dan Cernat wrote:

> > I have the following code:
> >
> > <code>
> > class X {
> > ___ sin();
> > }
> >
> > X sin( X ) { X y; sin( y, x ); return y; }
> > </code>
>
> Your code isn't compilable. I cannot even understand what you ask.
> What is sin(y, x)? Never heared of a sine that has two arguments.
> Moreover, why reinventing the wheel? The standard libraries come with
> a sin function. Please clarify.

The function sin( y, x ) computes the sine of x and stores the result in
y. Indeed, the code seems to be wrong; I corrected it above. That is,
the function outside the class is to be used as in y = sin(x).

The question is what the function X::sin() should do when it occurs in the
class as given in the example. More precisely, should x.sin() compute the
sine of x and store the result back into x, or should it behave as y =
sin(x), that is x.sin() computes the sine of x and returns the result as a
new object of class X?

My apologies for the apparant mistake.

Thanks for any reply.

Regards,

Franky B.

franky.backeljauw@ua.ac.be

On Mon, 8 Sep 2003, Howard wrote:

> The sin function should *return* its result, not store it in an output
> parameter. It should be defined something like this:
>
> float sin( float x ); or double sin( double x );
>
> I see no reason it should be a member of a class, either. The sin function
> operates on a single value and returns a single value, so there's no reason
> to have it a class member. But if, for some reason, you needed such a
> function, then it should still return the result, not store it in a
> parameter.

It feels strange, I know, but now I have a class which provides these
functions as member functions, and also as non-member functions. While
the non-member function behaves as in y = sin(x), that is it computes the
sine of x and returns the result (so it can be assigned to y), I thought
the member function would behave as in x = x.sin(), that is computing the
sine of the object and storing the result back in x. Otherwise, I would
see no reason to have these member functions at all.

> P.S., what's with the three leading underscores before the function
> name? And where's the return type?

That depends on what it should do. It is either X& or void, depending on
whether it should return the result or not (I believe it should not return
the result if the behavior is as in x = sin(x)).

Regards,

Franky B.

franky.backeljauw@ua.ac.be

>
> It feels strange, I know, but now I have a class which provides these
> functions as member functions, and also as non-member functions. While
> the non-member function behaves as in y = sin(x), that is it computes the
> sine of x and returns the result (so it can be assigned to y), I thought
> the member function would behave as in x = x.sin(), that is computing the
> sine of the object and storing the result back in x. Otherwise, I would
> see no reason to have these member functions at all.
>
> > P.S., what's with the three leading underscores before the function
> > name? And where's the return type?
>
> That depends on what it should do. It is either X& or void, depending on
> whether it should return the result or not (I believe it should not return
> the result if the behavior is as in x = sin(x)).
>
I cannot imagine when you would ever write "x = sin(x)". The input
parameter is a value in degreees or radians, and the output is a value
between -1 and 1.

If you have some legitimate reason to modify x itself by computing its sine,
then feel free to do so. As to whether such a function should return a copy
of x or simply modify x, it all depends on how you intend to use it. If
you're going to want to write it as part of a longer equation (assignment
statement), such as "y = 3 * sin(x)", then you'll obviously want it to
return a useable value.

If you're *never* going to want to do that, then you can just as easily have
a void return type and modify the object in place. But in that case, you
might want to change the name from "sin" to "ConvertToSine" or something
similar, since using the name "sin" implies the usual mathematical function,
not a procedural call.

-Howard

Howard

franky backeljauw wrote:

> I have the following code:
>
> <code>
> class X {
> X sin(void) const;
> };
>
> X sin(const X& x) { return sin(y, x); }
> </code>
>
> Then what should X::sin(void) const do and return? Should it do the same
> that is sin(y, x) and return y, or should it do sin(x, x)
> that is compute the sine of itself and store it in itself?
>
> I am stuck in choosing either of these
> so I would like to know your opinion on this
> and/or some examples of classes which have both these functionalities.

const X x;
assert(x.sin() == sin(x); // always true

E. Robert Tisdale

On Mon, 8 Sep 2003 20:50:11 +0200, wrote:

>On Mon, 8 Sep 2003, Howard wrote:
>
>> The sin function should *return* its result, not store it in an output
>> parameter. It should be defined something like this:
>>
>> float sin( float x ); or double sin( double x );
>>
>> I see no reason it should be a member of a class, either. The sin function
>> operates on a single value and returns a single value, so there's no reason
>> to have it a class member. But if, for some reason, you needed such a
>> function, then it should still return the result, not store it in a
>> parameter.
>
>It feels strange, I know, but now I have a class which provides these
>functions as member functions, and also as non-member functions. While
>the non-member function behaves as in y = sin(x), that is it computes the
>sine of x and returns the result (so it can be assigned to y), I thought
>the member function would behave as in x = x.sin(), that is computing the
>sine of the object and storing the result back in x. Otherwise, I would
>see no reason to have these member functions at all.

Right, drop the member functions (making the non-members friends if
necessary).

>
>> P.S., what's with the three leading underscores before the function
>> name? And where's the return type?
>
>That depends on what it should do. It is either X& or void, depending on
>whether it should return the result or not (I believe it should not return
>the result if the behavior is as in x = sin(x)).

I presume you mean "X or void", not "X& or void".

It would be counter-intuitive to have sin be a member function that
modifies the "this" pointer. The intuitive version is a non-member
that returns the sine of the argument.

Tom

tom_usenet