Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.std.c++ Subject: Re: Encouraging readonly memory (was ~const) Message-ID: <4200@lupine.NCD.COM> Date: 2 Mar 91 21:37:42 GMT References: <1991Feb20.220900.7523@ithaca.uucp> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 36 In article brucec@phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) writes: > >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... That seems to be true around here also. >...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. Hummm... I'll bet you would like to see the data object called `array' in the following example be able to go into ROM. Interestingly, I think that the semantics currently defined for the initialization of local static objects might effectively prohibit such treatment. void foobar () { static const char array[] = "Hello world.\n"; // ... } This is probably not the best example I could have cooked up, but if you read the bottom half of page 92 in the ARM, you may see the problem that I'm getting at. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.