This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 {
			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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]