Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » 'bool' : undeclared identifier??

This thread is locked; no one can reply to it. rss feed Print
 1   2 
'bool' : undeclared identifier??
Kodafox
Member #4,193
January 2004
avatar

Can anyone tell me why I cant use the type bool without getting this error?

error C2065: 'bool' : undeclared identifier

Thanks!

Matthew Leverton
Supreme Loser
January 1999
avatar

Because you are using a language that doesn't have a standard bool type.

Kodafox
Member #4,193
January 2004
avatar

I took this from the MSDN Library

Quote:

bool
C++ Specific

bool declarators;

This keyword is an integral type. A variable of this type can have values true and false. All conditional expressions now return a value of type bool. For example, i!=0 now returns true or false depending on the value of i.

It says bool is an integral type in C++.

Matthew Leverton
Supreme Loser
January 1999
avatar

Are you working with a C++ or a C file though?

I don't have MSVC6 with me, but with MSVC7, bool works fine in a .cpp file.

Edit: Actually I do have MSVC 6 here... bool works fine on .cpp file on that as well.

int main(void)
{
  bool foo;
  return 0;
}

Chris Katko
Member #1,881
January 2002
avatar

bool works fine on my MSVC6.

Is the file .c? If so, rename it to *.cpp.

There's also C99's _Bool type if your programming in C.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Kodafox
Member #4,193
January 2004
avatar

Oh thanks guys, I didn't realize the file extension had an effect on how the compiler interpreted the file.

DanielH
Member #934
January 2001
avatar

I came across the same problem when working with c. Here is a workaround.

#ifndef bool
    #define bool int
    #define false ((bool)0)
    #define true  ((bool)1)
#endif

Billybob
Member #3,136
January 2003

DanielH: char would be a better idea, since all that is really needed for bool is 1-bit.

Bob
Free Market Evangelist
September 2000
avatar

Or, if you have a recent compiler:

#include <stdbool.h>

--
- Bob
[ -- All my signature links are 404 -- ]

Mr. Xboxor
Member #3,763
August 2003
avatar

I had this problem a while back with a 16bit dos compiler. I remember that if I tried to define bool as a type char instead of int, I got compiler errors when I tried to use boolean variables in certain ways. Of course, I can't remember what now, and I may have just been doing something wrong. Personally, I would stick with int.

"Java is high performance. By high performance we mean adequate. By adequate we mean slow." -Mr. Bunny

Chris Katko
Member #1,881
January 2002
avatar

An integer is also faster then a character.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Thomas Fjellstrom
Member #476
June 2000
avatar

Bob said:

Or, if you have a recent compiler:

#include <stdbool.h>

Which is funny.. I thought GCC 3.2.3 was recent enough, but I don't have a stdbool header. :(

Quote:

Oh thanks guys, I didn't realize the file extension had an effect on how the compiler interpreted the file.

Think about it, an .exe is a program. a .c is a C source file, and a .cpp is a C++ source file :) C and C++ are two different languages.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Billybob
Member #3,136
January 2003

Quote:

and C++ are two different languages.

I'm not seeing how that is. C is a programming language. C++ is C incremented with more abilities.

You might beed GCC 3.3 for that header...

Korval
Member #1,538
September 2001
avatar

Quote:

An integer is also faster then a character.

Not on x86 machines. They still have native 8-bit registers, so they don't have to do any bitshifting to access a char.

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

Not on x86 machines.

You sure? I know I heard that using an int on x86 is faster than using char or short (if those'r not the native bit-depth of the processor). I think it was because the CPU had to do extra stuff to access the non-32bit registers.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Billybob
Member #3,136
January 2003

Look, a 32-bit CPU has 32-bit registers. End of story.

gillius
Member #119
April 2000

Kitty, if the data is misaligned (off the 32-bit boundary) that is true. And WH is not correct. The x87 functionality has 80-bit registers, and MMX registers are 64 bit (I think) and SSE1 and SSE2 registers I believe are 128 bit.

Gillius
Gillius's Programming -- http://gillius.org/

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

if the data is misaligned (off the 32-bit boundary) that is true.

Then you'd still be using the same amount of data since speed-optimized programs more than likely align everything to the 32-bit boundary. So there's really no reason to use a char instead of an int for booleans since they'd end up taking up the same amount of space in an optimized program, and indeed may be slower on non-x86 platforms where variable/register size does matter (if such a platform exists). Though for other data types, where you need to clamp the data to a specified number of bytes, I can see.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

X-G
Member #856
December 2000
avatar

It might be important on platforms where memory conservation is important, such as the GBA. A speed-optimized program on the x86 should be able to deal with aligning them to word boundaries, but some times you do need to conserve that memory ...

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

gillius
Member #119
April 2000

X-G, you shouldn't really bring that up. Coding for GBA and coding for 3ghz PCs are completely different. You have to know your requirements, then code for them. The choice really depends on what your compiler does, your platform, target system speeds, and portability.

Gillius
Gillius's Programming -- http://gillius.org/

X-G
Member #856
December 2000
avatar

Yes. That was the point I was trying to make. This thread seemed to be making the assumption that we are all coding for a 3GHz PC, which I consider to be inaccurate to say at least ...

Ah, bitfields are the answer, anyway.

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

gnolam
Member #2,030
March 2002
avatar

TF said:

Which is funny.. I thought GCC 3.2.3 was recent enough, but I don't have a stdbool header. :(

Oh? My MinGW install has it, and that's GCC 3.2.3...

William Heatley said:

I'm not seeing how that is. C is a programming language. C++ is C incremented with more abilities.

Not quite true. There are things that are legal in C but illegal in C++ and vice versa, and there are a few ambiguous cases where the interpretation differs, like with:

void foo()
{
 /* blah */
}

That piece of code means one thing in C++ (no arguments) and another in C (unspecified arguments)...

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Rash
Member #2,374
May 2002
avatar

Tobias Dammers
Member #2,604
August 2002
avatar

AFAIK, an int is: A native integer, guaranteed to be at least 16-bit. So on a <16bit cpu, char should be as fast or faster than int (which is 16bit on those platforms), on >=16bit, int (native register) is as fast or faster.
The 80x86 does have 8-bit registers (ah, al...), but these are actually "half" registers. 8bit register operations take as much time as 16-bit equivalents (at least so I remember). Memory r/w aligned is equally fast for 8bit and 16bit; unaligned 16bit takes twice the time.
On >=386, 8 bit registers (ah, al) are parts of 16 bit registers (ax), which in turn are parts of 32 bit registers (like eax), so a 32bit op should be as fast as an 8 bit op.
When the goal to be achieved is not processing / logic, but rather storing, then bitfields of some sort are more appropriate (either C++, or just an integer of appropriate size).

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Evert
Member #794
November 2000
avatar

Quote:

an int is: A native integer, guaranteed to be at least 16-bit. So on a <16bit cpu, char should be as fast or faster than int (which is 16bit on those platforms), on >=16bit, int (native register) is as fast or faster.

I don't think its guarenteed to be at least 16 bit - what of a platform that has native 8 bit integers (yeah, pretty academic these days, I know)?
AFAIK, all that you know is sizeof(char)<=sizeof(int)<=sizeof(long int).

Note that 64 bit targets in C compilers actually use 32 bit ints too, since it seems too much code counts on ints being 32 bit, so the rule that int is the native integer type of the target system is no longer strictly true in those cases.

 1   2 


Go to: