🚀 go-pugleaf

In article <58861@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>TYPOS, COMMENTS, AND A QUICK REVIEW ON X3J16/90-0091
>
>[The following are my opinions only]
>
>[...]
>5-8	"A pointer to an object of const type can be cast into a pointer
>	to a non-const type....The result of attempting to modify that
>	object through such a pointer will either cause an addressing
>	exception or be the same as if the original pointer had referred
>	to a non-const object.  It is implementation dependent whether 
>	the addressing expection occurs.
>
>	In my opinion, this section is oxy-moronic.  A standard should not
>	sanctify two bipolar implementation choices that so differ that no
>	reasonable strictly-conforming program can make use of both 
>	behaviors.  Either ONE behavior for const objects should be 
>	codified, or the entire issue should be left implementation 
>	dependent.  It is silly to insist that compilers accept cast-
>	from-const constructs, where that construct is just going to cause
>	a runtime error later, because on that machine consts are write-
>	protected.  My recommendation is that the entire issue of cast 
>	from const be implementation dependent.  In particular, on 
>	machines where consts go in read-only memory, compilers should
>	not allow cast from const.  And highly-optimizing C++ compilers 
>	may wish to prohibit cast-from-const to allow efficiencies by
>	making const-ness assumptions part of the function calling 
>	protocol.  [IE enregistered const parameters need not be reloaded
>	over function call boundaries.]

I disagree strongly on this point.  By specifying exactly 2 options
for compiler writers, ANSI gives a needed degree of freedom while minimizing
the difficulty for programmers.  Under the proposal, people who want
ultra-clean code will avoid casting away const, just as they will under
Jim's proposal.  However, under the ANSI proposal, programmers will be able 
to write portable code which takes advantage of casting away const and 
works portably across all machines that allow it (which I expect to be
the majority of them), while (with judicious use of #defines) they could
preserve a second version fairly easily that did not rely on casting away
const.

For example, a class might be designed which caches results of common
operations in private members of the object.  Even if the object is 
semantically const, it should be legal for the object to update these
caches, and could be accomplished by casting "this" from const.  It would
not be hard to write such classes so that caching (and casting from const)
could be turned off with a #define.  

I interpret the spec to say "Well, lots of people want const to be an
artificial limitation, to make programs easier to debug, but lots of
other people want to write ROMable code and use const to tell the compiler
it is okay to put this variable in ROM.  Since we don't want to add still
one more keyword, we will just let compiler writers choose which one they
want to implement, since the customers of a particular compiler will likely
agree on which choice is better."

Also note that the spec doesn't say that a compiler either has to do it 
one way or another.  It would not be unreasonable to have the compiler
always generate the same code (which allows casting away const), and have the
address exception only occur when the program is executed from ROM.

I expect the result of the ANSI proposal will be that most compilers would
allow casting away const (in a portable way), while only compilers that
were being used to develop embedded code that would actually live in 
ROM would not allow casting away const.  Compilers could also be written
to support both options, with a command-line option or pragma to select
between them.

>8-11 8.4.3 'A variable declared to be a T&, that is "reference to type 
>	T" (&8.2.2), must be initialized by an object of type T or by
>	an object that can be converted into a T."
>
>	In my opinion, null references should be explicitly allowed, thus
>	maintaining the general symmetry between pointers and references.  
>	Also, it seems silly to prohibit such in the language spec when 
>	compilers can't detect such usages.  IE we should explicitly 
>	allow:
>
>	int& r = *(int*)0;


And I suppose you then would write:

if (&r == 0)  cerr << "r is null";

This strikes me as too error prone.  In general, a reference is just 
another name for a real object.  If you want to allow for there not
being an object, then use a pointer.

>9-4	"Nonstatic data membres of a class declared without an intervening
>	access-specifier are allocated so that later members have higher
>	addresses within a class object."
>
>	In my opinion, this statement is silly and outside the scope of
>	a language definition and instead is the business of compiler
>	implementators.  [...]

I would like to see the stronger statement that would provide for 
strict correspondance between C++ class data members and ANSI-C structs.
Perhaps that was what was intended by this requirement, although it
appears in fact to be too weak to have much of any usage.

>9-7	"A union may be thought of as a structure whose member objects
>	all begin at offset zero and whose size is sufficient to contain 
>	any of its member objects."
>
>	A union CAN be thought of like this, or any other way you might
>	choose, but if this isn't meant to be a constraint on how 
>	compilers are allowed to implement unions, then it'd be best to 
>	leave the statement out.  [...]

I think a little clarification and explanation can remain in the spec, 
even if it isn't a strict requirement.  If it is not made explicit 
elswhere, then I would agree that this statement should be expanded into
a requirement on how unions are implemented.
>16-4	"An implementation may impose a limit on the depth of #include
>	directives within source files that have been read while 
>	processing a #include directive in another source file."
>
>	A sensible lower bound should be stated that all conforming
>	implementations must be able to meet.  What does ANSI-C call out?

I agree.  People are already reporting to comp.lang.c++ problems caused
by one compiler's limit of 11 levels of #include nesting.



-- 
Jeremy Grodberg      "I don't feel witty today.  Don't bug me."
jgro@lia.com