Initialising a BOOL array to TRUE ??

[Pete Becker]

Re: Initialising a BOOL array to TRUE ??

On 2008-08-02 06:15:32 -0400, "kwikius" <andy@servocomm .freeserve.co.u ksaid:

>
"Pete Becker" <pete@versatile coding.comwrote in message
news:2008080118 071816807-pete@versatilec odingcom...

>On 2008-08-01 17:33:44 -0400, "kwikius" <andy@servocomm .freeserve.co.u k>
>said:
>>

>>>
>>"Greg Comeau" <comeau@panix.c omwrote in message
>>news:g6v9mn$s a1$1@panix2.pan ix.com...
>>>
>>>
>>>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 ...
>>>

>>
>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.
>

RPC via quantum tunneling.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[kwikius]

Re: Initialising a BOOL array to TRUE ??


"Pete Becker" <pete@versatile coding.comwrote in message
news:2008080207 260416807-pete@versatilec odingcom...

On 2008-08-02 06:15:32 -0400, "kwikius" <andy@servocomm .freeserve.co.u k>
said:
>

>>
>"Pete Becker" <pete@versatile coding.comwrote in message
>news:200808011 8071816807-pete@versatilec odingcom...

>>On 2008-08-01 17:33:44 -0400, "kwikius" <andy@servocomm .freeserve.co.u k>
>>said:
>>>
>>>>
>>>"Greg Comeau" <comeau@panix.c omwrote in message
>>>news:g6v9mn$ sa1$1@panix2.pa nix.com...
>>>>
>>>>
>>>>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 ...
>>>>
>>>
>>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.
>>

>
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]

Re: Initialising a BOOL array to TRUE ??

On Aug 2, 11:54 am, blargg <blargg....@gis hpuppy.comwrote :

In article
<a3e60d63-d0ad-4e24-b8df-c7fdddd0a...@j2 2g2000hsf.googl egroups.com>,
James Kanze <james.ka...@gm ail.comwrote:

...
If I understand the C++ standard correctly, it
guarantees that, given:

bool b ;
int i ;

, i = b will result in i having the value of 0 or 1, and b = i
will result in b having the value false if i == 0, and true
otherwise. I'm not sure, but I don't think it makes any
guarantees with regards to what the actual bits in b contain. I
think an implementation could ue 43 for true, and 7 for false,
as long as it did the conversions correctly. (Practically,
speaking, of course, no implementation will do this.)

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).

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34