Re: /usr/include/curses.h not fixed on sparc-sun-solaris2.5.1

[Per Bothner <bothner at cygnus dot com>]

> Please keep the performance hit as low as possible!

That is of course the goal.  Last time this was brought up,
our compiler hackers suggested the time penalty of 1-byte bool could
be much reduced by having gcc use full-word registers inside functions.
That sounds reasonable, but I don't know the relevant parts of the compiler.

> our code took more than twice(!) as long due to the new
> specialization of vector<bool>. :-(

But that has nothing to do with sizeof(bool)!  If vector<bool>
packs multiple booleans (one per bit) into a byte, of course there
will be a speed penalty compared to used one byte or one word
per boolean.  That is, unless the arrays are large enough to
effect your cache hit ratio and/or paging working set, in which
case it might well go the other way - or worse!

Whether vector<bool> should use a bit-packed representation
depends on the application.  Thus the programmer needs a
choice between packed and unpacked bool arrays.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner