You can make e_ and j_ vectors and save on copy control.

QuoteOriginally posted by: renormHow about this. It should work well for matrices with many more rows than columns.How about views, ranges and slices of this matrix structure? difficult?

How about this? Is it legal?

SSE instructions work with buckets of 4 floats. If you have 11 floats, it is easier and faster to process them as 3 buckets and then discard 12th element, instead of processing them as 2 buckets plus a non-SSE branch for the remaining 3 elements. User code would see vector v as 11 elements big, while SSE subroutine could treat array a as if it has 12 elements .

QuoteOriginally posted by: renormHow about this? Is it legal?would it work? probablyThe vector wouldn't change its memory for a shrink in size so you wouldn't have memory problems. v[11] is equivalent to *(v.begin()+11)24.1.5 "The library never assumes that past-the-end values are dereferenceable."However, you are doing a[11] not v[11] so the issue is solely whether the memory would shrink. A quick look at the standard was not overly clear. There is an implication that as long as the capacity does not increase the memory will not be reallocated so you should be ok.

reading the standard a bit more.An insert is not supposed to cause a reallocation unless the capacity is exceeded, and all iterators that point to before the new end after a resize are supposed to remain valid if it's a shrink.It's difficult to see how this could be achieved without it being safe to use the memory off the end of the vector below the capacity size.

Very good point regarding iterators.I took a look at STLs on my PC. Both Visual C++ and MinGW use SGI STL implementation. I presume the same is true for GCC and many other implementations. SGI vector never shrinks its capacity on its own.

POD has no destructors. "the swap trick" can remove the hidden tail. But as mj pointed out, shrinking resize can't remove excess capacity without invalidating iterators.

Anyone for Pool?

outrun,v.begin() will change as soon as the vector is relocated. Therefore shrinking resize won't relocate vector's storage.Cuchulainn,Many boost docs lack a proper tutorial. Pool is one of them. Does your books covers it?