|
This thread is locked; no one can reply to it. |
1
2
|
'bool' : undeclared identifier?? |
Kodafox
Member #4,193
January 2004
|
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
|
Because you are using a language that doesn't have a standard bool type. |
Kodafox
Member #4,193
January 2004
|
I took this from the MSDN Library Quote:
bool 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
|
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
|
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: |
Kodafox
Member #4,193
January 2004
|
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
|
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
|
Or, if you have a recent compiler: #include <stdbool.h>
-- |
Mr. Xboxor
Member #3,763
August 2003
|
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
|
An integer is also faster then a character. -----sig: |
Thomas Fjellstrom
Member #476
June 2000
|
Bob said: Or, if you have a recent compiler: 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. -- |
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
|
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
|
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. -- |
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 |
Kitty Cat
Member #2,815
October 2002
|
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. -- |
X-G
Member #856
December 2000
|
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 ... -- |
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 |
X-G
Member #856
December 2000
|
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. -- |
gnolam
Member #2,030
March 2002
|
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)... -- |
Rash
Member #2,374
May 2002
|
Tobias Dammers
Member #2,604
August 2002
|
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. --- |
Evert
Member #794
November 2000
|
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)? 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
|