problems with logic operations within loops
Interrupt
I’m having problem with a function I’ve written. It takes and array
and removes the white spaces. I’m having problems with logic
operations within loops.
My first problem is once If statement executes and “i” is incremented
the else statement doesn’t execute again!! WHY???
*****************************CODE********************************************
/* copy: copy 'from' into 'to'removing white space */
void copy(char to[], char from[], int maxi)
{
int i;
for(i=0;i<=maxi;++i)
{
if(from[i]==' ' || from[i]=='\0' || from[i]=='\t'|| from[i]
=='\n')
{
to[i] = from[i+1]; // if there is white space copy
the next value
i++; //>>>>>>>>>>>>>>>>>>>> problems start here
}
else
{
to[i] = from[i]; // if no white space copy
}
}
}
********************************CODE******************************************
So I thought I’d approach the problem from the opposite angle if it’s
not white space, but the if statement executes whether there is white
space or not…..WHY???
********************************CODE2*****************************************
/* copy: copy 'from' into 'to'removing white space */
void copy(char to[], char from[], int maxi)
{
int i;
for(i=0;i<=maxi;++i)
{
if(from[i]!=' '||from[i]!='\0'||from[i]!='\t'||from[i]!='\n')
>>>>>>>>executes whether there is white space or not
{
to[i] = from[i]; // if no white space
copy
}
else
{
to[i] = from[i+1]; // if there is white space copy the
next value
i++;
}
}
}
**************************************CODE2*************************************
Andrew Poelstra
> Hi folks I?m working though some exercise trying to teach myself C,
> I?m having problem with a function I?ve written. It takes and array
> and removes the white spaces. I?m having problems with logic
> operations within loops.
>
> My first problem is once If statement executes and ?i? is incremented
> the else statement doesn?t execute again!! WHY???
> *****************************CODE********************************************
>
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
You almost certainly do not want <= here. Think about how
arrays are indexed in C.
> {
> if(from[i]==' ' || from[i]=='\0' || from[i]=='\t'|| from[i]
>=='\n')
#include <ctype.h>
...and use isspace() instead.
> {
> to[i] = from[i+1]; // if there is white space copy
> the next value
You can't use // comments in most C compilers today, and even
if you could you shouldn't on Usenet because they wrap around
like this and then nobody can compile your code.
Also, how do you know i + 1 is a valid index into from?
> i++; //>>>>>>>>>>>>>>>>>>>> problems start here
You can't use the same index into to[] and from[], if you
expect to be referencing different offsets in each array.
> }
>
> else
> {
> to[i] = from[i]; // if no white space copy
> }
> }
>
> }
> ************************CODE**********************************
>
> So I thought I?d approach the problem from the opposite angle if it?s
> not white space, but the if statement executes whether there is white
> space or not?..WHY???
>
> ************************CODE2*********************************
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
> {
> if(from[i]!=' '||from[i]!='\0'||from[i]!='\t'||from[i]!='\n')
>>>>>>>>>executes whether there is white space or not
Of course. When do you expect that (X != 1 || X != 2) will be false?
Perhaps if you would space your code decently it would be clearer.
> {
> to[i] = from[i]; // if no white space
> copy
> }
>
> else
> {
> to[i] = from[i+1]; // if there is white space copy the
> next value
> i++;
...and you still haven't fixed the original problem.
> }
> }
>
> }
> ******************************CODE2*****************************
>
nb I have removed sixteen stars from each of these lines.
Tom St Denis
wrote:
> You can't use // comments in most C compilers today, and even
> if you could you shouldn't on Usenet because they wrap around
> like this and then nobody can compile your code.
Um what? // are standard in C99 aren't they? GCC certainly will
accept them except when in -ansi mode. Though yes, it's good to use /
* */ instead, mostly for backwards compatibility but also to avoid
wrapping.
Tom
Andrew Poelstra
They are standard in C99, but gcc is not standard in C99 mode ;)
(It is close enough for most purposes, though. I perhaps should
have been clearer.)
paul
i++ increments i, then at the end of the for loop, it is incremented
again (by the loop). This skips a char in the 'to' buffer.
I suggest re-writing this to use a while loop. It won't fix your problem,
but it will make it more obvious. This is just one of the reasons
that changing a loop variable (i) within the loop is considered bad
practice.
Paul.
Richard Bos
> > to[i] = from[i+1]; // if there is white space copy
> > the next value
>
> You can't use // comments in most C compilers today,
Wrong (and it was wrong in many cases even before C99 made them
official), but...
> and even if you could you shouldn't on Usenet because they wrap around
> like this and then nobody can compile your code.
...right, as demonstrated.
Richard
Tim Streater
> Hi folks I�m working though some exercise trying to teach myself C,
> I�m having problem with a function I�ve written. It takes and array
> and removes the white spaces. I�m having problems with logic
> operations within loops.
If you use a "for" loop for this, it should look like:
for (i=0; i<maxi; i++)
Are you processing the whole string? If so then a "while" loop would be
better, with your test being about whether the current character is a null.
More importantly, you need to have a pointer moving along the input
string, and another moving along the output string. These can't be the
same pointer as they don't move along at the same rate necessarily (in
general they won't).
So it might be something like:
j = 0;
for (i=0; i<maxi; i++)
{
ch = from[i];
if (isspace(ch)==true) continue;
to[j] = ch;
j++;
}
--
Tim
"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"
Bill of Rights 1689
Tom St Denis
My point is GCC [and other compilers] silently accepted // by
default. You can only get gcc to whine about it when you enter ANSI
mode [e.g. C89/C90].
Though the rest of your point stands, C developers should use /**/ by
default.
Tom
Richard Heathfield
> On Jan 26, 10:40 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> You can't use // comments in most C compilers today, and even
>> if you could you shouldn't on Usenet because they wrap around
>> like this and then nobody can compile your code.
>
> Um what? // are standard in C99 aren't they?
Yes. Most C compilers, however, are not C99 compilers.
> GCC
is not "most compilers". It's *one* compiler.
> certainly will
> accept them except when in -ansi mode.
i.e. if you switch off conformance, which isn't always desirable. (For
me, it's almost never desirable.)
> Though yes, it's good to use /
> * */ instead,
Instead of /
* */, I recommend /* */ :-)
> mostly for backwards compatibility but also to avoid
> wrapping.
I think of it as "maximum portability" rather than "backward
compatibility", but yes.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Andrew Poelstra
> On Jan 26, 10:53�am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> On 2010-01-26, Tom St Denis <t...@iahu.ca> wrote:
>>
>> > On Jan 26, 10:40�am, Andrew Poelstra <apoels...@localhost.localdomain>
>> > wrote:
>> >> You can't use // comments in most C compilers today, and even
>> >> if you could you shouldn't on Usenet because they wrap around
>> >> like this and then nobody can compile your code.
>>
>> > Um what? �// are standard in C99 aren't they? �GCC certainly will
>> > accept them except when in -ansi mode. �Though yes, it's good to use /
>> > * */ instead, mostly for backwards compatibility but also to avoid
>> > wrapping.
>>
>> > Tom
>>
>> They are standard in C99, but gcc is not standard in C99 mode ;)
>>
>> (It is close enough for most purposes, though. I perhaps should
>> �have been clearer.)
>
> My point is GCC [and other compilers] silently accepted // by
> default. You can only get gcc to whine about it when you enter ANSI
> mode [e.g. C89/C90].
>
I (implicitly) meant that in default mode, gcc is not a C
compiler. (Rather a "GNU-C" compiler, which is a slightly
different beast.)
My bad - I try to word things to avoid these discussions,
since anyone who cares has in all likelihood heard them a
thousand times before.
Richard Heathfield
> Andrew Poelstra <apoe...@localhost.localdomain> wrote:
>
>
>>> to[i] = from[i+1]; // if there is white space copy
>>> the next value
>> You can't use // comments in most C compilers today,
>
> Wrong
Wrong.
> (and it was wrong in many cases even before C99 made them
> official), but...
No, in C99 you can use them - but only six people have a C99 compiler.
In other implementations, you have to invoke the compiler in a
non-conforming mode in order to use them. If we accept as C something
that a compiler can only accept in non-conforming mode, we can
cheerfully accept Fortran as C, which is not something I'm prepared to do.
<snip>
jacob navia
>
> Yes. Most C compilers, however, are not C99 compilers.
>
This is yet another lie. Please name one compiler that doesn't
accept // comments by default.
And no, putting gcc in pedantic mode doesn't count.
This is standard C, and it is widely implemented. I bet you can't
even name one compiler that doesn't accept those comments.
Keith Thompson
> Richard Heathfield a écrit :
>> Yes. Most C compilers, however, are not C99 compilers.
>
> This is yet another lie. Please name one compiler that doesn't
> accept // comments by default.
Accepting // comments doesn't make a C compiler a C99 compiler.
If Richard posted anything untrue, it wasn't in the text that
you quoted.
You need to stop throwing the word "lie" around.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"
Rob Kendrick
jacob navia <ja...@nospam.org> wrote:
> Richard Heathfield a écrit :
> >
> > Yes. Most C compilers, however, are not C99 compilers.
> >
>
> This is yet another lie. Please name one compiler that doesn't
> accept // comments by default.
It is not a lie if you include the context you must have accidentally
snipped and not read. :)
> This is standard C, and it is widely implemented. I bet you can't
> even name one compiler that doesn't accept those comments.
The Norcroft/Codemist-based compiler I am occasionally forced to use
doesn't.
B.
Richard Heathfield
> Richard Heathfield a �crit :
>>
>> Yes. Most C compilers, however, are not C99 compilers.
>>
>
> This is yet another lie.
No, it isn't. Please don't use the word "lie" when what you really mean
is "something Jacob Navia doesn't agree with".
> Please name one compiler that doesn't
> accept // comments by default.
Any compiler invoked in C90 conforming mode is required to issue a
diagnostic message when translating a translation unit containing at
least one syntax error or constraint violation. Since // comments are
always a syntax error in C90 (pathological cases excepted), all
C90-conforming compilers are required to object to // comments.
> And no, putting gcc in pedantic mode doesn't count.
If you don't invoke the compiler in conforming mode, it isn't required
to conform.
> This is standard C, and it is widely implemented. I bet you can't
> even name one compiler that doesn't accept those comments.
If by "accept" you mean "fail to issue a diagnostic message for", then
no C90-conforming implementations accept them. I will win the bet by
naming Borland C.
#include <stdio.h>
int main(void)
{
// get a diagnostic message
puts("Hello, diagnostic message.");
return 0;
}
When I compile this in conforming mode, I get this output:
Error E2188 scratch.c 5: Expression syntax in function main
*** 1 errors in Compile ***
Keith Thompson
> On Tue, 26 Jan 2010 18:20:07 +0100
> jacob navia <ja...@nospam.org> wrote:
>
>> Richard Heathfield a écrit :
>> >
>> > Yes. Most C compilers, however, are not C99 compilers.
>> >
>>
>> This is yet another lie. Please name one compiler that doesn't
>> accept // comments by default.
>
> It is not a lie if you include the context you must have accidentally
> snipped and not read. :)
It is not a lie given the context he actually quoted. Most C
compilers are *not* C99 compilers.
Nick
> Richard Bos wrote:
>> Andrew Poelstra <apoe...@localhost.localdomain> wrote:
>>
>>
>>>> to[i] = from[i+1]; // if there is white space copy
>>>> the next value
>>> You can't use // comments in most C compilers today,
>>
>> Wrong
>
> Wrong.
>
>> (and it was wrong in many cases even before C99 made them
>> official), but...
>
> No, in C99 you can use them - but only six people have a C99
> compiler. In other implementations, you have to invoke the compiler in
> a non-conforming mode in order to use them. If we accept as C
> something that a compiler can only accept in non-conforming mode, we
> can cheerfully accept Fortran as C, which is not something I'm
> prepared to do.
I do think you're being unnecessarily dogmatic, and confusing for
newcomers, here.
Firstly, in the case of just about every compiler I've come across, the
question isn't one of "invoking in a non-conforming mode", it's a case
of "not very carefully specifying half-a-dozen flags to force it into a
conforming mode".
Even if there are no C99 compilers, what the OP posted was perfectly
good C99 as far as I can see (certainly it appeared to be perfectly good
C with no features that worked differently between C standards, but with
// comments).
To claim you'd like to widen topicality, and then claim that any code
with // comments in it is equivalent to Fortran seems a bit rich, IMO.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Tim Streater
> jacob navia wrote:
>> Richard Heathfield a �crit :
>>>
>>> Yes. Most C compilers, however, are not C99 compilers.
>>>
>>
>> This is yet another lie.
>
> No, it isn't. Please don't use the word "lie" when what you really mean
> is "something Jacob Navia doesn't agree with".
Ahem. Any chance all you chaps could focus on the OP's problem ?
Fred
> On 26/01/2010 15:29, Interrupt wrote:
>
> > I m having problem with a function I ve written. It takes and array
> > and removes the white spaces. I m having problems with logic
> > operations within loops.
>
> If you use a "for" loop for this, it should look like:
>
> for (i=0; i<maxi; i++)
>
> Are you processing the whole string? If so then a "while" loop would be
> better, with your test being about whether the current character is a null.
>
> More importantly, you need to have a pointer moving along the input
> string, and another moving along the output string. These can't be the
> same pointer as they don't move along at the same rate necessarily (in
> general they won't).
>
> So it might be something like:
>
> j = 0;
> for (i=0; i<maxi; i++)
> {
> ch = from[i];
> if (isspace(ch)==true) continue;
> to[j] = ch;
> j++;
> }
>
Not necessarily. The OP did not include the definition of maxi
in the original posting, so it is possible that the "<=" is
correct (the name could be taken to imply that maxi is
the maximum value that i is allowed to have).
--
Fred K
jacob navia
> If by "accept" you mean "fail to issue a diagnostic message for", then
> no C90-conforming implementations accept them. I will win the bet by
> naming Borland C.
>
> #include <stdio.h>
>
> int main(void)
> {
> // get a diagnostic message
> puts("Hello, diagnostic message.");
> return 0;
> }
>
> When I compile this in conforming mode, I get this output:
>
> Error E2188 scratch.c 5: Expression syntax in function main
> *** 1 errors in Compile ***
>
Sorry but which "borland C" did you use?
I downloaded Turbo C from 1995 (the earliest I could get
that is still available) and compiled that without any problems.
You are using turbo C from 1989, or similar rubbish
You are lying again heathfield.
Michael Angelo Ravera
> Hi folks I’m working though some exercise trying to teach myself C,
> I’m having problem with a function I’ve written. It takes and array
> and removes the white spaces. I’m having problems with logic
> operations within loops.
>
> My first problem is once If statement executes and “i” is incremented
> the else statement doesn’t execute again!! WHY???
>
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
> {
> if(from[i]==' ' || from[i]=='\0' || from[i]=='\t'|| from[i]
> =='\n')
> {
> to[i] = from[i+1]; // if there is white space copy
> the next value
> i++; //>>>>>>>>>>>>>>>>>>>> problems start here
> }
>
> else
> {
> to[i] = from[i]; // if no white space copy
> }
> }
>
> }
>
>
> So I thought I’d approach the problem from the opposite angle if it’s
> not white space, but the if statement executes whether there is white
> space or not…..WHY???
>
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
> {
> if(from[i]!=' '||from[i]!='\0'||from[i]!='\t'||from[i]!='\n')>>>>>>>>executes whether there is white space or not
>
> {
> to[i] = from[i]; // if no white space
> copy
> }
>
> else
> {
> to[i] = from[i+1]; // if there is white space copy the
> next value
> i++;
> }
> }
>
> }
>
OK. First, most array functions would have the signature as follows:
void copy(char to[], char from[], int from_size, int to_max_size, int
* to_size)
or
int copy(char to[], char from[], int to_max_size, int from_size)
or even
int copy(char to[], char from[], int from_size)
It is important to know how large the resultant array is, since it can
not be predicted from the size of the input how large the output will
be, and you will want to know how big the result is.
If I were writing the function, and had access to the standard
library, I'd write this function as follows:
int copy (char to [], char from [], int from_size)
{
/*assume that we have at least from_size in the to[] array */
int res;
int idx;
for (res = 0, idx = 0; idx < from_size; idx ++)
{
if (!isspace (from [idx])
to [res ++] = from [idx];
}
return res;
}
If you have some special definitiion of what a whitespace characfter
is, you could substitute it in the test. If you want to stop on a null
or on the length, you could make the test say from "(idx < max_from)
&& from [idx]"
If instead of or in addtion to returning the length of the resulting
string, you'd rather put a null at the end of the buffer, you just do
to [res] = '\0'; ahead of the return line.
If you want to include maximum result length as an argument to the
function, you would augment the test in the for loop with "&& (res <
max_to_size)"
Lots of variations on this are possible. Have fun.
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> Richard Bos wrote:
>>> Andrew Poelstra <apoe...@localhost.localdomain> wrote:
<snip>
>>>> You can't use // comments in most C compilers today,
>>> Wrong
>> Wrong.
>>
>>> (and it was wrong in many cases even before C99 made them
>>> official), but...
>> No, in C99 you can use them - but only six people have a C99
>> compiler. In other implementations, you have to invoke the compiler in
>> a non-conforming mode in order to use them. If we accept as C
>> something that a compiler can only accept in non-conforming mode, we
>> can cheerfully accept Fortran as C, which is not something I'm
>> prepared to do.
>
> I do think you're being unnecessarily dogmatic, and confusing for
> newcomers, here.
Well, I hope you'll forgive me for disagreeing. Firstly, I'm not
expressing any "dogma", just explaining the facts as I see them. (The
"only six people have a C99 compiler" was, I hope, understood to be
comic exaggeration.)
> Firstly, in the case of just about every compiler I've come across, the
> question isn't one of "invoking in a non-conforming mode", it's a case
> of "not very carefully specifying half-a-dozen flags to force it into a
> conforming mode".
<shrug> That's an implementation issue.
> Even if there are no C99 compilers, what the OP posted was perfectly
> good C99 as far as I can see (certainly it appeared to be perfectly good
> C with no features that worked differently between C standards, but with
> // comments).
I agree entirely. It was perfectly good C99, and C99 is perfectly
topical here.
> To claim you'd like to widen topicality, and then claim that any code
> with // comments in it is equivalent to Fortran seems a bit rich, IMO.
But that wasn't the claim I made. The claim I made was that, if we
accept as C any feature that any conforming compiler accepts as an
extension, then Fortran is C. Code with // comments in it is conforming
C99, and perfectly acceptable to a C99 compiler; as such, it is not an
extension. In C90, however, // comment syntax /is/ an extension (if
available at all, which is often but not universally the case). Those
who require their code to conform to C90 would therefore be well-advised
to avoid // comments. I don't see how this argument constitutes an
attempt to narrow topicality.
Richard Heathfield
> On 26/01/2010 18:32, Richard Heathfield wrote:
>> jacob navia wrote:
>>> Richard Heathfield a �crit :
>>>>
>>>> Yes. Most C compilers, however, are not C99 compilers.
>>>>
>>>
>>> This is yet another lie.
>>
>> No, it isn't. Please don't use the word "lie" when what you really mean
>> is "something Jacob Navia doesn't agree with".
>
> Ahem. Any chance all you chaps could focus on the OP's problem ?
>
I assumed it had already been dealt with. Still, since you ask:
void copy(char to[], char from[], int maxi)
{
int i = 0;
int j = 0;
while(maxi--)
{
if(isspace(from[i]))
{
++i;
}
else
{
to[j++] = from[i++];
}
}
to[j] = '\0';
Richard Heathfield
> Richard Heathfield a �crit :
>> If by "accept" you mean "fail to issue a diagnostic message for", then
>> no C90-conforming implementations accept them. I will win the bet by
>> naming Borland C.
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> // get a diagnostic message
>> puts("Hello, diagnostic message.");
>> return 0;
>> }
>>
>> When I compile this in conforming mode, I get this output:
>>
>> Error E2188 scratch.c 5: Expression syntax in function main
>> *** 1 errors in Compile ***
>>
>
> Sorry but which "borland C" did you use?
5.6, in conforming mode.
> I downloaded Turbo C from 1995 (the earliest I could get
> that is still available) and compiled that without any problems.
Try again, this time in conforming mode (-A).
> You are using turbo C from 1989, or similar rubbish
Actually, I was using Borland C 5.6, dated 2002. Sure, it's not the most
up to date version, but it is the version that happens to be installed
on this laptop. It is a C90-conforming compiler. It rejects // comments
when invoked in conforming mode. You said I could not name such a
compiler. I have shown that I can.
> You are lying again heathfield.
I am beginning to think that you don't know what the word means.
Eric Sosman
> Tim Streater wrote:
>> On 26/01/2010 18:32, Richard Heathfield wrote:
>>> jacob navia wrote:
>>>> Richard Heathfield a �crit :
>>>>>
>>>>> Yes. Most C compilers, however, are not C99 compilers.
>>>>>
>>>>
>>>> This is yet another lie.
>>>
>>> No, it isn't. Please don't use the word "lie" when what you really mean
>>> is "something Jacob Navia doesn't agree with".
>>
>> Ahem. Any chance all you chaps could focus on the OP's problem ?
>>
>
> I assumed it had already been dealt with. Still, since you ask:
>
> void copy(char to[], char from[], int maxi)
> {
> int i = 0;
> int j = 0;
> while(maxi--)
> {
> if(isspace(from[i]))
IHYM `isspace( (unsigned char) from[i] )'.
--
Eric Sosman
eso...@ieee-dot-org.invalid
jacob navia
> jacob navia wrote:
>> Richard Heathfield a �crit :
>>> If by "accept" you mean "fail to issue a diagnostic message for",
>>> then no C90-conforming implementations accept them. I will win the
>>> bet by naming Borland C.
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>> // get a diagnostic message
>>> puts("Hello, diagnostic message.");
>>> return 0;
>>> }
>>>
>>> When I compile this in conforming mode, I get this output:
>>>
>>> Error E2188 scratch.c 5: Expression syntax in function main
>>> *** 1 errors in Compile ***
>>>
>>
>> Sorry but which "borland C" did you use?
>
> 5.6, in conforming mode.
>
Still, it accepts // comments (like all compilers since ages).
And that is what I said. "Unless deliberately crippled" and
in this context you force the compiler to reject // comments by
using a conforming C89 mode.
I will stop here, since you are deliberately confusing people.
Richard Heathfield
> On 1/26/2010 4:37 PM, Richard Heathfield wrote:
<snip>
>> if(isspace(from[i]))
>
> IHYM `isspace( (unsigned char) from[i] )'.
IDMT. SM. TYFTC.
Richard Heathfield
> Richard Heathfield a �crit :
>> jacob navia wrote:
>>> Richard Heathfield a �crit :
>>>> If by "accept" you mean "fail to issue a diagnostic message for",
>>>> then no C90-conforming implementations accept them. I will win the
>>>> bet by naming Borland C.
>>>>
>>>> #include <stdio.h>
>>>>
>>>> int main(void)
>>>> {
>>>> // get a diagnostic message
>>>> puts("Hello, diagnostic message.");
>>>> return 0;
>>>> }
>>>>
>>>> When I compile this in conforming mode, I get this output:
>>>>
>>>> Error E2188 scratch.c 5: Expression syntax in function main
>>>> *** 1 errors in Compile ***
>>>>
>>>
>>> Sorry but which "borland C" did you use?
>>
>> 5.6, in conforming mode.
>>
> conforming to C 1990.
Right.
> In 2002 Borland did not have a C99 compiler.
Right. Do they have one now? I could find no evidence that they do.
> Still, it accepts // comments (like all compilers since ages).
Not when invoked in conforming mode.
> And that is what I said. "Unless deliberately crippled" and
> in this context you force the compiler to reject // comments by
> using a conforming C89 mode.
I don't accept that invoking a compiler in conforming mode is equivalent
to crippling it.
> I will stop here, since you are deliberately confusing people.
I'm not trying to confuse anyone. The distinction is clear: a compiler
that conforms to C90 is required to diagnose // comments (except in
pathological cases which I suspect neither of us cares about); a
compiler that conforms to C99 is required to accept // comments. What
could be clearer?
Seebs
> Richard Heathfield a �crit :
>> Yes. Most C compilers, however, are not C99 compilers.
> This is yet another lie.
No, it's not.
> Please name one compiler that doesn't
> accept // comments by default.
He didn't say they didn't accept // comments by default, he said they
were not C99 compilers.
I think the point he's making is that, for most compilers, there is no mode
where they both genuinely and plausibly claim standards conformance, and
accept // comments, because the only way they could do that would be to
have full C99 support. Since they don't, their C99 mode isn't going to
claim conformance, so you're stuck with their C89 mode, which won't take //
comments.
Now, that may not be totally responsive to your point, because it's pretty
easy to get most compilers into a mode where they accept // comments, but
it is true that doing so will often put them into a mode where some other
reasonably normal stuff gets broken.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
jaysome
<r...@see.sig.invalid> wrote:
[snip]
>In other implementations, you have to invoke the compiler in a
>non-conforming mode in order to use them.
Wrong.
I use // comments in C code and invoke the (gcc) compiler in a
conforming mode. The trick to getting this to "work" is to pipe the
output from the compiler into a script that weeds out the warning
about "C++ style comments". The filter applied to the output of gcc is
like this:
grep -v 'warning:.*C\+\+ style comments'
The gcc options I use are specified in a makefile, and look something
like this (the "-Wc," part is particular to the gcc compiler and OS
I'm using, and simply means "pass the following option to the *real*
gcc compiler"):
WARN_BASE=-Wc,-Wall -Wc,-W
WARN_BASE += -Wc,-Wno-unknown-pragmas
WARN_BASE += -Wc,-Wpointer-arith
WARN_BASE += -Wc,-Wshadow
WARN_BASE += -Wc,-Wwrite-strings
WARN=$(WARN_BASE)
WARN += -Wc,-pedantic
WARN += -Wc,-Wbad-function-cast
WARN += -Wc,-Wcast-align
WARN += -Wc,-Wcast-qual
WARN += -Wc,-Wconversion
WARN += -Wc,-Wformat-nonliteral
WARN += -Wc,-Wmissing-declarations
WARN += -Wc,-Wmissing-prototypes
WARN += -Wc,-Wnested-externs
WARN += -Wc,-Wstrict-prototypes
WARN += -Wc,-Wundef
The "pedantic" reader will notice that the "-Wall" option to gcc
doesn't really get you "all" warnings, as you would rightfully expect.
When using the "-Wall" option with gcc, think of it as something like
"-Wmost" or "-Wmany". Go figure.
--
jay
frank
> Andrew Poelstra <apoe...@localhost.localdomain> wrote:
>
>
>>> to[i] = from[i+1]; // if there is white space copy
>>> the next value
>> You can't use // comments in most C compilers today,
>
> Wrong (and it was wrong in many cases even before C99 made them
> official), but...
Do you remember the program you used to illustrate this difference? It
basically consisted of a printf statement that would toggle a value to
indicate which decade was definitive. (??)
>
>> and even if you could you shouldn't on Usenet because they wrap around
>> like this and then nobody can compile your code.
>
> ...right, as demonstrated.
>
> Richard
Wrong, as demonstrated.
Heathfield's strarr.h got preprocessed and compiled tonight.
--
Ersek, Laszlo
> WARN_BASE=-Wc,-Wall -Wc,-W
> WARN_BASE += -Wc,-Wno-unknown-pragmas
> WARN_BASE += -Wc,-Wpointer-arith
> WARN_BASE += -Wc,-Wshadow
> WARN_BASE += -Wc,-Wwrite-strings
> WARN=$(WARN_BASE)
> WARN += -Wc,-pedantic
> WARN += -Wc,-Wbad-function-cast
> WARN += -Wc,-Wcast-align
> WARN += -Wc,-Wcast-qual
> WARN += -Wc,-Wconversion
> WARN += -Wc,-Wformat-nonliteral
> WARN += -Wc,-Wmissing-declarations
> WARN += -Wc,-Wmissing-prototypes
> WARN += -Wc,-Wnested-externs
> WARN += -Wc,-Wstrict-prototypes
> WARN += -Wc,-Wundef
>
> The "pedantic" reader will notice that the "-Wall" option to gcc
> doesn't really get you "all" warnings, as you would rightfully expect.
> When using the "-Wall" option with gcc, think of it as something like
> "-Wmost" or "-Wmany". Go figure.
Interesting. I notice you don't pass -ansi or -std=c[89]9, even though
you pass -pedantic. Maybe you do this exactly in order to enable C++
style comments:
----v----
`-ansi'
[...] For the C compiler, it disables recognition of C++ style `//'
comments as well as the `inline' keyword.
----^----
I use -Wformat=2 instead of -Wformat-nonliteral, as the former includes
the latter and more. I also pass -Wfloat-equal -Wlarger-than-32767
-Wlong-long -Wredundant-decls -Wunreachable-code.
Cheers,
lacos
Richard Heathfield
> On Tue, 26 Jan 2010 17:02:58 +0000, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
> [snip]
>
>> In other implementations, you have to invoke the compiler in a
>> non-conforming mode in order to use them.
>
> Wrong.
>
> I use // comments in C code and invoke the (gcc) compiler in a
> conforming mode. The trick to getting this to "work" is to pipe the
> output from the compiler into a script that weeds out the warning
> about "C++ style comments".
In other words, the implementation behaves correctly, but you filter the
diagnostic output. Jolly good. If only your build system were part of
the C language, I'd think you had a point.
Michael Foukarakis
> On Tue, 26 Jan 2010 17:02:58 +0000, Richard Heathfield
>
> <r...@see.sig.invalid> wrote:
>
> [snip]
>
> >In other implementations, you have to invoke the compiler in a
> >non-conforming mode in order to use them.
>
> Wrong.
>
> I use // comments in C code and invoke the (gcc) compiler in a
> conforming mode. The trick to getting this to "work" is to pipe the
> output from the compiler into a script that weeds out the warning
> about "C++ style comments". The filter applied to the output of gcc is
> like this:
>
> grep -v 'warning:.*C\+\+ style comments'
Then one day, you might get introduced to -Werror (aka. The
Sledgehammer), or discover warnings that SHOULD'VE been errors
(especially if you're using someone else's code) and your "trick" will
give you so much grief.. :-) Please send me a picture of your facial
expression then. TY.
> The "pedantic" reader will notice that the "-Wall" option to gcc
> doesn't really get you "all" warnings, as you would rightfully expect.
> When using the "-Wall" option with gcc, think of it as something like
> "-Wmost" or "-Wmany". Go figure.
No. Go RTFM. "Note that some warning flags are not implied by -Wall".
Joachim Schmitz
> Richard Heathfield a �crit :
>>
>> Yes. Most C compilers, however, are not C99 compilers.
>>
>
> This is yet another lie. Please name one compiler that doesn't
> accept // comments by default.
c89 on NonStop Kernel. And no, there is no c99 nor c95 available on that
platform.
There is, however, a switch to enable C++ style
comments, -Wallow_cpluplus_comments
There is also a switch -Wc99lite to ebable some, but by far not all c99
features.
> And no, putting gcc in pedantic mode doesn't count.
>
> This is standard C, and it is widely implemented. I bet you can't
> even name one compiler that doesn't accept those comments.
Bet lost.
Bye, Jojo
jacob navia
> jacob navia wrote:
>> Richard Heathfield a �crit :
>>>
>>> Yes. Most C compilers, however, are not C99 compilers.
>>>
>>
>> This is yet another lie. Please name one compiler that doesn't
>> accept // comments by default.
>
> c89 on NonStop Kernel. And no, there is no c99 nor c95 available on that
> platform.
>
> There is, however, a switch to enable C++ style comments,
> -Wallow_cpluplus_comments
> There is also a switch -Wc99lite to ebable some, but by far not all c99
> features.
>
Well, you see?
// comments are an universal feature in all C compilers, please let's stop
this stupidity. It is the most widely used C99 feature.
Richard Heathfield
<snip>
> // comments are an universal feature in all C compilers,
Clearly not. You have already been shown some examples.
> please let's stop this stupidity.
Be my guest.
> It is the most widely used C99 feature.
Possibly, but that's not the point.
Antoninus Twink
> jacob navia wrote:
>
> Clearly not. You have already been shown some examples.
Another lie to add to the tally, Heathfield.
Every single example presented so far has been of a compiler that
accepts // comments by default, but rejects them if you go out of your
way to provide options to run the compiler in a crippled mode with
certain features disabled.
>> please let's stop this stupidity.
>
> Be my guest.
Why is the real world such an unappealing place to you, Heathfield?
Antoninus Twink
> Richard Heathfield <r...@see.sig.invalid> writes:
>> compiler.
>
> newcomers, here.
No shit, Sherlock.
> Firstly, in the case of just about every compiler I've come across, the
> question isn't one of "invoking in a non-conforming mode", it's a case
> of "not very carefully specifying half-a-dozen flags to force it into a
> conforming mode".
Exactly.
> Even if there are no C99 compilers, what the OP posted was perfectly
> good C99 as far as I can see (certainly it appeared to be perfectly good
> C with no features that worked differently between C standards, but with
> // comments).
Exactly.
> To claim you'd like to widen topicality, and then claim that any code
> with // comments in it is equivalent to Fortran seems a bit rich, IMO.
Exactly.
Paul N
> jacob navia wrote:
>
> > Please name one compiler that doesn't
> > accept // comments by default.
>
> Any compiler invoked in C90 conforming mode is required to issue a
> diagnostic message when translating a translation unit containing at
> least one syntax error or constraint violation. Since // comments are
> always a syntax error in C90 (pathological cases excepted), all
> C90-conforming compilers are required to object to // comments.
>
> > even name one compiler that doesn't accept those comments.
>
> If by "accept" you mean "fail to issue a diagnostic message for", then
> no C90-conforming implementations accept them. I will win the bet by
> naming Borland C.
I think most people would regard "Borland C accepts // comments in its
default mode" as being a proof, rather than a disproof, of the
statement "Borland C accepts // comments".
Richard Heathfield
When I refer to a particular C compiler, you may generally assume that
I'm talking about its conforming mode unless I say otherwise. After all,
if it's not being invoked in a conforming mode, it's not really a C
compiler, is it?
In its default mode, Borland C is not a conforming compiler, and
therefore outside the remit of this newsgroup. In conforming mode, it
rejects // comments as claimed.
Phil Carmody
> if (isspace(ch)==true) continue;
I don't remember seeing anyone jump on that line. isspace() returns
something which is either zero or non-zero. Do not pretend you can
guess what non-zero value it might have. (And cast not-unsigned
chars to unsigned char before passing them to it, of course.)
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Seebs
> Tim Streater <timst...@waitrose.com> writes:
>> if (isspace(ch)==true) continue;
> I don't remember seeing anyone jump on that line. isspace() returns
> something which is either zero or non-zero. Do not pretend you can
> guess what non-zero value it might have. (And cast not-unsigned
> chars to unsigned char before passing them to it, of course.)
Good catch.
Interestingly, you can safely do (in C99):
bool x = isspace(ch);
if (x == true) ...
Ben Pfaff
> Interestingly, you can safely do (in C99):
> bool x = isspace(ch);
> if (x == true) ...
Yes.
"bool" is tricky though. Suppose that you instead wrote this:
bool x = isspace(ch);
if (x) ...
This will always do the right thing on C99. It usually works on
C89, too, if "bool" is a typedef to, say, unsigned char. But not
always: if isspace() returns 0x1000 for "true", and unsigned char
is an 8-bit type, then it will misclassify spaces as non-spaces.
So I always (if I'm thinking carefully) write assignments to bool
like this:
bool x = isspace(ch) != 0;
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl
"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt
Keith Thompson
> On 2010-01-28, Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>> Tim Streater <timst...@waitrose.com> writes:
>>> if (isspace(ch)==true) continue;
>
>> I don't remember seeing anyone jump on that line. isspace() returns
>> something which is either zero or non-zero. Do not pretend you can
>> guess what non-zero value it might have. (And cast not-unsigned
>> chars to unsigned char before passing them to it, of course.)
>
> Good catch.
>
> Interestingly, you can safely do (in C99):
> bool x = isspace(ch);
> if (x == true) ...
Yes, but there's still no good reason to write
if (x == true)
rather than
if (x)
Of course, a more meaningful name than "x" makes this clearer.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"
Tim Streater
> On 2010-01-28, Phil Carmody<thefatphi...@yahoo.co.uk> wrote:
>> Tim Streater<timst...@waitrose.com> writes:
>>> if (isspace(ch)==true) continue;
>
>> I don't remember seeing anyone jump on that line. isspace() returns
>> something which is either zero or non-zero. Do not pretend you can
>> guess what non-zero value it might have. (And cast not-unsigned
>> chars to unsigned char before passing them to it, of course.)
>
> Good catch.
>
> Interestingly, you can safely do (in C99):
> bool x = isspace(ch);
> if (x == true) ...
I expect you can tell I normally do all my work in PHP these days.
--
Tim
"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"
Bill of Rights 1689
Keith Thompson
> On 29/01/2010 00:01, Seebs wrote:
>> On 2010-01-28, Phil Carmody<thefatphi...@yahoo.co.uk> wrote:
>>> Tim Streater<timst...@waitrose.com> writes:
>>>> if (isspace(ch)==true) continue;
>>
>>> I don't remember seeing anyone jump on that line. isspace() returns
>>> something which is either zero or non-zero. Do not pretend you can
>>> guess what non-zero value it might have. (And cast not-unsigned
>>> chars to unsigned char before passing them to it, of course.)
>>
>> Good catch.
>>
>> Interestingly, you can safely do (in C99):
>> bool x = isspace(ch);
>> if (x == true) ...
>
> I expect you can tell I normally do all my work in PHP these days.
<OT>
Not really. As far as I can tell, the "== true" is no more necessary
(or sensible) in PHP than it is in C.
</OT>
Nick Keighley
wrote:
> Tim Streater <timstrea...@waitrose.com> writes:
> > if (isspace(ch)==true) continue;
>
> I don't remember seeing anyone jump on that line. isspace() returns
> something which is either zero or non-zero. Do not pretend you can
> guess what non-zero value it might have. (And cast not-unsigned
> chars to unsigned char before passing them to it, of course.)
there's an easy work around just define "true" as non-zero!
#define true !0
:-)
Daniel Giaimo
I don't know if you're joking, but that won't work. !0 is 1
not any value other than 0, so, for example, 2==!0 is false.
--
Dan G
Keith Thompson
Apparently you missed (and snipped) the smiley.
Antoninus Twink
> When I refer to a particular C compiler, you may generally assume that
> I'm talking about its conforming mode unless I say otherwise.
Sure, Heathfield.
And the rest of us will keep on assuming we're talking about its
fully-functional mode.
> After all, if it's not being invoked in a conforming mode, it's not
> really a C compiler, is it?
Did anyone ever tell you you're a complete dick?
Barry Schwarz
> Hi folks I’m working though some exercise trying to teach myself C,
> I’m having problem with a function I’ve written. It takes and array
> and removes the white spaces. I’m having problems with logic
> operations within loops.
>
> My first problem is once If statement executes and “i” is incremented
> the else statement doesn’t execute again!! WHY???
> *****************************CODE********************************************
>
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
> {
> if(from[i]==' ' || from[i]=='\0' || from[i]=='\t'|| from[i]
> =='\n')
> {
> to[i] = from[i+1]; // if there is white space copy
> the next value
> }
>
> else
> {
> to[i] = from[i]; // if no white space copy
> }
> }
>
> }
>
> ********************************CODE******************************************
>
> So I thought I’d approach the problem from the opposite angle if it’s
> not white space, but the if statement executes whether there is white
> space or not…..WHY???
>
> ********************************CODE2*****************************************
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
> {
> if(from[i]!=' '||from[i]!='\0'||from[i]!='\t'||from[i]!='\n')>>>>>>>>executes whether there is white space or not
>
> {
> to[i] = from[i]; // if no white space
> copy
> }
>
> else
> {
> to[i] = from[i+1]; // if there is white space copy the
> next value
> }
> }
>
> }
>
> **************************************CODE2*************************************
There are several problems with your code. Many have been mentioned
but they may have been lost due to the low signal/noise ratio that
this thread has degenerated to.
1 - The limits of your for loop are suspect. If maxi is the maximum
index then it is fine but the ususal C idiom for functions like this
is to use a length. In that case, the maximum index would be maxi-1
and you should use <, not <=.
2 - Your if expression evaluates to true under all defined
conditions. Probably not what you had in mind.
3 - Your test against '\0' is suspect. You did say array of
characters and not string but most white space removal tools work on
strings. If you did mean strings, then you should stop at the first
'\0' because by definition that is the end of the string.
4 - Your if expression is not exhaustive. There are other white space
characters. You might want to look up the isspace standard function.
5 - You blindly copy the character following a white space character.
You don't know if this character even exists (you could be at the end
of the array). If it does exist, you don't know if it is also white
space and if so your function should not copy it either.
6 - You use the same index for source and destination. Once you skip
over the first white space character, the two arrays no longer have
the same number of characters.
7 - Since '\0' is currently not special to you, you have no way to
tell the calling function how much of the target array contains valid
data.
Curtis Dyer
> Tim Streater <timst...@waitrose.com> writes:
>> On 29/01/2010 00:01, Seebs wrote:
>>> On 2010-01-28, Phil Carmody<thefatphi...@yahoo.co.uk>
>>> wrote:
>>>> Tim Streater<timst...@waitrose.com> writes:
>>>>> if (isspace(ch)==true) continue;
>>>
>>>> I don't remember seeing anyone jump on that line. isspace()
>>>> returns something which is either zero or non-zero. Do not
>>>> pretend you can guess what non-zero value it might have. (And
>>>> cast not-unsigned chars to unsigned char before passing them
>>>> to it, of course.)
>>>
>>> Good catch.
>>>
>>> Interestingly, you can safely do (in C99):
>>> bool x = isspace(ch);
>>> if (x == true) ...
>>
>> I expect you can tell I normally do all my work in PHP these
>> days.
>
> <OT>
> Not really. As far as I can tell, the "== true" is no more
> necessary (or sensible) in PHP than it is in C.
> </OT>
<OT>
Indeed, but perhaps Tim was referring to the cases when you need
to use "$x === true" to also ensure strict type comparison. Just
a thought.
</OT>
--
"Don't worry about efficiency until you've attained correctness."
~ Eric Sosman, comp.lang.c
Tim Streater
Thanks for the kind thought but I was really referring to the fact that
"true" is defined in PHP but not in C.
And I prefer to write "==true" because it makes my code more readable to
me. If I have "if (x>3) { ..." I can read this as "if x is greater then
3 then do so-and-so". I read "if (x) { ..." as "if x then do so-and-so".
WTF? If x *what*? Forgot to put the cat out? Needs its hair cut?
Ben Bacarisse
<snip>
> And I prefer to write "==true" because it makes my code more readable
> to me.
You are probably still talking about PHP, but just in case this gets
taken as a more general point, it is unwise to do that in C because
true must be just one value and any non-zero values is acceptable as
"not false" (such as those that the isxxxx functions might return).
> If I have "if (x>3) { ..." I can read this as "if x is greater
> then 3 then do so-and-so". I read "if (x) { ..." as "if x then do
> so-and-so". WTF? If x *what*? Forgot to put the cat out? Needs its
> hair cut?
I'd say that is the fault of whoever chose x as the name. If x is a
boolean, the name should indicate WTF: if (x_needs_hair_cut)... If x
is not boolean (say it is the number of until a hair cut is required)
I would test against 0: if (x_days_to_hair_cut == 0)...
--
Ben.
Tim Streater
Could do that I suppose, but "if (debugflag_is_true) { ..." gets tedious
quite quickly.
Eric Sosman
> On 30/01/2010 13:28, Ben Bacarisse wrote:
>> Tim Streater<timst...@waitrose.com> writes:
>> <snip>
>>> And I prefer to write "==true" because it makes my code more readable
>>> to me.
>>
>> You are probably still talking about PHP, but just in case this gets
>> taken as a more general point, it is unwise to do that in C because
>> true must be just one value and any non-zero values is acceptable as
>> "not false" (such as those that the isxxxx functions might return).
>>
>>> If I have "if (x>3) { ..." I can read this as "if x is greater
>>> then 3 then do so-and-so". I read "if (x) { ..." as "if x then do
>>> so-and-so". WTF? If x *what*? Forgot to put the cat out? Needs its
>>> hair cut?
>>
>> I'd say that is the fault of whoever chose x as the name. If x is a
>> boolean, the name should indicate WTF: if (x_needs_hair_cut)... If x
>> is not boolean (say it is the number of until a hair cut is required)
>> I would test against 0: if (x_days_to_hair_cut == 0)...
>
> Could do that I suppose, but "if (debugflag_is_true) { ..." gets tedious
> quite quickly.
You'd prefer `if (debugflag_is_true == true)', I guess? ;-)
There's also the question of when to stop:
if (x)
if (x == true)
if (x == true == true)
if (x == true == true == true)
...
It's mostly a matter of personal style, but I've never
found a convincing reason (in any language) to compare with a
Boolean constant. I like explicit comparisons of pointers
to NULL and numbers to zero: `if (ptr != NULL)' rather than
`if (ptr)', but it's just a preference. (I particularly abhor
`if (!strcmp(answer,"no"))', which reads so wrongly it rouses
righteous rage.)
Also, as mentioned up-thread, `if (isdigit(ch) == true)'
is just plain wrong, R-O-N-G, wrong.
--
Eric Sosman
eso...@ieee-dot-org.invalid
achp
> And I prefer to write "==true" because it makes my code more readable to
> me. If I have "if (x>3) { ..." I can read this as "if x is greater then
> 3 then do so-and-so". I read "if (x) { ..." as "if x then do so-and-so".
> WTF? If x *what*? Forgot to put the cat out? Needs its hair cut?
Well, in this case it's perfectly transparent: "if x is space
then...".
Or at least it would be so if not that disgusting flaw with the is*
functions...
achp
> 2 - Your if expression evaluates to true under all defined
> conditions. Probably not what you had in mind.
I'd also like to add why.
In Boolean algebra, there are so called De Morgan's laws. In terms of
C,
!(X && Y) == (!X) || (!Y)
and
!(X || Y) == (!X) && (!Y)
Therefore, when you swap "then" and "else" branches of an "if"
statement, you need to not only negate the condition clauses, but also
to replace all conjunctions into disjunctions and vice versa.
Seebs
> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>> There's also the question of when to stop:
>> if (x)
>> if (x == true)
>> if (x == true == true)
>> if (x == true == true == true)
>> ...
> He wants to stop at the second case, because this is
> readable as English �if x is true, then�, while neither
> �if x, then� nor �if x is true is true, then� is English.
Sure they are. Especially if x is already a predicate:
if molly is a kitty
if "molly is a kitty" is true
if ""molly is a kitty" is true" is true
-s
p.s.: molly is in fact a kitty
Keith Thompson
> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>> There's also the question of when to stop:
>> if (x)
>> if (x == true)
>> if (x == true == true)
>> if (x == true == true == true)
>> ...
>
> readable as English »if x is true, then«, while neither
> »if x, then« nor »if x is true is true, then« is English.
Only because "x" is a poor name. If it were named, say, "done",
would you consider writing
if (done == true)
rather than
if (done)
BTW, C99 does have "true" and "false", if you #include <stdbool.h>,
and you can easily declare them in C90 if you like.
Phil Carmody
> Daniel Giaimo <dgi...@gmail.com> writes:
>> On 1/29/2010 3:12 AM, Nick Keighley wrote:
>>> On 28 Jan, 11:07, Phil Carmody<thefatphil_demun...@yahoo.co.uk>
>>> wrote:
>>>> Tim Streater<timstrea...@waitrose.com> writes:
>>>
>>>>> if (isspace(ch)==true) continue;
>>>>
>>>> I don't remember seeing anyone jump on that line. isspace() returns
>>>> something which is either zero or non-zero. Do not pretend you can
>>>> guess what non-zero value it might have. (And cast not-unsigned
>>>> chars to unsigned char before passing them to it, of course.)
>>>
>>> there's an easy work around just define "true" as non-zero!
>>>
>>> #define true !0
>>
>> I don't know if you're joking, but that won't work. !0 is 1
>> not any value other than 0, so, for example, 2==!0 is false.
>
> Apparently you missed (and snipped) the smiley.
It was clear you forgot that true has to be _any_ non-zero. So you want:
#define true .ne. !0
...
int condition=get_condition();
if (condition true) { ...
Muahahahah....