Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #16269 > unrolled thread
| Started by | Avinash Sonawane <avinash.sonawane1990@gmail.com> |
|---|---|
| First post | 2012-01-26 13:59 -0800 |
| Last post | 2012-01-27 11:12 -0600 |
| Articles | 20 on this page of 100 — 30 participants |
Back to article view | Back to comp.lang.c
About -lm switch used for linking math.h Avinash Sonawane <avinash.sonawane1990@gmail.com> - 2012-01-26 13:59 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-26 14:15 -0800
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-26 17:17 -0500
Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-26 20:54 -0500
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 02:12 +0000
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-26 23:29 +0100
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-26 23:09 -0700
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-27 08:37 +0100
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 09:48 +0000
OT:Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-27 10:15 +0000
Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 14:43 +0000
Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 07:49 -0800
Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 15:55 +0000
Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:14 -0800
Re: OT:Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:23 -0800
Re: OT:Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 09:42 -0700
Re: OT:Re: About -lm switch used for linking math.h 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:08 -0800
Re: OT:Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:14 +0200
Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 16:56 +0000
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 17:50 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:58 +0000
Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:15 -0800
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 19:25 +0000
Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-28 18:09 +0000
Re: About -lm switch used for linking math.h jt@toerring.de (Jens Thoms Toerring) - 2012-01-27 21:32 +0000
Re: About -lm switch used for linking math.h "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2012-01-27 12:40 +0100
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 12:48 +0000
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-27 14:28 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:14 +0000
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 10:43 -0700
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 12:25 -0600
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 18:41 +0000
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 13:45 -0500
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:29 -0800
Re: About -lm switch used for linking math.h Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-27 22:35 +0100
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 17:19 -0600
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 19:22 -0500
Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:32 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:26 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 13:30 +1300
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 17:04 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:10 +1300
Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-27 21:06 -0500
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:09 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:15 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 23:03 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 19:10 +1300
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-28 04:28 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-28 15:25 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:39 +1300
Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:53 -0800
Re: About -lm switch used for linking math.h Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-03 10:39 +0000
Re: About -lm switch used for linking math.h Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-01 16:42 -0800
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-02-02 01:29 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:22 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-29 16:52 -0600
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:04 -0800
Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-01-30 10:22 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:36 -0800
Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:33 +0200
Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-02-14 23:48 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-02-14 16:35 -0800
Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:44 +0200
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-30 04:30 -0800
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 14:36 +0000
Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:50 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:29 -0800
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 09:11 -0800
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-29 17:49 +0000
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 10:07 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-29 14:24 -0800
Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:43 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:54 -0800
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 01:09 +0000
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:20 +1300
Re: About -lm switch used for linking math.h Azazel <azazel@remove.azazel.net> - 2012-01-30 17:40 -0600
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-31 00:05 +0000
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-27 20:03 +0000
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-27 12:26 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:24 +1300
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 21:32 +0000
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 16:39 -0500
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-27 23:24 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 20:38 +1300
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 02:17 -0600
Re: About -lm switch used for linking math.h Richard Damon <news.x.richarddamon@xoxy.net> - 2012-01-28 14:07 -0500
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 15:07 -0600
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-28 21:09 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 21:39 -0700
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-28 11:21 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-28 17:51 -0700
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-29 02:03 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 18:58 +0000
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-28 20:48 +0100
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 22:54 -0600
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-29 21:42 +0000
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-30 00:14 -0600
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 11:12 -0600
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-27 16:26 -0800 |
| Message-ID | <lnd3a43c56.fsf@nuthaus.mib.org> |
| In reply to | #16322 |
Stephen Sprunk <stephen@sprunk.org> writes:
[...]
> "_Bool" is a hack around the fact there is no way to introduce a new
> basic type in a header file. "bool" is what the standard was really
> trying to introduce, but that is a typedef to "_Bool" that one gets by
> including <stdbool.h>.
"bool" is a macro, not a typedef (I'm not sure why).
> I'm not sure why "bool" isn't simply a typedef to some existing integer
> type, which was common practice prior to _Bool being added to the
> language. Perhaps knowing a variable is boolean allows compilers to
> make more aggressive optimizations that would be unsafe for other
> integer types.
_Bool has some characteristics that no other integer type has. For
example, converting any scalar type to _Bool yields 0 or 1.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-28 13:30 +1300 |
| Message-ID | <9ogttuF8j1U1@mid.individual.net> |
| In reply to | #16326 |
On 01/28/12 01:26 PM, Keith Thompson wrote: > Stephen Sprunk<stephen@sprunk.org> writes: > [...] >> "_Bool" is a hack around the fact there is no way to introduce a new >> basic type in a header file. "bool" is what the standard was really >> trying to introduce, but that is a typedef to "_Bool" that one gets by >> including<stdbool.h>. > > "bool" is a macro, not a typedef (I'm not sure why). > >> I'm not sure why "bool" isn't simply a typedef to some existing integer >> type, which was common practice prior to _Bool being added to the >> language. Perhaps knowing a variable is boolean allows compilers to >> make more aggressive optimizations that would be unsafe for other >> integer types. > > _Bool has some characteristics that no other integer type has. For > example, converting any scalar type to _Bool yields 0 or 1. Isn't that the general case converting any larger scalar type to a smaller signed one? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-27 17:04 -0800 |
| Message-ID | <ln4nvg3adl.fsf@nuthaus.mib.org> |
| In reply to | #16327 |
Ian Collins <ian-news@hotmail.com> writes:
> On 01/28/12 01:26 PM, Keith Thompson wrote:
>> Stephen Sprunk<stephen@sprunk.org> writes:
>> [...]
>>> "_Bool" is a hack around the fact there is no way to introduce a new
>>> basic type in a header file. "bool" is what the standard was really
>>> trying to introduce, but that is a typedef to "_Bool" that one gets by
>>> including<stdbool.h>.
>>
>> "bool" is a macro, not a typedef (I'm not sure why).
>>
>>> I'm not sure why "bool" isn't simply a typedef to some existing integer
>>> type, which was common practice prior to _Bool being added to the
>>> language. Perhaps knowing a variable is boolean allows compilers to
>>> make more aggressive optimizations that would be unsafe for other
>>> integer types.
>>
>> _Bool has some characteristics that no other integer type has. For
>> example, converting any scalar type to _Bool yields 0 or 1.
>
> Isn't that the general case converting any larger scalar type to a
> smaller signed one?
Not at all.
Do you mean "smaller *unsigned* type"? That might have been a way
to approach it; make _Bool unsigned, and require it to have only 1
value bit and (CHAR_BIT * sizeof (_Bool) - 1) padding bits. In fact,
I can't think of a way that the current wording is inconsistent
with that model.
But it still couldn't be a typedef for any pre-existing integer
type, since none of the existing types are permitted to have just
one value bit.
Well, it could have been if they hadn't added the conversion rule,
and the requirement that it has lower rank than any other type.
I suspect C++ compatibility was part of the motivation (not that
C *has* to be compatible with C++, but it probably shouldn't be
gratuitously incompatible).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-28 14:10 +1300 |
| Message-ID | <9oh07gF8j0U7@mid.individual.net> |
| In reply to | #16330 |
On 01/28/12 02:04 PM, Keith Thompson wrote: > Ian Collins<ian-news@hotmail.com> writes: >> On 01/28/12 01:26 PM, Keith Thompson wrote: >>> Stephen Sprunk<stephen@sprunk.org> writes: >>> [...] >>>> "_Bool" is a hack around the fact there is no way to introduce a new >>>> basic type in a header file. "bool" is what the standard was really >>>> trying to introduce, but that is a typedef to "_Bool" that one gets by >>>> including<stdbool.h>. >>> >>> "bool" is a macro, not a typedef (I'm not sure why). >>> >>>> I'm not sure why "bool" isn't simply a typedef to some existing integer >>>> type, which was common practice prior to _Bool being added to the >>>> language. Perhaps knowing a variable is boolean allows compilers to >>>> make more aggressive optimizations that would be unsafe for other >>>> integer types. >>> >>> _Bool has some characteristics that no other integer type has. For >>> example, converting any scalar type to _Bool yields 0 or 1. >> >> Isn't that the general case converting any larger scalar type to a >> smaller signed one? > > Not at all. > > Do you mean "smaller *unsigned* type"? That might have been a way > to approach it; make _Bool unsigned, and require it to have only 1 > value bit and (CHAR_BIT * sizeof (_Bool) - 1) padding bits. In fact, > I can't think of a way that the current wording is inconsistent > with that model. Yes, I guess my 'u' and 'n' keys weren't working! > But it still couldn't be a typedef for any pre-existing integer > type, since none of the existing types are permitted to have just > one value bit. I wasn't suggesting that, it is a distinct type. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2012-01-27 21:06 -0500 |
| Message-ID | <jfvl7p$hs0$1@dont-email.me> |
| In reply to | #16330 |
On 1/27/2012 8:04 PM, Keith Thompson wrote: > Ian Collins<ian-news@hotmail.com> writes: >> On 01/28/12 01:26 PM, Keith Thompson wrote: >>> >>> _Bool has some characteristics that no other integer type has. For >>> example, converting any scalar type to _Bool yields 0 or 1. >> >> Isn't that the general case converting any larger scalar type to a >> smaller signed one? > > Not at all. > > Do you mean "smaller *unsigned* type"? That might have been a way > to approach it; make _Bool unsigned, and require it to have only 1 > value bit and (CHAR_BIT * sizeof (_Bool) - 1) padding bits. In fact, > I can't think of a way that the current wording is inconsistent > with that model. typedef __One_Unsigned_Bit _Bool; // be indulgent, OK? _Bool b = 2; -- Eric Sosman esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-27 20:09 -0800 |
| Message-ID | <lnvcnw1n92.fsf@nuthaus.mib.org> |
| In reply to | #16335 |
Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 1/27/2012 8:04 PM, Keith Thompson wrote:
>> Ian Collins<ian-news@hotmail.com> writes:
>>> On 01/28/12 01:26 PM, Keith Thompson wrote:
>>>>
>>>> _Bool has some characteristics that no other integer type has. For
>>>> example, converting any scalar type to _Bool yields 0 or 1.
>>>
>>> Isn't that the general case converting any larger scalar type to a
>>> smaller signed one?
>>
>> Not at all.
>>
>> Do you mean "smaller *unsigned* type"? That might have been a way
>> to approach it; make _Bool unsigned, and require it to have only 1
>> value bit and (CHAR_BIT * sizeof (_Bool) - 1) padding bits. In fact,
>> I can't think of a way that the current wording is inconsistent
>> with that model.
>
> typedef __One_Unsigned_Bit _Bool; // be indulgent, OK?
> _Bool b = 2;
There it is, then.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-27 20:15 -0800 |
| Message-ID | <lnlios1mzg.fsf@nuthaus.mib.org> |
| In reply to | #16335 |
Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 1/27/2012 8:04 PM, Keith Thompson wrote:
>> Ian Collins<ian-news@hotmail.com> writes:
>>> On 01/28/12 01:26 PM, Keith Thompson wrote:
>>>>
>>>> _Bool has some characteristics that no other integer type has. For
>>>> example, converting any scalar type to _Bool yields 0 or 1.
>>>
>>> Isn't that the general case converting any larger scalar type to a
>>> smaller signed one?
>>
>> Not at all.
>>
>> Do you mean "smaller *unsigned* type"? That might have been a way
>> to approach it; make _Bool unsigned, and require it to have only 1
>> value bit and (CHAR_BIT * sizeof (_Bool) - 1) padding bits. In fact,
>> I can't think of a way that the current wording is inconsistent
>> with that model.
>
> typedef __One_Unsigned_Bit _Bool; // be indulgent, OK?
> _Bool b = 2;
Another example (from the C99 Rationale): (_Bool)0.5 == 1, but
(int)0.5 == 0 .
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-01-27 23:03 -0600 |
| Message-ID | <jfvvjr$qn1$1@dont-email.me> |
| In reply to | #16327 |
On 27-Jan-12 18:30, Ian Collins wrote: > On 01/28/12 01:26 PM, Keith Thompson wrote: >> Stephen Sprunk<stephen@sprunk.org> writes: >> [...] >>> "_Bool" is a hack around the fact there is no way to introduce a new >>> basic type in a header file. "bool" is what the standard was really >>> trying to introduce, but that is a typedef to "_Bool" that one gets by >>> including<stdbool.h>. >> >> "bool" is a macro, not a typedef (I'm not sure why). Correction noted. >>> I'm not sure why "bool" isn't simply a typedef to some existing integer >>> type, which was common practice prior to _Bool being added to the >>> language. Perhaps knowing a variable is boolean allows compilers to >>> make more aggressive optimizations that would be unsafe for other >>> integer types. >> >> _Bool has some characteristics that no other integer type has. For >> example, converting any scalar type to _Bool yields 0 or 1. > > Isn't that the general case converting any larger scalar type to a > smaller signed one? If _Bool were simply an unsigned integer type with one value bit, wouldn't the normal conversion rules mean (_Bool)2 == 0? That's not how _Bool works. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-28 19:10 +1300 |
| Message-ID | <9ohhqpF8j0U10@mid.individual.net> |
| In reply to | #16343 |
On 01/28/12 06:03 PM, Stephen Sprunk wrote: > On 27-Jan-12 18:30, Ian Collins wrote: >> On 01/28/12 01:26 PM, Keith Thompson wrote: >>> Stephen Sprunk<stephen@sprunk.org> writes: >>> [...] >>>> "_Bool" is a hack around the fact there is no way to introduce a new >>>> basic type in a header file. "bool" is what the standard was really >>>> trying to introduce, but that is a typedef to "_Bool" that one gets by >>>> including<stdbool.h>. >>> >>> "bool" is a macro, not a typedef (I'm not sure why). > > Correction noted. > >>>> I'm not sure why "bool" isn't simply a typedef to some existing integer >>>> type, which was common practice prior to _Bool being added to the >>>> language. Perhaps knowing a variable is boolean allows compilers to >>>> make more aggressive optimizations that would be unsafe for other >>>> integer types. >>> >>> _Bool has some characteristics that no other integer type has. For >>> example, converting any scalar type to _Bool yields 0 or 1. >> >> Isn't that the general case converting any larger scalar type to a >> smaller signed one? > > If _Bool were simply an unsigned integer type with one value bit, > wouldn't the normal conversion rules mean (_Bool)2 == 0? That's not how > _Bool works. Fair enough. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-01-28 04:28 -0800 |
| Message-ID | <c26d808d-1ecd-470d-b1ad-a244ab780373@l16g2000vbl.googlegroups.com> |
| In reply to | #16343 |
On Jan 28, 5:03 am, Stephen Sprunk <step...@sprunk.org> wrote: > > If _Bool were simply an unsigned integer type with one value bit, > wouldn't the normal conversion rules mean (_Bool)2 == 0? That's not how > _Bool works. > This is exactly the problem. Denis Ritchie knew all about boolean types. They were excluded from C for some reason, but trying to tack them on now causes all sorts of problems and inconsistencies. In C true is non-zero. But if we hash define true and false, if(2 == true) evaluates to false, if(2) evaluates to true. Most undesireable. Adding true as a keyword causes even more problems. Then if a _Bool is a one bit type, _Bool bit = 2; should set bit to zero. Then we'd expect that _Bool myflags[100000000]; would be a space efficient way of declaring a big array of flags. If instead you've got to do unsigned char myflags[10000000/8], then you've got two boolean types kicking about your program, and _Bool is a hinderance rather than a help to anyone who's got to read your code. It is obviously good to have booleans documented as such. But in most functions, you don't normally have many booleans, and they normally do something quite simple, like adding or suppressing a newline on the last line of output. For a small gain, _Bool causes too many headaches, and that's neglecting the problem of double definition. -- MiniBasic - how to write a script interpreter http://malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-01-28 15:25 -0600 |
| Message-ID | <jg1p56$kgf$1@dont-email.me> |
| In reply to | #16351 |
On 28-Jan-12 06:28, Malcolm McLean wrote: > On Jan 28, 5:03 am, Stephen Sprunk <step...@sprunk.org> wrote: >> If _Bool were simply an unsigned integer type with one value bit, >> wouldn't the normal conversion rules mean (_Bool)2 == 0? That's not how >> _Bool works. >> > This is exactly the problem. > > Denis Ritchie knew all about boolean types. They were excluded from C > for some reason, but trying to tack them on now causes all sorts of > problems and inconsistencies. > > In C true is non-zero. But if we hash define true and false, if(2 == > true) evaluates to false, if(2) evaluates to true. Most undesireable. The logical solution to that problem would be to define an equality test with a boolean operand so the test becomes if( (_Bool)2 == true). > Adding true as a keyword causes even more problems. There's no need, though "#define true (_Bool)1" seems no less ugly than "#define true _True". You couldn't add true itself as a keyword for the same reason you can't add bool. The main reason for a first-class boolean type would seem to be so that you could redefine various operators to return a genuine boolean result rather than an int. > Then if a _Bool is a one bit type, _Bool bit = 2; should set bit to > zero. That's why a special rule is needed for conversions to _Bool. > Then we'd expect that _Bool myflags[100000000]; would be a space > efficient way of declaring a big array of flags. If instead you've got > to do unsigned char myflags[10000000/8], then you've got two boolean > types kicking about your program, and _Bool is a hinderance rather > than a help to anyone who's got to read your code. Unfortunately, if you pack an array of _Bool like that, that causes all sorts of problems when you try to take the address of one of the members of the array. Also, it would make accessing the members a lot more expensive than it appears, which could well overshadow any performance benefit to packing them. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-29 11:39 +1300 |
| Message-ID | <9ojbobF8j0U14@mid.individual.net> |
| In reply to | #16368 |
On 01/29/12 10:25 AM, Stephen Sprunk wrote: > On 28-Jan-12 06:28, Malcolm McLean wrote: > >> Then we'd expect that _Bool myflags[100000000]; would be a space >> efficient way of declaring a big array of flags. If instead you've got >> to do unsigned char myflags[10000000/8], then you've got two boolean >> types kicking about your program, and _Bool is a hinderance rather >> than a help to anyone who's got to read your code. > > Unfortunately, if you pack an array of _Bool like that, that causes all > sorts of problems when you try to take the address of one of the members > of the array. > > Also, it would make accessing the members a lot more expensive than it > appears, which could well overshadow any performance benefit to packing > them. Which is one reason why C++ has specialised containers for bool. In some ways bool sits better in C++ than in C (it has always been part of the language), but then again just about every C project I've worked on has some form of boolean type defined. So adding _Bool to the language does follow the standardisation mantra of standardising existing practice. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-29 09:53 -0800 |
| Message-ID | <d05c5968-99c0-4add-94c4-8bcb0ae54a92@hb4g2000vbb.googlegroups.com> |
| In reply to | #16371 |
On Jan 28, 10:39 pm, Ian Collins <ian-n...@hotmail.com> wrote: > [...] but then again just about every C project I've worked on > has some form of boolean type defined. I even knew of a project that had four different boolean types. One of which had TRUE, FALSE and MAYBE. > So adding _Bool to the language > does follow the standardisation mantra of standardising existing practice.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2012-02-03 10:39 +0000 |
| Message-ID | <slrnjineb7.1ls.grahn+nntp@frailea.sa.invalid> |
| In reply to | #16400 |
On Sun, 2012-01-29, Nick Keighley wrote: > On Jan 28, 10:39 pm, Ian Collins <ian-n...@hotmail.com> wrote: > >> [...] but then again just about every C project I've worked on >> has some form of boolean type defined. > > I even knew of a project that had four different boolean types. One of > which had TRUE, FALSE and MAYBE. Seen that many times (not the MAYBE). Sometimes they are designed so that 'if(my_boolean)' doesn't work as expected. Add to that various status code/return code types/defines and the various conventions for using int return codes (e.g. 0 is success and -1 failure; OK and ERROR are defined in various ways), and you have great opportunities for broken error handling :-( /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2012-02-01 16:42 -0800 |
| Message-ID | <a95b2469-daf3-4997-8472-eb811778b72c@g4g2000pbi.googlegroups.com> |
| In reply to | #16371 |
On Jan 28, 2:39 pm, Ian Collins <ian-n...@hotmail.com> wrote: > On 01/29/12 10:25 AM, Stephen Sprunk wrote: > > Unfortunately, if you pack an array of _Bool like that, that causes all > > sorts of problems when you try to take the address of one of the members > > of the array. > > > Also, it would make accessing the members a lot more expensive than it > > appears, which could well overshadow any performance benefit to packing > > them. > > Which is one reason why C++ has specialised containers for bool. In > some ways bool sits better in C++ than in C (it has always been part of > the language), but then again just about every C project I've worked on > has some form of boolean type defined. So adding _Bool to the language > does follow the standardisation mantra of standardising existing practice. Really? I thought this was considered a headache in C++, and there was talk of deprecating the template specialization of std::vector<bool> due to its various headaches. It really would have been much better to introduce a specific type like std::bit_vector instead of specializing and thereby changing the semantics of std::vector<bool>.
[toc] | [prev] | [next] | [standalone]
| From | jgk@panix.com (Joe keane) |
|---|---|
| Date | 2012-02-02 01:29 +0000 |
| Message-ID | <jgcou0$hgk$1@reader1.panix.com> |
| In reply to | #16371 |
In article <9ojbobF8j0U14@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: >Which is one reason why C++ has specialised containers for bool. Which is more of a headache than useful. A bit is not an object, it doesn't have an address. Just make 'bitstring' and done-with-it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-28 15:22 -0800 |
| Message-ID | <ln62fv1kfn.fsf@nuthaus.mib.org> |
| In reply to | #16368 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 28-Jan-12 06:28, Malcolm McLean wrote:
>> On Jan 28, 5:03 am, Stephen Sprunk <step...@sprunk.org> wrote:
>>> If _Bool were simply an unsigned integer type with one value bit,
>>> wouldn't the normal conversion rules mean (_Bool)2 == 0? That's not how
>>> _Bool works.
>>>
>> This is exactly the problem.
>>
>> Denis Ritchie knew all about boolean types. They were excluded from C
>> for some reason, but trying to tack them on now causes all sorts of
>> problems and inconsistencies.
>>
>> In C true is non-zero. But if we hash define true and false, if(2 ==
>> true) evaluates to false, if(2) evaluates to true. Most undesireable.
>
> The logical solution to that problem would be to define an equality test
> with a boolean operand so the test becomes if( (_Bool)2 == true).
No, the logical solution is *not to compare Boolean values to true*.
"if (2)" isn't likely to occur in real code, but if you have a
variable like "ok" whose value is logically Boolean (whether it's
declared as bool, _Bool, int, or something else), then the way to
test it is simply:
if (ok) ...
Writing this:
if (ok == true) ...
make no more sense than this:
if ((ok == true) == true) ...
There are issues when you want to compare two non-constant Boolean
values to each other. For example, you might have two Boolean functions
that are supposed to compute the same result, and you want to verify
that they behave consistently. In that case, what you really want to do
is:
if (func1() == func2()) ...
which can fail if they return int, and one of them returns 1 while the
other returns 2 (both true values). In that case, you need some
additional logic to avoid that kind of problem -- such as:
if ((bool)func1() == (bool)func2()) ...
(assuming your compiler gets this right), or:
if (!!func1() == !!func2()) ...
But for most uses of _Bool, or bool, or even int used to hold logically
Boolean values, it's easy enough to write your code in a way that (a) is
straightforward, and (b) works correctly whether there are multiple true
values or not.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-01-29 16:52 -0600 |
| Message-ID | <jg4ijv$pcd$1@dont-email.me> |
| In reply to | #16373 |
On 28-Jan-12 17:22, Keith Thompson wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> On 28-Jan-12 06:28, Malcolm McLean wrote: >>> In C true is non-zero. But if we hash define true and false, if(2 == >>> true) evaluates to false, if(2) evaluates to true. Most undesireable. >> >> The logical solution to that problem would be to define an equality test >> with a boolean operand so the test becomes if( (_Bool)2 == true). > > No, the logical solution is *not to compare Boolean values to true*. > > "if (2)" isn't likely to occur in real code, but if you have a > variable like "ok" whose value is logically Boolean (whether it's > declared as bool, _Bool, int, or something else), then the way to > test it is simply: > > if (ok) ... > > Writing this: > > if (ok == true) ... > > make no more sense than this: > > if ((ok == true) == true) ... That much is fair. I prefer "if (ptr)" over "if (ptr!=NULL)" as well. I'll note, though, that "if (ok!=false)" works just fine, even for uncommon values of truth. > There are issues when you want to compare two non-constant Boolean > values to each other. For example, you might have two Boolean functions > that are supposed to compute the same result, and you want to verify > that they behave consistently. In that case, what you really want to do > is: > > if (func1() == func2()) ... > > which can fail if they return int, and one of them returns 1 while the > other returns 2 (both true values). In that case, you need some > additional logic to avoid that kind of problem -- such as: > > if ((bool)func1() == (bool)func2()) ... That's just working around a bug: the functions return int instead of returning bool. > (assuming your compiler gets this right), or: > > if (!!func1() == !!func2()) ... or "if (!func1() == !func2())". I've done that before. > But for most uses of _Bool, or bool, or even int used to hold logically > Boolean values, it's easy enough to write your code in a way that (a) is > straightforward, and (b) works correctly whether there are multiple true > values or not. I agree, but that is a skill that we had to learn _because_ C didn't have a real boolean type. Perhaps it was so long ago for you that you don't remember it, but I do. And it's an obvious source of bugs, particularly when a function only rarely returns a value other than 1 for truth. I prefer that the language match the meaning as closely as possible, so that my code is self-documenting, which often happens to enable more aggressive compiler optimization as a side effect. Do you eschew unsigned types because signed ones are good enough and _you_ know that a particular variable will never be negative, even if the compiler doesn't? No, because you're used to them and know that, in certain cases, unsigned types work better. I assert the same would be true if you were used to having a true boolean type. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-30 02:04 -0800 |
| Message-ID | <ln7h09zetn.fsf@nuthaus.mib.org> |
| In reply to | #16413 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 28-Jan-12 17:22, Keith Thompson wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>> On 28-Jan-12 06:28, Malcolm McLean wrote:
>>>> In C true is non-zero. But if we hash define true and false, if(2 ==
>>>> true) evaluates to false, if(2) evaluates to true. Most undesireable.
>>>
>>> The logical solution to that problem would be to define an equality test
>>> with a boolean operand so the test becomes if( (_Bool)2 == true).
>>
>> No, the logical solution is *not to compare Boolean values to true*.
>>
>> "if (2)" isn't likely to occur in real code, but if you have a
>> variable like "ok" whose value is logically Boolean (whether it's
>> declared as bool, _Bool, int, or something else), then the way to
>> test it is simply:
>>
>> if (ok) ...
>>
>> Writing this:
>>
>> if (ok == true) ...
>>
>> make no more sense than this:
>>
>> if ((ok == true) == true) ...
>
> That much is fair. I prefer "if (ptr)" over "if (ptr!=NULL)" as well.
I don't, though that's more a matter of taste. My rationale, is that
"ptr" is not what I call "logically Boolean"; it has meaningfully
distinct "true" values.
> I'll note, though, that "if (ok!=false)" works just fine, even for
> uncommon values of truth.
Yes, but "if (!ok)" is clearer and, IMHO, better.
[snip]
>> But for most uses of _Bool, or bool, or even int used to hold logically
>> Boolean values, it's easy enough to write your code in a way that (a) is
>> straightforward, and (b) works correctly whether there are multiple true
>> values or not.
>
> I agree, but that is a skill that we had to learn _because_ C didn't
> have a real boolean type. Perhaps it was so long ago for you that you
> don't remember it, but I do. And it's an obvious source of bugs,
> particularly when a function only rarely returns a value other than 1
> for truth.
I learned Pascal before I learned C. Even in Pascal, with a built-in
Boolean type and predefined constants True and False, comparing a value
for equality to True didn't make sense. It would work correctly, but
the "= True" would just be redundant.
In most cases, good clean code happens to be code that works well with
pre-1999 C's treatment of boolean values.
> I prefer that the language match the meaning as closely as possible, so
> that my code is self-documenting, which often happens to enable more
> aggressive compiler optimization as a side effect.
>
> Do you eschew unsigned types because signed ones are good enough and
> _you_ know that a particular variable will never be negative, even if
> the compiler doesn't? No, because you're used to them and know that, in
> certain cases, unsigned types work better. I assert the same would be
> true if you were used to having a true boolean type.
I certainly don't hesitate to use a true boolean type in languages that
have such a type -- except perhaps when such a type was added recently
enough that existing code doesn't use it.
(Unsigned types can have their own pitfalls. The lower bound of the
type's full range is 0, which is a common value, making it easy to wrap
to very large values if you're not careful. For a sufficiently large
signed type, the bounds are far away from any reasonable values you're
dealing with, so you can (with care) treat it as unbounded. But that's
another discussion.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2012-01-30 10:22 +0000 |
| Message-ID | <slrn3vfsjicrrr.mi6.ike@iceland.freeshell.org> |
| In reply to | #16421 |
On 2012-01-30, Keith Thompson <kst-u@mib.org> wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> I'll note, though, that "if (ok!=false)" works just fine, even for >> uncommon values of truth. > > Yes, but "if (!ok)" is clearer and, IMHO, better. (ok) is still clearer and still better.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web