«

James Kanze wrote:
>> This is more or less the same as using an exported template,
>> but in the reverse direction -- from a viewpoint of the
>> standard, there's no question that it's acceptable. For real
>> use, it's completely unacceptable for nearly everybody (i.e.
>> anybody who has to use any compiler other than Comeau).
>
> 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)

--
Gennaro Prota | <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

"Greg Comeau" <> wrote in message
news:g6v9mn$sa1$...


> 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

"Pete Becker" <> wrote in message
news:2008080118071816807-pete@versatilecodingcom...
> On 2008-08-01 17:33:44 -0400, "kwikius" <>
> said:
>
>>
>> "Greg Comeau" <> wrote in message
>> news:g6v9mn$sa1$...
>>
>>
>>> 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.

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

"Pete Becker" <> wrote in message
news:2008080207260416807-pete@versatilecodingcom...
> On 2008-08-02 06:15:32 -0400, "kwikius" <>
> said:
>
>>
>> "Pete Becker" <> wrote in message
>> news:2008080118071816807-pete@versatilecodingcom...
>>> On 2008-08-01 17:33:44 -0400, "kwikius" <>
>>> said:
>>>
>>>>
>>>> "Greg Comeau" <> wrote in message
>>>> news:g6v9mn$sa1$...
>>>>
>>>>
>>>>> 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

On Aug 2, 11:54 am, blargg <blargg....@gishpuppy.com> wrote:
> In article
> <a3e60d63-d0ad-4e24-b8df-c7fdddd0a...@j22g2000hsf.googlegroups.com>,
> James Kanze <james.ka...@gmail.com> wrote:

> > ...
> > 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:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34