www.digitalmars.com         C & C++   DMDScript  

D - newbees. Boolean type

reply "Florian Lavrard" <flavrard free.fr.nospam.> writes:
Hi,

Could you help me please.

1)
I can't find the good syntax to use boolean type.
Does it exist ? It don't appear in the d type list .
2)
i've a little problem with printf()
 printf("%d",var);
- var could be an int or a char (or other)
 It don't word gook with char if i use "%d", or don't work good with int if
i use "%c".
Have you got a tips please ?
3)
 is there a FAQ or archive for this newwsgroup ?

Thanks,

Florian
ps: sorry for my poor english expression.
May 08 2003
next sibling parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with the
constants 'true' and 'false'.

 -- C. Sauls
May 08 2003
next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <b9f97v$28q9$1 digitaldaemon.com>, C. Sauls says...

There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with the
constants 'true' and 'false'.


Which many people in this forum think is a mistake.  Boolean is a type, a very
common type used by most programmers, a bit is a unit of storage. It would be
nice if Walter provided a standard Boolean type as well as bit type (just
consider it syntactic sugar).

Otherwise everyone will create some typedef variant for Boolean just like what
was done in the C language up until C99 added 'bool'. Of course, thousands upon
thousands of lines of C code with BOOL, BOOLEAN, boolean, etc already exist
which makes it harder for people to maintain and understand.
May 09 2003
next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Mark T wrote:

 
 In article <b9f97v$28q9$1 digitaldaemon.com>, C. Sauls says...

There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with the
constants 'true' and 'false'.


 
 Which many people in this forum think is a mistake.  Boolean is a type, a very
 common type used by most programmers, a bit is a unit of storage. It would be
 nice if Walter provided a standard Boolean type as well as bit type (just
 consider it syntactic sugar).
 
 Otherwise everyone will create some typedef variant for Boolean just like what
 was done in the C language up until C99 added 'bool'. Of course, thousands upon
 thousands of lines of C code with BOOL, BOOLEAN, boolean, etc already exist
 which makes it harder for people to maintain and understand.


alias bit boolean;

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 09 2003
parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <3EBBE410.EB530CA2 chello.at>, Helmut Leitner says...


alias bit boolean;


There are two problems with the bit type that makes it inadequate
as a boolean type. A bit can not be an inout or out parameter of 
a function and you can't slice a bit array arbitrarily.

While I understand from an implementation point of view why bits
have this restriction I belive that a type that is to be used as 
a boolean should not have the restrictions that bit currently
has.  


For this reason I belive that either

1. The bit type needs to have it fuctionality expanded to include
the capablities above.  ( With all the implementation baggage this
brings.)

--or--

2. There should be a separate boolean type.
May 09 2003
next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Patrick Down wrote:

 
 In article <3EBBE410.EB530CA2 chello.at>, Helmut Leitner says...
 

alias bit boolean;


 
 There are two problems with the bit type that makes it inadequate
 as a boolean type. A bit can not be an inout or out parameter of
 a function and you can't slice a bit array arbitrarily.
 
 While I understand from an implementation point of view why bits
 have this restriction I belive that a type that is to be used as
 a boolean should not have the restrictions that bit currently
 has.
 
 For this reason I belive that either
 
 1. The bit type needs to have it fuctionality expanded to include
 the capablities above.  ( With all the implementation baggage this
 brings.)
 
 --or--
 
 2. There should be a separate boolean type.


First of all, one could just as well chose
  alias int boolean;
or 
  type char boolean;
although it seems not very logical.

Apart from that I don't see much implementation problems with bit 
references and slices in itself. Bit addressing could just be
address<<3+index. 

I suppose you mean the relationship between these and gc?
As the gc must be reworked anyway these problems are bound 
together and maybe have to be solved together.

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 10 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBD4A81.D4F35E8E chello.at...

 Patrick Down wrote:

 In article <3EBBE410.EB530CA2 chello.at>, Helmut Leitner says...


alias bit boolean;


 There are two problems with the bit type that makes it inadequate
 as a boolean type. A bit can not be an inout or out parameter of
 a function and you can't slice a bit array arbitrarily.

 While I understand from an implementation point of view why bits
 have this restriction I belive that a type that is to be used as
 a boolean should not have the restrictions that bit currently
 has.

 For this reason I belive that either

 1. The bit type needs to have it fuctionality expanded to include
 the capablities above.  ( With all the implementation baggage this
 brings.)

 --or--

 2. There should be a separate boolean type.


 First of all, one could just as well chose
   alias int boolean;
 or
   type char boolean;
 although it seems not very logical.

 Apart from that I don't see much implementation problems with bit
 references and slices in itself. Bit addressing could just be
 address<<3+index.

 I suppose you mean the relationship between these and gc?
 As the gc must be reworked anyway these problems are bound
 together and maybe have to be solved together.

 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com
May 21 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 First of all, one could just as well chose
   alias int boolean;
 or
   type char boolean;
 although it seems not very logical.


It should be a typedef, not an alias. Being able to mix and match booleans
and other integrals without compiler complaints is not good
May 21 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 2. There should be a separate boolean type.


Heartily agree
May 21 2003
prev sibling next sibling parent reply Bill Cox <bill viasic.com> writes:
I'll second the request for the bool keyword.  Too many newbies trip on 
it.  It goes against that whole goal of feeling like you've just left 
the gravel road and are on a smooth highway.  'Bit' is definately a bump 
in the road, although I like having the alias.

I've had trouble with that 'bool' typedef forever.  Before C++ added 
bool to the language, Microsoft used every variant you listed, making a 
local version difficult.  We wound up using utBool, UTTRUE, and UTFALSE 
(the ut was the utility module prefix).  Yuk.

Bill

Mark T wrote:

 In article <b9f97v$28q9$1 digitaldaemon.com>, C. Sauls says...
 

There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with the
constants 'true' and 'false'.


 
 
 Which many people in this forum think is a mistake.  Boolean is a type, a very
 common type used by most programmers, a bit is a unit of storage. It would be
 nice if Walter provided a standard Boolean type as well as bit type (just
 consider it syntactic sugar).
 
 Otherwise everyone will create some typedef variant for Boolean just like what
 was done in the C language up until C99 added 'bool'. Of course, thousands upon
 thousands of lines of C code with BOOL, BOOLEAN, boolean, etc already exist
 which makes it harder for people to maintain and understand.
May 09 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
Agreed.  Both C and Python finally added a bool type after many long years.
What they did as a corrective measure, D can design properly.

The particulars of internal storage don't matter (and might even vary), just the
semantics of the boolean type.

Mark
http://www.python.org/peps/pep-0285.html


Bill Cox says...

I'll second the request for the bool keyword.
May 09 2003
parent reply Jonathan Andrew <Jonathan_member pathlink.com> writes:
I like the bool keyword too, for the same reasons.
The only reason I hesitate is that there are some neat tricks you can do
with math expressions when comparisons return a numeric value. Still, as long
as the bool type could be cast to a bit or int, this sort of stuff could still
be done.

-Jon

In article <b9gt2c$spr$1 digitaldaemon.com>, Mark Evans says...

Agreed.  Both C and Python finally added a bool type after many long years.
What they did as a corrective measure, D can design properly.

The particulars of internal storage don't matter (and might even vary), just the
semantics of the boolean type.

Mark
http://www.python.org/peps/pep-0285.html


Bill Cox says...

I'll second the request for the bool keyword.
May 09 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
Then define your own semantics in code.  Don't ask the language to support
ambiguous semantics.  That is one of the big problems with C.  If you want an
integer with two meanings, define it yourself, and track them by hand.

A type cast re-types a section of memory without changing it.  That is a
low-level, dangerous, and implementation-dependent operation.  Simple
conversions to and from int make more sense, because the semantics can be
controlled.

Even if a D conversion looks like a C typecast -- which it should not IMO --
then it should be defined clearly as a conversion, not a typecast.

Mark


Jonathan Andrew says...

I like the bool keyword too, for the same reasons.
The only reason I hesitate is that there are some neat tricks you can do
with math expressions when comparisons return a numeric value. Still, as long
as the bool type could be cast to a bit or int, this sort of stuff could still
be done.

-Jon
May 09 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Mark Evans wrote:

 A type cast re-types a section of memory without changing it...


Why actually? A "(newtype)expr" should try to convert the value in a 
legal manner. For the cases where there is no conversion which makes 
sense, implementations usually define a "pretend as if" type change, 
although this is not requiered. For example, LCC didn't allow to cast a 
pointer into an integer till recently - and i believe by a reason.

Just think of it: when you write "float f = (float)integervariable;", 
you don't get a useless bit pattern in "f", but instead a value of 
integer variable converted correctly into a float. And if the bit length 
of types were different, a corresponding adjustment would take place.

-i.
May 09 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
Ilya Minkov says...

 A type cast re-types a section of memory without changing it...


Why actually?


By definition. A conversion is not a type cast.  Confusing the two is dangerous
for language semantics and type-casting is already dangerous enough as things
stand.  That is why I advocate distinct syntax for each operation.

Conversely there are proper places for typecasting, and if the language does
conversions where I need typecasts, it is not helping me.

-Mark
May 09 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
By C standard - and Walter would confirm - a "C cast" means a 
conversion, not changing a type assoziated with an expression. This is 
also compliant with terminology in Pascal and diverse other languages. 
The "other meaning" which has been added to C - type pretending - really 
makes a mess out of it.

And by the way, there *is* a legal way to accomplish a type pretending - 
which you call typecast - in C: you have to cast to void first, then to 
the desired type. This is clear since void doesn't define a storage. It 
is also visually distinct, even if not very legible. The latter was 
probably the reason why the implementors have taken a shortcut.

Please note that D doesn't actually introduce the concept of type 
pretending as a separate - but instead follows the same justifiable 
scheme more strictly. This should be enough, as long as implementors are 
smart enough not to repeat the same mistake as in C.

My definition is by the standard. And where does yours come from?
And if C bends and misuses some terms, this doesn't mean you have to 
call everything false names.

-i.

Mark Evans wrote:

 Ilya Minkov says...
 

A type cast re-types a section of memory without changing it...


Why actually?


 
 
 By definition. A conversion is not a type cast.  Confusing the two is dangerous
 for language semantics and type-casting is already dangerous enough as things
 stand.  That is why I advocate distinct syntax for each operation.
 
 Conversely there are proper places for typecasting, and if the language does
 conversions where I need typecasts, it is not helping me.
 
 -Mark
May 09 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
You may be right but C has confused semantics in the first place.  This item
might be just one more example.  Whatever the names, these are two distinct
operations, which is the main point.  A language should not use the same syntax
to implement both.
Mark
May 09 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Mark Evans wrote:

 You may be right but C has confused semantics in the first place. 
 This item might be just one more example.  Whatever the names, these
 are two distinct operations, which is the main point.  A language 
 should not use the same syntax to implement both. Mark


WhoopS! I was somewhat wrong. I'm just reading the standard - and though
it *does* define a cast as a conversion - it does not define a way to
make "reinterpret_cast". And casting everything to void *always* means
discarding the value to hell - the result may not be used in any
expression.

Reading further. The standard defines a number of completely nonsense
"legal" casts, the result of which is implementation-defined, but the
*usage* is *undefined*. What a mess! "Standard-compliant behaviour is
considered harmful" :>

I guess C++ got it more or less right - separating the "real" cast,
which is dynamic_cast, a completely safe conversion utility, which has
also made its way to D; the static_cast, which is somewhat unsafe and
only relevant to performance freaks; and finally the reinterpret_cast,
just for the case someone has to fiddle with bits of a pointer or somesuch.

IIRC Walter argumented that D doesn't need reinterpret_cast, since it
can be simulated easily enough if really desired. Create a union,
containing both types, put one, manipulate the other. Seems to make
enough sense to me - one would also not forget to cast back. Just other
programmers also have to be convinced - else it'll fail, and future
implementors may repeat the same mistake!

-i.
May 09 2003
parent reply C <cc.news gateway.mirlex.com> writes:
Ilya Minkov wrote:


 IIRC Walter argumented that D doesn't need reinterpret_cast, since it
 can be simulated easily enough if really desired. Create a union,
 containing both types, put one, manipulate the other. Seems to make
 enough sense to me - one would also not forget to cast back. Just other
 programmers also have to be convinced - else it'll fail, and future
 implementors may repeat the same mistake!


Yes, I remember asking about / discussing this some months ago
(early last year?) in a thread dedicated to this topic - have to check
the archives.

I believe the conclusion reached was, as you stated, that
'cast(Type)variable' is a conversion cast, and to reinterpret the
type you do 'cast(newType*)&oldVaribale'.

exampli grata ...

int i = 0x3f800000;
printf( "'%g', '%g'\n", cast(float)i, char(float*)&i );

should print "'0.1016e+9', '1.0'"

C 2003/5/10

Post scriptum :

Mathematics where done in my head, so they will probably be wrong
:-)
May 09 2003
parent reply KM <KM_member pathlink.com> writes:
Yes, I remember asking about / discussing this some months ago
(early last year?) in a thread dedicated to this topic - have to check
the archives.

I believe the conclusion reached was, as you stated, that
'cast(Type)variable' is a conversion cast, and to reinterpret the
type you do 'cast(newType*)&oldVaribale'.


Ugh!  Do it like Nice where type(var) gives the conversion and then let (type)
var give the reinterpret-cast.  See conversion it is really a function so why
not make it look like one.  Then you are not confusing as Evans says.
May 10 2003
parent C <cc.news gateway.mirlex.com> writes:
KM wrote:

 Ugh!  Do it like Nice where type(var) gives the conversion and then let (type)
 var give the reinterpret-cast.  See conversion it is really a function so why
 not make it look like one.  Then you are not confusing as Evans says.


Err, that was Walters recommendation - I, in the afore mentioned
post, stated it was 'ugly' but workable.

The evidence; for those who want to check it out ...

http://www.digitalmars.com/drn-bin/wwwnews?D/7420

Besides the '(type)var' C style cast is being deprecated:
there have been several requests for its removal.

With inlineing this 'do it yourself' reinterpret cast
could be placed in a function and still be efficient.

C 2003/5/11
May 11 2003
prev sibling parent Derek Parnell <derek.parnell no.spam> writes:
On Fri, 9 May 2003 13:38:39 +0000 (UTC), Mark T <Mark_member pathlink.com> 
wrote:


 In article <b9f97v$28q9$1 digitaldaemon.com>, C. Sauls says...

 There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with 
 the
 constants 'true' and 'false'.


 Which many people in this forum think is a mistake.  Boolean is a type, a 
 very
 common type used by most programmers, a bit is a unit of storage. It 
 would be
 nice if Walter provided a standard Boolean type as well as bit type (just
 consider it syntactic sugar).

 Otherwise everyone will create some typedef variant for Boolean just like 
 what
 was done in the C language up until C99 added 'bool'. Of course, 
 thousands upon
 thousands of lines of C code with BOOL, BOOLEAN, boolean, etc already 
 exist
 which makes it harder for people to maintain and understand.


Agreed.

A boolean value represents a position of truth - something is either true 
or false. A boolean value is one of two possible states.

A bit value can obviously used to emulate a boolean value because a bit 
value also has only two states. However, a bit value is a numeric value and 
can thus be used with arithmetic expressions. There are a lot of coders 
(myself included) that have used this artifact of bit (and aliased ints) to 
effect some coding trickery/wizardy. However, now that I've grown old and 
experienced, I learned that this sort of coding does NOT pay in the long 
term. Because of the cost of maintaining code, it is always better to be 
explicit and obvious about your intentions, rather than resorting to 
(smug?) tricks-of-the-trade.

By this I mean that if one 'needs' to use a boolean value in some 
arithmetic, then be explicit about it.

  bool x;
  int k;
  int z;
  x = someFunc( ... );
  if (x == TRUE)
  {
    k = 1;
  }
  else
  {
    k = 0;
  }

  z = A*k + B*(1-k);

There is no guess work about this now on the part of the reader. Note that 
some languages assume TRUE is -1 and others assume it is 1! Confusion 
reigns.

(Excuse the trivial nature of the example. In real life, one would do this 
very much more efficiently.)


-- 
Derek
May 11 2003
prev sibling parent reply "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> writes:
There is an argument floating around somewhere (sorry, I can't find the
exact reference I'm thinking of) that says boolean types are overused and
often especially poor choices for function parameters.

The problem is (at least) twofold: first, it's usually not obvious from the
function name itself how to set the flag.  Consider the pseudo-code
   bool equal(string s1, string s2, bool ignore_case)
you have to look at the argument name "ignore_case" to know exactly how to
use equal().  Given that, wouldn't it be better to put this information in
the function name itself such as
   bool equalI(string s1, string s2);
   bool equal(string s1, string s2);
now it's clear that equalI() does a case-insensitive comparision.

The other issue is that there really aren't that many parameters that are
really boolean.  Keeping with this string comparison example, should various
UNICODE encodings be considered?  How about UNICODE combining characters?
Should punctuation be ignored (when comparing names or addresses)?  The
point is that often some type of enumeration should be used instead of a
boolean argument.  This makes the purpose of the parameter much clearer,
while at the same time making it easier to expand as the need arises.

   Dan

"C. Sauls" <ibisbasenji yahoo.com> wrote in message
news:b9f97v$28q9$1 digitaldaemon.com...

 There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with the
 constants 'true' and 'false'.

  -- C. Sauls
May 09 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I agree with your thesis in the main. Often it is better to use an
enumeration to control function behaviour (though we then get into whether
to combine enumerators as flags in an integer parameter - this is a good
thing, however, as it documents whether enumerators can/should be combined
or not.)

However, the appropriateness of a boolean keyword does not rest only on
whether it is useful as function parameters (which I would suggest it would
be in any case), since:

class SomeContainer
{

    bool IsEmpty();
};

It either is empty or it's not, and we want that truth expressed as a
boolean quantity.

boolean is also very useful for overloading methods, e.g. in serialisation.
It's pretty ugly (never mind confusing to user's of your code) when
(de-)serialising a boolean value to have to (un-)pack it as a
bit/char/short/etc.



"J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> wrote in message
news:b9grsl$ri8$1 digitaldaemon.com...

 There is an argument floating around somewhere (sorry, I can't find the
 exact reference I'm thinking of) that says boolean types are overused and
 often especially poor choices for function parameters.

 The problem is (at least) twofold: first, it's usually not obvious from


the

 function name itself how to set the flag.  Consider the pseudo-code
    bool equal(string s1, string s2, bool ignore_case)
 you have to look at the argument name "ignore_case" to know exactly how to
 use equal().  Given that, wouldn't it be better to put this information in
 the function name itself such as
    bool equalI(string s1, string s2);
    bool equal(string s1, string s2);
 now it's clear that equalI() does a case-insensitive comparision.

 The other issue is that there really aren't that many parameters that are
 really boolean.  Keeping with this string comparison example, should


various

 UNICODE encodings be considered?  How about UNICODE combining characters?
 Should punctuation be ignored (when comparing names or addresses)?  The
 point is that often some type of enumeration should be used instead of a
 boolean argument.  This makes the purpose of the parameter much clearer,
 while at the same time making it easier to expand as the need arises.

    Dan

 "C. Sauls" <ibisbasenji yahoo.com> wrote in message
 news:b9f97v$28q9$1 digitaldaemon.com...

 There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with




the

 constants 'true' and 'false'.

  -- C. Sauls
May 21 2003
parent reply "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> writes:
It's not my thesis; but I do agree with the basic ideas and unfortunately I
can't remember the reference.

The appropriateness of a keyword is related to how often "bool" would be
used.  Sure, there are some uglinesses to deal with if there isn't a
keyword, but if you don't deal with bools that much (as perhaps you
shouldn't), then maybe it's not that big of a deal to have to put up with a
few annoyances on occasion.

Your IsEmpty() example matches what I did for equal() and equalI(); a
function return value (as opposed to arguments) can be a more appropriate
use of booleans.

   Dan

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bah32r$dqb$4 digitaldaemon.com...

 I agree with your thesis in the main. Often it is better to use an
 enumeration to control function behaviour (though we then get into whether
 to combine enumerators as flags in an integer parameter - this is a good
 thing, however, as it documents whether enumerators can/should be combined
 or not.)

 However, the appropriateness of a boolean keyword does not rest only on
 whether it is useful as function parameters (which I would suggest it


would

 be in any case), since:

 class SomeContainer
 {

     bool IsEmpty();
 };

 It either is empty or it's not, and we want that truth expressed as a
 boolean quantity.

 boolean is also very useful for overloading methods, e.g. in


serialisation.

 It's pretty ugly (never mind confusing to user's of your code) when
 (de-)serialising a boolean value to have to (un-)pack it as a
 bit/char/short/etc.



 "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> wrote in message
 news:b9grsl$ri8$1 digitaldaemon.com...

 There is an argument floating around somewhere (sorry, I can't find the
 exact reference I'm thinking of) that says boolean types are overused




and

 often especially poor choices for function parameters.

 The problem is (at least) twofold: first, it's usually not obvious from


 the

 function name itself how to set the flag.  Consider the pseudo-code
    bool equal(string s1, string s2, bool ignore_case)
 you have to look at the argument name "ignore_case" to know exactly how




to

 use equal().  Given that, wouldn't it be better to put this information




in

 the function name itself such as
    bool equalI(string s1, string s2);
    bool equal(string s1, string s2);
 now it's clear that equalI() does a case-insensitive comparision.

 The other issue is that there really aren't that many parameters that




are

 really boolean.  Keeping with this string comparison example, should


 various

 UNICODE encodings be considered?  How about UNICODE combining




characters?

 Should punctuation be ignored (when comparing names or addresses)?  The
 point is that often some type of enumeration should be used instead of a
 boolean argument.  This makes the purpose of the parameter much clearer,
 while at the same time making it easier to expand as the need arises.

    Dan

 "C. Sauls" <ibisbasenji yahoo.com> wrote in message
 news:b9f97v$28q9$1 digitaldaemon.com...

 There is no 'bool', 'BOOL', or 'boolean' for D, instead use 'bit' with




 the

 constants 'true' and 'false'.

  -- C. Sauls
May 22 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi.

It's Friday, and I've just had my third beer, which makes me nastier 
than usual.

In that spirit, re-reading the 'Boolean type' posts, I find I'm 
convinced that at least half of us will create little 'bool.d' files 
containing the single line:

alias bit bool;

If we can all agree that this is the standard definition, and that it 
lives in "bool.d", we can all write much more compatible code. 
Otherwise, I'll have to have something doppey like "mybool.d" containing 
the equally doppey "alias bit mybool;".

Anyone with me?  Shall we make it a defacto standard?

Bill
Jun 27 2003
next sibling parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <3EFCA3B6.5010802 viasic.com>, Bill Cox says...

Hi.

alias bit bool;


Except mine would be

alias byte bool;
Jun 27 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Same here

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bdi8dp$sdq$1 digitaldaemon.com...

 In article <3EFCA3B6.5010802 viasic.com>, Bill Cox says...

Hi.

alias bit bool;


 Except mine would be

 alias byte bool;
Jul 08 2003
prev sibling next sibling parent reply Jonathan Andrew <jonNO SPAMece.arizona.edu> writes:
Sigh. I suppose we might as well take lemons and make lemonade out of the no
boolean situation. Should that be an alias or a typedef though?

-Jon

In article <3EFCA3B6.5010802 viasic.com>, Bill Cox says...

Hi.

It's Friday, and I've just had my third beer, which makes me nastier 
than usual.

In that spirit, re-reading the 'Boolean type' posts, I find I'm 
convinced that at least half of us will create little 'bool.d' files 
containing the single line:

alias bit bool;

If we can all agree that this is the standard definition, and that it 
lives in "bool.d", we can all write much more compatible code. 
Otherwise, I'll have to have something doppey like "mybool.d" containing 
the equally doppey "alias bit mybool;".

Anyone with me?  Shall we make it a defacto standard?

Bill
Jun 27 2003
next sibling parent reply Bill Cox <bill viasic.com> writes:
Jonathan Andrew wrote:

 Sigh. I suppose we might as well take lemons and make lemonade out of the no
 boolean situation. Should that be an alias or a typedef though?
 
 -Jon
 
 In article <3EFCA3B6.5010802 viasic.com>, Bill Cox says...
 

Hi.

It's Friday, and I've just had my third beer, which makes me nastier 
than usual.

In that spirit, re-reading the 'Boolean type' posts, I find I'm 
convinced that at least half of us will create little 'bool.d' files 
containing the single line:

alias bit bool;

If we can all agree that this is the standard definition, and that it 
lives in "bool.d", we can all write much more compatible code. 
Otherwise, I'll have to have something doppey like "mybool.d" containing 
the equally doppey "alias bit mybool;".

Anyone with me?  Shall we make it a defacto standard?

Bill


 
 
 


Argh!  I don't care!  Byte is fine.  Typedef is fine.  I just want a 
'bool' type so I can get mad when I see programmers adding bools and 
ints.  When I say bool, I mean bool.

Bill

P.S.  I'm into a bit of rum now, so please ignore me.
Jun 27 2003
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Bill Cox wrote:

 Jonathan Andrew wrote:
 

 Sigh. I suppose we might as well take lemons and make lemonade out of 
 the no
 boolean situation. Should that be an alias or a typedef though?

 -Jon

 In article <3EFCA3B6.5010802 viasic.com>, Bill Cox says...


 Hi.

 It's Friday, and I've just had my third beer, which makes me nastier 
 than usual.

 In that spirit, re-reading the 'Boolean type' posts, I find I'm 
 convinced that at least half of us will create little 'bool.d' files 
 containing the single line:

 alias bit bool;

 If we can all agree that this is the standard definition, and that it 
 lives in "bool.d", we can all write much more compatible code. 
 Otherwise, I'll have to have something doppey like "mybool.d" 
 containing the equally doppey "alias bit mybool;".

 Anyone with me?  Shall we make it a defacto standard?

 Bill




 
 Argh!  I don't care!  Byte is fine.  Typedef is fine.  I just want a 
 'bool' type so I can get mad when I see programmers adding bools and 
 ints.  When I say bool, I mean bool.
 
 Bill
 
 P.S.  I'm into a bit of rum now, so please ignore me.
 


It has to be an alias, or we won't be able to do assignments with 'true' 
and 'false' without casts.
Jun 27 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
You can specify the underlying type of an enum in D.  But I forget exactly
how.  Does anyone remember?

Sean

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bdicah$10so$1 digitaldaemon.com...

 It has to be an alias, or we won't be able to do assignments with 'true'
 and 'false' without casts.
Jun 29 2003
parent reply Farmer <itsFarmer. freenet.de> writes:
Looking for this?

enum bool : bit
{
    	TRUE=false,
    	FALSE=true
}



Farmer.

"Sean L. Palmer" <palmer.sean verizon.net> wrote in 
news:bdna96$pag$1 digitaldaemon.com:


 You can specify the underlying type of an enum in D.  But I forget exactly
 how.  Does anyone remember?
 
 Sean
 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bdicah$10so$1 digitaldaemon.com...

 It has to be an alias, or we won't be able to do assignments with 'true'
 and 'false' without casts.
Jun 30 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
That looks like it.  Thanks!

Sean

"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns93AAEF916A3AAitsFarmer 63.105.9.61...

 Looking for this?

 enum bool : bit
 {
     TRUE=false,
     FALSE=true
 }



 Farmer.

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in
 news:bdna96$pag$1 digitaldaemon.com:


 You can specify the underlying type of an enum in D.  But I forget




exactly

 how.  Does anyone remember?

 Sean

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bdicah$10so$1 digitaldaemon.com...

 It has to be an alias, or we won't be able to do assignments with






'true'

 and 'false' without casts.
Jun 30 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
typedef

"Jonathan Andrew" <jonNO SPAMece.arizona.edu> wrote in message
news:bdi93p$td6$1 digitaldaemon.com...

 Sigh. I suppose we might as well take lemons and make lemonade out of the


no

 boolean situation. Should that be an alias or a typedef though?

 -Jon

 In article <3EFCA3B6.5010802 viasic.com>, Bill Cox says...

Hi.

It's Friday, and I've just had my third beer, which makes me nastier
than usual.

In that spirit, re-reading the 'Boolean type' posts, I find I'm
convinced that at least half of us will create little 'bool.d' files
containing the single line:

alias bit bool;

If we can all agree that this is the standard definition, and that it
lives in "bool.d", we can all write much more compatible code.
Otherwise, I'll have to have something doppey like "mybool.d" containing
the equally doppey "alias bit mybool;".

Anyone with me?  Shall we make it a defacto standard?

Bill
Jul 08 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Matthew Wilson wrote:

 typedef


no, alias. or just get used to thinking in bits, which i prefer. typedef 
would make lots of trouble.

-i.
Jul 09 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Sorry, your explanation makes no sense. Can you expound?

btw, am now wondering whether int is better than byte. It's a trade off of
efficiencies, whether storage (as in arrays/containers of bool) vs function
returns and the painful/wasteful testing against 0 to convert to true/false.

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bei0i5$6ur$1 digitaldaemon.com...

 Matthew Wilson wrote:

 typedef


 no, alias. or just get used to thinking in bits, which i prefer. typedef
 would make lots of trouble.

 -i.
Jul 09 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
bool is one of those types (like int) that should be defined by its
semantics and not by its implementation details.  You won't get any
guarantees about how big a bool is.  It could be a bit, a byte, or an int.
It could in fact not live in memory but in a processor flags register.  But
it seems important to be able to have pointers to them, send them as inout
parameters, etc.  To do that, the compiler may need to temporarily move the
value somewhere that can be referenced easier (a byte in memory) and then
move it back when the reference is no longer necessary.  Since you can pass
addresses around willy-nilly in D, this can get a programmer in big trouble,
and means the compiler is severely constrained in what it is allowed to do
without breaking language semantics.

bit is more like int32; it is saying exactly the storage requirement for the
value.  A cheap D compiler could use a byte to hold a bit if it wants to,
though.  It also seems pretty important to be able to have pointers to bits.
A bit pointer however is unlike a normal pointer in that it must specify
which bit in the containing byte it is actually pointing to.  This would
need special compiler support, and Walter doesn't seem interested in making
this effort at this time.  Has many more important things that need doing,
apparently.  ;)

One thing that could be done to alleviate the problem somewhat would be that
local, class, and global scope variables have *no* defined ordering or size,
and thus you can't determine the address of a variable merely by looking at
the class declaration and knowing a pointer to the class,  you'd have to use
offsetof(x).  With the language semantics so altered, it would be possible
to take the address of a local variable bit or bool, which would let the
compiler store it as a byte instead of a bit.  Taking the address of bits
stored in structs or arrays could wait until Walter makes fat bit pointers.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:beid7m$jh2$1 digitaldaemon.com...

 Sorry, your explanation makes no sense. Can you expound?

 btw, am now wondering whether int is better than byte. It's a trade off of
 efficiencies, whether storage (as in arrays/containers of bool) vs


function

 returns and the painful/wasteful testing against 0 to convert to


true/false.

 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:bei0i5$6ur$1 digitaldaemon.com...

 Matthew Wilson wrote:

 typedef


 no, alias. or just get used to thinking in bits, which i prefer. typedef
 would make lots of trouble.

 -i.
Jul 10 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
I'd wondered about this, at least as far as mutable between byte and
processor-sized-int, and I like it conceptually - though only for bool
type - but would bet a lot of cash that Walter will suggest it is too hard
for implementation to be worth it.

The offsetof() seems interesting, but then I wonder if we'll end up like the
feature-bloated .NET languages where there are compiler layouts and various
other attribute-based layout schemes. (Maybe we're there already ??)


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bek61g$29q2$1 digitaldaemon.com...

 bool is one of those types (like int) that should be defined by its
 semantics and not by its implementation details.  You won't get any
 guarantees about how big a bool is.  It could be a bit, a byte, or an int.
 It could in fact not live in memory but in a processor flags register.


But

 it seems important to be able to have pointers to them, send them as inout
 parameters, etc.  To do that, the compiler may need to temporarily move


the

 value somewhere that can be referenced easier (a byte in memory) and then
 move it back when the reference is no longer necessary.  Since you can


pass

 addresses around willy-nilly in D, this can get a programmer in big


trouble,

 and means the compiler is severely constrained in what it is allowed to do
 without breaking language semantics.

 bit is more like int32; it is saying exactly the storage requirement for


the

 value.  A cheap D compiler could use a byte to hold a bit if it wants to,
 though.  It also seems pretty important to be able to have pointers to


bits.

 A bit pointer however is unlike a normal pointer in that it must specify
 which bit in the containing byte it is actually pointing to.  This would
 need special compiler support, and Walter doesn't seem interested in


making

 this effort at this time.  Has many more important things that need doing,
 apparently.  ;)

 One thing that could be done to alleviate the problem somewhat would be


that

 local, class, and global scope variables have *no* defined ordering or


size,

 and thus you can't determine the address of a variable merely by looking


at

 the class declaration and knowing a pointer to the class,  you'd have to


use

 offsetof(x).  With the language semantics so altered, it would be possible
 to take the address of a local variable bit or bool, which would let the
 compiler store it as a byte instead of a bit.  Taking the address of bits
 stored in structs or arrays could wait until Walter makes fat bit


pointers.

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:beid7m$jh2$1 digitaldaemon.com...

 Sorry, your explanation makes no sense. Can you expound?

 btw, am now wondering whether int is better than byte. It's a trade off




of

 efficiencies, whether storage (as in arrays/containers of bool) vs


 function

 returns and the painful/wasteful testing against 0 to convert to


 true/false.

 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:bei0i5$6ur$1 digitaldaemon.com...

 Matthew Wilson wrote:

 typedef


 no, alias. or just get used to thinking in bits, which i prefer.






typedef

 would make lots of trouble.

 -i.
Jul 10 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
It needs to go into Phobos.

Sean

"Bill Cox" <bill viasic.com> wrote in message
news:3EFCA3B6.5010802 viasic.com...

 Hi.

 It's Friday, and I've just had my third beer, which makes me nastier
 than usual.

 In that spirit, re-reading the 'Boolean type' posts, I find I'm
 convinced that at least half of us will create little 'bool.d' files
 containing the single line:

 alias bit bool;

 If we can all agree that this is the standard definition, and that it
 lives in "bool.d", we can all write much more compatible code.
 Otherwise, I'll have to have something doppey like "mybool.d" containing
 the equally doppey "alias bit mybool;".

 Anyone with me?  Shall we make it a defacto standard?

 Bill
Jun 29 2003
prev sibling parent "Florian Lavrard" <flavrard free.fr.nospam.> writes:


 May 10 2003