View mode: basic / threaded / horizontal-split · Log in · Help
February 25, 2004
Re: Implicit casting
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
February 25, 2004
Re: Implicit casting
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/
February 25, 2004
Re: Implicit casting
>> - 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/
February 25, 2004
Re: Implicit casting
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/
February 25, 2004
Re: Implicit casting
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/
February 25, 2004
Re: Implicit casting
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.
February 25, 2004
Re: Implicit casting
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/
February 25, 2004
Re: Implicit casting
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/
February 25, 2004
Re: Implicit casting
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/
February 25, 2004
Re: Implicit casting
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/
1 2 3 4 5
Top | Discussion index | About this forum | D home