Hi, 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 accessor functions. Ciao, Michael.
