On Thu, 5 Sep 2013, Richard Sandiford wrote:
> Kenneth Zadeck <zad...@naturalbridge.com> writes:
> > 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.
>
> Well, I was more worried that lots of friend clauses were often seen as
> bad design. It wasn't really an "is this feature OK in gcc" question.
>
> > 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.
>
> There are two sub-issues here really:
>
> (1) whether it's OK for wide_ints to be writable.
>
> The interface already exposed the idea of an array of blocks,
> via get_val() and get_len(). The question here is whether it is OK
> to also have the corresponding write functions write_val() and set_len().
>
> IMO if you're exposing the array publicly, there's nothing wrong
> with having it be a read/write interface rather than a read-only
> interface. My analogy on IRC was std::string. std::string exposes
> the array of characters, and allows those characters to be both read
> or written. The alternative being suggested is the equivalent of
> saying that anything that wants to directly or indirectly modify
> individual characters of a std::string must be either a member of
> std::string or a friend (but reading individual characters is fine).
>
> I suppose the alternative is closer to the Java idea of immutable
> strings. I don't really see the need for that in C++ though.
> If you want an object to stay constant after construction,
> just declare it "const".
If all wide_int ops are non-mutating (which as wide-ints can be
large may be a bad idea, even if it's "clean") then the members
should be not writable apart from at construction time. Well,
ideally at least - implementation-wise that may not be very easy,
but at least the setters could be private.
> (2) We have some functions that are purely there to handle out-of-line
> cases for inline functions, like add_large handling the large add
> cases. Is it OK for these out-of-line functions to be publicly callable?
>
> I think this really is one where we have to trust ourselves not
> to do something silly. E.g. the rtl-checking functions use things
> like rtl_check_failed_type1 to handle the out-of-line case of a
> checking failure. That has always been directly callable,
> but I don't ever remember anyone trying to use it directly.
> Using things like add_large "accidentally" seems just as unlikely,
> especially given its array-based interface.
>
> If we want a bit of extra dressing to emphasise that these functions
> are private, we could have something like a wi::priv namespace.
The functions could also be private static member functions of wide_int,
no?
Richard.
