Patch for stl_vector.h and vector.tcc.

[Felix Yen]

 >  Yes. I agree with you partially. The main objective of this patch 
was [...]

In that case, maybe we agree completely.

My point is that the released implementations of the STL containers are 
quite clean with respect to allocator parameter usage, and that there 
are mitigating factors that reduce the defect's priority thereby 
justifying the search for a solution that addresses all the container 
implementations in spite of the complications you described.  In other 
words, preventing interference between the allocator and the container 
while enabling EBO should be viewed as one problem, not as a set of 
container implementation-specific ones, and the ideal solution reuses 
code.  (The distinction between container type and container 
implementation is important, because it lets us ignore the differences 
between map, set, multimap, and multiset, while confronting us with the 
partial specialization of vector<bool>.)

This defect is not a regression, and the only allocator known to expose 
it is the one you created for this purpose, so this doesn't feel like a 
situation that demands immediate action.  (It's ironic that we're 
obsessed with EBO, but the motivating example uses an allocator that 
does not benefit from this optimization.  How does one justify giving 
an allocator a virtual method?)  On the other hand, you've gotten me to 
think about the problem long enough so that I might be compelled to 
test some of my ideas.  It's an interesting puzzle that begs for a 
template-based solution.  If I reread one of Matt's messages, maybe ...


Felix