Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   operator==, member function or free function (http://www.velocityreviews.com/forums/t290009-operator-member-function-or-free-function.html)

=?ISO-8859-1?Q?Mattias_Br=E4ndstr=F6m?= 04-07-2005 08:20 AM

operator==, member function or free function
 
Hello!

I'm just curious as to what the group recommends when implementing
operator==? Should it be a member function or a free function. The
reason I might want to have it as free function is to get type
conversion on the left hand side argument.

class Decimal() {
public:
Decimal(std::string);
}

Decimal d("1.2");
d == "1";
"1" == d;

As fas as I understand this is the recomended way to implement the
arithmetic operators. Does the same arguments hold for operator==?

Regards,
Mattias

Donovan Rebbechi 04-07-2005 12:10 PM

Re: operator==, member function or free function
 
On 2005-04-07, Mattias Brändström <> wrote:
> Hello!
>
> I'm just curious as to what the group recommends when implementing
> operator==? Should it be a member function or a free function. The


Make it a free function unless it needs to be a member function. If
it has to be a member function, you can write the other version in
terms of the member function.

> reason I might want to have it as free function is to get type
> conversion on the left hand side argument.
>
> class Decimal() {
> public:
> Decimal(std::string);


I hope this isn't real code. This constructor should be
declared explicit to prevent implicit conversion, and the
argument should probably be passed by reference (this is
a general rule of thumb for class types). There are places
where one may want to permit implicit conversion, but where
the types are fundamentally different, it isn't recommended.
e.g. this shouldn't be allowed: Decimal x; x += "2.3";

btw, better to go with least common denominator and use a const
char* argument, not a string argument.

Also, I'd question even having an operator== if it's a
floating point class.

Cheers,
--
Donovan Rebbechi
http://pegasus.rutgers.edu/~elflord/

Rolf Magnus 04-07-2005 01:07 PM

Re: operator==, member function or free function
 
Donovan Rebbechi wrote:

> On 2005-04-07, Mattias Brändström <> wrote:
>> Hello!
>>
>> I'm just curious as to what the group recommends when implementing
>> operator==? Should it be a member function or a free function. The

>
> Make it a free function unless it needs to be a member function. If
> it has to be a member function, you can write the other version in
> terms of the member function.
>
>> reason I might want to have it as free function is to get type
>> conversion on the left hand side argument.


Yep, that's the usual reason for making it a non-member. (to the OP) So why
do you ask? Do you have any reason to make it a member?

>>
>> class Decimal() {
>> public:
>> Decimal(std::string);

>
> I hope this isn't real code. This constructor should be
> declared explicit to prevent implicit conversion,


Unless he wants such a conversion.

> and the argument should probably be passed by reference (this is
> a general rule of thumb for class types).


In this case, by reference to const, i.e.

Decimal(const std::string&);

> There are places where one may want to permit implicit conversion, but
> where the types are fundamentally different, it isn't recommended.
> e.g. this shouldn't be allowed: Decimal x; x += "2.3";


It isn't anyway.

> btw, better to go with least common denominator and use a const
> char* argument, not a string argument.


I'd say that depends on how the constructor is using it. If it's parsing the
string using a stringstream, it needs an std::string anyway. Then there is
not much sense in needing to make a const char* out of an std::string by
using c_str(), just to copy that into a new std::string.

> Also, I'd question even having an operator== if it's a floating point
> class.


It might be a fixed point class.


Richard Herring 04-07-2005 03:17 PM

Re: operator==, member function or free function
 
In message <d33bal$gkv$01$1@news.t-online.com>, Rolf Magnus
<ramagnus@t-online.de> writes
>Donovan Rebbechi wrote:
>

[...]

>> Also, I'd question even having an operator== if it's a floating point
>> class.

>
>It might be a fixed point class.


Even if it's not, that's no reason not to define equality.

Granted, _arithmetic_ operations on floating-point numbers are not
always reversible, so there's no guarantee that (a+b-b)==a, but there's
more to numbers than arithmetic.

One often wants to sort on a set of floating values, and that requires
not arithmetic but a strict weak ordering. Floating-point numbers
(except maybe NaN ;-) have a natural ordering defined by operator< which
has all the right properties. Given that, there's an obvious definition
for operator== (neither < nor >) which is consistent with that ordering,
and it would be pointless not to define these operators in the obvious
way.

--
Richard Herring

Rolf Magnus 04-07-2005 03:27 PM

Re: operator==, member function or free function
 
Richard Herring wrote:

> In message <d33bal$gkv$01$1@news.t-online.com>, Rolf Magnus
> <ramagnus@t-online.de> writes
>>Donovan Rebbechi wrote:
>>

> [...]
>
>>> Also, I'd question even having an operator== if it's a floating point
>>> class.

>>
>>It might be a fixed point class.

>
> Even if it's not, that's no reason not to define equality.
>
> Granted, _arithmetic_ operations on floating-point numbers are not
> always reversible, so there's no guarantee that (a+b-b)==a, but there's
> more to numbers than arithmetic.
>
> One often wants to sort on a set of floating values, and that requires
> not arithmetic but a strict weak ordering.


You don't need operator== for that.

> Floating-point numbers (except maybe NaN ;-) have a natural ordering
> defined by operator< which has all the right properties. Given that,
> there's an obvious definition for operator== (neither < nor >) which is
> consistent with that ordering, and it would be pointless not to define
> these operators in the obvious way.


If there is not much use for operator==, then it's not poinless to not
define it. Same for operator!=, to add another "not". ;-)


Richard Herring 04-07-2005 04:47 PM

Re: operator==, member function or free function
 
In message <d33jgu$q9f$04$2@news.t-online.com>, Rolf Magnus
<ramagnus@t-online.de> writes
>Richard Herring wrote:
>
>> In message <d33bal$gkv$01$1@news.t-online.com>, Rolf Magnus
>> <ramagnus@t-online.de> writes
>>>Donovan Rebbechi wrote:
>>>

>> [...]
>>
>>>> Also, I'd question even having an operator== if it's a floating point
>>>> class.
>>>
>>>It might be a fixed point class.

>>
>> Even if it's not, that's no reason not to define equality.
>>
>> Granted, _arithmetic_ operations on floating-point numbers are not
>> always reversible, so there's no guarantee that (a+b-b)==a, but there's
>> more to numbers than arithmetic.
>>
>> One often wants to sort on a set of floating values, and that requires
>> not arithmetic but a strict weak ordering.

>
>You don't need operator== for that.


I know. Read on:
>
>> Floating-point numbers (except maybe NaN ;-) have a natural ordering
>> defined by operator< which has all the right properties. Given that,
>> there's an obvious definition for operator== (neither < nor >) which is
>> consistent with that ordering,


.... and having == (or !=) means you can then add searching to the list
of algorithms that can be used on the class.

>> and it would be pointless not to define
>> these operators in the obvious way.

>
>If there is not much use for operator==, then it's not poinless to not
>define it. Same for operator!=, to add another "not". ;-)


Sure, if that's truly the case. No point in cluttering the interface
with unnecessary stuff.

But searching and sorting are so common that it's quite likely that the
_user_ of the class will want to do them, even if the designer didn't
consider the possibility.

But none of those considerations has anything to do with whether the
class happens to be some kind of implementation of floating-point
arithmetic. And _that_ was my point.

--
Richard Herring

Donovan Rebbechi 04-07-2005 08:40 PM

Re: operator==, member function or free function
 
On 2005-04-07, Rolf Magnus <ramagnus@t-online.de> wrote:

>> I hope this isn't real code. This constructor should be
>> declared explicit to prevent implicit conversion,

>
> Unless he wants such a conversion.


Sure, but it's the sort of thing one should think twice about "wanting".

>> and the argument should probably be passed by reference (this is
>> a general rule of thumb for class types).

>
> In this case, by reference to const, i.e.
>
> Decimal(const std::string&);


yep

>> There are places where one may want to permit implicit conversion, but
>> where the types are fundamentally different, it isn't recommended.
>> e.g. this shouldn't be allowed: Decimal x; x += "2.3";

>
> It isn't anyway.


If you tweak the constructor to take const char* instead of string, it is.

>> btw, better to go with least common denominator and use a const
>> char* argument, not a string argument.

>
> I'd say that depends on how the constructor is using it. If it's parsing the
> string using a stringstream, it needs an std::string anyway. Then there is
> not much sense in needing to make a const char* out of an std::string by
> using c_str(), just to copy that into a new std::string.


Reduces dependencies by moving the use of std::string from interface to
implementation. In some contexts, a good thing.

>> Also, I'd question even having an operator== if it's a floating point
>> class.

>
> It might be a fixed point class.


Yep.

Cheers,
--
Donovan Rebbechi
http://pegasus.rutgers.edu/~elflord/


All times are GMT. The time now is 01:47 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.