Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ithaca!garry
From: garry@ithaca.uucp (Garry Wiegand)
Newsgroups: comp.std.c++
Subject: Encouraging readonly memory (was ~const)
Message-ID: <1991Feb20.220900.7523@ithaca.uucp>
Date: 20 Feb 91 22:09:00 GMT
Organization: Ithaca Software
Lines: 70

Tom Ngo writes:
>ARM 7.1.6: [proposed]
>
>    A const object of a type that does not have a constructor or a
>    destructor might be placed in readonly memory.  The const parts of
>    any object that does have a constructor might be placed in
>    DISCARDABLE [write-once] memory unless the class contains any
>    ~const member function.  Discardable memory is virtual memory that
>    is paged to disk only the first time it is faulted out after
>    construction.  Thereafter, the effect of any write operation to
>    any const part of any such object is undefined.

ARM 7.1.6: (original)
     A const object of a type that does not have a constructor or a
     destructor may be placed in readonly memory.

Why in the world does the ARM have to get involved in all these
implementation details?? It seems like a bad policy to be describing
machinery rather than describing the language. 

Would it not suffice, in language terms, to say:

    A const object may be set or changed only during construction. At
    other times const objects may be cast to non-const, but the actual
    writing of such an object is still prohibited. The enforcement of
    this prohibition is implementation-dependent.

Ie, const memory may or may not be hardware-readonly and/or "discardable"
after construction. As is explained and depicted in the immediately-
preceding example section in the ARM.

Rationale:
Readonly implementations should be encouraged, not prohibited ("a
type that does not have a constructor or destructor may be placed in
readonly memory" reads to me as a prohibition in the normal
"constructed" case.) Readonly memory, properly implemented, doesn't
hurt anything and ought to be encouraged - it helps find bugs,
and in some cases it improves efficiency.

Argument:
Margaret/Bjarne justify the policy by saying "...since in most
practical machine architectures memory cannot be made 'readonly'
during program execution". This ain't true. VMS machines, for
example, are not rare and VMS implemented 'memory protection fixups'
during image startup years ago. The startup sequence loads initial
values in, and then makes the proper op sys call to change the page
protections/paging mechanism on the relevant group of pages to
'readonly'. Exactly what you'd want at least for static const C++
objects. (Dynamic const objects would require a small amount of
additional trickiness, for efficiency - I'm thinking of a separate
'readonly heap', plus a certain bit of Vax magic for quickly
temporarily getting privileged write-access to the pages.)

Note 1:
Writeability is required only during construction by the first
paragraph of 7.1.6. So I can't see what the rationale was for
bothering with the words "or a deconstructor" in the original quoted
section. Have I missed something?

Note 2:
If the casting to non-const weren't allowed *at all*, then "the
enforcement of this prohibition" would no longer have to be
"implementation-dependent" - the compiler could handle it
completely. If I understand C++.

Yes, I know declaring any kind of cast to be unreasonable wouldn't
be "C-like".

Garry Wiegand    ---    Ithaca Software, Alameda, California
...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net