From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28053 invoked by alias); 5 Sep 2013 07:12:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28041 invoked by uid 89); 5 Sep 2013 07:12:58 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 05 Sep 2013 07:12:58 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,FREEMAIL_FROM autolearn=ham version=3.3.2 X-HELO: mail-wi0-f182.google.com Received: by mail-wi0-f182.google.com with SMTP id ez12so1421673wid.9 for ; Thu, 05 Sep 2013 00:12:54 -0700 (PDT) X-Received: by 10.180.185.10 with SMTP id ey10mr5187986wic.29.1378365174489; Thu, 05 Sep 2013 00:12:54 -0700 (PDT) Received: from localhost ([2.26.203.233]) by mx.google.com with ESMTPSA id i12sm9344309wiw.3.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 05 Sep 2013 00:12:53 -0700 (PDT) From: Richard Sandiford To: Kenneth Zadeck Mail-Followup-To: Kenneth Zadeck ,gcc-patches@gcc.gnu.org, mikestump@comcast.net, rguenther@suse.de, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, mikestump@comcast.net, rguenther@suse.de Subject: Re: [RFC] Changes to the wide-int classes References: <87wqn0bb5q.fsf@talisman.default> <5227A65B.6080406@naturalbridge.com> Date: Thu, 05 Sep 2013 07:12:00 -0000 In-Reply-To: <5227A65B.6080406@naturalbridge.com> (Kenneth Zadeck's message of "Wed, 04 Sep 2013 17:30:03 -0400") Message-ID: <874n9zbv2j.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-09/txt/msg00272.txt.bz2 Kenneth Zadeck writes: > It is possible restore the privacy of the original patches but this=20 > seems to involve using a private class inside the namespace and using=20 > C++ friends. > > Adding visibility adds extra code > > namespace wi { > class impl { > private: > add_large() { } > } > friend add(=E2=80=A6); > }; > > that is roughly 1 line per client that uses an internal routine for the f= riend declaration and 5 extra lines for the other stuff. > > Richard worries that using friends is not within the scope acceptable=20 > C++ mechanisms to use within the gcc community. We are, of course, open=20 > 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=20 > that go. In past comments, Richi, asked that we remove all of the public= =20 > method calls that modified the internals of a wide-int. We did this and=20 > we generally are happy that we did this. So there is the question is the= =20 > 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 callabl= e? 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