www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bool type - can't it be zero / nonzero?

reply celopmuh <humpolec gmail.com> writes:
From what I gathered, the inconsistency in using bool/int types is for the sake
of optimization, and int logical values work faster mainly because they're 0 /
non-0, not 0/1 (so that you can use simple subtraction to compare things).

But why is the bool type represented as 0 / 1 in the first place? We already
know that zero/nonzero convention makes things faster, so why discard it?
The only thing it makes more complicated is comparing two bools, but I believe
such comparison is not performed often and/or can be optimized better than
comparison of two numbers.
Jun 07 2008
parent reply Chris Wright <dhasenan gmail.com> writes:
celopmuh wrote:

 From what I gathered, the inconsistency in using bool/int types is for the
sake of optimization, and int logical values work faster mainly because they're
0 / non-0, not 0/1 (so that you can use simple subtraction to compare things).


The inconsistency is a compiler-specific optimization: dmd, I believe, 
generates slow code for dealing with bools, so Walter made 
Object.opEquals return an int.

There's faster code available for dealing with bool comparisons that 
make them at least as fast as the integer equivalents. It's been on the 
newsgroup once or twice.
Jun 08 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Wright" <dhasenan gmail.com> wrote in message 
news:g2gp5a$n1m$1 digitalmars.com...

 celopmuh wrote:

 From what I gathered, the inconsistency in using bool/int types is for 
 the sake of optimization, and int logical values work faster mainly 
 because they're 0 / non-0, not 0/1 (so that you can use simple 
 subtraction to compare things).


 The inconsistency is a compiler-specific optimization: dmd, I believe, 
 generates slow code for dealing with bools, so Walter made Object.opEquals 
 return an int.


This "tool issues drive the spec" kind of worries me.  This is not the only 
instance.  D limits the size of single blocks of data in the static data 
segment to 16MB with the rationale that "anything bigger should really be on 
the heap."  The truth seems to be that OPTLINK simply crashes or does 
something equally horrible if there is a piece of data more than 16MB in the 
static data segment.  Coincidence?
I'm worried what's next.  "D does not permit variadic templates whose 
mangled names would be longer than 4096 characters"?

Now some things are understandable.  Working on my own implementation of a 
language it's become clear that some features are simply unworkable because 
of inherent limitations of the environment in which the implementation is 
written.  But this should not have any bearing on the spec, only a note in 
the implementation notes saying that it _almost_ follows the spec but 
doesn't in this area because of some restriction.
Jun 08 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 This "tool issues drive the spec" kind of worries me.  This is not the only 
 instance.  D limits the size of single blocks of data in the static data 
 segment to 16MB with the rationale that "anything bigger should really be on 
 the heap."  The truth seems to be that OPTLINK simply crashes or does 
 something equally horrible if there is a piece of data more than 16MB in the 
 static data segment.  Coincidence?


No. Both are true. Optlink has an internal limit of 16Mb for one 
variable of static data, and it's hard to fathom a need for anything 
larger that isn't better served by the heap.



 I'm worried what's next.  "D does not permit variadic templates whose 
 mangled names would be longer than 4096 characters"?


D has almost no numerical limits compared to other languages like C and 
C++, which have quite a few.



 Now some things are understandable.  Working on my own implementation of a 
 language it's become clear that some features are simply unworkable because 
 of inherent limitations of the environment in which the implementation is 
 written.  But this should not have any bearing on the spec, only a note in 
 the implementation notes saying that it _almost_ follows the spec but 
 doesn't in this area because of some restriction.


It's difficult to say if a program is language conformant if it fails on 
one compiler due to exceeding a limit and works with another, and if the 
language does not specify any limits. It's also difficult to say if a 
compiler is conformant.

16Mb is an extremely high limit for a single piece of statically 
initialized data.
Jun 09 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  9 de junio a las 03:33 me escribiste:

 16Mb is an extremely high limit for a single piece of statically initialized 
 data.


"640kb ought to be enough for anybody." -- Bill Gates =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Pitzulino! Pitzulino!
Todos a cantar por el tubo!
Pitzulino! Pitzulino!
Todos a cantar por el codo!
Jun 09 2008