C - <= and >= Problems

I have to convert an array of characters to a Binary value. Without using any C functions the only way that I know to check if something is an integer or letter is to use the ASCII chart. I followed the numbers in my functions but somehow it is not working out at all. The program executes and falls into every if statement even when it shouldnt.

Code:

---

int convert( const char Val[], int Base , int * InValue )
{
  int i;
  int count = 0;
  bool negFlag = 0;
  for( i = 0 ;; i++ )
  {
      if ( Val[i] == '\0' )
      {
        break;
      }
      printf ( "%i\n" , Val[i] );
      if (Val[i]<=90 || Val[i]>=65);
      {
      printf ( "%i\n" , count );
        count++;
      }
  }

  i = 0;
  int Base10Value = 0;
  int Base10Count = count;
      printf ( "%i\n" , count );
  for( count ; count >= 0 ;  )
  {
      if ((65<=Val[i]<=90)or(97<=Val[i]<=122));
      {
        int BaseToPower = 1 ;
        for ( Base10Count ; ( Base10Count - 1 ) > 0  ; Base10Count-- )
        {
            BaseToPower *= Base;
        }
        if ( 65 <= Val[i] <= 90 )
        {
            Base10Value += ( ((Val[i] - 'A')+10) * BaseToPower);
        }
        if (Val[i]<= 97 )
        {
            Base10Value += ( ((Val[i] - 'a')+10) * BaseToPower);
        }
        count--;
      }
      if ( ( 48 <= Val[i] <= 57 ));
      {
        int BaseToPower = 1 ;
        for ( Base10Count ; ( Base10Count - 1 ) > 0  ; Base10Count-- )
        {
            BaseToPower *= Base;

        }
        Base10Value += ( (Val[i] - '0') * BaseToPower);
        count--;
      }
      i++;
  }

---

thanks in advance

Quote:

---

Originally Posted by boydale1

Code:

---

      if (Val[i]<=90 || Val[i]>=65);

---

---

There are not many numbers which are not either smaller or equal than 90 or greater or equal than 65. For which number do you expect the above to be false?

can you provide your input string also.

Quote:

---

Originally Posted by treuss

There are not many numbers which are not either smaller or equal than 90 or greater or equal than 65. For which number do you expect the above to be false?

---

Agreed. But you also have a ; at the end of your if statement!!
Meaning the code in the { } will always run.

Edit: In fact, you do this numerous times.

Quote:

---

Originally Posted by boydale1

Code:

---

if ( 65 <= Val[i] <= 90 )

---

---

This might not do what you expect it to do either.
it basically evaluates to

Code:

---

if (( true or false ) <= 90)

---

you could as well write

Code:

---

if ( true )

---

try

Code:

---

if ( Val[i] >= 65 &&  Val[i] <= 90 )

---

Kurt

Quote:

---

Originally Posted by ZuK

Code:

---

if ( Val[i] >= 65 &&  Val[i] <= 90 )

---

---

This is correct in C++, but not mathematics, so even though it would work, I would consider this ambiguous code. I much prefer to use parenthesis in situations like that.

Quote:

---

Originally Posted by ninja9578

This is correct in C++, but not mathematics, so even though it would work, I would consider this ambiguous code.

---

Personally, I feel that it is not ambiguous because the relative precedence of >= and && should be well known, thus grouping with parentheses clutters the code. This is also a matter of taste, since one might think that despite the clutter ensuring against misinterpretation by a reader is more important. As for mathematics: I recall that in the mathematical notation that I was taught, the relative precedence of these operators is the same as in C++; but then mathematics should not be a factor here anyway.

The input to the function is as follows.

Code:

---

char A[] = "100";
int * Value;


convert( A, 10, Value );

---

Thanks for the help. I cleaned up my code a lot.

Things like:

( 65 <= Val[i] <= 90 )

I picked that up in python which is correct, but in C doesn't work.

thanks for the help.

Quote:

---

Originally Posted by ninja9578

This is correct in C++, but not mathematics, so even though it would work, I would consider this ambiguous code. I much prefer to use parenthesis in situations like that.

---

That's not even slightly ambiguous. Why clutter it up with unnecessary parenthesis?

Quote:

---

Originally Posted by boydale1

The input to the function is as follows.

Code:

---

char A[] = "100";
int * Value;


convert( A, 10, Value );

---

Thanks for the help. I cleaned up my code a lot.

Things like:

( 65 <= Val[i] <= 90 )

I picked that up in python which is correct, but in C doesn't work.

thanks for the help.

---

You only created a pointer to an int, not an actual int.
Your program will most likely crash if you try to assign a value to it.

It should read:

Code:

---

char A[] = "100";
int Value;
convert(A,10,&Value);

---

Edit: Actually you never even touch *InValue so why are you passing it?
Nor are you returning any values. I have no idea how to help you.

Quote:

---

Originally Posted by GCDEF

That's not even slightly ambiguous. Why clutter it up with unnecessary parenthesis?

---

I find the extra parenthesis help with the visual grouping of conditions. More complicated boolean conditions can be fiddly to disassemble without the visual help that parenthesis provide. It also helps when the coder got the operator precedence wrong. The parenthesis force the condition to mean what they actually intended.

I agree that its not ambiguous at all.
How do the parenthesis force anything?

Quote:

---

Originally Posted by JohnW@Wessex

I find the extra parenthesis help with the visual grouping of conditions. More complicated boolean conditions can be fiddly to disassemble without the visual help that parenthesis provide. It also helps when the coder got the operator precedence wrong. The parenthesis force the condition to mean what they actually intended.

---

But that case is really simple. To me, the parenthesis imply there's more going on than is readily obvious. Simple is always best IMHO.

A simple example

A && B || C

You could assume that the coder knows the operator precedence and it does what he intended.

If he were to type A && (B || C) then it doesn't matter whether the coder remembers && or || has the higher precedence, it will work as intended.
Now imagine a much longer and more complicated logic test.
I stick to this principle because it alleviates having to debug silly mistakes and lets me concentrate on the bigger issues.

If parenthesis are superfluous, then what about spaces and carriage returns?

Code:

---

#include<iostream>
#include<string>
int main(){std::string name;std::cout<<"Name?";std::cin>>name;std::cout<<"Hello "<<name;}

---

It's not about whether things are superfluous or not, it's about readability and conciseness of meaning;

Quote:

---

Originally Posted by JohnW@Wessex

A && (B || C)

---

Sure, but the question is whether it's worthwhile to type

(A) && ((B) || (C)).

I'd say no; everyone should know that the logical operators have lower precedence than comparison operators.

If you had a bitwise operator in there, then it might make sense for clarity.

Quote:

---

Originally Posted by JohnW@Wessex

A simple example

A && B || C

You could assume that the coder knows the operator precedence and it does what he intended.

If he were to type A && (B || C) then it doesn't matter whether the coder remembers && or || has the higher precedence, it will work as intended.
Now imagine a much longer and more complicated logic test.
I stick to this principle because it alleviates having to debug silly mistakes and lets me concentrate on the bigger issues.

If parenthesis are superfluous, then what about spaces and carriage returns?

Code:

---

#include<iostream>
#include<string>
int main(){std::string name;std::cout<<"Name?";std::cin>>name;std::cout<<"Hello "<<name;}

---

It's not about whether things are superfluous or not, it's about readability and conciseness of meaning;

---

Spaces and carriage returns are for readability. Parenthesis are there for grouping to change the natural order of evaluation. Spaces don't change logic. Parenthesis do, so when they're there, it's assumed that they're there to affect logic, at least by me. Maybe they make it more readable to you but to me they're there to change the normal order of evaluation and it seems strange to add them when they do nothing.

In the code in this case it's a simple logical and. There's nothing confusing or ambiguous about it.

Quote:

---

Originally Posted by JohnW@Wessex

A simple example

A && B || C

---

That's a total different kind of beef than a < b && b < c.

&& and || are from a logical point of view equal types of operators, so the preference ordering in C is purely autocratic.

< and && are different types of operators and the C language luckily follows common sense here and defines the preference ordering as one would expect.a < b && b < c should make sense to anyone without knowing the preference order by heart.

Quote:

---

Originally Posted by GCDEF

Maybe they make it more readable to you but to me they're there to change the normal order of evaluation and it seems strange to add them when they do nothing.

---

My coding style preferences come after many, many years of coding and debugging (often other people's code). Over the years I have moved to a principle of coding in a style that is much more verbose. I add in 'superfluous' parentheses; I test explicitly for zero/non-zero rather that using the implicit conversion to bool + many other 'useless' things. I do all this (and wrote it into the coding style) because it all but eliminates most of the dumb mistakes people make. I've found that it's not a good idea to assume that has the same interpretation of 'obvious'.

================================================================================
BBCode Version 0.10 (freeware)
Author: potatoCode on forum www.codeguru.com
================================================================================

Code:

---


int convert( const char Val[], int Base , int * InValue )
{
int i;
int count = 0;
bool negFlag = 0;
for( i = 0 ;; i++ )
{
if ( Val[i] == '\0' )
{
break;
}
printf ( "%i\n" , Val[i] );
if (Val[i]<=90 || Val[i]>=65);
{
printf ( "%i\n" , count );
count++;
}
}

i = 0;
int Base10Value = 0;
int Base10Count = count;
printf ( "%i\n" , count );
for( count ; count >= 0 ; )
{
if ((65<=Val[i]<=90)or(97<=Val[i]<=122));
{
int BaseToPower = 1 ;
for ( Base10Count ; ( Base10Count - 1 ) > 0 ; Base10Count-- )
{
BaseToPower *= Base;
}
if ( 65 <= Val[i] <= 90 )
{
Base10Value += ( ((Val[i] - 'A')+10) * BaseToPower);
}
if (Val[i]<= 97 )
{
Base10Value += ( ((Val[i] - 'a')+10) * BaseToPower);
}
count--;
}
if ( ( 48 <= Val[i] <= 57 ));
{
int BaseToPower = 1 ;
for ( Base10Count ; ( Base10Count - 1 ) > 0 ; Base10Count-- )
{
BaseToPower *= Base;

}
Base10Value += ( (Val[i] - '0') * BaseToPower);
count--;
}
i++;
}

---

-------------------------------- Report Message --------------------------------
Total errors (1)
Total warning (0)
Line 0 : Unmatched Curly brackets
--------------------------------------------------------------------------------
Elasped time: 0.0065 second(s)

Quote:

---

Originally Posted by JohnW@Wessex

My coding style preferences come after many, many years of coding and debugging (often other people's code). Over the years I have moved to a principle of coding in a style that is much more verbose. I add in 'superfluous' parentheses; I test explicitly for zero/non-zero rather that using the implicit conversion to bool + many other 'useless' things. I do all this (and wrote it into the coding style) because it all but eliminates most of the dumb mistakes people make. I've found that it's not a good idea to assume that has the same interpretation of 'obvious'.

---

Couldn't agree more. Always practice defensive coding style. I would much rather have "ugly" code, than waste time debugging trivial syntax errors.