On Fri, Nov 22, 2013 at 6:49 AM, Trevor Saunders <tsaund...@mozilla.com> wrote: > On Tue, Nov 19, 2013 at 01:15:54PM +0100, Richard Biener wrote: >> On Mon, Nov 18, 2013 at 10:08 PM, Trevor Saunders <tsaund...@mozilla.com> >> wrote: >> > On Mon, Nov 18, 2013 at 10:03:53PM +0100, Marc Glisse wrote: >> >> On Mon, 18 Nov 2013, Trevor Saunders wrote: >> >> >> >> >This patch adds a class auto_vec which releases its internal >> >> >storage in its destructor, but unlike stack_vec it has no built in >> >> >storage so its reasonable to use it in objects on the heap. It >> >> >then replaces a bunch of vectors on the stack with stack_vec if >> >> >the initial creation size was a compile time constant or auto_vec >> >> >otherwise. >> >> >> >> Why not use stack_vec<T, 0>? You could partially specialize it if there >> >> is waste, and you could make the 0 implicit. >> > >> > I'd like to see it get used for stuff on the heap, but that depends on >> > or at least only makes sense once other stuff uses destructors. >> >> Using stack_vec would be odd, but yes, making the 0 implicit >> and adding a constructor with element count would make sense. > > it occured to me we could rename stack_vec to auto_vec and make the > default 0 and add the constructor taking a size. That would seem to > handle all use cases without being strange, does that sound good?
Yeah, that sounds like a nice idea. >> Of course then we'd have auto_bitmap but stack_vec, that's a bit >> inconsistent. > > I think I'll be successful in adding ctor / dtor to bitmap_head hoping > to post a patch tonight. > >> So in the end I think the patch is ok as-is. Please wait for further >> comments though. > > Hearing none other than Jacub's ChangeLog issue which I hopefully got > right I committed this as r205244, I figure the renaming part should be > super safe so we should probably be fine doing that next week. Yep. Thanks, Richard. > Trev > >> >> Thanks, >> Richard. >> >> > Trev >> > >> >> >> >> -- >> >> Marc Glisse
