www.digitalmars.com         C & C++   DMDScript  

D - ctype module -- int or bit?

reply Benji Smith <Benji_member pathlink.com> writes:
I noticed the cytpe module in phobos for the first time the other day. And I
don't know if I'm the only one, but the functions don't seem like their
implemented in the most useful way.

A few of the functions in the module are:

int isdigit(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS A DIGIT
int isupper(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS UPPER-CASE
int islower(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS LOWER-CASE

I can't fathom why I would want an int return value from these types of
functions. What am I going to do with an int? What I'd really like is a bit
return value (or a bool, if that suits your fancy).

So, for example, I'd like to write code like this:

if (isdigit(c)) { ... }

..or like this...

if (isdigit(c) == true) { ... }


..rather than code like this:

if (isdigit(c) != 0) { ... }

As it stands, I've written my own set of functions that mirror the purpose of
the functions in the ctype module. But my functions return bits.

Am I all alone in thinking this way? Should these functions return ints or bits?
As far as I'm concerned, any function whose name starts with "is" should return
a bit or a bool. Maybe there's some hidden gem of knowledge that I'm missing
here, but I don't think so. If you know why ints are better, let me know.
Jul 08 2003
next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
Benji Smith wrote:

 
 I noticed the cytpe module in phobos for the first time the other day. And I
 don't know if I'm the only one, but the functions don't seem like their
 implemented in the most useful way.
 
 A few of the functions in the module are:
 
 int isdigit(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS A DIGIT
 int isupper(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS UPPER-CASE
 int islower(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS LOWER-CASE
 
 I can't fathom why I would want an int return value from these types of
 functions. What am I going to do with an int? What I'd really like is a bit
 return value (or a bool, if that suits your fancy).
 
 So, for example, I'd like to write code like this:
 
 if (isdigit(c)) { ... }


It's perfectly legal to use "if(isdigit(c))"
given the definitions above.
 
--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Jul 08 2003
prev sibling next sibling parent Dario <Dario_member pathlink.com> writes:
They return ints to be faster. Consider the code:

bit islower(char c) { return cast(bit) (_ctype[1 + c] & _LC); }
void func() { if(islower('c')) ... ; }

Since "cast(bit) n" is performed as "n ? true : false",
the int would be checked twice: once in islower() and once in func().

I don't know if this would be optimized after inlining, if it is not
then I prefer ctype.d's functions to return ints.

Anyway it is unconvenient that 2==true returns false. The compiler
should either complain that two incompatible types are compared or
cast 2 to an int (actually true is casted to int). What do you think?


I noticed the cytpe module in phobos for the first time the other day. And I
don't know if I'm the only one, but the functions don't seem like their
implemented in the most useful way.

A few of the functions in the module are:

int isdigit(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS A DIGIT
int isupper(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS UPPER-CASE
int islower(char c) // RETURNS A NONZERO VALUE IF THE CHAR IS LOWER-CASE

I can't fathom why I would want an int return value from these types of
functions. What am I going to do with an int? What I'd really like is a bit
return value (or a bool, if that suits your fancy).

So, for example, I'd like to write code like this:

if (isdigit(c)) { ... }

..or like this...

if (isdigit(c) == true) { ... }

..rather than code like this:

if (isdigit(c) != 0) { ... }

As it stands, I've written my own set of functions that mirror the purpose of
the functions in the ctype module. But my functions return bits.

Am I all alone in thinking this way? Should these functions return ints or bits?
As far as I'm concerned, any function whose name starts with "is" should return
a bit or a bool. Maybe there's some hidden gem of knowledge that I'm missing
here, but I don't think so. If you know why ints are better, let me know.
Jul 09 2003
prev sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 Am I all alone in thinking this way?


No...


 As far as I'm concerned, any function whose name starts with "is" should return
 a bit or a bool. Maybe there's some hidden gem of knowledge that I'm missing
 here, but I don't think so. If you know why ints are better, let me know.


int is usually faster, as Dario also said. (BTW, that's why
a 'bool' type (at lucky places where it exists) is usually
implemented as a machine word (int), rather than a bit.)

But this int-bool-bit thing is actually an annoying little
problem language/compiler designers constantly struggle
with. There must be an underlying problem in the current
CPU designs that causes this... ;-o

Sz.
Jul 10 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Yeah, it's that none of our programming languages deal with the case where a
function wants to return a boolean value in a CPU flag bit.  They always
want to put the value into an integer register or in memory.  The other part
of the problem is that almost every x86 instruction screws with the flag
bits, possibly invalidating them, which is probably why compilers don't put
return values there.

It could be done.  Don't hold your breath though.  ;)

Sean

"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bek94m$2d9o$1 digitaldaemon.com...

 int is usually faster, as Dario also said. (BTW, that's why
 a 'bool' type (at lucky places where it exists) is usually
 implemented as a machine word (int), rather than a bit.)

 But this int-bool-bit thing is actually an annoying little
 problem language/compiler designers constantly struggle
 with. There must be an underlying problem in the current
 CPU designs that causes this... ;-o
Jul 11 2003