getting around lack of bool type support

S

ssylee

I am using mikroC to program some microcontroller code in C. However I
have come across of potential problem of bool type not being supported
from the compiler complaint on how I declared type bool variable. From
a forum thread that I've pulled out from mikroBasic, I realized that
bool type isn't fully supported. When programming in mikroC, I have
been getting an error message of "invalid expression" when I declared
a bool type variable, "specifier needed" when I declared the bool type
variable within a function parameter and also when I declared the bool
type variable as a file scope. I'm not sure if there are any mikroC
users on this mailing list, but would much appreciate any comments or
suggestions. Thanks.
 
V

vippstar

I am using mikroC to program some microcontroller code in C. However I
have come across of potential problem of bool type not being supported
from the compiler complaint on how I declared type bool variable. From
a forum thread that I've pulled out from mikroBasic, I realized that
bool type isn't fully supported. When programming in mikroC, I have
been getting an error message of "invalid expression" when I declared
a bool type variable, "specifier needed" when I declared the bool type
variable within a function parameter and also when I declared the bool
type variable as a file scope. I'm not sure if there are any mikroC
users on this mailing list, but would much appreciate any comments or
suggestions. Thanks.

#include <stdbool.h>
 
F

Flash Gordon

ssylee wrote, On 29/12/07 00:21:
I am using mikroC to program some microcontroller code in C. However I
have come across of potential problem of bool type not being supported
from the compiler complaint on how I declared type bool variable. From
a forum thread that I've pulled out from mikroBasic, I realized that
bool type isn't fully supported. When programming in mikroC, I have
been getting an error message of "invalid expression" when I declared
a bool type variable, "specifier needed" when I declared the bool type
variable within a function parameter and also when I declared the bool
type variable as a file scope. I'm not sure if there are any mikroC
users on this mailing list, but would much appreciate any comments or
suggestions. Thanks.

I know nothing of mikroC (or microBasic) but I *do* know that the
boolean type (spelled _Bool) was only added to C in the 1999 standard
which is not implemented fully by most compilers (and a significant
number do not implement it at all). Further, it is only spelt "bool" if
you have included stdbool.h

In C you can use any integral type for boolean work as long as you
understand that 0 if false and *any* non-zero value is true, so don't
define a constant named "true" or "TRUE" and do comparisons against it.
 
I

Ivan Novick

I am using mikroC to program some microcontroller code in C. However I
have come across of potential problem of bool type not being supported
from the compiler complaint on how I declared type bool variable. From
a forum thread that I've pulled out from mikroBasic, I realized that
bool type isn't fully supported. When programming in mikroC, I have
been getting an error message of "invalid expression" when I declared
a bool type variable, "specifier needed" when I declared the bool type
variable within a function parameter and also when I declared the bool
type variable as a file scope. I'm not sure if there are any mikroC
users on this mailing list, but would much appreciate any comments or
suggestions. Thanks.

If you are trying to get existing code to compile and don't have bool
on your system try typedefing it.

typedef short bool
#define true 1
#define false 0

Regards,
Ivan Novick
http://www.0x4849.net
 
C

Chris McDonald

Ivan Novick said:
If you are trying to get existing code to compile and don't have bool
on your system try typedefing it.
typedef short bool
#define true 1
#define false 0

(Serious question) why have you chosen to use a short (not a char, not an int)?
Thanks,
 
S

ssylee

Thank you for the responses. I have used the method of defining 1 and
0 to true and false and got around that. The reason why I used short
instead of char or int is probably b/c of avoiding unnecessary memory
consumption, although the difference is nearly negligible.
 
U

user923005

Thank you for the responses. I have used the method of defining 1 and
0 to true and false and got around that. The reason why I used short
instead of char or int is probably b/c of avoiding unnecessary memory
consumption, although the difference is nearly negligible.

On many systems, char is smaller than short.
And char will never be larger than short.

Anyway {for pre-C99 at least}, it's a FAQ:

9.1: What is the right type to use for Boolean values in C? Why
isn't it a standard type? Should I use #defines or enums for
the true and false values?

A: C does not provide a standard Boolean type, in part because
picking one involves a space/time tradeoff which can best be
decided by the programmer. (Using an int may be faster, while
using char may save data space. Smaller types may make the
generated code bigger or slower, though, if they require lots
of
conversions to and from int.)

The choice between #defines and enumeration constants for the
true/false values is arbitrary and not terribly interesting
(see
also questions 2.22 and 17.10). Use any of

#define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0

enum bool {false, true}; enum bool {no, yes};

or use raw 1 and 0, as long as you are consistent within one
program or project. (An enumeration may be preferable if your
debugger shows the names of enumeration constants when
examining
variables.)

Some people prefer variants like

#define TRUE (1==1)
#define FALSE (!TRUE)

or define "helper" macros such as

#define Istrue(e) ((e) != 0)

These don't buy anything (see question 9.2 below; see also
questions 5.12 and 10.2).
 
K

Keith Thompson

Ivan Novick said:
If you are trying to get existing code to compile and don't have bool
on your system try typedefing it.

typedef short bool
#define true 1
#define false 0

I like this:

typedef enum { false, true } bool;

but of course there are many other possibilities.

See also section 9 of the comp.lang.c FAQ, <http://www.c-faq.com>.
 
M

Malcolm McLean

user923005 said:
#define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0
#define TRUE -1 is also very neat.

A single set bit is -1 in two's complement notation, but the real advantage
is now we can say
~TRUE == FALSE.
 
M

Malcolm McLean

ssylee said:
Thank you for the responses. I have used the method of defining 1 and
0 to true and false and got around that. The reason why I used short
instead of char or int is probably b/c of avoiding unnecessary memory
consumption, although the difference is nearly negligible.
In that case use int. I'm a firm believer in ints with everything, unless
the case for another type is overwhelming. There are lots of advantages in
having only one integer type kicking about the system.
 
K

Keith Thompson

It would have to be
#define TRUE (-1)
A single set bit is -1 in two's complement notation, but the real
advantage is now we can say
~TRUE == FALSE.

-1 has *all* bits set, not a single bit. And I fail to see the
advantage of ~TRUE == FALSE. Surely !TRUE == FALSE is better.

Define TRUE and FALSE as 1 and 0 also matches the results of the
equality and relational operators (though of course any non-zero value
is true).
 
A

Army1987

Why did you precede that line by >? it was not in the post you were
replying to. Btw, I'd add parentheses, just to avoid... er... TRUE[ptr]
do the wrong thing.
A single set bit is -1 in two's complement notation, but the real advantage
is now we can say
~TRUE == FALSE.
I fail to see why that's an advantage.
 
F

Flash Gordon

Army1987 wrote, On 29/12/07 15:30:
Why did you precede that line by >? it was not in the post you were
replying to. Btw, I'd add parentheses, just to avoid... er... TRUE[ptr]
do the wrong thing.
Indeed.
A single set bit is -1 in two's complement notation, but the real advantage
is now we can say
~TRUE == FALSE.
I fail to see why that's an advantage.

Once upon a time in a land far far away there existed processors where
it made sense to use -1 for one of the two logical values. Well, the
land was not very far away, but processors have been able to do
efficient comparisons against 0 for a very long time, so it really was
long long ago.

Of course, as I said earlier comparing against TRUE is a very dangerou
thing to do. Doing it with TRUE defined as -1 is more dangerous because
the expressions ((1==1)==TRUE) would yield 0, i.e. false. So we have the
following:

if ((1==1) == TRUE)
puts("Not completely broken definition of TRUE");
else
puts("A completely broken definition of TRUE");

Will correctly report "A completely broken definition of TRUE".
 
K

Keith Thompson

Golden California Girls said:
Your newsreader must have missed a message

No, I just checked. The lines

#define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0

were in user923005's message (quoted from the FAQ); the line

#define TRUE -1 is also very neat.

was not; it first appeared in Malcolm's message with a ">" prefix.
 
A

Army1987

Golden said:
Your newsreader must have missed a message
Even if it has, someone used a wrong number of > signs.
The lines " #define TRUE 1 #define YES 1" and "#define TRUE -1 is ..."
appear to be both by user923005, whose message I have, but the latter line
doesn't appear there.
 
G

Golden California Girls

Army1987 said:
Even if it has, someone used a wrong number of > signs.
The lines " #define TRUE 1 #define YES 1" and "#define TRUE -1 is ..."
appear to be both by user923005, whose message I have, but the latter line
doesn't appear there.

It appears as if Malcolm started his response with a ">" character. Likely was
on the wrong line when he typed it. My newsreader does have a blank line
between his response and the quoted material above.
 
A

Army1987

Golden said:
It appears as if Malcolm started his response with a ">" character. Likely was
on the wrong line when he typed it. My newsreader does have a blank line
between his response and the quoted material above.

And what I asked to Malcom was exactly why did he add a > at the beginning
of the line.
 
R

Randy Howard

And what I asked to Malcom was exactly why did he add a > at the beginning
of the line.

In the spirit of those "making mountains out of molehills", have you
all really never made a simple typo when editing a response to a long
threaded post with lots of different levels of '>>>>' indentation?

It happens. Furrfu.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top