Assignment Operator in ABC

[Rick N. Backer]

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?

Thanks in advance.

Ken Wilson

Amer. Dlx. Tele, Gary Moore LP, LP Faded DC,
Jeff Beck Strat, Morgan OM Acoustic,
Rick 360/12, Std. Strat (MIM), Mesa 100 Nomad,
Mesa F-30

"Goodnight Austin, Texas, wherever you are."

[Leor Zolman]

On Tue, 25 May 2004 00:44:12 GMT, Rick N. Backer <ke********@NsOhSaPw.cAaM>
wrote:

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?
That rather depends on whether or not you wish to allow assignment of
objects of concrete subclasses or not. An assignment operator is never
"necessary" if you don't wish to support assignment.

If you /do/ wish to support assignment of the derived class objects, and
you don't write an assignment operator for the ABC, then just as would be
the case for any base class, the compiler will generate one that does a
shallow copy (it will literally copy your pointer values). That's probably
not what you want if those values represent dynamically allocated memory
and you're not doing any fancy reference counting on them.

IOW, the fact your BC is A doesn't keep the basic Rule of Three from
applying.
-leor

Thanks in advance.

Ken Wilson

Amer. Dlx. Tele, Gary Moore LP, LP Faded DC,
Jeff Beck Strat, Morgan OM Acoustic,
Rick 360/12, Std. Strat (MIM), Mesa 100 Nomad,
Mesa F-30

"Goodnight Austin, Texas, wherever you are."

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Victor Bazarov]

"Rick N. Backer" <ke********@NsOhSaPw.cAaM> wrote...

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?

Not enough information. Read up on "Rule of Three".

Victor

[Rick N. Backer]

On Mon, 24 May 2004 21:41:33 -0400, Leor Zolman <le**@bdsoft.com> did
courageously avow:

On Tue, 25 May 2004 00:44:12 GMT, Rick N. Backer <ke********@NsOhSaPw.cAaM>
wrote:

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?
That rather depends on whether or not you wish to allow assignment of
objects of concrete subclasses or not. An assignment operator is never
"necessary" if you don't wish to support assignment.

If you /do/ wish to support assignment of the derived class objects, and
you don't write an assignment operator for the ABC, then just as would be
the case for any base class, the compiler will generate one that does a
shallow copy (it will literally copy your pointer values). That's probably
not what you want if those values represent dynamically allocated memory
and you're not doing any fancy reference counting on them.

Thank you for your input. I have added the assignment operator. I
needed the deep copying. Should I be declaring it as a virtual
function?

IOW, the fact your BC is A doesn't keep the basic Rule of Three from
applying.
I've visited the C++ FAQ-Lite and cannot find a reference to the Rule
of Three. Am I safe in assuming you are referring to the three
functions that don't get inherited, constructor, destructor and
assignment? Or are you referring to even more arcane wizardry? :-) -leor

Ken Wilson
"Just because people don't understand you doesn't mean
you are an artist"

[tom_usenet]

On Tue, 25 May 2004 00:44:12 GMT, Rick N. Backer
<ke********@NsOhSaPw.cAaM> wrote:

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?

It probably is necessary. Generally, ABCs should be declared
non-copyable. e.g.

//either
class MyABC: boost::noncopyable
{
//...
};

//or
class MyABC: boost::noncopyable
{
//...
private:
MyABC(MyABC const& rhs); //no impl
MyABC& operator=(MyABC const& rhs); //no impl
};

Alternatively, if you do want to be able to copy them, you might want
to add a virtual clone method. Something like:

class MyABC: boost::noncopyable
{
//...
public:
virtual MyABC* clone() const;

protected: //could be public if you don't mind accidently misuse
MyABC(MyABC const& rhs); //add impl, prevent slicing?
private:
MyABC& operator=(MyABC const& rhs); //no impl
};

Now derived classes can implement it by using their protected copy
constructors.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Leor Zolman]

On Tue, 25 May 2004 05:29:58 GMT, Rick N. Backer <ke********@NsOhSaPw.cAaM>
wrote:

On Mon, 24 May 2004 21:41:33 -0400, Leor Zolman <le**@bdsoft.com> did
courageously avow:

On Tue, 25 May 2004 00:44:12 GMT, Rick N. Backer <ke********@NsOhSaPw.cAaM>
wrote:

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?
That rather depends on whether or not you wish to allow assignment of
objects of concrete subclasses or not. An assignment operator is never
"necessary" if you don't wish to support assignment.

If you /do/ wish to support assignment of the derived class objects, and
you don't write an assignment operator for the ABC, then just as would be
the case for any base class, the compiler will generate one that does a
shallow copy (it will literally copy your pointer values). That's probably
not what you want if those values represent dynamically allocated memory
and you're not doing any fancy reference counting on them.

Thank you for your input. I have added the assignment operator. I
needed the deep copying. Should I be declaring it as a virtual
function?

See
http://pcroot.cern.ch/TaligentDocs/T...WM/WM_136.html

Usually, operator= is not declared virtual, and, if necessary, operator= in
a derived class directly calls operator= of the base class to do the base
class part of the job. Thus assignment operators end up "chained", the same
way constructor and destructors do it automatically, but in the case of
assignment operators, the chaining has to be performed manually.

I still consider it rather counterintuitive that /generated/ derived class
assignment operators automatically chain to their base class counterparts,
but /explicitly/ defined ones do not. In fact, I've written to Bjarne and
requested that he make that fact more evident in TC++PL. I guess we'll have
to wait and see what happens in the 4th edition...
-leor

IOW, the fact your BC is A doesn't keep the basic Rule of Three from
applying.

I've visited the C++ FAQ-Lite and cannot find a reference to the Rule
of Three. Am I safe in assuming you are referring to the three
functions that don't get inherited, constructor, destructor and
assignment? Or are you referring to even more arcane wizardry? :-)

"Any class requiring a destructor, copy constructor, or an assignment
operator must have all three implemented."

The idea being, for example, that if there are raw pointers involved, it
is difficult to imagine that they'd need special treatment in only some of
those three functions.

[http://c2.com/cgi/wiki?RuleOfThree, and scroll down past Alice's
Restaurant ;-) ]
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Thomas Matthews]

Rick N. Backer wrote:

On Mon, 24 May 2004 21:41:33 -0400, Leor Zolman <le**@bdsoft.com> did
courageously avow:

On Tue, 25 May 2004 00:44:12 GMT, Rick N. Backer <ke********@NsOhSaPw.cAaM>
wrote:

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?

That rather depends on whether or not you wish to allow assignment of
objects of concrete subclasses or not. An assignment operator is never
"necessary" if you don't wish to support assignment.

If you /do/ wish to support assignment of the derived class objects, and
you don't write an assignment operator for the ABC, then just as would be
the case for any base class, the compiler will generate one that does a
shallow copy (it will literally copy your pointer values). That's probably
not what you want if those values represent dynamically allocated memory
and you're not doing any fancy reference counting on them.

Thank you for your input. I have added the assignment operator. I
needed the deep copying. Should I be declaring it as a virtual
function?

From experience, I make the assignment operator in base classes as
private. This prevents slicing or deep copying of one descendant
type to another descendent type.

Deep copying should be performed by the leaf descendant. That
descendant should execute the parent's assignment operator. The
parent should execute the grandparent assignment operator and so on.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Victor Bazarov]

Thomas Matthews wrote:

Rick N. Backer wrote:

[...]
Thank you for your input. I have added the assignment operator. I
needed the deep copying. Should I be declaring it as a virtual
function?

From experience, I make the assignment operator in base classes as
private. This prevents slicing or deep copying of one descendant
type to another descendent type.

Deep copying should be performed by the leaf descendant. That
descendant should execute the parent's assignment operator. The
parent should execute the grandparent assignment operator and so on.

If the base class assignment operator is declared private, how do you
accomplish the execution of the assignment up the hierarchy?

V

[Thomas Matthews]

Victor Bazarov wrote:

Thomas Matthews wrote:

Rick N. Backer wrote:

[...]
Thank you for your input. I have added the assignment operator. I
needed the deep copying. Should I be declaring it as a virtual
function?

From experience, I make the assignment operator in base classes as
private. This prevents slicing or deep copying of one descendant
type to another descendent type.

Deep copying should be performed by the leaf descendant. That
descendant should execute the parent's assignment operator. The
parent should execute the grandparent assignment operator and so on.

If the base class assignment operator is declared private, how do you
accomplish the execution of the assignment up the hierarchy?

V

Sorry, but that is a typo. Should be protected.
Thanks for catching it.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Daniel T.]

Rick N. Backer <ke********@NsOhSaPw.cAaM> wrote:

I have an abstract base class that has char* members. Is an
assignment operator necessary for this abstract base class? Why or
why not?

I would say no, ABC's should not have assignment operators under any
circumstance I can think of.

Assignment operator is for code to reset one object using data found in
another:

void foo( A& a, const A& b ) {
a = b;
}

To me, this doesn't make much sense for an abstract class.

Some have suggested creating the assignment operator but making it
protected so that the above code wouldn't work, however the derived
classes are required to call the base class assignment op explicitly,
and frankly, I don't know how to do that... It would be easier if the
method was a normal member-function rather than an operator...

class ABC {
protected:
void copyFrom( const ABC& ref );
};

class Derived: public ABC {
public:
Derived& operator=(const Derived& ref ) {
copyFrom( ref );
// do the rest
}
};

Then there is the question of wether it should be virtual. In any case,
it doesn't make sense IMO to make it virtual unless it is public and all
derived class objects can reasonably be able to reset themselves
completely based only on the information enclosed in the ABC.