In article <9502222.1165@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
> kevlin@wslint.demon.co.uk (Kevlin Henney) writes:
>
> >I guess that
> >some of the logic behind disallowing const void * output was that you
> >could break constness by reading the pointer straight back in again!
> >But this is a pretty weak argument (there are far easier ways of casting
> >away constness!), so I'm afraid I don't know what the real reason for the
> >change was.
>
> My guess is that there wasn't _any_ logic behind disallowing const void *
> output.  I'd bet that it was inadvertent - the original author just
> didn't think about `const void *'.

There is reason to suspect that it may have originated with a bug in
Cfront.  The "const void *" version is present, but commented out, in
the <iostream.h> from Cfront 3.0:

     ostream&        operator<<(unsigned int a);
     ostream&        operator<<(unsigned long);
     ostream&        operator<<(void*);
    /*      ostream&        operator<<(const void*);   add this later */

It makes me think that they probably tried "const void *", and ran into
problems.

Anyway, I hope the committee will repair it in the standard.
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth

In article <3g0mbh$7pb@seattle.polstra.com>
           jdp@polstra.com "John Polstra" writes:

>There is reason to suspect that it may have originated with a bug in
>Cfront.  The "const void *" version is present, but commented out, in
>the <iostream.h> from Cfront 3.0:
>
>            ostream&        operator<<(unsigned int a);
>            ostream&        operator<<(unsigned long);
>            ostream&        operator<<(void*);
>    /*      ostream&        operator<<(const void*);   add this later */
>
>It makes me think that they probably tried "const void *", and ran into
>problems.

So a broken compiler leads to a broken standard? :-(

>Anyway, I hope the committee will repair it in the standard.

Ditto.

+---------------------------+------------------------------------+
| Kevlin A P Henney         | Money confers neither intelligence |
| kevlin@wslint.demon.co.uk | nor wisdom on those who spend it   |
| Westinghouse Systems Ltd  |                                    |
+---------------------------+------------------------------------+

In article <3es36j$hke@seattle.polstra.com> jdp@polstra.com (John Polstra) writes:
>The iostreams portion of the C++ library provides a way to output
>arbitrary pointers as numbers, presumably for debugging.  Stroustrup 2nd
>edition describes this as:
>
>    ostream::operator<<(const void *)
>
>while Plauger, "The Draft Standard C++ Library" describes it as:
>
>    ostream::operator<<(void *)
>
>Which is correct, according to the current thinking of the standards
>committee?
>

 Probably, neither. The correct form would be

 ostream::operator<<(void const volatile*);

-- so you can output the address of an io port.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3es36j$hke@seattle.polstra.com>
           jdp@polstra.com "John Polstra" writes:

>The iostreams portion of the C++ library provides a way to output
>arbitrary pointers as numbers, presumably for debugging.  Stroustrup 2nd
>edition describes this as:
>
>    ostream::operator<<(const void *)
>
>while Plauger, "The Draft Standard C++ Library" describes it as:
>
>    ostream::operator<<(void *)
>
>Which is correct, according to the current thinking of the standards
>committee?

According to the current working paper, the latter example is in fact
the correct one. I was surprised when I went to look this up, as this
hinders writing simple debugging code - all your pointers to const need
casting <yuk!>. I also noticed that istream has acquired the member

 istream &operator>>( void *& );

If I remember correctly, this was not originally present. I guess that
some of the logic behind disallowing const void * output was that you
could break constness by reading the pointer straight back in again!
But this is a pretty weak argument (there are far easier ways of casting
away constness!), so I'm afraid I don't know what the real reason for the
change was.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+