Initialising a BOOL array to TRUE ??

[Gennaro Prota]

Exactly. The word "C++" has a different meaning in the two
groups.

Who knows... he said something like "the standard requires
std::vector<bool> to be specialized to store bools compactly" (from
memory), and his sentence was about as vague as the one from the
standard (i.e.: it wasn't clear whether he just said that
specialization is required, or that specialization and compact
representation are both required). So I thought to be a little more
precise, especially considering that the intent isn't something you
can gather from the standard directly. For the rest, he was the one
mentioning "standard". (What a useless sub-thread, really)

 

[kwikius]

Besides, everbody knows that 0.5 is a good compromise

hmm interesting. FWIW I'm currently working on a quantum boolean type. It
may be true, or maybe false or even simultaneously true and false. The act
of reading or copying it changes its state of course, so each read or copy
you will need to remember its actually in the other state or even in a state
of superposition between states. The real interesting useage is an atomic
flag in a multi-threaded app of course ...

regards
Andy Little

 

[kwikius]

It would be more interesting as a subatomic flag.

Ahh yes. Well we did experiment with this but found that once we went
subatomic the boolean variable could flip states , disappearing from its
rightful place within one application and appearing in another. Furthermore
the other application could even be on an entirely different PC anywhere in
the world distant in time or even in a PC belonging to some alien
civilisation in a far flung corner of the galaxy.

Therefore, though interesting and having been offered an indecent amount of
funding to explore this approach by a certain large military government
establishment we sadly had to curtail our work in that area on moral
grounds.

I expect the idea will appear on boost.org soon with the grant money but
under someone elses name as their original work of course...

AMDG

regards
Andy Little

 

[kwikius]

RPC via quantum tunneling.

hmm Interesting. In fact this is probably the explanation why the Y2K bug
never materialised... apparently. IOW though the quantum boolean is still
only alpha at our shop, we can assume that the problems will be solved, then
quantum booleans can be sent back in time ... via a quantum tunnelling RPC ,
to intercept all those Y2k bugs. This presumably does happen at some future
time.

Meanwhile I must apologise. If you have a bug in you app past, present or
future that just doesnt seem to have any explanation, it is probably a
result of our beta testing. Unfortunately we lost a few :-( so there are
quite a few of these things flying around by now.

regards
Andy Little

 

[James Kanze]

This is my understanding as well. If a particular platform
could more efficiently convert a non-zero value to -1 rather
than 1, I'd expect a compiler to use all bits set for a true
bool, and only convert this to 1 when converting a bool to
int, which should occur less often than non-zero value to
bool.

I agree, although I suspect that in practice, there are few
platforms where it would make a difference. (Or are there. On
platforms which don't have an instruction to convert the result
of a comparison into a word---and that includes early Intel
8086---the classic trick was to get the bool into the carry bit
somehow, and then SUBC AX,AX, or whatever: subtract a register
from itself, with carry. Which, of course, results in either 0
or -1, i.e. all bits set, depending on the carry bit.)

I'd also expect such a compiler to optimize an expression like
(b1 && (b2 || b3)) into (b1 & (b2 | b3)), where b* are
non-volatile booleans with no side-effects when accessed,
since it can rely on the booleans containing only one of two
values, one being zero (assuming that's how it represents
bool).

I would to, if it makes a difference (and it might, since it
means no branch instructions).