David Daeschler wrote:
Straight out of the docs http://www.boost.org/libs/smart_ptr/scoped_array.htm
Because scoped_array is so simple, in its usual implementation every operation is as fast as a built-in array pointer and it has no more space overhead that a built-in array pointer.
IMHO saying that the change to an array pointer is an "optimization" at all is dubious.
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? I originally wrote that using a scoped_array to document the lifetime, ownership, and type of data pointed to. And so I didn't have to worry about things like forgetting to call delete[] instead of delete. I figured that any compiler worth using should inline this out to the same code as the "optimized" version but I have no proof of that I was hoping someone would have done simple tests comparing generated code that I could reference when I discuss these "improvements" with the team later this week. The copy constructor argument Richard Hadsell mentioned I hadn't even considered and it is a good argument in its own right. 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? Thanks, Michael Marcin