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? > 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. Trev > > Thanks, > Richard. > > > Trev > > > >> > >> -- > >> Marc Glisse
