Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > short circuit evaluation

Reply
Thread Tools

short circuit evaluation

 
 
James Kuyper
Guest
Posts: n/a
 
      09-17-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Sep 16, 7:38 pm, (E-Mail Removed) wrote:
>> (E-Mail Removed) wrote:
>>> On Sep 16, 8:55 pm, "Lassie" <(E-Mail Removed)> wrote:
>>>> bool finished = is_done();
>>>> if (finished && try_again()) { }
>>>> Is my understanding of short circuit evaluation correct that if finished is
>>>> false that try_again() will never be executed?
>>>> Or does it get evaluated sometimes?
>>> no it will not be evaluated ever,
>>> but are you trying it in "C".
>>> In "C" there is no "bool" built in data type .

>> No, but it is a standard typedef. This is just a code fragment, which
>> doesn't even provide declarations for is_done() and try_again(). I
>> would assume that the missing code also contains a line which says
>>
>> #include <stdbool.h>

>
> It is actually a macro, it's explicity mentioned in the standard to be
> so.
> See 7.16 p 2


You're right - my mistake. But I mis-remembered it as a standard typedef
because it makes more sense to me that it would be a typedef. Does
anyone know why it's a macro? I suppose it might be because you can
#undef a macro, but you can't turn off a typedef. If you want to use
'bool' as the standard macro in one part of a translation unit, and as a
user-defined identifier with an incompatible meaning from legacy code in
a later part of the same translation unit, making 'bool' a macro allows
you do so. But that seems like too convoluted a motivation for such a
choice.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      09-17-2008
James Kuyper wrote:
>

.... snip about <stdbool.h> ...
>
> You're right - my mistake. But I mis-remembered it as a standard
> typedef because it makes more sense to me that it would be a
> typedef. Does anyone know why it's a macro? I suppose it might be
> because you can #undef a macro, but you can't turn off a typedef.
> If you want to use 'bool' as the standard macro in one part of a
> translation unit, and as a user-defined identifier with an
> incompatible meaning from legacy code in a later part of the same
> translation unit, making 'bool' a macro allows you do so. But
> that seems like too convoluted a motivation for such a choice.


Because 'bool' was not a reserved word in C90. This way you can
keep the compiler compatible with C90 source that used it, and true
and false macros, differently. Note that _Bool IS a reserved word,
but is in the implementors namespace.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-17-2008
CBFalconer <(E-Mail Removed)> writes:
> James Kuyper wrote:
>>

> ... snip about <stdbool.h> ...
>>
>> You're right - my mistake. But I mis-remembered it as a standard
>> typedef because it makes more sense to me that it would be a
>> typedef. Does anyone know why it's a macro? I suppose it might be
>> because you can #undef a macro, but you can't turn off a typedef.
>> If you want to use 'bool' as the standard macro in one part of a
>> translation unit, and as a user-defined identifier with an
>> incompatible meaning from legacy code in a later part of the same
>> translation unit, making 'bool' a macro allows you do so. But
>> that seems like too convoluted a motivation for such a choice.

>
> Because 'bool' was not a reserved word in C90. This way you can
> keep the compiler compatible with C90 source that used it, and true
> and false macros, differently. Note that _Bool IS a reserved word,
> but is in the implementors namespace.


The question is why 'bool' is a macro rather than a typedef, not why
it's not a keyword in C99.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      09-17-2008
CBFalconer wrote:
> James Kuyper wrote:
> ... snip about <stdbool.h> ...
>> You're right - my mistake. But I mis-remembered it as a standard
>> typedef because it makes more sense to me that it would be a
>> typedef. Does anyone know why it's a macro? I suppose it might be
>> because you can #undef a macro, but you can't turn off a typedef.
>> If you want to use 'bool' as the standard macro in one part of a
>> translation unit, and as a user-defined identifier with an
>> incompatible meaning from legacy code in a later part of the same
>> translation unit, making 'bool' a macro allows you do so. But
>> that seems like too convoluted a motivation for such a choice.

>
> Because 'bool' was not a reserved word in C90. This way you can
> keep the compiler compatible with C90 source that used it, and true
> and false macros, differently. Note that _Bool IS a reserved word,
> but is in the implementors namespace.


How would making bool a typedef that is defined in stdbool.h cause a
problem for the compiler? Standard typedefs (like size_t) aren't
keywords, any more than standard macros are.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-18-2008
Keith Thompson wrote:
> CBFalconer <(E-Mail Removed)> writes:
>> James Kuyper wrote:
>>
>> ... snip about <stdbool.h> ...
>>
>>> You're right - my mistake. But I mis-remembered it as a standard
>>> typedef because it makes more sense to me that it would be a
>>> typedef. Does anyone know why it's a macro? I suppose it might be
>>> because you can #undef a macro, but you can't turn off a typedef.
>>> If you want to use 'bool' as the standard macro in one part of a
>>> translation unit, and as a user-defined identifier with an
>>> incompatible meaning from legacy code in a later part of the same
>>> translation unit, making 'bool' a macro allows you do so. But
>>> that seems like too convoluted a motivation for such a choice.

>>
>> Because 'bool' was not a reserved word in C90. This way you can
>> keep the compiler compatible with C90 source that used it, and true
>> and false macros, differently. Note that _Bool IS a reserved word,
>> but is in the implementors namespace.

>
> The question is why 'bool' is a macro rather than a typedef, not why
> it's not a keyword in C99.


Which is what I thought I said.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-18-2008
James Kuyper wrote:
> CBFalconer wrote:
>> James Kuyper wrote:
>>
>> ... snip about <stdbool.h> ...
>>
>>> You're right - my mistake. But I mis-remembered it as a standard
>>> typedef because it makes more sense to me that it would be a
>>> typedef. Does anyone know why it's a macro? I suppose it might be
>>> because you can #undef a macro, but you can't turn off a typedef.
>>> If you want to use 'bool' as the standard macro in one part of a
>>> translation unit, and as a user-defined identifier with an
>>> incompatible meaning from legacy code in a later part of the same
>>> translation unit, making 'bool' a macro allows you do so. But
>>> that seems like too convoluted a motivation for such a choice.

>>
>> Because 'bool' was not a reserved word in C90. This way you can
>> keep the compiler compatible with C90 source that used it, and true
>> and false macros, differently. Note that _Bool IS a reserved word,
>> but is in the implementors namespace.

>
> How would making bool a typedef that is defined in stdbool.h cause a
> problem for the compiler? Standard typedefs (like size_t) aren't
> keywords, any more than standard macros are.


Consider a source for C90 that defines bool, true, and false. If
C99 made those words reserved, the C90 source could not be compiled
on a C99 compiler (barring identical definitions). However, simply
failing to #include <stdbool.h> avoids the whole problem. This is
fairly automatic, since <stdbool.h> didn't exist in C90.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-18-2008
CBFalconer <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> CBFalconer <(E-Mail Removed)> writes:
>>> James Kuyper wrote:
>>>
>>> ... snip about <stdbool.h> ...
>>>
>>>> You're right - my mistake. But I mis-remembered it as a standard
>>>> typedef because it makes more sense to me that it would be a
>>>> typedef. Does anyone know why it's a macro? I suppose it might be
>>>> because you can #undef a macro, but you can't turn off a typedef.
>>>> If you want to use 'bool' as the standard macro in one part of a
>>>> translation unit, and as a user-defined identifier with an
>>>> incompatible meaning from legacy code in a later part of the same
>>>> translation unit, making 'bool' a macro allows you do so. But
>>>> that seems like too convoluted a motivation for such a choice.
>>>
>>> Because 'bool' was not a reserved word in C90. This way you can
>>> keep the compiler compatible with C90 source that used it, and true
>>> and false macros, differently. Note that _Bool IS a reserved word,
>>> but is in the implementors namespace.

>>
>> The question is why 'bool' is a macro rather than a typedef, not why
>> it's not a keyword in C99.

>
> Which is what I thought I said.


Um, no.

Your statement "Because 'bool' was not a reserved word in C90" is a
valid answer to "Why is 'bool' not a reserved word in C99?", but
nobody asked that question.

*Either* making bool a macro *or* making it a typedef would avoid any
problems with C90 code that uses the name "bool" as an identifier;
such code wouldn't include <stdbool.h>, so the macro or typedef would
not be visible.

The question under discussion was: Why is bool a macro rather than a
typedef in C99? Nothing you've said addresses that question.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      09-18-2008
CBFalconer wrote:
> Keith Thompson wrote:
>> CBFalconer <(E-Mail Removed)> writes:
>>> James Kuyper wrote:
>>>
>>> ... snip about <stdbool.h> ...
>>>
>>>> You're right - my mistake. But I mis-remembered it as a standard
>>>> typedef because it makes more sense to me that it would be a
>>>> typedef. Does anyone know why it's a macro? I suppose it might be
>>>> because you can #undef a macro, but you can't turn off a typedef.
>>>> If you want to use 'bool' as the standard macro in one part of a
>>>> translation unit, and as a user-defined identifier with an
>>>> incompatible meaning from legacy code in a later part of the same
>>>> translation unit, making 'bool' a macro allows you do so. But
>>>> that seems like too convoluted a motivation for such a choice.
>>> Because 'bool' was not a reserved word in C90. This way you can
>>> keep the compiler compatible with C90 source that used it, and true
>>> and false macros, differently. Note that _Bool IS a reserved word,
>>> but is in the implementors namespace.

>> The question is why 'bool' is a macro rather than a typedef, not why
>> it's not a keyword in C99.

>
> Which is what I thought I said.


No, you explained why it isn't a keyword. Since defining bool as a macro
or as a typedef would be equally effective at avoid the problem that
would occur if it were defined as a keyword, your answer says nothing
about why a macro was chosen, rather than a typedef. Since my question
was about why a macro was chosen, rather than a typedef; since my
question did not involve keywords in any way, shape, or form, your
answer was completely irrelevant to my question.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      09-18-2008
CBFalconer wrote:
> James Kuyper wrote:
>> CBFalconer wrote:
>>> James Kuyper wrote:
>>>
>>> ... snip about <stdbool.h> ...
>>>
>>>> You're right - my mistake. But I mis-remembered it as a standard
>>>> typedef because it makes more sense to me that it would be a
>>>> typedef. Does anyone know why it's a macro? I suppose it might be
>>>> because you can #undef a macro, but you can't turn off a typedef.
>>>> If you want to use 'bool' as the standard macro in one part of a
>>>> translation unit, and as a user-defined identifier with an
>>>> incompatible meaning from legacy code in a later part of the same
>>>> translation unit, making 'bool' a macro allows you do so. But
>>>> that seems like too convoluted a motivation for such a choice.
>>> Because 'bool' was not a reserved word in C90. This way you can
>>> keep the compiler compatible with C90 source that used it, and true
>>> and false macros, differently. Note that _Bool IS a reserved word,
>>> but is in the implementors namespace.

>> How would making bool a typedef that is defined in stdbool.h cause a
>> problem for the compiler? Standard typedefs (like size_t) aren't
>> keywords, any more than standard macros are.

>
> Consider a source for C90 that defines bool, true, and false. If
> C99 made those words reserved, ...


I wasn't asking about why C99 didn't make bool a reserved word. I was
asking why C99 didn't make it a typedef, like size_t.

> ... the C90 source could not be compiled
> on a C99 compiler (barring identical definitions). However, simply
> failing to #include <stdbool.h> avoids the whole problem. This is
> fairly automatic, since <stdbool.h> didn't exist in C90.


What does that have to do with whether bool should have been a macro or
a typedef? What you've said is equally true either way.
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      09-25-2008
Keith Thompson <(E-Mail Removed)> wrote:
>
> Oddly, I can't find this change either in any of the Technical
> Corrigenda or in any of the Defect Reports.


Caution: Editor at work
--
Larry Jones

I think if Santa is going to judge my behavior over the last year,
I ought to be entitled to legal representation. -- Calvin
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
logical expressions simplification with short circuit evaluation mingze zhang C Programming 4 10-22-2011 09:51 AM
logic expressions & short circuit evaluation mingze zhang C++ 2 07-15-2010 01:56 PM
short-circuit evaluation and assignment operators Anthony Paul C Programming 5 06-06-2009 06:49 PM
Short-Circuit Evaluation of Boolean Expressions webposter C Programming 2 09-14-2004 03:43 AM
short-circuit operators - part of the spec? Phil... Java 10 10-23-2003 08:42 PM



Advertisments