James Kanze US/ESC 60/3/141 #40763 (kanze@lts.sel.alcatel.de) wrote:
: Does the following look right to you?
:     while ( (cin >> x).succeeded() ) ...
: I like it in some ways, but it does bother me that the principal
: operation (the input) is in the extra parentheses; this seems to make it
: subordinate to the function, at least visually.

    while ( cin.operator>>(x).succeeded() )
Solves the visual problem, but verbose.

: (FWIW: I've not yet decided in my own mind.  I currently use a mixture of:
:     while ( ! (cin >> x).fail() ) ...
: and:
:     while ( cin >> x ) ...
: In the long, I think I will probably fully adopt the latter style,
: despite my misgivings, because this is what the people reading my code
: will most expect.  I still think it very confusing, but I can't really
: say that I have a better alternative.)

    for ( cin >> x; ! cin.fail(); cin >> x )
Hum, looks like an iterator loop :)
    for (istream_iterator<X> i(cin); i != istream_iterator<X>(); ++ i)
        x = *i;
or
    for_each(istream_iterator<X>(cin), istream_iterator<X>(),
            BodyOfLoopFunctionObject() );
Not claiming that any of these are better, just noting that there will
be many new ways to do it and "expect" may no longer be reasonable.

The sad part is that the idiom being used is for known good data with
the failure expected at eof.  It should be
    for ( cin >> x; ! cin.eof(); cin >> x)
which works on systems which always have a '\n' at the end of the file
but fails for some types on systems which omit the final '\n'.

John


[ 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                             ]

Dave Hansen <dhansen@btree.com> wrote in article
<199609172322.SAA09539@T-Rex.Minn.Net>...
> But I can't remember
> _ever_ relying on the automatic conversion of a bool to a numeric
> type.

I can. Programming languages with conditional operators (?:) like C/C++ are
much less common than languages that don't, like Basic and Cobol: languages
that many of us learned long before C.

In a ?:-lacking language, the usual conditional-op idiom goes like this:

 a = (b == c) * 3 + 1;

which is equivalent to

 a = (b == c) ? 4 : 1;

In many Basics, True == -1 (that is, ~0), so the expression above becomes

 LET A = (B = C) * -3 + 1

The idiom breaks down with complicated expressions or variable types, but
it's very handy for little expressions when you know the integer value of
"true." Plus, the compiler might even get away with translating the *
expression without a branch, which a ?: is almost guaranteed to give you
under a typical compiler.

Therefore, people accostomed to the above idiom, unfamiliar with ?:, or
heavily sub-optimizing their code (read: most programmers) do in fact rely
on a conversion from bool to int. Other more common examples include

 int switch = a < b;

Sure, bool doesn't exist in C, but a < b does, and changing the return type
of a < b means you break code unless the new type can convert to the old
one. Finding and updating existing code like this is a real, major problem
in corporate computing. Even worse is when the code happens in libraries or
applications purchased in source-code format (like it is on most unixes and
mainframes). Is it safe to modify the vendor's code? If so, you *still*
have a major maintenance problem.
--
Bradd W. Szonye
bradds@ix.netcom.com
http://www.netcom.com/~bradds


[ 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                             ]

Graham C. Hughes <graham@resnet.ucsb.edu> wrote in article
<m27mpwbgb8.fsf@graham.resnet.ucsb.edu>...
> >  double w,x,y;
> >  foo z;
> >  ...
> >  x = y + z; // oops, meant w=x+y
> > it will compile and run. The result will be
> >  x = y + double(z.operator bool());
>
> Did I miss something, or is this a double conversion?  (i.e., z is
> required to convert to a bool, then to a double)  And isn't that
> prohibited by everything from Stroustrup's
> _The_C++_Programming_Language_ on?

It's not illegal, because the WP only prohibits two user-defined
conversions. bool to double is a standard conversion.

> Stroustrup's 2nd edition mentions that "only one level of user-defined
> implicit conversion is legal."  Is the kicker here "user-defined", and
> what happens if we say that "only one level of implicit conversion is
> legal"?  What breaks if we try that?

I imagine that it would break a lot of library code, if not user code.

Actually, this situation is the first thing I've seen that would call for
use of an "explicit" conversion to type. Ordinarily you're better off
writing a "named" function to provide explicit conversion to type (as
opposed to implicit conversion). Here is a place where "explicit" would be
*very* handy...

class ios {
 // ...
 explicit operator bool() const {return good();}
 // ...
};

In this case, you could convert an ios to bool only explicitly and not in
an implicit expression conversion. Consider the bool "argument" to
conditionals an explicit conversion to bool. Then

 if (cin) { /* ... */ }

is legal at compile time, but

 int x, y = 10;
 x = y + cin;

or

 int x;
 cout >> x;

is not. (Am I right here? That is, cout >> x does involve an implicit
conversion, right?) Is it too late to incorporate this idea into the WP,
since it has a precedent in explicit constructors and it satisfies the
"Principle of least astonishment" in a way the current WP doesn't? My only
concern is that considering the boolean in a conditional as an explicit
conversion may have undesirable side-effects.
--
Bradd W. Szonye
bradds@ix.netcom.com
http://www.netcom.com/~bradds
---
[ 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
]

In article fsf@graham.resnet.ucsb.edu, "Graham C. Hughes" <graham@resnet.ucsb.edu> writes:
>clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:
>
>> That works fine. The problem is the the fact that bool also can be
>> silently converted to any numeric type. For example, if you wrote
>>  double w,x,y;
>>  foo z;
>>  ...
>>  x = y + z; // oops, meant w=x+y
>> it will compile and run. The result will be
>>  x = y + double(z.operator bool());
>
>Did I miss something, or is this a double conversion?  (i.e., z is
>required to convert to a bool, then to a double)  And isn't that
>prohibited by everything from Stroustrup's
>_The_C++_Programming_Language_ on?
>
>Stroustrup's 2nd edition mentions that "only one level of user-defined
>implicit conversion is legal."  Is the kicker here "user-defined",

Yes, "user-defined" is the key. In the ARM and in the current draft,
promotions and standard conversions are allowed before and after a
user-defined conversion in resolving overloading.

>what happens if we say that "only one level of implicit conversion is
>legal"?  What breaks if we try that?

If you really mean "one level of implicit conversion", that breaks
lots of things. For example, if you declared
 complex foo(complex);
you couldn't call it as
 foo(1)
since there isn't a direct conversion from int to complex. It would
mean cluttering up every class with extra functions taking each of the
basic types. (You could argue, and many would agree, that C and C++
have too many numeric types and too much interconversion allowed
among them. That isn't going to change any time soon.)

Every time you tinker with the kinds and order of conversions allowed
in overload resolution, you get significantly different results.
Usually if you tweak the rules to make one case work better, you
make other cases give worse results. The rules have been tweaked
many times over the years.

The C++ Committee has been investigating the problem with "bool"
noted above and as of the last meeing had not found a really good
solution. As usual, C compatibility is the problem. Introducing
a true bool type that doesn't implicitly convert to other numeric
types breaks most existing non-trivial programs.

---
Steve Clamage, stephen.clamage@eng.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         ]
[ 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 Clamage wrote:

> isxxxx() function member can yield more information about what the
> truth value of the class actually _means_, whereas the name `operator
> bool' doesn't really tell you much about what the states `true' and
> `false' actually represent with respect to the class.
>
> This _is_ a better approach, IMHO.  What, then, are we to make of
> streams?  :)

# Iostreams also have, for example, the state-testing functions good(),
# bad(), fail(), and eof(), which give you more information than testing
# for true/false.

The true/false test should give you the most important information: can
I use the tested object for it's intended use? In the case of istreams,
ostreams and iostreams with one of ios::in/ios::out set, this is really
clear: Can I read data from this stream, can I write data to this
stream, can I {read from|write to} (depending on open mode) this stream?

It gets a bit difficult when you ask this question about iostreams with
BOTH ios::in and ios::out set. The intented use in this case is both
reading from and writing to the stream. So, it seems logical that the
test should return true if you can BOTH read from and write to the
stream.

In case the test fails, you can always use the specific fail(), bad(),
good(), eof() or any other isxxxx() function to determine what exactly
is the matter.

Bart

Bart
---
[ 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
]

"Bradd W. Szonye" <bradds@ix.netcom.com> wrote:
>Graham C. Hughes <graham@resnet.ucsb.edu> wrote in article
><m27mpwbgb8.fsf@graham.resnet.ucsb.edu>...
>> Stroustrup's 2nd edition mentions that "only one level of user-defined
>> implicit conversion is legal."  Is the kicker here "user-defined", and
>> what happens if we say that "only one level of implicit conversion is
>> legal"?  What breaks if we try that?
>
>I imagine that it would break a lot of library code, if not user code.
>
>Actually, this situation is the first thing I've seen that would call for
>use of an "explicit" conversion to type. Ordinarily you're better off
>writing a "named" function to provide explicit conversion to type (as
>opposed to implicit conversion). Here is a place where "explicit" would be
>*very* handy...
>
>class ios {
>        // ...
>        explicit operator bool() const {return good();}
>        // ...
>};
>
>In this case, you could convert an ios to bool only explicitly and not in
>an implicit expression conversion. Consider the bool "argument" to
>conditionals an explicit conversion to bool. Then
>
>        if (cin) { /* ... */ }
>
>is legal at compile time, but
>
>        int x, y = 10;
>        x = y + cin;
>
>or
>
>        int x;
>        cout >> x;
>
>is not. (Am I right here? That is, cout >> x does involve an implicit
>conversion, right?) Is it too late to incorporate this idea into the WP,
>since it has a precedent in explicit constructors and it satisfies the
>"Principle of least astonishment" in a way the current WP doesn't? My only
>concern is that considering the boolean in a conditional as an explicit
>conversion may have undesirable side-effects.

Your example, "if (cin)," does involve an implicit conversion
from istream_withassign (at least that's what it used to be--I
haven't checked to see what its type is in the DWP) to bool. If
you declare ios::operator bool explicit, that example will fail
to compile. You'd have to write this instead:

        if (static_cast<bool>cin)

which is hardly what we want (to avoid breaking code anyway).

I have to wonder if there could be yet another keyword, not
unlike explicit, that says no more implicit conversions may be
applied to the result of a user-defined conversion. I don't have
a good idea for the name of this keyword, but it would have to be
something suggestive of "terminal implicit" or even
"single implicit" conversion. For now, I'll use "xxx."
ios::operator bool could now be this:

        xxx     operator bool(void) const;

and the example is still this:

        if (cin)

but the result is that cin converts to a bool, the type expected
in the if expression, so the implicit conversion is valid.
However, in an expression like this:

        cout >> j;

it results in an error, because, as Steve Clamage pointed out,
cout doesn't have an operator >>, so this would be interpreted
as:

        int(cout.operator bool()) >> j;

Since operator bool() used the "xxx" keyword, the
implicit conversion to int would be illegal, so "cout >> j;"
would be incorrect.

Robert Stewart  | My opinions are usually my own.
Datalytics, Inc. | stew@datalytics.com
   | http://www.datalytics.com
---
[ 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
]

On 17 Sep 1996 14:48:36 GMT, Steve Clamage wrote in comp.std.c++:

>The C++ Committee has been investigating the problem with "bool"
>noted above and as of the last meeing had not found a really good
>solution. As usual, C compatibility is the problem. Introducing
>a true bool type that doesn't implicitly convert to other numeric
>types breaks most existing non-trivial programs.

Is this true?  I mean, I can see that many programs would break if a
numeric was not implicitly converted to a bool.  But I can't remember
_ever_ relying on the automatic conversion of a bool to a numeric
type.  The latter case seems to be the source of the more hirsute
problems.

Would it feasible to allow the implicit conversion of numeric types to
bool, but require the conversion of bools to numeric types be
explicit?  Is the lack of symmetry fatal?  Or am I missing a common C
idiom that relies on the implicit conversion of a bool to a numeric
type?  And even so, could these not be fixed with a simple cast?

This would not solve the problem noted by Scott Johnson in the
original post of this thread: "if (foo == 3)" compiling without error
even though there is no defined conversion of foo to int, because both
foo and the int would be implicitly converted to bool.  (OTOH, this
almost :) makes sense.)  Problems like these could be eliminated if we
limited the valid operators for boolean types to be &&, ||, and ! (and
new and delete, of course).

No, I haven't thought this all the way through, and yes, I may be
starting a slide down a slippery slope.  But since C does not have a
true boolean type, it seems that the place to start resolving these
problems is to place limitations on the C++ boolean type.  Even if
such limitations are not symmetrical, orthoganal, or "pure."  If
anyone has comments, I'm more than willing to listen. (I'm here to
learn!)

     -=Dave
     dhansen@btree.com

I can barely speak for myself, so I certainly can't speak for B-Tree
---
[ 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
]

In article <199609121841.LAA11836@taumet.eng.sun.com>, clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:
> That works fine. The problem is the the fact that bool also can be
> silently converted to any numeric type. For example, if you wrote
>  double w,x,y;
>  foo z;
>  ...
>  x = y + z; // oops, meant w=x+y
> it will compile and run. The result will be
>  x = y + double(z.operator bool());

Now I'm confused.  I thought only one implicit conversion could be applied
to an operand to make the expression legal.  Am I wrong about that, or is
something else going on?  What exactly is the (current) rule about implicit
conversions?

--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.ccur.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Concurrent Computer Corporation.


[ 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                             ]

dhansen@btree.com (Dave Hansen) writes:

> Is this true?  I mean, I can see that many programs would break if a
> numeric was not implicitly converted to a bool.  But I can't remember
> _ever_ relying on the automatic conversion of a bool to a numeric
> type.

int flag = a < b;

Jason
---
[ 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
]

stew@datalytics.com (Rob Stewart) writes:

>I have to wonder if there could be yet another keyword, not
>unlike explicit, that says no more implicit conversions may be
>applied to the result of a user-defined conversion. I don't have
>a good idea for the name of this keyword, but it would have to be
>something suggestive of "terminal implicit" or even
>"single implicit" conversion. For now, I'll use "xxx."
>ios::operator bool could now be this:

>        xxx     operator bool(void) const;

Perhaps your "xxx" should be viewed as a "meta-CV" qualifier, implying that a
type thus qualified cannot be cast to another type (perhaps modulo CV
conversions???)

I'd suggest the keyword "typeconst". Hence:

 operator typeconst bool (void) const;

Such a qualifier could also be used to disable implicit (or all???) casts on a
variable:

 typeconst int i = 1;

 sqrti = sqrt(i);   // ERROR. IMPLICIT CAST OF A typeconst int
 sqrti = sqrt((double)i);  // ERROR???

or temporarily disable them on a function parameter:

 double foo(typeconst int i)
 {
  return i;    // ERROR. NO IMPLICIT CAST FROM typeconst int
 }

 foo(1);  // OKAY.
 foo(2.3); // OKAY. typeconst PARAMETERS CANNOT BE CAST _FROM_,
   //       BUT THEY CAN BE CAST _TO_.


Note that this last version is opposite in semantics to the oft-suggested
"explicit" qualifier:

 double foo(explicit int i)
 {
  return i;    // OKAY
 }

 foo(1);  // OKAY
 foo(2.3); // ERROR. NO IMPLICIT CAST TO explicit int.


Of course, if necessary you could be totally up-tight and use both to turn
off all casts:

 double foo(explicit typeconst int i)
 {
  return i;    // ERROR. NO IMPLICIT CAST FROM typeconst int
 }

 foo(1);  // OKAY
 foo(2.3); // ERROR. NO IMPLICIT CAST TO explicit int.


One for the "next standard" list?

damian


[ 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                             ]

In article <323E6D67.41C6@wi.leidenuniv.nl> Bart Samwel
<bsamwel@WI.leidenuniv.nl> writes:

|> Steve Clamage wrote:

|> > isxxxx() function member can yield more information about what the
|> > truth value of the class actually _means_, whereas the name `operator
|> > bool' doesn't really tell you much about what the states `true' and
|> > `false' actually represent with respect to the class.
|> >
|> > This _is_ a better approach, IMHO.  What, then, are we to make of
|> > streams?  :)

|> # Iostreams also have, for example, the state-testing functions good(),
|> # bad(), fail(), and eof(), which give you more information than testing
|> # for true/false.

|> The true/false test should give you the most important information: can
|> I use the tested object for it's intended use?

This is not, however, the case of iostreams.  The conversion to bool
returns true if and only if all operations since the preceding clear
have succeeded.  Thus, for example, I don't think that you would argue
that a stream is unusable simply because there was an overflow while
converting an int.  The stream should still return false.

In the case of iostreams, at least, I think that the decision was purely
pragmatic.  The desire was to support a specific idiom, and the choice
of conditions was made accordingly.

I don't think that this is generally a good thing.  The same way that I
don't think that overloading an existing operator to do something
entirely different is a good thing.  The case of iostreams, however, is
a bit special.  IO is, after all, a fundamental part of all programs.
(I have already seen it mentioned somewhere that most beginning C++
programmers think of >> as input, and wonder why the same symbol was
chosen for right shift.)  I'm not sure I agree with the conversion to
bool/void*, but it is hard to think of a reasonably alternative which
works well.  Does the following look right to you?

 while ( (cin >> x).succeeded() ) ...

I like it in some ways, but it does bother me that the principal
operation (the input) is in the extra parentheses; this seems to make it
subordinate to the function, at least visually.

(FWIW: I've not yet decided in my own mind.  I currently use a mixture of:

 while ( ! (cin >> x).fail() ) ...

and:

 while ( cin >> x ) ...

In the long, I think I will probably fully adopt the latter style,
despite my misgivings, because this is what the people reading my code
will most expect.  I still think it very confusing, but I can't really
say that I have a better alternative.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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                             ]

In article <199609172322.SAA09539@T-Rex.Minn.Net> dhansen@btree.com writes:

> >The C++ Committee has been investigating the problem with "bool"
> >noted above and as of the last meeing had not found a really good
> >solution. As usual, C compatibility is the problem. Introducing
> >a true bool type that doesn't implicitly convert to other numeric
> >types breaks most existing non-trivial programs.

> Is this true?  I mean, I can see that many programs would break if a
> numeric was not implicitly converted to a bool.  But I can't remember
> _ever_ relying on the automatic conversion of a bool to a numeric
> type.  The latter case seems to be the source of the more hirsute
> problems.

An example of what breaks:

 int flag;
 flag = x > y;

If the language is changed so that x > y is bool, rather than int,
then it had better be possible to convert bool to int.
--
    --Andrew Koenig
      ark@research.att.com
---
[ 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
]

Scott Johnson (sj@aracnet.com) wrote:
| In many classes (smart pointers, for instance), it is useful to define a
| true-false mapping--that is, certain states of the class are considered
| true, others false.
|
| class foo;
| class bar;
|
| void baz ( void )  // I know, my type and variable names are creative...
| {
|     foo x;
|     bar y;
|     if (x) { ... }
|     while (!y) { ... }
|     for ( x.blah(); !x; x.blech() ) { ... }
|     int i = y ? 45 : 73;
| };
|
| [ Overloading operator bool allows other, unwanted, things to happen. ]
|
| My suggestion:  Allow overloading of operator if.  [...]
|
| Comments?  Is this a solution in need of a problem?

Yes, because you can solve the above problem using function members.
There's no need for an extension to the language.

    class foo { public: bool istrue() ; } ;
    class bar { public: bool istrue() ; } ;

    void baz ()
    {
 foo x;
 bar y;
 if (x.istrue()) { ... }
 while (!y.istrue()) { ... }
 for ( x.blah(); !x.istrue(); x.blech() ) { ... }
 int i = y.istrue() ? 45 : 73;
    }

The only argument against this is that it involves extra typing.

However, to me, that is vastly offset by the fact that in my experience
most real world classes do not have a *single* truth value, and whereas it
is possible to write as many isxxxx() function members as one likes, there
is only one `operator bool' (or `operator if').  Moreover, the _name_ of the
isxxxx() function member can yield more information about what the truth value
of the class actually _means_, whereas the name `operator bool' doesn't really
tell you much about what the states `true' and `false' actually represent with
respect to the class.
---
[ 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
]

On 11 Sep 1996 09:48:02 PDT, Jonathan de Boyne Pollard wrote in
comp.std.c++:

>Scott Johnson (sj@aracnet.com) wrote:
>| In many classes (smart pointers, for instance), it is useful to define a
>| true-false mapping--that is, certain states of the class are considered
>| true, others false.
[...]
>| My suggestion:  Allow overloading of operator if.  [...]
>|
>| Comments?  Is this a solution in need of a problem?

>Yes, because you can solve the above problem using function members.
>There's no need for an extension to the language.

>    class foo { public: bool istrue() ; } ;
>    class bar { public: bool istrue() ; } ;

[...]

>The only argument against this is that it involves extra typing.

Forgive my naivete, but since "bool" is now a built-in type, could we
not simply define a conversion operator so the object would be
implicitly converted to bool where required?  e.g.,

   class foo { public: operator bool() ; } ;

   foo bar;

   [...]

      if (bar) { /*do something*/ }

Or are the conditional expressions in "if," "while," and "for"
statements not required to be converted to type bool?

>However, to me, that is vastly offset by the fact that in my experience
>most real world classes do not have a *single* truth value, and whereas it
>is possible to write as many isxxxx() function members as one likes, there
>is only one `operator bool' (or `operator if').  Moreover, the _name_ of the
>isxxxx() function member can yield more information about what the truth value
>of the class actually _means_, whereas the name `operator bool' doesn't really
>tell you much about what the states `true' and `false' actually represent with
>respect to the class.

This _is_ a better approach, IMHO.  What, then, are we to make of
streams?  :)

     -=Dave
     dhansen@btree.com

I can barely speak for myself, so I certainly can't speak for B-Tree
---
[ 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
]

In article KAA25347@T-Rex.Minn.Net, dhansen@btree.com (Dave Hansen) writes:
>On 11 Sep 1996 09:48:02 PDT, Jonathan de Boyne Pollard wrote in
>comp.std.c++:>

>Forgive my naivete, but since "bool" is now a built-in type, could we
>not simply define a conversion operator so the object would be
>implicitly converted to bool where required?  e.g.,
>
>   class foo { public: operator bool() ; } ;
>
>   foo bar;
>
>   [...]
>
>      if (bar) { /*do something*/ }

That works fine. The problem is the the fact that bool also can be
silently converted to any numeric type. For example, if you wrote
 double w,x,y;
 foo z;
 ...
 x = y + z; // oops, meant w=x+y
it will compile and run. The result will be
 x = y + double(z.operator bool());

We currently have the same problem with iostreams in recent drafts.
Class ios used to have members
 operator!();
 operator void*();
to allow direct testing of streams. That approach more or less works,
but is pretty ugly. The obvious thing to do was to change those to
 operator bool();
But now you can write
 cout >> j; // j is an integer type
The code is legal, even though cout doesn't have an operator>>. The
code compiles as
 int(cout.operator bool()) >> j;
In other words, the value 0 or 1 (according cout's state) is right-shifted
by the value of j and the result is discarded.

The C++ Committee is investigating what to do about this problem.
If we don't have the automatic conversions to and from type bool,
a lot of existing code will fail to compile. Yet the examples
above really ought to yield compile-time errors if C++ is to have
any pretense of type safety.

>>However, to me, that is vastly offset by the fact that in my experience
>>most real world classes do not have a *single* truth value, and whereas it
>>is possible to write as many isxxxx() function members as one likes, there
>>is only one `operator bool' (or `operator if').  Moreover, the _name_ of the
>>isxxxx() function member can yield more information about what the truth value
>>of the class actually _means_, whereas the name `operator bool' doesn't really
>>tell you much about what the states `true' and `false' actually represent with
>>respect to the class.
>
>This _is_ a better approach, IMHO.  What, then, are we to make of
>streams?  :)

Iostreams also have, for example, the state-testing functions good(), bad(),
fail(), and eof(), which give you more information than testing for true/false.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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
]

-----BEGIN PGP SIGNED MESSAGE-----

clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:

> That works fine. The problem is the the fact that bool also can be
> silently converted to any numeric type. For example, if you wrote
>  double w,x,y;
>  foo z;
>  ...
>  x = y + z; // oops, meant w=x+y
> it will compile and run. The result will be
>  x = y + double(z.operator bool());

Did I miss something, or is this a double conversion?  (i.e., z is
required to convert to a bool, then to a double)  And isn't that
prohibited by everything from Stroustrup's
_The_C++_Programming_Language_ on?

Stroustrup's 2nd edition mentions that "only one level of user-defined
implicit conversion is legal."  Is the kicker here "user-defined", and
what happens if we say that "only one level of implicit conversion is
legal"?  What breaks if we try that?

Slightly confused,
- --
Graham Hughes (graham@resnet.ucsb.edu)  finger for PGP key
``Unix is many things to many people, but it's never been
  everything to anybody.''
Home page at: http://www.cs.ucsb.edu/~ghughes/

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMjt5kSqNPSINiVE5AQHvwwQAoilX2ze3nYoyYdX6nAT/Fd9ludJZT4tW
1mPbACOnNHoitnqgA2ZEXs/f3dZXPjzO+Jmwq4UcF8AJauLMevnWtHww5wKzGLPl
VtJejaV0LB2tIgbOOei4d+fYHEt02sdQAn3F9dCiHRCvZvQi4SVxTWyL9cWk+eHH
QdeAfUmboRM=
=QWxC
-----END PGP SIGNATURE-----


[ 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                             ]

In many classes (smart pointers, for instance), it is useful to define a
true-false mapping--that is, certain states of the class are considered
true, others false.

Client code can then use this relationship in if (and other conditional)
clauses.  It would be useful to be able to do the following:

class foo;
class bar;

void baz ( void )  // I know, my type and variable names are creative...
{
    foo x;
    bar y;

    ...

    if (x)
    {
        ....
    }

    while (!y)
    {
     ...
    }

    for ( x.blah(); !x; x.blech() )
    {
 ...
    }

    int i = y ? 45 : 73;

};

The cases involving the ! operator are easy to deal with safely; just
overload operator !.  The other cases are harder.  One can overload
operator bool, but that opens the door for ALL sorts of side effects--ie
being able to compare a foo to an int (if foo has operator bool, the
compiler will accept this, by casting BOTH the foo and the int to bools).

My suggestion:

Allow overloading of operator if.  This operator shall return a bool,
and shall be called whenever an expression in an if or while clause, or
the second part of a for clause, or the first part of ?: is NOT an
expression of type bool; but shall not be called otherwise (and cannot be
used as a type conversion operator).

In the above example, if foo has operator if overloaded, if ( a ) would
be legal, whereas if (a == 3) would not (unless the equality operator is
overloaded to take an int.)

When an if clause (or one of the others) is encountered, and the
expression is not of type bool, the following should happen:

If the type is a class (or struct or union):
   If operator if is defined for the expression type, call it.
   Else if operator bool is defined for the expression type, call it
   Else, the statement is an error.
If the type is a built-in type or an enum, handle the situation as normal.
(If it's zero, '\0', or null, its false.  Otherwise, it's true.)

Comments?  Is this a solution in need of a problem?


Scott

--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/
---
[ 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
]