Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Understanting assignments

Reply
Thread Tools

Understanting assignments

 
 
et al.
Guest
Posts: n/a
 
      08-25-2010
Hi all! I am following the C++ operator overloading guidelines (*) in
order to create a simple matrix class, with all standard operators
(sum, difference, and so on). Everything worked until I tried to use
the assignment operator! As with the guideline, I started implementing
the compound assignments, then I use them exactly as in the guide to
create an operator (first operator=*, and next using it for defining
operator*).

What I am battling with this compilation error:

error: no match for 'operator=' in 'p = #'obj_type_ref' not supported
by dump_expr#<expression error>(((matrix&)(& o)))'
note: candidates are: virtual matrix& matrix:perator=(matrix&)

within this simple assignment:

matrix p, a, o;
// Do something with "a" and "o", then:
p = a * o; // <==== BAM! Compilation error!

My class "matrix" defines all the operators I need as in the guideline:

class matrix {
// ...
virtual matrix& operator=(matrix& src);

virtual matrix& operator+=(matrix& src);
virtual matrix& operator-=(matrix& src);
virtual matrix& operator*=(double src);
virtual matrix& operator*=(matrix& src);

virtual matrix operator+(matrix& src);
virtual matrix operator-(matrix& src);
virtual matrix operator*(double src);
virtual matrix operator*(matrix& src);

virtual bool operator==(matrix& src);
virtual bool operator!=(matrix& src);
// ...
};

However, if I change a little the assignment using the compound ones,
it works perfectly:


matrix p, a, o;
// Do something with "a" and "o", then:
p = a;
p *= o;
// It works like a charm


I am sorry I can't understand the error, I am still learning! Can you
point me in the right direction?

Thanks & cheers!


(*) URL:
http://www.cs.caltech.edu/courses/cs...e/cpp-ops.html

 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      08-25-2010
On 25 Aug., 17:22, Christian Hackl wrote:
>
> Oh, and there's one more thing I overlooked before. The functions
> themselves should be declared const, too, because they don't change
> their own matrix.
>
> matrix const operator+(matrix const& src) const;

^^^^^
This const is debatable. I never felt the need to return objects by
const value. And with C++0x coming along you're effectivly disabling
move semantics with this.

> ...
> bool operator==(matrix const& src) const;


Also, for symmetry reasons the above two operators could be replaced
by free functions.

Cheers!
SG
 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      08-25-2010
On 25 Aug., 18:31, Christian Hackl wrote:
> SG ha scritto:
>
> > On 25 Aug., 17:22, Christian Hackl wrote:

>
> >> matrix const operator+(matrix const& src) const;

> > * * * * *^^^^^
> > This const is debatable. I never felt the need to return objects by
> > const value.

>
> How else do you prevent (a * b) = c?
>
> This is also an item in Effective C++.


Yes. I have that book (3rd edition). I like it. But this is one of the
very few rules I don't agree with. And I'm sure that if a C++0x-aware
edition came out, it would say something different.

If you want this code fragment to be ill-formed, you also have the
option of adding a ref qualifier to your assignment operator in C++0x.

Anyhow, for about 10 years, I'm using programming languages that have
== as comparison operator. I really can't recall the last time (if
ever) I made this mistake you're referring to.

> I've not studied C++0x move semantics enough. But surely there's a way
> to have both the efficiency gained by move semantics and the prevention
> of (a * b) = c.


Yes:

class foo {
...
foo& operator=(foo const&) &;
...
};


Cheers!
SG
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      08-25-2010
On 8/25/2010 12:48 PM, Christian Hackl wrote:
> Pete Becker ha scritto:
>
>> On 2010-08-25 12:31:47 -0400, Christian Hackl said:
>>
>>> SG ha scritto:
>>>
>>>> On 25 Aug., 17:22, Christian Hackl wrote:
>>>>> matrix const operator+(matrix const& src) const;
>>>> ^^^^^
>>>> This const is debatable. I never felt the need to return objects by
>>>> const value.
>>> How else do you prevent (a * b) = c?

>>
>> Don't write it. Seriously.

>
> But what if I don't want others (i.e. users of my class) to write it, or
> not to write it by accident?


Accident? Seriously? What, a typo when you intended to write

(a * b) == c

? With matrices? Strongly doubt that. As Pete says, you're spending
time worrying about something that almost never happens.

>> You can spend your time solving non-problems, or you can do real work.

>
> Since when does adding "const" to a function signature waste time that
> could be spent for "real" work?


Any time you do that to the code you inherit (and that doesn't contain
those const qualifiers), you'd not be doing real work, you'd be wasting
everybody's time.

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
SG
Guest
Posts: n/a
 
      08-25-2010
On 25 Aug., 19:46, Pete Becker wrote:
>
> Oh, I see: this is the = instead of == typo. Easily caught by unit
> tests. Still way down on my list.


Since one would want to use it in a boolean context, it won't even
compile unless the type in quetion is also convertible to something
"bool-like". I don't think that the matrix class needs to be
convertible to a "bool-like".

Cheers!
SG
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      08-25-2010
Christian Hackl wrote:

> Victor Bazarov ha scritto:
>
>> On 8/25/2010 12:48 PM, Christian Hackl wrote:
>>> Pete Becker ha scritto:
>>>
>>>> On 2010-08-25 12:31:47 -0400, Christian Hackl said:
>>>>
>>>>> SG ha scritto:
>>>>>
>>>>>> On 25 Aug., 17:22, Christian Hackl wrote:
>>>>>>> matrix const operator+(matrix const& src) const;
>>>>>> ^^^^^
>>>>>> This const is debatable. I never felt the need to return objects by
>>>>>> const value.
>>>>> How else do you prevent (a * b) = c?
>>>> Don't write it. Seriously.
>>> But what if I don't want others (i.e. users of my class) to write it, or
>>> not to write it by accident?

>>
>> Accident? Seriously? What, a typo when you intended to write
>>
>> (a * b) == c

>
> No, I was thinking of typos like when someone intended to write a = (b *
> c).


I don't recall an instant of screwing up that way. Maybe, I was just lucky;
but I have a feeling that this kind of typo might be rather rare.

>> Any time you do that to the code you inherit (and that doesn't contain
>> those const qualifiers), you'd not be doing real work, you'd be wasting
>> everybody's time.

>
> Changing existing files which are used by everyone else on the project
> is a different story. I was more thinking of the case when a class is
> designed and you are writing new code to be added to the project.


Actually, that would depend on the coding guidelines for the project. If
there is established precedence that operators return by value rather than
by const value, I would go with the precedence. After all, users of my
matrix class may try things like

(B*C).swap( A ); // simulating a move to A

to speed up performance in bottlenecks. The point is that coding guidelines
and precedence shape rational expectations, which one might not want to
break within a project.


Best

Kai-Uwe Bux
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      08-25-2010
On 25 aug, 22:52, Christian Hackl <(E-Mail Removed)> wrote:
> Pete Becker ha scritto:
>
> > Oh, I see: this is the = instead of == typo. Easily caught by unit
> > tests.

>
> If it's a library used by someone else, then your own unit tests cannot
> catch the typo.
>
> I'm quite surprised that such a harmless[*] hint, backed by a
> recommendation in of the most recommended C++ books, would cause so much
> discussion on the grounds that it's not important enough
>
>[*] except of the problem with move semantics, which I had not been
> aware of before


Sorry, i do not care really about issue itself, up to designer of
interface and its contract IMO. Just particular detail makes me
wonder... how does it compile? for example:

Matrix a, b, c;
if ( ( a * b ) = c )
{
// blah-blah
}

It should say you cannot convert a Matrix to bool. Or is there some
safe bool? What does it indicate? if ( a ) sounds similarily
nonsensical about Matrix.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      08-25-2010
On 8/25/2010 3:52 PM, Christian Hackl wrote:
> Pete Becker ha scritto:
>
>> Oh, I see: this is the = instead of == typo. Easily caught by unit tests.

>
> If it's a library used by someone else, then your own unit tests cannot
> catch the typo.
>
>
> I'm quite surprised that such a harmless[*] hint, backed by a
> recommendation in of the most recommended C++ books, would cause so much
> discussion on the grounds that it's not important enough
>
>
>[*] except of the problem with move semantics, which I had not been
> aware of before


When I encounter code

SomeType const function(arguments...);

then the first thing that springs into my mind is, "it's a typo and the
implementor forgot to add either * or & before the function name..." It
is idiomatic to see

SomeType function(arguments...);

or

SomeType const& function(arguments...);

The recommendations to write anything different require (in my book
anyway) that the reason better be important. Harmless hint? No, it's a
step away from very common idioms, you see.

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      08-25-2010
On 8/25/2010 4:48 PM, Öö Tiib wrote:
> On 25 aug, 22:52, Christian Hackl<(E-Mail Removed)> wrote:
>> Pete Becker ha scritto:
>>
>>> Oh, I see: this is the = instead of == typo. Easily caught by unit
>>> tests.

>>
>> If it's a library used by someone else, then your own unit tests cannot
>> catch the typo.
>>
>> I'm quite surprised that such a harmless[*] hint, backed by a
>> recommendation in of the most recommended C++ books, would cause so much
>> discussion on the grounds that it's not important enough
>>
>>[*] except of the problem with move semantics, which I had not been
>> aware of before

>
> Sorry, i do not care really about issue itself, up to designer of
> interface and its contract IMO. Just particular detail makes me
> wonder... how does it compile? for example:
>
> Matrix a, b, c;
> if ( ( a * b ) = c )
> {
> // blah-blah
> }
>
> It should say you cannot convert a Matrix to bool. Or is there some
> safe bool? What does it indicate? if ( a ) sounds similarily
> nonsensical about Matrix.


Somebody might design the class that calculates some kind of
characteristic of the matrix to be used in shortcuts like those. I am
not advocating it, but don't dismiss it simply because you're not going
to use it. Correctness of the interface is in the eye of the beholder.
Of course, just like with other things, implicit conversions are
dangerous and better avoided, blah blah... All falls into the style
category, as far as I'm concerned.

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      08-25-2010
On 26 aug, 00:35, Christian Hackl <(E-Mail Removed)> wrote:
> Maybe the influence of Meyers' books on my mind has been too strong, but
> to me, "SomeType operator+(SomeType const &)" is what looks "strange",
> and not the const version. YMMV.



Yeah, matter of taste. For example the one that looks most familiar to
me is:

class SomeType
{
// ...
friend SomeType operator+(const SomeType&, const SomeType&);
// ...
}

That is because i always try to write binary operators (besides =) as
non-member non-friends and if i can't, as friends. why to argue? There
are only very tiny differences.
 
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
Trouble making signal assignments in a procedure Alex Rast VHDL 3 11-24-2004 12:20 PM
Back-Annotate Assignments ALuPin VHDL 1 10-20-2004 09:21 PM
Using aggregates for assignments Gary Thorpe VHDL 4 06-15-2004 03:33 PM
Concurrent assignments to std_ulogic_vector slice is OK with ModelSim Nicolas Matringe VHDL 9 06-14-2004 10:10 PM
using entity attributes for pin number assignments Neil Zanella VHDL 2 10-26-2003 03:22 AM



Advertisments