James Dennett wrote:
> With D, at present, probably none.  Some mainframes and
> some embedded environments are the only remaining ones
> I know about (though my knowledge is, of course, a long
> long way from being encyclopedic.)

IBM still builds some machines which use EBCDIC, but with EBCDIC, things are even worse: the characters aren't even arranged contiguously in the space!  So in EBCDIC
  char c;
  int i = c - 'a';
won't work!

But you're right, I don't think that D is running on any of those...unless GDC is portable to one...

Walter Bright wrote:
> Bruno Medeiros wrote:
>> I agree, but on a side note, shouldn't D's cast() operator be used exclusively to subvert *static* type checking?
>> (Since currently it's also used to check the runtime type of class, instead of a separate construct like Java's 'instanceof', C#'s 'is', or C++'s 'dynamic_cast')
> 
> I could argue it either way.

Some other interesting examples.

--- Ruby
obj.is_a? Class       # Considers all ancestor classes
obj.instanceof? Class # Only considers immediate class
obj.class == Class    # Same as above, naturally

--- PHP
is_a(obj, 'Class')


The terms 'is' and 'is a' seem to be everywhere.

(But I'm actually perfectly fine with the cast() style.)

-- Chris Nicholson-Sauls

Russell Lewis wrote:
> James Dennett wrote:
> 
>> With D, at present, probably none.  Some mainframes and
>> some embedded environments are the only remaining ones
>> I know about (though my knowledge is, of course, a long
>> long way from being encyclopedic.)
> 
> 
> IBM still builds some machines which use EBCDIC, but with EBCDIC, things are even worse: the characters aren't even arranged contiguously in the space!  So in EBCDIC
>   char c;
>   int i = c - 'a';
> won't work!
> 

a-f and A-F are sequential so that works (after case conversion) and also a & A are different by only one bit so:

c |= 'a' ^ 'A'
c &= ~('a' ^ 'a')

works, as does

c += ('a' - 'A')

0ffh wrote:
> Derek Parnell wrote:
>> On Tue, 24 Jul 2007 20:55:41 -0400, Robert Fraser wrote:
>>
>>> for(int i = 100; i; i--) // Takes a second to mentally figure out
>>> what's going on
>>
>> I'm still not explaining myself I guess. Yes, it doesn't take much to
>> work
>> out what the compiler is going to generate for that code. But that is not
>> the issue I'm addressing.
> 
> I think maybe you wanted to address me here, not Robert.
> A second is a looonng time! :)
> 
>> If however, one gets used to typing 'i>0' or similar fully specified
>> comparisions,
>> we all have a better confidence level that the code is written as
>> intended to be written.
>> Of course, it is not a way to prevent all errors, but just a technique to
>> reduce coding errors.
> 
> I know the argument well. I use it myself to argue for fully braced expressions instead of relying on operator precedence (apart from the usual exceptions). Also, braces will actually help me parsing.
> 
> BUT there is a huge difference here: I'll repeat it this once before stopping to do this (I don't believe in reiteration contests):
> 
> Using integers or pointers as bools is
> 
>   1. /Easy/ to understand and use correctly
>   2. /Shorter/ - less to type and less to take in - and therefore
>   3. /Faster/ to parse mentally (once you're used to it), also it's
>   4. Not obligatory for those who feel uncomfortable with it, but
>   5. Looks one darn hell better
>      than having a detrimental tumour of nop characters attached.

And, with a similar amount of evidence, I claim that being explicit about comparisons with zero or null is

  1. Easier to understand and use correctly;
  2. More explicit - less to fill in implicitly, and therefore
  3. Faster to parse mentally (once you're used to rigor), also it's
  4. Not obligatory for those who feel uncomfortable with it, but
  5. Looks one darn hell better than having expressions that are
     morally, if not technically, type errors left in code.

I suspect, but cannot prove, that it's also less error-prone. However, without evidence, the debate is pointless.

-- James

0ffh wrote:
> Robert Fraser wrote:
>> 0ffh Wrote:
>> "if(x != 0)" is just more explicit than "if(x)", but not many people
>> use "if(b != false)" (unless you're that guy
>> where I wrote who wrote "while(m_userSubscribed ==
>> Boolean.FALSE.booleanValue())", which I sincerely hope wasn't
>> sincere), so being concise isn't bad as long as you're meaning is
>> clear. I think it looks ugly in for loops, though:
> 
> So help me glod I did not, but I consider that code line to be sarcastic humour! :)
> 
>> for(int i = 100; i; i--) // Takes a second to mentally figure out
>> what's going on
> 
> Funny! I claim my brain parses the "i" /faster/ without the "=!0"!
> 
> "if (x)" takes me half a glance to parse and understand.
> "if (x!=0)" takes at least three quarters of a glance.
> 
> Maybe it's just a matter of being used to use this construct?

No; you'll find that many of those who advocate the explicit approach are very used to both.  It's best not to assume that people whose opinions differ from our own are less informed.

-- James

James Dennett wrote:
> 0ffh wrote:
>> Maybe it's just a matter of being used to use this construct?
> No; you'll find that many of those who advocate the explicit
> approach are very used to both.  It's best not to assume that
> people whose opinions differ from our own are less informed.

I assume if you really, really tried, you could spot the
difference between offering a noncommittal hypothesis and
making an assumption.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:f80p2n$2k7a$1@digitalmars.com...
>
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.019.zip
>
> http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.2.003.zip

Oww, I was quitely hoping that extern (System) would allow one to write

extern (System) char[] bzip2(char[]);

and that the compiler would then insert the necessary code to redirect stdin/out to the strings...

Oh well.. Still a great release ; )

L.

Lionello Lunesu wrote:
> Oww, I was quitely hoping that extern (System) would allow one to write
> 
> extern (System) char[] bzip2(char[]);
> 
> and that the compiler would then insert the necessary code to redirect stdin/out to the strings...

I'd have been annoyed if it had... all that work writing a bzip2 binding...

:P

	-- Daniel

Well, I suppose my last posting in this thread was
a bit emotional. I took offence and couldn't help
the urge to give some in return. I agologise.

Regards, Frank

0ffh wrote:
> 
> Well, I suppose my last posting in this thread was
> a bit emotional. I took offence and couldn't help
> the urge to give some in return. I agologise.
> 
> Regards, Frank

Apology accepted; we've all done similarly (and those
who haven't, likely will one day).  I'll offer my
apology that my wording in previous posts may have
seemed abrasive.  It wasn't intended to be so, but I
do tend to use a style some may perceive as adversarial.
(I hope people try not to take me too seriously.  I
know I don't.)

-- James