Michael Marcin wrote:
That's pretty much what I figured. Also I believe the added inline keyword is redundant as a function defined inside of a class declaration is the same as defining inline after the closing semi-colon of the class correct?
Your interpretation is correct, the inline specifier is redundant here.
The copy constructor argument Richard Hadsell mentioned I hadn't even considered and it is a good argument in its own right.
I would like to strengthen Richard's remarks: The newly proposed class violates the "rule of three", because it define's the d'tor, but forget's to implement copy c'tor and copy-assignment op (which is, as Richard already said, a bad idea here). Astonishingly for an expert...
What are the likely results of calling operator delete instead of operator delete[] on an array of builtins allocated with operator new[]? Is it undefined behavior?
It's UB, see 5.3.5/2: "[..]In the first alternative (delete object), the value of the operand of delete shall be a pointer to a non-array object or a pointer to a sub-object (1.8) representing a base class of such an object (clause 10). If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete shall be the pointer value which resulted from a previous array new-expression. If not, the behavior is undefined.[..]" Greetings from Bremen, Daniel Krügler