[PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com