operator==, member function or free function

Discussion in 'C++' started by =?ISO-8859-1?Q?Mattias_Br=E4ndstr=F6m?=, Apr 7, 2005.

  1. 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
    =?ISO-8859-1?Q?Mattias_Br=E4ndstr=F6m?=, Apr 7, 2005
    #1
    1. Advertising

  2. 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/
    Donovan Rebbechi, Apr 7, 2005
    #2
    1. Advertising

  3. =?ISO-8859-1?Q?Mattias_Br=E4ndstr=F6m?=

    Rolf Magnus Guest

    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.
    Rolf Magnus, Apr 7, 2005
    #3
  4. In message <d33bal$gkv$01$-online.com>, Rolf Magnus
    <> 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
    Richard Herring, Apr 7, 2005
    #4
  5. =?ISO-8859-1?Q?Mattias_Br=E4ndstr=F6m?=

    Rolf Magnus Guest

    Richard Herring wrote:

    > In message <d33bal$gkv$01$-online.com>, Rolf Magnus
    > <> 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". ;-)
    Rolf Magnus, Apr 7, 2005
    #5
  6. In message <d33jgu$q9f$04$-online.com>, Rolf Magnus
    <> writes
    >Richard Herring wrote:
    >
    >> In message <d33bal$gkv$01$-online.com>, Rolf Magnus
    >> <> 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
    Richard Herring, Apr 7, 2005
    #6
  7. On 2005-04-07, Rolf Magnus <> 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/
    Donovan Rebbechi, Apr 7, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Vinokur
    Replies:
    3
    Views:
    5,002
    Jeff Schwab
    Mar 20, 2005
  2. ghager
    Replies:
    6
    Views:
    615
    ghager
    Jan 19, 2006
  3. Replies:
    2
    Views:
    676
    Marcus Kwok
    Mar 14, 2007
  4. Replies:
    11
    Views:
    722
    James Kanze
    May 16, 2007
  5. W Karas
    Replies:
    3
    Views:
    248
    Victor Bazarov
    Nov 30, 2012
Loading...

Share This Page