Initialising a BOOL array to TRUE ??

[Simon L]

BOOL bMyarray[1000];
memset(bMyArray , 0xFF, sizeof(BOOL) * 1000);

clean & quick until someone else's code found I was returning -1 to
mean true

Because my BOOL is 4 bytes long, TRUE in memory works out as 01 00 00
00 which is a right pain.

Doing it in a for loop is 10 x slower btw.

Bit of a numpty question this, is there another way?

TIA

[Ian Collins]

Simon L wrote:

BOOL bMyarray[1000];
memset(bMyArray , 0xFF, sizeof(BOOL) * 1000);

clean & quick until someone else's code found I was returning -1 to
mean true

Because my BOOL is 4 bytes long, TRUE in memory works out as 01 00 00
00 which is a right pain.

Why not use bool?

--
Ian Collins.

[Simon L]

Why not use bool?

--
Ian Collins.

I'm working in C (oops, wrong group..)

[Pascal J. Bourguignon]

Simon L <si*******@hotmail.comwrites:

BOOL bMyarray[1000];
memset(bMyArray , 0xFF, sizeof(BOOL) * 1000);

clean & quick until someone else's code found I was returning -1 to
mean true

Because my BOOL is 4 bytes long, TRUE in memory works out as 01 00 00
00 which is a right pain.

Doing it in a for loop is 10 x slower btw.

Bit of a numpty question this, is there another way?

If you have a lot of booleans, it may be worthwhile to store them as
bits. Using less memory, more of the vector will stay in L1-cache, so
accessing them will be faster (even considering the bit
packing/unpacking):
#include <iostream>
#include <limits.h>
typedef int bit; // one bit, 0 or 1
typedef int word; // some bits
#ifndef WORD_BIT
#define WORD_BIT (sizeof(word)*CHAR_BIT)
#endif

class bit_vector {
protected:
unsigned int dimension;
word* words;
public:
bit_vector(unsigned int dimension){
this->dimension=dimension;
this->words=new word[(this->dimension+WORD_BIT-1)/WORD_BIT];
}
virtual ~bit_vector(){
delete [] this->words;
}

inline bit operator[](unsigned int index){
return((index<this->dimension)
?(1&(this->words[index/WORD_BIT]>>(index%WORD_BIT)))
:0); }

inline bit set(unsigned int index,bit value){
if(index<this->dimension){
if(value==0){
this->words[index/WORD_BIT]&=(~(1<<(index%WORD_BIT)));
}else{
this->words[index/WORD_BIT]|=(1<<(index%WORD_BIT)); }}
return(value); }

// so now filling the vector will be 256 times faster:

void fill(bit value){
word filler=(value==0)?(0):(~0);
for(unsigned int i=0;i<(this->dimension+WORD_BIT-1)/WORD_BIT;i++){ this->words[i]=filler; }}

};

using namespace std;

int main(void){
bit_vector v(1000);
v.fill(1);
cout<<v[0]<<", "<<v[999]<<endl;
v.fill(0);
cout<<v[0]<<", "<<v[999]<<endl;
v.set(0,1);
cout<<v[0]<<", "<<v[999]<<endl;
v.set(999,1);
cout<<v[0]<<", "<<v[999]<<endl;
return(0);
}

--
__Pascal Bourguignon__

[Ben Bacarisse]

Simon L <si*******@hotmail.comwrites:

>Why not use bool?

--
Ian Collins.

It is best not to quote sigs.

I'm working in C (oops, wrong group..)

C also has bool.

By the way, if you want to save some pride, it is likely that the code
that found out you were using -1 for true is flawed. -1 is a
perfectly good true value (in both C an C++) it just does not compare
== to true. Good code should not test booleans for equality simply
because, historically, anything not zero is true.

--
Ben.

[Jerry Coffin]

In article <7c************@pbourguignon.anevia.com>,
pj*@informatimago.com says...

[ ... ]

If you have a lot of booleans, it may be worthwhile to store them as
bits. Using less memory, more of the vector will stay in L1-cache, so
accessing them will be faster (even considering the bit
packing/unpacking):

[ code elided ]

While your advice is certainly reasonable, I'd note that yet _another_
bit-vector implementation is about the last thing C++ needs. The
standard requires that std::vector<boolbe specialized to store bools
as a single bit apiece. The standard also includes std::bitset for
storing, manipulating, etc., sequences of bits. In the case of bitset,
the size of the set is a template argument, so it must be a compile-time
constant.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Pascal J. Bourguignon]

Jerry Coffin <jc*****@taeus.comwrites:

In article <7c************@pbourguignon.anevia.com>,
pj*@informatimago.com says...

[ ... ]

>If you have a lot of booleans, it may be worthwhile to store them as
bits. Using less memory, more of the vector will stay in L1-cache, so
accessing them will be faster (even considering the bit
packing/unpacking):

[ code elided ]

While your advice is certainly reasonable, I'd note that yet _another_
bit-vector implementation is about the last thing C++ needs. The
standard requires that std::vector<boolbe specialized to store bools
as a single bit apiece. The standard also includes std::bitset for
storing, manipulating, etc., sequences of bits. In the case of bitset,
the size of the set is a template argument, so it must be a compile-time
constant.

Ah, that's true, I forgot std::vector<boolwas special-cased.

--
__Pascal Bourguignon__

[James Kanze]

On Jul 31, 2:19 pm, Ben Bacarisse <[e-mail]:

Simon L <[e-mail]:

Why not use bool?

I'm working in C (oops, wrong group..)

C also has bool.

By the way, if you want to save some pride, it is likely that
the code that found out you were using -1 for true is flawed.
-1 is a perfectly good true value (in both C an C++) it just
does not compare == to true. Good code should not test
booleans for equality simply because, historically, anything
not zero is true.

I don't know about C, but in C++, a bool can only take on two
legal values, true and false. The implementation can represent
them any way it wants (as long as the convert to 1 and 0), and
anything you do which puts some values other than what the
implementation uses into the variable results in undefined
behavior.

In C++, of course, this isn't a problem: std::fill is typesafe,
and normally should be faster than memset as well.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Greg Comeau]

In article <c2**********************************@34g2000hsh.g ooglegroups.com>,
Simon L <si*******@hotmail.comwrote:

>BOOL bMyarray[1000];
memset(bMyArray , 0xFF, sizeof(BOOL) * 1000);

clean & quick until someone else's code found I was returning -1 to
mean true

Because my BOOL is 4 bytes long, TRUE in memory works out as 01 00 00
00 which is a right pain.

Doing it in a for loop is 10 x slower btw.

Bit of a numpty question this, is there another way?

First, Standard C++ has a bool type (C99 does too and they also both
support bitfields). That said, I'm not clear on exactly what the
problem being raised is or what the exact question is, however,
I suspect it may lie in your definition of BOOL and TRUE versus
somebody else's. IOWs, there seems to be a misunderstanding
and "your group" needs to come up with agreement as to what BOOL is
and what is should look like and what it's semantics are AND AREN'T,
especially in the presence of something like memset.
--
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?

[Greg Comeau]

In article <d3**********************************@a1g2000hsb.g ooglegroups.com>,
Simon L <si*******@hotmail.comwrote:

>Why not use bool?

I'm working in C (oops, wrong group..)

Well, this is a C++ group, in any even C99 supports a bool type.
--
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?

[Gennaro Prota]

Pascal J. Bourguignon wrote:

Ah, that's true, I forgot std::vector<boolwas special-cased.

And special-fated :-) Difficult to guess what will happen to it.

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

[Gennaro Prota]

Jerry Coffin wrote:

While your advice is certainly reasonable, I'd note that yet _another_
bit-vector implementation is about the last thing C++ needs. The
standard requires that std::vector<boolbe specialized to store bools
as a single bit apiece.

Caution. The standard does *not* require such a representation. It
just allows it.

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

[Jerry Coffin]

In article <g6**********@aioe.org>, gennaro/pr***@yahoo.com says...

Jerry Coffin wrote:

While your advice is certainly reasonable, I'd note that yet _another_
bit-vector implementation is about the last thing C++ needs. The
standard requires that std::vector<boolbe specialized to store bools
as a single bit apiece.

Caution. The standard does *not* require such a representation. It
just allows it.

According to section 23.2.5, "To optimize space allocation, a
specialization of vector for bool elements is provided". It's
undoubtedly true that an implementation _could_ be written that would
use multiple bits of storage for each bool, but if such a thing exists,
I've never heard of it.

At least IMO, in comp.std.c++, your comment would be absolutely correct,
but in comp.lang.c++, it's basically wrong.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <g6**********@aioe.org>, gennaro/pr***@yahoo.com says...

[ ... ]

At least IMO, in comp.std.c++, your comment would be absolutely correct,
but in comp.lang.c++, it's basically wrong.

Well, it's either correct or not. It doesn't depend on what newsgroup
you are in :-)

Not really. comp.std.c++ is about what the standard requires, and from
that viewpoint you're right.

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.

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

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ben Bacarisse]

James Kanze <ja*********@gmail.comwrites:

On Jul 31, 2:19 pm, Ben Bacarisse <[e-mail]:

>Simon L <[e-mail]:

>Why not use bool?
I'm working in C (oops, wrong group..)

>C also has bool.

>By the way, if you want to save some pride, it is likely that
the code that found out you were using -1 for true is flawed.
-1 is a perfectly good true value (in both C an C++) it just
does not compare == to true. Good code should not test
booleans for equality simply because, historically, anything
not zero is true.

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 "historically" and "booleans" (rather
than bools). It is safe (but odd) in C99 to test a bool == true.

I was addressing the OP's use of -1 in a BOOL (some MS type, most
likely) which is defensible on the grounds that without a proper bool
type, testing for equality is bad style. This was not clear, since I
started with "C also has bool". I should maybe have continued
"However, without it...".

<snip>

In C++, of course, this isn't a problem: std::fill is typesafe,
and normally should be faster than memset as well.

I note that the OP really wants C, and if they post in comp.lang.c
I am sure they'll get the rather less neat C idiom!

--
Ben.

[James Kanze]

On Aug 1, 2:24 am, Ben Bacarisse <[e-mail]:

James Kanze <[e-mail]:

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 "historically" 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 1, 1:45 am, Jerry Coffin <[e-mail]:

In article <g6thq7$[e-mail]>, gennaro/[e-mail] 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pascal J. Bourguignon]

James Kanze <ja*********@gmail.comwrites:

On Aug 1, 2:24 am, Ben Bacarisse <[e-mail]:

>James Kanze <[e-mail]:

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

On 2008-08-01 08:35:59 -0400, pj*@informatimago.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]

In article <7c************@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pj*@informatimago.comwrote:

>James Kanze <ja*********@gmail.comwrites:

>On Aug 1, 2:24 am, Ben Bacarisse <[e-mail]:

>>James Kanze <[e-mail]:
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 "historically" 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]

James Kanze <ja*********@gmail.comwrites:

On Aug 1, 2:24 am, Ben Bacarisse <[e-mail]:

>James Kanze <[e-mail]:

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 "historically" 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)*CHAR_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]

On 2008-08-01 11:21:59 -0400, co****@panix.com (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]

On Aug 1, 5:21 pm, [e-mail] (Greg Comeau) wrote:

In article <[e-mail]>,
Pascal J. Bourguignon <[e-mail]:

[...]

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 1, 5:36 pm, Ben Bacarisse <[e-mail]:

James Kanze <[e-mail]:

On Aug 1, 2:24 am, Ben Bacarisse <[e-mail]:

James Kanze <[e-mail]:
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 "historically" 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)*CHAR_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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gennaro Prota]

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

"Greg Comeau" <co****@panix.comwrote in message
news:g6**********@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]

On 2008-08-01 17:33:44 -0400, "kwikius" <an**@servocomm.freeserve.co.uksaid:

>
"Greg Comeau" <co****@panix.comwrote in message
news:g6**********@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]

In article
<a3**********************************@j22g2000hsf. googlegroups.com>,
James Kanze <ja*********@gmail.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]

In article <7c************@pbourguignon.anevia.com>,
pj*@informatimago.com (Pascal J. Bourguignon) wrote:

James Kanze <ja*********@gmail.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_cast).

[kwikius]

"Pete Becker" <pe**@versatilecoding.comwrote in message
news:2008080118071816807-pete@versatilecodingcom...

On 2008-08-01 17:33:44 -0400, "kwikius" <an**@servocomm.freeserve.co.uk>
said:

>>
"Greg Comeau" <co****@panix.comwrote in message
news:g6**********@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.

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]

On 2008-08-02 06:15:32 -0400, "kwikius" <an**@servocomm.freeserve.co.uksaid:

>
"Pete Becker" <pe**@versatilecoding.comwrote in message
news:2008080118071816807-pete@versatilecodingcom...

>On 2008-08-01 17:33:44 -0400, "kwikius" <an**@servocomm.freeserve.co.uk>
said:

>>>
"Greg Comeau" <co****@panix.comwrote in message
news:g6**********@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.

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]

"Pete Becker" <pe**@versatilecoding.comwrote in message
news:2008080207260416807-pete@versatilecodingcom...

On 2008-08-02 06:15:32 -0400, "kwikius" <an**@servocomm.freeserve.co.uk>
said:

>>
"Pete Becker" <pe**@versatilecoding.comwrote in message
news:2008080118071816807-pete@versatilecodingcom...

>>On 2008-08-01 17:33:44 -0400, "kwikius" <an**@servocomm.freeserve.co.uk>
said:
"Greg Comeau" <co****@panix.comwrote in message
news:g6**********@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.

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]

On Aug 2, 11:54 am, blargg <[e-mail]:

In article
<[e-mail]>,
James Kanze <[e-mail]:

...
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]