www.digitalmars.com         C & C++   DMDScript  

D - Implicit casting

reply Sark7 <sark7 mail333.com> writes:
I think that implicit casting from greater space to lesser space should be 
not allowed, because imho it isn't logically correct.

for example:

unit -> int  // ok
int  -> uin  // error

float -> double // ok
double -> float // error

int   -> float // ok
float -> int   // error

--
Sark7
Feb 23 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I couldn't agree more


"Sark7" <sark7 mail333.com> wrote in message
news:opr3ux0xcvut8jae news.digitalmars.com...

 I think that implicit casting from greater space to lesser space should be
 not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok
 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

 --
 Sark7
Feb 23 2004
parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Tue, 24 Feb 2004 15:58:24 +1100 (02/24/04 15:58:24)
, Matthew <matthew.hat stlsoft.dot.org> wrote:


 I couldn't agree more


 "Sark7" <sark7 mail333.com> wrote in message
 news:opr3ux0xcvut8jae news.digitalmars.com...

 I think that implicit casting from greater space to lesser space should 
 be
 not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok
 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

 --
 Sark7




At the very least, a warning message would be nice. The general principle 
being that if a implicit cast can possibly cause loss of information at 
run-time, then the coder should be made aware of it.

Excuse my ignorance, but what about the case where two floats are 
multiplied and the result assigned to a third float. Does D cause the 
first two floats to be promoted to a double such that the calculated 
product (temporary result) is a double prior to being assigned to storage?

   float a,b, c;

    a = 12.3456789012;
    b = 23.4567890123;
    c = a * b;

-- 
Derek




-- 
Derek
Feb 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Derek Parnell" <Derek.Parnell Psyc.ward> wrote in message
news:opr3u0mvnhdeu3pf news.digitalmars.com...

 On Tue, 24 Feb 2004 15:58:24 +1100 (02/24/04 15:58:24)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 I couldn't agree more


 "Sark7" <sark7 mail333.com> wrote in message
 news:opr3ux0xcvut8jae news.digitalmars.com...

 I think that implicit casting from greater space to lesser space should
 be
 not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok
 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

 --
 Sark7




 At the very least, a warning message would be nice. The general principle
 being that if a implicit cast can possibly cause loss of information at
 run-time, then the coder should be made aware of it.

 Excuse my ignorance, but what about the case where two floats are
 multiplied and the result assigned to a third float. Does D cause the
 first two floats to be promoted to a double such that the calculated
 product (temporary result) is a double prior to being assigned to storage?

    float a,b, c;

     a = 12.3456789012;
     b = 23.4567890123;
     c = a * b;


I would expect that to be the case, but I don't know
Feb 23 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


multiplied and the result assigned to a third float. Does D cause the
first two floats to be promoted to a double such that the calculated
product (temporary result) is a double prior to being assigned to storage?

   float a,b, c;

    a = 12.3456789012;
    b = 23.4567890123;
    c = a * b;
    


I would expect that to be the case, but I don't know
  


That would be a very bad idea performance wise, unless the calculation 
is a compile time one (like would be possible with the example given).

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
prev sibling next sibling parent reply Juan C <Juan_member pathlink.com> writes:
In article <opr3ux0xcvut8jae news.digitalmars.com>, Sark7 says...

I think that implicit casting from greater space to lesser space should be 
not allowed, because imho it isn't logically correct.

for example:

unit -> int  // ok
int  -> uin  // error

float -> double // ok
double -> float // error

int   -> float // ok
float -> int   // error

--
Sark7


I thought that was already true.
Feb 23 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Juan C wrote:


 I thought that was already true.


But why do you think that this is true? May I cite a recent posting of
yours?:

| [...] the language shouldn't prevent the user from making errors.

I cannot find anything illegal in casting into lesser space in that case,
that the actual source value fits into the range of the target type.

So long.
Feb 24 2004
prev sibling next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Sark7 wrote:

[...]

 imho it isn't logically correct.


That depends on the logic you want to use. Why should it be "logically
incorrect" to implicitly cast from a type with fine resolution, small
range of values and much space to a type with coarser resolution, broader
range of values and less space?

[...]

 unit -> int  // ok
 int  -> uin  // error


[...]

If you mean `uint' and `int' here, then why should it be "logically
correct" to implicitly cast an actual value of `int.max + 1', which can be
hold by an `uint', to an `int'?

So long.
Feb 24 2004
prev sibling next sibling parent Steve Adams <adamss ascinet.com> writes:
Sark7 wrote:

 I think that implicit casting from greater space to lesser space should 
 be not allowed, because imho it isn't logically correct.
 
 for example:
 
 unit -> int  // ok
 int  -> uin  // error
 
 float -> double // ok
 double -> float // error
 
 int   -> float // ok
 float -> int   // error
 
 -- 
 Sark7


I agree.
Feb 24 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Sark7 wrote:


 I think that implicit casting from greater space to lesser space 
 should be not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok


But uint's can be greater then int's.  I don't think either should be 
allowed without a cast.


 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error


I think float/double to int should also have a forced cast.  Most of the 
time you are using floating point for calculations that need the 
fraction part and accidental conversion to int can be a real problem.

However, I think these things are to late to change now, it's kinda 
engrained in D now and would cause to many changes in stuff that is 
already written.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
parent reply larry cowan <larry_member pathlink.com> writes:
An important point is that implicit casting where it's not guaranteed to be safe
is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
TIME.

It should be reconsidered whether or not it breaks Phobos or other projects
developed or in-work.  Explicit casting need not have such limitations - it can
be searched for and any problems can be dealt with.  The correction of the
limited amount of long-term current code can be fixed by explicit casting when
the compiler starts rejecting it.

-larry

In article <c1g43k$11he$1 digitaldaemon.com>, J Anderson says...

Sark7 wrote:


 I think that implicit casting from greater space to lesser space 
 should be not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok


But uint's can be greater then int's.  I don't think either should be 
allowed without a cast.


 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error


I think float/double to int should also have a forced cast.  Most of the 
time you are using floating point for calculations that need the 
fraction part and accidental conversion to int can be a real problem.

However, I think these things are to late to change now, it's kinda 
engrained in D now and would cause to many changes in stuff that is 
already written.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Just playing devils advocate:

larry cowan wrote:


An important point is that implicit casting where it's not guaranteed to be safe
is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
TIME.
  


I think this *feature* could be argued both ways, so IMHO I think it is 
best to stick with what we have at the moment.


It should be reconsidered whether or not it breaks Phobos or other projects
developed or in-work.  Explicit casting need not have such limitations - it can
be searched for and any problems can be dealt with.  The correction of the
limited amount of long-term current code can be fixed by explicit casting when
the compiler starts rejecting it.
  


It's difficult to grep and therefore in most cases would have to be done 
by hand.  However its merits should be considered of course.


-larry
  


-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
next sibling parent larry cowaqn <larry_member pathlink.com> writes:
In article <c1g8fi$1978$1 digitaldaemon.com>, J Anderson says...

Just playing devils advocate:

larry cowan wrote:


An important point is that implicit casting where it's not guaranteed to be safe
is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
TIME.
  


I think this *feature* could be argued both ways, so IMHO I think it is 
best to stick with what we have at the moment.


I understand, but like I mentioned, it's easy to include in the spec now,
valuable, and need not be included in the 1.0 compiler which will have errors if
only in things we haven't found yet.  It should be considered on its merits.


It should be reconsidered whether or not it breaks Phobos or other projects
developed or in-work.  Explicit casting need not have such limitations - it can
be searched for and any problems can be dealt with.  The correction of the
limited amount of long-term current code can be fixed by explicit casting when
the compiler starts rejecting it.
  


It's difficult to grep and therefore in most cases would have to be done 
by hand.  However its merits should be considered of course.


As far as grepping for explicit casts, it needs only anything with reasonable
re-like acceptance, and could be either for 'cast' or 'cast\s*\(float\s*\**\)'
or some such.  If grep wouldn't find what you wanted, a simple perl program
could scan the code.


-larry
  


-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:

 Just playing devils advocate:
 
 larry cowan wrote:
 

 An important point is that implicit casting where it's not guaranteed 
 to be safe
 is DANGEROUS.

 And especially in large systems of code and in later maintenance changes.




[...]

 It's difficult to grep and therefore in most cases would have to be done 
 by hand.  However its merits should be considered of course.


I think it'd be impossible to grep, but at least the compiler error 
messages should point to the code that needs correcting. I'm not sure if 
it needs changing, but if something this fundamental is going to be 
changed, now is our opportunity to make the change. Pretty soon, the 
door will close on that chance.

D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
change here once it does arrive.


-- 
Justin
http://jcc_7.tripod.com/d/
Feb 24 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not sure 
 if it needs changing, but if something this fundamental is going to be 
 changed, now is our opportunity to make the change. Pretty soon, the 
 door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.



With my other hat:

It is something I like from C++ with all warnings (maximum level) as 
errors set.  Actually I think that just about all c++ warnings (maximum 
level) should become errors in D.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
next sibling parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
, J Anderson <REMOVEanderson badmama.com.au> wrote:


 J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not sure 
 if it needs changing, but if something this fundamental is going to be 
 changed, now is our opportunity to make the change. Pretty soon, the 
 door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.



 With my other hat:

 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings (maximum 
 level) should become errors in D.


Doesn't an error imply that D cannot continue compiling, whereas a warning 
means that D can continue but the results may not be what the coder 
expects.

A *potential* loss of data due to implicit cast conversions would 
therefore only warrant a warning at best, as D can continue compiling.

-- 
Derek


-- 
Derek
Feb 24 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Derek Parnell wrote:


 On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
 , J Anderson <REMOVEanderson badmama.com.au> wrote:
 

 J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not sure 
 if it needs changing, but if something this fundamental is going to 
 be changed, now is our opportunity to make the change. Pretty soon, 
 the door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.




 With my other hat:

 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings 
 (maximum level) should become errors in D.


 
 Doesn't an error imply that D cannot continue compiling, whereas a 
 warning means that D can continue but the results may not be what the 
 coder expects.
 
 A *potential* loss of data due to implicit cast conversions would 
 therefore only warrant a warning at best, as D can continue compiling.
 


Walter is philosophically against warnings and I think he's right. The 
idea is if it's alarming enough to warn about, compilation should stop 
and it should be fixed.


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

Under "Who D is For":
People who compile with maximum warning levels turned on and who 
instruct the compiler to treat warnings as errors.

Under "No Warnings":
D compilers will not generate warnings for questionable code. Code will 
either be acceptable to the compiler or it will not be. This will 
eliminate any debate about which warnings are valid errors and which are 
not, and any debate about what to do with them. The need for compiler 
warnings is symptomatic of poor language design.

-- 
Justin
http://jcc_7.tripod.com/d/
Feb 24 2004
parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Tue, 24 Feb 2004 19:36:16 -0600 (02/25/04 12:36:16)
, J C Calvarese <jcc7 cox.net> wrote:


 Derek Parnell wrote:


 On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
 , J Anderson <REMOVEanderson badmama.com.au> wrote:


 J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not sure 
 if it needs changing, but if something this fundamental is going to 
 be changed, now is our opportunity to make the change. Pretty soon, 
 the door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.




 With my other hat:

 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings 
 (maximum level) should become errors in D.


 Doesn't an error imply that D cannot continue compiling, whereas a 
 warning means that D can continue but the results may not be what the 
 coder expects.

 A *potential* loss of data due to implicit cast conversions would 
 therefore only warrant a warning at best, as D can continue compiling.


 Walter is philosophically against warnings and I think he's right. The 
 idea is if it's alarming enough to warn about, compilation should stop 
 and it should be fixed.


Okay, thanks for that. I guess my point was regardless of what you call 
these messages, warnings or errors, it is often useful to continue 
compiling in some cases so that as many messages as possible are produced 
per compilation run. This allows coders to correct many problems before 
resubmitting to compilation.

I too don't really care if a message is classified as an error or warning, 
it still needs to be fixed up. What I do care about is being effecient in 
my work practices so I can keep costs down. And any reductions in the 
analyse-edit-compile-test loop are welcome.

-- 
Derek
Feb 24 2004
parent reply C <dont respond.com> writes:
Thats interesting, I take a different approach. Write 5 - 10 lines, =

compile, fix the errors which is usually minimal.  PCH and faster machin=
es =

make this possible ( unless your using GCC :/ ) to be really effecient, =

and I almost never have to debug.

C

On Wed, 25 Feb 2004 13:02:11 +1100, Derek Parnell =

<Derek.Parnell Psyc.ward> wrote:


 On Tue, 24 Feb 2004 19:36:16 -0600 (02/25/04 12:36:16)
 , J C Calvarese <jcc7 cox.net> wrote:


 Derek Parnell wrote:


 On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
 , J Anderson <REMOVEanderson badmama.com.au> wrote:


 J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler erro=










r =


 messages should point to the code that needs correcting. I'm not =











 sure if it needs changing, but if something this fundamental is =











 going to be changed, now is our opportunity to make the change. =











 Pretty soon, the door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a=










 =


 change here once it does arrive.




 With my other hat:

 It is something I like from C++ with all warnings (maximum level) a=








s =


 errors set.  Actually I think that just about all c++ warnings =









 (maximum level) should become errors in D.


 Doesn't an error imply that D cannot continue compiling, whereas a =







 warning means that D can continue but the results may not be what th=






e =


 coder expects.

 A *potential* loss of data due to implicit cast conversions would =







 therefore only warrant a warning at best, as D can continue compilin=






g.


 Walter is philosophically against warnings and I think he's right. Th=




e =


 idea is if it's alarming enough to warn about, compilation should sto=




p =


 and it should be fixed.


 Okay, thanks for that. I guess my point was regardless of what you cal=


l =


 these messages, warnings or errors, it is often useful to continue =



 compiling in some cases so that as many messages as possible are =



 produced per compilation run. This allows coders to correct many =



 problems before resubmitting to compilation.

 I too don't really care if a message is classified as an error or =



 warning, it still needs to be fixed up. What I do care about is being =



 effecient in my work practices so I can keep costs down. And any =



 reductions in the analyse-edit-compile-test loop are welcome.




-- =

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



 Feb 24 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


C wrote:


 Thats interesting, I take a different approach. Write 5 - 10 lines, 
 compile, fix the errors which is usually minimal.  PCH and faster 
 machines make this possible ( unless your using GCC :/ ) to be really 
 effecient, and I almost never have to debug.

 C


When you get a large program, it can take even hours to compile.  Often 
the machines are setup make a recompile overnight and you hand the error 
messages over to the appropriate people the next day.  Adding unit 
testing to that and it can get really big.

Of course you can reduce compile time by chopping it up into libraries 
but you still can have long compile times.

I find programming a heap and then compiling is much more efficient then 
being a trigger happy coder.  Even the pressing of F5 and looking to see 
if there is error messages is a slow down.  It's also faster to fix 10 
of the same types of errors in one go then one error 10 times.  Fast 
coding is what it is about otherwise you get less done.

-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



  parent reply larry cowan <larry_member pathlink.com>  writes:


In article <c1h5j8$2t80$1 digitaldaemon.com>, J Anderson says...

C wrote:


 Thats interesting, I take a different approach. Write 5 - 10 lines, 
 compile, fix the errors which is usually minimal.  PCH and faster 
 machines make this possible ( unless your using GCC :/ ) to be really 
 effecient, and I almost never have to debug.

 C


When you get a large program, it can take even hours to compile.  Often 
the machines are setup make a recompile overnight and you hand the error 
messages over to the appropriate people the next day.  Adding unit 
testing to that and it can get really big.

Of course you can reduce compile time by chopping it up into libraries 
but you still can have long compile times.

I find programming a heap and then compiling is much more efficient then 
being a trigger happy coder.  Even the pressing of F5 and looking to see 
if there is error messages is a slow down.  It's also faster to fix 10 
of the same types of errors in one go then one error 10 times.  Fast 
coding is what it is about otherwise you get less done.

-- 
-Anderson: http://badmama.com.au/~anderson/


Don't you have a dev platform that you can at least compile individual modules
locally before putting them in to a huge build you might break?  If its that big
there must be a lot of people with the potential for breaking it with a dumb
error once a month each.

While I would like the compiler to go as far as it can do so effectively,
spitting out 10 identical errors is not very useful - there will be a quitting
point somewhere that may not be the last occurrence.  Searching for more
instances of the same error or context when you see one errmsg (or at least if
you see more than one) may not be a lot of fun, but it usually can be done.  If
you don't code a horrendous amount before checking (locally) you probably know
when you see the first occurrence whether there are potentially more of the same
- and you won't continue coding additional ones.

Getting lots done is great, but getting lots done right is more to the point.

Anyway, you don't program systems, you program modules - which is what unit
testing is all about.  If every module works right, getting the system to work
right is much easier.



 Feb 24 2004



  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


larry cowan wrote:


While I would like the compiler to go as far as it can do so effectively,
spitting out 10 identical errors is not very useful - there will be a quitting
point somewhere that may not be the last occurrence.  Searching for more
  


You would only look at the first 2 or 3 out of the 10. Search-replace 
all occuraces and then to the rest, but my point is, my mind at least is 
in error termination mode when I'm doing this.  I used to be a trigger 
happy programmer but that that was only at the beginning when learning 
the language.


instances of the same error or context when you see one errmsg (or at least if
you see more than one) may not be a lot of fun, but it usually can be done.  If
you don't code a horrendous amount before checking (locally) you probably know
when you see the first occurrence whether there are potentially more of the same
- and you won't continue coding additional ones.
  


IMHO

How many lines of code (on average) do you know you can program without 
error?  IMHO This is how many you should write before checking.  I don't 
code up the entire program just each algorithm, get it right and then 
test it in once go.  Otherwise I need to generate a lot more debugging 
(which gets scrapped latter on).  Also I always try to complete the 
algorithm before leaving so I know what's new.  I think as I get better, 
I'll need to check even less and to be able to program more with less 
checking intervals.  It's like spell checking, when typing you don't 
spell check till after you've finished (Yes. I'm still guilty of 
checking every paragraph rather then the entire document at the end).  
If you stop at every spelling mistake, you can't go as fast.  Then you 
re-read it and make sure the draft you've typed is correct. 

Anyhow, I guess I'm a top-down programmer and your a bottom up.  There 
are pros and cons of both, so I guess there's no right answer.

-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



  parent reply "Carlos Santander B." <carlos8294 msn.com>  writes:


J Anderson wrote:

 ...
 and to be able to program more with less checking intervals.  It's
 like spell checking, when typing you don't spell check till after
 you've finished (Yes. I'm still guilty of checking every paragraph
 rather then the entire document at the end). If you stop at every
 spelling mistake, you can't go as fast.  Then you re-read it and
 make sure the draft you've typed is correct.
 ...


Humbly (sp?), I can say I don't make spelling mistakes in Spanish. But every
time I doubt about a word, I check how I wrote it. Now, that happens in
about one or two words each page. If that's too when programming, then when
someone really masters programming, s/he would write hundreds of lines of
code and just stops to check one line here or there? Eventually could go as
far as doing an entire module just compiling at the end? I'd like to know if
there's someone who can really do that.

-----------------------
Carlos Santander Bernal



 Feb 27 2004



  parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


Carlos Santander B. wrote:


J Anderson wrote:
  


...
and to be able to program more with less checking intervals.  It's
like spell checking, when typing you don't spell check till after
you've finished (Yes. I'm still guilty of checking every paragraph
rather then the entire document at the end). If you stop at every
spelling mistake, you can't go as fast.  Then you re-read it and
make sure the draft you've typed is correct.
...
    


Humbly (sp?), I can say I don't make spelling mistakes in Spanish. But every
time I doubt about a word, I check how I wrote it. Now, that happens in
about one or two words each page. If that's too when programming, then when
someone really masters programming, s/he would write hundreds of lines of
code and just stops to check one line here or there? 

  


Generally I use something like rational rose (C++) to build the module, 
then I just need to fill in the blanks.  Things like getters/setters are 
easily filled in without any checking.  The real meat is the difficult 
(which is a relative term) algorithms. Often I just write out what I'm 
going to do in comment form then fill in all the blanks, this includes 
any sub-routines.  Once that's done then I compile (and might-run if 
there's no mistake).  These algorithms are usually a couple of 100 
lines.  Of course the algorithms generally aren't fully semanticly 
correct, but because the entire algorithm is there I can see the bigger 
picture in my head better.

My period between running and testing the algorithms can be much longer 
then the syntactical correction, particularly because many of my 
algorithm require a couple of minutes (or hours) to run.

But that's just my style, you might find something else works for you.


Eventually could go as
far as doing an entire module just compiling at the end? I'd like to know if
there's someone who can really do that.


Personally, I wouldn't go that far. I would work on a theme in the 
module and get that working before checking. I would only do as much as 
I can comprehend and only in one sitting.  Sometimes that means 
compiling after a few lines but more generally a few hundred.  I 
generally try to make sure everything is working (that I was working) 
before I leave a sit-in because I know if I go away I'll forget something.


-----------------------
Carlos Santander Bernal
  


-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 27 2004



prev sibling  parent  Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Tue, 24 Feb 2004 21:36:45 -0800 (02/25/04 16:36:45)
, C <dont respond.com> wrote:


 Thats interesting, I take a different approach. Write 5 - 10 lines, 
 compile, fix the errors which is usually minimal.  PCH and faster 
 machines make this possible ( unless your using GCC :/ ) to be really 
 effecient, and I almost never have to debug.

 C

 On Wed, 25 Feb 2004 13:02:11 +1100, Derek Parnell 
 <Derek.Parnell Psyc.ward> wrote:


[snip]


 I too don't really care if a message is classified as an error or 
 warning, it still needs to be fixed up. What I do care about is being 
 effecient in my work practices so I can keep costs down. And any 
 reductions in the analyse-edit-compile-test loop are welcome.




I agree. That too is how I tend to work nowadays, based on the theory that 
any new errors are most likely to be in the lines just add or changed. But 
the principle about reducing the cost of development still applies.

And there are still those times when a one line change can now cause a 
ripple of errors in code that was written months ago ;-)

-- 
Derek



 Feb 24 2004



prev sibling  parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


Derek Parnell wrote:


 On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
 , J Anderson <REMOVEanderson badmama.com.au> wrote:


 J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not 
 sure if it needs changing, but if something this fundamental is 
 going to be changed, now is our opportunity to make the change. 
 Pretty soon, the door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.




 With my other hat:

 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings 
 (maximum level) should become errors in D.


 Doesn't an error imply that D cannot continue compiling, whereas a 
 warning means that D can continue but the results may not be what the 
 coder expects.


I don't even know if D has any warning messages. Walter hates them (as 
do I).


 A *potential* loss of data due to implicit cast conversions would 
 therefore only warrant a warning at best, as D can continue compiling.



I think it should be an *error* because you can always cast your way out 
of it.  Casting is like telling the compiler, I know what I'm doing.  
The reason I have treat errors as warnings in C++ is that every warning 
I've come across I've been able to deal with.

IMHO If you have warnings you asking for trouble because people just 
ignore them.  I've seen peoples programs with hundreds of warnings 
because people can't be bothered fixing them.  If you say, well I'm not 
lazy, then making warnings into error messages won't make life harder 
anyway.  When I bug arrives it is normally because of one of the 
warnings.  Warnings are bad because they don't force the people to use them.

Since all warnings can be explicitly ignored they should be errors not 
warnings.

So:
Warnings -> Bad
The warning messages from C++ made into errors in D -> good.

If you argue that warnings are different then errors, then half the D's 
error messages should become warnings (and then it wouldn't be strongly 
typed).  There is little no reason why there should be warnings at all, 
just more errors to help the programmer out.

-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net>  writes:


J Anderson wrote:

 J C Calvarese wrote:
 

 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not sure 
 if it needs changing, but if something this fundamental is going to be 
 changed, now is our opportunity to make the change. Pretty soon, the 
 door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.


 
 With my other hat:
 
 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings (maximum 
 level) should become errors in D.


If Walter doesn't see these implicit casts as a problem, it's possible 
that a clever D programmer can create a program to check that the 
variables aren't being implicitly cast in the ways that the OP was 
concerned about. It sounds like a very ambitious task to me, but I 
suppose it's possible.

Another check that could be helpful: ensuring that every swtich has a 
default case (no one likes pesky runtime errors) BEFORE compilation. If 
the cases are susposed to be specified, it could be "default: 
assert(0);". If unspecified cases are permitted, it could be default: 
break;". Walter seems to be unwavering on this controversial issue, but 
I think this would be an easier thing to check for.

Just thinking outloud...

-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 24 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


J C Calvarese wrote:


 If Walter doesn't see these implicit casts as a problem, it's possible 
 that a clever D programmer can create a program to check that the 
 variables aren't being implicitly cast in the ways that the OP was 
 concerned about. It sounds like a very ambitious task to me, but I 
 suppose it's possible.



It's passing the buck. I mean, it would be much easier (for just about 
everyone) to have it in the main program.  Having a separate checker 
program is just as bad as warnings. 

You can get really good checker programmers that pick up allot of 
might-be-errors that could never be real errors, but for trivial things 
like this, it should be an error in the compiler.


 Another check that could be helpful: ensuring that every swtich has a 
 default case (no one likes pesky runtime errors) BEFORE compilation. 
 If the cases are susposed to be specified, it could be "default: 
 assert(0);". If unspecified cases are permitted, it could be default: 
 break;". Walter seems to be unwavering on this controversial issue, 
 but I think this would be an easier thing to check for.

 Just thinking outloud...



Check everything I say.  I've met that many programmers who leave 
warning messages in C++ (because they can't be bothered working out how 
to fix them) and found that their problem was exactly as the warning 
message stated.

I would like it if D
- forced variable initialization,
- made sure all variables where used,

It just makes it so much easier if the compiler does this kinda 
redundant thinking for me and I can focus on the higher level stuff.

-- 
-Anderson: http://badmama.com.au/~anderson/


-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



  parent reply J C Calvarese <jcc7 cox.net>  writes:


J Anderson wrote:

 J C Calvarese wrote:
 

 If Walter doesn't see these implicit casts as a problem, it's possible 
 that a clever D programmer can create a program to check that the 
 variables aren't being implicitly cast in the ways that the OP was 
 concerned about. It sounds like a very ambitious task to me, but I 
 suppose it's possible.


 
 It's passing the buck. I mean, it would be much easier (for just about 


I'm not passing the buck for Walter. I'm trying to show that maybe a 
compromise is possible. Fine, you don't consider this an option. It was 
just a suggestion. I'm sorry if you saw it as a cop-out. That's not how 
I intended it.

I'm not going to track down a particular message, but I suspect this has 
been brought up before. He seems to have already made up his mind of 
this issue. If Walter doesn't think this is the thing to do, he won't do 
it. But we can still try to change his mind by ganging up on him...


 everyone) to have it in the main program.  Having a separate checker 
 program is just as bad as warnings.
 You can get really good checker programmers that pick up allot of 
 might-be-errors that could never be real errors, but for trivial things 
 like this, it should be an error in the compiler.
 


[...]

 Just thinking outloud...


 
 Check everything I say.  I've met that many programmers who leave 
 warning messages in C++ (because they can't be bothered working out how 
 to fix them) and found that their problem was exactly as the warning 
 message stated.
 
 I would like it if D
 - forced variable initialization,


Please, no.

Let the compiler do this. int=0. double=nan. char="". object=null. 
That's good enough for me. I know others disagree. If you disagree, the 
hypothetical independent checking program can help you out.


 - made sure all variables where used,


Please, no.

Often when I'm debugging (or writing a new program), I'm don't intend to 
use all the variables every time a compile. I don't need the compiler 
breathing down my neck about it about "proper coding processes" when I'm 
trying chase down a bug.


 It just makes it so much easier if the compiler does this kinda 
 redundant thinking for me and I can focus on the higher level stuff.


-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 24 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


J C Calvarese wrote:


 J Anderson wrote:


 J C Calvarese wrote:


 If Walter doesn't see these implicit casts as a problem, it's 
 possible that a clever D programmer can create a program to check 
 that the variables aren't being implicitly cast in the ways that the 
 OP was concerned about. It sounds like a very ambitious task to me, 
 but I suppose it's possible.



 It's passing the buck. I mean, it would be much easier (for just about 



 I'm not passing the buck for Walter. I'm trying to show that maybe a 
 compromise is possible. Fine, you don't consider this an option. It 
 was just a suggestion. I'm sorry if you saw it as a cop-out. That's 
 not how I intended it.

 I'm not going to track down a particular message, but I suspect this 
 has been brought up before. He seems to have already made up his mind 
 of this issue. If Walter doesn't think this is the thing to do, he 
 won't do it. But we can still try to change his mind by ganging up on 
 him...


Sorry, I didn't mean you, I was talking about D, and Walter. D is 
passing the buck to another program if it doesn't do these changes 
because *it can be done in another program by others*. Passing the buck 
can be a good idea in some situations.


-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



  parent  J C Calvarese <jcc7 cox.net>  writes:


J Anderson wrote:
[...]

 I'm not passing the buck for Walter. I'm trying to show that maybe a 
 compromise is possible. Fine, you don't consider this an option. It 
 was just a suggestion. I'm sorry if you saw it as a cop-out. That's 
 not how I intended it.

 I'm not going to track down a particular message, but I suspect this 
 has been brought up before. He seems to have already made up his mind 
 of this issue. If Walter doesn't think this is the thing to do, he 
 won't do it. But we can still try to change his mind by ganging up on 
 him...


 
 Sorry, I didn't mean you, I was talking about D, and Walter. D is 
 passing the buck to another program if it doesn't do these changes 
 because *it can be done in another program by others*. Passing the buck 
 can be a good idea in some situations.


Oh, OK. I misunderstood.

I am concerned about this casting issue. I'm not looking forward to the 
idea of putting a bunch of new casts in my old code, but the implicit 
casts seems like they could cause some serious problems. (The way that I 
write code, I've probably already been adversely affected. :) .)

-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 24 2004



prev sibling  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


 - made sure all variables where used,


 Please, no.

 Often when I'm debugging (or writing a new program), I'm don't intend 
 to use all the variables every time a compile. I don't need the 
 compiler breathing down my neck about it about "proper coding 
 processes" when I'm trying chase down a bug.


IMHO, it's rather easy to shut the compiler up (just comment out the 
variables initalizion points).  If you have loose variables around in 
debugging code, it can cause more unexpected bugs.

-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



  parent reply J C Calvarese <jcc7 cox.net>  writes:


J Anderson wrote:

 - made sure all variables where used,


 Please, no.

 Often when I'm debugging (or writing a new program), I'm don't intend 
 to use all the variables every time a compile. I don't need the 
 compiler breathing down my neck about it about "proper coding 
 processes" when I'm trying chase down a bug.


 IMHO, it's rather easy to shut the compiler up (just comment out the 
 variables initalizion points).  If you have loose variables around in 
 debugging code, it can cause more unexpected bugs.
 


I don't understand. If they're unused, aren't they just "inert"?

-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 24 2004



  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


J C Calvarese wrote:


 J Anderson wrote:


 - made sure all variables where used,


 Please, no.

 Often when I'm debugging (or writing a new program), I'm don't 
 intend to use all the variables every time a compile. I don't need 
 the compiler breathing down my neck about it about "proper coding 
 processes" when I'm trying chase down a bug.


 IMHO, it's rather easy to shut the compiler up (just comment out the 
 variables initalizion points).  If you have loose variables around in 
 debugging code, it can cause more unexpected bugs.


 I don't understand. If they're unused, aren't they just "inert"?


ie - C++ (warnings as errors)

void func()
{
    int t;

   for (t ...) //error t is used without initialization

}

ie

void func()
{
    int t; //error t is not used
}

 in C++ you could do one of either to shut the compiler up...

void func()
{
    //int t;
}

or

void func()
{
    int t;
    t;
}

ie

void func(int t) //error t not used.
{

}

in C++ you could do one of either to shut the compiler up...

void func(int)
{

}

or

void func(int t )
{
    t;
}

Not much effort, for the compiler to help catch you out.

-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



  parent reply larry cowan <larry_member pathlink.com>  writes:


But then is it going to complain about struct members not used (by this module,
but by 3 other modules which see the struct) and class methods not used - that
could really get painful...

Or should it be smart enough to know that an extern is being generated or some
instance or reference is being passed to an external function; and then suppress
the message?

Between unwanted pain and uncontrollable leakage it just seems a bad idea.  We
have enough problems with the occassional need to compile all the modules
together to get all the errors to show up - or prevent the linker from losing
something (and I'm not happy with having to dummy instantiate all the types I'm
going to give my template in the template module to get a usable object).

Matthew - I don't envy you when you do your DTL.  So far arbitrary type
templates are chimera unless you code them in the local module or stack them
into your compile (as opposed to link stage).

In article <c1hcen$88h$2 digitaldaemon.com>, J Anderson says...

J C Calvarese wrote:


 J Anderson wrote:


 - made sure all variables where used,


 Please, no.

 Often when I'm debugging (or writing a new program), I'm don't 
 intend to use all the variables every time a compile. I don't need 
 the compiler breathing down my neck about it about "proper coding 
 processes" when I'm trying chase down a bug.


 IMHO, it's rather easy to shut the compiler up (just comment out the 
 variables initalizion points).  If you have loose variables around in 
 debugging code, it can cause more unexpected bugs.


 I don't understand. If they're unused, aren't they just "inert"?


ie - C++ (warnings as errors)

void func()
{
    int t;

   for (t ...) //error t is used without initialization

}

ie

void func()
{
    int t; //error t is not used
}

 in C++ you could do one of either to shut the compiler up...

void func()
{
    //int t;
}

or

void func()
{
    int t;
    t;
}

ie

void func(int t) //error t not used.
{

}

in C++ you could do one of either to shut the compiler up...

void func(int)
{

}

or

void func(int t )
{
    t;
}

Not much effort, for the compiler to help catch you out.

-- 
-Anderson: http://badmama.com.au/~anderson/





 Feb 24 2004



  parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


larry cowan wrote:


But then is it going to complain about struct members not used (by this module,
but by 3 other modules which see the struct) and class methods not used - that
could really get painful...
  


C++ does do that. It's not a module or class level thing.  It's function 
level.  Have you ever used full warnings with treat warnings as errors 
in C++?


Or should it be smart enough to know that an extern is being generated or some
instance or reference is being passed to an external function; and then suppress
the message?
  


It's only very basic logic.  It's not a runtime thing.  If the variable 
is passed to any function it is considered used.


Between unwanted pain and uncontrollable leakage it just seems a bad idea.  We
have enough problems with the occassional need to compile all the modules
together to get all the errors to show up - or prevent the linker from losing
  


Why use a strongly typed compiler at all then.  You might as well use 
basic. If its a standard error message module creators have to fix it so 
there should be less problems.  In my experience 99% of the time the 
warnings will not show up because the code is correct.   Other other 1% 
you can simply explicitly specify what you meant.  Of course there is 
the cases where stubs are created, but they need to be fixed eventually 
anyway.


something (and I'm not happy with having to dummy instantiate all the types I'm
going to give my template in the template module to get a usable object).
  


Ininitaliztion wouldn't even deal with objects (just ints, floats 
ect...).  Particularly since you pass objects by reference, they can be 
changed in the function called anyway so that a no no.


Matthew - I don't envy you when you do your DTL.  So far arbitrary type
templates are chimera unless you code them in the local module or stack them
into your compile (as opposed to link stage).

  


Sorry I'm not sure where on the same planet here?  This stuff has been 
done in C++ for ages as warnings, I don't see the problem in changing 
warnings to error messages (C++ even allows you to do this but it's not 
a default).

I'm sure you've got some good points in there somewhere, and I'm just 
not getting them ;)


In article <c1hcen$88h$2 digitaldaemon.com>, J Anderson says...
  


J C Calvarese wrote:

    


J Anderson wrote:

      


- made sure all variables where used,
            


Please, no.

Often when I'm debugging (or writing a new program), I'm don't 
intend to use all the variables every time a compile. I don't need 
the compiler breathing down my neck about it about "proper coding 
processes" when I'm trying chase down a bug.

          


IMHO, it's rather easy to shut the compiler up (just comment out the 
variables initalizion points).  If you have loose variables around in 
debugging code, it can cause more unexpected bugs.

        


I don't understand. If they're unused, aren't they just "inert"?

      


ie - C++ (warnings as errors)

void func()
{
   int t;

  for (t ...) //error t is used without initialization

}

ie

void func()
{
   int t; //error t is not used
}

in C++ you could do one of either to shut the compiler up...

void func()
{
   //int t;
}

or

void func()
{
   int t;
   t;
}

ie

void func(int t) //error t not used.
{

}

in C++ you could do one of either to shut the compiler up...

void func(int)
{

}

or

void func(int t )
{
   t;
}

Not much effort, for the compiler to help catch you out.

-- 
-Anderson: http://badmama.com.au/~anderson/
    



  



-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 25 2004



prev sibling  parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net>  writes:


J C Calvarese wrote:

 J Anderson wrote:
 

 J C Calvarese wrote:


 J Anderson wrote:

 I think it'd be impossible to grep, but at least the compiler error 
 messages should point to the code that needs correcting. I'm not sure 
 if it needs changing, but if something this fundamental is going to 
 be changed, now is our opportunity to make the change. Pretty soon, 
 the door will close on that chance.

 D 1.0 hasn't arrived yet, and I don't think we'd be able to make a 
 change here once it does arrive.



 With my other hat:

 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings 
 (maximum level) should become errors in D.


 
 
 If Walter doesn't see these implicit casts as a problem, it's possible 


Walter wrote:

 I've changed the language so that floating point values are no longer
 implicitly converted to integral types.


... in thread "[Language design] yet another notational error"

Walter, does this mean you'll disallow implicit casts to lesser-space in 
all cases (ie uints/ints etc etc etc)?

Please? ;)

Cheers,
Sigbjørn Lund Olsen



 Feb 25 2004



  parent reply Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Wed, 25 Feb 2004 15:18:05 +0100 (02/26/04 01:18:05)
, Sigbjørn Lund Olsen <sigbjorn lundolsen.net> wrote:


 J C Calvarese wrote:






[snip]

 If Walter doesn't see these implicit casts as a problem, it's possible


 Walter wrote:
  > I've changed the language so that floating point values are no longer
  > implicitly converted to integral types.

 ... in thread "[Language design] yet another notational error"

 Walter, does this mean you'll disallow implicit casts to lesser-space in 
 all cases (ie uints/ints etc etc etc)?


If implicit casting is not an error and cannot be a despicable warning, 
would it still be useful as an 'informational' message. In my case, I'd 
like to know where all cases of D doing this occurs so that I can either 
change datatypes or make the cast explicit, or even something else. Its 
not always obvious to the human eye where such implicit casts exist.

-- 
Derek



 Feb 25 2004



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Derek Parnell wrote:
[...]

 
 If implicit casting is not an error and cannot be a despicable warning, 
 would it still be useful as an 'informational' message. In my case, I'd 
 like to know where all cases of D doing this occurs so that I can either 
 change datatypes or make the cast explicit, or even something else. Its 
 not always obvious to the human eye where such implicit casts exist.
 


Your description of an "informational" message sounds eerily similar to 
what I thought a "warning" message was. :)

-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 25 2004



  parent  Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Wed, 25 Feb 2004 17:35:16 -0600 (02/26/04 10:35:16)
, J C Calvarese <jcc7 cox.net> wrote:


 Derek Parnell wrote:
 [...]

 If implicit casting is not an error and cannot be a despicable warning, 
 would it still be useful as an 'informational' message. In my case, I'd 
 like to know where all cases of D doing this occurs so that I can 
 either change datatypes or make the cast explicit, or even something 
 else. Its not always obvious to the human eye where such implicit casts 
 exist.


 Your description of an "informational" message sounds eerily similar to 
 what I thought a "warning" message was. :)


Yah think ? ;-)

-- 
Derek



 Feb 25 2004



prev sibling  parent reply Sean Kelly <sean ffwd.cx>  writes:


J Anderson wrote:

 
 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings (maximum 
 level) should become errors in D.


Agreed.  I always compile with warnings set at max level and only ignore 
those produced by third-party libraries (because I have to).  Except for 
some silly ones that have no context in D, all C++ warnings should be 
treated as errors in D.


Sean



 Feb 24 2004



  parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


Sean Kelly wrote:


 J Anderson wrote:


 It is something I like from C++ with all warnings (maximum level) as 
 errors set.  Actually I think that just about all c++ warnings 
 (maximum level) should become errors in D.



 Agreed.  I always compile with warnings set at max level and only 
 ignore those produced by third-party libraries (because I have to).  
 Except for some silly ones that have no context in D, all C++ warnings 
 should be treated as errors in D.


 Sean


In C++ I put push-pop the warning level for every file (it's in my cpp 
template so it's not effort).  That way third party are no problem.

-- 
-Anderson: http://badmama.com.au/~anderson/



 Feb 24 2004



prev sibling next sibling parent  C <dont respond.com>  writes:


I completely agree, fixing the pre-existing code should not be too =

dificult , even if its all by hand.

C

On Tue, 24 Feb 2004 19:09:42 +0000 (UTC), larry cowan =

<larry_member pathlink.com> wrote:


 An important point is that implicit casting where it's not guaranteed =


to =


 be safe
 is DANGEROUS.

 And especially in large systems of code and in later maintenance chang=


es.

 THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO=


 =


 THINGS
 BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - =


AS =


 A
 SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT =



 COMPILER IN
 TIME.

 It should be reconsidered whether or not it breaks Phobos or other =



 projects
 developed or in-work.  Explicit casting need not have such limitations=


 - =


 it can
 be searched for and any problems can be dealt with.  The correction of=


 =


 the
 limited amount of long-term current code can be fixed by explicit =



 casting when
 the compiler starts rejecting it.

 -larry

 In article <c1g43k$11he$1 digitaldaemon.com>, J Anderson says...

 Sark7 wrote:


 I think that implicit casting from greater space to lesser space
 should be not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok


 But uint's can be greater then int's.  I don't think either should be=





 allowed without a cast.


 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error


 I think float/double to int should also have a forced cast.  Most of =




the

 time you are using floating point for calculations that need the
 fraction part and accidental conversion to int can be a real problem.=





 However, I think these things are to late to change now, it's kinda
 engrained in D now and would cause to many changes in stuff that is
 already written.

 --
 -Anderson: http://badmama.com.au/~anderson/






-- =

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



 Feb 24 2004



prev sibling next sibling parent  =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net>  writes:


larry cowan wrote:

 An important point is that implicit casting where it's not guaranteed to be
safe
 is DANGEROUS.
 
 And especially in large systems of code and in later maintenance changes.
 
 THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
 BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
 SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
 TIME.
 
 It should be reconsidered whether or not it breaks Phobos or other projects
 developed or in-work.  Explicit casting need not have such limitations - it can
 be searched for and any problems can be dealt with.  The correction of the
 limited amount of long-term current code can be fixed by explicit casting when
 the compiler starts rejecting it.


I do agree, and while I've not written large amounts of D code yet, but 
I would think that when writing code for a language/compiler that is 
unfinished and incomplete, language changes breaking code really ought 
not be that big a concern. Especially since D is a language that *does* 
break backwards compatability to its 'ancestors' C/C++ *precisely* 
because it wants to deal with problems. Do we really wish to deal with 
problems in D simply because by 0.79 it was 'too late' to fix them?

Besides, and not to step on anybody's toes, but I wouldn't say enormous 
amounts of code has been written for D at this point, relatively 
speaking. It would certainly be better to fix the problem that implicit 
casting can be now than for D 2.0.

Cheers,
Sigbjørn Lund Olsen



 Feb 24 2004



prev sibling  parent  "Matthew" <matthew.hat stlsoft.dot.org>  writes:


Coulnd't agree more.

But, ouch!, that shouting hurt my eyes. ;/

"larry cowan" <larry_member pathlink.com> wrote in message
news:c1g7hm$17is$1 digitaldaemon.com...

 An important point is that implicit casting where it's not guaranteed to


be safe

 is DANGEROUS.

 And especially in large systems of code and in later maintenance changes.

 THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO


THINGS

 BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
 SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER


IN

 TIME.

 It should be reconsidered whether or not it breaks Phobos or other


projects

 developed or in-work.  Explicit casting need not have such limitations -


it can

 be searched for and any problems can be dealt with.  The correction of the
 limited amount of long-term current code can be fixed by explicit casting


when

 the compiler starts rejecting it.

 -larry

 In article <c1g43k$11he$1 digitaldaemon.com>, J Anderson says...

Sark7 wrote:


 I think that implicit casting from greater space to lesser space
 should be not allowed, because imho it isn't logically correct.

 for example:

 unit -> int  // ok


But uint's can be greater then int's.  I don't think either should be
allowed without a cast.


 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error


I think float/double to int should also have a forced cast.  Most of the
time you are using floating point for calculations that need the
fraction part and accidental conversion to int can be a real problem.

However, I think these things are to late to change now, it's kinda
engrained in D now and would cause to many changes in stuff that is
already written.

-- 
-Anderson: http://badmama.com.au/~anderson/







 Feb 24 2004



prev sibling  parent reply J C Calvarese <jcc7 cox.net>  writes:


Sark7 wrote:

 I think that implicit casting from greater space to lesser space should 
 be not allowed, because imho it isn't logically correct.
 
 for example:
 
 unit -> int  // ok
 int  -> uin  // error
 
 float -> double // ok
 double -> float // error
 
 int   -> float // ok
 float -> int   // error
 
 -- 
 Sark7


Your post and some of the replied got me thinking...

Okay, I know it's "Garbage In, Garbage Out," but it seems to me there's 
multiple reasons why the code below might raise a compile-time error.

First of all, I would expect an error when I initialize the uint j to a 
negative number. Is the compiler being too forgiving here? I guess 
there's a fine between a harrassing compiler and a too lenient 
compilation process.

I'm also disturbed the implicit casting from int to uint (and uint to 
int, too), but I'm afraid it'll be painful if the compiler starts 
disallowing all of this activity. I haven't really made up my mind yet.



import std.c.stdio;

void printInt(int i)
{
    printf("%d\n", i);
}

void printUint(uint u)
{
    printf("%d\n", u);
}


void main()
{
    int i = -2000000000;
    uint j = -1000000000;


    printInt(i);
    printInt(j);
	
    printUint(i);
    printUint(j);	
}

/+

Output:
-2000000000 // expected
-1000000000 // somewhat expected
2294967296  // nonsense
3294967296  // nonsense

+/


-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 24 2004



  parent reply Manfred Nowak <svv1999 hotmail.com>  writes:


J C Calvarese wrote:

[...]

 Output:
 -2000000000 // expected
 -1000000000 // somewhat expected
 2294967296  // nonsense
 3294967296  // nonsense


Not confirmed.

My output:
-2000000000
-1000000000
-2000000000
-1000000000

And the output you got is in no means nonsense, because it is the `uint'
interpretation of the specified negative `int' values.

What you have to do is to check whether the actual value is in the range
of the target type, if you do not already know, that it is in this range.

But when done checking, why should the language force you, to now declare
that you are really, really shure that you want to cast by requiring an
explicit cast?

  int i;
  uint j;
  ...
  if(uint.min <= i && i <= uint.max)j= cast(uint) i; // ?
    else throw ....

So long.



 Feb 25 2004



  parent  J C Calvarese <jcc7 cox.net>  writes:


Manfred Nowak wrote:

 J C Calvarese wrote:
 
 [...]
 

Output:
-2000000000 // expected
-1000000000 // somewhat expected
2294967296  // nonsense
3294967296  // nonsense


 
 
 Not confirmed.
 
 My output:
 -2000000000
 -1000000000
 -2000000000
 -1000000000


Oops. I meant to use this code in my example:

void printUint(uint u)
{
	printf("%u\n", u);  /* d => u */
}

Thanks for straightening me out.


 
 And the output you got is in no means nonsense, because it is the `uint'
 interpretation of the specified negative `int' values.


OK, I exaggerated. My example is admittedly contrived, but the lack of 
any compiler errors is still unassuring.


 What you have to do is to check whether the actual value is in the range
 of the target type, if you do not already know, that it is in this range.
 
 But when done checking, why should the language force you, to now declare
 that you are really, really shure that you want to cast by requiring an
 explicit cast?
 
   int i;
   uint j;
   ...
   if(uint.min <= i && i <= uint.max)j= cast(uint) i; // ?
     else throw ....
 
 So long.


Not that long ago, I would have argued in favor of all sorts of implicit 
casting, but now I think that I was way wrong. I'm just not sure how far 
I should argue to the other extreme.


-- 
Justin
http://jcc_7.tripod.com/d/



 Feb 25 2004