Re: operator=

• Previous message: Vince Morgan: "Re: operator="
• In reply to: Vince Morgan: "Re: operator="
• Next in thread: Vince Morgan: "Re: operator="
• Reply: Vince Morgan: "Re: operator="
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 01 Mar 2005 08:27:23 GMT

"Vince Morgan" <vinhar@NOSPAMoptusnet.com.au> wrote in message
news:42241c6e$0$5188$afc38c87@news.optusnet.com.au...
> I think I got off to a particularly bad start with this.
>
> Perhaps if I rephrase the question :)
>
> I am trying to get a firm understanding of the interactions
> between copy ctors and 'operator=' assignments.
> Until yesterday I did not know that the compiler
> would\could work with what it had to try and achieve
> an implementation, at least not to this extent.
>

Compiler will supply - unless the programmer decides to do it - the
following:

* Constructor - parameterless [a.k.a. default constructor]
* Copy Constructor
* Assignment Operator
* Destructor

However, in many situations you're better off implementing them yourself
[and in some where you *should* do this], if for no other reason than to
ensure all data members are initialised to known values.

>
> None of this would be of any concerne whatsoever if I
> just threw every conceivable operator overload into
> every class I build. However, I just can't quite make
> myself comfortable with such a method.
>

It is generally recommended that you implement only the functions /
operators that you need: no more, no less :) !

>
> In the decs below I believed (incorrectly) that
> "CAString(const CAString &str)" was 'required' to
> assign from a CAString object.
>

It isn't required in an assignment:

    a = b;

but is used in default initialisation:

    C a = ...;

and here:

    C a(...);

You will find that the code within the copy constructor and assignment
operator is usually quite similar. In some cases 'private' helper member
functions are implemented and are called in both the copy constructor and
assignment operator.

>
> On discovering, to my enormous surprise I might add,
> that if I removed it the compiler found a way to achieve
> what was required by itself I realized there was much
> more about class ctors and overloads than anything
> I've ever read.
>

Yes, default behaviour, whether that of the C++ compiler, or other systems,
can be unexpected, hence unnerving. Learning about such behaviour is part of
the learning curve.

>
> Perhaps I should have known about the interactions
> that were possible, however, I certainly don't. But I
> would like to.
>
> Previous replies seem to indicate that I am universally
> alone in my ignorance so I expect this is well known
> and someone perhaps will be kind enough to point
> me in the direction of some material that I can read :)
>

Sure. For 'just the FAQ's', try:

    http://www.parashift.com/c++-faq-lite/

and for a more comprehensive coverage [a highly reputable online textbook,
no less], try:

    http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html

>
> The way I see it, if I come to understand this my
> future classes can contain code limited to what is
> required. I don't feel comfortable with the notion
> of including unrequired code.
>

Exactly - your classes will contain code you will use, or are fairly
confident will be used.

>
> Also, I need to know what is good practice in this
> regard.
>

<SNIP>

I prepared this code the other day when first reading your post, but never
got around to posting it. Aside from the inlined code [i.e. the member
function code appearing directly within the class definition] it illustrates
fairly standard class design practices [well I *hope* it does :)]. Modify to
suit, perhaps after looking at code in the links I posted.

Don't worry about your progress, you're doing fine. Don't worry about abrupt
responses, just write it off as communication static :) !

I hope this helps.

Anthony Borla

// ------------------------------------------

#include <string>
#include <cstdlib>
#include <iostream>

// Uncomment following line to generate
// user-defined constructors
// #define USE_USER_CONS

// Uncomment following line to generate
// op=(const char* const)
// #define USE_OPEQU_STR

class A
{
public:

#ifdef USE_USER_CONS
  A(const char* const fromStr = "")
    : str_(fromStr)
  {
    std::cout << "A(const char* const) - str_ = "
              << str_ << std::endl;
  }

  A(const A& from)
    : str_(from.str_)
  {
    std::cout << "A(const A&) - str_ = "
              << str_ << std::endl;
  }
#endif

  A& operator=(const A& from)
  {
    std::cout << "[B]op=(const A&) - str_ = "
              << str_ << std::endl;

    if (&from != this)
    {
      str_ = from.str_;
    }

    std::cout << "[A]op=(const A&) - str_ = "
              << str_ << std::endl;

    return *this;
  }

#ifdef USE_OPEQU_STR
  A& operator=(const char* const fromStr)
  {
    std::cout << "[B]op=(const char* const) - str_ = "
              << str_ << std::endl;

    if (fromStr != NULL)
    {
      str_ = fromStr;
    }

    std::cout << "[A]op=(const char* const) - str_ = "
              << str_ << std::endl;

    return *this;
  }
#endif

  void setStr(const char* const fromStr) { str_ = fromStr; }

private:
  std::string str_;
};

// Entry Point
int main()
{
  A a1, a2; a2.setStr("abc");

  a1 = a2;
  a2 = "ABC";

  return EXIT_SUCCESS;
}

• Previous message: Vince Morgan: "Re: operator="
• In reply to: Vince Morgan: "Re: operator="
• Next in thread: Vince Morgan: "Re: operator="
• Reply: Vince Morgan: "Re: operator="
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]