clipka wrote:
> Darren New schrieb:
>> You fix the routine that needs the new parameter, and the routine that 
>> has the new parameter. You compile the code. Anyone who calls the new 
>> routine won't compile.
> 
> Are you *perfectly* sure about this??
> 
> This is /not/ something you want to break: Any function you happen to 
> miss (because it happens to be stored in a void* pointer somewhere, or 
> whatever, and you happen to be a bit too tired that night)

Functions don't get stored in void pointers.  (I know what you mean. 
Understand my point before you complain I missed yours. :-)

If you're complaining that the weak typing of C can fk you up, then sure, of 
course. But then, storing an integer into a void* and hoping none of your 
code ever follows that "pointer" is at least as bad if not worse. At least 
you can't do math on function pointers.

> Misusing the compiler for identifying stuff affected by code refactoring 
> is a risky business.

Sure. Of course there needs to be a modicum of intelligence applied to the 
parts of the code where the compiler can't tell what function it's calling.

> (Other question is, how long does it take to compile? And how many 
> layers of functions do you have that you'll need to repair? 

I wasn't meaning to imply you should be mindlessly mechanical about it. Just 
that the fact there were thousands of functions to fix didn't mean it was 
more difficult than tedious to fix them.

 > Let alone
> that some part involved may be a library you don't have source code 
> access to.)

That's always a potential problem, yes.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message