Francis Glassborow wrote:
>
> In article <8lh00r$25d$1@esel.cosy.sbg.ac.at>, Gerhard Wesp
> <gwesp@cosy.sbg.ac.at> writes
> >a) it would be by far more natural and
> >b) it would make it possible to spot errors like the above at compile
> >   time!
> >
> >so what were the reasons for the committee to standardize the void*
> >conversion instead?  am i missing something obvious?
>
> Yes, for a short period they did that but it made code such as:
> int i = 3;
> cin << i;
>
> valid:)

In case it isn't obvious, if the iostream classes had an
operator bool(), the expression would be equivalent to
 bool(cin) << i; // yields 1 or 0 left shifted by i bits
Instead of an error message, the code would compile
without complaint, and you'd get unexpected program behavior.

Similarly, cin+2 would be a valid expression.

Yet another example why type conversion functions are dangerous,
except when you truly want to allow the conversion in any
conceivable circumstance.  There are not many places where an
implicit conversion to void* causes problems (because there are
no implicit conversions from void*, and you can't do arithmetic
on a void*), so it was used as a reasonable compromise.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dennis Yelle wrote:
>
> Francis Glassborow wrote:
> >
> > In article <8lh00r$25d$1@esel.cosy.sbg.ac.at>, Gerhard Wesp
> > <gwesp@cosy.sbg.ac.at> writes
> > >a) it would be by far more natural and
> > >b) it would make it possible to spot errors like the above at compile
> > >   time!
> > >
> > >so what were the reasons for the committee to standardize the void*
> > >conversion instead?  am i missing something obvious?
> >
> > Yes, for a short period they did that but it made code such as:
> > int i = 3;
> > cin << i;
> >
> > valid:)
>
> Heh.  So why was it made legal to shift a bool?

You can't shift a bool. In an expression, a bool value is
converted to int. If the iostream classes had an operator bool(),
the result of cin<<i would be an int with the value int(bool(cin))<<i.

---
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <397CCC90.4C99EDB3@jps.net>, Dennis Yelle <dennis51@jps.net>
writes
>Heh.  So why was it made legal to shift a bool?
>(I would vote against it.)

So would I, but one result of design by consensus was that the only way
bool could be voted into the language was by allowing implicit outward
conversions to arithmetic types. So in the above, the user defined
conversion would generate a bool, which the compiler then implicitly
converts to an int so that it can call the built-in shift operator.

The above decision was motivated (as not a few other technically poor
decisions) by the political need for backward compatibility with C.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article ToTR2HB3brf5Ew0u@robinton.demon.co.uk, Francis Glassborow at
francis@robinton.demon.co.uk wrote on 7/27/00 12:48 AM:

> In article <397CCC90.4C99EDB3@jps.net>, Dennis Yelle <dennis51@jps.net>
> writes
>> Heh.  So why was it made legal to shift a bool?
>> (I would vote against it.)
>
> So would I, but one result of design by consensus was that the only way
> bool could be voted into the language was by allowing implicit outward
> conversions to arithmetic types. So in the above, the user defined
> conversion would generate a bool, which the compiler then implicitly
> converts to an int so that it can call the built-in shift operator.
>
> The above decision was motivated (as not a few other technically poor
> decisions) by the political need for backward compatibility with C.

There ought to be a policy that C++ compilers generate warnings for features
that exist only for backward compatibility. Then, at least, coders would be
encouraged to move forward and there might be a possibility of someday
dropping some of C++'s more annoying quirks - or at least allow compilers to
support a safer non-compatability mode.

Anders.

--
Anders Pytte                                   Milkweed Software
PO Box 32                                  voice: (802) 586-2545
Craftsbury, VT 05826                  email: anders@milkweed.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Anders Pytte wrote:
>
> in article ToTR2HB3brf5Ew0u@robinton.demon.co.uk, Francis Glassborow at
> francis@robinton.demon.co.uk wrote on 7/27/00 12:48 AM:
>
> > In article <397CCC90.4C99EDB3@jps.net>, Dennis Yelle <dennis51@jps.net>
> > writes
> >> Heh.  So why was it made legal to shift a bool?
> >> (I would vote against it.)
> >
> > So would I, but one result of design by consensus was that the only way
> > bool could be voted into the language was by allowing implicit outward
> > conversions to arithmetic types. So in the above, the user defined
> > conversion would generate a bool, which the compiler then implicitly
> > converts to an int so that it can call the built-in shift operator.
> >
> > The above decision was motivated (as not a few other technically poor
> > decisions) by the political need for backward compatibility with C.

But, C had no bool type at that time.

> There ought to be a policy that C++ compilers generate warnings for features
> that exist only for backward compatibility. Then, at least, coders would be
> encouraged to move forward and there might be a possibility of someday
> dropping some of C++'s more annoying quirks - or at least allow compilers to
> support a safer non-compatability mode.

That sounds good, but, where can I find a list of these annoying quirks?
Do you think we can come to a consensus on what they are?
I suppose you could add this to gcc, if you really wanted it.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <B5A47D80.81EB%anders@milkweed.com>, Anders Pytte
<anders@milkweed.com> writes
>There ought to be a policy that C++ compilers generate warnings for features
>that exist only for backward compatibility.

However that is a QoI issue and outside the remit of the Standard.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <397F47F8.74EB7EDB@jps.net>, Dennis Yelle <dennis51@jps.net>
writes
>> > The above decision was motivated (as not a few other technically poor
>> > decisions) by the political need for backward compatibility with C.
>
>But, C had no bool type at that time.

Exactly so programmers used idioms that relied on integer values
representing booleans.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> The above decision was motivated (as not a few other technically poor
> decisions) by the political need for backward compatibility with C.

Not just with C, but with common usage in C++.

Until type bool was introduced, boolean expressions had type int.
If bool values were not implicitly promoted to type int in expressions,
a large amount of reasonable C++ code would break. That in turn would
likely prevent adoption of the standard (which must be by consensus), or
use of the standard if it were nevertheless adopted.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8lh00r$25d$1@esel.cosy.sbg.ac.at>, Gerhard Wesp
<gwesp@cosy.sbg.ac.at> writes
>a) it would be by far more natural and
>b) it would make it possible to spot errors like the above at compile
>   time!
>
>so what were the reasons for the committee to standardize the void*
>conversion instead?  am i missing something obvious?

Yes, for a short period they did that but it made code such as:
int i = 3;
cin << i;

valid:)



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <8lh00r$25d$1@esel.cosy.sbg.ac.at>, Gerhard Wesp
> <gwesp@cosy.sbg.ac.at> writes
> >a) it would be by far more natural and
> >b) it would make it possible to spot errors like the above at compile
> >   time!
> >
> >so what were the reasons for the committee to standardize the void*
> >conversion instead?  am i missing something obvious?
>
> Yes, for a short period they did that but it made code such as:
> int i = 3;
> cin << i;
>
> valid:)

Heh.  So why was it made legal to shift a bool?
(I would vote against it.)

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <qlDP1XA12Gf5EwDL@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>int i = 3;
>cin << i;

  ok, i don't even want to know which constructs would become valid if
we used for example a operator double() instead! ;-)
--
 Mag. Gerhard Wesp -- Institut f"ur Mathematik -- Universit"at Salzburg
   -- Hellbrunnerstr. 34 -- A-5020 Salzburg -- Tel. +43 662 8044 5329

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Dennis Yelle" <dennis51@jps.net> wrote

> So why was it made legal to shift a bool?

It isn't legal to shift a bool.  However bool is convertable to int, and you
can shift an int.  Lots of languages agree with you that bools (and chars)
should not be implicitly convertible to and from int.  C and C++ say they
are.

> (I would vote against it.)

I believe that I would too, unless I was using C compatibiltiy as a major
selling point of my language.

Idiomatic C uses
    number_correct += (answer == correct_answer);
Making that statement illegal breaks too much existing code.  For an
experienced C programmer that statement is, IMO, easier to read than the
equivalent statements that use 'if', '?:', or a cast.  The version with 'if'
is, IMO, much easier to read for someone not all that familiar with C.

HTH



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

last friday it took me a fair amount of time to spot the error in the
following code:

#include <iostream>
#include <fstream>
#include <string>

using namespace std ;

void foo(const string& file)
{
    // open file or use cout:
  ostream*
    op = file == "-" ? &cout : new ofstream( file.c_str() ) ;

    // write something to *op ...

    // if we wrote to a file, close it now:
  if( op != cout ) delete op;
    //     ^
    //     oops, forgot the & here!
}

what surprised me at first is that the op != cout comparison is actually
valid!  after all, notationally we compare a type to a pointer to this
type, like in  cout == &cout .  but what happens here is that cout is
converted into a void* by basic_ios::operator void*() and then we have
just a comparison of pointers.  the void* conversion is defined in
27.4.4.3p1 and returns:

  If fail(), then a null pointer, otherwise some non-null pointer to
  indicate success.

this means, the only use for the returned pointer is to compare it to
0 in order to test the stream state.  IMO, for this purpose a conversion
to bool would be more appropriate because

a) it would be by far more natural and
b) it would make it possible to spot errors like the above at compile
   time!

so what were the reasons for the committee to standardize the void*
conversion instead?  am i missing something obvious?
--
 Mag. Gerhard Wesp -- Institut f"ur Mathematik -- Universit"at Salzburg
   -- Hellbrunnerstr. 34 -- A-5020 Salzburg -- Tel. +43 662 8044 5329

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]