468,504 Members | 1,985 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,504 developers. It's quick & easy.

getting around lack of bool type support

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.
Dec 29 '07 #1
15 3815
On Dec 29, 2:21 am, ssylee <staniga...@gmail.comwrote:
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>
Dec 29 '07 #2
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.
--
Flash Gordon
Dec 29 '07 #3
On Dec 28, 4:21 pm, ssylee <staniga...@gmail.comwrote:
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
Dec 29 '07 #4
Ivan Novick <iv**@0x4849.netwrites:
>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,

--
Chris.
Dec 29 '07 #5
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.

Dec 29 '07 #6
On Dec 28, 6:53*pm, ssylee <staniga...@gmail.comwrote:
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).
Dec 29 '07 #7
Ivan Novick <iv**@0x4849.netwrites:
[...]
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>.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dec 29 '07 #8

"user923005" <dc*****@connx.comwrote in message
#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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Dec 29 '07 #9
"ssylee" <st********@gmail.comwrote in message
>
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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Dec 29 '07 #10
"Malcolm McLean" <re*******@btinternet.comwrites:
"user923005" <dc*****@connx.comwrote in message
> #define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0
>#define TRUE -1 is also very neat.
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).

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dec 29 '07 #11
On Dec 28, 5:39 pm, Chris McDonald <ch...@csse.uwa.edu.auwrote:
Ivan Novick <i...@0x4849.netwrites:
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,

--
Chris.
I agree, it should be char.

Regards,
Ivan Novick
http://www.0x4849.net
Dec 29 '07 #12
Malcolm McLean wrote:
"user923005" <dc*****@connx.comwrote in message
> #define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0
>#define TRUE -1 is also very neat.
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.
--
Army1987 (Replace "NOSPAM" with "email")
Dec 29 '07 #13
Army1987 wrote:
Malcolm McLean wrote:
>"user923005" <dc*****@connx.comwrote in message
>> #define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0
#define TRUE -1 is also very neat.
Why did you precede that line by >? it was not in the post you were
Your newsreader must have missed a message

Dec 29 '07 #14
Army1987 wrote, On 29/12/07 15:30:
Malcolm McLean wrote:
>"user923005" <dc*****@connx.comwrote in message
>> #define TRUE 1 #define YES 1
#define FALSE 0 #define NO 0
#define TRUE -1 is also very neat.
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".
--
Flash Gordon
Dec 29 '07 #15
Ivan Novick wrote:
>
On Dec 28, 5:39 pm, Chris McDonald <ch...@csse.uwa.edu.auwrote:
Ivan Novick <i...@0x4849.netwrites:
>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)?
I agree, it should be char.
I would have chosen int.
The use of lower ranking types than int,
tends to cause implicit conversions.
The meaning of the code is simpler
when it has fewer implicit conversions,
and that's the way I like it.

It's possible and perhaps even likely,
that your C implementation,
may choose to line up small types on int address boudaries anyway,
in which case, the space saved, may not be usable.

It's also possible that your C implementation
may use masking operations
to implement arithmetic operations on small types,
in which case the resulting executable code
is both larger and slower than it would be
using an int type for bool instead.

--
pete
Jan 3 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

303 posts views Thread by mike420 | last post: by
12 posts views Thread by Gnolen | last post: by
18 posts views Thread by Marcin Kalicinski | last post: by
16 posts views Thread by raj | last post: by
76 posts views Thread by KimmoA | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.