"Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:

>>      while (bool(cin))
>There's an awful lot of code out there that says "while (cin) ...", and
>no one wants to rewrite it all just to coax it through the new compiler.
>That's probably the reason.

Right, but that's not really my point. My point is that allowing the
keyword "explicit" for conversion operators would make a lot of sense.
If the committee ever did want to eliminate implicit conversion from
istream to bool, then they could simply make it explicit. Sure, people
would have to change their code, but at least the change would be
mnemonic and readable. More importantly would be the addition of

   template <class T> class auto_ptr {
     ...
     explicit operator bool() const;
   };

This would be a clean syntax that would allow

   auto_ptr<foo> x;
   while (bool(x))
     ...

I shouldn't have confused the issue by using cin as my example.
-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Willer wrote:
> ... the (April '95) draft standard auto_ptr doesn't have an operator
> bool() function in it, making it inconvenient to write "if (ptr)" type
> constructs. Is there some sort of reason for that? I know that implicit type
> conversion is generally a bad thing, but I can't see how this one would be
> particularly dangerous (also, can the new explicit keyword be used on the
> return type?).

Automatic conversion only to bool would not, as Steve suggests, be
likely to cause problems.  However, once converted to bool, it would
then convert freely to int, char, or double.

> the latest iostream standard has an operator bool() and an operator!()
> defined. So why not be consistent?

This problem is serious enough that the Core working group has resolved
to consider restricting conversion sequences involving bool.

If the Core WG doesn't resolve the problem, the Library WG will replace
iostream's operator bool() with operator void*().  (This alternative is
less attractive in the case of auto_ptr<>, where it would cause confusion.)

Automatic conversions can be a problem in general, but the problems
with automatic conversions to a numeric type are ridiculous.
Compatibility with C has its downside.

As a side note...  The problem with automatic conversions is not
only that the conversion may be called unexpectedly; the
possibility of the conversion affects overloading, so it may
force you to add "unnecessary" casts to guide the compiler to
the correct choice of function to call.

Nathan Myers
ncm@cantrip.org   http://www.cantrip.org/
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

"Nathan Myers, http://www.cantrip.org/" <ncm@cantrip.org> wrote:

>Automatic conversions can be a problem in general, but the problems
>with automatic conversions to a numeric type are ridiculous.
>Compatibility with C has its downside.
>
>As a side note...  The problem with automatic conversions is not
>only that the conversion may be called unexpectedly; the
>possibility of the conversion affects overloading, so it may
>force you to add "unnecessary" casts to guide the compiler to
>the correct choice of function to call.

Sounds like another reason to permit the keyword "explicit" to apply to
conversion operators. I really don't see why the committee is so
resistant to this concept. I think the following would be a perfectly
satisfactory usage:

   class istream : public ...
   {
     ...
     explicit operator bool() const;
     ...
   };

   void f()
   {
     while (bool(cin))
       // do something
   }

Its clear. Its easy to remember. Its clean. Same would work for
auto_ptr<>.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pablo Halpern wrote:
> I really don't see why the committee is so
> resistant to this concept. I think the following would be a perfectly
> satisfactory usage:
>
>    class istream : public ...
>    {
>      ...
>      explicit operator bool() const;
>      ...
>    };
>
>    void f()
>    {
>      while (bool(cin))
>        // do something
>    }

There's an awful lot of code out there that says "while (cin) ...", and
no one wants to rewrite it all just to coax it through the new compiler.
That's probably the reason.

--

Ciao,
Paul D. DeRocco
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Pablo Halpern wrote:
>
> "Nathan Myers, http://www.cantrip.org/" <ncm@cantrip.org> wrote:
>
> >Automatic conversions can be a problem in general, but the problems
> >with automatic conversions to a numeric type are ridiculous.
> >Compatibility with C has its downside.
> >
> >As a side note...  The problem with automatic conversions is not
> >only that the conversion may be called unexpectedly; the
> >possibility of the conversion affects overloading, so it may
> >force you to add "unnecessary" casts to guide the compiler to
> >the correct choice of function to call.
>
> Sounds like another reason to permit the keyword "explicit" to apply to
> conversion operators. I really don't see why the committee is so
> resistant to this concept. I think the following would be a perfectly
> satisfactory usage:
>
>    class istream : public ...
>    {
>      ...
>      explicit operator bool() const;
>      ...
>    };
>
>    void f()
>    {
>      while (bool(cin))
>        // do something
>    }
>
> Its clear. Its easy to remember. Its clean. Same would work for
> auto_ptr<>.
>

I'd agree with that.  An explicit cast from a string to a <charT> * would be
nice as well ... much cleaner than c_str() and data().
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]