www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.130 release

reply "Walter Bright" <newshound digitalmars.com> writes:
http://www.digitalmars.com/d/changelog.html
Sep 06 2005
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 http://www.digitalmars.com/d/changelog.html
 
 
 


Mmm.... bugs!!!

http://img378.imageshack.us/my.php?image=10001261rn.jpg
http://img378.imageshack.us/my.php?image=10001259sh.jpg

(sorry, couldn't resist linking to my favorite bug eater which I just 
happened to find today! And then afterwards see all these bug fixes!)
Sep 06 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dfl7ju$1u8b$1 digitaldaemon.com...

 http://www.digitalmars.com/d/changelog.html


Looking back at some of the recent updates, I kind of wonder who's doing 
more work - you, or Ben Hinkle ;)  The upshot of it is that we now have a 
very professional-feeling Streams library.  Makes me want to work on Phobos 
too.
Sep 06 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:dflb11$20s6$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:dfl7ju$1u8b$1 digitaldaemon.com...

 http://www.digitalmars.com/d/changelog.html


 Looking back at some of the recent updates, I kind of wonder who's doing
 more work - you, or Ben Hinkle ;)  The upshot of it is that we now have a
 very professional-feeling Streams library.  Makes me want to work on


Phobos

 too.


Ben Hinkle has been doing excellent work. I am grateful to him for his
efforts.
Sep 06 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dflipi$26l0$1 digitaldaemon.com...

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
 news:dflb11$20s6$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:dfl7ju$1u8b$1 digitaldaemon.com...

 http://www.digitalmars.com/d/changelog.html


 Looking back at some of the recent updates, I kind of wonder who's doing
 more work - you, or Ben Hinkle ;)  The upshot of it is that we now have a
 very professional-feeling Streams library.  Makes me want to work on


 Phobos

 too.


 Ben Hinkle has been doing excellent work. I am grateful to him for his
 efforts.


Thanks guys! I encourage others to get involved with phobos, too.
Sep 06 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:

 http://www.digitalmars.com/d/changelog.html



Fixed D.bugs/4750


What about:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4832
Which is somewhat similar, but different.

also see:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4836

Unless I'm doing something wrong, the bug is still there:
----------------------------------------------------------
D:\Documents and Settings\Aljudy\temp>dmd
Digital Mars D Compiler v0.130
Copyright (c) 1999-2005 by Digital Mars written by Walter Bright
Documentation: www.digitalmars.com/d/index.html
Usage:
   dmd files.d ... { -switch }

   files.d        D source files
   -c             do not link
   -d             allow deprecated features
   -debug         compile in debug code
   -debug=level   compile in debug code <= level
   -debug=ident   compile in debug code identified by ident
   -g             add symbolic debug info
   -Ipath         where to look for imports
   -inline        do function inlining
   -Llinkerflag   pass linkerflag to link
   -O             optimize
   -odobjdir      write object files to directory objdir
   -offilename    name output file to filename
   -op            do not strip paths from source file
   -profile       profile runtime performance of generated code
   -quiet         suppress unnecessary messages
   -release       compile release version
   -unittest      compile in unit tests
   -v             verbose
   -version=level compile in version code >= level
   -version=ident compile in version code identified by ident
   -w             enable warnings

D:\Documents and Settings\Aljudy\temp>type bug.d
void main(char[][] arg)
{
     printf("-5/3 prints: %d\n", -5/3);
     printf("-5/2 prints: %d\n", -5/2);
     printf("-7/3 prints: %d\n", -7/3);
     printf("-7/4 prints: %d\n", -7/4);
     printf("-7/7 prints: %d\n", -7/7);
     printf("-8/7 prints: %d\n", -8/7);
     printf("-12/6 prints: %d\n", -12/6);
     printf("12/6 prints: %d\n", 12/6);
     printf("-9/7 prints: %d\n", -9/7);
     printf("-11/8 prints: %d\n", -11/8);
     printf("-7/9 prints: %d\n", -7/9);
}
D:\Documents and Settings\Aljudy\temp>dmd bug.d
E:\dmd\dmd\bin\..\..\dm\bin\link.exe bug,,,user32+kernel32/noi;

D:\Documents and Settings\Aljudy\temp>bug
-5/3 prints: 1431655763
-5/2 prints: -3
-7/3 prints: 1431655763
-7/4 prints: -2
-7/7 prints: -1840700271
-8/7 prints: -1840700271
-12/6 prints: -1431655768
12/6 prints: 2
-9/7 prints: -1840700271
-11/8 prints: -2
-7/9 prints: 1908874353

D:\Documents and Settings\Aljudy\temp>
----------------------------------------------------------
Sep 06 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:dflc5g$21n3$1 digitaldaemon.com...

 ----------------------------------------------------------
 D:\Documents and Settings\Aljudy\temp>dmd bug.d
 E:\dmd\dmd\bin\..\..\dm\bin\link.exe bug,,,user32+kernel32/noi;

 D:\Documents and Settings\Aljudy\temp>bug
 -5/3 prints: 1431655763
 -5/2 prints: -3
 -7/3 prints: 1431655763
 -7/4 prints: -2
 -7/7 prints: -1840700271
 -8/7 prints: -1840700271
 -12/6 prints: -1431655768
 12/6 prints: 2
 -9/7 prints: -1840700271
 -11/8 prints: -2
 -7/9 prints: 1908874353


How embarassing for me. When I fixed the CmpExp constant folding, I
neglected to fix the DivExp and ModExp ones too, they have the same bug in
it (using the wrong typedef). Anyhow, it's fixed now and will go out in the
next update. Sorry about that. These tests are in the test suite now, so
they'll stay dead. grrrr!
Sep 08 2005
prev sibling next sibling parent reply jicman <jicman_member pathlink.com> writes:
dead link:

http://www.digitalmars.com/d/phobos/errors.html

Walter Bright says...

http://www.digitalmars.com/d/changelog.html
Sep 06 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
Fixed. Thanks!
Sep 07 2005
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
I'm delighted to see my name on the changelog, after such a short 
experience with D -- it's much easier to contribute to than C++ !!

But looking in std.math, I see you've included my draft function, 
precisionEquality(). This was superceded by feqrel(). It should be 
removed in the next update.

Might be worth making iabs public, though.

I have written a few more functions for std.math, but I will submit them 
  together as a block.
Sep 07 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
Could you email me feqrel then, please?

"Don Clugston" <dac nospam.com.au> wrote in message
news:dfm6r1$2o30$1 digitaldaemon.com...

 I'm delighted to see my name on the changelog, after such a short
 experience with D -- it's much easier to contribute to than C++ !!

 But looking in std.math, I see you've included my draft function,
 precisionEquality(). This was superceded by feqrel(). It should be
 removed in the next update.

 Might be worth making iabs public, though.

 I have written a few more functions for std.math, but I will submit them
   together as a block.
Sep 07 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Could you email me feqrel then, please?


The feqrel() that is in std.math is the correct one.
precisionEquality() was the previous name of the same function,
and is deprecated. Delete lines 842 - 975 from std.math.
(except that you can retain iabs() in line 871-874).

Sorry for the confusion.

-Don.

 
 "Don Clugston" <dac nospam.com.au> wrote in message
 news:dfm6r1$2o30$1 digitaldaemon.com...
 

I'm delighted to see my name on the changelog, after such a short
experience with D -- it's much easier to contribute to than C++ !!

But looking in std.math, I see you've included my draft function,
precisionEquality(). This was superceded by feqrel(). It should be
removed in the next update.

Might be worth making iabs public, though.

I have written a few more functions for std.math, but I will submit them
  together as a block.
Sep 07 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message
news:dfon8m$21lt$1 digitaldaemon.com...

 The feqrel() that is in std.math is the correct one.
 precisionEquality() was the previous name of the same function,
 and is deprecated. Delete lines 842 - 975 from std.math.
 (except that you can retain iabs() in line 871-874).

 Sorry for the confusion.


Done. No problem.
Sep 08 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 http://www.digitalmars.com/d/changelog.html


"added File.available overload digitalmars.D/27384"

What has this particular post to do with File.available?

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.
Sep 07 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 http://www.digitalmars.com/d/changelog.html


 "added File.available overload digitalmars.D/27384"

 What has this particular post to do with File.available?


Somewhere between my email and the release the number 6 changed to a 3. It 
should be http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27684
Sep 07 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:dfmkf1$34l$1 digitaldaemon.com...

 Somewhere between my email and the release the number 6 changed to a 3. It
 should be http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27684


Fixed.
Sep 07 2005
prev sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <dfl7ju$1u8b$1 digitaldaemon.com>, Walter Bright says...

http://www.digitalmars.com/d/changelog.html


Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit
broken. Because, if a negative value compares again ulong.min it still gives the
wrong result as the example code below shows.








































Output:
-------------------------
C:\dmd>dmd negcompare3.d
C:\dmd\bin\..\..\dm\bin\link.exe negcompare3,,,user32+kernel32/noi;

C:\dmd>negcompare3
With -128 in a literal works now.
main() : (-128 >= 0)=false, (-128 <= 0)=true

With -128 in a variable still works
main() : (-128 >= 0)=false, (-128 <= 0)=true
main() : (128 >= 0)=true, (128 <= 0)=false

But where I need it the most, it still does not!
ulong.min=0, ulong.max=18446744073709551615
main() : (-128 >= ulong.min)=true, (-128 <= ulong.max)=true
main() : (128 >= ulong.min)=true, (128 <= ulong.max)=true

C:\dmd>

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Sep 07 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
David L. Davis wrote:

 In article <dfl7ju$1u8b$1 digitaldaemon.com>, Walter Bright says...
 

http://www.digitalmars.com/d/changelog.html


 
 
 Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit
 broken. Because, if a negative value compares again ulong.min it still gives
the
 wrong result as the example code below shows.


I'd say it's just bad style to be comparing longs and ulongs.. If you 
compare a signed long with a value larger than long.max, the "correct" 
result is constant anyway, ditto for negative values compared with 
anything unsigned..


xs0
Sep 08 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
xs0 wrote:

 David L. Davis wrote:

 In article <dfl7ju$1u8b$1 digitaldaemon.com>, Walter Bright says...
 

 http://www.digitalmars.com/d/changelog.html


 
 Walter thank you for doing the Bugs/4750 fix, but I think it's still a 
 bit broken. Because, if a negative value compares again ulong.min it still 
 gives the wrong result as the example code below shows.


 
 I'd say it's just bad style to be comparing longs and ulongs.. If you 
 compare a signed long with a value larger than long.max, the "correct" 
 result is constant anyway, ditto for negative values compared with 
 anything unsigned..


It actually shouldn't be that difficult to implement correctly.

If one side of the comparison is a compile-time constant, the compiler 
can determine whether the result is constant on a case-by-case basis, 
and if it isn't constant, do the compare in the type of the side that 
isn't constant.

OTOH if you have this

     long l;
     ulong ul;
     ...
     if (l < ul) { ... }

the code that's generated for the if statement would be equivalent to this

     if ((l & long.min) || (cast(ulong) l < ul)) { ... }

Similarly,

     l > ul

would become

     !(l & long.min) && (cast(ulong) l < ul)

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.
Sep 08 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"David L. Davis" <SpottedTiger yahoo.com> wrote in message
news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit
 broken. Because, if a negative value compares again ulong.min it still


gives the

 wrong result as the example code below shows.


Unfortunately, that's the C integral promotion rules at work. If either
operand is of unsigned type, then the result become an unsigned comparison.
Sep 08 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:


 "David L. Davis" <SpottedTiger yahoo.com> wrote in message
 news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit
 broken. Because, if a negative value compares again ulong.min it still


 gives the

 wrong result as the example code below shows.


 
 Unfortunately, that's the C integral promotion rules at work. If either
 operand is of unsigned type, then the result become an unsigned comparison.


Yes, one must not use common sense here. Its obvious that when a coder
wants to compare a potentially negative value with a guaranteed positive
value that she really meant to interpret the bit pattern of the signed
value as if it was an unsigned value. Stupid to think otherwise, no?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 1:53:52 PM
Sep 08 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg 40tude.net...

 On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:


 "David L. Davis" <SpottedTiger yahoo.com> wrote in message
 news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's still a






bit

 broken. Because, if a negative value compares again ulong.min it still


 gives the

 wrong result as the example code below shows.


 Unfortunately, that's the C integral promotion rules at work. If either
 operand is of unsigned type, then the result become an unsigned




comparison.

 Yes, one must not use common sense here. Its obvious that when a coder
 wants to compare a potentially negative value with a guaranteed positive
 value that she really meant to interpret the bit pattern of the signed
 value as if it was an unsigned value. Stupid to think otherwise, no?


The trouble with such rules is they've become deeply embedded in the C/C++
programmer's psyche. The difference in behavior shows up in the corner
cases. This means that if one relies on one's tried and true instincts about
how things work, they'll fail oddly. Worse, it would make it impractical to
convert existing C/C++ code to D that had non-trivial integer calculations
in it.
Sep 08 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 8 Sep 2005 23:20:32 -0700, Walter Bright wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg 40tude.net...

 On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:


 "David L. Davis" <SpottedTiger yahoo.com> wrote in message
 news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's still a






 bit

 broken. Because, if a negative value compares again ulong.min it still


 gives the

 wrong result as the example code below shows.


 Unfortunately, that's the C integral promotion rules at work. If either
 operand is of unsigned type, then the result become an unsigned




 comparison.

 Yes, one must not use common sense here. Its obvious that when a coder
 wants to compare a potentially negative value with a guaranteed positive
 value that she really meant to interpret the bit pattern of the signed
 value as if it was an unsigned value. Stupid to think otherwise, no?


 
 The trouble with such rules is they've become deeply embedded in the C/C++
 programmer's psyche. The difference in behavior shows up in the corner
 cases. This means that if one relies on one's tried and true instincts about
 how things work, they'll fail oddly. Worse, it would make it impractical to
 convert existing C/C++ code to D that had non-trivial integer calculations
 in it.


I understand. I keep forgetting that D is evolutionary and not
revolutionary. It must keep it's 'appendix'.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 4:52:08 PM
Sep 08 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg 40tude.net...

 On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
 

 "David L. Davis" <SpottedTiger yahoo.com> wrote in message 
 news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's
 still a bit broken. Because, if a negative value compares
 again ulong.min it still gives the wrong result as the example
 code below shows.








<snip>

 The trouble with such rules is they've become deeply embedded in the
 C/C++ programmer's psyche. The difference in behavior shows up in
 the corner cases. This means that if one relies on one's tried and
 true instincts about how things work, they'll fail oddly. Worse, it
 would make it impractical to convert existing C/C++ code to D that
 had non-trivial integer calculations in it.


The real question is: which is the lessest of three evils?

(a) admitting code that behaves differently from the same code in C 
(already done in at least two places)

(b) admitting code that has counter-intuitive behaviour

(c) the working cases that don't rely on this difference and would 
become bloated if we disallowed it, hence requiring a cast?

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.
Sep 09 2005
next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <dfri1g$1fgr$1 digitaldaemon.com>, Stewart Gordon says...

Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg 40tude.net...

 On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
 

 "David L. Davis" <SpottedTiger yahoo.com> wrote in message 
 news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's
 still a bit broken. Because, if a negative value compares
 again ulong.min it still gives the wrong result as the example
 code below shows.








<snip>

 The trouble with such rules is they've become deeply embedded in the
 C/C++ programmer's psyche. The difference in behavior shows up in
 the corner cases. This means that if one relies on one's tried and
 true instincts about how things work, they'll fail oddly. Worse, it
 would make it impractical to convert existing C/C++ code to D that
 had non-trivial integer calculations in it.


The real question is: which is the lessest of three evils?

(a) admitting code that behaves differently from the same code in C 
(already done in at least two places)

(b) admitting code that has counter-intuitive behaviour

(c) the working cases that don't rely on this difference and would 
become bloated if we disallowed it, hence requiring a cast?

Stewart.


The three evils...what is a Monkey to do?
-----------------------------------------
a) Monkey see  (ignore it, move on to b)
b) Monkey hear (ignore it, move on to c)
c) Monkey do   (always cast to the highest type before a numeric compare)

Well I guess it's better for a Monkey to have a "cast," than a "wrench."

<g>

David L.

P.S. Stewart, I hope you don't mind me having a little fun with the three evils?


-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Sep 09 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <dfri1g$1fgr$1 digitaldaemon.com>, Stewart Gordon says...

Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg 40tude.net...

 On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
 

 "David L. Davis" <SpottedTiger yahoo.com> wrote in message 
 news:dfnfsc$tg6$1 digitaldaemon.com...

 Walter thank you for doing the Bugs/4750 fix, but I think it's
 still a bit broken. Because, if a negative value compares
 again ulong.min it still gives the wrong result as the example
 code below shows.








<snip>

 The trouble with such rules is they've become deeply embedded in the
 C/C++ programmer's psyche. The difference in behavior shows up in
 the corner cases. This means that if one relies on one's tried and
 true instincts about how things work, they'll fail oddly. Worse, it
 would make it impractical to convert existing C/C++ code to D that
 had non-trivial integer calculations in it.


The real question is: which is the lessest of three evils?

(a) admitting code that behaves differently from the same code in C 
(already done in at least two places)

(b) admitting code that has counter-intuitive behaviour

(c) the working cases that don't rely on this difference and would 
become bloated if we disallowed it, hence requiring a cast?


All good points.  Although I'm leaning toward (c) (I take this as flag a compile
error since its ambiguous) I would argure for (d) - It doesn't matter (no
offense intended here).

No matter what, its going to be inconsistent with *something*; as you mention,
they're all less than optimal (evil).  As long as the behavior is
well-documented, possibly in a FAQ or something else more searchable, then at
least it won't cause a programmer too much trouble.

I can't tell you how many times I've lost time to a problem that was built-in or
a consequence of platform design that simply wasn't on the books.  Being able to
look something like this up is what saves folks huge amounts of time, no matter
what the decided outcome is.


- EricAnderton at yahoo
Sep 09 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <dfri1g$1fgr$1 digitaldaemon.com>, Stewart Gordon says...

The real question is: which is the lessest of three evils?

(a) admitting code that behaves differently from the same code in C 
(already done in at least two places)

(b) admitting code that has counter-intuitive behaviour

(c) the working cases that don't rely on this difference and would 
become bloated if we disallowed it, hence requiring a cast?


Visual C++ flags comparisons between signed/unsigned types at warning level 4.
Being a tad pragmatic, I always compile at this warning level and explicitly
cast for the few comparisons where I want to allow this.  I would be willing to
accept implicit comparisons of this nature being an error in D.  Porting C/C++
code would then be simple (if a bit tedious)--throw in a bunch of casts and
you're done.


Sean
Sep 09 2005