How Methods Return Objects

[Victor Bazarov]

Victor Bazarov wrote in @newsread1.dllstx09.us.to.verio.net in comp.lang.c++:

In message <[email protected]>, "Niels Dekker (no reply
[...]

In what situation would you prefer to implement a binary
operator as a member function?


If the function modifies its argument (e.g. operator+= above.).

Operator += is an assignment operator and it cannot be implemented as
a non-member, no matter whether it in fact modifies its left operand
or not (and it is up to you to decide whether it does modify it).

#include <iostream>
#include <ostream>

struct X {};

X &operator += ( X &lhs, X const & )
{
std::cout << "Ok" << std::endl;
return lhs;
}

int main()
{
X a, b;
a += b;
}

Works fine for me.

Perhaps it's my misreading of the Standard. First it calls all @=
operators "assignment operators" (@ denotes an operation like + or -)
then it says that the assignment operator has to be a member, but when
it gives an example it only speaks of operator=. Does that mean that
operators like += don't have to be members? Perhaps that's open to
interpretation. Perhaps not. I will ask for clarification in the
standard newsgroup.

Also operator ->(), I can't remember any others (*).

*) Ok, new and delete, but I don't think they count .

They are actually static, while not declared so. Very unusual.

V

 

[Rob Williscroft]

Victor Bazarov wrote in @newsread1.dllstx09.us.to.verio.net in comp.lang.c++:

Perhaps it's my misreading of the Standard. First it calls all @=
operators "assignment operators" (@ denotes an operation like + or -)
then it says that the assignment operator has to be a member, but when
it gives an example it only speaks of operator=. Does that mean that
operators like += don't have to be members? Perhaps that's open to
interpretation. Perhaps not.

Yep, I just looked and I see your point.

I will ask for clarification in the
standard newsgroup.

Sounds good, though AFAICT Exsisting Practice(tm) is that operator @=
can be a non-member, so the question is really "does the standard need
clarification".

Rob.

 

[Mark A. Gibbs]

[snip] (but note that the numbers in parentheses refer to a paragraph in
the standard related to this).

I was under the (mistaken) impression that this was a standard way to
indicate member variables. Do you know what leading underscores are
reserved for? Also, what is the standard way to indicate a member
variable -- trailing underscore?

[snip]

Its a good way to indicate member variables. I don't understand why
some people claim its dangerous (I am aware of when underscore use is
illegal). Perhaps Mark could justify his claim?

as i pointed out it is not technically illegal to use a leading
underscore in this case. most people know that double underscores are
reserved, and many know that an underscore followed by an uppercase
letter is reserved also.

however, leading underscores followed by a lowercase letter are reserved
for the implementation for use in the global namespace. most people
don't know that.

in my mind it makes little sense to use leading underscores when there
are so many restrictions and caveats. is it ok to use an underscore
followed by a number? (yes, as long as it's not in the global
namespace). what if you're dealing with programmers who don't speak a
latin-based language natively, and who have to consult a reference in
order to remember what's uppercase and what's lowercase? (afaict, the
standard doesn't even bother to define that, which tells me that it
doesn't care about splitting the difference most of the time, so why here?)

to hell with it all. i just say no leading underscores at all. use
trailing underscores, if anything; there are no restrictions on those.
or prefix "m_". whatever you want, as long as it's clear. i think
leading underscores, with all their hazards, are not particularly clear.
but i live in a free country, so i won't tell anyone else what to do.

mark

 

[David Hilsee]

I don't find the rule, 'use a leading underscore followed by a lower case
letter for member variables' hard to remember. I would always use a leading
lower case letter in any case even if I wasn't using a leading underscore. I
don't think the argument that you 'might as well' avoid it in new code very
convincing. Why exactly? No bad things are going to happen that I can see.

Most of this is a matter of personal taste, so while no bad things will
happen, some folks may not like it. Personally, I don't like leading
underscores because that naming convention is used by the implementation in
the global namespace, which can make the code look like it is referencing
implementation-specific symbols when it is not. Every time I see a leading
underscore, I think "implementation-specific functionality." Granted, I can
think for a second and realize that the code is referencing a member, but
the main reason for using a different convention for members is that it
makes them look different from other symbols and therefore makes the code
easier to read. Using a naming convention that is already used elsewhere
can almost defeat the purpose of using the convention in the first place.

 

[John Harrison]

Most of this is a matter of personal taste, so while no bad things will
happen, some folks may not like it. Personally, I don't like leading
underscores because that naming convention is used by the implementation
in
the global namespace, which can make the code look like it is referencing
implementation-specific symbols when it is not. Every time I see a
leading
underscore, I think "implementation-specific functionality." Granted, I
can
think for a second and realize that the code is referencing a member, but
the main reason for using a different convention for members is that it
makes them look different from other symbols and therefore makes the code
easier to read. Using a naming convention that is already used elsewhere
can almost defeat the purpose of using the convention in the first place.

That's a fair point, although in my coding I very rarely use such
implementation-specific symbols.

Maybe I should give the trailing underscore method a go, see if I too can
learn to love it.

john

 

[Richard Herring]

Operator += is an assignment operator and it cannot be implemented as
a non-member, no matter whether it in fact modifies its left operand
or not (and it is up to you to decide whether it does modify it).

True, but if it doesn't do so, and do it in a way consistent with
operator+ and operator= (and probably also operators - and -= and maybe
++ and --) I humbly suggest you should be calling them something else,
on the principle of least surprise.