Mail Archives: djgpp/1997/09/10/09:14:17
On 9/10/97 5:18:29 AM frenchc wrote:
> .... I originally thought that it was because DJGPP actually
>didn't support bool, in full enough effect to allow for STL containers.
Or,
> ...
g++ (and DJGPP) support the C++ keword 'bool'. For example the
file 'bool.h' that comes with DJGPP is a "No-Op" :
#ifndef __GNUC__
# define bool int
# define true 1
# define false 0
#endif
Everything is #ifdefed out so all STL source and headers are compiled
with the compiler native support for 'bool'.
> .... does DJGPP just automatically treat bool as int? Actually, no, I
think
>I was right after all. At least...
DJGPP does not treat bool as int.
'bool' is a different type. There are many ways to demonstrate it. For
example:
1. sizeof (bool) != sizeof(int) (at least not in DJGPP)
2. you can overload functions with bool also
void func(bool);
void func(int);
// ...
func(1); // calls func(int)
func(a != b); // calls func(bool)
3. and more ...
Besides, the concepts that 'bool' and 'int' represent are totally different
and language independent. (PASCAL Boolean, FORTRAN LOGICAL etc..)
This is not present in C because IMHO, C was designed to be small and
simple to
implement. Since an int can be used to test logical conditions, the extra
type
is not necessary and the overhead on the implementation is avoided.
Another issue is what is the **practical** gain compared with just an int ?
- I think that letting the programmer think more abstractly IS a
practical gain
- type safety
- overloading (see above)
- different template instantiations :
std C++ vector<int> and vector<bool> are different. the latter is a
vector of bits
(STL bitvector)
I would like to here more about this issue.
Eyal.
- Raw text -