try to stump me on C++

Quote:

---

Originally Posted by Mitsukai

so was i

Code:

---

MyClass& MyClass::operator=(MyClass temp)
{
  Swap(temp);
  return *this;
}

---

---

Then I don't understand your objections.

its bad design...

cause your constructing a whole object on the stack and then wasting another cpu cycles with the swap method... while all u have todo is call a common private function.

I don't see the swap function as a significant waste. Creating the temp on the stack and swapping the internal pointers is almost the same expense as using temporary pointers in the assignment operator function.

How would you write a typical assignment operator then?

Quote:

---

Originally Posted by Zaccheus

I don't see the swap function as a significant waste. Creating the temp on the stack and swapping the internal pointers is almost the same expense as using temporary pointers in the assignment operator function.

---

first, do you have proof that this is actually true. cause an object is alot heavier than a temp pointer.

and did i mention yet in allocators this breaks the reservation of memory?

Quote:

---

Originally Posted by Mitsukai

its bad design...

cause your constructing a whole object on the stack and then wasting another cpu cycles with the swap method... while all u have todo is call a common private function.

---

No that (Zaccheus post) is a very good design, and the one most recommended for high reliability situations.

The only time to avoid it is if you havwe measured performance and determined that the small differential cost has a significant impact on your documented performance requirements.

No matter where an exception occurs you can never have a corrupted or partial object. Either the assignment will complete 100% or the state of the (externally visible) object will not be impacted. This is guaranteed by design.

Even if you manage to write a "typical" assignment operator that is 100% exception safe, then you still have to develop tests to prove this (and maintain both the code and the tests for the entire lifecycle of the project).

Testing and proving exception safety (in the general case...) is a notoriously hard (and unbelievably tedious) thing to do.

i agree with most of your points but i still stand by my point, and it will probally never change unless i get paid. I still think it as a bad work around. But thats just my point of view.

I would really like to see an exception safe operator= which is a lot faster than the one I showed.

Quote:

---

Originally Posted by Mitsukai

first, do you have proof that this is actually true. cause an object is alot heavier than a temp pointer.

---

I think it is self evident that an object it is NOT a lot heavier than its individual data members.

Quote:

---

Originally Posted by Mitsukai

and did i mention yet in allocators this breaks the reservation of memory?

---

How, exactly?

Quote:

---

Originally Posted by Zaccheus

I think it is self evident that it is NOT a lot heavier than equivalent temp pointers.

---

Prove it to me? and what makes you say that this "lil" bit is not alot on 1watt laptop processors? who are you to say this "lil" overhead is actually not alot?

Quote:

---

Originally Posted by Zaccheus

How, exactly?

---

cause the whole point of it is to "Adept" to the usage of the class, the more is added the more memory it will reserve. If you create a complete new object all this reserved memory is gone. Also the whole point of the memory reservation is to prevent it from allocating memory every time it needs more space. And then when adding again which is must likely to happen in large applications it has to allocate again all that space. This is for containers ofcourse.

Quote:

---

Originally Posted by Zaccheus

I think it is self evident that an object it is NOT a lot heavier than its individual data members.

---

one ptr on the stack vs a whole object? there is no need to have tmp vars at all in most cases, so if the obj has 10 var members its even more clear waste of stack and cpu

Please show me the assignment operator implementation you prefer and then we can compare. :)

Quote:

---

Originally Posted by Mitsukai

one ptr on the stack vs a whole object? there is no need to have tmp vars at all in most cases, so if the obj has 10 var members its even more clear waste of stack and cpu

---

Actually adjusting the stack pointer by <32K (signed 16 bit offset) takes FEWER clock cycles than pushing one 32 bit value. So that part of your post is WRONG.

Unless the copy constructor is invoked in the call stack of the maximum stack depth your program ever achieves, then does not waste a single byte of memory. This maximum stack depth will (typically) occur at exactly one point in your program, and if you are working on small systems (embedded, tiny mobile, etc), then you should know exactly where and when this is.

The pre-allocation your are talking about is spefically for the freestore (used with new/delete), this is because there is management overhead of finding the "best" free block, and for collapsing free blocks at the time of delete. It has nothing to do with stack variables.

Here's a concrete example:

Code:

---

#include <cstring>
#include <algorithm>

class Buffer
{
    unsigned char*    data;
    size_t            length;

public:

    Buffer(const unsigned char* buf, size_t len)
    :        data(new unsigned char[len]),
        length(len)
    {
        std::memcpy(data, buf, length);
    }

    Buffer(const Buffer& other)
    :        data(new unsigned char[other.length]),
        length(other.length)
    {
        std::memcpy(data, other.data, other.length);
    }

    ~Buffer()
    {
        delete [] data;
    }

    Buffer& operator=(const Buffer& other)
    {
        Buffer temp(other);
        swap(temp);

        return *this; 
    }

    void swap(Buffer& other)
    {
        std::swap(data, other.data);
        std::swap(length, other.length);
    }
};

---

Quote:

---

Originally Posted by andersod2

Ok without cheating....basically you never want to modify the "this" pointer, expecially this way.

---

Who is modifying the "this" pointer? Modifying this pointer is a compilation error and the code above doesn't do that.

Quote:

---

Originally Posted by andersod2

In fact, this could be an example of the worst case scenario use of *this.

---

Meaningless. As for use of the dereferencing of the this pointer, it is perfectly valid.

Quote:

---

Originally Posted by andersod2

It is usurping the allocation of the class (major memory leak).

---

I don't see a leak forget about it being a major one.

Quote:

---

Originally Posted by andersod2

It's also potentially wreaking havoc with the "new"-ing of this class, potentially forcing some kind of access violation.

---

No new-ing, and no access violation. What are you talking about?

Quote:

---

Originally Posted by andersod2

Lot's of negative implications with modifying *this, and should almost never be done.

---

What? What negative implications? You can modify the object pointed to by the this pointer. Why should it almost never be done?

Quote:

---

Originally Posted by andersod2

Alternatively, to properly copy an instance of a class, do a member-wise copy in your copy constructor,

---

As I see it, I do see a member-wise copy even though the code is not an example of *real* code (in practice). What are you talking about?

Quote:

---

Originally Posted by andersod2

or simply leave out the copy constructor and the operator= overload and the default behavior will be do implement those functions behind the scenes.

---

To come to a conclusion on that, one needs to know what those (...) stand for in the original snippet. So, a counter-question for clarifications from my side. Should avoid reaching conclusions so early.

Quote:

---

Originally Posted by andersod2

Or, if it really was one's intention to simply create a second pointer to the same exact memory space, one can just declare a pointer to that class (or it's parent if applicable), and set the pointer to the first instance's address....

---

What? I cannot make out a single sensible meaning out of this.

Quote:

---

Originally Posted by andersod2

That was a good question...hope I got it right...

---

Horrible, if you frankly ask me. But there's always hope. :)

Quote:

---

Originally Posted by Duoas

@andersod2
You did, and very comprehensively too. :-)

---

Yeah, right. :) It is a bit unfortunate that you say that after seeing that the question came from you.

Quote:

---

Originally Posted by Zaccheus

My answer to Duoas' question would have been that operator= should be implemented via the copy constructor, not the other way around. Using operator= in the copy constructor is either wasteful or downright catastrophic.

---

Yes. Fully agree. Writing exception safe assignment operators is one advantage you get that way. But I think it is not catastrophic even though there's not enough code to come to a conclusion but it would not be very hard to imagine that the code works except that there's a difference of initialization vs assignment as suggested by Hermit somewhere above I think. Apart from that, I don't see a problem.

Quote:

---

Originally Posted by Zaccheus

Because the operator= will assume that the class is already fully constructed, it might try to delete a data member pointer which has not yet been initialised.

---

That would be the problem with the "other" constructors which left uninitialized pointers. (EDIT: Sorry, on a second thought, yes, it can be a problem).

Quote:

---

Originally Posted by Zaccheus

And if operator= has correctly been implemented using the copy constructor, an infinite recursion would very quickly crash the application.

---

In that case, a simple advice would be "don't work for such a firm whose developers don't know how to write copy constructors and assignment operators". :)