On 08/25/2013 06:55 PM, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford <rdsandif...@googlemail.com>
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between wi and wide_int_ro (except for the debug routines).
It seems reasonable; I don't see anything I object to. Seems like most of the
time, the code is shorter (though, you use wi, which is fairly short). It
doesn't seem any more complex, though, knowing how to spell the operation
wide_int:: v wi:: is confusing on the client side. I'm torn between this and
the nice things that come with the patch.
(3) Removing the comparison member functions and using the static
ones everywhere.
I've love to have richi weigh in (or someone else that wants to play the role
of C++ coding expert)… I'd defer to them…
The idea behind using a namespace rather than static functions
is that it makes it easier to separate the core, tree and rtx bits.
Being able to separate core, tree and rtx bits gets a +1 in my book. I do
understand the beauty of this.
IMO wide-int.h shouldn't know about trees and rtxes, and all routines
related to them should be in tree.h and rtl.h instead. But using
static functions means that you have to declare everything in one place.
Also, it feels odd for wide_int to be both an object and a home
of static functions that don't always operate on wide_ints, e.g. when
comparing a CONST_INT against 16.
Yes, though, does wi feel odd being a home for comparing a CONST_INT and 16?
:-)
on the other hand, how else are you going to do this. i have not seen
anyone sign up to make an oo version of rtl and even if they did that,
the consts are just a small part of it.
i agree that it is odd, but then again, it is actually nice to have a
largely similar interface for trees and rtl.
I realise I'm probably not being helpful here.
Iterating on how we want to code to look like is reasonable. Prettying it up
where it needs it, is good.
Indeed, if the code is as you like, and as richi likes, we'll then our mission
is just about complete. :-) For this patch, I'd love to defer to richi (or
someone that has a stronger opinion than I do) to say, better, worse…
