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
jos...@codesourcery.com
