Re: [RFC] Changes to the wide-int classes

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Richi, and the rest of the community,

Richard Sandiford has proposed a set of patches that change the wide-int 
api in a significant way. We think that we really need some input from 
the community as to if this is what we want using C++ in gcc is going to 
look like. There are, as I see it, two issues that are raised by these 
patches:

1) Visibility. In my original wide-int patch, there were things that 
were public and things that were private. In general, the implementation 
details were private, but also the privacy was used to enforce the 
readonlyness of the representation. A wide int is an object and that 
object has value that cannot be changed. In Richard's restructuring, 
everything is visible in the wi namespace. The privacy of the internals 
can only be enforced by review of the maintainers.

It is possible restore the privacy of the original patches but this 
seems to involve using a private class inside the namespace and using 
C++ friends.

Adding visibility adds extra code

namespace wi {
	class impl {
		private:
			add_large() { }
	}
	friend add(…);
};

that is roughly 1 line per client that uses an internal routine for the friend declaration and 5 extra lines for the other stuff.

Richard worries that using friends is not within the scope acceptable 
C++ mechanisms to use within the gcc community. We are, of course, open 
to other suggestions.

My personal view is that privacy is important and I do not want to let 
that go. In past comments, Richi, asked that we remove all of the public 
method calls that modified the internals of a wide-int. We did this and 
we generally are happy that we did this. So there is the question is the 
privacy important and if it is what is the proper mechanism to implement it.

2) In my original patch, almost all of the operations either used 
operators or method calls. In richard's patch, those method calls have 
all become regular function calls. This is not just a syntactic change. 
The wide-int operations are fairly generic. The operations are not just 
defined on wide-ints but also on tree and rtx constants. In my patch the 
tree and rtx arguments were not converted to wide-ints. instead, the 
code looked inside of the representation of the tree and rtl and just 
operated on that. However, in my patch the first parameter had to be a 
wide-int to make the method call. By making everything a regular 
function call, richard's patch avoids having to make the wide-int object 
just to make the method call. This seems like a big win, but it means 
that the wide-int code does not "look like" the double-int code anymore. 
I am in favor of this change, but it i (we) fear that there will be 
pushback from those that wanted this to look more oo-like as double-int 
currently does.

comments suggestions, and questions are appreciated.

thanks,

kenny