On Mon, Mar 2, 2009 at 10:29 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
Alternatively we might try to compute a reasoable default size based on the size of the type and based on minimum and maximum default sizes.
Agreed. Especially in terms of providing a meaningful default, the amount of bytes being used up on the stack is much more of a concern than the number of individual objects on the stack. In retrospect, it might even make sense for the template parameter to be in bytes rather than object count. Concerning your implementation there is at least one major issue I have -- your use of "optimized_const_reference." You define optimized_const_reference to be a const value_type if the value_type has a trivial assignment operation. You then return this from const accessors such as front, back, and operator []. While it first this might seem like a clever trick, it is flawed in several subtle ways. Firstly, it is not necessarily optimized because the object may be considerably large, implying you'd be making a copy of a large object simply by calling operator [], but aside from that there are much more important reasons why you should avoid this. Unless I am mistaken, it makes your container not a valid STL container, although it already has an O(n) swap which is unavoidable. But the main reason why I consider this a fault is that it now means that if you store a pointer/reference to an element in the array taken from a non-const accessor it will not reference the same object as what is returned from a const accessor which can cause obvious subtle issues (and it means you cannot get a pointer to an element in the array when all you have is a const reference to the container unless you use "data")! It also means that you cannot directly take the address of the values returned from your const accessor functions in cases where the type contained has a trivial assignment operation since you can't directly take the address of a temporary. All of this is avoided by simply returning a const_reference to the contained object, and it makes the behavior for your template consistent between different instantiations, not to mention with containers in the STL. While the optimized_const_reference trick is clever, I do not believe it is appropriate here. -- -Matt Calabrese