On 10 November 2010 06:04, Kirk Wallace <[email protected]> wrote:
Speaking from a position of near-ignorance, having only been playing
with C for a few months myself, I might have a useful perspective.
> I would have tended to have made the read only param's as variables, but
> I found that variables won't show up in halscope, so I am assuming that
> param's were used for this reason?
I assume so. Params and pins live in the HAL shared-memory region
where other things can see them and adjust them (including Halscope).
In theory halscope could look at the memory location where
function-local variables were stored, but how would it know where to
look? Pins and parameter memory addresses are added to a database and
given a global name. (In fact, that is pretty much all that creating
a pin is, I suppose)
> I also would have declared new_in up
> in the param section as a variable or param, but I guess "int new_in =
> in" kills the declaration and the value assignment with one stone?
Yes. It also means that new_in is local to that function (anything
declared between {} only exists within those braces) and possibly more
importantly isn't going to change part way through code execution.
Because "in" is in shared memory it makes sense to work on a static
copy of it to avoid trouble if it happens to be changed by another
function while the code is running.
> The
> statement "if(new_in && new_in != last_in)" kind of baffles me. "foo &&
> foo" seems to be a programming trick called a short circuit?
This works because != has a higher precedence than &&. This might be a
sign of a programmer who implicitly knows this, or a programmer who
got lucky. I would tend to prefer if(new_in && (new_in != last_in))
because I don't know my operator precedences.
--
atp
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
