1 hour ago, alvaro said:

 

You don't need to inherit to share functionality. Composition will be better in the vast majority of situations. So both VertexBuffer and ConstantBuffer can have a member of type Buffer (or MemoryBuffer, or RawBuffer... Using good names is important) and share functionality that way.

 

Note that private inheritance is one implementation of composition

30 minutes ago, alvaro said:

Yes, it's the one with the confusing syntax.

And the confusing defaults. Why use public always as default for struct and use private always as default for class? This makes no sense for inheritance. But on the other hand if the syntax is not explicit, one asks for trouble sooner or later.

5 hours ago, matt77hias said:

Shoudn't the argument be a reference for a general copy assignment operator?

No.  Trace through the operation of the code I wrote.  See how the copy constructor is used to implement the assignment operator?  Now, isn't it elegant?

10 minutes ago, Bregma said:

No.  Trace through the operation of the code I wrote.  See how the copy constructor is used to implement the assignment operator?  Now, isn't it elegant?

Ok I get it. Elegant: yes.

But come on, you need to look at this few lines of code twice imho to get what is happening.

Someone of your team sees your signature. Adds the "missing" reference. And then it all depends on you "swp" signature, how things would go...

18 hours ago, matt77hias said:

Ok I get it. Elegant: yes.

But come on, you need to look at this few lines of code twice imho to get what is happening.

Someone of your team sees your signature. Adds the "missing" reference. And then it all depends on you "swp" signature, how things would go...

I do not work with bottom-grade programmers who would alter functionality without understanding it first. 

If you absolutely must blindly follow rigid ideology and make the argument to your copy assignment operator a reference, the code would look like this.

VertexBuffer& VertexBuffer::operator=(VertexBuffer const& other)
{
	VertexBuffer tmp(other);
	this->swap(tmp);
	return *this;
}

Interestingly, modern compilers will pessimize that alternative code because they can not take advantage of copy elision like they can with pass-by-value parameters.  Your coworker's blind obedience to cargo-cult pass-by-const-reference just cost a thousand CPU cycles.  Consider giving them an opportunity to pursue a more satisfying role as a node.js front-end developer where they can cause less harm.

One of the big advantages of the copy-and-swap idiom is that it provides the strong exception safety guarantee, whereas the original code did not (again, trace it through).  You might argue against the use of exceptions in C++ (after all, we're already speaking of a level of mindless reverence at play in your place of work) but writing the most robust code as possible is usually a win in the long run.  Sure, in this trivial example you're unlikely to see an exception, but not all code is so trivial and the copy-and-swap idiom will always apply.

As for adding a self-check, consider the cost of adding and maintaining an equality operator (and corresponding inequality operator) and the cost of calling it every time and compare that to how ofter you write code that performs self-assignment.  I know I very very rarely write code that assigns an object to itself, but code that is never written costs less and is guaranteed bug-free.  Always spending extra CPU cycles and increasing the risk in code to make a single highly unlikely edge-case more efficient seems like a lose-lose tradeoff to me.

Really, other than deleting the copy assignment operator entirely or adding debug printfs, why would you ever use anything other than the two-line copy-and-swap I wrote above for all your classes?

15 minutes ago, Bregma said:

Really, other than deleting the copy assignment operator entirely or adding debug printfs, why would you ever use anything other than the two-line copy-and-swap I wrote above for all your classes?

I use for 95% of the cases:

VertexBuffer &VertexBuffer::operator=(const VertexBuffer &buffer) = delete;

and for 4.99% of the cases:

VertexBuffer &VertexBuffer::operator=(const VertexBuffer &buffer) = default;