In article <40dbd10d$0$559$e4fe514c@news.xs4all.nl>, Jaded Hobo
<omni@scient.net> writes
>In my experience, programmers have a somewhat extended grasp of mathematics.
>Enough at least to
>have been exposed to boolean algebra. Boolean algebra is quite simple: it
>has only three operators
>AND, OR and NOT. There is no addition, multiplication, division, etc. Hence,
>mathematical
>operators that apply to rational numbers don't apply to booleans.

Actually either the NAND or the NOR operator is quite sufficient and
there is no need to spoil oneself with any others:-)

>And as booleans are not integer nor floats, there are numerous possible
>mappings to these types. Just
>look at the ways the TRUE macro was (is) defined before the bool type made
>it into the language:
>
>#define FALSE 0                    //does not say anything about number of
>bits
>#define TRUE ~FALSE
>or
>#define TRUE 1                     //does not say anything about number of
>bits
>
>Thus even when BOOL was an integer, you didn't know what result you would
>get from
>incrementing TRUE.

Yes you did because all non-zero values evaluated as true in both C and
early C++. I suppose there was some remote possibility that TRUE was
defined as -1.

>
>In my opinion bool is not a number and implicit conversion between bool and
>int should even
>be illegal.

Agreed but unfortunately there were two many places in legacy code where
clever sods had written things like:

i += (i < j);

OK I just made that one up. But adding the result of a comparison to an
int was often used. The consequence was that there was no hope of
getting consensus on a bool type devoid of any implicit conversions. We
had to make do with the best we could get. Sometimes one just has to
compromise in order to make progress.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2004-06-18, John Nagle <nagle@animats.com> wrote:
>      Formally, arithmetic for "bool" has the same problems as
> arithmetic for the other types - overflow is undefined.
>
>  short i = 32767;
>  i++;   // undefined behavior

I've only got a copy of one of the drafts to hand , but that didn't
sound right to me so I checked.

AFAICS overflow is defined as it it was casting from a larger integer type,
so is implemenation defined for signed types  according to section 4.7.3,
and is defined to be modulo-2 for unsigned types by section 4.7.2

Which unless I've missed something is closer to what 'most programmers'
expect and doesn't evoked the dreaded undefined clause.

TTFN
--
Roger.                          Home| http://www.sandman.uklinux.net/
Master of Peng Shui.      (Ancient oriental art of Penguin Arranging)
Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/
So what are the eigenvalues and eigenvectors of 'The Matrix'? --anon

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

roger wrote:

> On 2004-06-18, John Nagle <nagle@animats.com> wrote:
>
>>     Formally, arithmetic for "bool" has the same problems as
>>arithmetic for the other types - overflow is undefined.
>>
>> short i = 32767;
>> i++;   // undefined behavior
>
>
> I've only got a copy of one of the drafts to hand , but that didn't
> sound right to me so I checked.
>
> AFAICS overflow is defined as it it was casting from a larger integer type,
> so is implemenation defined for signed types  according to section 4.7.3,
> and is defined to be modulo-2 for unsigned types by section 4.7.2

Overflow is different from, and is not defined in terms of,
casting or conversion. Overflow is explicitly specified to be
undefined behaviour, in 5/5:

"If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable values
for its type, the behavior is undefined, unless such an expression
is a constant expression (5.19), in which case the program is
ill-formed. [Note: most existing implementations of C++ ignore
integer overflows. Treatment of division by zero, forming a remainder
using a zero divisor, and all floating point exceptions vary among
machines, and is usually adjustable by a library function. ]"

And I like to add that, AFAIK the notation "4.7.3" refers to the
section 4.7.3, which does not exist. You meant the 3rd paragraph
of section 4.7, which is usually written as "4.7/3" or "4.7p3".
Please correct me if I'm wrong.

--
Seungbeom Kim

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

roger wrote:
>> short i = 32767;
>> i++;   // undefined behavior
> AFAICS overflow is defined as it it was casting from a larger integer type,
> so is implemenation defined for signed types  according to section 4.7.3,
> and is defined to be modulo-2 for unsigned types by section 4.7.2
>
> Which unless I've missed something is closer to what 'most programmers'
> expect and doesn't evoked the dreaded undefined clause.

5.2.6 1: (about postfix ++) "...After the result is noted, the value of
the object is modified by adding 1 to it,..."

5 5: "If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable values for its
type, the behavior is undefined, unless such an expression is a constant
expression (5.19), in which case the program is illformed."

So the behaviour of overflowing i++ seems indeed undefined also for signed
integer types.

--
------------- Matti Rintala ------------ matti.rintala@tut.fi ------------
If you do not climb you will not fall. This is true. But is it that bad to
fail, that hard to fall? Sometimes you wake, and sometimes, yes, you die.
But there is a third alternative. - from Fear of Falling by Neil Gaiman

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Matti Rintala" <matti.rintala@tut.fi> wrote in message
news:cbabpr$1h4r$1@news.cc.tut.fi...
> roger wrote:
> >> short i = 32767;
> >> i++; // undefined behavior
> > AFAICS overflow is defined as it it was casting from a larger integer
type,
> > so is implemenation defined for signed types  according to section
4.7.3,
> > and is defined to be modulo-2 for unsigned types by section 4.7.2
> >
> > Which unless I've missed something is closer to what 'most programmers'
> > expect and doesn't evoked the dreaded undefined clause.
>
> 5.2.6 1: (about postfix ++) "...After the result is noted, the value of
> the object is modified by adding 1 to it,..."
>
> 5 5: "If during the evaluation of an expression, the result is not
> mathematically defined or not in the range of representable values for
its
> type, the behavior is undefined, unless such an expression is a constant
> expression (5.19), in which case the program is illformed."
>
> So the behaviour of overflowing i++ seems indeed undefined also for
signed
> integer types.

So is this where the buck stops? I just gotta ask: What does undefined
mean? If the standard currently has nothing definitive to say about it
(undefined being defined as no definition) then there is room to discuss
what that definition could be. For instance, what helps programmers to
think in their problem space? What are current usage scenarios? In this
way, we can contribute to the expressiveness of the language.

Within this thread it has been implied that boolean variables are not a
number, but instead their own special type. I assert that perspective
imposes unnecessary limitations upon possible solutions.  Boolean variables
can be thought of as a base-2 number with a range of exactly two values. I
can say BOOL_MAX = 1. Conversions to/from integer types are common
practice, and bitwise comparisons to true/false are also typical usage.

It seems fitting to me that the increment and decrement operators should
function in a manner that is both orthagonal and consistent with integers.

--
AngleWyrm
The C++ hat random selection container:
http://home.comcast.net/~anglewyrm/hat.html

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

AngleWyrm wrote:
> I just gotta ask: What does undefined
> mean? If the standard currently has nothing definitive to say about it
> (undefined being defined as no definition)

The term "undefined" is defined in section 1.3.12 of the C++ standard.
It means that the standard places no requirements on the
implementation, where "no requirements" means that literally any
result (or lack of result) is allowed. For programmers, it means
"don't do that", because you can't necessarily predict what will
happen. Among the likely outcomes of undefined behavior are
- failure to compile
- failure to link
- crash at runtime
- run to completion with a result you did not expect
- run to completion with a result you did expect.

(Sometimes people hyperbolically assert that outcomes can include
reformatting your hard drive, or monkeys flying out of your nose. I
think those outcomes are unlikely.)

>
> Within this thread it has been implied

Actually, I said it outright.

 > that boolean variables are not a
> number, but instead their own special type. I assert that perspective
> imposes unnecessary limitations upon possible solutions.  Boolean variables
> can be thought of as a base-2 number with a range of exactly two values.

Yes, in some other language, perhaps. The definition in C++ is precise.

Type bool has two values, denoted "true" and "false". The words
"bool", "true", and "false" are reserved keywords with predefined and
unchangeable meanings. The values "true" and "false" can be used in
numerical expressions, in which case the value of "true" is converted
to the value 1 and "false" to 0. A boolean object does not have the
value 1 or 0, but only the values "true" or "false".

Reference: C++ standard, section 3.9.1, Fundamental types.

---
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

no_spam_anglewyrm@hotmail.com ("AngleWyrm") wrote in message news:<GLFCc.111712$0y.59368@attbi_s03>...
..
> ... I just gotta ask: What does undefined
> mean?

It means, very simply, that the standard does not define it. Anything
is possible, including a great many things that you'd usually prefer
were NOT possible. In this particular case, on some platforms, signed
integer overflow can cause a hardware exception to occur, which might
abort your program.

If you don't care what your program does, that's not a problem. If
something other than the C++ standard DOES define the behavior that
the C++ standard leave undefined (for instance, the documentation for
the compiler you're using), in an acceptable fashion (for instance, if
your code is only intended for that particular compiler), then that's
not a problem. However, in general, a program which has no constraints
on what it can do is a pretty dangerous thing to write.

In code that is intended to be portable, the fact that a given
construct would have undefined behavior in certain circumstances means
nothing more or less than that it is the developer's responsibility to
make sure that those circumstances are avoided.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In my experience, programmers have a somewhat extended grasp of mathematics.
Enough at least to
have been exposed to boolean algebra. Boolean algebra is quite simple: it
has only three operators
AND, OR and NOT. There is no addition, multiplication, division, etc. Hence,
mathematical
operators that apply to rational numbers don't apply to booleans.
And as booleans are not integer nor floats, there are numerous possible
mappings to these types. Just
look at the ways the TRUE macro was (is) defined before the bool type made
it into the language:

#define FALSE 0                    //does not say anything about number of
bits
#define TRUE ~FALSE
or
#define TRUE 1                     //does not say anything about number of
bits

Thus even when BOOL was an integer, you didn't know what result you would
get from
incrementing TRUE.

In my opinion bool is not a number and implicit conversion between bool and
int should even
be illegal.

Jaded

""AngleWyrm"" <no_spam_anglewyrm@hotmail.com> schreef in bericht
news:GLFCc.111712$0y.59368@attbi_s03...
> "Matti Rintala" <matti.rintala@tut.fi> wrote in message
> news:cbabpr$1h4r$1@news.cc.tut.fi...
> > roger wrote:
> > >> short i = 32767;
> > >> i++; // undefined behavior
> > > AFAICS overflow is defined as it it was casting from a larger integer
> type,
> > > so is implemenation defined for signed types  according to section
> 4.7.3,
> > > and is defined to be modulo-2 for unsigned types by section 4.7.2
> > >
> > > Which unless I've missed something is closer to what 'most
programmers'
> > > expect and doesn't evoked the dreaded undefined clause.
> >
> > 5.2.6 1: (about postfix ++) "...After the result is noted, the value of
> > the object is modified by adding 1 to it,..."
> >
> > 5 5: "If during the evaluation of an expression, the result is not
> > mathematically defined or not in the range of representable values for
> its
> > type, the behavior is undefined, unless such an expression is a constant
> > expression (5.19), in which case the program is illformed."
> >
> > So the behaviour of overflowing i++ seems indeed undefined also for
> signed
> > integer types.
>
> So is this where the buck stops? I just gotta ask: What does undefined
> mean? If the standard currently has nothing definitive to say about it
> (undefined being defined as no definition) then there is room to discuss
> what that definition could be. For instance, what helps programmers to
> think in their problem space? What are current usage scenarios? In this
> way, we can contribute to the expressiveness of the language.
>
> Within this thread it has been implied that boolean variables are not a
> number, but instead their own special type. I assert that perspective
> imposes unnecessary limitations upon possible solutions.  Boolean
variables
> can be thought of as a base-2 number with a range of exactly two values. I
> can say BOOL_MAX = 1. Conversions to/from integer types are common
> practice, and bitwise comparisons to true/false are also typical usage.
>
> It seems fitting to me that the increment and decrement operators should
> function in a manner that is both orthagonal and consistent with integers.
>
> --
> AngleWyrm
> The C++ hat random selection container:
> http://home.comcast.net/~anglewyrm/hat.html
>
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

   Recently I've read somewhere that post-increment and decrement
operator for bool shouldn't be used and is (or is going to be)
deprecated or isn't supported at all. I don't understand why - these
could be implemented like:

bool operator ++ (bool & b, int)
{
   bool ret = b;
   b = true;
   return ret;
}

bool operator -- (bool & b, int)
{
   bool ret = b;
   b = false;
   return ret;
}

This could be very useful, e.g. in situations like this:

bool State = false;

//...

bool StateChangedNow = !(State++);

You wouldn't have to write it like this:

bool StateChangedNow = !State;
State = true;

   I know that it's saving me only one line, but the first version seems
more convinient and obvious to me, and it's also more expressive -
something that C++ is known for. Maybe there are better examples of
using ++ and -- for bool, this is only what I can think of now.
   I'm just wondering why such intuitive and harmless (as it seems to
me) operation is forbidden.

Greetz,
RK

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Robert Kawulak" <tigrisek@interia.pl> wrote in message
news:40D1BE8C.8090605@interia.pl...
>    Recently I've read somewhere that post-increment and decrement
> operator for bool shouldn't be used and is (or is going to be)
> deprecated or isn't supported at all. I don't understand why - these
[clip]
> bool State = false;
> bool StateChangedNow = !(State++);


bool state = false;
bool toggle_active = true;
//...
state ^= toggle_active; // toggle state only if toggle_active is true

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Robert Kawulak" <tigrisek@interia.pl> schreef in bericht
news:40D1BE8C.8090605@interia.pl...
>    Recently I've read somewhere that post-increment and decrement
> operator for bool shouldn't be used and is (or is going to be)
> deprecated or isn't supported at all. I don't understand why - these
> could be implemented like:
>
> bool operator ++ (bool & b, int)
> {
>    bool ret = b;
>    b = true;
>    return ret;
> }
>
> bool operator -- (bool & b, int)
> {
>    bool ret = b;
>    b = false;
>    return ret;
> }
>
[snip]

In my opinion this is counter intuitive. A boolean can only have two states
and has therefore
modulo 2 behaviour. Incrementing the value of a boolean should wrap it
around *not* clip it.

Without seeing you implementation I'd assume that bool++ would turn true
into false and
vice versa (and the same for bool--)

JustAnExampleFunc( bool State )
{
    if ( true == State )
    {
        bool Done = State++; //Done == true, State == false
    }
    else
    {
        bool DoLater = State--; //DoLater == false, State == true
    }
}


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

AngleWyrm
The C++ hat random selection container:
http://home.comcast.net/~anglewyrm/hat.html
""Jaded Hobo"" <omni@scient.net> wrote in message
news:40d2943e$0$568$e4fe514c@news.xs4all.nl...
>
> In my opinion this is counter intuitive. A boolean can only have two
states
> and has therefore modulo 2 behaviour.
> Incrementing the value of a boolean should wrap it
> around *not* clip it.
>
> Without seeing you implementation I'd assume that bool++ would turn true
> into false and
> vice versa (and the same for bool--)
>
> JustAnExampleFunc( bool State )
> {
>     if ( true == State )
>     {
>         bool Done = State++; //Done == true, State == false
           cout << Done << State; // "11" is my output here

I agree; the above implementation does not work as implied; instead the ++
works like ( var |= 1 ), a ceiling function. The increment line compiles,
but the decrement line doesn't compile on my compiler,  ("invalid use of --
on boolean variable"), which I find to be exceedingly bizarre.

Compare that behavior to this behavior for an unsigned int:

#include <limits>
unsigned int i = UINT_MAX;
i++;
cout << i; // i = 0
i--;
cout << i; // i = 4294967295

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

     Formally, arithmetic for "bool" has the same problems as
arithmetic for the other types - overflow is undefined.

 short i = 32767;
 i++;   // undefined behavior

So,

 bool b = true;
 b++;   // undefined behavor

is formally no worse.

But the typical C or C++ programmer doesn't think that way.
It's considered normal to expect integer arithmetic to behave
like unchecked twos-complement integer binary arithmetic.

     The problem for "bool" is that the allowed values don't
usually occupy the entire allocated space.  All random bit
values for "int" are valid.  That's not true of "bool".
So arithmetic can generate values that aren't necessarily meaningful.

     If "++" is disallowed for "bool", it's probably appropriate
to disallow all the arithmetic and bit operations.  Only "==",
"<", ">", "||", "&&", and "!" are guaranteed to return
correct values for "bool".

     It's probably better to disallow arithmetic on "bool" than
to try to create valid semantics for it.

    John Nagle
    Animats
Robert Kawulak wrote:
>   Recently I've read somewhere that post-increment and decrement
> operator for bool shouldn't be used and is (or is going to be)
> deprecated or isn't supported at all.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

AngleWyrm wrote:

> "Robert Kawulak" <tigrisek@interia.pl> wrote in message
> news:40D1BE8C.8090605@interia.pl...
>
>>   Recently I've read somewhere that post-increment and decrement
>>operator for bool shouldn't be used and is (or is going to be)
>>deprecated or isn't supported at all. I don't understand why - these
>
> [clip]
>
>>bool State = false;
>>bool StateChangedNow = !(State++);
>
>
>
> bool state = false;
> bool toggle_active = true;
> //...
> state ^= toggle_active; // toggle state only if toggle_active is true

     That won't do what you expect.

     "^" is a bitwise operator.  What that really does is this:

 int temp1 = toggle_active ? 1 : 0; // per 4.5.4 of std.
 int temp2 = ^temp1;  // turns 0 into 0xffffffff
     // turns 1 into 0xfffffffe
     // temp2 is always nonzero
 toggle_active = (temp2 != 0);  // per 4.12 of std
     // toggle_active is true

The result is thus always "true".

You need to write

 toggle_active = !toggle_active;

This sort of thing is a good reason to disallow
arithmetic operations on "bool".


     John Nagle
     Animats

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

     Sorry, that's not quite right.  There is no unary "^".

Let's write out all the conversions and temporaries here.


 // state ^= toggle_active
 int istate0 = state ? 1 : 0;  // bool to int
 int itoggle_active= toggle_active ? 1 : 0; // bool to int
 int istate1 = istate0 ^ itoggle_active; // bitwise XOR
 state = (istate1 != 0);   // int to bool

So if state = true and toggle_active = true, then

 istate0 = 1
 itoggleactive = 1
 istate1 = 0xfffffffe
 state = true

which wasn't what was intended.

    John Nagle
    Animats

John Nagle wrote:

> AngleWyrm wrote:
>
>> "Robert Kawulak" <tigrisek@interia.pl> wrote in message
>> news:40D1BE8C.8090605@interia.pl...
>>
>>>   Recently I've read somewhere that post-increment and decrement
>>> operator for bool shouldn't be used and is (or is going to be)
>>> deprecated or isn't supported at all. I don't understand why - these
>>
>>
>> [clip]
>>
>>> bool State = false;
>>> bool StateChangedNow = !(State++);
>>
>>
>>
>>
>> bool state = false;
>> bool toggle_active = true;
>> //...
>> state ^= toggle_active; // toggle state only if toggle_active is true
>
>
>     That won't do what you expect.
>
>     "^" is a bitwise operator.  What that really does is this:
>
>     int temp1 = toggle_active ? 1 : 0; // per 4.5.4 of std.
>     int temp2 = ^temp1;        // turns 0 into 0xffffffff
>                     // turns 1 into 0xfffffffe
>                     // temp2 is always nonzero
>     toggle_active = (temp2 != 0);     // per 4.12 of std
>                     // toggle_active is true
>
> The result is thus always "true".
>
> You need to write
>
>     toggle_active = !toggle_active;
>
> This sort of thing is a good reason to disallow
> arithmetic operations on "bool".
>
>
>                     John Nagle
>                     Animats
>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Seems to be a lot of guessing, for a newsgroup that is supposed to be
about the C++ standard. Here is what the standard says in 5.3.2
Increment and decrement:

-------------------------------------------------------------------
The operand of prefix ++ is modified by adding 1, or set to true if
it is bool (this use is deprecated).
..
The operand of prefix -- is modified by subtracting 1. The operand
shall not be of type bool.
-------------------------------------------------------------------

The wording for postfix is similar.

The reason why increment is deprecated is because the result is not
very intuitive. The reason why decrement is disallowed is because it
has no obvious meaning, particularly when the operand is false.

Remember: bool is not a signed or unsigned type. It is its own unique
type. Bool objects can be converted to an integer value.

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


AngleWyrm wrote:
> AngleWyrm
> The C++ hat random selection container:
> http://home.comcast.net/~anglewyrm/hat.html
> ""Jaded Hobo"" <omni@scient.net> wrote in message
> news:40d2943e$0$568$e4fe514c@news.xs4all.nl...
>
>>In my opinion this is counter intuitive. A boolean can only have two
>
> states
>
>>and has therefore modulo 2 behaviour.
>>Incrementing the value of a boolean should wrap it
>>around *not* clip it.
>>
>>Without seeing you implementation I'd assume that bool++ would turn true
>>into false and
>>vice versa (and the same for bool--)
>>
>>JustAnExampleFunc( bool State )
>>{
>>    if ( true == State )
>>    {
>>        bool Done = State++; //Done == true, State == false
>
>            cout << Done << State; // "11" is my output here
>
> I agree; the above implementation does not work as implied; instead the ++
> works like ( var |= 1 ), a ceiling function. The increment line compiles,
> but the decrement line doesn't compile on my compiler,  ("invalid use of --
> on boolean variable"), which I find to be exceedingly bizarre.
>
> Compare that behavior to this behavior for an unsigned int:
>
> #include <limits>
> unsigned int i = UINT_MAX;
> i++;
> cout << i; // i = 0
> i--;
> cout << i; // i = 4294967295
>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> But the typical C or C++ programmer doesn't think that way.
> It's considered normal to expect integer arithmetic to behave
> like unchecked twos-complement integer binary arithmetic.
>

  That's right, and I think this attitude is quite inappropriate when
concerning bool. Bool is NOT yet another arithmetic type with values 0 & 1,
it's a completely distinct type with values false & true. And I agree that
there should't be two sets of operators for bool (arithmetic and boolean),
and also implicit conversion of bool to integer and arithmetic operations on
it shold be forbidden.
  However, the ++ & -- could be an exception. What I've got in mind is to
create bool (not to reuse the int version of) operators ++ and --. Not
because they are essential, but because they're convinient. I think that
'post' operators would be very useful, just as their arithmetic
counterparts - they set a new value, while returning old one. Several times
it happened that I needed such feature but had to do a workaround, that's
why I think it might be useful.

Greetz,
RK


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>      Sorry, that's not quite right.  There is no unary "^".
>
> Let's write out all the conversions and temporaries here.
>
>
> // state ^= toggle_active
> int istate0 = state ? 1 : 0; // bool to int
> int itoggle_active= toggle_active ? 1 : 0; // bool to int
> int istate1 = istate0 ^ itoggle_active; // bitwise XOR
> state = (istate1 != 0); // int to bool
>
> So if state = true and toggle_active = true, then
>
> istate0 = 1
> itoggleactive = 1
> istate1 = 0xfffffffe

This is incorrect.  000...001 ^ 000...001 == 000...000 no matter how many
bits you use.

> state = true

state = false, which is what was intended.

-cd

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:GKGAc.74599$kq6.8573@newssvr29.news.prodigy.com...
>  Formally, arithmetic for "bool" has the same problems as
> arithmetic for the other types - overflow is undefined.

> short i = 32767;
> i++; // undefined behavior

> So,

> bool b = true;
> b++; // undefined behavor

> is formally no worse.
> But the typical C or C++ programmer doesn't think that way.

The typical C or C++ compiler doesn't seem to think that way either.
On my system, performing the above example lines:

  short i = 32767;
  i++;
  cout << i; // result = -32768 on my system

results in wrap-around, just the same as the UINT_MAX example of the
previous post. Does this seem like "normal" behavior to you?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

The C++ hat random selection container:
http://home.comcast.net/~anglewyrm/hat.html
"John Nagle" <nagle@animats.com> wrote in message
news:kZGAc.74603$rv6.62506@newssvr29.news.prodigy.com...

> > bool state = false;
> > bool toggle_active = true;
> > //...
> > state ^= toggle_active; // toggle state only if toggle_active is true
>
>      That won't do what you expect.
>      "^" is a bitwise operator.  What that really does is this:

Have you tried running the above code? It seems to perform as advertised.

state  toggle   XOR
=================
true    false     true  // if toggle false, then state = state
false   false     false // "

true    true      false // if toggle=true, then state = !state
false   true      true  // "

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

stephen.clamage@sun.com (Steve Clamage) writes:

| Remember: bool is not a signed or unsigned type.

which gets us to what numeric_limits<bool>::is_signed should mean :-)

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>     Sorry, that's not quite right.  There is no unary "^".
>
> Let's write out all the conversions and temporaries here.
>
>
>     //    state ^= toggle_active
>     int istate0 = state ? 1 : 0;        // bool to int
>     int itoggle_active= toggle_active ? 1 : 0;    // bool to int
>     int istate1 = istate0 ^ itoggle_active;    // bitwise XOR
>     state = (istate1 != 0);            // int to bool
>
> So if state = true and toggle_active = true, then
>
>     istate0 = 1
>     itoggleactive = 1
>     istate1 = 0xfffffffe
>     state = true
>
> which wasn't what was intended.

Sorry, but that's not quite right either. 1 ^ 1 gives 0, not 0xfffffffe,
so the result is

   istate0 = 1
   itoggleactive = 1
   istate1 = 0
   state = false

which is indeed what was intended.

Alberto

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]