Re: Operator overloading and copy constructor. Can't find the error.
[I've reordered the quoting some, so that my answers make
some sense. I hope I didn't screw up in doing it.]
On Jul 22, 11:21 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
"clicwar" <clic...@gmail.com> wrote in message
news:1185134796.453311.9430@k79g2000hse.googlegroups.com...
news:1185131506.971858.250680@m3g2000hsh.googlegroups.com...
A simple program with operator overloading and copy constructor:
[...]
Vector::Vector(Vector &source) {
x = (source.x)*2 ; y = (source.y)*2 ;
}
Note the semantics of the copy constructor. This doesn't copy.
Vector Vector::operator+ (Vector a) {
And note that the operator+ takes its argument by copy.
[...]
Change it to:
Vector::Vector( const Vector& a )
and it should work.
First of all, thank you Jim. It worked ( but i don't know why the
simple addition of the const modifier can do that. Could you tell
me? ).
You can't bind a temporary to a non-const reference. With your
original version of the copy constructor, you cannot copy
temporary values, only named variables.
If you fail to define a copy constructor, the compiler generates
one for you automatically. Which has a const reference as
parameter. (The rules are actually a little more complicated,
but that's the usual situation.)
The output now is:
Data members of the vector c: (13,5)
Data members of the vector e: (13,5)
But it should be (16,6) for both c and e.
Any suggestions?
On 22 jul, 16:20, "Jim Langston" <tazmas...@rocketmail.com> wrote:
"clicwar" <clic...@gmail.com> wrote in message
Well, I get even a weirder result with your code (26.3 or
something). Not sure why,
His copy constructor doesn't copy; the new object has different
values. The compiler is allowed to assume that a copy
constructor copies, and in various cases, suppress intermediate
temporaries, and the copy that was used to create them. Given
his copy constructor, a large range of results are possible.
but if you fix your operator+ it'll show the correct answer of
16.6
Vector operator+ (const Vector& a) const;
Operators and constructors have specific signatures.
Only a very few do. For the most part, all that is required is
that they take the right number of arguments, and that at least
one parameter is a user defined type (class or enum). There's
absolutely nothing wrong with his operator+ (from a language
standpoint---it certainly isn't very idiomatic); the problem is
with his copy constructor.
const is part of them and I believe references are also.
I don't think that there's any case where the const is required
by the language (although the operator may not be usable where
one would expect to use it without the const), and about the
only time a reference is required is for the copy constructor.
That's from the language standpoint, of course. From the point
of view of usability, or user expectations, you really want to
follow the usual models. (But even in the usual models, whether
operator+ takes a const reference or a value depends on the
type.)
I really don't know what was going on that was giving us the
wrong results (I.E. no clue what the compiler was donig) and
don't really care, cause fixing the operator+ fixes the
problem.
As to why it didn't work without your constructor having
const, that's because it didn't recognize it as a copy
constructor.
If the compiler hadn't recognized his constructor as a copy
constructor, it would have generated one, and his original code
would have compiled. The problem is just the opposite; his code
didn't work because the compiler recognized that he had already
provided a copy constructor. Even though it couldn't be
called in a number of situations because it didn't have the
"usual" signature, the compiler didn't generate another one.
Which makes me think, changing it from a copy to a reference
probably means your copy constructor is not working right, let
me look at it...
Exactly. And you have to be careful with copy constructors,
because the compiler is allowed to assume that all they do is
copy; the number of times it actually gets called may vary from
one compiler to the next, or according to the optimization
options.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34