Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!zephyr.ens.tek.com!sol!tekchips!tekcrl!brucec From: brucec@phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) Newsgroups: comp.std.c++ Subject: Re: Encouraging readonly memory (was ~const) Message-ID: Date: 21 Feb 91 21:23:33 GMT References: <1991Feb20.220900.7523@ithaca.uucp> Sender: news@tekchips.LABS.TEK.COM Organization: Tektronix Inc. Lines: 47 In-reply-to: garry@ithaca.uucp's message of 20 Feb 91 22:09:00 GMT In article <1991Feb20.220900.7523@ithaca.uucp> garry@ithaca.uucp (Garry Wiegand) writes: > 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. As a developer of software tools for a company which employs several hundred embedded systems programmers (somewhat fewer than a company like AT&T), I disagree with the implication that readonly memory is only a convenience. For us it's a fact of life. There are many places in a program where we must be able to *guarantee* that a particular object can be burned into ROM, or we have to change our design. Currently, all that sort of handwaving is done literally by hand :-), that is we have to write code in contorted ways, at higher-than-optimal development cost, to ensure that things can go in the right places. This contortion is why C is so popular in embedded software (1/2 :-)). In fact I support very strongly some sort of statement in the standard which guarantees me some conditions in which I can be sure I can ROM an object. Otherwise I have to negotiate that separately with each compiler writer, probably getting a different solution and a different set of conditions from each. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077