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

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/

>> - 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/

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/

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/

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.

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/

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/

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/

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/