Re: Patch for stl_vector.h and vector.tcc.

[Dhruv Matani <dhruvbird at gmx dot net>]

On Fri, 2004-02-13 at 23:49, Felix Yen wrote:
> I should mention that I don't think the motive for this development is 
> especially compelling.  Defining an allocator with a method that 
> conflicts with an STL container method seems like a mistake.  
> Furthermore, I suspect that the compiler fails to optimize an empty 
> base with a virtual method.  On my Apple, gcc 3.3 (-O3) respectively 
> produces class sizes 1, 4, 4, and 8 for the following:
> 
> struct empty {int f() {return 0;}};
> struct virtually_empty {virtual int f() {return 0;}};
> struct derived_from_empty : public empty {int baz;};
> struct derived_from_virtually_empty : public virtually_empty {int baz;};

Yes. I agree with you partially. The main objective of this patch was
something like this:

if (Empty_Allocator)
	sizeof(Container) does not increase.
else
	sizeof(Container) has to increase no matter what.

Here, Empty_Allocator means one not having any virtualness and no member
data. malloc_alloc/new_alloc are typical candidates.



> But Nathan's BaseOpt technique doesn't look that painful ...

I saw the link that you sent in your earlier message. In effect, the
current optimization is similar to what's mentioned there, except that
Nathan has given the case for only list, where you may make do with only
one Node (one data member). Other implementations may keep the size
cached too. Also, for vector/deque/rb_tree, there are more than one data
members.






-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/