Absense of bool

[Guest]

I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.

If the point is just pretty coding, then:
typedef int bool;

Or better:
typedef unsigned bool;
(Operations on unsigned values are often less expensive than signed ones)

JJ

 

[Guest]

First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.

Why a major flaw? What do you need the concept of boolean type in C for?
Anyway, if you really NEED it, you can always typedef it.

It would just complicate things. Besides, it's just against the design
principle of C.
C just implements some basic abstractions in order to make it easy to
program in low level. It abstracts variables, functions, static memory
structures (structs and arrays) and algorithms. JUST that!
It doesn't even define I/O resources. All that (including dynamic
allocation) is defined/implemented by the Standard Library (which is not,
strictly, part of the language / indeed, you can replace the C standard
library, create your own and use it in your program).

C is not a portable assembly. However, it is a language that works *like*
assembly. It's not meant to extend assembly, but only to provide a portable
and more structured equivalently featured language. It picks a number of
rules that, generally, any serious ASM program needs to follow (like being
logically separated in procedures, carefully allocating meaningful
variables across registers and memory, establishing uniform calling
conventions, putting sequentially accessed data in neighbor memory
addresses, not doing self-modifying code tricks, etc), and adds them to the
core language to save the programmer from having to follow them.
Additionally, it abstracts the processor's Instruction Set in order to
allow you to describe algorithms machine-independently.

- C has pointers because machine code needs pointers.
- In C, an array is represented as a pointer to it's first element
because, in ASM, arrays are represented and manipulated like that.
- C, natively, only knows how to deal with logical and arithmetic data.
That's because most processors only know that.
- C doesn't have built-in Garbage Collection because ASM languages don't
support the concept either.
- C doesn't have dynamic typing simply because there's no direct way to
tell the type of a data structure in machine code.
- C integers overflow because integers, in ASM, overflow too...
- Like above, C doesn't have a boolean data type because processors
emulate boolean values with (modular) integers, too. The exception may be,
perhaps, bit-addressed machines (I don't know, never programmed one)...

That doesn't mean that you are limited to what the language offers you.
Just like what happens in assembly, you can always extend the language at
your will. (of course, you can still do much more in assembly, but it's
generally special purpose)

OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.

But THAT's the point.
C is very extensible through the library (and again, just like it happens
to be in assembly).

Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.

Nope... Unless you want a bit field (in order to have many bools inside a
byte), it's much more efficient to manipulate entire words instead of chars...

Even if you save some space, the processor will need to sign extend the
byte in order to work with it.

JJ

 

[Chris Dollin]

If the point is just pretty coding, then:
typedef int bool;

Or better:
typedef unsigned bool;
(Operations on unsigned values are often less expensive than signed ones)

They are?

Which operations, how much, and how often?

 

[Richard]

Why a major flaw? What do you need the concept of boolean type in C for?
Anyway, if you really NEED it, you can always typedef it.

It would just complicate things. Besides, it's just against the design
principle of C.
C just implements some basic abstractions in order to make it easy to
program in low level. It abstracts variables, functions, static memory
structures (structs and arrays) and algorithms. JUST that!

I would be interested in this "abstraction" you refer to. Please
explain. How does C "abstract" anything? Your comments below don't do
that.

It doesn't even define I/O resources. All that (including dynamic
allocation) is defined/implemented by the Standard Library (which is not,
strictly, part of the language / indeed, you can replace the C standard
library, create your own and use it in your program).

C is not a portable assembly. However, it is a language that works
*like*

There are not many "portable assemblies" :-;

assembly. It's not meant to extend assembly, but only to provide a portable
and more structured equivalently featured language. It picks a number of
rules that, generally, any serious ASM program needs to follow (like being
logically separated in procedures, carefully allocating meaningful
variables across registers and memory, establishing uniform calling
conventions, putting sequentially accessed data in neighbor memory
addresses, not doing self-modifying code tricks, etc), and adds them to the
core language to save the programmer from having to follow them.
Additionally, it abstracts the processor's Instruction Set in order to
allow you to describe algorithms machine-independently.

You mean like almost every other language out there?

- C has pointers because machine code needs pointers.

I suspect that is not the reason. C has pointers because people need
efficient direct access to memory and variable values. Regardless how
people want to play word games.

- In C, an array is represented as a pointer to it's first element
because, in ASM, arrays are represented and manipulated like that.

There are no such things as arrays in most ASM - indexed memory yes...

- C, natively, only knows how to deal with logical and arithmetic data.
That's because most processors only know that.

Is this without the standard library?

- C doesn't have built-in Garbage Collection because ASM languages don't
support the concept either.

No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.

- C doesn't have dynamic typing simply because there's no direct way to
tell the type of a data structure in machine code.
- C integers overflow because integers, in ASM, overflow too...

This is not true. The underlying actions of the ASM are covered and
hidden by the standard.

 

[Guest]

I would be interested in this "abstraction" you refer to. Please
explain. How does C "abstract" anything? Your comments below don't do
that.

You looked the wrong way. It's not *below* but *ABOVE*.
"It abstracts variables, functions, static memory structures (structs and
arrays) and algorithms. JUST that!"

There are not many "portable assemblies" :-;

No... There are no portable assemblies...

However, someone wrote in this thread that C is portable assembly.

You mean like almost every other language out there?

No. High level languages (i do not include C in this group) typically
abstract concepts much further than C does.
Many have native support for lists, dictionaries, higher-order functions,
and much more.

I suspect that is not the reason. C has pointers because people need
efficient direct access to memory and variable values.

Yes... I also suspect that, if pointers weren't needed, they wouldn't have
been implemented in C.
That's what happens with calling conventions: they are irrelevant, so they
are abstracted. All you need is a logical idea of what is passed to
functions as arguments and what is returned.

Although, both are needed in machine code, right? So C abstracts the
irrelevant concept and maintains the relevant one as it is.
But C doesn't add abstractions that don't usually exist in machine languages.

There are no such things as arrays in most ASM - indexed memory yes...

Arrays, variables, functions, classes and every other programming concept
that you ever used exists in assembly whenever you apply them. However,
they aren't abstracted (this is, the language compiler doesn't know about
them).
Lists aren't abstracted in C. However, they exist since you implement
primitives that deal with linked lists.

Is this without the standard library?

No! Don't tell me that C needs the standard library to do arithmetic! I
don't think so!

No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.

Yes.
ASM languages don't support the concept of GC, but the compiler could
generate ASM code that took care of the business.

However, for many reasons, among others:
- It makes the code less efficient
- It would be an extra feature (that does not natively exist in ASM languages)
- And, of course, it didn't exist when C was invented (however pointless
it is, because C could have been created today with no GC, be it the
creators' will)

....it was not included in the language.

This is not true. The underlying actions of the ASM are covered and
hidden by the standard.

You are still off to the point.
The underlying actions are covered, but the additional instructions that
the compiler would need to issue would be an extension to what is possible
to do directly in machine language.

Of course, the compiled program could store an integer, along with the
variable itself, so that it could identify the variable's type latter. But
it would be an extension to the features of ASM.

JJ

 

[Guest]

They are?

Which operations, how much, and how often?

In reality, they don't matter for bools...

Multiplications and divisions.

JJ

 

[santosh]

No, C doesnt have it because it didnt exist when C was invented and it
makes a mockery of efficiency IMO.

No. Garbage collection existed before C. LISP had it.

<snip>

 

[santosh]

No! Don't tell me that C needs the standard library to do arithmetic!
I don't think so!

Some arithmetic operations may however be implemented as "magic"
function calls, essentially compiler magic, invisible from the
standpoint of Standard C. Extended width arithmetic is typically done
this way.

<snip>

 

[Flash Gordon]

João Jerónimo wrote, On 05/11/07 17:49:

In reality, they don't matter for bools...

Multiplications and divisions.

On the processors where I have had an interest in the speed those were
no slower for signed than for unsigned. This shows that at the very
least your assertion is not true for all implementations.

 

[Martin Ambuhl]

No. Garbage collection existed before C. LISP had it.

<snip>

I'm shocked! Can it be true that someone actually reads post from
(e-mail address removed)?

 

[Tor Rustad]

Nowhere in the mandate of the standard committee is there any
requirement to avoid keywords or other identifiers that Tor Rustad, or
Jack Klein, or any other C programmer or group of C programmers
considers ugly.

Cosmetic issues matter to the working programmer, why wasn't Pascal/Ada
a hit?

The spirit of C is to have a small and simple language (among other
things). C99 was mainly about scientific computing, bloating the
standard to ca. 550 pages.

Not so hard perhaps. But how hard would it be in some industries to
document all of the code changes to hundreds or thousands of files?

A quick search through the header files of Linux kernel, show that most
hits (if not all) could have been removed by filtering away the comments:

/usr/include/linux$ grep -r 'bool' *.h
audit.h:#define AUDIT_MAC_CONFIG_CHANGE 1405 /* Changes to booleans */
auxvec.h:#define AT_SECURE 23 /* secure mode boolean */
video_decoder.h:#define DECODER_ENABLE_OUTPUT _IOW('d', 6, int)
/* boolean output enable control */
video_encoder.h:#define ENCODER_ENABLE_OUTPUT _IOW('e', 5, int)
/* boolean output enable control */

/usr/include/linux$ grep -r 'false' *.h
filter.h: __u8 jf; /* Jump false */
reiserfs_fs.h:/** always check a condition and panic if it's false. */
telephony.h:* a TRUE if the device has that capability, otherwise it
returns false.

/usr/include/linux$ grep -r 'true' *.h
cdrom.h: if the "xa_flag" is true. */
ethtool.h: * being true) the user may set 'autonet' here non-zero
to have the
fb.h: struct fb_bitfield red; /* bitfield in fb mem if true
color, */
fdreg.h: * This is especially true if the tests are unneeded.
filter.h: __u8 jt; /* Jump true */
ixjuser.h:* bytes of physical buffer memory for the record channel so
the true
kernel.h:/* Force a compilation error if condition is true */
wanrouter.h: unsigned char true_if_encoding; /* Set the dev->type to
true board protocol */

And why force that work on people with large code bases with no gain
for their efforts?

Nobody was forced to use C99, it's rather a major failure of C99, that
most people still use C90.

The committee does have a mandate to avoid breaking existing code,
even if that code could be fixed with a "simple" (maybe), find and
replace.

Bah.. making bool/true/false *keywords*, would have been the right thing
to do, and such a change, would be trivial for a porting team in most
cases. What to really watch out for, are rather the *quiet changes*.

_Bool and _Complex do not break any existing code that did not invade
the implementation's reserved namespace.

Normally, engineering improvements are done via control process
feedback. Unless backward compatibility is broken at times, the C
language cannot remove/fix poor features.

Hopefully, the C1x standards people will focus more on improvements for
system, security and embedded programming, else I beleave C language is
heading towards self-destruction.

 

[CBFalconer]

I'm shocked! Can it be true that someone actually reads post from
(e-mail address removed)?

Once in a while I find he has made a direct reply to me (which
hasn't been quoted) and become curious about any improvement. Then
I mark that reply unread, and my next connection to the news-server
gets it. In general I find no improvement.

 

[Richard]

Marvin L. Minsky. A Lisp garbage collector algorithm using serial
secondary storage. Technical Report Memo 58 (rev.), Project MAC, MIT,
Cambridge, MA, December 1963.

I don't claim that this is the first paper on GC, just that it
pre-dates C. There are dozens of papers about GC from the 60s and DMR
cites 1969-73 as the key design time for C.

What languages used GC at the time that C and its forefathers were
evolving? How do you see GC fitting into the "style" of C?

Putting GC into C would have been like interpreting assembler IMO ....

 

[Chris Dollin]

What languages used GC at the time that C and its forefathers were
evolving?

Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
I think the timing fits, but I can't remember when RSRE did the first
A68 implementation. Certainly the technology was "well known".

How do you see GC fitting into the "style" of C?

It didn't (certainly not at that time). Tradeoffs change.

Putting GC into C would have been like interpreting assembler IMO ....

A perfectly reasonable thing to do, in some circumstances.

 

[Chris Dollin]

Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.

Argh! How could I forget POP2!

 

[Richard Tobin]

Marvin L. Minsky. A Lisp garbage collector algorithm using serial
secondary storage. Technical Report Memo 58 (rev.), Project MAC, MIT,
Cambridge, MA, December 1963.

I don't claim that this is the first paper on GC

The OED's first citation for "garbage collector" is 1960, McCarthy's
LISP I Programmer's Manual.

-- Richard

 

[Richard]

Lisp, Algol W, Algol 68, Snobol (I think that's in the frame), Simula 67.
Off the top of my head, and not intended to be exhaustive by any means.
I think the timing fits, but I can't remember when RSRE did the first
A68 implementation. Certainly the technology was "well known".


It didn't (certainly not at that time). Tradeoffs change.

I know. Hence my question. My stance is that it simply wasnt available
as a practical workable solution in the confines/structure of the C
style and mindset.

Yes, yes, it might have added value to "some" people.

A perfectly reasonable thing to do, in some circumstances.

As is smearing ketchup all over your printouts I'm sure. if we reason
like that then it was also perfectly reasonable to interpret the C as
opposed to compile it :-;

 

[Richard]

Argh! How could I forget POP2!

Yup all very C-like. What were the designers of C thinking!!!

 

[Richard Tobin]

I think the timing fits, but I can't remember when RSRE did the first
A68 implementation. Certainly the technology was "well known".

It was RRE in those days. The "first published" date in the
ALGOL 68-R Users [sic] Guide is 1972.

-- Richard

 

[Ben Bacarisse]

Richard wrote:

Yes.

- And, of course, it didn't exist when C was invented

Marvin L. Minsky. A Lisp garbage collector algorithm using serial
secondary storage. Technical Report Memo 58 (rev.), Project MAC, MIT,
Cambridge, MA, December 1963.

I don't claim that this is the first paper on GC, just that it
pre-dates C. There are dozens of papers about GC from the 60s and DMR
cites 1969-73 as the key design time for C.