Overloading assignment operator in a class with inheritance?

[osfreak]

class base
{
public:
	
	
	base(int data = 0):a(data)
	{}
	base(const base& rhs)
	{
		a = rhs.a;
	}
	base& operator = (const base& rhs)
	{
			a = rhs.a;
		return *this;
	}

private:
	int a;
};

class derived:public base
{

public:
	int b;
	derived(int data =0):b(data),base(data)
	{}
	derived(const derived& rhs):base(rhs)
	{
		b = rhs.b;
	}
	derived& operator = (const derived& rhs)
	{
		this->base::operator=(rhs);
		b = rhs.b;
		return *this;
	}
};
int main()
{

derived der1(1),der2(2),der3(3);

der1 = der2 = der3;
}

Is this implementation right?
or Even if it is right, Is there a better way of doing it?
Pls advice

[Banfa]

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.

[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:

  (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.

[Banfa]

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.

[Oralloy]

@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?

[Banfa]

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.

[Oralloy]

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*

[Banfa]

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::exce ption&) it is just treated as throw(...).

[Oralloy]

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!

[osfreak]

@ 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(Nev er thought of it)
(a = b) = c;

@Banfa
Ya i do have to check for self assignment

Both of you, Thanks for the quick reply