Re: Introduce proper bool types - finally.
[I am moving this to -beta]
Martin Buchholz <martin(a)xemacs.org> writes:
Is it really so bad to be able to say
static size_t
Lstream_adding (Lstream *lstr, size_t num, bool force)
...
size_t chunk = Lstream_adding (lstr, size, false);
No. But it doesn't have that warm comfy feeling :-)
Having done some benchmarking, I hereby retract the part of the
patch
that defined a bool type that occupies a char. The first compiler I
tried gave a 17% performance improvement in (garbage-collect) by
making the mark bit a char. However, other compilers have not
confirmed the advantage of this change - some work the other way
around.
Jan: By the way, this means that I'm not sure I believe your 10%
redisplay speedup is for real - you might have just been lucky with
your choice of compiler and machine.
Note that that choice included Solaris with its native compiler and
egcs 1.1 on i386 so I think it covers the majority of users.
However I frankly do not believe that this patch could cause a
slowdown anywhere. it does not increase the size of the structure. Are
there really compilers/machine that are faster at masking off bits
then at reading bytes. What I can believe is that there isn't a speed
up on machine that cannot do byte addressing and thus have to masking
for that too..
So let's just talk about `bool'. Is it so bad to have a type
that
expresses the idea of a `bit' in a standard way? After all, Elisp
also knows about bits.
This patch seems to be going down in flames, but I'd really like to
know why there is such *strong* opposition.
Because I like the fact that in C truth values (not bits) are
represented by numbers. I simply do not see the use of introducing
bolos. For instance in the example above I do not see any gain in
clarity.
It might make sense in languages that are much more strongly typed but
I cannot see it in C.
Jan