Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!att!cbnewsl!cbnewsk!pegasus!hansen
From: hansen@pegasus.att.com (Tony L. Hansen)
Newsgroups: comp.lang.c++
Subject: Re: Comparison functions for qsort() and bsearch()
Summary: we agree! (sort of)
Keywords: C++, void*, standards
Message-ID: <1991Feb15.162246.1887@cbnewsk.att.com>
Date: 15 Feb 91 16:22:46 GMT
References: <1991Feb3.195156.151@cbnewsk.att.com> <1991Feb6.222244.23132@clear.com> <70670@microsoft.UUCP>
Sender: hansen@cbnewsk.att.com (tony.l.hansen)
Organization: AT&T Bell Laboratories
Lines: 49

< From: jimad@microsoft.UUCP (Jim ADCOCK), Message-ID: <70450@microsoft.UUCP>
< Hansen's position is that one can assume that any permissions granted
< by ANSI-C not granted by ARM represents an omission from ARM.  I
< disagree.  The ANSI-C++ committee's stated position is that the ARM is
< the primary source, and the ANSI-C document is secondary.  This raises
< the question of whether differences between ARM and the ANSI-C document
< are intentional, or accidental.  These differences will hopefully,
< someday, be resolved by the ANSI-C++ committee.  Until then, someone
< wanting to write portable C++ code would do well to only write code to
< the explicit permissions contained in ARM.
<
< There are already, well documented, well thought out, differences
< between ANSI-C and C++ in regards to void pointers.  I see no reason to
< assume then, in this case, that ANSI-C and C++ will be the same.
< Again, I encourage people to consider ARM and the working papers of the
< ANSI-C++ committee to be the defacto definition of C++ until we get the
< final ANSI-C++ document some years hence.

< From: jimad@microsoft.UUCP (Jim ADCOCK), Message-ID: <70670@microsoft.UUCP>
< The bottom line is eventually one has to admit that the ARM is indeed a
< reference manual, and not a standards specification.  Hopefully, all
< these little details will be nailed down by the ansification effort.

There are definitely places where the ARM (and the cfront 2.1 reference
manual) is obviously not a a full standards specification. My understanding
of the ANSI C++ stand on ANSI C is that where the cfront 2.1 reference manual
(not the ARM) doesn't cover something, the ANSI C rule shines through. You
and I disagree as to whether the ANSI C rule should shine through in this
case. We definitely agree that the cfront 2.1 reference manual is
insufficient and that the final ANSI C++ standard must resolve the issue. All
current C++ compilers and common practice follow the ANSI C rule in this one
area. I hope that the next ANSI C++ draft (due out soon) will address this
issue and resolve this question.

(The following may be stating the obvious to some of you.) Note, as time goes
on, the ARM will inevitably become out of date. Reprints include corrections,
but pretty soon, the only true document which can be considered as any
statement of the current ANSI C++ position will be the current draft
standard.  Whether the ARM will continue to try to reflect the "current
draft" is a subject that Peggy and Bjarne will have to address. If it IS kept
up, then we'll be in the position of continually asking "which printing of
the ARM are you looking at?" If not, then we'll be in the same position that
we were in during ANSI C's development: people will continually have problems
gaining access to the current draft.

					Tony Hansen
				att!pegasus!hansen, attmail!tony
				    hansen@pegasus.att.com
				      tony@attmail.com