On 11/10/2010 01:36 PM, Kirk Wallace wrote:
> On Wed, 2010-11-10 at 11:34 -0500, Mark Wendt wrote:
> ... snip
>
>>> (AFAIK :) )
>>> - Steve
>>>
>> Steve,
>>
>> Yes, you're "absolute"ly right... ;-)
>>
>> Mark
>>
> Sorry for rattling the cage.
>
Kirk,
No need to be sorry. Though this isn't the developers list, lotsa
good programming info seems to come out here. My C skills are quite
rusty since most of my sysadmin stuff is done in perl, and I enjoy
talking about coding and programming. I even occasionally post
something incorrect, and the guys that do this stuff a lot more than me
are quick to correct, which is a good thing. Sometimes we have to learn
things, and then re-learn them. At any rate, it gets us thinking about
it again, and who knows? Maybe one of these little tid bits turns on a
light bulb for someone who's having a bit of problem with a piece of code.
> What I am trying to do is learn enough C to be able to evaluate what the
> code is trying to do. Also, to clarify, I added everything after all of
> the //'s, therefore they carry no weight.
>
Comments are always good because they express what the programmer is
hoping to achieve from that bit o' code. Or, when you have to go back
in to the code to either fix something, or change something. It kinda
gives you a snapshot of what you were thinking and what you were trying
to achieve at the time.
> For the issue of whether operator precedence trumps short circuit, I
> suppose that is up to what gcc was programed to do, so I could reference
> gcc. Or, I could just write some code to test the different scenarios.
>
Yep, the compiler is the ultimate adjudicator of the argument. Just
remember, with C, and C++, sometimes what you expect to happen, doesn't,
and the compiler goes merrily on it's way.
> But... if
> " if(new_in&& new_in != last_in) {"
> tests for an edge in the the proper direction, why does the previous
> line normalize the edge?
> " if(in_edge) new_in = ! new_in;"
> or did I get this wrong too?
>
You've got two completely different expressions. The first does a
logical AND between the two expressions. The second only evaluates the
variable "in_edge". The first "may" require both expressions to be
evaluated, while the second only assigns new_in to the "not" new_in if
in_edge is not 0.
> Somehow I got the impression that comp needed to have all variables
> declared in the top portion of the file, and that comp stripped off the
> top and placed the variables as needed. I also found that "comp
> --compile foobar" creates a file "foobar.c" which might provide some
> insight into this. It's like I see what might be a trunk, but I am not
> seeing the elephant. I just need to be patient and look for it.
>
I'm not too familiar with comp, but typically, C code global variables
are declared outside the "main", and local variables are declared either
in the body, or in the function. Comp may differ?
Mark
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
