On Sun, 25 Aug 2013, Mike Stump wrote:
> On Aug 25, 2013, at 12:26 AM, Richard Sandiford <[email protected]>
> 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?
Yeah - wi::lt (a, b) is much better than a.lt (b) IMHO. It mimics how
the standard library works.
> > 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.
Now, if you look back in discussions I wanted a storage
abstraction anyway. Basically the interface is
class wide_int_storage
{
int precision ();
int len ();
element_t get (unsigned);
void set (unsigned, element_t);
};
and wide_int is then templated like
template <class storage>
class wide_int : public storage
{
};
where RTX / tree storage classes provide read-only access to their
storage and a rvalue integer rep to its value.
You can look at my example draft implementation I posted some
months ago. But I'll gladly wiggle on the branch to make it
more like above (easy step one: don't access the wide-int members
directly but via accessor functions)
> > 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.
Indeed - in my sample the wide-int-rtx-storage and wide-int-tree-storage
storage models were declared in rtl.h and tree.h and wide-int.h did
know nothing about them.
> Yes, though, does wi feel odd being a home for comparing a CONST_INT and
> 16? :-)
>
> > 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?
The comparisons? Better.
Thanks,
Richard.
