This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GSoc-2015: Modular GCC (RFC on refactoring)
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 18 Mar 2015 00:50:58 -0400
- Subject: Re: GSoc-2015: Modular GCC (RFC on refactoring)
- Authentication-results: sourceware.org; auth=none
- References: <CAA_ASpVFs7LXS4Pw1Mxo5VCxtEncvYXjYgnULGoRAWnbM3PkYw at mail dot gmail dot com> <54F87A48 dot 6070803 at redhat dot com> <54FA52CD dot 2080003 at gmail dot com> <54FB1C2B dot 7010108 at redhat dot com> <5508F5F3 dot 500 at gmail dot com> <20150318042427 dot GA5533 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <550900B5 dot 5000601 at redhat dot com>
On Tue, Mar 17, 2015 at 10:36:05PM -0600, Jeff Law wrote:
> On 03/17/2015 10:32 PM, Trevor Saunders wrote:
> >
> >>2. Lists, list nodes and list iterators should be objects of distinct
> >>types. In this case, header file function.h gets additional dependency,
> >>because struct rtldata contains insn/expr lists as members; currently
> >>they are pointers, so a forward declaration is sufficient. A possible
> >>workaround is to create an opaque type like it's done with struct
> >>initial_value_struct (at a cost of one additional level of indirection).
> >>Which is better?
> >
> >given std::forward_list isn't available in c++98 I expect you'll write
> >your own version of it. It seems pretty reasonable to me function.h
> >would depend on the hypothetical header containing that list template,
> >and presumably more stuff than just rtx_insn_list's could be made to use
> >it.
> Sigh. We could just use a vec then... That would still be better in
> various ways than chaining things via EXPR_LIST or INSN_LIST.
yeah, I even seem to remember coming across a place where both were done
and wondering why.
Trev
>
>
> Jeff
>