In article <1028@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>Jim,
>
>It appears that you are going to be making a lot of proposals.  That's fine,
>but if you want them taken seriously, you should try to come up with
>some very specific wording that could be incorporated directly into the
>ANSI draft document.  Also, you should try to specify what section of E&S
>we are talking about for this proposal and you should say where and how
>your new proposed text should be fitted together with the existing wording
>in that section.

I'm not sure I buy this.  I'd like to have comp.std.c++ be the forum
for "public input" on the c++ standard.  This is the spirit in which
I am writing to comp.std.c++

Hopefully, at least on some issues, public input will reach some kind
of general consensus on how some of the loose ends in C++ should be
resolved.

But, eventually what's going to happen is a representatives from various
compiler vendors, etc, are going to have to sit down in a room, hammer out
the exact details, and fix the wording in the C++ documentation.  That
is the place where things are going to have to get really formal, not
in public discussion.  However, the wording can't get fixed until
the intent is nailed down.

In any case, I hope to be able to restrain myself from making lots of
proposals.  I'm mainly trying to point out little loose ends that need
to be cleaned up -- not major overhauls.

In article <56159@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>1) That null references explicitly be defined as legal in the language.  A
>null reference is that which is created from a "dereferenced" null pointer
>such as follows:
>
> FOO& fooref = *((FOO*)0);
>
>2) That "dereferencing" null pointers except in the initialization of references
>be explicitly defined as not legal in the language.  The exact effect
>of dereferencing a null pointer would be "implementation defined", but the
>intent is that no legal object can be referenced via a null pointer.
>
>[disclaimer: this posting represents the opinions of an individual C++ user]

Jim,

It appears that you are going to be making a lot of proposals.  That's fine,
but if you want them taken seriously, you should try to come up with
some very specific wording that could be incorporated directly into the
ANSI draft document.  Also, you should try to specify what section of E&S
we are talking about for this proposal and you should say where and how
your new proposed text should be fitted together with the existing wording
in that section.

For instance:

 8.4.3 References

  Strike the first sentence and replace it with:

  "A variable declared to be a T&, that is `reference
  to type T' (&8.2.2), must be initialized by a value of
  type T&.  For the initializer of a reference, a conversion
  of a type T value to a type T& value will be implicitly
  supplied by the compiler where needed."

  "If the initializer for a reference is an expression
  whose last operation is the dereferencing of a pointer
  valued subexpression via the unary `*' operator, then the
  evaluation of the initializer expression will not include
  the application of the final unary `*'.  Rather, in such
  cases, the reference will be initialized to refer to the
  same portion of memory as does the pointer-valued sub-
  expression.  (Note that the value of the pointer-valued
  subexpression may legally be NULL.)"

  "Similarly, if the initializer for a reference is an
  expression which (before implicit conversions are applied)
  itself has the same reference type, then the evaluation of the
  initializer expression will not include the application of
  normal implicit conversion of that reference type value to its
  corresponding (referent) object type value.  Rather, the
  reference value itself will initialize the reference
  object which is being initialized."

--
// Ron Guilmette
// C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <RLS.90Jul31125458@onondaga.steinmetz.ge.com> rls@onondaga.steinmetz.ge.com (Rod Sprattling) writes:
>
>One use for dereferencing null pointers leaps to mind.  Consider this
>definition, used in Intrinsics-based widgets in the X Window System:
>
>#define XtOffset(type,field) \  ...

The correct way to deal with this is with ANSI C's `offsetof' macro,
which can do whatever magic is necessary in a particular implementation.

That is, there is no need to invent a solution -- e.g. allowing null
dereferencing -- for this problem, it has already been solved.
--
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry