> > So what happens here then: > > > > Two integers: currentTotal and flowIncrement > > > > Which, if any, is signed and which, if any, unsigned? What if > you have to > do > > arithmetic with them and must not lose any signs? > > There's not enough context information here. I'd need to know > more about the > domain to know if either could be negative.
Is this what you'd say to an employer when they asked you to fault find a piece of code in the middle of a huge embedded app? "Sorry, no can do, I need more context to be able to work on this." You know as well as any of us do that you just don't always get that luxury in a software job. Even if you got this description (context): "It is a fiscal flow metering application, which uses one of four types of flow meter (turbine, orifice, linear or ultrasonic turbine) to measure the amount of product flowing through the pipelines, and provides a running total of how much product has passed. Ultrasonic flow meters can actually be used to measure flow in the reverse direction." ... does that really help? If those variables had been prefixed, the context and any kind of understanding of the application would not be necessary; you'd know explicitly what [type and sign] they were without needing to know what they represent, and thus could have seen the dangers of trying to add them together. Notation has its advantages as well as disadvantages. I'm not trying to challenge you here; you have your beliefs, and that's fine by me. I just wanted to show that, through direct experience (for a change), a blanket 'Nope' is not necessarily a sensible answer. And yes, I WILL be trying to follow my own point about blanket 'Nopes'. (The actual situation was, flowIncrement represents the amount of product that has flowed in this calculation cycle, and thus is small, but could be negative if the product is flowing in reverse; thus, it was a signed integer. currentTotal represents the accumulated total since whenever, and thus could be a huge number; it must therefore hold as large a value as possible. A negative total is meaningless; it would never go below zero by design. Thus, it was an unsigned integer. Hence, the (un)signed arithmetic problem arose when updating the total because originally ultrasonic meters weren't supported and so it was never a problem. In case the point isn't clear yet, because someone did not use any distinguishing notation the numbers were blindly added together, and once ultrasonic support came in, the app failed and we had to fault-find it to determine why; had they been prefixed, the danger would have been spotted sooner, and we would not have had that issue creep in - a maintenance issue created by lack of notation.) -- Jason Teagle [EMAIL PROTECTED] _______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
