Jump to content

  • Log In with Google      Sign In   
  • Create Account


sizeof() giving strange results...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
28 replies to this topic

#21 Ectara   Crossbones+   -  Reputation: 2915

Like
1Likes
Like

Posted 23 January 2013 - 01:07 AM

Shouldn't it be:


It's rather trivial in this case; nothing will be harmed by assigning three floats to themselves. Past attempting to maintain the invariants of the class, there is little other reason to check to see if you are assigning to yourself for a class that contains nothing but primitive types.

http://www.parashift.com/c++-faq/self-assignment-how.html

 

If you don't need to explicitly test for self-assignment, for example, if your code works correctly (even if slowly) in the case of self-assignment, then do not put an if test in your assignment operator just to make the self-assignment case fast. The reason is simple: self-assignment is almost always rare, so it merely needs to be correct - it does not need to be efficient. Adding the unnecessary if statement would make a rare case faster by adding an extra conditional-branch to the normal case, punishing the many to benefit the few.

In other words, don't stick one in just to do it. Do it for a provable reason that isn't speed.



Sponsor:

#22 pinebanana   Members   -  Reputation: 475

Like
1Likes
Like

Posted 23 January 2013 - 02:28 AM

Shouldn't it be:


It's rather trivial in this case; nothing will be harmed by assigning three floats to themselves. Past attempting to maintain the invariants of the class, there is little other reason to check to see if you are assigning to yourself for a class that contains nothing but primitive types.

http://www.parashift.com/c++-faq/self-assignment-how.html

 

 

If you don't need to explicitly test for self-assignment, for example, if your code works correctly (even if slowly) in the case of self-assignment, then do not put an if test in your assignment operator just to make the self-assignment case fast. The reason is simple: self-assignment is almost always rare, so it merely needs to be correct - it does not need to be efficient. Adding the unnecessary if statement would make a rare case faster by adding an extra conditional-branch to the normal case, punishing the many to benefit the few.

In other words, don't stick one in just to do it. Do it for a provable reason that isn't speed.

 

Ah, my bad.


anax - An open source C++ entity system


#23 Ectara   Crossbones+   -  Reputation: 2915

Like
0Likes
Like

Posted 23 January 2013 - 02:29 AM

Ah, my bad.


No harm done.



#24 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 23 January 2013 - 04:21 AM

No, it shouldn't be. Self assignment is harmless in this case and it's quicker not to do the branch.

#25 Matias Goldberg   Crossbones+   -  Reputation: 3137

Like
0Likes
Like

Posted 23 January 2013 - 11:39 AM

Btw, since equality operator in a Vector3 class is highly likely to be used frequently, you should seriously consider inlining it back. Just make sure it's available all translation units. You can define it in the header, or to make the code more tidy and clean, define it in an "inl" file and include it in the Vector3 header.



#26 Álvaro   Crossbones+   -  Reputation: 12916

Like
0Likes
Like

Posted 23 January 2013 - 12:07 PM

Btw, since equality operator in a Vector3 class is highly likely to be used frequently, you should seriously consider inlining it back. Just make sure it's available all translation units. You can define it in the header, or to make the code more tidy and clean, define it in an "inl" file and include it in the Vector3 header.

While that advice is generally correct, I want to point out that recent compilers can use link-time optimization and inline the function anyway.

#27 Tasche   Members   -  Reputation: 222

Like
0Likes
Like

Posted 23 January 2013 - 03:27 PM

okeys, just to let you guys know, i read everything and learned more then i asked for.

thanks for all the insight, it really helps once you go back to optimizing just having heard about this stuff and spending a thought on this or two.

but for now, i am just happy it works now as expected, and i know what went wrong. never hurts to keep conventions though =)



#28 iMalc   Crossbones+   -  Reputation: 2299

Like
2Likes
Like

Posted 24 January 2013 - 07:10 PM

No. The proper implementation of operator = for a class where all members already know how to copy themselves is:
// This code block intentionally left empty
That's right. Make some use of your delete key! Don't implement what the compiler can already correctly do for you.

Edited by iMalc, 24 January 2013 - 07:11 PM.

"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

#29 SiCrane   Moderators   -  Reputation: 9550

Like
2Likes
Like

Posted 24 January 2013 - 07:57 PM

There's also the = default option if using a C++11 compiler that supports it.
MyClass & operator=(const MyClass &) = default;





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS