Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Comparison functions for qsort() and bsearch()
Keywords: Sun, C++
Message-ID: <70670@microsoft.UUCP>
Date: 14 Feb 91 18:02:38 GMT
References: <1991Jan21.022720.20707@cbnewsk.att.com> <70271@microsoft.UUCP> <1991Feb3.195156.151@cbnewsk.att.com> <1991Feb6.222244.23132@clear.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 57

In article <1991Feb6.222244.23132@clear.com> rmartin@clear.com (Bob Martin) writes:
|From: jimad@microsoft.UUCP (Jim ADCOCK)
|>< [... some stuff deleted ...]
|>< I see nothing in ARM that gives one permission to
|>< explicitly cast back from a void* back to the original object* type.
|>
|
|If you refer to ARM section 4.6 there is an peculiar statement which reads:
|
|	"in C++ a void* cannot be assigned to an object of any type other than
|	a void* without an explicit cast."
|
|If we remove the double negative it becomes:
|
|	"in C++ a void* can be assigned to an object of any type other than
|	a void* only with an explicit cast."
|
|This is roundabout, but I think it refutes Jim's statement.

I disagree.  Usually language references and standards consist of
explicit permissions and denials.  Only by taking all the explicit
permissions and denials in a language reference or standard can one
make sense of the authors intent.  When you invert the double negative,
you are attempting to turn an explicit denial into an implicit permission.
In this, I disagree.  Explicit denials cannot imply permissions -- they
always only restrict what a programmer is allowed to do.  If one could
imply implicit permissions from denial statements, you'd find the 
manual highly contradictory!

The original statement says that you cannot convert a pointer from a 
void* without an explicit cast -- it says nothing about where or when
such explicit casts are allowed.

Section 5.4 does explain what casts are permitted.  It also makes an
extrodinarily strong statement that any type conversion not mentioned
in that section and not explicitly defined by the user is an error!

Now the second paragraph on page 68 says that a pointer to one object
type may be explicitly converted to a pointer to another object type
[subject to other restrictions in section 5.4]  It also explicitly states
that a void* is a pointer to object type.  It also says that a pointer 
can be converted to an object of the same or smaller size and back again
without change.  Now a char* represents a pointer to the smallest object,
so a char* would seem to be preferred for such back casting.  Where are 
the "void" size and alignments specified?

The question that remains in my mind is exactly what is to be interpreted
from the "[subject to other restrictions in section 5.4]" statement --
given that it is already stated that anything not explicitly permitted
in 5.4 is denied, and given therefore that there *aren't* other restrictions
in section 5.4 -- since everything else is explicitly denied, the wording
of section 5.4 only consists of permissions.  What then, is the meaning of the
"[subject to other restrictions ....]" statement  ????

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.