There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.

The most obvious is int opEquals(Object) defined in the Object class. Changing this'll break a considerable amount of existing code - but then again, the 0.163 change of making imports private by default has done this already.

But there are many functions in Phobos that can be cleaned up a bit without doing much harm.  Just to name a few....

std.string.iswhite
std.string.inPattern
std.ctype.isalnum (indeed, most of the functions in std.ctype)
std.file.exists
std.file.isfile
std.file.isdir
std.intrinsic.bt
std.intrinsic.btc
std.intrinsic.btr
std.intrinsic.bts
std.math.isnan (and other is* functions)
std.math.signbit

Going through the other modules will probably reveal many more, but I haven't checked.

Stewart.

Stewart Gordon wrote:
> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.

They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference.

Walter Bright wrote:
> Stewart Gordon wrote:
>> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.
> 
> They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference.

But isn't bool an int internally? Why is it less efficient to use a bool?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:e9qd21$2ueu$2@digitaldaemon.com...

> But isn't bool an int internally? Why is it less efficient to use a bool?

It's a byte internally.

Bruno Medeiros wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
>>> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.
>>
>> They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference.
> 
> But isn't bool an int internally? Why is it less efficient to use a bool?

It's a byte internally, and is constrained to be one of the values 0 or 1.

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Stewart Gordon wrote:
>>>> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.
>>>
>>> They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference.
>>
>> But isn't bool an int internally? Why is it less efficient to use a bool?
> 
> It's a byte internally, and is constrained to be one of the values 0 or 1.

Duh, it's a byte of course, I should have checked that.

But the question remains, is it then less efficient to return a byte than a int? Why? And if so isn't there a way for the compiler to somehow optimize it?
I find it a bit hard to believe that nowadays there isn't sufficient compiler and/or CPU technology to somehow make a bool(byte) return value as efficient as a int one. :/

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

>> It's a byte internally, and is constrained to be one of the values 0 or 1.
> 
> Duh, it's a byte of course, I should have checked that.
> 
> But the question remains, is it then less efficient to return a byte than a int? Why? And if so isn't there a way for the compiler to somehow optimize it?
> I find it a bit hard to believe that nowadays there isn't sufficient compiler and/or CPU technology to somehow make a bool(byte) return value as efficient as a int one. :/

Well, I'm just guessing, but I think something like

> int opEquals(Foo foo)
> {
>     return this.bar == foo.bar;
> }

is compiled to something like

> return this.bar-foo.bar; // 1 instruction

but if the return type is bool, it becomes

> return this.bar-foo.bar?1:0; // 3 instructions

It's the 1/0 constraint on bools that causes the slowness, not the size (stack is usually size_t-aligned anyway)


xs0

xs0 wrote:
<snip>
> Well, I'm just guessing, but I think something like
> 
>  > int opEquals(Foo foo)
>  > {
>  >     return this.bar == foo.bar;
>  > }
> 
> is compiled to something like
> 
>> return this.bar-foo.bar; // 1 instruction
> 
> but if the return type is bool, it becomes
> 
>> return this.bar-foo.bar?1:0; // 3 instructions

If it does this, then there's a serious bug in the compiler.

Moreover, what's your evidence that subtracting one number from another might be more efficient than comparing them for equality directly?

> It's the 1/0 constraint on bools that causes the slowness, not the size (stack is usually size_t-aligned anyway)

But if the function only tries to return 0 or 1 anyway, then what difference does it make?  At the moment, I can't think of an example of equality testing that can be made more efficient by being allowed to return a value other than 0 or 1.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Bruno Medeiros wrote:
> But the question remains, is it then less efficient to return a byte than a int?

Yes. It's also less efficient to constrain the results to 0 or 1.

> Why?

Consider:

	a = 0x1000;
	b = 0x2000;

Now convert (a == b) into a bool. If the result is an int, I can just do (a - b), one instruction. Converting it to a byte, or to 1 or 0, takes more.

> And if so isn't there a way for the compiler to somehow optimize it?

The math is inevitable <g>.

> I find it a bit hard to believe that nowadays there isn't sufficient compiler and/or CPU technology to somehow make a bool(byte) return value as efficient as a int one. :/

I work with what the CPU makes available.

P.S. Inevitably, some will ask "who cares" about these small efficiencies. The trouble is, these kinds of things often appear in tight loops, where small inefficiencies get multiplied by millions.

Stewart Gordon wrote:
> xs0 wrote:
> <snip>
>> Well, I'm just guessing, but I think something like
>>
>>  > int opEquals(Foo foo)
>>  > {
>>  >     return this.bar == foo.bar;
>>  > }
>>
>> is compiled to something like
>>
>>> return this.bar-foo.bar; // 1 instruction
>>
>> but if the return type is bool, it becomes
>>
>>> return this.bar-foo.bar?1:0; // 3 instructions
> 
> If it does this, then there's a serious bug in the compiler.

What instruction sequence do expect to be generated for it?

> Moreover, what's your evidence that subtracting one number from another might be more efficient than comparing them for equality directly?

The only difference between a CMP and a SUB instruction is where the result ends up. But the CMP doesn't generate 0 or 1 as a result, it puts the result in the FLAGS register. Converting the FLAGS to a 0 or 1 in a register takes more instructions.

>> It's the 1/0 constraint on bools that causes the slowness, not the size (stack is usually size_t-aligned anyway)
> 
> But if the function only tries to return 0 or 1 anyway, then what difference does it make?  At the moment, I can't think of an example of equality testing that can be made more efficient by being allowed to return a value other than 0 or 1.

I can. (a == b), where a and b are ints, can be implemented as (a - b), and the result is int 0 for equality, int !=0 for inequality.