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) /will/ screw 
up your running program in a beautifully obscure fashion. Welcome, 
Heisenbug!

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

(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? Let alone 
that some part involved may be a library you don't have source code 
access to.)

Post a reply to this message

clipka wrote:
> Well, if that's a total of six man-hours (as opposed to maybe thousands 
> of people losing six hours each), then it's more economic to leave the 
> bug in there. 

Sure. ANd when you start getting into "thousands of people", the equation 
changes again. Now it's not "how many man hours can we save", but "how many 
people won't buy our product because of this bug" vs "how much does the bug 
take to fix."

If only 3 people are going to switch from Windows to Linux because of a bug 
that costs you 6 hours a year, chances of MS spending a man month to fix it 
are slim even if it wastes the time of 1000s of people a year.

>> Hard to say, really. Certainly the *easy* programs are desktop and web 
>> apps.
> 
> I guess old-fashioned mainframe business apps are rather boring, too.

Yup. "Say, generate for me a list of all employees in order of the total 
number of days they've worked since getting hired."

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

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

Darren New schrieb:
> Sure. ANd when you start getting into "thousands of people", the 
> equation changes again. Now it's not "how many man hours can we save", 
> but "how many people won't buy our product because of this bug" vs "how 
> much does the bug take to fix."

Absolutely. I just didn't want to go /that/ deep into detail ;-)

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> If you're got to actually change function prototypes then, yeah, 
>> that's not going to happen...
> 
> Not sure why not. It's actually pretty easy.
> 
> 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. Fix them to accept a new parameter and pass it 
> in. Iterate until all functions on the call chain between where you have 
> the parameter and where you need the parameter are passing it down.
> 

Aren't Callback functions often used in places where it's not easy to 
just change one thing and recompile?  I would think that many parts of 
the codebase would depend on that specific function signature being the 
way it is.

...Chambers

Post a reply to this message

Chambers wrote:
> Aren't Callback functions often used in places where it's not easy to 
> just change one thing and recompile?  I would think that many parts of 
> the codebase would depend on that specific function signature being the 
> way it is.

I would think if you have a callback routine that actually uses the third 
parameter, passing the right thing would be necessary each time, but you'd 
also have that information each time. I.e., you wouldn't be invoking the 
callback that depended on which controller was invoking it if it wasn't 
actually coming from the controller. Since the other routines didn't use 
that third parameter, they could get a dummy value there everywhere they're 
called from a context where the new parameter doesn't make sense.

I can see situations where that would be difficult to resolve, but you 
wouldn't be able to resolve it by passing the integer in cast to void* in 
those cases either.  I.e., given that they solved the problem by sometimes 
(i.e., conditionally) passing the value as the wrong type and then 
extracting it where appropriate, it doesn't seem like it's the sort of 
problem that would be hard to solve by adding a new variable of the right 
type (modulo performance problems and/or lacking some source code, of course).

If they were using a language where functions can have default arguments, 
this would the canonical example of "a good place to use that." :-)

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

> The bit I like best is where they count the number of bytes they received 
> before they turned off the receiver and then adjust the wake-up time they 
> program into the hardware, on the basis that the heat from running the 
> receiver will have made the crystal run at a different speed for the next 
> 1.28 seconds they're asleep, and you don't want to wake up too soon or too 
> late. :-)  Scary stuff going on inside there.

I know, I used to work supplying the displays for phones, and every last 
tiny bit of power reduction was always demanded.  For standby mode (when you 
haven't touched any keys for a minute or so) we ended up with reducing the 
display to just a few horizontal lines (enough to show the time and a few 
icons), reducing to 3-bit colour (ie each RGB sub-pixel either fully on or 
off) and reducing to 5 Hz refresh.  Then you can design the power supply and 
driving circuits in a clever way so that in standby you only need a fraction 
of the electronics running.  Because production volumes are so high there is 
plenty of cash around for developing really clever and complex stuff to save 
power and improve performance.

> I also found out that while my car has a bluetooth headset feature built 
> in that lets me make hands-free calls from the car without taking the 
> phone out of my pocket, lots of cars in Europe use the "SIM profile" of 
> bluetooth. So there's an entire phone built into the car that just 
> wirelessly accesses the SIM chip, pulling in the phone book of whoever is 
> in the car and everything. Very cool.

Oh yes, my current car and my last car had that.  It means when someone 
calls you the car can display the name of the person from the phonebook. 
Note that the phonebook in most phones is stored in the phone and not on the 
SIM card, because the SIM card has very limited storage capacity.  Also it 
means if you want to call someone you can scroll through the address book on 
the car display and not have to use the tiny buttons and screen on your 
phone whilst driving.

Post a reply to this message

> That's one reason why in-house tools tend to be so crappy: It's more 
> economic to accept the loss of productivity of the few people who 
> actually use it, than investing that productivity into improving it.

Exactly the reason why most level editors for games are crap.

Post a reply to this message

>> That's one reason why in-house tools tend to be so crappy: It's more 
>> economic to accept the loss of productivity of the few people who 
>> actually use it, than investing that productivity into improving it.
> 
> Exactly the reason why most level editors for games are crap.

I was wondering about that...

Personally, after using a few level editors, I find it absolutely 
*astonishing* that games are ever produced. I mean, if it takes 4 hours 
of hassle to construct an empty cuboid room, how the hell do people 
construct anything customers would pay money for?!

Post a reply to this message

Invisible wrote:
> Personally, after using a few level editors, I find it absolutely 
> *astonishing* that games are ever produced. I mean, if it takes 4 hours 
> of hassle to construct an empty cuboid room, how the hell do people 
> construct anything customers would pay money for?!

They go the UT3 route, and build the whole level in 3DS Max (you have no 
idea how much this "design decision" pissed me off when I found out. 
What's the point of UnrealEd if it just imports static meshes from Max?)

...Chambers

Post a reply to this message