On Wed, Oct 17, 2012 at 12:26:42AM +0000, Joseph S. Myers wrote:
> On Tue, 16 Oct 2012, Michael Meissner wrote:
>
> > It occurs to me that now that we've committed to GCC being done in C++, we
> > could just make global_options{,_set} be a class instead of a structure. So
> > you could say:
> >
> > global_options.set_FOO (value)
> >
> > Or:
> >
> > global_options.set_FOO ();
> > global_options.clear_FOO ();
> >
> > I could generate the macros (or inline functions) if you would prefer to
> > stick
> > the C style of doing things. However, as an old C dinosaur, I'm not sure of
> > all of the ramifications of doing this. It just seems it would be cleaner
> > to
> > use the class structure, instead of passing pointers.
>
> In general, as much as possible should use an instance of struct
> gcc_options that is passed explicitly to the relevant code (or associated
> with the function being compiled, etc.), rather than using global_options
> directly (explicitly or implicitly).
>
> The existing way of doing that is using a pointer to a gcc_options
> structure. With a class I'd think you'd still need to pass it around as
> either a pointer or a reference (even if you then use member functions for
> some operations on these structures), and I'm not aware of any particular
> advantage of using a reference. I do not think most functions that happen
> to take a gcc_options pointer (often along with lots of other pointers to
> other pieces of state) are particularly suited to being member functions
> of gcc_options.
>
> Given that existing practice is passing pointers around, I'd think that's
> appropriate for any new such functions / macros, unless and until we have
> some clear notion of when functionality should or should not be a member
> function of gcc_options.
In thinking about it this morning, I don't think we need the options machinery
to generate new functions. We can just use the set_option function in
opts-common.c to set those options. I likely will add a convenience function
in rs6000.c to default most of the arguments for this.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
