From C++ to Shining C
Jim Fleming
For people interested in getting more information on how the ANSI C++
and C standards work are related, you might want to check out the
August 1995 Issue of Dr. Dobb's Journal.
For those that have claimed (in this forum) that there is no movement
to have C++ features migrate to the C standard, you might want to
read this issue.
The ANSI C standard was completed in 1990 and on the 5th anniversary
all standards are considered for review. According to the article in
Dr. Dobb's Journal, in 1994, P.J. Plauger (one of the copyright holders
of the ANSI C++ standard) convened an *early* effort to begin evaluating
the need to revise the ISO/ANSI C standard. This effort resulted in
recommending that the ANSI C standard be revised.
Evidently a meeting was held recently (early June 1995?) in Copenhagen,
Denmark to review the various proposals for revising the ISO/ANSI C
standard. I don't recall anything being posted here regarding the
meeting such as an agenda or the meeting notes. One would expect that
this would be a good forum to discuss such a meeting.
The article in the magazine sheds some light on the proposed changes.
Since most magazines are edited three months in advance, some of these
proposals may have changed by this time. It is unfortunate that Usenet
is not used to report more up to date information.
Comments on the article, the meeting, and any other trends that show
that the ANSI C standard *may* be revised to include C++ features would
certainly be interesting.
Also, I would be curious at what point C++ and C converge and the
need for two standards disappears.
--
Jim Fleming /|\ Unir Corporation Unir Technology, Inc.
j...@tiger.bytes.com / | \ One Naperville Plaza 184 Shuman Blvd. #100
%Techno Cat I / | \ Naperville, IL 60563 Naperville, IL 60563
East End, Tortola |____|___\ 1-708-505-5801 1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX) 1-708-305-0600
\__/-------\__/ http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|
Soenke Behrens
jim.f...@bytes.com (Jim Fleming) wrote:
>For those that have claimed (in this forum) that there is no movement
>to have C++ features migrate to the C standard, you might want to
>read this issue.
See also a CUJ from some months back. It's somewhere here ... I had it
.. oh heck, I'll dig it out if really necessary.
>Comments on the article, the meeting, and any other trends that show
>that the ANSI C standard *may* be revised to include C++ features would
>certainly be interesting.
It will most certainly be revised to contain new features. Among those
could be a sort of low-key OOP mechanism. I say "low-key" because the
people working on the standard apparently feel that, while OOP can do
something for the language, they do not want to abandon the
"simplicity" principle that underlies C.
So, you might think of the proposed OOP additions as "C with classes"
_not_ gone viral :).
>Also, I would be curious at what point C++ and C converge and the
>need for two standards disappears.
This will certainly not happen. There are good points to be made for
both languages:
o C++ is the current language "playground", more and more extremely
powerful features have been added in a very short time, making the
language uniquely versatile and uniquely complex.
o C has been around for a long time, many consider it less cluttered
than C++; it is certainly easier to understand what a C compiler is
doing than trying to understand exactly what happens when you write
C++ code.
Soenke
--
I don't know what it is he's doing, it must be art
Paul Hepworth
> need for two standards disappears.
I don't think this will ever happen. C++ has taken the kitchen-sinking
approach to features whereas C retains a keep-it-simple philosophy.
It was proposed months ago that classes be added to C, but the C standards
commitee was strongly opposed to templates, operator overloading, and
automatic constructor/destructor invokation; these are my favorite
features of C++! I don't think the day will ever come when the C die-hards
accept all the kitchen-C++, nor will us C++ lovers ever part with our
more complex features. (Of course, those who don't like the complex
features may still use C++, but employ only the subset with which they
are comfortable.
Paul
(references: numerous articles in C/C++ Users Journal)
Jim Fleming
I hope that you are right. Maybe languages like Java (http://java.sun.com/)
and C+@ will illustrate to people that real OO languages can be developed
as companions to C without the need to add incremental features to C that
make it more complex than needed.
These companion languages can focus on the goals of the OO application
developer. I call them "languages for programming systems" as opposed to
"systems programming languages" (like C).
With companion languages, projects can have the traditional C programmers
working on the "hot", performance critical code that is referenced by
the "less hot" OO code that emphasizes reuse and extreme portability.
There is a nice separation of skill sets and the management can more
easily focus each group of programmers on the right objectives.
When the incremental (C++) approach is used, you end up with skilled,
unskilled, left-brain, and right-brain programmers all working in the
same language but potentially using different styles and paradigms.
This may sound eclectic and creative, but it turns out to be a mess.
The best analogy I have found for the companion language approach is
the three-dimensional chess/checker board description. Imagine that
you have a chess board above a checker board. Imagine that as you move
the chess pieces on the upper board things happen on the checker board
via well-defined interfaces. Also, imagine that when pieces are moved
on the checker board side-effects occur on the chess board above.
With a language like C+@ (more so than Java), C+@ programmers write
the rules for the chess game on the upper level while the C programmers
are handling the checker game on the lower level. Well defined interfaces
keep everything in synch.
It has been my experience that using C++ is like collapsing the two
boards into one with the chess pieces and checkers sharing squares, etc.
It is very difficult to see what is going on and the rules for the
combined game are very complex.
I hope that C remains as simple as checkers and I hope that companion
languages (like C+@) show people that a new game can be played on a
similar board and the rules can be simple, like chess, but the potential
can be greater than checkers.
Todd Blanchard
: all standards are considered for review. According to the article in
: Dr. Dobb's Journal, in 1994, P.J. Plauger (one of the copyright holders
: of the ANSI C++ standard) convened an *early* effort to begin evaluating
: the need to revise the ISO/ANSI C standard. This effort resulted in
Well that would suck. C is what it is. C++ is what it is. I use both.
I like C for what it does. Small is beautiful, simple is elegant.
C++ is feature packed and I would not welcome the current standards committees
group think mentality mucking about with something that has served me so
well for so long.
Todd Blanchard
Stephen Baynes
: Evidently a meeting was held recently (early June 1995?) in Copenhagen,
: Denmark to review the various proposals for revising the ISO/ANSI C
: standard. I don't recall anything being posted here regarding the
: meeting such as an agenda or the meeting notes. One would expect that
: this would be a good forum to discuss such a meeting.
It is a shame if those working on the standard setting do not seem to
publish what they are doing (or perhaps they just have not got round to
writing up the minutes). Compare with comp.std.unix which often has
progress reports from the various parts of the standard setting process.
--
Stephen Baynes bay...@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton My views are my own.
United Kingdom
Jim Fleming
bay...@ukpsshp1.serigate.philips.nl says...
>
>Jim Fleming (jim.f...@bytes.com) wrote:
>
>: Evidently a meeting was held recently (early June 1995?) in Copenhagen,
>: Denmark to review the various proposals for revising the ISO/ANSI C
>: standard. I don't recall anything being posted here regarding the
>: meeting such as an agenda or the meeting notes. One would expect that
>: this would be a good forum to discuss such a meeting.
>
>It is a shame if those working on the standard setting do not seem to
>publish what they are doing (or perhaps they just have not got round to
>writing up the minutes). Compare with comp.std.unix which often has
>progress reports from the various parts of the standard setting process.
>
>--
>Stephen Baynes
They publish, but they only do it in the forums that they control. They
carefully time their publications so that the general public has little
chance of becoming involved. In some cases, the publications are obsolete
before they hit the printer and the general public spends enormous amounts
of time trying to sort through the various versions and viewpoints. In
other cases historical documents are generated which gloss over the issues
and give the public the impression that everything is being handled as
an open and fair process.
What is really a shame is that the discussions and e-mail exchanges are
not part of these Usenet forums. Because some large companies have very
strict policies about their "researchers" engaging in commercial activities
(especially on company time and using company resources), it appears that
some people are not able to use these forums because their company would
discover the nature of their "academic" activities. Therefore, they come
up with convenient reasons why this forum is unacceptable for reporting
their results. People who do not have these same restrictions, blindly
follow the leaders who clearly have no interest in the public having
knowledge of what is going on until they are ready for the "market".
Todd Blanchard
> C is what it is and C++ is what it is, but the C standards committee seems
> bent on making C more like C++ than I can stomach. I have been considering
> developing an alternate C dialect I call "C without classes."
>
> Sincerely,
> Robert Corbett
I would support you. Just make it look exactly like ANSI C circa 1994
I think the C++ committee has lost their collective mind in the last year.
And still no support for (optional) GC. Instead we get bool (significant
non-value right there) and an auto_ptr with a copy constructor to
exacerbate the hidden reference problem.
Twain was right about committees.
Todd Blanchard
Marc Shepherd
Don't overreact. The objective of revising C is *not*, so far as I know,
to make it more like C++. There are a number of important extensions having
nothing at all to do with C++, that warrant attention. The ability to
represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
mentioned example.
---
Marc Shepherd
Salomon Brothers Inc
shep...@schubert.sbi.com The opinions I express are no one's but mine!
Todd Blanchard
: In article n...@citadel.evolving.com, tbla...@evolving.com (Todd Blanchard) writes:
: >: recommending that the ANSI C standard be revised.
: >
: >Well that would suck. C is what it is. C++ is what it is. I use both.
: Don't overreact. The objective of revising C is *not*, so far as I know,
: to make it more like C++. There are a number of important extensions having
: nothing at all to do with C++, that warrant attention. The ability to
: represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
: mentioned example.
That's hardly worthy of a language review. The current standard covers that
anyhow. From K&R 2nd:
"The intent is that short and long should provide different lengths of integers
where practical; int will normally be the natural size for a particular
machine. short is often 16 bits, long 32 bits, and int either 16 or 32
bits. Each compiler is free to choose appropriate sizes for its own hardware,
subject only to the restriction that shorts and ints are at least 16 bits,
longs are at least 32 bits, and short is no longer than int which is no
longer than long."
So a compiler could define:
sizeof(short) == 32
sizeof(int) == 64
sizeof(long) == 128
You'd need a more compelling reason than longer types for a language review.
Todd Blanchard
Markus Freericks
> Marc Shepherd (shep...@debussy.sbi.com) wrote:
> : Don't overreact. The objective of revising C is *not*, so far as I know,
> : to make it more like C++. There are a number of important extensions having
> : nothing at all to do with C++, that warrant attention. The ability to
> : represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
> : mentioned example.
>
> That's hardly worthy of a language review. The current standard covers that
> anyhow. From K&R 2nd:
>
> You'd need a more compelling reason than longer types for a language review.
There is some need for _sized_ types, say int<k> (or int:k or whatever
syntax one could come up with), with a semantics of "an integer type having
at least <k> bits" (*). Such an extension to C could improve portability,
both of new and of old programs (when porting from an old machine with,
say, 36-bit longs, one could simply #define long as int(36) to approximate
the old behaviour). As a side benefit, >32-bit-values could be used without
resorting to horrors like "long long".
-- Markus
(* I know, there are dozens of minor open issues wrt the precise behaviour
of shifting and overflow, argument widening, maximum implementation-provided
<k> and whatnot. But hey, working out these details is what standards
committees are for, no? ;-)
Shankar Unni
> That's hardly worthy of a language review. [...]
> So a compiler could define:
> sizeof(short) == 32
> sizeof(int) == 64
> sizeof(long) == 128
Actually, it *is* worthy of review, because the model is restrictive. For
instance, it doesn't address the following needs:
- types of known size (smallest type that's at least 32 bits wide)
- more than 3 natural word sizes (the next generation of machines is
likely to make this necessary).
There are excellent proposals out there that would allow such extensions in
a standard fashion without adding a major burden to the language. (Of
course, I haven't made my mind up about this particular "extension", but
the proposal is worthy of consideration).
Other good extensions for consideration are:
- "//" comments
- declarations inside "for" and "while" controlling expressions (that have
a scope extending to the end of the dependent statement only, as in
the ANSI C++ draft).
- inline functions.
- integral and floating-point named constants without storage.
(The last two remove 90% of the uses for macros, which I consider to be a
Good Thing To Do(tm) - tagless enum's are a gross and tasteless hack for
named integral constants without storage).
All these can make code more readily understandable to the maintainers and
writers (and encourage good programming style) without adding a significant
burden on the language or its implementors (which is one of the most
important considerations for C). And all of them need review, obviously.
I'm torn on the "bool" data type (nah... - it can be done trivially with a
header file). Allowing bitfields of any integral type is, however, also a
good extension - everyone does it anyway, why make it nonstandard?
--
Shankar Unni E-Mail: sha...@sgi.com
Silicon Graphics Inc. Phone: +1-415-390-2072
URL: http://reality.sgi.com/employees/shankar
Marc Shepherd
>Marc Shepherd (shep...@debussy.sbi.com) wrote:
>: nothing at all to do with C++, that warrant attention. The ability to
>: represent new, longer integral types (e.g. 64, 128 bit) is one frequently-
>: mentioned example.
>
>That's hardly worthy of a language review. The current standard covers that
>anyhow. From K&R 2nd:
>where practical; int will normally be the natural size for a particular
>machine. short is often 16 bits, long 32 bits, and int either 16 or 32
>bits. Each compiler is free to choose appropriate sizes for its own hardware,
>subject only to the restriction that shorts and ints are at least 16 bits,
>longs are at least 32 bits, and short is no longer than int which is no
>longer than long."
>
>
>sizeof(short) == 32
>sizeof(int) == 64
>sizeof(long) == 128
>
That doesn't hold up, I'm afraid. The existing language definition assumes
at most three sizes of integer types. Many machines are starting to appear
that offer 32, 64 and 128 bits *in addition to* the traditional 16. The
existing language is simply unable to represent all of them.
Many compilers offer a 'long long' type as an extension, but this has been
criticized as being ugly and short-sighted by many people. (What are you
going to do wheh 256-bit integers come along--call them 'long long long'?
'very long'?)
The Committee is also considering a number of extensions to floating point
arithmetic. C, in case you didn't know, was not specifically designed for
scientific or numerical programming, and the support it provides is noticeably
weaker than FORTRAN. Whether these extensions will be adopted remains to be
seen, but it would certainly be foolish not to consider them.
---
Marc Shepherd
Salomon Brothers Inc
shep...@schubert.sbi.com <<These are my opinions, not my employer's.>>
Dag Bruck
>
>I'm torn on the "bool" data type (nah... - it can be done trivially with a
>header file).
It's worth pointing out that this is a significant difference between C and
C++; in C a simple typedef will do fine:
typedef int bool;
in C++ this is not good enough, because that will not allow us to overload
a function on both int and bool.
I think C should make bool a pre-defined typedef (i.e., no header file),
otherwise C++ should have a corresponding empty header file.
-- Dag
--
Dynasim AB Phone: +46 46 182500
Research Park Ideon Fax: +46 46 129879
S-223 70 Lund E-mail: D...@Dynasim.se
Sweden
John Max Skaller
Paul Hepworth <sl...@cc.usu.edu> wrote:
>> Also, I would be curious at what point C++ and C converge and the
>> need for two standards disappears.
>
>I don't think this will ever happen. C++ has taken the kitchen-sinking
>approach to features whereas C retains a keep-it-simple philosophy.
I'm not sure if that is a fair description of C++, and
I wouldn't count on the C committee -- which is current reviewing
the C Standard -- keeping C all that simple -- or indeed,
making it simpler. (I hope it does, however).
C++ basically adds three features to C -- user defined
types (classes), exceptions, and templates. It also soups
up the safety of a couple of things -- casts, offsetof is replaced
by pointers to members. And it adds "inline" functions for
efficiency.
Almost all the other "features" turn out to be necessary
to support these things, including constructors, overloading,
references and inheritance.
Unfortunately, C turns out not to be a nice simple
language at all. If it were, extending it would be easy and
the result relatively simple.
--
JOHN (MAX) SKALLER, INTERNET:max...@suphys.physics.su.oz.au
Maxtal Pty Ltd,
81A Glebe Point Rd, GLEBE Mem: SA IT/9/22,SC22/WG21
NSW 2037, AUSTRALIA Phone: 61-2-566-2189
Dave Mooney
> People who do not have these same restrictions, blindly
> follow the leaders who clearly have no interest in the public having
> knowledge of what is going on until they are ready for the "market".
ANSI X3J11, being a subgroup of the Trilateral Commission, has very
strict rules about how and when it is allowed to disseminate information
to the public. This has the side-effect of-- whoops, I've said too much
already.
dave
--
Dave Mooney | IBM Toronto Lab | "We see the fish below the ice sometimes."
Jim Fleming
says...
This sounds like C is going to "buy cancer". As soon as classes are
added to C, then the rest comes along for the ride.
If ANSI C inherits (not OO inheritance) most of the features of C++,
then why have two standards?
I currently meet people all of the time that claim that they are programming
in C++. I ask them if they are doing object-oriented programming. They
answer, "Yep!". I ask them if they use classes, they usually say, "No, I
have not gotten that far into the language".
In my opinion, C has lost it's heritage to C++. While this might be viewed
as a major marketing coup by language designers, I think that it is a
disservice to the C programming community. It is also a disservice to the
field of object technology, because we now have educated people running
around that think they know what OO is about...but, they "have not gotten
that far into the language"...and therefore, have not scratched the surface
of OO...
Can you imagine a lawyer saying, I use English but I have not mastered
contracts because I have not gotten that far into the language? The
language should be easy to master, the various usages (like contract law)
should build upon the simple language base. If English had to have
extensions to support certain domains, then it would die under the
weight of the extensions.
I predict that C++ will die under the weight of it's OO extensions. I
hope that it does not take C with it...
Maybe C++ needs to be renamed...then it would not impact C....
...we could call it DOOG...or D+OO+G...or D+OO+Gnu...:)
C+@ could remain as CAT...:)
...then C could remain as C...
@@@@@@@@@@@@@@@@@@@@@@@@@@@@
John Max Skaller
Todd Blanchard <tbla...@evolving.com> wrote:
>Marc Shepherd (shep...@debussy.sbi.com) wrote:
>
>You'd need a more compelling reason than longer types for a language review.
Irrelevant. The reason there is a language review is that 5 years
is up from the last Standard. Its normal procedure.
--
JOHN (MAX) SKALLER, INTERNET:max...@suphys.physics.su.oz.au
Christopher R. Volpe
>In article <1995Jul2.1...@cc.usu.edu>,
>Paul Hepworth <sl...@cc.usu.edu> wrote:
>>> Also, I would be curious at what point C++ and C converge and the
>>> need for two standards disappears.
>>
>>I don't think this will ever happen. C++ has taken the kitchen-sinking
>>approach to features whereas C retains a keep-it-simple philosophy.
>
> I'm not sure if that is a fair description of C++, and
>I wouldn't count on the C committee -- which is current reviewing
>the C Standard -- keeping C all that simple -- or indeed,
>making it simpler. (I hope it does, however).
>
> C++ basically adds three features to C -- user defined
>types (classes), exceptions, and templates. It also soups
>up the safety of a couple of things -- casts, offsetof is replaced
>by pointers to members. And it adds "inline" functions for
I don't think this is an appropriate analogy. Offsetof is just as useful for
C++ as it is for C. C already allows you to take the address of structure
members. The result is a pointer to the type of the data member, and it works
exactly the same way as in C++. The "pointer to member" of C++ is actually a
"pointer to member FUNCTION", which is necessary in C++ due to the extra
"this" pointer that C++ member functions have. There is no analog of this in C.
--
Chris Volpe Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D Fax: (518) 387-6560
PO Box 8, Schenectady, NY 12301 Email: vol...@crd.ge.com
Jim Fleming
says...
>
>In article <3tgsog$2...@citadel.evolving.com>,
>Todd Blanchard <tbla...@evolving.com> wrote:
>>Marc Shepherd (shep...@debussy.sbi.com) wrote:
>>
>>You'd need a more compelling reason than longer types for a language
review.
>
> Irrelevant. The reason there is a language review is that 5 years
>is up from the last Standard. Its normal procedure.
>--
> JOHN (MAX) SKALLER, INTERNET:max...@suphys.physics.su.oz.au
I am not sure that this is accurate. Just because the 5 years are up, that
does _not_ trigger an automatic rework of the language. I think that the
process has at least two steps.
As I understand the process, *after* 5 years, there are three doors to
choose:
Door #1 - The standard stands with no changes
Door #2 - The standard is reworked (this was selected)
Door #3 - The standard is abandoned because of irrelevance
According to the August issue of Dr. Dobb's Journal, P. J. Plauger asked
the committee in 1994 (a year early) to consider the above three choices.
Door #2 was selected. It is not clear why the early request was made, but
the rework process has been started.
After 5 years, it is hard to imagine that Door #1 could have been selected.
Door #3 is certainly not an option because clearly, there is still a lot
of C code being written...at least the last time I looked...:-)
The question now is, how much review/rework/rewriting etc. is required
and how will that dove-tail with the C++ Standards work...???
Warner Losh
Christopher R. Volpe <vo...@ausable.crd.ge.com> wrote:
>I don't think this is an appropriate analogy. Offsetof is just as useful for
>C++ as it is for C. C already allows you to take the address of structure
>members. The result is a pointer to the type of the data member, and it works
>exactly the same way as in C++. The "pointer to member" of C++ is actually a
>"pointer to member FUNCTION", which is necessary in C++ due to the extra
>"this" pointer that C++ member functions have. There is no analog of this in C.
However, C++'s does have pointers to member DATA. They are quite
useful and make things more typesafe if you want to initialize
elements of a class from a data table. That sounds like a replacement
to me.
C++ also has pointers to member FUNCTIONS which are, quite frankly, a
big pain in the butt due the all the restrictions in their use that
have recently been added to them (relative to a liberal reading of the
ARM).
Warner
--
Warner Losh "VMS Forever" home: i...@village.org
Cyberspace Development, Inc work: i...@marketplace.com
Makers of TIA, The Internet Adapter. http://marketplace.com/
Michael Shields
Shankar Unni <sha...@engr.sgi.com> wrote:
> - inline functions.
I'd also like to see ways to declare that a function has no side effects,
and that it does not return.
> I'm torn on the "bool" data type (nah... - it can be done trivially with a
> header file).
It depends on the semantics you want. Personally, I'd like to say that
bool can only be 0 or 1, so that `foo--' will always set it false, and
`tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
--
Shields.
Shankar Unni
> It depends on the semantics you want. Personally, I'd like to say that
> bool can only be 0 or 1, so that `foo--' will always set it false, and
> `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
Hahahaha. (sorry). Check out the C++ draft:
bool-- is an undefined operation, and is not guaranteed to set the boolean
to zero. bool++ will, however, set it to true.
I guess the intent was that implementations can quietly implement bool as
"unsigned char" and do nothing else, but that's clearly silly, since they
would still have to guard against 256 ++'s in a row.
In practice, I guess most implementations would actually implement bool as
an unsigned char, with bool++ being changed to bool=true, and bool-- to
bool=false;
However, tzname[isdst] will work regardless of the implementation, because
the conversion of a bool to an int must always yield a 0 or a 1..
Michael Shields
Shankar Unni <sha...@engr.sgi.com> wrote:
> Michael Shields (shi...@tembel.org) wrote:
>
> > It depends on the semantics you want. Personally, I'd like to say that
> > bool can only be 0 or 1, so that `foo--' will always set it false, and
> > `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
>
> Hahahaha. (sorry). Check out the C++ draft:
>
> bool-- is an undefined operation, and is not guaranteed to set the boolean
> to zero. bool++ will, however, set it to true.
Is there a rationale given?
I'm pretty sure ISO Pascal worked the same way, but that's not a reason.
--
Shields.
Richard Krehbiel
>bool-- is an undefined operation, and is not guaranteed to set the boolean
>to zero. bool++ will, however, set it to true.
>I guess the intent was that implementations can quietly implement bool as
>"unsigned char" and do nothing else, but that's clearly silly, since they
>would still have to guard against 256 ++'s in a row.
>In practice, I guess most implementations would actually implement bool as
>an unsigned char, with bool++ being changed to bool=true, and bool-- to
>bool=false;
If bool++ means bool=true then what about bool+=i? Where i is zero?
(MHO: Should be illegal. Also IMHO bool++ should be illegal - if you
mean bool=true, damn it, spend the three extra keystrokes and say it
that way.)
--
Richard Krehbiel, Kastle Systems, Arlington VA USA
ri...@kastle.com (work) or ri...@cais.com (personal)
Norman Diamond
>Personally, I'd like to say that
>bool can only be 0 or 1, so that `foo--' will always set it false, and
>`tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
Close. You'd have to say that bool can only be 0, 1, or Maybe, so that
tzname[isdst] will index correctly :-)
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
Michael Shields
Norman Diamond <dia...@jrd.dec.com> wrote:
> In article <3tv3gv$b...@yage.tembel.org>, shi...@tembel.org (Michael Shields) writes:
> >Personally, I'd like to say that
> >bool can only be 0 or 1, so that `foo--' will always set it false, and
> >`tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
>
> Close. You'd have to say that bool can only be 0, 1, or Maybe, so that
> tzname[isdst] will index correctly :-)
Perhaps there should be a new `quantum' type; you would be able to take
its address or value, but not both simultaneously.
--
Shields.
Michael Cook
SU> I guess the intent was that implementations can quietly implement bool as
SU> "unsigned char" and do nothing else, but that's clearly silly, since they
SU> would still have to guard against 256 ++'s in a row.
No, it looks like the intent was that `++' and `--' could be impelemented for
`bool' in the same way as for other integers:
++b is b=b+1 is b=1+1 is b=bool(2) is b=true
or b=0+1 is b=bool(1) is b=true
and
--b is b=b-1 is b=1-1 is b=bool(0) is b=false
or b=0-1 is b=bool(-1) is b=true
In other words, `++b' does the Just Works, as they say.
But `--b' doesn't.
Michael.
Pete Becker
>
>Michael Shields (shi...@tembel.org) wrote:
>
>> bool can only be 0 or 1, so that `foo--' will always set it false, and
>> `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
>
>
>to zero. bool++ will, however, set it to true.
>
>
The reason for this was to make conversion of existing applications easy.
One example is a command-line parser, which increments the p-counter every
time it encounters -p on the command line. Since the only issue after the
parsing has been done is 0 vs. non-0, it sure looks like a boolean value.
-- Pete
Christopher R. Volpe
>Shankar Unni <sha...@engr.sgi.com> wrote:
>> - inline functions.
>
>I'd also like to see ways to declare that a function has no side effects,
>and that it does not return.
>
>> I'm torn on the "bool" data type (nah... - it can be done trivially with a
>> header file).
>
>bool can only be 0 or 1, so that `foo--' will always set it false, and
If the bool type can be only zero or one, I'm not sure I'd want "--" to be a
valid operator for the type.
Christopher R. Volpe
>In article <DBK0I...@crdnns.crd.ge.com>,
>Christopher R. Volpe <vo...@ausable.crd.ge.com> wrote:
>>I don't think this is an appropriate analogy. Offsetof is just as useful for
>>C++ as it is for C. C already allows you to take the address of structure
>>members. The result is a pointer to the type of the data member, and it works
>>exactly the same way as in C++. The "pointer to member" of C++ is actually a
>>"pointer to member FUNCTION", which is necessary in C++ due to the extra
>>"this" pointer that C++ member functions have. There is no analog of this in C.
>
>However, C++'s does have pointers to member DATA. They are quite
>useful and make things more typesafe if you want to initialize
>elements of a class from a data table.
Thanks. I wasn't aware of that. How are they more typesafe? And what type does
the "&" operator yield when applied to a class member of type int? Does it
yield "pointer to int" or "pointer to class member of type int"?
> That sounds like a replacement
>to me.
Not to me. It doesn't seem to me that pointer to data member gives you
anything towards making offsetof obsolete that simply taking the address of a
struct field gives you. In C, the offsetof macro is useful despite the ability
to generate a pointer to a struct member. Whatever uses offsetof has in C
should still apply in C++ despite the existence of a more typesafe pointer
type.
>
>C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>big pain in the butt due the all the restrictions in their use that
>have recently been added to them (relative to a liberal reading of the
>ARM).
Such as? (Just curious)
Fergus Henderson
>Michael Shields (shi...@tembel.org) wrote:
>
>> It depends on the semantics you want. Personally, I'd like to say that
>> bool can only be 0 or 1, so that `foo--' will always set it false, and
>> `tzname[isdst]' will index correctly without the `tzname[!!isdst]' hack.
In C++, a bool can only be `true' or `false'.
In an integer context, `true' converts to 1, `false' converts to 0.
>Hahahaha. (sorry). Check out the C++ draft:
>
>bool-- is an undefined operation, and is not guaranteed to set the boolean
>to zero.
Wrong. It's not undefined, it's ill-formed. The compiler must issue
a diagnostic if you use `--' on a bool.
>bool++ will, however, set it to true.
>
>I guess the intent was that implementations can quietly implement bool as
>"unsigned char" and do nothing else, but that's clearly silly, since they
>would still have to guard against 256 ++'s in a row.
You guess wrong.
I'm pretty sure that the reason `++' was defined for bools is to allow
easy conversion of old dusty-deck code which has been observed to use
`++' on variables whose type is a typedef or macro called `bool' or
something similar.
--
Fergus Henderson
f...@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
Michael Shields
Richard Krehbiel <ri...@kastle.com> wrote:
> If bool++ means bool=true then what about bool+=i? Where i is zero?
It would leave bool unchanged. A positive i would set bool true and a
negative i would set it false.
--
Shields.
Tim Hollebeek
>pe...@borland.com (Pete Becker) wrote:
>>The reason for this was to make conversion of existing applications easy.
>>One example is a command-line parser, which increments the p-counter every
>>time it encounters -p on the command line.
>
>than p++?
Probably. On the other hand, what have people always used? Answer: p++.
Backwards compatibility is a hairy subject that is seldom logical.
>>Since the only issue after the
>>parsing has been done is 0 vs. non-0, it sure looks like a boolean value.
>
>Sounds like the question is whether or not a boolean type should be a
>_modulo-2_ integral type. I think it should.
Unfortunately, that implies p++ is XOR, not SET, contrary to current
usage, regardless of what is "should" be. IMHO, the answer (ignoring
the backwards compatibility question since you seem to be ignoring it)
is obvious: p++ is nonsensical. Limit operations on booleans to the
'traditional' mathematical operations, which are the only sanely
defined ones.
If you want to set a bool to be true, use bool = true. If you want to
flip it, use bool = ~bool or bool ^= true (granted, that second one
looks a bit counterintuitive, but it's sound from a mathematical standpoint).
It shouldn't be strictly possible to 'add' booleans, etc. add is an operation
on integral types, not booleans. However, one can obviously do it
through a conversion to (int), so true + true == 2, and (bool)5 +
(bool)12 == 2.
That's the _sensible_ way to do it. Of course, there are other
practical issues lurking in the corners here which can't be ignored.
--
---
Tim Hollebeek 'There will be a better sig when I have time'
Michael Cook
MS> In article <1995Jul13.1...@friend.kastle.com>,
MS> Richard Krehbiel <ri...@kastle.com> wrote:
>> If bool++ means bool=true then what about bool+=i? Where i is zero?
MS> It would leave bool unchanged. A positive i would set bool true and a
MS> negative i would set it false.
If you implement `bool+=i' in terms of the existing implicit conversions, then
`b+=i' is `b=b+i' is `b=bool(int(b)+i)' is one of
b=bool(0+i)
or
b=bool(1+i)
which has different truth values depending on the value of i and the previous
value of b.
Michael.
Ross Ridge
> bool-- is an undefined operation, and is not guaranteed to set the boolean
Michael Shields <shi...@tembel.org> wrote:
>Is there a rationale given?
>
>I'm pretty sure ISO Pascal worked the same way, but that's not a reason.
My guess is that "bool++" is common C idiom, "bool--" isn't. Going
further would only constrain implementations and encourage (what I at
least would call) a bad programming style.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU, Ook +1 519 883 4329
[oo][oo] rri...@csclub.uwaterloo.ca http://csclub.uwaterloo.ca/u/rridge/
-()-/()/
db //
Michael Shields
Michael Cook <mc...@cognex.com> wrote:
> If you implement `bool+=i' in terms of the existing implicit conversions, then
> `b+=i' is `b=b+i' is `b=bool(int(b)+i)' is one of
>
> b=bool(0+i)
> or
> b=bool(1+i)
>
> which has different truth values depending on the value of i and the previous
> value of b.
If you don't add new semantics to bool, why make it a type at all,
when you could just treat an int as a boolean, as people do now?
--
Shields.
Michael Cook
MS> If you don't add new semantics to bool, why make it a type at all,
MS> when you could just treat an int as a boolean, as people do now?
Overloading.
BTW, has someone pointed out yet that `E1 op= E2' is ill formed if E1 is of
type `bool'?
Michael.
Lars Wirzenius
> >>The reason for this was to make conversion of existing applications easy.
> >>One example is a command-line parser, which increments the p-counter every
> >>time it encounters -p on the command line.
Then the p-counter is not a boolean, and should not be made to have a
boolean type. If the p-counter is intended to be a boolean, it shouldn't
be incremented.
t...@handel.Princeton.EDU (Tim Hollebeek) wrote (not directly in response
to the above):
> Probably. On the other hand, what have people always used? Answer: p++.
> Backwards compatibility is a hairy subject that is seldom logical.
Personally, I see no point in using "p++" instead of "p = 1" or "p = YES"
(or "p = TRUE", for those who prefer that spelling), even in C. "p++"
is not intuitive, and gives a creepy feeling that something is going
to break if p grows too large.[1] Creepy feelings are something to
avoid when coding.
Making a boolean type work with ++ (but not with --) is not going to
buy all that much. If the old code is something like this:
int p = 0;
if (some_condition)
++p;
then, if someone changes p to be a boolean, the compiler could easily
diagnose every instance of ++ used with p. That would make it easier
to fix the program.
There are likely to be other places that might need to be changed if
the type of p is changed. I can't imagine that it would be very costly
to have to change "p++".
> If you want to set a bool to be true, use bool = true. If you want to
> flip it, use bool = ~bool or bool ^= true (granted, that second one
> looks a bit counterintuitive, but it's sound from a mathematical standpoint).
I'd prefer these:
bool = true; // set it
bool = false; // clear it
bool = !bool; // flip it
Again, I see no reason to "taint" a boolean type so that it works with
operands that lack the boolean nature.
--
Lars.Wi...@helsinki.fi (finger wirz...@klaava.helsinki.fi)
NEW: Publib version 0.5: ftp://ftp.cs.helsinki.fi/pub/Software/Local/Publib/
[1] What do you mean, it is known not to grow too large. Did you
prove it? If so, wouldn't it have been easier to just use "p=1"?
Sakari Jalovaara
>>bool can only be 0 or 1, so that `foo--' will always set it false, and
>
>valid operator for the type.
In C there already are variables that only have values one and zero
and where "--" is valid:
struct { unsigned int ean:1 } bool;
bool.ean--; /* i.e. "bool.ean = !bool.ean;" */
Methinks that having "++bool" equivalent to "(bool = True)" is a brilliant
example of the main problem of C++. And why in the future C should fight
with all its might lest it become another C++.
++sja
Andrew Koenig
> I guess the intent was that implementations can quietly implement bool as
> "unsigned char" and do nothing else, but that's clearly silly, since they
> would still have to guard against 256 ++'s in a row.
The intent is to allow programmers who use int values as booleans
and set them to true by applying ++ to them to change them to type bool
without changing alll the places they're used.
Wise or not, the practice of using ++ to make a variable "true"
is widespread.
--
--Andrew Koenig
a...@research.att.com
Mr.H
- >>>>> "SU" == Shankar Unni <sha...@sgi.com> writes:
- SU> I guess the intent was that implementations can quietly implement bool as
- SU> "unsigned char" and do nothing else, but that's clearly silly, since they
- SU> would still have to guard against 256 ++'s in a row.
- No, it looks like the intent was that `++' and `--' could be impelemented for
- `bool' in the same way as for other integers:
- ++b is b=b+1 is b=1+1 is b=bool(2) is b=true
- or b=0+1 is b=bool(1) is b=true
- and
- --b is b=b-1 is b=1-1 is b=bool(0) is b=false
- or b=0-1 is b=bool(-1) is b=true
- In other words, `++b' does the Just Works, as they say.
- But `--b' doesn't.
- Michael.
What if b is already -1 (true)? then...
++b is b=b+1 is b=-1+1 is b=bool(0) is b=false
Clearly, if b is being treated as a signed integral type then the
'b++ is always true' statement has to be false, doesn't it?
--
-------------------------------------------------------------------
-- Mr.H - mi...@mrhappy.if.com --
-- All opinions expressed herein are my own... right? --
-- "Things are more like they are now than they have ever been." --
-- - Gerald Ford --
-------------------------------------------------------------------
Fergus Henderson
>max...@Physics.usyd.edu.au (John Max Skaller) writes:
>> C++ basically adds three features to C -- user defined
>>types (classes), exceptions, and templates. It also soups
>>up the safety of a couple of things -- casts, offsetof is replaced
> ^^^^^^^^^^^^^^^^^^^^
>>by pointers to members. And it adds "inline" functions for
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
>I don't think this is an appropriate analogy.
It's not perfect, but I think it is closer than you make out.
>Offsetof is just as useful for C++ as it is for C.
Well... not quite. In C++, offsetof() isn't guaranteed to work
for all fields - it is only guaranteed to work for fields of PODs,
i.e. C-like structs. You can't (portably or reliably) use offsetof()
on classes with virtual functions, virtual base classes, etc.
>C already allows you to take the address of structure
>members. The result is a pointer to the type of the data member, and it works
>exactly the same way as in C++. The "pointer to member" of C++ is actually a
>"pointer to member FUNCTION", which is necessary in C++ due to the extra
>"this" pointer that C++ member functions have. There is no analog of this in C.
But in C++, pointers to members can point to data, they don't have to
point to functions. John Skaller should have said "offsetof is replaced
by pointers to data members" (as opposed to pointers to function members).
--
Fergus Henderson
f...@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC 8B 3E 0F 01 E7 5D C4 3F
Barry Margolin
>There's absolutely no justification in adding all sorts of stupid and
>non-obvious quirks to the bool type (such as the example under discussion
>of allowing the ++ operator) so that existing code "works without
>alteration" when the people who will be wanting to convert to using `bool'
>instead of `int' (or `unsigned char') will be having to edit their code
>*anyway* in order to do so.
It's much easier to edit a couple of variable declarations, or very often
just one macro or typedef in a header file, than to find all the places
where you use <boolvar>++ and fix them.
>Go too far down that road and you start defining silly things just in order
>to keep things straight, such as defining semantics for left-shifting `true'
>and `false' or whether implementations are allowed to represent !true and
>~true with different bit patterns "under the covers".
This is silly. No one (well, maybe I should play it safe and say hardly
anyone) shifts boolean variables in existing code, so no one is going to
propose that it be defined for the official bool type. On the other hand,
we know that there's a large amount of code out there that uses <bool>++,
even though it's poor style.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
bar...@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-5124
Jonathan de Boyne Pollard
: The intent is to allow programmers who use int values as booleans
: and set them to true by applying ++ to them to change them to type bool
: without changing alll the places they're used.
:
: Wise or not, the practice of using ++ to make a variable "true"
: is widespread.
Then let them continue to use those int values as booleans!
There's absolutely no justification in adding all sorts of stupid and
non-obvious quirks to the bool type (such as the example under discussion
of allowing the ++ operator) so that existing code "works without
alteration" when the people who will be wanting to convert to using `bool'
instead of `int' (or `unsigned char') will be having to edit their code
*anyway* in order to do so.
Go too far down that road and you start defining silly things just in order
to keep things straight, such as defining semantics for left-shifting `true'
and `false' or whether implementations are allowed to represent !true and
~true with different bit patterns "under the covers".
If people want to do silly things with ints, then let them continue to do
so. But REQUIRE them to tidy up their concepts of boolean variables so that
they include the common criteria that booleans can ONLY HAVE TWO VALUES and
ONLY RESPOND TO A LIMITED SET OF OPERATIONS before they can convert such
code to using `bool'.
[[ One has to wonder : Are the people promoting the idea of adding arbitrary
and non-obvious semantics to the `bool' type for the sake of mere and
somewhat dubious convenience the same C++ programmers who scream loudly
and long when others suggest that "for convenience" it would be nice to add
in members to class definitions after the fact ? ]]
Stephen Baynes
: Personally, I see no point in using "p++" instead of "p = 1" or "p = YES"
: (or "p = TRUE", for those who prefer that spelling), even in C. "p++"
: is not intuitive, and gives a creepy feeling that something is going
: to break if p grows too large.[1] Creepy feelings are something to
: avoid when coding.
I agree
: Making a boolean type work with ++ (but not with --) is not going to
: buy all that much. If the old code is something like this:
: int p = 0;
: if (some_condition)
: ++p;
: then, if someone changes p to be a boolean, the compiler could easily
: diagnose every instance of ++ used with p. That would make it easier
: to fix the program.
: There are likely to be other places that might need to be changed if
: the type of p is changed. I can't imagine that it would be very costly
: to have to change "p++".
If you want to add extra boolean functionality for this case, then add
something realy useful ie ||= and &&= then the above code can be
written:
p ||= some_condition;
: > If you want to set a bool to be true, use bool = true. If you want to
: > flip it, use bool = ~bool or bool ^= true (granted, that second one
: > looks a bit counterintuitive, but it's sound from a mathematical standpoint).
: I'd prefer these:
: bool = true; // set it
: bool = false; // clear it
: bool = !bool; // flip it
I agree, though I would also support (adding ^^ and ^^= to the language)
bool ^^= true; /* to flip it */
--
Stephen Baynes bay...@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton My views are my own.
United Kingdom
James Kanze US/ESC 60/3/141 #40763
(Dag Bruck) writes:
|> In article <...>, Shankar Unni <sha...@engr.sgi.com> wrote:
|> >
|> >I'm torn on the "bool" data type (nah... - it can be done trivially with a
|> >header file).
|> It's worth pointing out that this is a significant difference between C and
|> C++; in C a simple typedef will do fine:
|> typedef int bool;
Not really. Ideally, conditional expressions (in `if', `while', etc.)
would require a bool type, and the compiler would generate an error if
any other type were provided.
Practically, of course, this would break so many C programs that it
has absolutely no chance of being adapted. With the exception of
function overloading (which Dag mentions below), the `bool' type as
defined in C++ doesn't really buy much more than the typedef (except
that compilers could generate warnings about dangerous conversions).
|> in C++ this is not good enough, because that will not allow us to overload
|> a function on both int and bool.
|> I think C should make bool a pre-defined typedef (i.e., no header file),
|> otherwise C++ should have a corresponding empty header file.
I think that C should do it correctly. Just take the original
proposal (which Dag co-authored with Andy Koenig), and adapt it
completely (with the type conversions *deprecated*).
--
James Kanze Tel.: (+33) 88 14 49 00 email: ka...@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
Michael Cook
H> What if b is already -1 (true)? then...
b is of type `bool'.
It can be only `false' or `true'.
It can't be -1.
int(false) is 0.
int(true) is 1.
int(bool(-1)) is 1.
int(bool(42)) is 1.
Michael.
Jim Fleming
>
>and set them to true by applying ++ to them to change them to type bool
>without changing alll the places they're used.
>
>Wise or not, the practice of using ++ to make a variable "true"
>is widespread.
> --Andrew Koenig
> a...@research.att.com
@@@@@@@@@@@
I guess this means that C++ is not just an incremental step past C...
...it could mean..."The *true* C"...or making C true...
I guess that C++ is "The right choice" after all...:)
@@@@@@@@@@@
For anyone that has followed C++ from day one, clearly everyone knows that
the designers and developers had a very tough job. C was (or is) a classic
and to add OO extensions to any language is a very difficult task. As I
have mentioned, this is like combining chess and checkers on the same
board and trying to explain the rules.
When C++ was started in the late 70's and early 80's, things were different.
We did not have low-cost 64 bit processors operating at over 100 MHz on
32 Meg memories. C++ was designed (or C was extended) with efficiency in
mind and assumed that all knowledge of the software engineering process
would be thrown away in the execution environment. Static was selected over
dynamic and C++ software is now brittle and difficult to reuse.
Things have now changed. It is now possible for a 747 to carry an on-board
computer that continues to be part of the software engineering environment.
Does this mean that 747 software is not tested, of course not, it simply
means that software engineers can now get feed-back from their creations
and this feed-back can be used to improve the software. (In theory, you
could probably imagine fixing a critical bug and updating it in flight,
but that level of theatrics is probably best left for the Space Shuttle
and telephone switches.
As more and more people discover the beauty, and classic lines of C, they
begin to see (no pun intended) that C++ provides a path to object-oriented
programming. Unfortunately, the path leads to a difficult approach and
the classic lines of C are lost. As mentioned above, they find themselves
playing checkers and chess on the same board, and they easily end up with
a mess.
Others (like the C+@ developers and Java developers see http://java.sun.com)
have taken a different path. They have taken the classic game of checkers
(which is like C) and have designed a new game like chess. The boards are
kept separate and very well-defined rules have been written to allow the
classic world of C to inter-work with the world of C+@ (or Java).
C is like checkers...it is now (in comparison) to C++ easy to learn...
C+@ is like chess...it offers new challenges, greater power, and some
checker players can step up to these challenges...
...also, some people can learn C+@ directly, without knowing
anything about C (or checkers)...
I know...I know...you have only one 8x8 board and your company (or school)
has said all of the pieces must be placed on one board...this is unfortunate
but is a marketing reality that exists...if you are in this situation, I
recommend that the best thing you can do is continue to play checkers (C) on
part of the board and try to play a limited game of chess (C++) on another
part of the board...if possiblem, try not to mix the pieces and the
paradigms...someday, your company may be able to add another board...it
makes both checkers and chess, much more fun...programming should be fun...
If you are just learning checkers (C)...stick with that...
You might be able to learn chess (C++) without understanding
checkers (C), but this is hard...
As C programmers know...there are several ways to increment a c...
c++;
c += 1;
c = c + 1;
c = 1 + c;
...there is only one way to "skin a C+@"...:)
...have a cup of Hot Java...it is FREE...!!!
...while you are waiting for the ANSI C++ standard...
--
Jim Fleming /|\ Unir Corporation Unir Technology, Inc.
j...@tiger.bytes.com / | \ One Naperville Plaza 184 Shuman Blvd. #100
%Techno Cat I / | \ Naperville, IL 60563 Naperville, IL 60563
East End, Tortola |____|___\ 1-708-505-5801 1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX) 1-708-305-0600
\__/-------\__/ http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|
James Kanze US/ESC 60/3/141 #40763
rri...@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
|> Shankar Unni <sha...@engr.sgi.com> wrote:
|> > bool-- is an undefined operation, and is not guaranteed to set the boolean
|> > to zero. bool++ will, however, set it to true.
|> Michael Shields <shi...@tembel.org> wrote:
|> >Is there a rationale given?
|> >
|> >I'm pretty sure ISO Pascal worked the same way, but that's not a reason.
|> My guess is that "bool++" is common C idiom, "bool--" isn't. Going
|> further would only constrain implementations and encourage (what I at
|> least would call) a bad programming style.
Your guess is correct.
In the original proposal, the ++ operator and the (silent) conversions
to int, from int/pointer/float were deprecated. The deprecation
somehow got lost in the adaption process.
Concerning deprecation: officially, deprecation means that the feature
is slated for removal in a future version of the standard.
Practically, well... Fortran 90 still has arithmetic if, which was
deprecated (if I'm not mistaken) 25 years ago. So deprecation really
only means that the standards organization thinks that the feature is
a bad thing, and is encouraging compiler writers to generate warnings.
Markus Freericks
> It's much easier to edit a couple of variable declarations, or very often
> just one macro or typedef in a header file, than to find all the places
> where you use <boolvar>++ and fix them.
Since the compiler would produce typecheck warnings/errors (*) for each
occurence of a <boolvar>++, the "finding" would be no problem. I suppose
the motivation of people who convert ints into bools in existing programs
is to clean up their code. Removing (IMHO) dangerous practices (**) like
<boolvar>++ would clearly fit that motivation.
-- Markus
(*) Maybe <boolvar>++ could be introduced as a "deprecated" feature?
(**) I know a project that lost more than a few man-days due to a bug
that involved <int-representing-a-flag>++. Some idiot had come across
the oh-so-succinct formulation
if (static_init_done_flag++) return;
[...init code that should *never* be run twice...]
;-)
Lars Wirzenius
> It's much easier to edit a couple of variable declarations, or very often
> just one macro or typedef in a header file, than to find all the places
> where you use <boolvar>++ and fix them.
All those places can be caught trivially by making ++ invalid for boolean
operators.
If they change the variable, they will have to check their code _anyway_.
Suppose they allocate booleans with malloc, and use sizeof(int) to
compute the size of a boolean? Suppose they print it out with printf;
is bool compatible with %d (or whatever format they're using)? Suppose
they read it in via scanf; is bool* compatible with int* ?
If they don't want to go through all that work, they can go on using
ints.
I can't imagine that "b++" is such an important idiom that it is worth
making the lives of millions of future programmers harder by making
C++ even more complicated than it already is.
James Kanze US/ESC 60/3/141 #40763
(Christopher R. Volpe) writes:
|> In article <3tusmn$m...@rover.village.org>, i...@village.org (Warner Losh) writes:
|> >In article <DBK0I...@crdnns.crd.ge.com>,
|> >Christopher R. Volpe <vo...@ausable.crd.ge.com> wrote:
|> >>I don't think this is an appropriate analogy. Offsetof is just as useful for
|> >>C++ as it is for C. C already allows you to take the address of structure
|> >>members. The result is a pointer to the type of the data member, and it works
|> >>exactly the same way as in C++. The "pointer to member" of C++ is actually a
|> >>"pointer to member FUNCTION", which is necessary in C++ due to the extra
|> >>"this" pointer that C++ member functions have. There is no analog of this in C.
|> >
|> >However, C++'s does have pointers to member DATA. They are quite
|> >useful and make things more typesafe if you want to initialize
|> >elements of a class from a data table.
|> Thanks. I wasn't aware of that. How are they more typesafe? And what type does
|> the "&" operator yield when applied to a class member of type int? Does it
|> yield "pointer to int" or "pointer to class member of type int"?
Pointer to class member of type int. Compare the following:
C (using offsetof):
struct S { int a ; int b ; } ;
size_t pi = offsetof( S , b ) ;
S* ps = &someS ;
*((int*)((char*)ps + pi)) = 1 ;
C++ (using pointer to member):
struct S { int a ; int b ; } ;
int S::* pi = &S::b ;
S* ps = &someS ;
ps->*pi = 1 ;
Note the casts in the C version. (For that matter, note the
complexity of the expression needed to access the value in C.)
|> > That sounds like a replacement
|> >to me.
|> Not to me. It doesn't seem to me that pointer to data member gives you
|> anything towards making offsetof obsolete that simply taking the address of a
|> struct field gives you. In C, the offsetof macro is useful despite the ability
|> to generate a pointer to a struct member. Whatever uses offsetof has in C
|> should still apply in C++ despite the existence of a more typesafe pointer
|> type.
What *is* the use of offsetof, other than the above? (To be truthful,
I've never used offsetof in C. I cannot say that pointers to member
data in C++ are that frequent in my code, either.)
|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
|> >big pain in the butt due the all the restrictions in their use that
|> >have recently been added to them (relative to a liberal reading of the
|> >ARM).
|> Such as? (Just curious)
I suspect that the original poster was referring to various
restrictions concerning casting of member pointers. Basically, the
ARM allowed casting from one class to another, *but* it did not define
the semantics of such a cast. In practice, the compilers I had access
to either did not allow the cast, or gave it reinterpret_cast syntax,
which basically made it useless, so I don't know why the poster
actually complaining. (Of course, without multiple inheritance,
reinterpret_cast and static_cast, which might have been useful,
actually generate the same code for most implementations. So if you
like to count on such chances...)
Andrew Koenig
> There's absolutely no justification in adding all sorts of stupid and
> non-obvious quirks to the bool type (such as the example under discussion
> of allowing the ++ operator) so that existing code "works without
> alteration" when the people who will be wanting to convert to using `bool'
> instead of `int' (or `unsigned char') will be having to edit their code
> *anyway* in order to do so.
Of course there is: that's what the committee voted for.
The main advantage of a democratic process is that the result is
acceptable to a large number of people. That is also the
main disadvantage.
--
--Andrew Koenig
a...@research.att.com
Jonathan de Boyne Pollard
: In article <3ueanu$5...@silver.jba.co.uk> JdeBP%uto...@jba.co.uk writes:
: >There's absolutely no justification in adding all sorts of stupid and
: >non-obvious quirks to the bool type (such as the example under discussion
: >of allowing the ++ operator) so that existing code "works without
: >alteration" when the people who will be wanting to convert to using `bool'
: >instead of `int' (or `unsigned char') will be having to edit their code
: >*anyway* in order to do so.
: It's much easier to edit a couple of variable declarations, or very often
: just one macro or typedef in a header file, than to find all the places
: where you use <boolvar>++ and fix them.
This is what line numbers in error messages are for! Sheesh!
: On the other hand,
: we know that there's a large amount of code out there that uses <bool>++,
: even though it's poor style.
No they do not. They use <int>++. There are *no* existing idioms for
bool, only idioms for using the boolean-esque features of int.
This is the whole point. People MISUSING booleans in that way can quite
easily change "++p" to "p = true" if the implementation gives a diagnostic
for the use of the `++' operator on a boolean.
It even allows the programmer to diagnose the case where they converted
`int' to `bool' and suddenly found that they were actually using the `int'
as a proper counter (rather than just a flag) in another part of the code.
Jonathan de Boyne Pollard
: In article <3ueanu$5...@silver.jba.co.uk> JdeBP%uto...@jba.co.uk writes:
:
: > There's absolutely no justification in adding all sorts of stupid and
: > non-obvious quirks to the bool type (such as the example under discussion
: > of allowing the ++ operator) so that existing code "works without
: > alteration" when the people who will be wanting to convert to using `bool'
: > instead of `int' (or `unsigned char') will be having to edit their code
: > *anyway* in order to do so.
:
:
: The main advantage of a democratic process is that the result is
: acceptable to a large number of people. That is also the
: main disadvantage.
If there was a justification in there, I missed it.
Clue : provide the *reasons* that the committee voted that way.
Jonathan de Boyne Pollard
: >Go too far down that road and you start defining silly things just in order
: >to keep things straight, such as defining semantics for left-shifting `true'
: >and `false' or whether implementations are allowed to represent !true and
: >~true with different bit patterns "under the covers".
: This is silly. No one (well, maybe I should play it safe and say hardly
: anyone) shifts boolean variables in existing code, so no one is going to
: propose that it be defined for the official bool type.
I said it was silly, but you were right to play it safe.
int p_flag = 0, q_flag = 0 ;
for ( int i = 0 ; i < argc ; ++i )
if (!strcmp(argv[i], "-p"))
p_flag = 1 ;
else if (!strcmp(argv[i], "-q"))
q_flag = 1 ;
int combined_flags = (q_flag << 3) | (p_flag << 7) ;
It may be desired to save `combined_flags' in a configuration file or in the
header of a data file, for example.
So ... how are you going to define "compatibility semantics" for left
shifting booleans, just on the off chance that the same programmer who
converted all of his other `int's to `bool's is now going to tackle the
above snippet ?
How far down this road do you have to go before you realise that what you
are doing is simply reinventing `int' ?
Warner Losh
James Kanze US/ESC 60/3/141 #40763 <ka...@lts.sel.alcatel.de> wrote:
>|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>|> >big pain in the butt due the all the restrictions in their use that
>|> >have recently been added to them (relative to a liberal reading of the
>|> >ARM).
>|> Such as? (Just curious)
>
>I suspect that the original poster was referring to various
>restrictions concerning casting of member pointers. Basically, the
>ARM allowed casting from one class to another, *but* it did not define
>the semantics of such a cast. In practice, the compilers I had access
>to either did not allow the cast, or gave it reinterpret_cast syntax,
>which basically made it useless, so I don't know why the poster
>actually complaining. (Of course, without multiple inheritance,
>reinterpret_cast and static_cast, which might have been useful,
>actually generate the same code for most implementations. So if you
>like to count on such chances...)
Excuse me, but I'm the original poster. And most compilers allowed
it. At least *ALL* of the compilers that I threw the OI library
against in the five years that I was working on it. These included
cfront, HP's compiler, DEC's cxx, IBM's xlC, GNU g++, a couple of
different Microsoft compilers and one or two others that have slipped
my mind (Lucid and Centerline maybe).
These casts were years before all the *_cast that are now in draft
versions of the standard. Member function pointers were quite useful
if you steered clear of MI, especially virtual base classes, but were
otherwise quite "robust", given that virtual functions had to work.
Basically, the code looks like (I no longer have access to the sources
in question, so there may be a couple of minor syntax errors in the
folowing):
class B
{ public: B(); ~B();
virtual void f();
};
typedef (B::*foo_memfnp)(void *, void *);
Now, if you derive a class D from class B that has a function that
takes two void *'s as parameters, then you could have code that looks
like the following:
class D : public B { void foo( void *, void *); };
D *d;
set_callback( d, (foo_memfnp) &D::foo );
where set_callback looks something like:
void set_callback( B * b, foo_memfnp )
{
cb = new cb( b, foo_memfnp );
}
and then later you can make a generic callback through cb as follows:
void * x;
void * y;
cb->callback( x, y )
void CB::Callback( void *a, void *b) {
(b->*mfp)( a, b );
}
(where b and mfp are members of class CB).
Notice that this method is allowed in the ARM, but it is unclear what
some of the language in the ARM means. One way of reading it is to
allow the above casting and calling. Another way of reading it is to
not allow it. The current standard, however, makes it clear that
calling through mfp produces undefined results.
That's the sort of change that I was complaining about :-). The
entire generic callbacks code in the OI library will have undefined
results when the standard is accepted and will need to be changed.
The OI library is a large hunk of code (on the order of 200K lines of
code, with callbacks strewn thoughout the entire code base).
I've moved on from the OI project, as have most people that know
enough about these problems to be concerned about the direction that
standarization is taking in this area. I just bring it up as an
example where the standards group, in their efforts to produce a
better language, broke existing practices. And these existing
practices were due to a more informal spec, which is why informal
specs are bogus (or am I confusing this thread with the HotJava
thread :-)?)
Warner
--
Warner Losh "VMS Forever" home: i...@village.org
Cyberspace Development, Inc work: i...@marketplace.com
Makers of TIA, The Internet Adapter. http://marketplace.com/
Thad Smith
ka...@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
>C (using offsetof):
>
> struct S { int a ; int b ; } ;
>
> size_t pi = offsetof( S , b ) ;
> S* ps = &someS ;
>
> *((int*)((char*)ps + pi)) = 1 ;
>
>What *is* the use of offsetof, other than the above? (To be truthful,
>I've never used offsetof in C. I cannot say that pointers to member
>data in C++ are that frequent in my code, either.)
I checked some recent code and found two uses with variable messages.
Consider a list of possible messages defined by structs (yes, I know
that the exact allocation is implementation-defined):
struct M1 { ... ; unsigned short crc; } m1;
struct M2 { ... ; unsigned short crc; } m2; /* different len */
AddCRC (&m1, offsetof(struct M1, crc));
AddCRC (&m2, offsetof(struct M2, crc));
Here AddCRC calculates the CRC of the message, for the given length
and places it at that offset.
Second use:
struct M3 { ...; unsigned char len; char data[16];} m3;
m3.len = messageLen;
SendMessage (&m3, offsetof (struct M3, data) + messageLen);
Here the data is the last element of M3 and is variable in length.
The second parameter of SendMessage specifies how many characters to
send (the message recipient knows how to handle variable length
messages).
Thad
>
>|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>|> >big pain in the butt due the all the restrictions in their use that
>|> >have recently been added to them (relative to a liberal reading of the
>|> >ARM).
>
>|> Such as? (Just curious)
>
>I suspect that the original poster was referring to various
>restrictions concerning casting of member pointers. Basically, the
>ARM allowed casting from one class to another, *but* it did not define
>the semantics of such a cast. In practice, the compilers I had access
>to either did not allow the cast, or gave it reinterpret_cast syntax,
>which basically made it useless, so I don't know why the poster
>actually complaining. (Of course, without multiple inheritance,
>reinterpret_cast and static_cast, which might have been useful,
>actually generate the same code for most implementations. So if you
>like to count on such chances...)
James Kanze US/ESC 60/3/141 #40763
Losh) writes:
|> In article <KANZE.95J...@slsvhdt.lts.sel.alcatel.de>,
|> James Kanze US/ESC 60/3/141 #40763 <ka...@lts.sel.alcatel.de> wrote:
|> >|> >C++ also has pointers to member FUNCTIONS which are, quite frankly, a
|> >|> >big pain in the butt due the all the restrictions in their use that
|> >|> >have recently been added to them (relative to a liberal reading of the
|> >|> >ARM).
|> >|> Such as? (Just curious)
|> >I suspect that the original poster was referring to various
|> >restrictions concerning casting of member pointers. Basically, the
|> >ARM allowed casting from one class to another, *but* it did not define
|> >the semantics of such a cast. In practice, the compilers I had access
|> >to either did not allow the cast, or gave it reinterpret_cast syntax,
|> >which basically made it useless, so I don't know why the poster
|> >actually complaining. (Of course, without multiple inheritance,
|> >reinterpret_cast and static_cast, which might have been useful,
|> >actually generate the same code for most implementations. So if you
|> >like to count on such chances...)
|> Excuse me, but I'm the original poster. And most compilers allowed
|> it. At least *ALL* of the compilers that I threw the OI library
|> against in the five years that I was working on it. These included
|> cfront, HP's compiler, DEC's cxx, IBM's xlC, GNU g++, a couple of
|> different Microsoft compilers and one or two others that have slipped
|> my mind (Lucid and Centerline maybe).
My experience is more limited, but g++ was the precise example of a
compiler which allowed it, but gave it useless semantics (those of
reinterpret_cast).
Since this is in comp.std.c, perhaps I should explain the
reinterpret_cast/static_cast business. The traditional C cast is in
fact overloaded: cast a double to int, and you get a conversion
(static_cast in the new C++ cast syntax). On the other hand, in
traditional C, casting a pointer would not change the bit pattern, but
was simple type punning (reinterpret_cast in the new C++ cast syntax).
When I refer to *_cast semantics, I am simply using a short-hand to
specify the semantics of the (C-style) cast: does it do an actual
conversion, or is it simply type-punning.
In C++, pointer casts within an inheritance hierarchy are
reinterpret_cast's, not static_casts. In particular, casting a
pointer to a derived class into a pointer to a base class will *not*
necessarily result in a pointer to the same physical bytes.
Similarly, the offset of an element relative to the base class may be
different from the offset of the same element relative to the derived
class. Thus, casting a `pointer to member' should be a static_cast.
The actual layout used by g++ (and most other compilers) make this
distinction unimportant in the case of single derivation, but it is
never the less there.
|> These casts were years before all the *_cast that are now in draft
|> versions of the standard. Member function pointers were quite useful
|> if you steered clear of MI, especially virtual base classes, but were
|> otherwise quite "robust", given that virtual functions had to work.
I agree, and would probably have preferred allowing them (and defining
the old cast syntax to have static_cast semantics). My contention is
simply that this was *not* existing practice; the compilers that
allowed them (most, I admit) implemented reinterpret_cast semantics.
You mention yourself the necessity of steering clear of MI; on all
implementations I am familiar with, there is no difference between a
static_cast and a reinterpret_cast except when MI is used, so I can
understand your statement that `they work'. On the other hand, I find
MI far more useful than pointers to members; in practice, the implemented
semantics of pointer to member casts made them useless as far as I was
concerned. (How can I be sure that my class will never participate in
multple inheritance.)
James Kanze US/ESC 60/3/141 #40763
Boyne Pollard) writes:
There is an obvious justification as to why the ++ operator is in the
C++ standard. In fact, it is the only allowable justification
according to the standards proceedure.
If you mean to say that this does not prove it is a good thing, then I
agree. But my idea of what is good may differ from yours; any such
`justification' I can give is not adequate to get something into (or
out of) the standard.
|> Clue : provide the *reasons* that the committee voted that way.
You'd actually have to ask each individual committee member.
At least one of the reasons why the authors of the proposal defined ++
for the bool type is that it wouldn't have passed in the committee
otherwise. Is that the justification you are looking for?
Richard A. O'Keefe
>we know that there's a large amount of code out there that uses <bool>++,
>even though it's poor style.
Um, it was about 1982 that I went through all my code making sure it didn't
do that any more. I switched to bvar |= 1 for a while, then I decided even
that was silly and switched to the obvious bvar = 1.
The reason I stopped using bar++ was that it broke. There was the sad day
when a program encountered 256 errors and reported none.
I think it is *vital* that bool++ ***NOT*** be allowed in any way, shape or
form, or at the very least that a diagnostic be required on every occurrence,
because code that has it is already broken. I do very much appreciate the
concern not to break existing *working* code, but I do not think that
silently covering up existing *bugs* helps anyone.
Note in particular that if anyone *did* intend the wrap-around-at-UCHAR_MAX
behaviour, and a maintainer *incorrectly* changes uchar to bool, the change
will introduce a bug that didn't previously exist. This does not strike me
as helpful either.
Today I start teaching a Software Creation and Maintenance course.
One of the things I am going to try, probably with the usual lack of
success, to pound into their heads is "ask for all the static checks
you can get; use the highest checking levels on cc, gcc, lcc, and any
other compilers you can get your hands on, use lint and LC-lint with
the highest checking levels, and any other static checkers you can."
The reason I am going to preach this sermon with all the fervour I can
summon is that every time I apply a new static check to existing C code
it finds old bugs that had been successfully hiding for years.
If bool++ were an operation that actually made sense for Booleans,
well, as it happens, it is. A lot of people think of the Booleans
as somehow related to the ring Z[[2]], in which addition corresponds
to exclusive or. I would expect
bool ++
to mean bool = bool + 1
and I would expect the + to be interpreted the "obvious" way, i.e.
bool = bool ^ 1
So the proposal is triply damnable:
(a) it will silently introduce bugs into correct code if an excusable
and likely maintenance error is made;
(b) it will silently mask bugs in what we are told is a "large amount"
of existing code, when the long-term cost is likely to be minimised
by exposing them (which can be done without breaking correct code)
(c) it will mislead new programmers
Save us from our "friends".
--
"The complex-type shall be a simple-type." ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Paul Eggert
>Today I start teaching a Software Creation and Maintenance course.
If you want to teach that course with a C-like language that has classes
and has the standard semantics for boolean, you might try Java;
the Java compiler complains `Invalid argument type boolean for ++'
when you try to apply ++ to a boolean value.
Sakari Jalovaara
> only means that the standards organization thinks that the feature is
> a bad thing, and is encouraging compiler writers to generate warnings.
Could a C/C++ standard _require_ that a conforming compiler must
diagnose deprecated features? (And that the program would still be
compiled after the diagnostics.)
++sja
Michael Cook
LW> All those places can be caught trivially by making ++ invalid for boolean
LW> operators.
LW> I can't imagine that "b++" is such an important idiom that it is worth
LW> making the lives of millions of future programmers harder by making
LW> C++ even more complicated than it already is.
By deprecating `b++' instead of making it ill-formed, the committee has
basically said, "a quality compiler should give you a warning if you do this"
rather than saying, "your existing code shall no longer compile."
IOW, you're not forced fix your `b++'s immediately.
That seems reasonable to me.
Michael.
Andrew Koenig
> If there was a justification in there, I missed it.
> Clue : provide the *reasons* that the committee voted that way.
Committee members are not generally required to justify their votes.
The arguments in both directions have been pretty well hashed out
in this newsgroup, I believe.
--
--Andrew Koenig
a...@research.att.com
hal...@caip.rutgers.edu
>It depends on the semantics you want. Personally, I'd like to say that
>bool can only be 0 or 1, so that `foo--' will always set it false, and
In article <DBpJA...@crdnns.crd.ge.com>, vo...@bart.crd.ge.com (Christopher R. Volpe) writes
> If the bool type can be only zero or one, I'm not sure I'd want "--" to be a
> valid operator for the type.
And I, if it is thus limited, want "--" and "++" to be the same,
and make 0 1 and 0 1
hal...@caip.rutgers.edu
> It shouldn't be strictly possible to 'add' booleans, etc. add is an operation
> on integral types, not booleans. However, one can obviously do it
> through a conversion to (int), so true + true == 2, and (bool)5 +
> (bool)12 == 2.
Nothing wrong with adding them: 0 = 0 + 0 = 1 + 1 --- 1 = 1 + 0 = 0 + 1 .
Quite all right. Note that this is equivalent to "not equal".
The trouble with the traditional logical operations is that thei are not
operations in the programming sens. Thei are static formulations of eternal
truths. It is better to take for a model the operations that electronic
engineers uze.
By the wai, I nevver liked, and nevver uzed, "++" for setting; instead
alwais " = 1 ". It is not enough for me that "++" is implemented with a
simple operation on the PDP-11. I suspect that this was the chief grounds
for this bad hack.
Anil Vijendran
Kanze US/ESC 60/3/141 #40763) said:
James> In article <3uh5dg$c...@silver.jba.co.uk> Jd...@jba.co.uk (Jonathan de
James> Boyne Pollard) writes:
James> |> Andrew Koenig (a...@research.att.com) wrote:
James> |> : In article <3ueanu$5...@silver.jba.co.uk> JdeBP%uto...@jba.co.uk writes:
James> |> :
James> |> : > There's absolutely no justification in adding all sorts of stupid and
James> |> : > non-obvious quirks to the bool type (such as the example under discussion
James> |> : > of allowing the ++ operator) so that existing code "works without
James> |> : > alteration" when the people who will be wanting to convert to using `bool'
James> |> : > instead of `int' (or `unsigned char') will be having to edit their code
James> |> : > *anyway* in order to do so.
James> |> :
James> |> : Of course there is: that's what the committee voted for.
James> |> :
James> |> : The main advantage of a democratic process is that the result is
James> |> : acceptable to a large number of people. That is also the
James> |> : main disadvantage.
James> |> If there was a justification in there, I missed it.
James> There is an obvious justification as to why the ++ operator is in the
James> C++ standard. In fact, it is the only allowable justification
James> according to the standards proceedure.
James> If you mean to say that this does not prove it is a good thing, then I
James> agree. But my idea of what is good may differ from yours; any such
James> `justification' I can give is not adequate to get something into (or
James> out of) the standard.
James> |> Clue : provide the *reasons* that the committee voted that way.
James> You'd actually have to ask each individual committee member.
James> At least one of the reasons why the authors of the proposal defined ++
James> for the bool type is that it wouldn't have passed in the committee
James> otherwise. Is that the justification you are looking for?
Isn't it rather ironic that Dr Stroustrup once talked about C++ never
being influenced by a committee or consensus?
No matter what you say, in this thread itself I'm yet to see one
person who argues (other than by citing majority) this (operator++ on
bool) is the most intuitive/right/reasonable (or only) thing to do.
I'm afraid that Jonathan's remark about "found" being used as a count
of the number of items found (as opposed to a *boolean* "found") could
turn out to be true. I've done it myself when extending code written
by someone else i.e seen "more" to what his code does than what he
intended and used it to my advantage. Imagine such a piece of legacy
code in a library...
One of the characteristics of a programming language is to prevent
multiple interpretations (or semantic overloading) of code
fragments. The ground irony is that this was a guiding principle in
not allowing user defined operators or user defined semantics
(precedence and sisters) to existing operators (and cautioning people
to overload existing operators with semantics as close as possible to
the "generally" accepted idea). Now builtin operators have
non-intuitive semantics on builtin types!
There is certainly the possibility that the majority that voted for
operator++ on bool wasn't aware of the dangers of
misinterpretation. Maybe they weren't so serious about it in the first
place. I'd expected majority to be balanced with reasoning. But in
this case, reasoning has had no place.
By the way, these are my personal opinions.
--
Peace.... +<:-)
James Kanze US/ESC 60/3/141 #40763
Jalovaara) writes:
I suppose that a standard could mandate just about anything that the
standardization committee wanted:-). In practice, this has always
been treated as a quality of implementation issue.
I suspect that this is correct. Basically, the current standards
divide programs into three large categories (for a given
implementation):
1. Those which are correct. The implementation must compile and run
them correctly (within the bounds of the implementations resource
limits). Note that even for these programs, the implementation is
allowed to generate diagnostic messages.
2. Those which have an error requiring a diagnostic. The
implementation must generate an error message. It may or may not
compile them, allow them to run, or anything else.
3. Those with undefined behavior. No further comment necessary.
Since the quality of the diagnostic messages is not mandated, and a
diagnostic is only required for the first error, a compiler which
*always* outputs the string "?" and always generates some program is,
strictly speaking, conforming.
Requiring warnings would, basically, introduce an additional category
between 1 and 2. But since in fact, a compiler is free to treat cases
1 and 2 exactly the same today, I don't think it is worth the effort.
(In practice, most compilers *do* try and distinguish between
diagnostics generated in case 1 and those in case 2, and most not
generate executable code in case 2. But the same market forces that
impose this will effectively mandate warnings for deprecated behavior,
without any additional requirements in the standard. I hope.)
Wil Evers
> At least one of the reasons why the authors of the proposal defined ++
> for the bool type is that it wouldn't have passed in the committee
> otherwise.
How interesting! If the advocates of the built-in bool would have done the
right thing, which is not to define ++ on it, than the committee would
have done the right thing too, which is not to have the built-in bool at
all. The built-in bool is just an unfortunate accident!
(Sorry, I just couldn't resist.)
- Wil
Stephen Baynes
: Of course there is: that's what the committee voted for.
: The main advantage of a democratic process is that the result is
: acceptable to a large number of people. That is also the
: main disadvantage.
: --
I hardly call the committee a democracy - they are not even elected. Even if
they were representative-democracy is not as good as participative-democracy
in producing a result acceptable to a large number of people.
--
Stephen Baynes bay...@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton My views are my own.
United Kingdom
hal...@caip.rutgers.edu
> But the same market forces that
> impose this will effectively mandate warnings for deprecated behavior,
> without any additional requirements in the standard. I hope.
Even when the deprecation is foolish, as the case of 'long float'. Types
'float' and 'double' are nothing but variants of one basic arithmetic type,
and the use of "double" instead of "long float" alwais was a mistake.
Likewize, the use of bare "short" or "long" is best considerd reallie an
abbreviation, wherin 'int' is afforded when an incomplete type is forbidden.
hal...@caip.rutgers.edu
>
> 1. 0 and 1 are *not* legal values for a bool type. The only legal
> values are true and false. When cast to an int (implicitly or
> explicitly), false must yield 0 and true 1, and I suspect that most
> implementations will in fact use 0 an 1 to implement bool at the
> hardware level (but this is not required).
This behavior is not appropriat for C. Indeed, "true" and "false" are gilded
lilie for C. One who wants them can doo this:
enum { false = 0, true = 1 };
> 2. In a real sense, `++' is not a valid operator for a bool type....
One is free to make it mean anithing that one wants it to mean, and there
is nothing wrong with the meaning that ++ makes a 'bool' 1 and -- makes
it fals. From the practical point of programming this is an extreemlie
useful operation. Restricting the operators to the ones found in logic
greatlie lessens the type s usefulness. The mathematical viewpoint
and the programming-viewpoint of two-state variables barelie overlap.
Mathematical logic deals with truth (and therefore more states than
twain are alloud in modern logic) and programming deals with state.
Norman Diamond
>In article <3u1113$p...@fido.asd.sgi.com> sha...@engr.sgi.com writes:
>> I guess the intent was that implementations can quietly implement bool as
>> "unsigned char" and do nothing else, but that's clearly silly, since they
>> would still have to guard against 256 ++'s in a row.
>The intent is to allow programmers who use int values as booleans
>and set them to true by applying ++ to them to change them to type bool
>without changing alll the places they're used.
>Wise or not, the practice of using ++ to make a variable "true"
>is widespread.
Wise and/or not, the practices of using printf() and malloc() without
bothering to #include relevant headers or declare them also used to be
widespread. The C standard could have allowed C programmers to continue
these lazy practices as well, only causing nuisances to implementors and
not even costing execution time, but it didn't.
I think I have to agree with someone else's posted opinion, this issue
best shows how C++ is being made as ugly as possible.
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
James Kanze US/ESC 60/3/141 #40763
writes:
Just to clarify a little:
1. 0 and 1 are *not* legal values for a bool type. The only legal
values are true and false. When cast to an int (implicitly or
explicitly), false must yield 0 and true 1, and I suspect that most
implementations will in fact use 0 an 1 to implement bool at the
hardware level (but this is not required).
2. In a real sense, `++' is not a valid operator for a bool type. It
is a `tolerated' operator, for reasons of compatibility with old code.
(I know that the standard doesn't have this type of distinction, but I
think it helps put the actual situation in perspective.)
If C is to adapt a bool type, I see two alternatives:
1. Adapt the C++ bool type, with eventual deprecation of the implicit
type conversions.
2. Create a real bool type, with no legal type conversions, implicit
or otherwise.
From the point of view of language theory and elegance, there is no
doubt that 2 would be the better solution. From a practical point of
view, adapt 2 and you no longer have C. (It is hard to imagine an
existing C program which wouldn't break.)
My vote would be for 1, with deprecation of the implicit conversions.
Mr.H
allowing ++ and -- operations on bool values has to do with the
effect that creating a built-in boolean type will have on existing
code. What about this: call the boolean type something other than
'bool' or 'boolean'. Don't ask me what, I don't get paid for that.
If the name were changed, let's call it 'foo' for the sake of argument,
then the vast majority of code out there could continue to use existing
conventions and header files. That code would not break. On the
other hand, those who wish to begin using a built-in, supported boolean
type could re-write or begin new implementations using foo from the
get go. The standards committee would be free to impose whatever
limited set of operators that truly makes sense for the type, and
nobody (at least very few people) would run into broken code by
accident. Thoughts?...
--
-------------------------------------------------------------------
-- Mr.H - mi...@mrhappy.if.com --
-- All opinions expressed herein are my own... right? --
-- "Things are more like they are now than they have ever been." --
-- - Gerald Ford --
-------------------------------------------------------------------
Steve Clamage
>Andrew Koenig (a...@research.att.com) wrote:
>
>: Of course there is: that's what the committee voted for.
>
>: The main advantage of a democratic process is that the result is
>: acceptable to a large number of people. That is also the
>: main disadvantage.
>
>
>Stephen Baynes bay...@mulsoc2.serigate.philips.nl
>Philips Semiconductors Ltd
>Southampton My views are my own.
>United Kingdom
Sure they are. Every organization with a legitimate interest in C++ can elect
its own representative. If you are not employed by such an organization, you
can even elect yourself to represent yourself. That seems to me to be more
democratic than the governmental systems of the US or the UK. Can Philips
Semiconductors get a vote in Parliament?** It can get a vote in X3J16. The
"poll tax" for voting in X3J16 is higher than for voting in the US or UK,
but much less than the cost of becoming elected to Parliament or Congress.
No campaigning is necessary, only one self-electing letter.
**Please, no jokes about buying legislators.
---
Steve Clamage, stephen...@eng.sun.com
Paul Long
>What about this: call the boolean type something other than
>'bool' or 'boolean'.
Some language, possibly PL/I, called these things "logicals," as in
logical p;
How about "logical?"
--
Paul Long 45:29:14N 122:48:09W
pl...@perf.com http://www.teleport.com/~pciwww/
"Wagging head and tail, the red-tailed fish, unsupported, turns around."
Victor Bazarov
ka...@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
>If C is to adapt a bool type, I see two alternatives:
>
>1. Adapt the C++ bool type, with eventual deprecation of the implicit
>type conversions.
What is "C++ bool type"? I missed it somehow...
>
>2. Create a real bool type, with no legal type conversions, implicit
>or otherwise.
Once it was a perfect language -- called "C". Someone has come and added type
called "bool". Language lost it's perfection. Just like that!
The less types, the better!
Long live AWK! :-)
Victor.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If it's stupid, but works, it isn't stupid.
Murphy
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tony Bass
> It seems to me that the problem almost everyone is having with
> allowing ++ and -- operations on bool values has to do with the
> effect that creating a built-in boolean type will have on existing
> code. What about this: call the boolean type something other than
> 'bool' or 'boolean'. Don't ask me what, I don't get paid for that.
How about "cool"?
C defined its special operators on integers, distinguishing zero and
non-zero, allowing all sorts of boolean programming by just using
integers, albeit less type-safely. Given this history of something so
written into the language, attempts to define a separate bool in C++ are
bound to compromise something.
My own preference in C is to keep using zero and non-zero ints, though
of course I would gladly use a bool type in a language that had it
designed in from the start. Perhaps a C++ bool will be separate enough
from C history that I can use it - I half hope so.
Tony Bass
--
# Tony Bass Tel: (01473) 645305
# MLB 3/19, BT Laboratories e-mail: a...@saltfarm.bt.co.uk
# Martlesham Heath, Ipswich, Suffolk, IP5 7RE DO NOT e-mail to From: line
# Opinions are my own
Peter Curran
US/ESC 60/3/141 #40763 (ka...@lts.sel.alcatel.de) wrote
[snip]
: 2. In a real sense, `++' is not a valid operator for a bool type. It
: is a `tolerated' operator, for reasons of compatibility with old code.
: (I know that the standard doesn't have this type of distinction, but I
: think it helps put the actual situation in perspective.)
[snip]
(Others have made similar comments,)
I don't understand this at all. At present there is no boolean type
in C, so how can there be any issue of compatibility with old code?
Of course there is lots of code that simulates a boolean type using
existing C facilities, but that code has to be changed regardless if
it is to be used with any new type. There are all sorts of problems
doing this, but why pick on the "++" operator as one the standard
should worry about, and ignore all the others (e.g. the problems
that will result whenever a new keyword is introduced)?
IMHO, if a boolean type is introduced into C, it should be done in a
way that makes most sense in its own right. (e.g. NO ++/-- operators,
as far as I'm concerned.) Any existing code that doesn't like this
new type as defined doesn't have to use it - the worst result is that
the name of it's boolean type has to be changed to avoid conflict with
the new keyword (and that will be obvious in most cases, such as in a
typedef statement, will cause compile errors.)
Anyhow, my point, I don't understand how compatibility with old code
is an issue when discussing an entirely new feature.
--
Peter Curran pcu...@isgtec.com
ISG Technologies, Inc (905) 672-2100 X315
6509 Airport Road, http://www.isgtec.com Fax (905) 672-2307
Mississauga, Ontario, Canada Usual disclaimers apply
Mark Brader
If we're talking about C (it's hard to tell, since this entire thread
is cross-posted), I'd say that there's absolutely no justification for
adding a "bool type" to the language in the first place, and good reason
(as covered in the comp.lang.c FAQ list) not to do so.
--
Mark Brader, m...@sq.com "C and C++ are two different languages.
SoftQuad Inc., Toronto That's UK policy..." -- Clive Feather
This article is in the public domain.
Michael Shields
James Kanze US/ESC 60/3/141 #40763 <ka...@lts.sel.alcatel.de> wrote:
> 1. 0 and 1 are *not* legal values for a bool type. The only legal
> values are true and false. When cast to an int (implicitly or
> explicitly), false must yield 0 and true 1, and I suspect that most
> implementations will in fact use 0 an 1 to implement bool at the
> hardware level (but this is not required).
Wouldn't `b = 1' be implicitly `b = (bool) 1' and thus `b = true'?
Or are casts from int to bool undefined, despite the asymmetry?
> If C is to adapt a bool type, I see two alternatives:
>
> 1. Adapt the C++ bool type, with eventual deprecation of the implicit
> type conversions.
>
> 2. Create a real bool type, with no legal type conversions, implicit
> or otherwise.
>
> From the point of view of language theory and elegance, there is no
> doubt that 2 would be the better solution. From a practical point of
> view, adapt 2 and you no longer have C. (It is hard to imagine an
> existing C program which wouldn't break.)
I assume that by `break' you mean `not be able to use the new boolean
type just as they used to use integers'. I don't see this as a flaw;
if the boolean type is just a plug-in replacement for int, it has no
advantages over int. And existing code with `bool' typedefs wouldn't
break if another name is used, say `logical' or `tf'.
Someone else said "the fewer types, the better". I think the real wish
is for *simplicity* in the type structure. A clean boolean type would
avoid reinventing int.
--
Shields.
Andrew Koenig
> If we're talking about C (it's hard to tell, since this entire thread
> is cross-posted), I'd say that there's absolutely no justification for
> adding a "bool type" to the language in the first place, and good reason
> (as covered in the comp.lang.c FAQ list) not to do so.
That may be true for C, but C doesn't have overloading.
With overloaded functions, the case for bool being a
separate type is much stronger.
--
--Andrew Koenig
a...@research.att.com
larry...@sdrc.com
> The traditional C cast is in
> fact overloaded: cast a double to int, and you get a conversion
> (static_cast in the new C++ cast syntax). On the other hand, in
> traditional C, casting a pointer would not change the bit pattern, but
> was simple type punning (reinterpret_cast in the new C++ cast syntax).
This is a common misconception, but it's just plain wrong. *All* C
casts cause a conversion (except when you're casting to the same type).
Just because there are some occasions where the two types have the same
representation, that doesn't mean that no conversion has occurred. For
example, on a machine where int and long have the same representation,
casting an int to long doesn't change the bit pattern, but it does
change the type. Similarly, casting an int * to a char * where all
pointers have the same representation doesn't change the bit pattern,
but the type changes. There's still a conversion, it just doesn't
require any code.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH 45150-2789 513-576-2070
larry...@sdrc.com
He's just jealous because I accomplish so much more than he does. -- Calvin
FFarance
>
> > There's absolutely no justification in adding all sorts of stupid and
> > non-obvious quirks to the bool type (such as the example under
discussion
> > of allowing the ++ operator) ...
>
> is cross-posted), I'd say that there's absolutely no justification for
> adding a "bool type" to the language in the first place, and good reason
> (as covered in the comp.lang.c FAQ list) not to do so.
A boolean type isn't really required in C, assuming you believe that
"bool" is just another name for "int". However ...
(The following is a summary of most of the issues to be resolved
for standardizing a boolean type in C9X.)
IMPLEMENTATION ISSUES
If you believe that a boolean type represents ``true'' and
``false'' and that happens to be mapped into some integral type, then
you might be interested in its implementation. A boolean type
can have several implementations, based upon the requirements of the
programmer. For example, performance attributes (fast, small,
unoptimized)
and addressibility (yes or no) are important implementation issues. This
is probably one of the reasons there are differing implementations of
the boolean type, yet similar semantics (they all can store ``true''
and ``false'' values). The following are some possible implementations:
Performance Addressible Candidates
fast yes int (the machine's fastest type)
fast no int (the machine's fastest type)
unoptimized yes char, short, int (imp-defined)
unoptimized no bit field, char (imp-defined)
small yes char
small no bit field
These issues are similar to the extended integer range proposals
in C9X (i.e., performance attributes, addressibility) -- see the
``Why "long long" doesn't work'' thread on "comp.std.c". These
implementation issues concern the native type that the boolean
type is mapped into.
PROMOTION RULES
An important issue is promotion rules (another extended integer range
issue). There aren't problems with assigning "true" or "false",
testing a value with "true" or "false", testing in a conditional
statement, or converting to an arithmetic type (i.e., "false" ==> 0,
"true" ==> 1). But what conversions do we allow to the boolean
type? We could probably agree that 0 and 1, when assigned to a
boolean type, result in "false" and "true", respectively. But
what about other values? Does non-zero mean true, or the low
order N bits == 0 (demotion to bit field, "char", or "short", or
"int").
OPERATORS
What operators are allowed? Is it only "=" and "!", or are there
other operators (e.g., "++", "--", "&=", "|=", etc.) that are
allowed?
LIBRARY FUNCTIONS
What library functions do you need? If the boolean type is an
abstract type, then you need conversion functions to/from text
(e.g., format specifiers for "printf" and "scanf").
BINDING
How will you bind this to C? Will there be a single boolean
implemenation (e.g., "bool" is always equivalent to "int") or
will there be performance tuning (e.g., "fast bool", "small bool",
"bool:1")? Is "bool" a "typedef", a macro, or a keyword? Is the
boolean type equivalent to an "enum", an integral type, or something
else? Is a header (e.g., "<bool.h>") required to use the type?
RELATED STANDARDS
WG14 is investigating a C binding to WG11's Language Independent
Datatypes draft standard (ISO DIS 11404). This draft standard
includes a boolean data type.
CONCLUSION
The discussion in WG14 has been favorable with respect to a
boolean type. I think there is much agreement on the following
points (of course, these are the easiest issues):
- "bool" will not be a keyword. This will break much code.
- The header "<bool.h>" must be included to access the
boolean type named "bool".
- The identifiers "true" and "false" are the boolean values.
- Assignment, negation ("!"), and use in conditional statements.
The following areas are fuzzy, but this is my guess of the probable
outcome:
- Conversion of 0 and 1 to a boolean type will be well-defined.
- Conversion of other values will be undefined (just as
overflow may produce undefined behavior).
- The implementor will have their choice of implementing it
as some existing integral type in C (e.g., "char", "short",
"int"), an "enum", or something else.
- There will be a feature test macro to determine if "bool"
is present as a keyword. This is a compatibility feature
with C++ because they (unfortunately, IMO) bound "bool" as
as keyword, rather the using an include file to turn on
the behavior (which would define the macro "bool" as whatever).
The following areas are fuzzy, but I don't have a clue as to their
outcome or existence in C9X:
- Additional format specifiers in "printf" and "scanf".
- Additional operators.
- Performance tuning.
- Use of "bool" in structure bit fields.
The following WG14 people have been active in the discussion of the
boolean type:
Frank Farance
Clive Feather
Francis Glassborow
Doug Gwyn
Tom Plum
John Washington
You might contact them directly if you want to voice some of your
concerns for C9X.
-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: fr...@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor
John Max Skaller
>In article <DBK0I...@crdnns.crd.ge.com>,
>Christopher R. Volpe <vo...@ausable.crd.ge.com> wrote:
>>I don't think this is an appropriate analogy. Offsetof is just as useful for
>>C++ as it is for C.
Only because C++ messed up the model of pointers to members
badly. IMHO.
>However, C++'s does have pointers to member DATA. They are quite
>useful and make things more typesafe if you want to initialize
>elements of a class from a data table. That sounds like a replacement
>to me.
They are NOT a replacement at present. The C++ ptm
system is functionally incomplete and provided invalid facilities.
See below.
>C++ also has pointers to member FUNCTIONS which are, quite frankly, a
>big pain in the butt due the all the restrictions in their use that
>have recently been added to them (relative to a liberal reading of the
>ARM).
I voted IN FAVOUR of those restrictions. I object
to the hijacking of pointers to members to provide
dynamic binding facilities which ought to have been provided
by a mechanism designed for that.
My model of ptms is "A ptm is a typed offset".
NEITHER the ARM or WG21 model implements that.
You can regard the restrictions as damage control --
restricting the semantics to that which enables any one of the
several ptm models as an extension.
--
JOHN (MAX) SKALLER, INTERNET:max...@suphys.physics.su.oz.au
Maxtal Pty Ltd,
81A Glebe Point Rd, GLEBE Mem: SA IT/9/22,SC22/WG21
NSW 2037, AUSTRALIA Phone: 61-2-566-2189
John Max Skaller
James Kanze US/ESC 60/3/141 #40763 <ka...@lts.sel.alcatel.de> wrote:
>
>for the bool type is that it wouldn't have passed in the committee
To clarify: ++ on bool isn't just defined.
Its defined AND DEPREACTED. WG21 voted in and
deprecated a feature at the same time. This was to facilitate
a smooth transition from
#define bool int
to
#if !defined(__cplusplus__)
#define bool int
#endif
in a single system wide header file -- a few seconds work --
with a minimum number of changes to most other source files.
Anyone writing _new_ code using ++ on bool should be shot.
Everyone ought to start fixing the remaining uses of ++ on
bool because it will probably be banned in the second C++ Standard.
Jason Merrill
> CONCLUSION
> The discussion in WG14 has been favorable with respect to a
> boolean type. I think there is much agreement on the following
> points (of course, these are the easiest issues):
> - "bool" will not be a keyword. This will break much code.
> - The header "<bool.h>" must be included to access the
> boolean type named "bool".
> - The identifiers "true" and "false" are the boolean values.
> - Assignment, negation ("!"), and use in conditional statements.
> The following areas are fuzzy, but this is my guess of the probable
> outcome:
> - Conversion of 0 and 1 to a boolean type will be well-defined.
> - Conversion of other values will be undefined (just as
> overflow may produce undefined behavior).
Will conditions take expressions of type bool? How about ||, &&, ?: and ! ?
If so, conversion of values other than 1 and 0 must be defined. In any
case, it seems silly to introduce a discrepancy between conversions to bool
and parts of the language that already take boolean values; if || treats
integer 42 as 'true', it should convert to boolean 'true'.
Jason
James Kanze US/ESC 60/3/141 #40763
bay...@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
|> Andrew Koenig (a...@research.att.com) wrote:
|> : Of course there is: that's what the committee voted for.
|> : The main advantage of a democratic process is that the result is
|> : acceptable to a large number of people. That is also the
|> : main disadvantage.
|> : --
|> I hardly call the committee a democracy - they are not even elected. Even if
|> they were representative-democracy is not as good as participative-democracy
|> in producing a result acceptable to a large number of people.
But the committee is actually a participative democracy. Anyone who
wants can join the committee and vote.
(Actually, there is a restriction: if your employer is a member, you
may not join. This is to prevent ballot box stuffing.)
James Kanze US/ESC 60/3/141 #40763
writes:
|> In article <KANZE.95J...@slsvhdt.lts.sel.alcatel.de>
|> ka...@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> > At least one of the reasons why the authors of the proposal defined ++
|> > for the bool type is that it wouldn't have passed in the committee
|> > otherwise.
|> How interesting! If the advocates of the built-in bool would have done the
|> right thing, which is not to define ++ on it, than the committee would
|> have done the right thing too, which is not to have the built-in bool at
|> all. The built-in bool is just an unfortunate accident!
Actually, I would argue that C/C++ have always had a boolean type.
After all, there are definitely situations where the compiler
generates code which makes a yes/no or true/false decision, which is
the fundamental characteristic of a boolean type.
The ``problem'' with C/C++ is that there is (or was) no way for the
user to define a variable with such a type, or even write an
expression with such a type. Instead, the programmer must depend on a
variety of sometimes confusing implicit type conversions. (Quick:
does strcmp return true or false when the strings match.) The
presence of such conversions (and the supposed absense of a boolean
type) has in turn lead to a number of questionable idioms: `if ( p )',
`while ( *p )', etc. While professional programmers quickly learn to
understand them in other's code, and avoid them in their own, such
idioms *do* cause confusion, particularly with less skilled
programmers.
FFarance
> ...
> > CONCLUSION
>
> > The discussion in WG14 has been favorable with respect to a
> > boolean type. I think there is much agreement on the following
> > points (of course, these are the easiest issues):
>
> > - "bool" will not be a keyword. This will break much code.
> > - The header "<bool.h>" must be included to access the
> > boolean type named "bool".
> > - The identifiers "true" and "false" are the boolean values.
> > - Assignment, negation ("!"), and use in conditional statements.
> ...
> Will conditions take expressions of type bool? How about ||, &&, ?: and
! ?
You probably missed the sentence I highlighted above in my original
posting. Yes, they can be used in conditions (e.g., "if", "switch",
"for", "while", "||", "&&", "?:", "!", "==").
hal...@caip.rutgers.edu
> Are you claiming that there is no place in C where a predicate is
> used. That `if' or `while' don't make a binary decision.
>
> C in fact has a boolean type; it just keeps it a secret (and thus
> forces the programmer to depend on implicit conversions).
Yes, "if" and "while" make a binarie decizion--so what?
Fortran had a three-valud type becauz it had arithmetic "if"?
C has no boolean type.
hal...@caip.rutgers.edu
> After all, there are definitely situations where the compiler
> generates code which makes a yes/no or true/false decision, which
> is the fundamental characteristic of a boolean type.
In real code this almost nevver is found except in conditional
expressions. Therefore there is no need for a variable, for the
condition almost nevver is stord. Stord conditions often hav more
than twain states, even as "strcmp" returns (Happens I hav longd for
Fortran s three-way "if", although not in its original "goto"ish form).
James Kanze US/ESC 60/3/141 #40763
(Victor Bazarov) writes:
|> In article <KANZE.95J...@slsvhdt.lts.sel.alcatel.de>,
|> ka...@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
|> >If C is to adapt a bool type, I see two alternatives:
|> >
|> >1. Adapt the C++ bool type, with eventual deprecation of the implicit
|> >type conversions.
|> What is "C++ bool type"? I missed it somehow...
A boolean type. The results of the comparison operators, and
operators `&&' and `||'. The type used by `if', `while' and `do
... while'.
In C, only the latter is a boolean type, although since you cannot
write an expression of boolean type, you have to depend on implicit
conversions to get it.
|> >2. Create a real bool type, with no legal type conversions, implicit
|> >or otherwise.
|> Once it was a perfect language -- called "C". Someone has come and added type
|> called "bool". Language lost it's perfection. Just like that!
If you consider C perfect, then I suspect that you hold it in higher
estime than its authors.
|> The less types, the better!
|> Long live AWK! :-)
I love AWK myself, but... I only put up with its lack of a boolean
type because it only has one type (and thus, no declarations, etc.).
This is not the case with C.
The languages are both generally adequate (AWK is actually superb),
but they address different problems.
James Kanze US/ESC 60/3/141 #40763
|> > There's absolutely no justification in adding all sorts of stupid and
|> > non-obvious quirks to the bool type (such as the example under discussion
|> > of allowing the ++ operator) ...
|> If we're talking about C (it's hard to tell, since this entire thread
|> is cross-posted), I'd say that there's absolutely no justification for
|> adding a "bool type" to the language in the first place, and good reason
|> (as covered in the comp.lang.c FAQ list) not to do so.
Are you claiming that there is no place in C where a predicate is
used. That `if' or `while' don't make a binary decision.
C in fact has a boolean type; it just keeps it a secret (and thus
forces the programmer to depend on implicit conversions).
Jason Merrill
> Anyone writing _new_ code using ++ on bool should be shot.
As someone else pointed out, bool++ is a nice shorthand for test-and-set.
The only alternative is much more verbose:
inline bool test_and_set (bool& flag)
{
bool b = flag; flag = true; return b;
}
...
if (test_and_set (initialized))
return;
init ();
...
Perhaps they should only be chastized. :)
Jason
James Kanze US/ESC 60/3/141 #40763
|> In article <KANZE.95J...@slsvhdt.lts.sel.alcatel.de>, ka...@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> > The traditional C cast is in
|> > fact overloaded: cast a double to int, and you get a conversion
|> > (static_cast in the new C++ cast syntax). On the other hand, in
|> > traditional C, casting a pointer would not change the bit pattern, but
|> > was simple type punning (reinterpret_cast in the new C++ cast syntax).
|> This is a common misconception, but it's just plain wrong. *All* C
|> casts cause a conversion (except when you're casting to the same type).
|> Just because there are some occasions where the two types have the same
|> representation, that doesn't mean that no conversion has occurred. For
|> example, on a machine where int and long have the same representation,
|> casting an int to long doesn't change the bit pattern, but it does
|> change the type. Similarly, casting an int * to a char * where all
|> pointers have the same representation doesn't change the bit pattern,
|> but the type changes. There's still a conversion, it just doesn't
|> require any code.
This is why I said `traditional' C, instead of simply C or standard C.
Most people have traditionally (albeit incorrectly) considered pointer
casts in C to be simple type punning, and not conversion. (Even
considering the cast to be type punning on the type pointed too is not
strictly correct; the result of casting a char* to an int* may not
point to the same physical byte.)
I'm still looking for a good, short way of explaining the difference
between static_cast and reinterpret_cast (to use the C++ syntax) when
applied to a pointer. (Add inheritance to C, and it will potentially
have the same problem.)
Todd Blanchard
: In article <1995Jul22.0...@sq.sq.com> m...@sq.sq.com (Mark Brader) writes:
: > If we're talking about C (it's hard to tell, since this entire thread
: > is cross-posted), I'd say that there's absolutely no justification for
: > adding a "bool type" to the language in the first place, and good reason
: > (as covered in the comp.lang.c FAQ list) not to do so.
: That may be true for C, but C doesn't have overloading.