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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Kenneth Zadeck <zadeck@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".

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

Thanks,
Richard