Topic: Is it legal to use ++ to set a bool *REFERENCE* to true?
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/24 Raw View
Paul D. DeRocco wrote:
>
> AllanW@my-dejanews.com wrote:
[...]
> > Actually, I kind of like the idea of finally inventing a logical-XOR
> > operator.
>
> But you've correctly noted that != is an XOR if its parameters are both
> bools. And XNOR is just as commonly needed as XOR, so why invent two
> operators when we already have != and ==?
Because == and != (obviously) don't have an implicit cast to bool?
[...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/06/24 Raw View
AllanW@my-dejanews.com writes:
>In article <6mecab$4fj@engnews1.Eng.Sun.COM>,
> clamage@Eng.Sun.COM (Steve Clamage) wrote:
>> The next step was defining semantics for operations on type bool.
>> The only operations that didn't have obvious semantics were ++
>> and --. Since those operations do not have an obvious meaning
>> for a boolean type, the choices were to disallow them or provide
>> semantics.
>What are the obvious semantics for:
> operator / -- What's the value of false/true, and is true/false legal
> operator % -- What's the value of false%true, and is true%false legal
> operator * -- Same as operator &&, I suppose
> operator + -- Same as operator ||, even though 1+1=2, still non-zero
> operator - -- Possibly a logical (not bitwise) XOR
> operator ^ -- Are there bitwise operators for data types which
> conceptually have only one bit
> operator & -- Same question, or is this same as operator &&
> operator | -- Same question, or is this same as operator ||
> operator != -- Yet a third candidate for logical XOR
> operator ~ -- Bitwise negation, or same as operator !
> sizeof -- Always same as sizeof(char), or could it be larger
>How much of the above is defined by FDIS?
Except for sizeof, those operations cannot be performed on type bool.
Sizeof, as always, returns the number of bytes the implemention
uses for an object of type bool. In the following discussion,
I omit "sizeof" from consideration.
If you apply any of those operators to a boolean value, the value
is first promoted to int, and the result is type int, not type
bool. (The same is true of enums, except that the promoted type
isn't necessarily int for an enum.) Notice that the promotion
also occurs for == as well as for !=.
(Lest anyone be concerned about runtime efficiency, the "as-if"
rule always applies. The bool values don't need to be extended
to int types at run time as long as the result of an expression
is the same. The C++ standard defines the semantic result, not
code which must be generated.)
The ++ and -- operators are special, because they compute a new
value and assign it to the operand, which must be an lvalue.
(None of the above operations require an lvalue.)
The ++ and -- operators are not defined for enums. If you write
++enum_variable
you get a compile-time error, unless you provide your own
overloaded operator++.
The question was whether also to disallow ++ and -- for bool, or
to provide semantics. As Pete Becker has pointed out, it is
common in existing code to use ++ on pseudo-boolean variables, so
the committee somewhat reluctantly decided to define semantics
for the that operator.
>So what is operator-- defined to do?
It is disallowed for type bool. The expressions --b and b-- are
errors if b is a bool. I misspoke earlier when I implied the
operations were defined. You cannot provide an overloaded unary
operator on arithmetic types (bool is arithmetic), so you cannot
provide your own overloaded operator-- for type bool.
Draft standard references:
3.9.1 Fundamental types
5.2.6 Increment and decrement
5.3.2 Increment and decrement
5.10 Equality operators
13.5 Overloaded operators
--
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/06/24 Raw View
In article <6mm72f$r7c$1@nnrp1.dejanews.com>, <AllanW@my-dejanews.com> wrote:
> In article <6mecab$4fj@engnews1.Eng.Sun.COM>,
> clamage@Eng.Sun.COM (Steve Clamage) wrote:
> > The next step was defining semantics for operations on type bool.
> > The only operations that didn't have obvious semantics were ++
> > and --. Since those operations do not have an obvious meaning
> > for a boolean type, the choices were to disallow them or provide
> > semantics.
> What are the obvious semantics for:
> operator / -- What's the value of false/true, and is true/false legal
> operator % -- What's the value of false%true, and is true%false legal
> operator * -- Same as operator &&, I suppose
> operator + -- Same as operator ||, even though 1+1=2, still non-zero
> operator - -- Possibly a logical (not bitwise) XOR
> operator ^ -- Are there bitwise operators for data types which
> conceptually have only one bit
> operator & -- Same question, or is this same as operator &&
> operator | -- Same question, or is this same as operator ||
> operator != -- Yet a third candidate for logical XOR
> operator ~ -- Bitwise negation, or same as operator !
> sizeof -- Always same as sizeof(char), or could it be larger
> How much of the above is defined by FDIS?
All of them. In general, bool values in expressions convert to int,
with false mapping to 0 and true to 1. So false/true means the
same as 0/1 and true/false means the same as 1/0.
sizeof(bool) is whatever it is. It is not required to be equal to sizeof(char),
but cannot be less (because sizeof(char) is always 1).
> Much of the above nonsense can be supported on purely esthetic grounds,
Maybe, maybe not. But what can be supported is that the expression (3<4)+(4<5)
has a well-defined value in C, and it would be nice if it had the same value
in C++.
> But does operator-- always set the bool to false? Does it toggle it? Does
> it always set the bool to true? I could invent sample BOOL-ALIAS code to
> justify any one of these choices, each time making the other two look
> completely wrong. But all I would really accomplish is to acknowledge that
> the standards committee had an almost impossible task, something I think
> most of us already realized.
> So what is operator-- defined to do?
It's not allowed, precisely because it's hard to figure out what it should mean.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/06/23 Raw View
In article <6mecab$4fj@engnews1.Eng.Sun.COM>,
clamage@Eng.Sun.COM (Steve Clamage) wrote:
> The next step was defining semantics for operations on type bool.
> The only operations that didn't have obvious semantics were ++
> and --. Since those operations do not have an obvious meaning
> for a boolean type, the choices were to disallow them or provide
> semantics.
What are the obvious semantics for:
operator / -- What's the value of false/true, and is true/false legal
operator % -- What's the value of false%true, and is true%false legal
operator * -- Same as operator &&, I suppose
operator + -- Same as operator ||, even though 1+1=2, still non-zero
operator - -- Possibly a logical (not bitwise) XOR
operator ^ -- Are there bitwise operators for data types which
conceptually have only one bit
operator & -- Same question, or is this same as operator &&
operator | -- Same question, or is this same as operator ||
operator != -- Yet a third candidate for logical XOR
operator ~ -- Bitwise negation, or same as operator !
sizeof -- Always same as sizeof(char), or could it be larger
How much of the above is defined by FDIS?
Much of the above nonsense can be supported on purely esthetic grounds,
which have nothing to do with the practical idea of generating readable,
maintainable, bug-free programs. In non-computer boolean mathematics,
the "or" operator often has the same notation as plus, and the "and"
operation often has the same notation as times. Which is almost
consistent with the Computer Science view of 0=false and 1=true --
except that 1+1=2, so it all works if 1 compares equal to 2. Also,
logical XOR is usually a plus with a circle around it; but since there's
no keyboard key for that, I could justify using a minus sign for the same
reason that plus works for inclusive-or.
Actually, I kind of like the idea of finally inventing a logical-XOR
operator. Almost every other language has it; not that they use it
every month, but I don't think they consider it a source of great
overhead when they're not using it. As classic C++ stands, it's just
too easy for a less-than expert programmer (or an expert on a bad day)
to use bitwise XOR when she meant logical XOR, and not realize it until
a space shuttle veers in the wrong direction...
> As a compromise, the committee chose to provide semantics but
> deprecate their use. If experience shows that ++ and -- are useful
> operations for booleans, they can be left in the language (and the
> deprecation removed). If it turns out, as I think it will, that ++
> and -- really make no sense, the operations can be removed from the
> next version of the standard.
My understanding is that the rationale behind supporting operator++
was to allow code like this:
typedef int BOOL;
enum { FALSE, TRUE };
BOOL found = FALSE;
// ...
for (int i=0; i<sizeof(x)/sizeof(x[0]); ++i)
if (x[i]==123) ++found;
if (found) // ...
to be translated into this:
bool found = FALSE;
// ...
for (int i=0; i<sizeof(x)/sizeof(x[0]); ++i)
if (x[i]==123) ++found;
if (found) // ...
That's good thinking, and I applaud the standards committee for thinking
about it. I probably wouldn't have thought of it myself, since I
personally don't code this way, and like many others, I have a nasty habit
of thinking with my ego -- if I don't code this way, then neither does
anyone else.
[ [ Don't laugh -- it seems quite reasonable in my head, and doesn't really
look rediculous until it's in black and white. I bet some of you have the
same problem, even if you don't know it. ] ]
But does operator-- always set the bool to false? Does it toggle it? Does
it always set the bool to true? I could invent sample BOOL-ALIAS code to
justify any one of these choices, each time making the other two look
completely wrong. But all I would really accomplish is to acknowledge that
the standards committee had an almost impossible task, something I think
most of us already realized.
So what is operator-- defined to do?
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/06/23 Raw View
AllanW@my-dejanews.com wrote:
>
> What are the obvious semantics for:
>
> operator * -- Same as operator &&, I suppose
> operator + -- Same as operator ||, even though 1+1=2
These should produce the correct answers when stored back into a bool,
but without the short-circuit evaluation guaranteed by && and ||.
> operator ^ -- Are there bitwise operators for data types which
> conceptually have only one bit
> operator & -- Same question, or is this same as operator &&
> operator | -- Same question, or is this same as operator ||
They are all bitwise, and in my view the standard guarantees that they
work as expected. But again, they are not the same as && and ||, because
of the lack of short-circuit evaluation.
> operator != -- Yet a third candidate for logical XOR
Yes, it should work, although the original post showed a VC++ code
generator bug that prevented it from working when two different integers
were converted to bool and then compared, in the context of an inline
member function.
> operator ~ -- Bitwise negation, or same as operator !
I don't think this works, because true will be promoted to 1, which (on
a two's complement machine) will complement to the bit pattern of -2,
which is still true.
> sizeof -- Always sizeof(char), or could it be larger
Yes, it can be larger, although on any byte-addressed machine, I'd be
irritated if it was.
> Much of the above nonsense can be supported on purely esthetic
> grounds, which have nothing to do with the practical idea of
> generating readable, maintainable, bug-free programs. In non-computer
> boolean mathematics, the "or" operator often has the same notation as
> plus, and the "and" operation often has the same notation as times.
Yes. For instance, PALASM uses * and +, so there's some precedent for
that. However, I believe it uses unary / for negation, which isn't
available in C++.
> Actually, I kind of like the idea of finally inventing a logical-XOR
> operator.
But you've correctly noted that != is an XOR if its parameters are both
bools. And XNOR is just as commonly needed as XOR, so why invent two
operators when we already have != and ==?
> But does operator-- always set the bool to false? Does it toggle it?
> Does it always set the bool to true?
I don't think this is specified, but I'll bet it typically toggles,
since 1 is decremented to 0, and 0 is decremented to some nonzero value
which is then converted back to 1. Too bad. If x++ is a useful shorthand
for test-and-set, then x-- would have been a useful shorthand for
test-and-clear.
There is one caveat with using bools that I haven't seen spelled out. I
believe a compiler typically constrains a value to be 0 or 1 when
storing into a bool, not when reading out of it. If this is the case,
then forcing a bool to some other value by using a cast (e.g.,
reinterpret_cast<char&>(b) = 2;) may produce unexpected results, for
instance when using & or ^.
--
Ciao,
Paul
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/21 Raw View
In article <Uwwi1.20776$08.4888008@newscene.newscene.com>,
alstevens@midifitz.com says...
> >The committee didn't invent incrementing boolean values, which is the
> >part that is deprecated.
>
>
> Wait a minute. The base document, the language you are codifying and
> enhancing, has no bool, with or without incrementing behavior.
Having a type named `bool' isn't existing practice. However, using
SOME integer type to represent Boolean values definitely IS existing
practice. The committee codified the existing practice of having a
type to represent Boolean values and came up with a uniform spelling
for the name of the type.
This is very similar to things like the C committee inventing the
token splicing operator. There certainly wasn't an operator named
"##" in the base language, but there were quite a few tricks (e.g.
putting an empty comment between two tokens) to splice tokens together
prior to that time.
In both cases, the NAME of the thing is new, but the thing itself is
FAR from new.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1998/06/19 Raw View
In article <0zfi1.18854$08.4446596@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>>Deprecating it means that implementors are encouraged to issue a
>>warning when they see the usage. This helps user make the transition,
>>which many people think is usually a good thing to do.
>
>That's not what the standard says deprecating means unless they changed the
>definition in FDIS.
It's not the strict definition, but it can be considered a corollary.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/19 Raw View
Al Stevens wrote:
>
> >This isn't something the committee invented.
>
> The committee didn't invent bool? It ain't in the ARM, the "ANSI Base
> Document."
There was a lot of innovation done by various developers between the ARM
and the start of the ISO process. Many of the things that appear to be
new in ISO C++ simply codified existing practice. A type named bool
defined by the user, rather than by the implementation, probably goes
all the way back to K&R C.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Al Stevens" <alstevens@midifitz.com>
Date: 1998/06/19 Raw View
>The committee didn't invent incrementing boolean values, which is the
>part that is deprecated.
Wait a minute. The base document, the language you are codifying and
enhancing, has no bool, with or without incrementing behavior. The FDIS has
a bool with incrementing behavior, which it also deprecates. The committee
did invent the bool, I assume. Who snuck in there and invented the
incrementing bahavior that the committee deprecates? Or is something other
than the ARM the base document?
And you don't think this is funny?
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Al Stevens wrote:
>
> >The committee didn't invent incrementing boolean values, which is the
> >part that is deprecated.
>
> Wait a minute. The base document, the language you are codifying and
> enhancing, has no bool, with or without incrementing behavior. The FDIS has
> a bool with incrementing behavior, which it also deprecates. The committee
> did invent the bool, I assume. Who snuck in there and invented the
> incrementing bahavior that the committee deprecates? Or is something other
> than the ARM the base document?
As I said in my original message:
> The idea is that in, for example, a command line parser you might
> have this:
>
> int has_a = 0;
>
> switch(cmd)
> {
> case 'a':
> ++has_a;
> }
>
> Now, granted, that's not the best way to write that code, but it does
> happen. Allowing boolean values to be incremented permits changing the
> type of has_a to bool without rewriting the code that sets it.
People were incrementing boolean values long before the C++ standard
committee considered adding a boolean type to the standard.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1998/06/20 Raw View
In article <Uwwi1.20776$08.4888008@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>Wait a minute. The base document, the language you are codifying and
>enhancing, has no bool, with or without incrementing behavior. The FDIS has
>a bool with incrementing behavior, which it also deprecates. The committee
>did invent the bool, I assume. Who snuck in there and invented the
>incrementing bahavior that the committee deprecates? Or is something other
>than the ARM the base document?
Bool was invented by all the users who wrote things like:
typedef int bool;
or simply used chars and ints in a boolean way. It has been common
practice for years to use ++ to "set" a boolean variable.
All that the committee did was add it to the standard language, i.e. codify
existing practice. But in the case of ++ on bools they added a note saying
that it's deprecated, i.e. they're just adding it for this version (to ease
the transition of all the code that uses this style), but don't plan on
keeping it around forever.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Al Stevens" <alstevens@midifitz.com>
Date: 1998/06/20 Raw View
>People were incrementing boolean values long before the C++ standard
>committee considered adding a boolean type to the standard.
Except that your example is not a boolean type. It is an integer being used
to exploit the boolean properties of the logical relational operators so
employed because C does not have an intrinsic boolean type.
People did not begin to increment variables of the intrinsic type bool until
there was an intrinsic type bool. In my opinion, the committee should have
defined the behavior as they wanted it without regard to exisiting
implementations (after, of course, all the intense internal techical
agonizing and debate over existing code that someone is bound to remind me
of) .
And so, I shall now resign from the dead horse molester's society and give
someone else the last word.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/06/20 Raw View
"Al Stevens" <alstevens@midifitz.com> writes:
>>The committee didn't invent incrementing boolean values, which is the
>>part that is deprecated.
>Wait a minute. The base document, the language you are codifying and
>enhancing, has no bool, with or without incrementing behavior. The FDIS has
>a bool with incrementing behavior, which it also deprecates. The committee
>did invent the bool, I assume. Who snuck in there and invented the
>incrementing bahavior that the committee deprecates? Or is something other
>than the ARM the base document?
Probably every non-trivial program in C and C++ invents its own
boolean type, no two quite the same. Most often the boolean type
is a macro or typedef resolving to an integer type. In those
cases, all the arithmetic operations are defined, although the
actual effects of something unusual could vary among programs.
Even in C++, you cannot write your own first-class boolean type,
since the value of comparisons and the implicit type of a
conditional is built into the language, and those types ought
be the same type as a boolean.
Combining common libraries from different sources normally
means coping with conflicting definitions of boolean types
and values. Often resolution is exremely difficult even with
full source-code access.
The C++ committee for all these reasons introduced a standard
boolean type that would be compatible as possible with common
home-grown implementations of a boolean type. After discussing
many possibilities, the most compatible solution seemed to
be making it compatible with integer types.
The next step was defining semantics for operations on type bool.
The only operations that didn't have obvious semantics were ++
and --. Since those operations do not have an obvious meaning
for a boolean type, the choices were to disallow them or provide
semantics.
As a compromise, the committee chose to provide semantics but
deprecate their use. If experience shows that ++ and -- are useful
operations for booleans, they can be left in the language (and the
deprecation removed). If it turns out, as I think it will, that ++
and -- really make no sense, the operations can be removed from the
next version of the standard.
--
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Al Stevens" <alstevens@midifitz.com>
Date: 1998/06/18 Raw View
>Deprecating it means that implementors are encouraged to issue a
>warning when they see the usage. This helps user make the transition,
>which many people think is usually a good thing to do.
That's not what the standard says deprecating means unless they changed the
definition in FDIS.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Al Stevens" <alstevens@midifitz.com>
Date: 1998/06/18 Raw View
>This isn't something the committee invented.
The committee didn't invent bool? It ain't in the ARM, the "ANSI Base
Document."
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1998/06/19 Raw View
In article <358883CD.14EDA0A2@infi.net>,
John M. Vreeland <jmvree@infi.net> wrote:
>Just thought I would point out that this use of "toggles" on bool types is
>deprecated, so conceivably Microsoft is rushing to enforce the ANSI standard,
>though it is more likely that they are just enforcing their own new feature.
>:-)
"Deprecated" means that implementations *must* support it, but users are
discouraged from using it because it's likely to go away in a future
revision of the standard. Implementations often give warnings about use of
deprecated features, to help users fix up such code, but if they fail to
compile or generate incorrect code they're just plain broken.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Al Stevens wrote:
>
> >This isn't something the committee invented.
>
> The committee didn't invent bool? It ain't in the ARM, the "ANSI Base
> Document."
The committee didn't invent incrementing boolean values, which is the
part that is deprecated.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Al Stevens" <alstevens@midifitz.com>
Date: 1998/06/18 Raw View
>As I understand it, if I have
>
> bool b;
> ++b;
>
>then b is set to true. The `++b' could be replaced with `b = true'.
Yes, except that that behavior is now deprecated.
(Which is kind of funny for the committee to deprecate the behavior of
something they invented.)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/06/18 Raw View
syd@quango.force9.co.uk wrote:
>
> #include <stdio.h>
>
> static void
> output( const bool *p )
> {
> printf( "flags = %s, %s, %s, %s\n",
> ( p[ 0 ] ? "true" : "false" ),
> ( p[ 1 ] ? "true" : "false" ),
> ( p[ 2 ] ? "true" : "false" ),
> ( p[ 3 ] ? "true" : "false" ) );
> }
>
> extern int
> main()
> {
> bool flags[ 4 ] = { false, true, true, true };
> output( flags );
>
> bool &firstFlag = flags[ 0 ];
> ++firstFlag;
> output( flags );
>
> return 0;
> }
>
> The first call to output displays (as expected):
>
> flags = false, true, true, true
>
> But after using ++ to set the reference to the bool to true
> (the `++firstFlag' line), the next call to output strangely displays:
>
> flags = true, false, false, false
>
> In other words, the first flag has correctly been changed to true, but
> the next 3 have been changed to false.
>
> Note that replacing `++firstFlag' with `firstFlag = true' displays the
> expected:
>
> flags = true, true, true, true
>
> It appears that using ++ on a reference to bool correctly sets the
> bool byte to 1, but it also trashes the next 3 bytes to 0.
Sounds like a code-generator bug. My guess is that bool is a byte-sized
type, but ++firstFlag is fetching a byte, converting it to a 32-bit int,
incrementing it, and storing it back as a 32-bit int, thus clobbering
the next three bytes. This is definitely wrong. You can verify exactly
what's happening by compiling to assembly language output and reading
the code, or doing the same thing in a debugger (assuming you know a
smattering of x86 assembly language).
--
Ciao,
Paul
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "John M. Vreeland" <jmvree@infi.net>
Date: 1998/06/18 Raw View
Just thought I would point out that this use of "toggles" on bool types is
deprecated, so conceivably Microsoft is rushing to enforce the ANSI standard,
though it is more likely that they are just enforcing their own new feature.
:-)
5.2.6 Increment and decrement [expr.post.incr]
1 The value obtained by applying a postfix ++ is the value that the
operand had before applying the operator. [Note: the value obtained
is a copy of the original value ] The operand shall be a modifiable
lvalue. The type of the operand shall be an arithmetic type or a
pointer to a complete object type. After the result is noted, the
value of the object is modified by adding 1 to it, unless the object
is of type bool, in which case it is set to true. [Note: this use is
deprecated, see annex _depr_. ] The result is an rvalue. The type of
the result is the cv-unqualified version of the type of the operand.
See also _expr.add_ and _expr.ass_.
2 The operand of postfix -- is decremented analogously to the postfix ++
operator, except that the operand shall not be of type bool. [Note:
For prefix increment and decrement, see _expr.pre.incr_. ]
Also, to mention a oft-forgotten feature, if you use streams you can just
cout << true << false;
and they should print out properly for your locale. You might have to
cout << boolalpha;
first, though.
-John M. Vreeland
syd@quango.force9.co.uk wrote:
> As I understand it, if I have
>
> bool b;
> ++b;
>
> then b is set to true. The `++b' could be replaced with `b = true'.
>
> Now, what if I have a REFERENCE to a bool?
>
> bool b = false;
> bool &br = b;
> ++br;
>
> Is the `++br' line legal, and should b get set to true?
>
> The reason I am asking is because of a problem I've found in Microsoft
> Visual C++ 5.0 (SP3) as follows:
>
> #include <stdio.h>
>
> static void
> output( const bool *p )
> {
> printf( "flags = %s, %s, %s, %s\n",
> ( p[ 0 ] ? "true" : "false" ),
> ( p[ 1 ] ? "true" : "false" ),
> ( p[ 2 ] ? "true" : "false" ),
> ( p[ 3 ] ? "true" : "false" ) );
> }
>
> extern int
> main()
> {
> bool flags[ 4 ] = { false, true, true, true };
> output( flags );
>
> bool &firstFlag = flags[ 0 ];
> ++firstFlag;
> output( flags );
>
> return 0;
> }
>
> The first call to output displays (as expected):
>
> flags = false, true, true, true
>
> But after using ++ to set the reference to the bool to true
> (the `++firstFlag' line), the next call to output strangely displays:
>
> flags = true, false, false, false
>
> In other words, the first flag has correctly been changed to true, but
> the next 3 have been changed to false.
>
> Note that replacing `++firstFlag' with `firstFlag = true' displays the
> expected:
>
> flags = true, true, true, true
>
> It appears that using ++ on a reference to bool correctly sets the
> bool byte to 1, but it also trashes the next 3 bytes to 0.
>
> If my code is illegal C++, shouldn't the compiler report it as an
> error?
>
> And if my code is legal C++, how do I report the bug to Microsoft?
>
> Geoff
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/06/18 Raw View
Al Stevens wrote:
>
> >As I understand it, if I have
> >
> > bool b;
> > ++b;
> >
> >then b is set to true. The `++b' could be replaced with `b = true'.
>
> Yes, except that that behavior is now deprecated.
>
> (Which is kind of funny for the committee to deprecate the behavior of
> something they invented.)
"++b;" isn't really any clearer or much easier to type than "b=true;".
However, a while back, we argued about whether "b++" is a good idea. My
feeling was that it nicely expresses the concept of "test and set".
--
Ciao,
Paul
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/18 Raw View
Al Stevens<alstevens@midifitz.com> wrote:
>>As I understand it, if I have
>>
>> bool b;
>> ++b;
>>
>>then b is set to true. The `++b' could be replaced with `b = true'.
>
>Yes, except that that behavior is now deprecated.
>
>(Which is kind of funny for the committee to deprecate the behavior of
>something they invented.)
Deprecating it means that implementors are encouraged to issue a
warning when they see the usage. This helps user make the transition,
which many people think is usually a good thing to do.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/18 Raw View
Al Stevens wrote:
>
> >As I understand it, if I have
> >
> > bool b;
> > ++b;
> >
> >then b is set to true. The `++b' could be replaced with `b = true'.
>
> Yes, except that that behavior is now deprecated.
>
> (Which is kind of funny for the committee to deprecate the behavior of
> something they invented.)
This isn't something the committee invented. It tries to encapsulate the
existing behavior of the things that people call booleans in existing
code. The idea is that in, for example, a command line parser you might
have this:
int has_a = 0;
switch(cmd)
{
case 'a':
++has_a;
}
Now, granted, that's not the best way to write that code, but it does
happen. Allowing boolean values to be incremented permits changing the
type of has_a to bool without rewriting the code that sets it.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: syd@quango.force9.co.uk
Date: 1998/06/17 Raw View
As I understand it, if I have
bool b;
++b;
then b is set to true. The `++b' could be replaced with `b = true'.
Now, what if I have a REFERENCE to a bool?
bool b = false;
bool &br = b;
++br;
Is the `++br' line legal, and should b get set to true?
The reason I am asking is because of a problem I've found in Microsoft
Visual C++ 5.0 (SP3) as follows:
#include <stdio.h>
static void
output( const bool *p )
{
printf( "flags = %s, %s, %s, %s\n",
( p[ 0 ] ? "true" : "false" ),
( p[ 1 ] ? "true" : "false" ),
( p[ 2 ] ? "true" : "false" ),
( p[ 3 ] ? "true" : "false" ) );
}
extern int
main()
{
bool flags[ 4 ] = { false, true, true, true };
output( flags );
bool &firstFlag = flags[ 0 ];
++firstFlag;
output( flags );
return 0;
}
The first call to output displays (as expected):
flags = false, true, true, true
But after using ++ to set the reference to the bool to true
(the `++firstFlag' line), the next call to output strangely displays:
flags = true, false, false, false
In other words, the first flag has correctly been changed to true, but
the next 3 have been changed to false.
Note that replacing `++firstFlag' with `firstFlag = true' displays the
expected:
flags = true, true, true, true
It appears that using ++ on a reference to bool correctly sets the
bool byte to 1, but it also trashes the next 3 bytes to 0.
If my code is illegal C++, shouldn't the compiler report it as an
error?
And if my code is legal C++, how do I report the bug to Microsoft?
Geoff
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]