From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Thu, 14 Sep 2000 08:13:46 +0000 From: "Douglas A. Gwyn" Message-ID: <39BFF7BE.108DBE4F@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20000913180633.35E20199E0@mail> Subject: Re: [9fans] no const? Topicbox-Message-UUID: 07a5fd1a-eac9-11e9-9e20-41e7f4b1d025 Russ Cox wrote: > Those are the two main needs for volatile, gone, at the > price of a little optimization, as was pointed out. > ... > compiler flag to make everything volatile. This is basically > what the Plan 9 compiler does. Of course, implementors are free to do that. The reason they tell me that they don't usually is that many of their customers demand more aggressive optimization (without the programmer having to edit source code to get it). If that is not important to Plan 9 goals, then its approach is fine and the "volatile" keyword can then in effect be a no-op. > In the case of const, ... it certainly feels like > such things have been added as a sacrifice to the god of > efficiency rather than for use by mere mortals. I use "const" frequently, and not because I expect any additional optimization. Rather, it documents one important property of some parameters etc. and enables diagnostics that routinely detect a certain class of bugs (which would be undetectable without some programmer- supplied indication of the intent in the source code). > And it is a fact that const and volatile are not easily > understood. Try explaining to a beginning C programmer > why "volatile Chan *c" or "Chan volatile *c" both declare > a pointer to a volatile Chan structure rather than a > volatile pointer to a Chan structure (which would, obviously, > be "Chan *volatile c"). That's just a problem in understanding Dennis's contextual design for C type declarations in general, and is no harder to explain than anything else of a similar sort in C.