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.

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

 -- C. Sauls

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.

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

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

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

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.

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.

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

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