mnemonic

[aarklon]

Hi all,

Is there any mnemonic for remembering C precedence rules????

I have just coined the word TUBSREBLCAC

where T --- top level operators
U ---- unary operators
B ----- binary operators
S ------ shift operators
R------- relational operators
E ------ equality operators
B ------- bitwise operators
L ------- logical operators
C ----- conditional operators
A ----- assignment operators
C ------ comma operator

how good is this mnemonic

or is there any simple mnemonic such as

"How I want a sweetened drink of course after the heavy lectures
involving quantum mechanics" which is mainly used by math pros for
remembering Pi value(3.14195265358979)

[Tor Rustad]

Richard wrote:

Tor Rustad <to********@hotmail.comwrites:

[...]

>A debugger isn't always the best tool for the job. How many race
conditions have you tracked down via a debugger?

I would not use a debugger to unblock the u-bend under my kitchen sink
either. But I would use it to catch errors in a real world C program ....

You sounds more like a junior programmer, maintaining a prototype.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[Richard]

Tor Rustad <to********@hotmail.comwrites:

Richard wrote:

>Tor Rustad <to********@hotmail.comwrites:

[...]

>>A debugger isn't always the best tool for the job. How many race
conditions have you tracked down via a debugger?

I would not use a debugger to unblock the u-bend under my kitchen sink
either. But I would use it to catch errors in a real world C program ....

You sounds more like a junior programmer, maintaining a prototype.

Well, I can say with some authority I clearly have much better and more
detailed knowledge of how to use a debugger for what it was intended to
do than you. Why you want to throw in straw men about the minority of
cases where a debugger might not be useful is quite beyond me. No one
described it as a "single solution for all cases".

From your rather "high level perch" I wonder why you are even discussing
debuggers since you are clearly too clever and senior to have to use one.

But thank you for the kind words regardless :-;

[J. J. Farrell]

On Nov 4, 4:15 pm, Richard <[e-mail]:

>
The view of some of the regulars here is quite astonishing and makes me
wonder how many have really worked in Industry on large code bases
maintained by multiple programmers across the world.

Now there's a sentiment I agree with entirely, though I suspect we're
thinking of different groups of regulars.

[Richard Bos]

Richard <rg****@gmail.comwrote:

Tor Rustad <to********@hotmail.comwrites:

Serve Lau wrote:

"James Kuyper" <ja*********@verizon.netwrote in message
That's a weird interpretation! The quote is about debugging, not
debuggers. It's about the importance of writing code so it can be
debugged, which implies that debugging is important too, not that
it's unnecessary.

Who's saying this?

its in this thread.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan

Nope, Kernighan refer to debugging, which is a process not limited to
running a program in a debugger.

Of course it isn't. But it would be fairly ridiculous to suggest that
any form of debugging an existing code base is NOT done with a
"debugger" of some description.

It would be ridiculous. However, for the wise, "debugger" means
"programmer who finds and removes bugs", and not "program which steps
through another program". The former _may_ use the latter, but by no
means has to.

Richard

[Nick Keighley]

On 3 Nov, 15:09, Richard <[e-mail]:

Tor Rustad <[e-mail]:

Serve Lau wrote:

"James Kuyper" <[e-mail] in message
news:Al%Wi.6919$9N6.487@trnddc03...

>That's a weird interpretation! The quote is about debugging, not
debuggers. It's about the importance of writing code so it can be
debugged, which implies that debugging is important too, not that
it's unnecessary.

>Who's saying this?

its in this thread.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan

debugging != using a debugger

this keeps on being said...

Nope, Kernighan refer to debugging, which is a process not limited to
running a program in a debugger.

Of course it isn't. But it would be fairly ridiculous to suggest that
any form of debugging an existing code base is NOT done with a
"debugger" of some description.

this is just silly. You're claiming a debugger is essential to
debugging
therefore if someone is debugging they are using a debugger. Make your
mind up.

A debugger is a special purpose program that is attached to a running
program
(or used to analyse a "core" dump) to aid in finding bugs in programs.

There are other ways to find bugs.

People who advocate littering code with
printfs are plain wrong IMO.

well depending what you mean by "littering" and "printf". My programs
typically write to log files. When Things Go Wrong the logfile at
least tells you
what the program was *trying to do. This sometimes happens on a
different
continent from my current location...

Yes, it might have its uses occasionally,
but any changing of the code to "debug" is generally considered a bad
thing.

"generally"?

From some of the comments I read here, I often wonder if the people
knocking debuggers have any idea whatsoever of just what they are, how
they work and the results they can achieve.

I use debuggers sometimes. I just don't think they are always useful.

One of my favorite uses of a debugger is simply to step through code to
get a feel for the control flow.

now this I find strange. Debugging is fixing faults. Why would you
step through the program at random (or is there a purpose?). The
programs I deal
with have soft RT requirements. If you start single stepping then the
program
looses data, drops comms links and fails to do things on time. They
are also
large. Stepping through the code "to get a feel for the control flow"
sounds odd.

Maybe this *is* an age thing.

Ability to step over calls and just
examine the returned data etc is much easier than "imagining" it by
reading code no matter how well and clearly that code is written and
annotated.

well I'll do that if I'm stuck. And debuggers are handy after crashes.
But not all bad things crash the program.

I have to deal with bugs where debuggers are not available. In fact
where
I am not even present.

Programs that record what tehya re doing are handy.
--
Nick Keighley

[Richard]

Nick Keighley <ni******************@hotmail.comwrites:

On 3 Nov, 15:09, Richard <[e-mail]:

>Tor Rustad <[e-mail]:

Serve Lau wrote:
"James Kuyper" <[e-mail] in message
news:Al%Wi.6919$9N6.487@trnddc03...

>>That's a weird interpretation! The quote is about debugging, not
debuggers. It's about the importance of writing code so it can be
debugged, which implies that debugging is important too, not that
it's unnecessary.

>>Who's saying this?

>its in this thread.

>"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan

debugging != using a debugger

this keeps on being said...

Yes, by me too.

>

Nope, Kernighan refer to debugging, which is a process not limited to
running a program in a debugger.

Of course it isn't. But it would be fairly ridiculous to suggest that
any form of debugging an existing code base is NOT done with a
"debugger" of some description.

this is just silly. You're claiming a debugger is essential to
debugging
therefore if someone is debugging they are using a debugger. Make your
mind up.

A debugger of some description.

>
A debugger is a special purpose program that is attached to a running
program
(or used to analyse a "core" dump) to aid in finding bugs in programs.

There are other ways to find bugs.

Yes. We explored that a lot in the thread.

>

>People who advocate littering code with
printfs are plain wrong IMO.

well depending what you mean by "littering" and "printf". My programs
typically write to log files. When Things Go Wrong the logfile at
least tells you
what the program was *trying to do. This sometimes happens on a
different
continent from my current location...

None of which has anything to do with why debugging is not a good thing.

>

>Yes, it might have its uses occasionally,
but any changing of the code to "debug" is generally considered a bad
thing.

"generally"?

Yes. Generally.

>

>From some of the comments I read here, I often wonder if the people
knocking debuggers have any idea whatsoever of just what they are, how
they work and the results they can achieve.

I use debuggers sometimes. I just don't think they are always useful.

No. But generally they are. Its why they were invented.

>

>One of my favorite uses of a debugger is simply to step through code to
get a feel for the control flow.

now this I find strange. Debugging is fixing faults. Why would you
step through the program at random (or is there a purpose?). The

Yes there is a purpose. Reread the sentence - it is clear enough. To
step through the code to understand the program flow. The ability to
force logic conditions to step through less likely states is obviously a
boon to the investigative programmer. Debugging code is easier with a
knowledge of how it is constructed and runs.

programs I deal
with have soft RT requirements. If you start single stepping then the
program
looses data, drops comms links and fails to do things on time. They
are also
large. Stepping through the code "to get a feel for the control flow"
sounds odd.

So why mention it. Not everyone is RT.

>
Maybe this *is* an age thing.

I have no idea what you mean. The great majority of SW is not RT and a
debugger and debugging and associated techniques are not rocket science
and bring a lot to the table.

>

>Ability to step over calls and just
examine the returned data etc is much easier than "imagining" it by
reading code no matter how well and clearly that code is written and
annotated.

well I'll do that if I'm stuck. And debuggers are handy after crashes.
But not all bad things crash the program.

No one said they did. But a debugger can halt a program using predefined
watch conditions. Makes it far easier to locate the problems. Even in RT systems.

>
I have to deal with bugs where debuggers are not available. In fact
where
I am not even present.

Programs that record what tehya re doing are handy.

Yes. And this is a form of debugging.

[Gray Area]

On 1 Nov, 20:58, Julienne Walker <[e-mail]:

On Nov 1, 4:43 pm, [e-mail] wrote:

Parentheses can be annoying and useless in code.

They can be, if you use them abusively. On the other hand, *lack* of
parentheses can be annoying and useless in code for the same reason.

The solution is to learn operator precedence.

Perhaps *you* have perfect memory, but *I* don't. I'd rather remember
a simple guideline than a slew of rules, because to be perfectly
frank, I have better things to spend my few remaining brain cells
on. :-)

Indeed. In fact many moons ago I used the Watcom compiler(cant recall
what version... may have been 9 or 10) on QNX4.0 and the compiler was
actually non compliant with regard to the precedence rules so using
parentheses... since that experience my little brqain is unable to
revert to remembering the rules.

[Keith Thompson]

Richard <rg****@gmail.comwrites:

Nick Keighley <ni******************@hotmail.comwrites:

[...]

>this is just silly. You're claiming a debugger is essential to
debugging therefore if someone is debugging they are using a
debugger. Make your mind up.

A debugger of some description.

That sentence no verb.

Are you saying that debugging must always involve "a debugger of some
description"? If so, you're using the word "debugger in a much more
inclusive sense than I've ever seen. Please clarify.

If I happen to correct a flaw in a program by adding examining the
source code and adding temporary printf calls, I'm not using a
debugger (unless I *am* the debugger).

[...]

>well depending what you mean by "littering" and "printf". My
programs typically write to log files. When Things Go Wrong the
logfile at least tells you what the program was *trying to do. This
sometimes happens on a different continent from my current
location...

None of which has anything to do with why debugging is not a good thing.

Huh? Who ever said that debugging is not a good thing? Unless you're
using the word "debugging" specifically to mean using a source-level
debugger (such as gdb), then your statement makes no sense as far as I
can tell.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Charlie Gordon]

"Richard" <rg****@gmail.coma écrit dans le message de news:
ob************@news.individual.net...

Note : of course it is better to get it right first time. But in the
real world there will always be bugs.

2nd note : if a system crashes I can guarantee that i can debug it to
the point of the crash quicker than you can read and understand 500000
lines of C code and run it through in your head with all possible data
input and come to a guess at where it might crash .....

That may well be, but reading the 500000 lines will undoubtedly unearth
hundreds of other bugs, some of which would crash the system in even lesser
appropriate times.

--
Chqrlie.

[Charlie Gordon]

"Ben Pfaff" <bl*@cs.stanford.edua écrit dans le message de news:
87************@blp.benpfaff.org...

Keith Thompson <ks***@mib.orgwrites:

>"Debugging" doesn't mean "using a debugger".

I'd say that about half of my bugs I find with printf. Another
half, I find with valgrind. Another 5% are made obvious with
"git bisect". The last 10%, I find with a traditional debugger.

My experience gives similar results.
I should also mention the 50% or more that are caught at typing time by
using proper editing tools with syntax coloring, automatic indentation,
brace balancing, completion... and the other 50% detected at code review
time.
But for reproducible crashes and endless loops, the debugger is indeed a
very effective tool.

--
Chqrlie

[Ben Bacarisse]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Ben Bacarisse" <be********@bsb.me.uka écrit dans le message de news:
87************@bsb.me.uk...

>aa*****@gmail.com writes:

>>Is there any mnemonic for remembering C precedence rules????

Not that I know, but here are some thing that help me remember:

<snip>

>Everyone know that * binds more tightly than +, so just remember that
&& and & are the Boolean and bit-wise analogues of multiplication
whereas || and | are the analogues of +. I.e. && binds tighter
than || and & beats |. (Many maths notations use AB or A×B to mean A
and B.)

While this is a good analogy, it may be misleading because & binds less than
+

I suppose it might. It helps only for the pairs * and +, && and ||, &
and |.

<snip>

>This covers the vast majority of common cases. I also like to
remember that you can assign a conditional ('index += up ? 1 : -1' is
my canonical example), but you can't shift by an arithmetic expression
('x >(32 - bits)' requires the parentheses).

No, it does not: >binds less than + and -, but it is certainly a good idea
to use parentheses to make your intent clear for both yourself and the next
person reading the code.

Good spot. Don't know where I got that from. For some reason I
always bracket these and that must have lodged in my mind as being
required, but of course it is not.

--
Ben.