In article <9335215.19883@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

> Is there really this difference between user defined conversions and
> standard conversions?  If b + b is legal, can s + s really be illegal
> as most compilers seem to claim?  If s + s is legal, couldn't we
> make b + b illegal in the same way?  (Not that this is necessarily
> a good idea - I just want to understand the rationale.)

I guess I'd better explain give an example of integral promotions.

Example 1:

 void f(short);
 void f(long);

 main()
 {
  f('a'); // error -- ambiguous
 }


Example 2:

 void g(short);
 void g(int);
 void g(long);

 main()
 {
  g('a'); // g(int)
 }


Example 3:

 void h(char);
 void h(short);
 void h(int);
 void h(long);

 main()
 {
  h('a'); // h(char)
 }

What's going on here?

The answer lies in a rule inherited from C: if you use an integral type
shorter than int in a situation that does not require a value of exactly
that type, it is promoted to int without further thought.  Thus,
'a' matches h(char) exactly, but because g(char) is not defined, 'a'
matches g(int) (and not g(short)).  Moreover, 'a' has no preference
between f(short) and f(long), even though one might think short to be a
better match for char than long.

That means that operators like + aren't defined on types like short and char
at all -- those types are instantly promoted to int and you take it from
there.

Now of course it would be possible to `define' + on bool operands to
say it's an error.  That would require changing the definition of
every arithmetic operator, which is a much more radical change than saying
that bool values promote to int.

Yes it could be done, but it is far from clear that the committee would
have accepted it.
--
    --Andrew Koenig
      ark@research.att.com

linh@info.polymtl.ca (Linh Minh Hong Dang) writes:

>Careful C++ programmer don't use
>            NULL
>they use    0

Nonsense.  There are plenty of careful C++ programmers that use NULL.

>They don't use neither typedef int bool nor enum bool {..}
>they use    `int' directly

Also nonsense.

--
Fergus Henderson        |   "People who brook no compromise in programming
                        |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU   |   machine language, depending." --Andrew Koenig.

I have half heartedly followed this thread and wish to add my two cents
worth.

Firstly, regarding the issue of breaking code, it would appear to me to
be impossible to break existing code, since, by definition, none using
the new feature can exist.  The worst thing that could happen would be a
naming conflict.

As to the behaviors of the operators, it seems to be that we should use
the approach of "what makes sense" and not "what is possible".  Thus:

  bool b;
  b++;

It might be possible to assign this a toggle function, but does it make
sense.  If 10 C++ experts were asked what does b++ mean, given that b is
a bool, would they all come up with the same answer?  I doubt it.
But, consider:

  int i;
  bool b = i;

I suspect that all those same 10 people would say that this should be
the same as:

  b = ( i == 0 ) ? false : true;

and the same argument can be applied to floats and pointers etc, since
we all understand current code that says:

  void *p;
  if ( p ) // etc

Similarly, I think we would all agree what AND, OR, XOR, NOT, etc means
on a boolean variable, but could we agree on what +, -, *, / mean?  Sure
we could assign meaning, but is it worth it, since at best it would only
duplicate some existing logical operation.

Kevin Hopps, in an earlier article submitted that the effect of all
operators on type bool needed to be defined, and Fergus Henderson
responded that it was ridiculous, and subsequently retracted the word
ridiculous.  But surely both are right.  I do want to know precisely
what action should be taken by a compiler given any operator, but it
also makes sense for some operations to be declared illegal on type
bool.

Despite the controversy, I think that a boolean type would be an asset.
In so many situations, integers are used as boolean variables and then
people get smart and do "clever" arithmetic on them to yield desired
results.  This kind of code can be difficult to maintain.  A simple
boolean that can only be assigned the value true or false would stop
this.

Martin Horton - Fort Worth, Texas 12/13/93 21:03
Internet:
Personal:  Martin.Horton@Chrysalis.org
Business:  Z5319@aa1profs.ibmmail.com

In article <9312150324.A4390wk@chrysalis.org> martin.horton@chrysalis.org writes:

> Firstly, regarding the issue of breaking code, it would appear to me to
> be impossible to break existing code, since, by definition, none using
> the new feature can exist.  The worst thing that could happen would be a
> naming conflict.

Indeed -- but if that name conflict is first noticed in, say,

 typedef int bool;

it would be nice to be able simply to remove the offending typedef.

> As to the behaviors of the operators, it seems to be that we should use
> the approach of "what makes sense" and not "what is possible".  Thus:

>   bool b;
>   b++;

> It might be possible to assign this a toggle function, but does it make
> sense.  If 10 C++ experts were asked what does b++ mean, given that b is
> a bool, would they all come up with the same answer?  I doubt it.

If they were asked what does b++ mean, given that b is an int used as
a bool, I suspect they would all indeed come up with the same answer.
Thus we preserve that well-known behavior as a transition aid, while
reserving the right to prohibit it eventually.  Programming language
standards have a finite lifetime, remember.

> But, consider:

>   int i;
>   bool b = i;

> I suspect that all those same 10 people would say that this should be
> the same as:

>   b = ( i == 0 ) ? false : true;

> and the same argument can be applied to floats and pointers etc, since
> we all understand current code that says:

>   void *p;
>   if ( p ) // etc

Exactly.

> Similarly, I think we would all agree what AND, OR, XOR, NOT, etc means
> on a boolean variable, but could we agree on what +, -, *, / mean?  Sure
> we could assign meaning, but is it worth it, since at best it would only
> duplicate some existing logical operation.

The point is that built-in operators like < and && today are defined
as yielding 0 or 1 and programs are entitled to take advantage of that
behavior.  Thus, for instance,

 int sign = (x > 0) - (x - 0);

sets `sign' to -1 if x<0, 0 if x==0, and 1 if x>0.  Since this behavior
is well-defined today, that is a strong argument for preserving it, which
can most expeditiously be done by defining bool->int conversion to
map false to 0 and true to 1.  By implication, that defines +, *, etc.
on booleans.  They may not be terribly useful, but at least code
won't break.

> Kevin Hopps, in an earlier article submitted that the effect of all
> operators on type bool needed to be defined, and Fergus Henderson
> responded that it was ridiculous, and subsequently retracted the word
> ridiculous.  But surely both are right.  I do want to know precisely
> what action should be taken by a compiler given any operator, but it
> also makes sense for some operations to be declared illegal on type
> bool.

Yes.  For instance, --.  It's possible to prohibit -- because no conversions
are applied to its argument.  It is much hard to prohibit things like *,
because it would require additional special cases to rule out conversions
that are automatic in all other contexts.

> Despite the controversy, I think that a boolean type would be an asset.
> In so many situations, integers are used as boolean variables and then
> people get smart and do "clever" arithmetic on them to yield desired
> results.  This kind of code can be difficult to maintain.  A simple
> boolean that can only be assigned the value true or false would stop
> this.

If enough people feel that way, compiler vendors will produce warnings.
--
    --Andrew Koenig
      ark@research.att.com

ark@alice.att.com (Andrew Koenig) writes:

>It's possible to prohibit -- because no conversions
>are applied to its argument.  It is much hard to prohibit things like *,
>because it would require additional special cases to rule out conversions
>that are automatic in all other contexts.

Would it?  Consider the following code:

 class String {
  String(const char *);
 };

 String operator +(String, String);
 // int operator +(int, int); (builtin)

 void foo() {
  bool b = false;
  const char *s = "hello ";

  s + s; // illegal (user defined conversion not invoked) ?
  b + b; // legal (standard conversion invoked) ?
 }

Is there really this difference between user defined conversions and
standard conversions?  If b + b is legal, can s + s really be illegal
as most compilers seem to claim?  If s + s is legal, couldn't we
make b + b illegal in the same way?  (Not that this is necessarily
a good idea - I just want to understand the rationale.)

--
Fergus Henderson |   "People who brook no compromise in programming
   |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU |   machine language, depending." --Andrew Koenig.

Andrew Koenig (ark@alice.att.com) wrote:
: In article <9312150324.A4390wk@chrysalis.org> martin.horton@chrysalis.org writes:

: > Firstly, regarding the issue of breaking code, it would appear to me to
: > be impossible to break existing code, since, by definition, none using
: > the new feature can exist.  The worst thing that could happen would be a
: > naming conflict.

: Indeed -- but if that name conflict is first noticed in, say,

:  typedef int bool;

Careful C++ programmer don't use
            NULL
they use    0

They don't use neither typedef int bool nor enum bool {..}
they use    `int' directly

So there will be no breaking of GOOD code
BAD code deserves to be BROKEN


LD

: it would be nice to be able simply to remove the offending typedef.

: > As to the behaviors of the operators, it seems to be that we should use
: > the approach of "what makes sense" and not "what is possible".  Thus:

: >   bool b;
: >   b++;

: > It might be possible to assign this a toggle function, but does it make
: > sense.  If 10 C++ experts were asked what does b++ mean, given that b is
: > a bool, would they all come up with the same answer?  I doubt it.

: If they were asked what does b++ mean, given that b is an int used as
: a bool, I suspect they would all indeed come up with the same answer.
: Thus we preserve that well-known behavior as a transition aid, while
: reserving the right to prohibit it eventually.  Programming language
: standards have a finite lifetime, remember.

: > But, consider:

: >   int i;
: >   bool b = i;

: > I suspect that all those same 10 people would say that this should be
: > the same as:

: >   b = ( i == 0 ) ? false : true;

: > and the same argument can be applied to floats and pointers etc, since
: > we all understand current code that says:

: >   void *p;
: >   if ( p ) // etc

: Exactly.

: > Similarly, I think we would all agree what AND, OR, XOR, NOT, etc means
: > on a boolean variable, but could we agree on what +, -, *, / mean?  Sure
: > we could assign meaning, but is it worth it, since at best it would only
: > duplicate some existing logical operation.

: The point is that built-in operators like < and && today are defined
: as yielding 0 or 1 and programs are entitled to take advantage of that
: behavior.  Thus, for instance,

:  int sign = (x > 0) - (x - 0);

: sets `sign' to -1 if x<0, 0 if x==0, and 1 if x>0.  Since this behavior
: is well-defined today, that is a strong argument for preserving it, which
: can most expeditiously be done by defining bool->int conversion to
: map false to 0 and true to 1.  By implication, that defines +, *, etc.
: on booleans.  They may not be terribly useful, but at least code
: won't break.

: > Kevin Hopps, in an earlier article submitted that the effect of all
: > operators on type bool needed to be defined, and Fergus Henderson
: > responded that it was ridiculous, and subsequently retracted the word
: > ridiculous.  But surely both are right.  I do want to know precisely
: > what action should be taken by a compiler given any operator, but it
: > also makes sense for some operations to be declared illegal on type
: > bool.

: Yes.  For instance, --.  It's possible to prohibit -- because no conversions
: are applied to its argument.  It is much hard to prohibit things like *,
: because it would require additional special cases to rule out conversions
: that are automatic in all other contexts.

: > Despite the controversy, I think that a boolean type would be an asset.
: > In so many situations, integers are used as boolean variables and then
: > people get smart and do "clever" arithmetic on them to yield desired
: > results.  This kind of code can be difficult to maintain.  A simple
: > boolean that can only be assigned the value true or false would stop
: > this.

: If enough people feel that way, compiler vendors will produce warnings.
: --
:     --Andrew Koenig
:       ark@research.att.com