This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ edge_iterator (was: Re: [SH] PR 53976 - Add RTL pass to eliminate clrt, sett insns)
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Trevor Saunders <tsaunders at mozilla dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 16 Dec 2013 18:26:31 +0100
- Subject: Re: C++ edge_iterator (was: Re: [SH] PR 53976 - Add RTL pass to eliminate clrt, sett insns)
- Authentication-results: sourceware.org; auth=none
- References: <1384975779 dot 2438 dot 119 dot camel at yam-132-YW-E178-FTW> <CABu31nPbcThrjzPN49E=VO3BrZjz5noaE95gjj-vx=0ikPj6+g at mail dot gmail dot com> <1386784057 dot 2455 dot 73 dot camel at yam-132-YW-E178-FTW> <20131212081349 dot GA1708 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <1386968457 dot 2455 dot 129 dot camel at yam-132-YW-E178-FTW> <20131216145751 dot GB14749 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <1387208640 dot 2455 dot 261 dot camel at yam-132-YW-E178-FTW> <20131216161530 dot GC14749 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
On Mon, 2013-12-16 at 11:15 -0500, Trevor Saunders wrote:
> > That could also be an option. Although having pointer wrappers already
> > in place might open some other opportunities in the future. For
> > instance it would make it relatively easy to try out reducing the number
> > of garbage collected objects by adding smart pointer functionality to
> > the pointer wrapper.
>
> Well, I'd expect freeing stuff owned by basic_block should happen in
> basic_block::~basic_block not some pointer wrapper which would be more
> error prone. However making that happen is kind of tricky while
> basic_block is in gc memory, I've been idly considering allowing gentype
> to call dtors somehow...
Usually smart pointers (i.e. pointer wrappers) don't delete aggregated
stuff in the pointee, but delete the pointee only (if at all). The
pointee's destructor is then supposed to free whatever it needs to,
which would meet your expectations.
> >
> > > for (edge *e = vec.begin (); e != vec.end (); e++)
>
> sure, I think writing that for a vector makes sense, though I might
> manually pull the vec.end() out of the loop
With which intention?
Cheers,
Oleg