Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > operator==, member function or free function

Reply
Thread Tools

operator==, member function or free function

 
 
=?ISO-8859-1?Q?Mattias_Br=E4ndstr=F6m?=
Guest
Posts: n/a
 
      04-07-2005
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
 
Reply With Quote
 
 
 
 
Donovan Rebbechi
Guest
Posts: n/a
 
      04-07-2005
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/
 
Reply With Quote
 
 
 
 
Rolf Magnus
Guest
Posts: n/a
 
      04-07-2005
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.

 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      04-07-2005
In message <d33bal$gkv$01$(E-Mail Removed)-online.com>, Rolf Magnus
<(E-Mail Removed)> 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
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      04-07-2005
Richard Herring wrote:

> In message <d33bal$gkv$01$(E-Mail Removed)-online.com>, Rolf Magnus
> <(E-Mail Removed)> 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".

 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      04-07-2005
In message <d33jgu$q9f$04$(E-Mail Removed)-online.com>, Rolf Magnus
<(E-Mail Removed)> writes
>Richard Herring wrote:
>
>> In message <d33bal$gkv$01$(E-Mail Removed)-online.com>, Rolf Magnus
>> <(E-Mail Removed)> 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
 
Reply With Quote
 
Donovan Rebbechi
Guest
Posts: n/a
 
      04-07-2005
On 2005-04-07, Rolf Magnus <(E-Mail Removed)> 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/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How would I use qsort to sort a struct with a char* member and a long member - I want to sort in order of the long member Angus Comber C Programming 7 02-05-2004 06:41 PM
performance of static member function vs. instance member function 0to60 C++ 4 11-21-2003 05:25 PM
Function pointer member variable to non-member function Alex C++ 0 10-15-2003 05:26 PM
Function pointer member variable to non-member function slide_o_mix C++ 0 10-15-2003 03:37 PM
Passing a pointer to member function as a parameter to another member function Newsgroup - Ann C++ 5 07-30-2003 02:54 AM



Advertisments