This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Changes to the wide-int classes
- From: Michael Matz <matz at suse dot de>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches at gcc dot gnu dot org, mikestump at comcast dot net
- Date: Thu, 5 Sep 2013 15:09:01 +0200 (CEST)
- Subject: Re: [RFC] Changes to the wide-int classes
- Authentication-results: sourceware.org; auth=none
- References: <87wqn0bb5q dot fsf at talisman dot default> <5227A65B dot 6080406 at naturalbridge dot com> <874n9zbv2j dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1309051113130 dot 3869 at zhemvz dot fhfr dot qr>
On Thu, 5 Sep 2013, Richard Biener wrote:
> > (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.
Generally in the context of GCC I don't believe in syntactic privacy if it
results in _any_ jumps through hoops (and adding friends is one in my
view). We don't create a library to be used by 3rd party developers, we
control all users of our constructs, so privacy by review is totally fine.
We also have good indication that this works in practice, first because
the first 25 years of GCC development didn't have compiler enforced
privacy, and second because also "recently" introduced data structures
didn't become abused just because some members were public. Think e.g.
gimple. Everything but low level mutators use the accessor functions.
And that's how it should be; the low level routines shouldn't need to use