I'm not sure if the compiler would either, but if it can then I would.
Originally Posted by Elysia
Code reuse is a noble goal, but copy-construction deserves to be a special case. It doesn't have to deal with any of the compexities that arrise in the other situations. Just as your copy-assignment is done as a special case, I hope you'd reconsider using the far simpler special case code for copy-construction. There's a point at which it's better to write special case code instead of continually building upon reuse upon reuse, and I'd say this is definitely it.
Well, I was pursuing a re-use code design, so it forwards call deeper into the class as a result.
I guess, but it's an easy algorithm to make sure I have enough space for the buffer and add some more so we don't reallocate all the time.
Reusing code and well... the destructor is supposed to delete/get rid of the buffer, so calling that would take care of that. Save duplicating code was my motive.
Something should really be implemented in terms of other things that are logically less work, not things that are more work. That means not implementing = in terms of +=, since += is logically more work. Otherwise you'd find that users of this class that thought they were optimising their code would wonder why it got slower. If it was changed around to be the other way then it should be about the same amount of code.
Basically, code reuse. Truncate the current buffer and then call += which does the real job. And since there's no data, it appends to the start.
Yeah that's it.
In other words, just call specialized templates to do the actual code instead of acquiring a function pointer?
So does the ATL one.
Yeah, I remembered MFC did the same and figured it would be better to make sure there was appropriate space so that I didn't have to reallocate each time I had to copy.