Topic: A proposal for const
Author: Rich.Blinne@FtCollinsCO.NCR.COM (Rich Blinne)
Date: 24 Oct 91 16:20:24 GMT Raw View
There has been much discussion about what the real meaning of "const" in
C++. I have a proposal that may deal with both the compiler optimization
issues and eliminating the need for casting away constness.
The solution is to mark members that do not represent the "state" of the
object as a volatile member and to provide volatile inheritance. Two examples
follow:
-------------------------------------------------------------------------
EXAMPLE 1
class ObjectWithReferenceCount{
public:
ObjectWithReferenceCount(constObject& object) : TheObject(object)
{ReferenceCount = 1;}
void IncrementRefCount() const {ReferenceCount++;}
private:
Object TheObject;
volatile int ReferenceCount;
};
-------------------------------------------------------------------------
EXAMPLE 2
class ReferenceCount{
public:
ReferenceCount() {RefCount = 1;}
void IncrementRefCount() {RefCount++};
private:
int RefCount;
};
class ObjectWithReferenceCount : private volatile ReferenceCount {
public:
ObjectWithReferenceCount(const Object& object) : ReferenceCount(),
TheObject(object) {}
IncrementRefCount() const {ReferenceCount::IncrementRefCount();}
private:
Object TheObject;
};
---------------------------------------------------------------------------
In example 1, notice the IncrementRefCount is a const member function. A
const member function only enforces "constness" of non-volatile members. Since
ReferenceCount is a volatile member and Object is not modified,
IncrementRefCount
is a const member function.
In example 2, a non-const member function can be called on a base class which
is inherited volatile and still remain a const member functions.
The compiler implications of this proposal are that a compiler can only
optimize classes which contain non-volatile members and is not inherited from
volatile base classes. Such a compiler would have to deprecate casting away
constness.
Any comments?
================================================================
Rich Blinne, NCR Microelectronic Products Division
NCR, The Networked Computing Resource of AT&T
2001 Danfield Ct. |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ft. Collins, CO 80525 | Rich.Blinne@FtCollinsCO.NCR.COM
(303) 223-5100 x334 | ..!uunet!ncrlnk!ncr-mpd!Rich.Blinne
================================================================
Rich Blinne, NCR Microelectronic Products Division
2001 Danfield Ct. |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ft. Collins, CO 80525 | Rich.Blinne@FtCollinsCO.NCR.COM
(303) 223-5100 x334 | ..!uunet!ncrlnk!ncr-mpd!Rich.Blinne
Author: jimad@microsoft.com (Jim ADCOCK)
Date: 28 Oct 91 20:27:37 GMT Raw View
In article <1135@ncr-mpd.FtCollins.NCR.COM> Rich.Blinne@FtCollinsCO.NCR.COM writes:
|There has been much discussion about what the real meaning of "const" in
|C++. I have a proposal that may deal with both the compiler optimization
|issues and eliminating the need for casting away constness.
|
|The solution is to mark members that do not represent the "state" of the
|object as a volatile member and to provide volatile inheritance.
....
|The compiler implications of this proposal are that a compiler can only
|optimize classes which contain non-volatile members and is not inherited from
|volatile base classes. Such a compiler would have to deprecate casting away
|constness.
|
|Any comments?
I agree that marking non-const members within const objects would be the
best way to go. Thomas Ngo <ngo@tammy.harvard.edu> has a well written
proposal before the committee on this subject, that I recommend to
people interested in this subject:
"Proposed extension to C++: ~const" X3J16/91-0112
Perhaps he can give you a copy of his paper, and you can coordinate
your efforts. Perhaps someone on the committee can state the present
status of Thomas' suggestion?