This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] add auto_vec
- From: Trevor Saunders <tsaunders at mozilla dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Trevor Saunders <trev dot saunders at gmail dot com>
- Date: Fri, 22 Nov 2013 00:49:44 -0500
- Subject: Re: [PATCH] add auto_vec
- Authentication-results: sourceware.org; auth=none
- References: <1384803979-16557-1-git-send-email-trev dot saunders at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1311182158320 dot 18892 at stedding dot saclay dot inria dot fr> <20131118210827 dot GA28138 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <CAFiYyc2ZdD4_FfUeookcOSHX-HtO62t8Xi86xQHDAdU3jdyj7Q at mail dot gmail dot com>
On Tue, Nov 19, 2013 at 01:15:54PM +0100, Richard Biener wrote:
> On Mon, Nov 18, 2013 at 10:08 PM, Trevor Saunders <tsaunders@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