By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,948 Members | 663 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,948 IT Pros & Developers. It's quick & easy.

Overloading assignment operator in a class with inheritance?

osfreak
P: 22
Expand|Select|Wrap|Line Numbers
  1.  
  2. class base
  3. {
  4. public:
  5.  
  6.  
  7.     base(int data = 0):a(data)
  8.     {}
  9.     base(const base& rhs)
  10.     {
  11.         a = rhs.a;
  12.     }
  13.     base& operator = (const base& rhs)
  14.     {
  15.             a = rhs.a;
  16.         return *this;
  17.     }
  18.  
  19. private:
  20.     int a;
  21. };
  22.  
  23. class derived:public base
  24. {
  25.  
  26. public:
  27.     int b;
  28.     derived(int data =0):b(data),base(data)
  29.     {}
  30.     derived(const derived& rhs):base(rhs)
  31.     {
  32.         b = rhs.b;
  33.     }
  34.     derived& operator = (const derived& rhs)
  35.     {
  36.         this->base::operator=(rhs);
  37.         b = rhs.b;
  38.         return *this;
  39.     }
  40. };
  41. int main()
  42. {
  43.  
  44. derived der1(1),der2(2),der3(3);
  45.  
  46. der1 = der2 = der3;
  47. }
  48.  
  49.  
Is this implementation right?
or Even if it is right, Is there a better way of doing it?
Pls advice
Sep 29 '10 #1

✓ answered by Oralloy

My only comments would be:

In your derrived class constructor, you initialize the attribute b before you initialize the base class. That might be problematic in some instanaces.

Your assignment operators should probably return const objects, otherwise someone might be tempted to write the pathological statement:
Expand|Select|Wrap|Line Numbers
  1.   (a = b) = c;
Which, while I might think it funny and a lovely way of obfuscating the code, is probably not a good thing to visit on maintenence programmers.

Lastly, the keyword inline exists for a reason. I realize that in some cases it might not be appropriate; however, in this case it's probably the right thing. Especially, if you plan to hoist your classes into header files.

Share this Question
Share on Google+
9 Replies


Banfa
Expert Mod 5K+
P: 8,916
Looks about right, you may want to protect against an object copying from itself with if (this != &rhs) round the code that actually does the copy.
Sep 29 '10 #2

Oralloy
Expert 100+
P: 983
My only comments would be:

In your derrived class constructor, you initialize the attribute b before you initialize the base class. That might be problematic in some instanaces.

Your assignment operators should probably return const objects, otherwise someone might be tempted to write the pathological statement:
Expand|Select|Wrap|Line Numbers
  1.   (a = b) = c;
Which, while I might think it funny and a lovely way of obfuscating the code, is probably not a good thing to visit on maintenence programmers.

Lastly, the keyword inline exists for a reason. I realize that in some cases it might not be appropriate; however, in this case it's probably the right thing. Especially, if you plan to hoist your classes into header files.
Sep 29 '10 #3

Banfa
Expert Mod 5K+
P: 8,916
In your derrived class constructor, you initialize the attribute b before you initialize the base class. That might be problematic in some instanaces.
The order of initialisation does not depend on the order of the initialisation list but rather then order things appear in the header. What will happen is if you run code like this through a program like Lint you will get a warning that the initialisation order is not the order that initialisers are written in. The initialisation order is fixed and base classes get initialised first.


Lastly, the keyword inline exists for a reason. I realize that in some cases it might not be appropriate; however, in this case it's probably the right thing. Especially, if you plan to hoist your classes into header files.
You don't need the inline keyword on functions defined inside the class definition, they are automatically inlined.

inline is useful of functions defined inside a header by outside a class definition.

A note on this, I have seen it said that a good practice is actually not to define functions in the class definition anyway, if you want the function definition in the header to inline it then put it after the class definition. The keeps the class definition clean and easy to read.
Sep 29 '10 #4

Oralloy
Expert 100+
P: 983
@Banfa,

It's interesting that the spec states initialization order. I had some troubles with that years ago, so I've been careful about sequence since. Live and learn. :)

As for inlining style. I agree with you that for non-trivial classes and methods, inline code should usually be carried in the header after the class definition. Otherwise, it's mater of readability and complexity.

As for implicit inlining, I know that the older C++ compilers didn't inline well, rather they created all kinds of out-of-line-inline-methods and such. The latest GNU compilers seem to be beyond such nonsense, but has Microsoft managed to achieve such a thing?
Sep 29 '10 #5

Banfa
Expert Mod 5K+
P: 8,916
I've had some issues with complex templates an the MS compiler and by their own admission they do not fully support exception specifications but I think they are more or less up to scratch on the rest of it.
Sep 30 '10 #6

Oralloy
Expert 100+
P: 983
What part of exceptions is uSoft having difficulty with?

I'd have thought that they'd have exception handling well worked out by now.

Oh well..... *sigh*
Sep 30 '10 #7

Banfa
Expert Mod 5K+
P: 8,916
No exceptions work but the exception specifications on methods/functions aren't fully implemented. The only support throw() no exceptions and throw(...) any exception. If you actually put one or more types in the exception specification e.g. throw(std::exception&) it is just treated as throw(...).
Sep 30 '10 #8

Oralloy
Expert 100+
P: 983
Ick.

Now that I didn't realize. I can see why its a low-priority problem from the usoft perspective.

Still, how rough can it be to resolve that one?

Thanks!
Sep 30 '10 #9

osfreak
P: 22
@ Oralloy

Studio 2008 took care of initializing base class first.Though its a good practice to make the list by order.

Returning a const does make it safer for preventing crazy assignments(Never thought of it)
(a = b) = c;

@Banfa
Ya i do have to check for self assignment

Both of you, Thanks for the quick reply
Sep 30 '10 #10

Post your reply

Sign in to post your reply or Sign up for a free account.