• Matthew Wilson (17/17) Oct 10 2003 Porting code from C/C++ is a minefield. Comparing pointers requires
• Hauke Duden (10/13) Oct 10 2003 \vote yes !!!!!
• Matthew Wilson (19/32) Oct 10 2003 I agree with that argument in general, even though I've managed to grok ...
• Charles Sanders (12/29) Oct 11 2003 I know im going againts popular opinion here but i like the === . I wou...
• Matthew Wilson (9/43) Oct 11 2003 rather
• Charles Sanders (19/64) Oct 11 2003 Im not sure what you mean actually, your saying that when wrapping the C
• Matthew Wilson (53/123) Oct 11 2003 No. I'm saying that when porting code, i.e. copying C or C++ code (in)to...
• Charles Sanders (25/156) Oct 11 2003 I see what your saying but it seems only a problem when porting code. I
• Charles Sanders (20/187) Oct 11 2003 After thinking about it and playing with it a little bit I agree === is ...
• Matthew Wilson (28/195) Oct 11 2003 Yes, as I said in another post, I've over-simplified the solution to thi...
• Ben Hinkle (33/162) Oct 12 2003 Wow. I didn't realize != didn't accept nulls. I'm so used to writing "!=
• Hauke Duden (16/19) Oct 12 2003 would
• Patrick Down (5/26) Oct 11 2003 While I'm all in favor of replacing === with 'is', I'm not quite sure
• Matthew Wilson (6/32) Oct 11 2003 Gah! You're right. What a dumbo!
• Vathix (2/9) Oct 11 2003 If your C/C++ code uses pointers, why don't you use pointers in D? Leave...
• Patrick Down (11/21) Oct 12 2003 I think it is wrong to burden the language

"Matthew Wilson" <matthew stlsoft.org> writes:

Porting code from C/C++ is a minefield. Comparing pointers requires
translating ==/!= to ===/!==, whereas doing it for other types requires
==/!= be preserved. The compiler does *nothing* to help, since it's quite
happy with the syntax if you forget/omit the extra "=" - it all still
compiles. Who knows when these erroneous constructs will bite at runtime?
The first time it's run? After 1,000,000 executions? It's the Turing Halting
problem, and its' NP.

Please, please, please, please, please can we get rid of === and !==, and
replace them with something that will not (or at least, less easily)
facilitate undetectable errors entering code? My suggestion is "is" and "is
not", but I'm not particularly stuck on that. Anything that will avoid these
errors.

The only alternative that will save us from unknown numbers of errors is to
proscribe all porting and require everything to be written anew. (Sounds of
myriad potential doors slamming ...)

Yours portentously

Freddie

"Hauke Duden" <H.NS.Duden gmx.net> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm7c3d$1pqi$1 digitaldaemon.com...
 Please, please, please, please, please can we get rid of === and !==, and
 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code?

\vote yes !!!!!

"is" is so much more readable than ===. Anecdotal evidence: I have noted a
tendency in myself that when I'm reading code and I see !== I intuitively
think that it is the negative form of ==, not ===. I don't want to delve
into a psychological analysis of why that is the case here, but I do think
too many = signs are just too confusing. I always have to consciously think
about what is meant by such an expression.

Hauke

"Matthew Wilson" <matthew stlsoft.org> writes:

I agree with that argument in general, even though I've managed to grok the
differences reasonably well over the course of my D experience. That's not
to say that I don't occasionally make the mistake, but it's not often.
However, even for those (few, probably) who are 100% confident and competent
with writing the operators themselves, when porting code there is
*absolutely no way* that anyone is going to achieve the same level of
success. I know this because I'm doing it right now, and the significance of
this issue is only just dawning on me. Where previously I had disliked the
operators for the reasons you have described (which, IMO, are sufficient to
require them to change in an ideal world), I now *know* that they are a
clear and present danger to code correctness.

Sorry to sound so alarmist, but as soon as large (the project I'm converting
now I would call small, as it's less than 3000 LOCs) projects are ported,
the evangelists of all D's competitor languages will have some powerful
evidence to back their current misgivings and prejudices.




"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bm7cvn$1qq5$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Please, please, please, please, please can we get rid of === and !==,


and
 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code?

 \vote yes !!!!!

 "is" is so much more readable than ===. Anecdotal evidence: I have noted a
 tendency in myself that when I'm reading code and I see !== I intuitively
 think that it is the negative form of ==, not ===. I don't want to delve
 into a psychological analysis of why that is the case here, but I do think
 too many = signs are just too confusing. I always have to consciously

think
 about what is meant by such an expression.

 Hauke

"Charles Sanders" <sanders-consulting comcast.net> writes:

I know im going againts popular opinion here but i like the === .  I would
prefer if == and != could do the same thing, but if not I would much rather
have an operator than 'is [of]'.  The operator helps maintain a level of
continuity.

C


"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers requires
 translating ==/!= to ===/!==, whereas doing it for other types requires
 ==/!= be preserved. The compiler does *nothing* to help, since it's quite
 happy with the syntax if you forget/omit the extra "=" - it all still
 compiles. Who knows when these erroneous constructs will bite at runtime?
 The first time it's run? After 1,000,000 executions? It's the Turing

Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and !==, and
 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code? My suggestion is "is" and

"is
 not", but I'm not particularly stuck on that. Anything that will avoid

these
 errors.

 The only alternative that will save us from unknown numbers of errors is

to
 proscribe all porting and require everything to be written anew. (Sounds

of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Matthew Wilson" <matthew stlsoft.org> writes:

"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .  I would
 prefer if == and != could do the same thing, but if not I would much

rather
 have an operator than 'is [of]'.  The operator helps maintain a level of
 continuity.

That's nice to know, ;), but you've not addressed my porting issue. Do you
think it's wrong, or that I've overstated the case, or you're not
interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers requires
 translating ==/!= to ===/!==, whereas doing it for other types requires
 ==/!= be preserved. The compiler does *nothing* to help, since it's


quite
 happy with the syntax if you forget/omit the extra "=" - it all still
 compiles. Who knows when these erroneous constructs will bite at


runtime?
 The first time it's run? After 1,000,000 executions? It's the Turing

 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and !==,


and
 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code? My suggestion is "is" and

 "is
 not", but I'm not particularly stuck on that. Anything that will avoid

 these
 errors.

 The only alternative that will save us from unknown numbers of errors is

 to
 proscribe all porting and require everything to be written anew. (Sounds

 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Charles Sanders" <sanders-consulting comcast.net> writes:

Im not sure what you mean actually, your saying that when wrapping the C
code in extern () blocks that the pointer comparison has to be manually
changed to === and !== , and that this causes a bunch of errors ?  Admitedly
I havent done any real porting so I dont have much of an argument other than
i think its 'purtier' than "is" ( although I am working with Y. Tomino to
get win32.lib easy to use, requiring alot of .def files and exports to get
it to work.  Right now the only way I can see to do it is for each .dll ,
write a corresponding .def file that maps all the functions to ther
_XXX (num) counterparts.  Is this really the only way ? This will take
forever ... )

Also congrats on the new column :D.

C


"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm9mub$1u0b$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .  I


would
 prefer if == and != could do the same thing, but if not I would much

 rather
 have an operator than 'is [of]'.  The operator helps maintain a level of
 continuity.

 That's nice to know, ;), but you've not addressed my porting issue. Do you
 think it's wrong, or that I've overstated the case, or you're not
 interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers requires
 translating ==/!= to ===/!==, whereas doing it for other types



requires
 ==/!= be preserved. The compiler does *nothing* to help, since it's


 quite
 happy with the syntax if you forget/omit the extra "=" - it all still
 compiles. Who knows when these erroneous constructs will bite at


 runtime?
 The first time it's run? After 1,000,000 executions? It's the Turing

 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and !==,


 and
 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code? My suggestion is "is"



and
 "is
 not", but I'm not particularly stuck on that. Anything that will avoid

 these
 errors.

 The only alternative that will save us from unknown numbers of errors



is
 to
 proscribe all porting and require everything to be written anew.



(Sounds
 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Matthew Wilson" <matthew stlsoft.org> writes:

No. I'm saying that when porting code, i.e. copying C or C++ code (in)to D,
the translation of != and == to !== and === can be overlooked, and the
compiler does nothing to help. Since porting code will feature large, this
is a certain accident waiting to happen. To be honest, I'm not even sure
that I've got every instance covered in the small amount of code I did
yesterday. In principle it is impossible to guarantee that these errors will
not creep into arbitrarily large amounts of ported code, since one operator
is a lexical subset of the other, and both can be applied to some
circumstance.

For example (names are chosen for clarity in this case; they're not my
naming convention), if I had some C++ code

Object *object_ptr
if(NULL != object_ptr)
{
  object_ptr->SomeMethod();
}

Object &object_ref =
if(0 != object_ref) /* Assuming Object is comparable with 0 */
{
  object_ref.SomeMethod();
}

Now when I'm porting this to D, I do the following:

- Replace NULL with null - this is 100% correctness-assured, since NULL is
not recognised in D
- Change all the pointers to D references - this is 100% correctnes-assured,
since D does not support ->, so we can replace all of those with ., and
handle the syntax errors
- Change all the C++ references to D references - I've not thought out this
completely, but I believe it's 100% correctness assured since D doesn't
allows the C++ reference declaration notation
- Try and change some of the != or == to !== and ===. I need to remember to
change the first one, and not the second one. In the two cases above, if I
make no change to these operators the compiler is happy. However, the first
conditional now has a runtime error waiting to kill the process. This may
come out in testing, or it may not. Proving that we've got it correct is
theoretically impossible (a la Turing Halting problem), so here comes la-la
land. People will rightly say that D has fostered entirely new methods of
writing invalid code.

(The example may not be the best, as I'm not sure that D objects can be
overloadedly comparable with integral values, but I think you get the idea.)

Is this clear? If it's not, I'll try again, because this is so important we
need to get a quorum of worried folks to badger Walter into changing it.
Otherwise, D-knockers have got a big gun to shoot it with.


"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bm9nsa$1vcu$1 digitaldaemon.com...
 Im not sure what you mean actually, your saying that when wrapping the C
 code in extern () blocks that the pointer comparison has to be manually
 changed to === and !== , and that this causes a bunch of errors ?

Admitedly
 I havent done any real porting so I dont have much of an argument other

than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino to
 get win32.lib easy to use, requiring alot of .def files and exports to get
 it to work.  Right now the only way I can see to do it is for each .dll ,
 write a corresponding .def file that maps all the functions to ther
 _XXX (num) counterparts.  Is this really the only way ? This will take
 forever ... )

 Also congrats on the new column :D.

 C


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9mub$1u0b$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .  I


 would
 prefer if == and != could do the same thing, but if not I would much

 rather
 have an operator than 'is [of]'.  The operator helps maintain a level



of
 continuity.

 That's nice to know, ;), but you've not addressed my porting issue. Do


you
 think it's wrong, or that I've overstated the case, or you're not
 interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers requires
 translating ==/!= to ===/!==, whereas doing it for other types



 requires
 ==/!= be preserved. The compiler does *nothing* to help, since it's


 quite
 happy with the syntax if you forget/omit the extra "=" - it all




still
 compiles. Who knows when these erroneous constructs will bite at


 runtime?
 The first time it's run? After 1,000,000 executions? It's the Turing

 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and




!==,
 and
 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code? My suggestion is "is"



 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




avoid
 these
 errors.

 The only alternative that will save us from unknown numbers of




errors
 is
 to
 proscribe all porting and require everything to be written anew.



 (Sounds
 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Charles Sanders" <sanders-consulting comcast.net> writes:

 People will rightly say that D has fostered entirely new methods of
 writing invalid code.

I see what your saying but it seems only a problem when porting code.  I
agree that its very easy to overlook, but i dont see how 'is' will solve it,
u still have to hunt down all those instances and replace them.

C

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm9qvj$23dg$1 digitaldaemon.com...
 No. I'm saying that when porting code, i.e. copying C or C++ code (in)to

D,
 the translation of != and == to !== and === can be overlooked, and the
 compiler does nothing to help. Since porting code will feature large, this
 is a certain accident waiting to happen. To be honest, I'm not even sure
 that I've got every instance covered in the small amount of code I did
 yesterday. In principle it is impossible to guarantee that these errors

will
 not creep into arbitrarily large amounts of ported code, since one

operator
 is a lexical subset of the other, and both can be applied to some
 circumstance.

 For example (names are chosen for clarity in this case; they're not my
 naming convention), if I had some C++ code

 Object *object_ptr
 if(NULL != object_ptr)
 {
   object_ptr->SomeMethod();
 }

 Object &object_ref =
 if(0 != object_ref) /* Assuming Object is comparable with 0 */
 {
   object_ref.SomeMethod();
 }

 Now when I'm porting this to D, I do the following:

 - Replace NULL with null - this is 100% correctness-assured, since NULL is
 not recognised in D
 - Change all the pointers to D references - this is 100%

correctnes-assured,
 since D does not support ->, so we can replace all of those with ., and
 handle the syntax errors
 - Change all the C++ references to D references - I've not thought out

this
 completely, but I believe it's 100% correctness assured since D doesn't
 allows the C++ reference declaration notation
 - Try and change some of the != or == to !== and ===. I need to remember

to
 change the first one, and not the second one. In the two cases above, if I
 make no change to these operators the compiler is happy. However, the

first
 conditional now has a runtime error waiting to kill the process. This may
 come out in testing, or it may not. Proving that we've got it correct is
 theoretically impossible (a la Turing Halting problem), so here comes

la-la
 land. People will rightly say that D has fostered entirely new methods of
 writing invalid code.

 (The example may not be the best, as I'm not sure that D objects can be
 overloadedly comparable with integral values, but I think you get the

idea.)
 Is this clear? If it's not, I'll try again, because this is so important

we
 need to get a quorum of worried folks to badger Walter into changing it.
 Otherwise, D-knockers have got a big gun to shoot it with.


 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9nsa$1vcu$1 digitaldaemon.com...
 Im not sure what you mean actually, your saying that when wrapping the C
 code in extern () blocks that the pointer comparison has to be manually
 changed to === and !== , and that this causes a bunch of errors ?

 Admitedly
 I havent done any real porting so I dont have much of an argument other

 than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino


to
 get win32.lib easy to use, requiring alot of .def files and exports to


get
 it to work.  Right now the only way I can see to do it is for each .dll


,
 write a corresponding .def file that maps all the functions to ther
 _XXX (num) counterparts.  Is this really the only way ? This will take
 forever ... )

 Also congrats on the new column :D.

 C


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9mub$1u0b$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .  I


 would
 prefer if == and != could do the same thing, but if not I would much

 rather
 have an operator than 'is [of]'.  The operator helps maintain a




level
 of
 continuity.

 That's nice to know, ;), but you've not addressed my porting issue. Do


 you
 think it's wrong, or that I've overstated the case, or you're not
 interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers





requires
 translating ==/!= to ===/!==, whereas doing it for other types



 requires
 ==/!= be preserved. The compiler does *nothing* to help, since





it's
 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 still
 compiles. Who knows when these erroneous constructs will bite at


 runtime?
 The first time it's run? After 1,000,000 executions? It's the





Turing
 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and




 !==,
 and
 replace them with something that will not (or at least, less





easily)
 facilitate undetectable errors entering code? My suggestion is





"is"
 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 avoid
 these
 errors.

 The only alternative that will save us from unknown numbers of




 errors
 is
 to
 proscribe all porting and require everything to be written anew.



 (Sounds
 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Charles Sanders" <sanders-consulting comcast.net> writes:

After thinking about it and playing with it a little bit I agree === is a
disaster waiting to happen.  How about a new equality operator ?  Shall we
vote on it ?  Ive set up a poll at :
http://groups.yahoo.com/group/DigitalMD/surveys?id=11324569

C
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bm9tl3$279r$1 digitaldaemon.com...
 People will rightly say that D has fostered entirely new methods of
 writing invalid code.

 I see what your saying but it seems only a problem when porting code.  I
 agree that its very easy to overlook, but i dont see how 'is' will solve

it,
 u still have to hunt down all those instances and replace them.

 C

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9qvj$23dg$1 digitaldaemon.com...
 No. I'm saying that when porting code, i.e. copying C or C++ code (in)to

 D,
 the translation of != and == to !== and === can be overlooked, and the
 compiler does nothing to help. Since porting code will feature large,


this
 is a certain accident waiting to happen. To be honest, I'm not even sure
 that I've got every instance covered in the small amount of code I did
 yesterday. In principle it is impossible to guarantee that these errors

 will
 not creep into arbitrarily large amounts of ported code, since one

 operator
 is a lexical subset of the other, and both can be applied to some
 circumstance.

 For example (names are chosen for clarity in this case; they're not my
 naming convention), if I had some C++ code

 Object *object_ptr
 if(NULL != object_ptr)
 {
   object_ptr->SomeMethod();
 }

 Object &object_ref =
 if(0 != object_ref) /* Assuming Object is comparable with 0 */
 {
   object_ref.SomeMethod();
 }

 Now when I'm porting this to D, I do the following:

 - Replace NULL with null - this is 100% correctness-assured, since NULL


is
 not recognised in D
 - Change all the pointers to D references - this is 100%

 correctnes-assured,
 since D does not support ->, so we can replace all of those with ., and
 handle the syntax errors
 - Change all the C++ references to D references - I've not thought out

 this
 completely, but I believe it's 100% correctness assured since D doesn't
 allows the C++ reference declaration notation
 - Try and change some of the != or == to !== and ===. I need to remember

 to
 change the first one, and not the second one. In the two cases above, if


I
 make no change to these operators the compiler is happy. However, the

 first
 conditional now has a runtime error waiting to kill the process. This


may
 come out in testing, or it may not. Proving that we've got it correct is
 theoretically impossible (a la Turing Halting problem), so here comes

 la-la
 land. People will rightly say that D has fostered entirely new methods


of
 writing invalid code.

 (The example may not be the best, as I'm not sure that D objects can be
 overloadedly comparable with integral values, but I think you get the

 idea.)
 Is this clear? If it's not, I'll try again, because this is so important

 we
 need to get a quorum of worried folks to badger Walter into changing it.
 Otherwise, D-knockers have got a big gun to shoot it with.


 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9nsa$1vcu$1 digitaldaemon.com...
 Im not sure what you mean actually, your saying that when wrapping the



C
 code in extern () blocks that the pointer comparison has to be



manually
 changed to === and !== , and that this causes a bunch of errors ?

 Admitedly
 I havent done any real porting so I dont have much of an argument



other
 than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino


 to
 get win32.lib easy to use, requiring alot of .def files and exports to


 get
 it to work.  Right now the only way I can see to do it is for each



.dll
 ,
 write a corresponding .def file that maps all the functions to ther
 _XXX (num) counterparts.  Is this really the only way ? This will take
 forever ... )

 Also congrats on the new column :D.

 C


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9mub$1u0b$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .





I
 would
 prefer if == and != could do the same thing, but if not I would





much
 rather
 have an operator than 'is [of]'.  The operator helps maintain a




 level
 of
 continuity.

 That's nice to know, ;), but you've not addressed my porting issue.




Do
 you
 think it's wrong, or that I've overstated the case, or you're not
 interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers





 requires
 translating ==/!= to ===/!==, whereas doing it for other types



 requires
 ==/!= be preserved. The compiler does *nothing* to help, since





 it's
 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 still
 compiles. Who knows when these erroneous constructs will bite at


 runtime?
 The first time it's run? After 1,000,000 executions? It's the





 Turing
 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and




 !==,
 and
 replace them with something that will not (or at least, less





 easily)
 facilitate undetectable errors entering code? My suggestion is





 "is"
 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 avoid
 these
 errors.

 The only alternative that will save us from unknown numbers of




 errors
 is
 to
 proscribe all porting and require everything to be written anew.



 (Sounds
 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Matthew Wilson" <matthew stlsoft.org> writes:

Yes, as I said in another post, I've over-simplified the solution to this
very nasty problem.

The port-savvy approach would be for D to not use == and != (forget === and
!== for the moment), which clearly isn't a solution.

This is the stuff I really hate with languages that fake references from
real pointers.

I guess the solution is to create a C++ => D pre-porter, which finds all ==
and != and simply replaces them with some invalid character sequence. This
would then force the porter to examine each and every case. (Maybe I'll
write one to do it for a whole directory structure, using recls of course.
:) )

This really chews. Imagine all the bugs that are going to come in as a
result of this. :(


"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bm9tl3$279r$1 digitaldaemon.com...
 People will rightly say that D has fostered entirely new methods of
 writing invalid code.

 I see what your saying but it seems only a problem when porting code.  I
 agree that its very easy to overlook, but i dont see how 'is' will solve

it,
 u still have to hunt down all those instances and replace them.

 C

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9qvj$23dg$1 digitaldaemon.com...
 No. I'm saying that when porting code, i.e. copying C or C++ code (in)to

 D,
 the translation of != and == to !== and === can be overlooked, and the
 compiler does nothing to help. Since porting code will feature large,


this
 is a certain accident waiting to happen. To be honest, I'm not even sure
 that I've got every instance covered in the small amount of code I did
 yesterday. In principle it is impossible to guarantee that these errors

 will
 not creep into arbitrarily large amounts of ported code, since one

 operator
 is a lexical subset of the other, and both can be applied to some
 circumstance.

 For example (names are chosen for clarity in this case; they're not my
 naming convention), if I had some C++ code

 Object *object_ptr
 if(NULL != object_ptr)
 {
   object_ptr->SomeMethod();
 }

 Object &object_ref =
 if(0 != object_ref) /* Assuming Object is comparable with 0 */
 {
   object_ref.SomeMethod();
 }

 Now when I'm porting this to D, I do the following:

 - Replace NULL with null - this is 100% correctness-assured, since NULL


is
 not recognised in D
 - Change all the pointers to D references - this is 100%

 correctnes-assured,
 since D does not support ->, so we can replace all of those with ., and
 handle the syntax errors
 - Change all the C++ references to D references - I've not thought out

 this
 completely, but I believe it's 100% correctness assured since D doesn't
 allows the C++ reference declaration notation
 - Try and change some of the != or == to !== and ===. I need to remember

 to
 change the first one, and not the second one. In the two cases above, if


I
 make no change to these operators the compiler is happy. However, the

 first
 conditional now has a runtime error waiting to kill the process. This


may
 come out in testing, or it may not. Proving that we've got it correct is
 theoretically impossible (a la Turing Halting problem), so here comes

 la-la
 land. People will rightly say that D has fostered entirely new methods


of
 writing invalid code.

 (The example may not be the best, as I'm not sure that D objects can be
 overloadedly comparable with integral values, but I think you get the

 idea.)
 Is this clear? If it's not, I'll try again, because this is so important

 we
 need to get a quorum of worried folks to badger Walter into changing it.
 Otherwise, D-knockers have got a big gun to shoot it with.


 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9nsa$1vcu$1 digitaldaemon.com...
 Im not sure what you mean actually, your saying that when wrapping the



C
 code in extern () blocks that the pointer comparison has to be



manually
 changed to === and !== , and that this causes a bunch of errors ?

 Admitedly
 I havent done any real porting so I dont have much of an argument



other
 than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino


 to
 get win32.lib easy to use, requiring alot of .def files and exports to


 get
 it to work.  Right now the only way I can see to do it is for each



.dll
 ,
 write a corresponding .def file that maps all the functions to ther
 _XXX (num) counterparts.  Is this really the only way ? This will take
 forever ... )

 Also congrats on the new column :D.

 C


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9mub$1u0b$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .





I
 would
 prefer if == and != could do the same thing, but if not I would





much
 rather
 have an operator than 'is [of]'.  The operator helps maintain a




 level
 of
 continuity.

 That's nice to know, ;), but you've not addressed my porting issue.




Do
 you
 think it's wrong, or that I've overstated the case, or you're not
 interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers





 requires
 translating ==/!= to ===/!==, whereas doing it for other types



 requires
 ==/!= be preserved. The compiler does *nothing* to help, since





 it's
 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 still
 compiles. Who knows when these erroneous constructs will bite at


 runtime?
 The first time it's run? After 1,000,000 executions? It's the





 Turing
 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and




 !==,
 and
 replace them with something that will not (or at least, less





 easily)
 facilitate undetectable errors entering code? My suggestion is





 "is"
 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 avoid
 these
 errors.

 The only alternative that will save us from unknown numbers of




 errors
 is
 to
 proscribe all porting and require everything to be written anew.



 (Sounds
 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Ben Hinkle" <bhinkle4 juno.com> writes:

Wow. I didn't realize != didn't accept nulls. I'm so used to writing "!=

be error prone and annoying. Why not keep C's defn of == and != and instead
do what Java did and make another "deep equals" operator or function?
I can see how in principle D's current definition of == and === make sense
and are nice, but the reality is that many many people will be switching
back and forth between C (and the other C-like languages) and D and this
will be a nasty "gochta".

In terms of worrying about == for "Object *obj" vs "Object &obj"... that
doens't bother me as much since porting "Object &obj" to D requires special
attention anyway.

-Ben

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm9qvj$23dg$1 digitaldaemon.com...
 No. I'm saying that when porting code, i.e. copying C or C++ code (in)to

D,
 the translation of != and == to !== and === can be overlooked, and the
 compiler does nothing to help. Since porting code will feature large, this
 is a certain accident waiting to happen. To be honest, I'm not even sure
 that I've got every instance covered in the small amount of code I did
 yesterday. In principle it is impossible to guarantee that these errors

will
 not creep into arbitrarily large amounts of ported code, since one

operator
 is a lexical subset of the other, and both can be applied to some
 circumstance.

 For example (names are chosen for clarity in this case; they're not my
 naming convention), if I had some C++ code

 Object *object_ptr
 if(NULL != object_ptr)
 {
   object_ptr->SomeMethod();
 }

 Object &object_ref =
 if(0 != object_ref) /* Assuming Object is comparable with 0 */
 {
   object_ref.SomeMethod();
 }

 Now when I'm porting this to D, I do the following:

 - Replace NULL with null - this is 100% correctness-assured, since NULL is
 not recognised in D
 - Change all the pointers to D references - this is 100%

correctnes-assured,
 since D does not support ->, so we can replace all of those with ., and
 handle the syntax errors
 - Change all the C++ references to D references - I've not thought out

this
 completely, but I believe it's 100% correctness assured since D doesn't
 allows the C++ reference declaration notation
 - Try and change some of the != or == to !== and ===. I need to remember

to
 change the first one, and not the second one. In the two cases above, if I
 make no change to these operators the compiler is happy. However, the

first
 conditional now has a runtime error waiting to kill the process. This may
 come out in testing, or it may not. Proving that we've got it correct is
 theoretically impossible (a la Turing Halting problem), so here comes

la-la
 land. People will rightly say that D has fostered entirely new methods of
 writing invalid code.

 (The example may not be the best, as I'm not sure that D objects can be
 overloadedly comparable with integral values, but I think you get the

idea.)
 Is this clear? If it's not, I'll try again, because this is so important

we
 need to get a quorum of worried folks to badger Walter into changing it.
 Otherwise, D-knockers have got a big gun to shoot it with.


 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9nsa$1vcu$1 digitaldaemon.com...
 Im not sure what you mean actually, your saying that when wrapping the C
 code in extern () blocks that the pointer comparison has to be manually
 changed to === and !== , and that this causes a bunch of errors ?

 Admitedly
 I havent done any real porting so I dont have much of an argument other

 than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino


to
 get win32.lib easy to use, requiring alot of .def files and exports to


get
 it to work.  Right now the only way I can see to do it is for each .dll


,
 write a corresponding .def file that maps all the functions to ther
 _XXX (num) counterparts.  Is this really the only way ? This will take
 forever ... )

 Also congrats on the new column :D.

 C


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm9mub$1u0b$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bm9hl9$1n09$1 digitaldaemon.com...
 I know im going againts popular opinion here but i like the === .  I


 would
 prefer if == and != could do the same thing, but if not I would much

 rather
 have an operator than 'is [of]'.  The operator helps maintain a




level
 of
 continuity.

 That's nice to know, ;), but you've not addressed my porting issue. Do


 you
 think it's wrong, or that I've overstated the case, or you're not
 interested?


 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Porting code from C/C++ is a minefield. Comparing pointers





requires
 translating ==/!= to ===/!==, whereas doing it for other types



 requires
 ==/!= be preserved. The compiler does *nothing* to help, since





it's
 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 still
 compiles. Who knows when these erroneous constructs will bite at


 runtime?
 The first time it's run? After 1,000,000 executions? It's the





Turing
 Halting
 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and




 !==,
 and
 replace them with something that will not (or at least, less





easily)
 facilitate undetectable errors entering code? My suggestion is





"is"
 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 avoid
 these
 errors.

 The only alternative that will save us from unknown numbers of




 errors
 is
 to
 proscribe all porting and require everything to be written anew.



 (Sounds
 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie

"Hauke Duden" <H.NS.Duden gmx.net> writes:

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:bmblju$1fss$1 digitaldaemon.com...
 Wow. I didn't realize != didn't accept nulls. I'm so used to writing "!=


would
 be error prone and annoying.

Hmmm. If this only applies to comparisons with null, then there would be a
simple solution. Since "== null" will always cause a crash if the ==
operator is implemented according to spec, the compiler could make this
statement illegal and produce a compiler error. So this particular issue
could be circumvented.

This won't solve the problem of comparison with a non-constant object
reference that has a null value, but I think such cases are less critical.

If "== null" were invalid and the === operator would be renamed to "is",
then I think the readability and error safety would be improved a lot.

Btw: has Walter ever commented on renaming the === operator? This issue
keeps coming up and I don't remember him ever stating his opinion on this
matter.

Hauke

Patrick Down <pat codemoon.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in
news:bm7c3d$1pqi$1 digitaldaemon.com: 

 Porting code from C/C++ is a minefield. Comparing pointers requires
 translating ==/!= to ===/!==, whereas doing it for other types
 requires ==/!= be preserved. The compiler does *nothing* to help,
 since it's quite happy with the syntax if you forget/omit the extra
 "=" - it all still compiles. Who knows when these erroneous constructs
 will bite at runtime? The first time it's run? After 1,000,000
 executions? It's the Turing Halting problem, and its' NP.
 
 Please, please, please, please, please can we get rid of === and !==,
 and replace them with something that will not (or at least, less
 easily) facilitate undetectable errors entering code? My suggestion is
 "is" and "is not", but I'm not particularly stuck on that. Anything
 that will avoid these errors.
 
 The only alternative that will save us from unknown numbers of errors
 is to proscribe all porting and require everything to be written anew.
 (Sounds of myriad potential doors slamming ...)
 
 Yours portentously
 
 Freddie

While I'm all in favor of replacing === with 'is', I'm not quite sure 
how this is going to help your porting problem.  It still seems like you
are stuck with a case by case decision of replacing == with 'is'.

"Matthew Wilson" <matthew stlsoft.org> writes:

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns94119FB75D346patcodemooncom 63.105.9.61...
 "Matthew Wilson" <matthew stlsoft.org> wrote in
 news:bm7c3d$1pqi$1 digitaldaemon.com:

 Porting code from C/C++ is a minefield. Comparing pointers requires
 translating ==/!= to ===/!==, whereas doing it for other types
 requires ==/!= be preserved. The compiler does *nothing* to help,
 since it's quite happy with the syntax if you forget/omit the extra
 "=" - it all still compiles. Who knows when these erroneous constructs
 will bite at runtime? The first time it's run? After 1,000,000
 executions? It's the Turing Halting problem, and its' NP.

 Please, please, please, please, please can we get rid of === and !==,
 and replace them with something that will not (or at least, less
 easily) facilitate undetectable errors entering code? My suggestion is
 "is" and "is not", but I'm not particularly stuck on that. Anything
 that will avoid these errors.

 The only alternative that will save us from unknown numbers of errors
 is to proscribe all porting and require everything to be written anew.
 (Sounds of myriad potential doors slamming ...)

 Yours portentously

 Freddie

 While I'm all in favor of replacing === with 'is', I'm not quite sure
 how this is going to help your porting problem.  It still seems like you
 are stuck with a case by case decision of replacing == with 'is'.

Gah! You're right. What a dumbo! <blush>

So it's all so much more hideous than I was thinking.

I'm going to skulk in a corner until I can think of a solution. I may be
some time ...

"Vathix" <vathix dprogramming.com> writes:

 While I'm all in favor of replacing === with 'is', I'm not quite sure
 how this is going to help your porting problem.  It still seems like you
 are stuck with a case by case decision of replacing == with 'is'.

 Gah! You're right. What a dumbo! <blush>

 So it's all so much more hideous than I was thinking.

 I'm going to skulk in a corner until I can think of a solution. I may be
 some time ...

If your C/C++ code uses pointers, why don't you use pointers in D? Leave the
D stuff to code specifically for D.

Patrick Down <pat codemoon.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in
news:bm9r94$23qu$1 digitaldaemon.com: 

 
 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns94119FB75D346patcodemooncom 63.105.9.61...
 
 Gah! You're right. What a dumbo! <blush>
 
 So it's all so much more hideous than I was thinking.
 
 I'm going to skulk in a corner until I can think of a solution. I may
 be some time ...

I think it is wrong to burden the language
with a lot of features that make easier to
port to it or connect it to C libraries.  I
really think that tools should be created
to help with these types of problems.

A header file translator could create wrapper
functions that deal with string issues.

A D lint like program could look for problem
areas in C to D ports.