Re: bool or BOOL in MFC projects



Also, in the PDP-11 compiler, which was a real piece of trash, if you wrote

int n = expr;
if(n == 0) ...

you got a larger code sequence than if you wrote
if( (n = expr) == 0)
mostly due to the way-behind-state-of-the-1950s-art code generator they had. Because the
machine had only 64K, such idioms were encouraged because they "saved space and time", and
became entrenched in the minds of programmers. I believe that embedded assignments should
be treated as errors by the compiler (give me a #pragma warning(error:xxxx) to enable it,
and enable it by default for high-level analysis). Most of the bad code we see in C comes
from people either following the original K&R style or by being taught C by people who
learned it on the PDP-11 and never unlearned all the bad habits they developed.

(For example, the reason many fields in structs started with prefixes, such as tmYear, was
that field names were GLOBAL to ALL structures, so if you used a field called x in struct
POINT, you could not use a field in ANY OTHER STRUCTURE! But modern users forget that the
reason for all this rubbish was that limitation of the early C compiler, and persist in
doing it again and again. Or the fact that you could not return a long from a function,
so to return a long you neede to write time(&longvalue) because it was impossible to write
longvalue=time(), because functions could ONLY return 16-bit values. Or that there was no
void type, so every function implicity returned int. Or that -> and . differ because the
language was so poorly defined that if A was a POINTER, then A.B computed the offset of B
from the symbol A, not derferencing the pointer in A to apply the B offset to the pointer.
The syntax struct NAME * A was considered "documentation" rather than "functional",
because there was exactly ONE data type, int. A.B was the offset B-distance from the
symbol A, but A->B forced a derefence of the pointer, because the language was so poorly
specified. It is well and truly amazing how bad the language actually was, through the
1980s. I was using a "modern" C compiler in the mid-1980s, and we couldn't port the 100K
lines of code to another platform because it rigidly followed K&R C as done on the PDP-11,
and the rewrite would have been massive. This was in the days before GNU C, or
availability of compilers on multiple platforms from a given vendor at a reasonable price
[the compiler we would have needed would have cost $7,000], so ultimately we abandoned the
project to port it. It compiled and ran on Sun, IBM PC/MS-DOS, Vax/VMS, Vax/Unix, MIPS,
Apollo, and several other machines I've long since forgotten, but we could not get a port
to a machine that I can't remember the manufacturer of, but it was a 68K in a weird
proprietary OS which was only used by that vendor. We decided the market didn't justify
the cost of the compiler, and there was no way we were going to change all the code. I
looked at trying to convert the executable image on another 68K platform (Apollo) to the
format of the weird machine, and that didn't look feasible)

"C gives you all the power of assembly code with all the expressive elegance of assembly
code" (I don't remember who first said this...)
joe

On Thu, 20 Dec 2007 04:17:53 +1000, "Ian Semmel" <anyone@xxxxxxxxxxxxxxxxx> wrote:



-----Original Message-----
From: Brian Muth [mailto:bmuth@xxxxxxxx]
Posted At: Wednesday, 19 December 2007 9:34 AM
Posted To: microsoft.public.vc.mfc
Conversation: bool or BOOL in MFC projects
Subject: Re: bool or BOOL in MFC projects


Microsoft should change their prototypes from BOOL to int. That's
what
they mean anyway in a lot of cases.


I couldn't disagree more vigorously. It's pretty clear to most
programmers that a variable of type BOOL is meant to take on only two
values, whereas int doesn't tell you anything. Also bear in mind that
MFC existed long before the keyword "bool" found its way into
the C++ standard.

The decision by the MFC designers was correct at the time.

Brian

But that is my point. Functions that return a BOOL can return any value
and in some cases do. Giving them a type of BOOL is misleading.

It is a C thing. The language did not define a boolean type for some
unknown reason.

The need for statements like

if ( a = b + c ) ...

...testing for a non-zero result from the assignment is a hangover from
assembler programming designed to encourage smart-arse "one-liners" who
could produce indecipherable code by including complex assignments (with
side-effects) into a conditional.

Unfortunately, C++ brought over a lot of baggage from C on the grounds
of compatibility. C# seems to have mostly cleaned things like this up.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.