Initialising a BOOL array to TRUE ??

[James Kanze]

Re: Initialising a BOOL array to TRUE ??

On Aug 1, 2:24 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

James Kanze <james.ka...@gm ail.comwrites:

I don't know about C, but in C++, a bool can only take on two
legal values, true and false.

Ditto in C. That is why I said "historical ly" and "booleans"
(rather than bools). It is safe (but odd) in C99 to test a
bool == true.

I know that C99 added _Bool, but I'm not too sure about its
semantics. 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.)

And because C and C++ do define bool differently (i.e. using
different words---the definitions in C99 are not copied from
C++), it's far from sure that C offers the same liberty in this
regard. (At the "correct" usage level, they should behave the
same.)

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

[James Kanze]

Re: Initialising a BOOL array to TRUE ??

On Aug 1, 1:45 am, Jerry Coffin <jcof...@taeus. comwrote:

In article <g6thq7$qr...@a ioe.org>, gennaro/pr...@yahoo.com says...

[ ... ]
comp.lang.c++ is about _using_ C++; when _every_ compiler
extant works in a particular way, that's how the language
works as far as actual use goes, even if (theoretically)
something else could exist.

To agree with you, but in somewhat different words: the
definition of C++ differs between the groups: in comp.std.c++
(supposing it was still there), C++ means the language defined
by ISO 14882, and nothing else. Here, C++ means what we
generally understand by the language, accross all (or most)
platforms implementing it. (Thus, for example, here, there is
no "export":-(. But there are threads, DLL's and who knows what
all else.)

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.

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

[Pascal J. Bourguignon]

Re: Initialising a BOOL array to TRUE ??

James Kanze <james.kanze@gm ail.comwrites:

On Aug 1, 2:24 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>James Kanze <james.ka...@gm ail.comwrites:

I don't know about C, but in C++, a bool can only take on two
legal values, true and false.

>

>Ditto in C. That is why I said "historical ly" and "booleans"
>(rather than bools). It is safe (but odd) in C99 to test a
>bool == true.

>
I know that C99 added _Bool, but I'm not too sure about its
semantics. 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.)

I'd be not so sure. Depends on the processor. For example, the 680x0
boolean instructions use $ff for true and $00 for false (ST, SF, SEQ,
SNE, etc). A superfast compiler for these processors wouldn't lose
time with a NEG.B needed to get 0 or 1, so you could get 0 or 255 for
false or true. Or, if sign-extended, 0 or -1.

Hence the goodness of defining i=b; to be i=b?1:0;


--
__Pascal Bourguignon__

[Pete Becker]

Re: Initialising a BOOL array to TRUE ??

On 2008-08-01 08:35:59 -0400, pjb@informatima go.com (Pascal J.
Bourguignon) said:

>
I'd be not so sure. Depends on the processor. For example, the 680x0
boolean instructions use $ff for true and $00 for false (ST, SF, SEQ,
SNE, etc). A superfast compiler for these processors wouldn't lose
time with a NEG.B needed to get 0 or 1, so you could get 0 or 255 for
false or true. Or, if sign-extended, 0 or -1.
>
Hence the goodness of defining i=b; to be i=b?1:0;

The C++ standard defines the result of converting a bool object to any
integral type. false becomes 0 and true becomes 1, regardless of the
internal representation or whether the compiler is "superfast" .

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

[Greg Comeau]

Re: Initialising a BOOL array to TRUE ??

In article <7cd4kslxow.fsf @pbourguignon.a nevia.com>,
Pascal J. Bourguignon <pjb@informatim ago.comwrote:

>James Kanze <james.kanze@gm ail.comwrites:

>On Aug 1, 2:24 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>>James Kanze <james.ka...@gm ail.comwrites:
>I don't know about C, but in C++, a bool can only take on two
>legal values, true and false.

>>

>>Ditto in C. That is why I said "historical ly" and "booleans"
>>(rather than bools). It is safe (but odd) in C99 to test a
>>bool == true.

>>
>I know that C99 added _Bool, but I'm not too sure about its
>semantics. 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.)

>
>I'd be not so sure. Depends on the processor. For example, the 680x0
>boolean instructions use $ff for true and $00 for false (ST, SF, SEQ,
>SNE, etc). A superfast compiler for these processors wouldn't lose
>time with a NEG.B needed to get 0 or 1, so you could get 0 or 255 for
>false or true. Or, if sign-extended, 0 or -1.
>
>Hence the goodness of defining i=b; to be i=b?1:0;

If you mean to actually code that last statement: don't.
From what I can see, James and Ben's statements are completely
correctly. Getting them correct faster is ok too though :)
Seriously, I suspect your mixing the syntax requirements
and the way the source code can look with the underlying representations
and internal semantics. Besides, everbody knows that 0.5 is
a good compromise :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Ben Bacarisse]

Re: Initialising a BOOL array to TRUE ??

James Kanze <james.kanze@gm ail.comwrites:

On Aug 1, 2:24 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>James Kanze <james.ka...@gm ail.comwrites:

I don't know about C, but in C++, a bool can only take on two
legal values, true and false.

>

>Ditto in C. That is why I said "historical ly" and "booleans"
>(rather than bools). It is safe (but odd) in C99 to test a
>bool == true.

>
I know that C99 added _Bool, but I'm not too sure about its
semantics. 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.

Yes, and this is true in C also. (Lets assume stdbool.h is included
then we can use "bool".)

I'm not sure, but I don't think it makes any
guarantees with regards to what the actual bits in b contain.

In C, because _Bool is an unsigned integer type, it is composed only
of value bits and padding bits and because its value can be only 0 or
1 we know that there is only one value bit. All the other
sizeof(_Bool)*C HAR_BIT bits are padding.

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

A C implementation could use those values, but I am not entirely sure
a C++ implementation could. C could not, however, use 15 for false
and 7 for true since one of the bits must be a value bit set 1 to
represent 1 and 0 to represent 0. For an 8-bit bool there are two
eligible value bits in your 43/7 example.

And because C and C++ do define bool differently (i.e. using
different words---the definitions in C99 are not copied from
C++), it's far from sure that C offers the same liberty in this
regard. (At the "correct" usage level, they should behave the
same.)

My reading of C++ is that there is slightly /less/ freedom in the
representation used for bool. bool is an integer type in C++ (but it
is not guaranteed to be unsigned as in C) and integral types must use
a "pure binary representation" using 2's complement, 1's complement or
sign and magnitude. I can't see any permission for padding bits
within a POD of integral type. Of course, all the explicit talk of
conversions in C++ may be intended to say that, while there may be
lots of bits in the value of a bool, you never "see" them because it
always converts to 1 or 0 and always compares to true or false.

--
Ben.

[Pete Becker]

Re: Initialising a BOOL array to TRUE ??

On 2008-08-01 11:21:59 -0400, comeau@panix.co m (Greg Comeau) said:

Besides, everbody knows that 0.5 is
a good compromise :)

Only if both alternatives are equally likely. For rare events it should
be lower.

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

[James Kanze]

Re: Initialising a BOOL array to TRUE ??

On Aug 1, 5:21 pm, com...@panix.co m (Greg Comeau) wrote:

In article <7cd4kslxow.... @pbourguignon.a nevia.com>,
Pascal J. Bourguignon <p...@informati mago.comwrote:

[...]

Hence the goodness of defining i=b; to be i=b?1:0;

If you mean to actually code that last statement: don't.

You could argue that implicit conversions hurt readability, and
prefer something more explicit than just "i = b", either an
explicit conversion, or that last statement. I'll admit that
while I would agree with that in theory, I don't often bother in
practice.

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

[James Kanze]

Re: Initialising a BOOL array to TRUE ??

On Aug 1, 5:36 pm, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

James Kanze <james.ka...@gm ail.comwrites:

On Aug 1, 2:24 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

James Kanze <james.ka...@gm ail.comwrites:
I don't know about C, but in C++, a bool can only take on two
legal values, true and false.

Ditto in C. That is why I said "historical ly" and "booleans"
(rather than bools). It is safe (but odd) in C99 to test a
bool == true.

I know that C99 added _Bool, but I'm not too sure about its
semantics. 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.

Yes, and this is true in C also. (Lets assume stdbool.h is
included then we can use "bool".)

I'm not sure, but I don't think it makes any guarantees with
regards to what the actual bits in b contain.

In C, because _Bool is an unsigned integer type, it is composed only
of value bits and padding bits and because its value can be only 0 or
1 we know that there is only one value bit. All the other
sizeof(_Bool)*C HAR_BIT bits are padding.

Ah, yes. That would cover it.

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

A C implementation could use those values, but I am not
entirely sure a C++ implementation could. C could not,
however, use 15 for false and 7 for true since one of the bits
must be a value bit set 1 to represent 1 and 0 to represent 0.
For an 8-bit bool there are two eligible value bits in your
43/7 example.

And because C and C++ do define bool differently (i.e. using
different words---the definitions in C99 are not copied from
C++), it's far from sure that C offers the same liberty in
this regard. (At the "correct" usage level, they should
behave the same.)

My reading of C++ is that there is slightly /less/ freedom in
the representation used for bool. bool is an integer type in
C++ (but it is not guaranteed to be unsigned as in C) and
integral types must use a "pure binary representation" using
2's complement, 1's complement or sign and magnitude. I can't
see any permission for padding bits within a POD of integral
type.

The first paragraph of §3.9.1: "For character types, all bits of
the object representation participate in the value
representation. For unsigned character types, all possible bit
patterns of the value representation represent numbers. These
requirements do not hold for other types." Note that last
sentence: for other types (including bool), it is not required
that all bits participate in the value representation. Trapping
representations are definitly allowed.

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

[Gennaro Prota]

Re: Initialising a BOOL array to TRUE ??

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

[kwikius]

Re: Initialising a BOOL array to TRUE ??


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

regards
Andy Little

[Pete Becker]

Re: Initialising a BOOL array to TRUE ??

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

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

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

[blargg]

Re: Initialising a BOOL array to TRUE ??

In article
<a3e60d63-d0ad-4e24-b8df-c7fdddd0ab96@j2 2g2000hsf.googl egroups.com>,
James Kanze <james.kanze@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'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).

[blargg]

Re: Initialising a BOOL array to TRUE ??

In article <7cd4kslxow.fsf @pbourguignon.a nevia.com>,
pjb@informatima go.com (Pascal J. Bourguignon) wrote:

James Kanze <james.kanze@gm ail.comwrites:

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

>
I'd be not so sure. Depends on the processor. For example, the 680x0
boolean instructions use $ff for true and $00 for false (ST, SF, SEQ,
SNE, etc). A superfast compiler for these processors wouldn't lose
time with a NEG.B needed to get 0 or 1, so you could get 0 or 255 for
false or true. Or, if sign-extended, 0 or -1.
>
Hence the goodness of defining i=b; to be i=b?1:0;

Such a compiler would need to do a NEG.B when converting a bool to int.
If ever i = b resulted in i having a value other than 0 or 1, the
compiler would be broken (except perhaps if one modified a bool via a
reinterpret_cas t).

[kwikius]

Re: Initialising a BOOL array to TRUE ??


"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$sa 1$1@panix2.pani x.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.

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