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." 9 2918
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
"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
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"
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
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
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
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
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
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. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
8 posts
views
Thread by Nitin Bhardwaj |
last post: by
|
5 posts
views
Thread by CoolPint |
last post: by
|
16 posts
views
Thread by Edward Diener |
last post: by
|
9 posts
views
Thread by Matthew Polder |
last post: by
|
1 post
views
Thread by Jon Slaughter |
last post: by
|
6 posts
views
Thread by Neil Zanella |
last post: by
|
11 posts
views
Thread by anongroupaccount |
last post: by
|
5 posts
views
Thread by raylopez99 |
last post: by
|
9 posts
views
Thread by George2 |
last post: by
| | | | | | | | | | |