Default Initialization of reference variables in methods

Well, you must have added the const in the wrong place then...

Code:

---

#include <stdio.h>

class A
{
public:
    int m_val;
    A(int val = 0):m_val(val){};
    ~A() {}

    A& operator = (const A& v2) {m_val = v2.m_val; return *this;}
    // This gives a compiler error
    A& operator + (const A& v2) const {m_val += v2.m_val; return *this;}
  // This is a way to do it correctly
    A operator + (const A& v2) const { return A(m_val + v2.m_val); }

    operator int () {return m_val;}
};

int main(int argc, char* argv[])
{
    A  a(1),b(2),c(3);

    printf("Before: a = %d b = %d c = %d\r\n", a, b, c);

    c = a + b;

    printf("After: a = %d b = %d c = %d\r\n", a, b, c);

    return 0;
}

---

PaulWendt, you have made some good point. But the point we are talking here is not how to write a correct operator. If any thing, what you pointed out exaxtly enhances my argument.

My argument is not how to correctly write operator overloads using references. My argument is using references (in good way or in bad way) makes code unreadable and could result in things you never expected.

Back to the origin. Look at this code line again:

Code:

---

    c = a + b;

---

Any reasonable reader would read the above code line and make a reasonable assumption that A and B would NOT change. Right?

I have demonstrated, that by using references and operator overloads, (whether that usage is acceptable or not is another iissue.) That you can do some thing some where else and cause the surprising effect of changing a, in "c = a + b", without you even realize it happening. And it could totally escape you attention.

And that is bad.

Your point is entirely valid since it applies to non-const references. const-references do not change things, so I don't see how they would be bad.

Quote:

---

Totally wrong. Just added "const" to my sample code and the test result is the same.

---

Anthony,

The point I was making is that the operator+ you provided is incorrect. It's simply flat out wrong. This is a bug, and has nothing to do with readability or references or anything. It's simply wrong.

Jeff

Quote:

---

Originally posted by AnthonyMai
PaulWendt, you have made some good point. But the point we are talking here is not how to write a correct operator. If any thing, what you pointed out exaxtly enhances my argument.

---

I understand your argument, but I have to agree with Yves and
jfaust still. Take into account this code, which takes YOUR
definition of operator+() and takes out all references. Yeah,
only values are used.

Code:

---

#include <stdio.h>

class A
{
public:
    int m_val;
    A(int val = 0):m_val(val){};
    ~A() {}

    A& operator = (const A& v2) {m_val = v2.m_val; return *this;}
    A operator + (A v2) {m_val += v2.m_val; return *this;}

    operator int () {return m_val;}
};

int main(int argc, char* argv[])
{
    A  a(1),b(2),c(3);

    printf("Before: a = %d b = %d c = %d\r\n", a, b, c);

    c = a + b;

    printf("After: a = %d b = %d c = %d\r\n", a, b, c);

    return 0;
}

---

See? The problem doesn't have anything to do with references;
it's that you are using operator+=() inside operator+(). For that
reason, I'm going to have say that it's your implementation of
operator+() that's flawed and not references....

--Paul

Hehe :) That's true, I hadn't even thought about this ;)

While the particular implementation of operator+ using operator+= was not correct, it actually is a good idea to implement operator+ using operator+=. This will link together the operators so that for a more complicated class you don't need to code the same thing multiple times.

From Scott Meyer's book "More Effective C++", Item 22:

Quote:

---

template<class T>
const T operator+( const T& lhs, const T&rhs )
{ return T(lhs) += rhs; }

---

This show a correct implementation of operator+ which uses operator+= to do the work. The actual job of adding 2 items together is then handled by implementing operator+=. Note that in this case a global template was used so that any class which implements operator+= will automatically generate an operator+ which can add 2 items together (if needed).

Best regards,
John

Quote:

---

Originally posted by jfaust
I prefer policies that can be enforced by the compiler rather than relying on source documentation.

---

I agree with this COMPLETELY. The problem's mentioned so far with passing by reference and operators are problems in the original code usage and should be caught at compile time. This is why I always try to use type-based policies and some of the template paradigms as first elucidated by Barton and Nackman (and expanded upon for the general public in Andrei Alexandrescu's gorgeous Modern C++ Design: Generic Programming and Design Patterns Applied). It is my opinion that proper type-based policies can solve any of these issues which should be caught at compile time. It just seems proper design to me.

Quote:

---

It is my opinion that proper type-based policies can solve any of these issues which should be caught at compile time. It just seems proper design to me.

---

When the code of exact same syntax and format could be resolved to two different interpretations. What is the use of type checking and how would you suppose the compiler can catch any thing? This happens when references are used, because you never know, when you call a function with a variable, whether a copy of the variable or just the reference of the variable, is passed to the function. If unfortunately you have both a version of the function which takes a copy of the value, and an overloaded one which takes a reference, then even the compiler doesn't know which one you really mean.

The c = a + b example I cited was not intended to demostrate the use of operator, but to demonstrate how this completely innocent looking code could MISLEAD you into thinking a and b would not change but in fact they change. Suppose I unintentionally made a mistake in my operator, it would be really hard to catch what goes wrong.

When I look at a code line, I need to be able to interpret it correctly, without any ambiguity, and without the need to look some where else. that is READABILITY.

If looking at

foo(par1, par2);

I am NOT quite sure that par1, par2 will stay the same (as is the case when par1 is passed in as a reference), then I have a big readability problem.

That is why I am against the use of references, for the sake of complete unambiguitiness and readability. I see no need for references at all.

Quote:

---

That is why I am against the use of references, for the sake of complete unambiguitiness and readability. I see no need for references at all.

---

I hope this only refers to non-const function parameters (and even then only when one is not looking at optimization). There are many situations (some described above) that require a reference return type, particularly when you desire lvalue status. And const references are preferred to enforce when you do not want block-relative copy semantics.

As for the compile-time type safety of policies, since templates are resolved at compile-time, it is a simple matter to invoke a template policy that will catch any undesired reassignments on any of my data types. Basically, any data I expose to a client can have a policy template typelist attached that will expose only those semantics I wish to allow (even defaults and assignments). In the second given case we are exploring (concerning passing by non-const referrence) I would send the data types that need to be manipulated wrapped up in a smart-pointer with a no-reference no-assignment policy attached. The design of such a policy could follow Stroustrup's point that "An Object may be explicitly converted to a reference type X& if a pointer to that object may be explicitly converted to an X*" although I think that an ambiguous resolver policy might be preferrable (as Mister Mai mentions at the end of his first paragraph).

The basic point is that I should not expose any objects to client programmers that do not have appropriate policies attached that would enforce my design goals. Objects created by the clients that do as described with operator+ would just mean I have bad coders for clients (and as pointed out above, does not rely on the referrence). I too can code badly if desired.

To Anthony Mai,

There are specific cases when overloading operators where the use of references is needed. One example is the overloading of operator[]. This operator needs to return something that can be the target of an assignment. You can't return a pointer, because that would require a change to the way that you write the assignment.

For any of the arithmetic operators, while you could pass a copy of the object, this involves constructing and destructing temporary objects. I would avoid this by passing a const reference to the object.

For the type of programming that I am generally working on (CAD systems with various types of points / matrices), I find that overloading operators makes the syntax much easier and more natural. The use of references when overloading these operators improves efficiency and is sometimes necessary.

Best regards,
John

Quote:

---

Originally posted by AnthonyMai
If looking at

foo(par1, par2);

I am NOT quite sure that par1, par2 will stay the same (as is the case when par1 is passed in as a reference), then I have a big readability problem.

---

As mentioned before, to write the above line you need to take a look at the declaration of 'foo()' otherwise you will not know which and how many parameters etc. need to be passed in. To read the above line you can quickly take a look the declaration as well...

Bottom line is, that you always have the declaration to look at, and except for standard functions you most-likely have to do it if you want to use the function...

Therefore this cannot and is not a valid argument against the use of references...

Additionally with some kind of style guidelines you would even be able to see it while looking at the function call...

Code:

---

foo(refPar1, Par2);    // 'refPar1' by reference, 'Par2' by value
foo(pPar1, Par2);      // 'pPar1' by pointer, 'Par2' by value

---

Of course this is only a valid argument while having a style guideline in place and actually confirming to it...