On 09/05/14 16:38, Trevor Saunders wrote:
So, in this case it seems to me you basically have two options
A. change the macro to an inline function, and fix up all the callers to
pass the right type. Then rebase that into some sort of reasonable
patch series.
b. add a function with a different name and convert users piece meal,
and then remove the old macro (I guess you can then rename the new
function to the old macro if you like).
of those I prefer b because it means you can convert call sites one at a
time and its easy to know which have been delt with.
My worry with piecemeal is obviously an incomplete transition. While we
have that to some extent with David's patches, we don't generally have
two ways to get at the same hunk of data.
I also do think the advantages of using members outways the cost.
I don't think it's always the case, but my general preference will be to
go to member functions.
For one thing functions with all caps names are just weird. I think the
more important reason though is that it will help make rtx_insn be a
separate class sometime in the far future, since at some point we can
make its inheritance from rtx_def protected to chase down things that
try to convert from rtx_insn to rtx. There's also the argument that its
inconsistant to have some things be members and others be functions.
Yes, the all caps is weird. There was a time when the all caps
designated that we were using a macro and it was expected to be very
efficient. When calling a function we were supposed to use lowercase to
signify the likely high overhead.
I'd tend to lean towards #1. If we want to convert to methods, I think
that can be a follow-up. Type safety is my focus right now, not pushing
towards member functions.
Jeff
