From:	frenchc AT cadvision DOT com (Calvin French)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: bool.h in C++
Date:	10 Sep 1997 02:15:57 GMT
Organization:	CADVision Development Corp.
Lines:	38
Message-ID:	<5v4vst$keg@elmo.cadvision.com>
References:	<42256506 DOT 00564D66 DOT 00 AT aks DOT com>
NNTP-Posting-Host:	ts44ip93.cadvision.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

In article <42256506 DOT 00564D66 DOT 00 AT aks DOT com>, eyal DOT ben-david AT aks DOT com says...

>This header was included in the original HP STL  implementation to emulate
>the new
>C++ keywords  'bool'   'true'  'false', for compilers that did not support
>it.
>
>Today it is redundant since most new compilers support these keywords
>(including DJGPP)
>DJGPP (g++ in general) will accept these keywords without including bool.h
>
>bool.h itself didn't do much. just #defined bool, true, false  as int, 1, 0
>respectively.

This makes sense, but I originally thought that it was because DJGPP actually 
didn't support bool, in full enough effect to allow for STL containers. Or, 
else, does DJGPP just automatically treat bool as int? Actually, no, I think 
I was right after all. At least...

Just ran a test, I am indeed right, for whatever reason I don't know. But the 
following:

int main()
{
   bool loob[100];
   loob[1] = 0;
   loob[0] = 1;
   return loob[0]; // try changing to return loob[1]
};

will return the SAME value despite which of loob[...] you return. This 
doesn't make sense to me if the gcc272 implementation was correct, or maybe 
I'm missing something. This was my understanding for the bool.h, since it 
said ``simulates bool'' or something like that. Oh well, I'm always 
interested in learning why I'm wrong =\

- Calvin -

- Raw text -