🚀 go-pugleaf

TYPOS, COMMENTS, AND A QUICK REVIEW ON X3J16/90-0091

[The following are my opinions only]

1-1 "February 1990"	

	Should be updated.

2-1 "tokens, that is, a file"

	Looks like a misuse of commas, but I can't figure out how to fix 
	it.

2-2 keywords

	Shouldn't this include a list of preprocessor directives and
	"defined" ?

5-5 5.3.3"The type-specifier-list may not contain const, volatile, class
	declarations, or enumeration declarations."

	It would seem that allowing const and/or volatile would not be 
	harmful, and might make for better type calculus, especially when 
	using the placement operator:

	const volatile ClockReg* pread_only_clock_reg = 
		new(0x12345678) const volatile ClockReg;

	or consider:

	#define ROClockReg const volatile ClockReg

	// ....

	ROClockReg* proClockReg = new(0x12345678) ROClockReg;

5-7 5.4 "A yet undefined class may be used in a pointer cast, in which
	case no assuptions will be made about class latices."

	Actually, in this situation it seems to me that a LOT of 
	assumptions ARE made!  Perhaps it would be better to state what
	those assumptions are?  To wit:  in such a situation, a pointer
	remains bitwise equivalent, and no pointer adjustments are made?
	Or what?

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.]

7-5 7.1.6	"Volatile"

	Exact meaning of volatile needs to be codified.  "A hint to the
	compiler not to be overagressive" is insufficient.

7-8	"it is recommended that the spelling be taken from the document
	defining that language, for example Ada (not ADA) and FORTRAN
	(not Fortran)

	Recommendations have no place in a standard.  Its either a 
	requirement or its not.  Make this a requirement.	

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;

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.  In the language, the only connotation of ordering
	of addresses is the ordering of elements of an array.  Therefor,
	it is not possible to write a strictly conforming program that 
	makes use of the above constraint.  Individual compilers
	can still choose to follow the above constraint, and programmers
	can then write non-strictly conforming programs that make use
	of those compilers' "features."  So what is the point of making
	ALL compilers forever-more conform to a constraint that NO 
	STRICTLY-conforming program can use !?

	All this constraint does is confuse customers about what kinds of
	pointer hacks are strictly conforming, and what aren't.

	Among other things, this unnecessary  constraint has a 
	negative impact on compilers striving for speed, compactness, 
	incremental compiles, schema evolution, etc...  

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.  In particular, it is easy to imagine
	on some machines "offset zero" might refer to left packed objects,
	but that machine might prefer to right pack objects into a union,
	leading to a "not offset zero" implementation.  Consider the 
	following trivial example:

	union { long l; char c; } U;

	Are both l and c constrained to be at "offset zero" ? I think 
	not.

10-1	"The commentary sections at the end of this chapter discuss the
	run-time mechanisms necessary to implement inheritence."

	The commentary is gone, and so should this statement.

13-2	"Note that only the second and subsequent array dimensions are
	significant in argument types."

	I think this is bad.  Arrays of fixed dimension should 
	always be considered of certain type, but be coercible to 
	uncertain type implicitly.  The rules for array parameters go
	the wrong way, allowing the below kind of silly-ness:

	double power(double d[1][3])
	{
		return 
		d[0][0]*d[0][0] +
		d[0][1]*d[0][1] +
		d[0][2]*d[0][2] ;
	}

	void doSomething()
	{
		double M3x3[3][3];

		double pow = power(M3x3);	// oops, we silently sliced 
							// off 2 rows!
	}

	.... or even worse.  Implicit coercion of arrays of definite
	type to arrays of indefinite type is bad enough.  Implicit
	coercions of arrays of indefinite type to arrays of definite
	type must be the weakest point in the C++ type system!


13-5	typo: numbers [1]-[5] are duplicated.

13-6	13.4	"The following operators cannot be overloaded"

	As I have argued before, I believe operator dot, and operator
	dot star, should be overloadable analogous to operator->() and
	operator->*()

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?