ngo@tammy.harvard.edu (Tom Ngo) (02/20/91)
Background information to this posting was in a very recent summary. Is ~const really needed? I have scoured the replies, looking for alternative ways to accomplish similar objectives without extending the language. The most obvious way to achieve the functionality of ~const is to cast constness away on a case by case basis. The only other alternative was described by Jim Adcock <jimad@microsoft.uucp>, who brought up the following suggested scheme, mainly to show how absurd it is. Say you want to implement the equivalent of ~const data members. If you want to avoid casting away const, which is implementation- dependent, you have to set up two classes which are <identical in all respects except that in one, all members are non-const, and in the other, all data members are const except the ones that you want to behave as if they were ~const. Then when what you want is the const version of the class, you declare an object of the latter class; otherwise, you declare an object of the former class. Then if you want to make things a bit neater, you can declare two smaller classes: one with all the members that are always ~const, and the other with the members that can be other const or not. This makes it easier to maintain consistency between the two classes of the previous paragraph. Are there any other alternatives? -- Tom Ngo ngo@harvard.harvard.edu 617/495-1768 lab number, leave message
Reid Ellis <rae@utcs.toronto.edu> (03/01/91)
Tom Ngo <ngo@tammy.harvard.edu> writes: >.. you have to set up two classes which are <identical in all >respects except that in one, all members are non-const, and in the >other, all data members are const except the ones that you want to >behave as if they were ~const. ... >Are there any other alternatives? How about this? struct foo { foo(); int method() const; int sometimes() const; int nonconst(); private: foo & fRef; }; foo::foo() : fRef(*this) {} Then, if say "sometimes()" needs to do a non-const thing, it can simply say "fRef.nonconst()". I guess this is esentially casting the const away, but the compiler won't make a peep about it. Reid -- Reid Ellis 176 Brookbanks Drive, Toronto ON, M3A 2T5 Canada rae@utcs.toronto.edu || rae%alias@csri.toronto.edu CDA0610@applelink.apple.com || +1 416 446 1644
jimad@microsoft.UUCP (Jim ADCOCK) (03/07/91)
In article <1991Mar1.094159.40@alias.uucp> Reid Ellis <rae@utcs.toronto.edu> writes: |How about this? | |struct foo { | foo(); | int method() const; | int sometimes() const; | int nonconst(); |private: | foo & fRef; |}; | |foo::foo() : fRef(*this) {} | |Then, if say "sometimes()" needs to do a non-const thing, it can |simply say "fRef.nonconst()". | |I guess this is esentially casting the const away, but the compiler |won't make a peep about it. Seems to me some compiler someday could choose to howl about this constructor when envoked for a const foo. It also seems to me that you point out a weakness in the language -- it should be possible to specify whether constructors are const "functions" or not.