Responses to ~const 1.6: Alternatives to ~const

Thread View: comp.std.c++

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Tom Ngo Tue, 19 Feb 1991 16:32

#847

Author: Tom Ngo
Date: Tue, 19 Feb 1991 16:32

31 lines
1958 bytes

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

Re: Responses to ~const 1.6: Alternatives to ~const

#881

Author: Reid Ellis
Date: Fri, 01 Mar 1991 09:41

32 lines
1348 bytes

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

Re: Responses to ~const 1.6: Alternatives to ~const

#921

Author: Jim ADCOCK
Date: Wed, 06 Mar 1991 20:26

24 lines
1214 bytes

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.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads