Michael Kilburn wrote:
>>>
>>> bool func() {...}
>>> bool b &= func();
>>
>> The fundamental problem here is that you are declaring b. &= is not
>> allowed at that point in a declaration.
>
> Of course, I did a mistake -- if you check subject I actually meant:

You should never keep important information in the subject line. The
subject should be a summary of the message contents; it shouldn't be
treated as an extra place to store information that should have been
in the message itself.

> bool func() {...}
> bool b =...;
> b &= func();
>
>
>> Therefore, what the '&' operator actually acts on are values of type int
>> promoted from the original 'bool' operands. Therefore, the
>> representation of 'bool' is irrelevant; all that's relevant is the
>> representation of int values of either 0 or 1.
>
> Yep, I know about that. But it did not answer question I tried to ask
> so clumsily :-)

Perhaps it didn't seem to, but it does. In fact, I tried to write my
answer in such a way as to make it clear that it did apply to this.
Semantically, b &= func() is identical to  b = b & func(), so my
detailed discussion of b&func() gave you precisely the answer you
needed.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> Semantically, b &= func() is identical to  b = b & func(), so my
> detailed discussion of b&func() gave you precisely the answer you
> needed.

So you think that integral promotions apply here? I.e.:
b &= func() -> b = b & func() -> b = to_bool( to_int(b) & to_int(func
()) ) ?

But according to my understanding integral promotions are executed
only when necessary, i.e. when argument types different from what
expressions expects. bool is an integral type (and this is what
bitwise 'AND' expects) -- why integral promotions should be used here?

Michael.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Michael Kilburn wrote:
>> Semantically, b &= func() is identical to  b = b & func(), so my
>> detailed discussion of b&func() gave you precisely the answer you
>> needed.
>
> So you think that integral promotions apply here? I.e.:
> b &= func() -> b = b & func() -> b = to_bool( to_int(b) & to_int(func
> ()) ) ?
>
> But according to my understanding integral promotions are executed
> only when necessary, i.e. when argument types different from what
> expressions expects. ...

That's not how the standard describes things. When the "usual arithmetic
conversions" are called for, the integral promotions always apply to any
integral operands, unless the other operand has a floating point type.

There is no single "expected" type for the operands of any given
operator. There are type limitations on the operands (many operators are
only meaningful on integer operands, for instance), but there are no
operators that expect only a single type for any of their operands.

The binary <<, >> operators perform the "integral promotions" on their
operands. Most other binary operations call for the "usual arithmetic
conversions" to occur, which include the "integral promotions". This is
true of binary *, /, %, &, ^, and |. It's also true of binary +, -, <,
  >, <=, >= when operating on types of arithmetic or enumeration type.
This also applies to the corresponding compound assignment operators,
since their behavior is defined in terms of the behavior of the simple
binary operator.

As a result, none of those operations ever 'expects' to operate on an
integral type whose corresponding promoted type differs from the type
itself.

Therefore, in the sense that you use the term above, binary '&' could be
described as "expecting" that it's operands will have a integral type of
rank greater than or equal to 'int'.

> ... bool is an integral type (and this is what
> bitwise 'AND' expects) -- why integral promotions should be used here?

The general idea, inherited from C, is that 'int' is the natural integer
type for any given platform, the one that it is most convenient for
carrying out operations in. As a result, in all of the cases describe
above, integral types of rank lower than int get promoted before
operations are performed.

In practice, in any case where you could not tell the difference whether
or not a given integral type had been promoted, an implementation is
always free to perform the arithmetic using the unpromoted type, if it
wishes, though this is only likely to happen if the platform has direct
hardware support for arithmetic on the smaller type.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

THIS ARTICLE IS ONLY ABOUT HOW TO POST TO CSC++.

* Michael Kilburn:
> why integral promotions should be used here?

1. James Kuyper answered your latest question in his first reply in this
     thread. Do read before asking again  --  and again, and again. You're
     wasting everyone's time.

2. As James Kuyper remarked earlier, "You should never keep important
     information [only] in the subject line". You're wasting everyone's
time.

3. Above you're quoting James Kuyper. I had to go back in the thread to
     find out that. Always indicate whom you're quoting. You're wasting
     everyone's time.

Thank you for fixing this in the future,

- Alf

--
Due to hosting requirements I need visits to [http://alfps.izfree.com/].
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 3, 5:17 pm, Michael Kilburn <crusader.m...@gmail.com> wrote:
> > Semantically, b &= func() is identical to  b = b & func(), so my
> > detailed discussion of b&func() gave you precisely the answer you
> > needed.

> So you think that integral promotions apply here? I.e.:
> b &= func() -> b = b & func() -> b = to_bool( to_int(b) & to_int(func
> ()) ) ?

> But according to my understanding integral promotions are
> executed only when necessary, i.e. when argument types
> different from what expressions expects. bool is an integral
> type (and this is what bitwise 'AND' expects) -- why integral
> promotions should be used here?

Most operators expect int as the smallest type---the binary
operators & and | aren't defined for bool (or char, or short),
for example.  See    5/9.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi,

Is this code correct:

bool func() {...}
bool b &= func();

To my understanding operator &= is defined for integral types and
therefore (because bool is an integral type) -- valid. But I could not
find a place in standard that could guarantee me that 'false' is 0 in
binary representation.

Michael.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Michael Kilburn wrote:
> Hi,
>
> Is this code correct:
>
> bool func() {...}
> bool b &= func();
>
> To my understanding operator &= is defined for integral types and
> therefore (because bool is an integral type) -- valid. But I could not
> find a place in standard that could guarantee me that 'false' is 0 in
> binary representation.

The fundamental problem here is that you are declaring b. &= is not
allowed at that point in a declaration. An initializer can only start
with '=', '(' or '{'.  Compound assignment operators are not allowed. It
should be easy to see why: the expression b &= func() is equivalent to b
= b & func(). Therefore, the result of that expression depends upon the
prior value of 'b'.  But at this point in initialization, 'b' doesn't
have a prior value.

However, it seems that you're really worried about just the expression
b&func(). 5.11p1 says that the "usual arithmetic conversions" are
performed on the operands of the '&' operator before the operations
continues. 5p10 says that this will result in the "integral promotions"
to be applied. Under the section on "integral promotions", section 4.5p4
says that "An rvalue of type bool can be converted to an rvalue of type
int, with false becoming zero and true becoming one."

Therefore, what the '&' operator actually acts on are values of type int
promoted from the original 'bool' operands. Therefore, the
representation of 'bool' is irrelevant; all that's relevant is the
representation of int values of either 0 or 1.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> > bool func() {...}
> > bool b &= func();
>
> The fundamental problem here is that you are declaring b. &= is not
> allowed at that point in a declaration.

Of course, I did a mistake -- if you check subject I actually meant:

bool func() {...}
bool b =...;
b &= func();


> Therefore, what the '&' operator actually acts on are values of type int
> promoted from the original 'bool' operands. Therefore, the
> representation of 'bool' is irrelevant; all that's relevant is the
> representation of int values of either 0 or 1.

Yep, I know about that. But it did not answer question I tried to ask
so clumsily :-)

Michael.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]