Faster for() loops?
Neo
states:for( i=0; i<10; i++){ ... }i loops through the values
0,1,2,3,4,5,6,7,8,9 If you don't care about the order of the loop counter,
you can do this instead: for( i=10; i--; ) { ... }Using this code, i loops
through the values 9,8,7,6,5,4,3,2,1,0, and the loop should be faster. This
works because it is quicker to process "i--" as the test condition, which
says "is i non-zero? If so, decrement it and continue.". For the original
code, the processor has to calculate "subtract i from 10. Is the result
non-zero? if so, increment i and continue.". In tight loops, this make a
considerable difference.
How far it holds true.. in the light of modern optimizing compilers? and
will it make a significant difference in case of embedded systems???
Thanks,
-Neo
"Do U really think, what U think real is really real?"
Al Borowski
Neo wrote:
[...] In tight loops, this make a
> considerable difference.
> How far it holds true.. in the light of modern optimizing compilers? and
> will it make a significant difference in case of embedded systems???
There is nothing like an experiment to test a theory. I just tried with
AVRGCC
void countDown(void){
int i;
for(i=10; i!=0; i--) doSomething();
}
void countUp(void){
int i;
for(i=0;i<10;i++) doSomething();
}
The generated code is
000000ce <countDown>:
}
void countDown(void){
ce: cf 93 push r28
d0: df 93 push r29
int i;
for(i=10; i!=0; i--) doSomething();
d2: ca e0 ldi r28, 0x0A ; 10
d4: d0 e0 ldi r29, 0x00 ; 0
d6: 0e 94 5d 00 call 0xba
da: 21 97 sbiw r28, 0x01 ; 1
dc: e1 f7 brne .-8 ; 0xd6
de: df 91 pop r29
e0: cf 91 pop r28
e2: 08 95 ret
000000e4 <countUp>:
}
void countUp(void){
e4: cf 93 push r28
e6: df 93 push r29
e8: c9 e0 ldi r28, 0x09 ; 9
ea: d0 e0 ldi r29, 0x00 ; 0
int i;
for(i=0;i<10;i++) doSomething();
ec: 0e 94 5d 00 call 0xba
f0: 21 97 sbiw r28, 0x01 ; 1
f2: d7 ff sbrs r29, 7
f4: fb cf rjmp .-10 ; 0xec
f6: df 91 pop r29
f8: cf 91 pop r28
fa: 08 95 ret
Counting down instead of up saves one whole instruction. It could make a
difference I suppose.
However, the compiler cannot optimise as well if anything in the loop
depends on the value of 'i'.
void countDown(void){
int i;
for(i=10; i!=0; i--) doSomething(i);
}
void countUp(void){
int i;
for(i=0;i<10;i++) doSomething(i);
}
Becomes
void countDown(void){
ce: cf 93 push r28
d0: df 93 push r29
int i;
for(i=10; i!=0; i--) doSomething(i);
d2: ca e0 ldi r28, 0x0A ; 10
d4: d0 e0 ldi r29, 0x00 ; 0
d6: ce 01 movw r24, r28
d8: 0e 94 5d 00 call 0xba
dc: 21 97 sbiw r28, 0x01 ; 1
de: d9 f7 brne .-10 ; 0xd6
e0: df 91 pop r29
e2: cf 91 pop r28
e4: 08 95 ret
000000e6 <countUp>:
}
void countUp(void){
e6: cf 93 push r28
e8: df 93 push r29
int i;
for(i=0;i<10;i++) doSomething(i);
ea: c0 e0 ldi r28, 0x00 ; 0
ec: d0 e0 ldi r29, 0x00 ; 0
ee: ce 01 movw r24, r28
f0: 0e 94 5d 00 call 0xba
f4: 21 96 adiw r28, 0x01 ; 1
f6: ca 30 cpi r28, 0x0A ; 10
f8: d1 05 cpc r29, r1
fa: cc f3 brlt .-14 ; 0xee
fc: df 91 pop r29
fe: cf 91 pop r28
100: 08 95 ret
This time there are a whole 2 extra instructions. I don't think this is
such a big deal. Unrolling the loop would give a better result.
cheers,
Al
Ian Bell
Many micros have a decrement jmp if zero (or non zero) machine instruction
so a decent optimising compiler should know this and use it in count down
to zero loops. Counting up often needs a compare followed by a jmp zero (or
non zero) which will be a tad slower.
Ian
Peter Bushell
news:4337...@news.microsoft.com...
The answer is "implementation-dependent".
A major advantage of writing in C is that you can, if you choose, write
understandable, maintainable code. This kind of hand-optimisation has the
opposite effect. If you really need to care about exactly how many
instruction cycle a loop takes, code it in assembly language. Otherwise, for
the sake of those that come after you, please write your C readably and
leave the compiler to do the optimisation. These days, most compilers can
optimise almost as well as you can, for most "normal" operations.
Regards,
--
Peter Bushell
http://www.software-integrity.com/
Skarmander
for( i=10; i--; ) finishes, i will have the value -1, since the
decrement is performed even if i is zero. This is counterintuitive, so
it's worth noting. It also means the following is not equivalent:
for (i = 10; i != 0; --i)
Since here one less decrement is performed. Incidentally, my
compiler/platform generates better code with this version -- it compares
i to -1 in the other, which is no better than comparing it to 10! If you
want to count down, I suggest writing what you mean and separating the
test and decrement parts -- it has the added bonus of making things more
readable. The rest is best left to the compiler.
S.
Scott Moore
Unroll it completely.
Roberto Waltman
>Hi Folks,http://www.abarnett.demon.co.uk/tutorial.html#FASTFOR Page
>states:for( i=0; i<10; i++){ ... }i loops through the values
>0,1,2,3,4,5,6,7,8,9 If you don't care about the order of the loop counter,
>you can do this instead: for( i=10; i--; ) { ... }Using this code, i loops
>through the values 9,8,7,6,5,4,3,2,1,0, and the loop should be faster.
>....
>How far it holds true.. in the light of modern optimizing compilers? and
>will it make a significant difference in case of embedded systems???
It may or not save a couple of assembly language instructions, (of
course depending on the compiler and processor used,) but I doubt this
"noptimization" will make any noticeable change in the performance of
a program, unless your code consist mainly of empty for() loops.
What impact can a minuscule reduction in the time required to decide
if the loop has ended or not have, if the body of the loop, for
example, call functions that format a CAN message, deliver it, wait
for a response, retry if there were errors or timeouts, decode the
response, store the values in a serial EEPROM, and based on them start
a few motors, open pneumatic valves, optionally sending an email
message to Katmandu.
That is not an optimization, but a total waste of time. Read the first
example in "Elements of programming style" and learn...
Roberto Waltman
[ Please reply to the group, ]
[ return address is invalid. ]
Joe Butler
> That is not an optimization, but a total waste of time. Read the first
> example in "Elements of programming style" and learn...
What if the difference is between fitting into memory and not?
Mark McIntyre
<timeless_il...@yahoo.com> wrote:
>Hi Folks,http://www.abarnett.demon.co.uk/tutorial.html#FASTFOR Page
>states
(that reversing loop order is faster)
The page is talking rot. It *may* be faster. It *may* be slower. The
only way to know is to benchmark your particular implementation in the
specific case you're examining.
>How far it holds true.. in the light of modern optimizing compilers? and
>will it make a significant difference in case of embedded systems???
Benchmark.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Kevin D. Quitt
cache, you want to go through incrementing addresses to maximize the use of cache.
Decrementing through memory is generally pessimal.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Christian Bau
Ian Bell <ruffr...@yahoo.com> wrote:
> Many micros have a decrement jmp if zero (or non zero) machine instruction
> so a decent optimising compiler should know this and use it in count down
> to zero loops. Counting up often needs a compare followed by a jmp zero (or
> non zero) which will be a tad slower.
The Pentium processors have a loop instruction. Every decent compiler
knows it and avoids it like hell because it runs slower than a subtract
+ compare + conditional branch :-)
Christian Bau
"Peter Bushell" <NOpeter...@SPAMsoftware-integrity.com> wrote:
> These days, most compilers can
> optimise almost as well as you can, for most "normal" operations.
Question: How can I optimise code better than the compiler?
Answer: If you ask, then you can't.
Flash Gordon
If you are hunting for that small an amount to get the program to fit
then you are in trouble anyway. Something will need changing making it
no longer fit!
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Joe Butler
If you can fit something into a cheaper processor model because you save a
couple of bytes by changing 1 or two loops, then you are not in trouble
anymore.
"Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
news:rq5m03x...@brenda.flash-gordon.me.uk...
Flash Gordon
Don't top post. Replies belong after the text you are replying to.
> "Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
> news:rq5m03x...@brenda.flash-gordon.me.uk...
>
>>Joe Butler wrote:
>>
>>>>That is not an optimization, but a total waste of time. Read the first
>>>>example in "Elements of programming style" and learn...
>>>
>>>What if the difference is between fitting into memory and not?
>>
>>If you are hunting for that small an amount to get the program to fit
>>then you are in trouble anyway. Something will need changing making it
>>no longer fit!
>>--
>>Flash Gordon
>>Living in interesting times.
>>Although my email address says spam, it is real and I read it.
Don't include peoples signatures unless you are commenting on them.
> I think I disagree.
>
> If you can fit something into a cheaper processor model because you
> save a couple of bytes by changing 1 or two loops, then you are not in
> trouble anymore.
I'll be more explicit then. EVERY SINGLE TIME I have come across a
system where people have tried to squeeze the code in believing it will
just about fit (either size or speed) one of the following has happened:
1) Customer required a subsequent change which proved to be impossible
unless the card was redesigned because there was no space for the new
code.
2) A bug fix requires some additional code and oops, there is no more
space.
3) By the time all the required stuff was added that the person who
thought it would only just fit had forgotten it did NOT fit by a mile
so it did not even come close to meeting the customers requirements
4) It turned out there were massive savings to be had else where because
of higher level problems allowing me to save far more space/time than
you could possibly save by such micro-optimisations.
Only with the third of those possibilities was it possible to meet the
requirements using the existing hardware, and meeting the requirements
involved fixing the algorithms or doing large scale changes where the
coding was just plain atrocious.
So my experience is that it is never worth bothering with such
micro-optimisations.
Joe Butler
make all the difference if a byte can be saved here and there. Afterall, 50
such 'optimisations' could amount to 10% of the total memory available. I'm
not necessarily suggesting this should be done from day 1, but have found it
useful just to get a feel for what the compiler works best with.
"Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
news:smdm03x...@brenda.flash-gordon.me.uk...
Mark VandeWettering
You could just test it.
I think it's a mistake to obfuscate your loops just for the sake of
(what is probably) executing one more instruction which in all likelihood
isn't on the critical path of your application _anyway_. If, as you say,
you don't use the loop index, you could indeed do without the one
extra compare instruction, but you'd probably benefit from loop unrolling
too.
Premature optimization is a hindrance to software development.
Mark
David Brown
> On Mon, 26 Sep 2005 12:11:23 +0530, in comp.lang.c , "Neo"
> <timeless_il...@yahoo.com> wrote:
>
>
>>Hi Folks,http://www.abarnett.demon.co.uk/tutorial.html#FASTFOR Page
>>states
>
>
> (that reversing loop order is faster)
>
> The page is talking rot. It *may* be faster. It *may* be slower. The
> only way to know is to benchmark your particular implementation in the
> specific case you're examining.
>
Actually, the page is talking rubbish about a great deal more than just
this case. It's full of generalisations that depend highly on the
compiler and target in question (the post is cross-posted to
comp.arch.embedded, so we are looking at a wide range of targets). "Use
switch instead of if...else..." (varies widely according to
target/compiler and the size of the switch), "Avoid ++, -- in while ()
expressions" (good compilers work well with such expressions), "Use
word-size variables instead of chars" (great for PPC, indifferent for
msp430, terrible for AVR), "Addition is faster than multiplication - use
'val + val + val' instead of 'val * 3' " (wrong for most compiler/target
combinations).
It's a nice idea to try to list such tips, but the page is badly out of
date, and makes all sorts of unwarranted assumptions.
So, as Mark says, benchmark your implementation. Also examine the
generated assembly code (you do understand the generated assembly? If
not, forget about such minor "optimisations".) And remember Knuth's
rules regarding such code-level optimisations:
1. Don't do it.
2. (For experts only) Don't do it yet.
Anonymous 7843
I tend to avoid this kind of loop because it's a bit less
intuitive to use with unsigned loop counters. After the
loop is done, an unsigned i would be set to some very high
implementation-defined number.
There is not much to be gained on loops that only count to
10... that extra instruction 10 times through the loop
would only add an extra 10 nanoseconds. This is likely to
pale in significance to any useful work done in the body of
the loop.
Loops that range over memory should never count backwards,
at least not when speed is important. For better or worse,
operating systems and memory caches only prefetch when
reading ascending addresses.
Dave Hansen
7843) wrote:
>In article <4337...@news.microsoft.com>,
>Neo <timeless_il...@yahoo.com> wrote:
>> for( i=10; i--; )
>> { ... }
>
>I tend to avoid this kind of loop because it's a bit less
>intuitive to use with unsigned loop counters. After the
>loop is done, an unsigned i would be set to some very high
>implementation-defined number.
FWIW, my bit-bang SPI output function looks something like
bit_ctr = 8;
do
{
Set_IO(SPI_DATA, (data&0x80) != 0);
Set_IO(SPI_CLOCK, 1);
data <<= 1;
Set_IO(SPI_CLOCK, 0);
} while (--bit_ctr);
which seems intuitive for the function at hand, and generates nearly
optimal assembly on all the platforms it's used on.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Default User
> OK, point taken.
[snip]
> "Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
> news:smdm03x...@brenda.flash-gordon.me.uk...
> > Joe Butler wrote:
> >
> > Don't top post. Replies belong after the text you are replying to.
You need to get the other point, the one about not top-posting.
Brian
Joe Butler
"Default User" <defaul...@yahoo.com> wrote in message
news:3ptmkbF...@individual.net...
Keith Thompson
I'm going to make one and only one attempt to make this clear to you.
It's arguably more than you deserve, but if you improve your posting
habits it will benefit all of us. If not, we can achieve the same
benefit by killfiling you -- which I'm sure many people already have.
We don't discourage top-posting because we like to enforce arbitrary
rules. We do so because top-posting makes articles more difficult to
read, especially in an environment like this one where bottom-posting
is a long-standing tradition. (In other words, top-posting in an
environment where it's commonly accepted is ok; top-posting where it's
not commonly accepted makes *your* article more difficult to read
because we have to make an extra effort to read a different format.)
Usenet is an asynchronous medium. Parent articles can arrive after
followups, or not arrive at all. It's important for each individual
article to be readable by itself, from top to bottom, providing as
much context as necessary from previous articles. It's not reasonable
to expect your readers to jump around within your article to
understand what you're talking about.
Quoting one of CBFalconer's sig quotes:
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
See also <http://www.caliburn.nl/topposting.html>.
I'm giving you good advice. You can believe me and follow it, or you
can ignore it and never be taken seriously here again. It's your
call.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Walter Roberson
Joe Butler <ffffh....@hotmail-spammers-paradise.com> wrote:
>OK, point taken. Although, when working with very small memories, it can
>make all the difference if a byte can be saved here and there. Afterall, 50
>such 'optimisations' could amount to 10% of the total memory available. I'm
>not necessarily suggesting this should be done from day 1, but have found it
>useful just to get a feel for what the compiler works best with.
If you are working with just 512 bytes of program memory, then you
probably should not be writing in C. C as a programming language makes
no attempt to mimimize code space. And though it is a matter outside of the
standards, most compilers prefer to trade off space for increased speed.
--
These .signatures are sold by volume, and not by weight.
Dan Henry
Where is the context? You've got me all twisted up.
>Depends what you're doing.
I'm reading Usenet articles at the moment. "Depends what..." That's
what I am doing. What...?
>If you're accessing a large chunk of memory on a system with
>cache, you want to go through incrementing addresses to maximize the use of cache.
OK, I am not doing that at this particular moment. Why are you
advising me on my disposition to go for large chunks? I do sometimes
"swing the other way" after all. You may hate me, but don't judge me!
>Decrementing through memory is generally pessimal.
I do it all the time. I'm bad, I know, but had to be told. Shame on
me.
--
Dan Henry
Flash Gordon
> prick.
>
> "Default User" <defaul...@yahoo.com> wrote in message
> news:3ptmkbF...@individual.net...
>
>>Joe Butler wrote:
<snip information on correct posting which has been ignored>
Well, one thing you seem to have learned is how to avoid getting help
when you want it. The convention of bottom posting has been established
for a long time and the reasons for it have been discussed here and else
where on many occasions, so I'm not going to debate them. Had you taken
not of the practices of this group you would have known this.
Flash Gordon
> OK, point taken. Although, when working with very small memories, it can
> make all the difference if a byte can be saved here and there. Afterall, 50
> such 'optimisations' could amount to 10% of the total memory available. I'm
> not necessarily suggesting this should be done from day 1, but have found it
> useful just to get a feel for what the compiler works best with.
If saving 50 or even 100 machine code instructions saves you 10% of
memory then you only have space for 1000 instructions and would, in my
opinion, be better off programming in assembler where you actually have
control over what happens. Otherwise you might well find changes in the
compiler and library from version to version are more significant.
> "Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
> news:smdm03x...@brenda.flash-gordon.me.uk...
>
>>Joe Butler wrote:
>>
>>Don't top post. Replies belong after the text you are replying to.
<snip>
I would refer you to the above, but based on your response to Brian I'm
guessing that you have no consideration for other users of this group.
Don't be surprised if this leaves you with only the ignorant to talk to.
Al Borowski
>>>You need to get the other point, the one about not top-posting.
>
>
> I'm going to make one and only one attempt to make this clear to you.
> It's arguably more than you deserve, but if you improve your posting
> habits it will benefit all of us. If not, we can achieve the same
> benefit by killfiling you -- which I'm sure many people already have.
<big snip>
>
> See also <http://www.caliburn.nl/topposting.html>.
See http://alpage.ath.cx/toppose/toppost.htm as well.
Thanks,
Al
Al Borowski
> See http://alpage.ath.cx/toppose/toppost.htm as well.
Oops. I can't spell.
Make that http://alpage.ath.cx/toppost/toppost.htm
Al
Joe Butler
Maybe 10% saved for a 1k memory was a bit of an exageration on my part.
I'm currently working with some inhereted AVR GNU that was incomplete, by
quite some margin, yet close to the preferred memory limit with decent debug
info, and too big to feel comfortable without the debug. Checking out the
size differences resulting from alternative ways of writing the same code
has resulted in a worthwhile amount of memory being recovered (I believe) -
i.e. I'm more relaxed about the situation now. I'm telling the compiler to
optimise for size, since speed is not a problem. Of course, if things won't
fit at the end, then I'll have to look for other optimisations, such as the
assembler suggested. It's unlikely that I'll be forced to switch to a
different version of the compiler or libs. Changing the code's architecture
and data structures results in bigger savings - I'm almost thru doing that
(for other reasons) and it looks like I'll recover over 1k of mem (out of
8k). and the resulting code is cleaner and easier to understand too.
You both probably know this through experience, but one trick I've found of
simply making a local copy of a global variable, that is used a fair bit in
a function, and then coping it back to the global afterwards saves a
reasonable amount of code size, over the more obvious code, that it makes
this particular trick worth knowing/trying when things do get tight - it's
obviously (to me now) a bigger saving if the global happens to be volatile
as well.
I have no personal problem trying these things out if it helps me to
understand what the compiler is likely to do with new code that I author
(afterall, it takes about 6 minutes to try a little trick out, which means
that it'll take about an hour to know 10 new things about the behaviour of
the compiler and to recognise oportunities, etc. in the future.) Perhaps at
the end of the project, I would have had plenty of room anyway, but, as I
said things were tight, I was feeling uneasy, and every time I wanted more
debug info, it meant choosing something else for temporary culling which was
beginning to make things thorougly difficult.
Things seem to be going 'swimmingly' now - I hope that holds up to the end.
"Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
news:e20p03x...@brenda.flash-gordon.me.uk...
Keith Thompson
Snipping attributions is considered rude. The quoted material
starting with "I'm going to make one and only one attempt" is mine.
I don't remember who write the line above that.
There is one valid point in the referenced web page (titled "In
Defence of Top Posting"):
Bottom posting without snipping irrelevant pats is at least as
annoying as a top-post.
Which is why nobody recommends bottom-posting without snipping
irrelevant parts.
Apart from that, the argument seems to be based on assumptions about
the software people use to read Usenet, and the environment in which
it runs.
Once again: Usenet is an asynchronous medium. The parent article may
not have arrived yet. It may have expired. It may never arrive at
all. I may have read it a week ago and forgotten it, and I very like
have my newsreader configured not to display articles I've already
read.
A simple command to jump to the parent article is a useful feature in
a newsreader, and one that exists in the one I use. I have no idea
which other newsreaders have such a command. That's why I try to make
each article readable by itself.
Perhaps the most telling point in the web page is:
A Threaded newsreader. These days, pretty much every PC has one.
Not everyone reads Usenet on a PC.
I realize this is cross-posted to comp.lang.c and comp.arch.embedded.
Perhaps top-posting is tolerated in comp.arch.embedded. In
comp.lang.c, we've reached a general consensus that top-posting is
discouraged, for perfectly valid reasons. And even if I *liked*
top-posting, I wouldn't do it in comp.lang.c; consistency is even more
important than the arguments in favor of a given style.
Peter Nilsson
> http://alpage.ath.cx/toppost/toppost.htm
You might like to google for "fallacious arguments".
>From your page:
"...embarked on a crusade...
"...top-posting isn't the spawn of Satan...
"...Some...mantras...
"And to those of you who act like this is a religious issue,
get a life."
The only person in bringing religion into this is yourself.
--
Peter
Al Borowski
I wrote that page some time ago in response to an argument on a
different newsgroup. The language I used was very tame compared to some
of the abuse heaped on top-posters at the time.
I'm not getting into an online debate on top-posting. That page has my
views and I won't repeat them here.
thanks,
Al
David Brown
<snip>
>
> I realize this is cross-posted to comp.lang.c and comp.arch.embedded.
> Perhaps top-posting is tolerated in comp.arch.embedded. In
> comp.lang.c, we've reached a general consensus that top-posting is
> discouraged, for perfectly valid reasons. And even if I *liked*
> top-posting, I wouldn't do it in comp.lang.c; consistency is even more
> important than the arguments in favor of a given style.
>
Top-posting is strongly discouraged in comp.arch.embedded as well. It's
not as bad as google groups posts that fail to include any context,
however, which seems to be considered the worst sin at the moment (I'm
not sure where posting in html ranks these days - I haven't seen any
html posts here for a while).
David.
Flash Gordon
> To Flash and Walter,
>
> Maybe 10% saved for a 1k memory was a bit of an exageration on my part.
If it's less then it is even less worth while.
<snip>
> different version of the compiler or libs. Changing the code's architecture
> and data structures results in bigger savings - I'm almost thru doing that
> (for other reasons) and it looks like I'll recover over 1k of mem (out of
> 8k). and the resulting code is cleaner and easier to understand too.
Which just goes to show that you should concentrate on high level
optimisations not micro-optimisations.
> You both probably know this through experience, but one trick I've found of
> simply making a local copy of a global variable, that is used a fair bit in
> a function, and then coping it back to the global afterwards saves a
> reasonable amount of code size, over the more obvious code,
I've used processors where it would be one instruction to set up the
offset then another to read/write the value for a local as compared to
in the worst case a single instruction the same size as that pair of
instructions for a global. Of course, the compiler optimisations make
this irrelevant with most compilers since they will keep it in a
register if it is used much.
> that it makes
> this particular trick worth knowing/trying when things do get tight - it's
> obviously (to me now) a bigger saving if the global happens to be volatile
> as well.
If it is volatile you are significantly changing the semantics, so
either the original code was wrong or your "optimised" code is wrong.
> I have no personal problem trying these things out if it helps me to
> understand what the compiler is likely to do with new code that I author
> (afterall, it takes about 6 minutes to try a little trick out, which means
> that it'll take about an hour to know 10 new things about the behaviour of
> the compiler and to recognise oportunities, etc. in the future.)
All that you learn about micro-optimisation on one system you have to
forget on the next where your "optimisations" actually make it worse.
Also, if your optimisations make the code harder to read you have just
increased the cost to the company of maintenance, and since maintenance
is often a major part of the cost of SW over its lifetime this is not good.
> Perhaps at
> the end of the project, I would have had plenty of room anyway, but, as I
> said things were tight, I was feeling uneasy, and every time I wanted more
> debug info, it meant choosing something else for temporary culling which was
> beginning to make things thorougly difficult.
It would almost certainly have saved you time and effort to restructure
the code and optimise the algorithms first (which you say you are doing)
since then you would not have found the need for "temporary culling"
because you have already admitted that it is saving you a significant
amount.
> Things seem to be going 'swimmingly' now - I hope that holds up to the end.
Not really. You included in your message that restructuring is saving
you a vast amount of space which is further evidence that you should
always start at the algorithm and work down, not start with
micro-optimisation.
> "Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
> news:e20p03x...@brenda.flash-gordon.me.uk...
<snip>
For continual refusal to post properly despite being informed that top
posting is not accepted here...
*PLONK*
Joe Butler
> Joe Butler wrote:
> > To Flash and Walter,
> >
> > Maybe 10% saved for a 1k memory was a bit of an exageration on my part.
>
> If it's less then it is even less worth while.
If you say so. It seems to me that I've just given myself a bit more memory
to play with in a tight situation.
>
> <snip>
>
> > different version of the compiler or libs. Changing the code's
architecture
> > and data structures results in bigger savings - I'm almost thru doing
that
> > (for other reasons) and it looks like I'll recover over 1k of mem (out
of
> > 8k). and the resulting code is cleaner and easier to understand too.
>
> Which just goes to show that you should concentrate on high level
> optimisations not micro-optimisations.
Yes, that's correct. It does not mean, so-called micro-optimisations should
not be attempted.
>
> > You both probably know this through experience, but one trick I've found
of
> > simply making a local copy of a global variable, that is used a fair bit
in
> > a function, and then coping it back to the global afterwards saves a
> > reasonable amount of code size, over the more obvious code,
>
> I've used processors where it would be one instruction to set up the
> offset then another to read/write the value for a local as compared to
> in the worst case a single instruction the same size as that pair of
> instructions for a global. Of course, the compiler optimisations make
> this irrelevant with most compilers since they will keep it in a
> register if it is used much.
Well, in my case, GNU didn't seem to choose this optimisation - so, the
trick saved some bytes - that's indisputable, and as far as I can see, odd
that you'd want to dismiss the idea.
>
> > that it makes
> > this particular trick worth knowing/trying when things do get tight -
it's
> > obviously (to me now) a bigger saving if the global happens to be
volatile
> > as well.
>
> If it is volatile you are significantly changing the semantics, so
> either the original code was wrong or your "optimised" code is wrong.
I don't think so. The code is in an ISR. While the ISR is running, the
global won't be changed externally. The little trick saved something like
28 bytes and yet the global was only touched twice, if I remember correctly.
However, if someone has a counter example, I would be interested in knowing.
>
> > I have no personal problem trying these things out if it helps me to
> > understand what the compiler is likely to do with new code that I author
> > (afterall, it takes about 6 minutes to try a little trick out, which
means
> > that it'll take about an hour to know 10 new things about the behaviour
of
> > the compiler and to recognise oportunities, etc. in the future.)
>
> All that you learn about micro-optimisation on one system you have to
> forget on the next where your "optimisations" actually make it worse.
Perhaps. Yet, for very little effort, I have given myself more room to play
with in the current system, I've got a better feeling for the compiler's
quirks, and have saved (with just a few micro-optimisations) about 250-bytes
(out of 8k) - that's plenty more to extend an existing parameter look up
table built into the system in both directions (thus increasing the
versitility of the system), or to include more human-readable debug output
and even to use more sophisticated code for some other operations that are
yet to be written. So, as far as I can see, I've gained by this exercise.
I've given myself an advantage, and you are still telling me it was next to
worthless because it comes under the lable 'micro-optimisation' or
'premature optimisation' - to me, it's just an achieved gain.
> Also, if your optimisations make the code harder to read you have just
> increased the cost to the company of maintenance, and since maintenance
> is often a major part of the cost of SW over its lifetime this is not
good.
Errm, in this case, I don't think the code is harder to read - it's
straighforward C-code - nothing particularly difficult. There are ample
comments documenting reasons for some of the slightly none-obvious ways of
doing something, along with the 'obvious' code snippet for ready-reference.
The code will go into a mass-produced product that is to be thorougly tested
before release - maintenance is not an option.
>
> > Perhaps at
> > the end of the project, I would have had plenty of room anyway, but, as
I
> > said things were tight, I was feeling uneasy, and every time I wanted
more
> > debug info, it meant choosing something else for temporary culling which
was
> > beginning to make things thorougly difficult.
>
> It would almost certainly have saved you time and effort to restructure
> the code and optimise the algorithms first (which you say you are doing)
> since then you would not have found the need for "temporary culling"
> because you have already admitted that it is saving you a significant
> amount.
I can't see this. I've positively gained thru this exercise. I have not
lost anything.
>
> > Things seem to be going 'swimmingly' now - I hope that holds up to the
end.
>
> Not really. You included in your message that restructuring is saving
> you a vast amount of space which is further evidence that you should
> always start at the algorithm and work down, not start with
> micro-optimisation.
It looks like I will save about 1k with the restructure (but I cannot tell
for sure until I get the full re-structure into the embedded compiler - I'm
currently writing and testing the restructured part under Windows). So, the
'micro-optimisations' would amount to another 25% on top of that - hardly a
worthless effort, wouln't you say.
Robert Scott
<da...@westcontrol.removethisbit.com> wrote:
>Top-posting is strongly discouraged in comp.arch.embedded as well...
It amazes me how some people can claim to speak for the whole group
with no documentation at all. I, for one, appreciate top-posting when
it is appropriate. At least I won't claim to speak for a whole group
who did not elect me to represent them.
-Robert Scott
Ypsilanti, Michigan
pete
I don't like top posting.
--
pete
Default User
> prick.
*plonk*
Brian
Steve at fivetrees
news:433aa761...@news.provide.net...
For the record, I simply don't care. I'm happy to make allowances for all
kinds. Life's too short.
Mark McIntyre
<ffffh....@hotmail-spammers-paradise.com> wrote:
>To Flash and Walter,
Are you clinically thick? You're /still/ top posting. In CLC thats the
height of rudeness. Stop it.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Mark McIntyre
For what its worth, arguments based on threading are bunk. Thread
members arrive out-of-order, not at all, and disappear from servers.
And arguments based on catering for cretinous users who're too thick
to snip are hardly likely to impress smart people...
I slightly agree with your conclusions tho. I'd modify (1) and (2) as
follows
1) Top Post (and totally remove the old message) if you are only
making 1 brief point which has no relation to any of the old message.
And then ask yourself why the hell you're replying to this post with
an irrelevant remark.
2) otherwise middle post
Richard Henry
"Dave Hansen" <id...@hotmail.com> wrote in message
news:1127846384.a408ac38deacc6faada150be098c0112@teranews...
A little alarm goes off in my brain every time I see an arithmetic variable
(bit_ctr) used as the parameter of a logical expression (while).
The following line better expresses what I think you mean:
while (--bit_ctr != 0);
The compiler optimizer may well deliver the same machine code for both
methods.
And please don't let me get started with the use of NULL pointers in similar
situations.
toby
Joe Butler wrote:
> >
> > That is not an optimization, but a total waste of time. Read the first
> > example in "Elements of programming style" and learn...
>
> What if the difference is between fitting into memory and not?
The answer to that is the same remedy offered to all sufferers of
premature optimisation: Measure First.
toby
David Brown wrote:
> ..."Use
> word-size variables instead of chars" (great for PPC, indifferent for
> msp430, terrible for AVR),
Catastrophic for PIC18.
> "Addition is faster than multiplication - use
> 'val + val + val' instead of 'val * 3' " (wrong for most compiler/target
> combinations).
And the implication is especially wrong for any val*n where n>3.
--T
Keith Thompson
[...]
> I slightly agree with your conclusions tho. I'd modify (1) and (2) as
> follows
>
> 1) Top Post (and totally remove the old message) if you are only
> making 1 brief point which has no relation to any of the old message.
> And then ask yourself why the hell you're replying to this post with
> an irrelevant remark.
Top-posting is posting new text *above* any quoted text; if there is
no quoted text, it's not top-posting (or at best it's a degenerate
case that could as easily be called bottom-posting or middle-posting).
What you're describing is, or should be, simply posting a new article.
> 2) otherwise middle post
--
Keith Thompson
> "Dave Hansen" <id...@hotmail.com> wrote in message
> news:1127846384.a408ac38deacc6faada150be098c0112@teranews...
>> FWIW, my bit-bang SPI output function looks something like
>>
>> bit_ctr = 8;
>> do
>> {
>> Set_IO(SPI_DATA, (data&0x80) != 0);
>> Set_IO(SPI_CLOCK, 1);
>> data <<= 1;
>> Set_IO(SPI_CLOCK, 0);
>>
>> } while (--bit_ctr);
>>
>> which seems intuitive for the function at hand, and generates nearly
>> optimal assembly on all the platforms it's used on.
>
> A little alarm goes off in my brain every time I see an arithmetic variable
> (bit_ctr) used as the parameter of a logical expression (while).
>
> The following line better expresses what I think you mean:
> while (--bit_ctr != 0);
>
> The compiler optimizer may well deliver the same machine code for both
> methods.
>
> And please don't let me get started with the use of NULL pointers in similar
> situations.
I tend to agree, in that I try to use only expressions that are
logically Boolean values as conditions, adding an explicit comparison
for anything else. But things like "while (--bit_ctr)", "if (ptr)",
and "if (!ptr)" are common C idioms. You might consider disconnecting
the little alarm in your brain, or at least turning down the volume.
The set of C code that you can easily read should be much wider than
the set of C code that you'd be willing to write.
Christian Bau
"Richard Henry" <rph...@home.com> wrote:
> "Dave Hansen" <id...@hotmail.com> wrote in message
> news:1127846384.a408ac38deacc6faada150be098c0112@teranews...
> > FWIW, my bit-bang SPI output function looks something like
> >
> > bit_ctr = 8;
> > do
> > {
> > Set_IO(SPI_DATA, (data&0x80) != 0);
> > Set_IO(SPI_CLOCK, 1);
> > data <<= 1;
> > Set_IO(SPI_CLOCK, 0);
> >
> > } while (--bit_ctr);
> >
> > which seems intuitive for the function at hand, and generates nearly
> > optimal assembly on all the platforms it's used on.
>
> A little alarm goes off in my brain every time I see an arithmetic variable
> (bit_ctr) used as the parameter of a logical expression (while).
>
> The following line better expresses what I think you mean:
> while (--bit_ctr != 0);
>
> The compiler optimizer may well deliver the same machine code for both
> methods.
>
> And please don't let me get started with the use of NULL pointers in similar
> situations.
Well, if anyone writes code like
> > char* p = /* whatever */
> > do
> > {
> > /* somestuff */
> >
> > } while (--p);
then they will get what they deserve!
toby
Christian Bau wrote:
> ...
> Well, if anyone writes code like
>
> > > char* p = /* whatever */
> > > do
> > > {
> > > /* somestuff */
> > >
> > > } while (--p);
>
> then they will get what they deserve!
Do you really think
for( p = /*whatever*/ ; p ; --p ){
/*somestuff*/
}
is any better?
Of course, the idea of counting a *pointer* down to NULL is rather
implausible in real code. Maybe you intended an integer variable.
Richard Henry
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnfyro2...@nuthaus.mib.org...
I read it ok. I can see that it will work. But when I encounter these
situations, I just stop to think "What will happen here? How can this go
wrong?"
Skarmander
eventually yield a null pointer? Could this loop forever or does it
summon nasal demons?
S.
toby
It's not guaranteed by the standard but on all implementations I know
of, it will eventually get there, unless of course, p isn't a multiple
of sizeof(*p) to begin with ;-) -- which can only arise through
naughtiness anyway.
>
> S.
toby
toby wrote:
> Skarmander wrote:
> > toby wrote:
> > >...
> > > Do you really think
> > >
> > > for( p = /*whatever*/ ; p ; --p ){
> > > /*somestuff*/
> > > }
> > >
> > > is any better?
> > >
> > > Of course, the idea of counting a *pointer* down to NULL is rather
> > > implausible in real code. Maybe you intended an integer variable.
> > >
> > Hold on there. Is there any guarantee that any amount of -- applications
> > eventually yield a null pointer? Could this loop forever or does it
> > summon nasal demons?
>
> It's not guaranteed by the standard but on all implementations I know
> of, it will eventually get there, unless of course, p isn't a multiple
> of sizeof(*p) to begin with ;-) -- which can only arise through
> naughtiness anyway.
...Or unless a runtime exception (such as alignment or protection
fault) intervenes.
>
> >
> > S.
Keith Thompson
> Skarmander wrote:
>> toby wrote:
>> > Christian Bau wrote:
>> >
>> >>...
>> >>Well, if anyone writes code like
>> >>
>> >>
>> >>>> char* p = /* whatever */
>> >>>> do
>> >>>> {
>> >>>> /* somestuff */
>> >>>>
>> >>>> } while (--p);
>> >>
>> >>then they will get what they deserve!
>> >
>> >
>> > Do you really think
>> >
>> > for( p = /*whatever*/ ; p ; --p ){
>> > /*somestuff*/
>> > }
>> >
>> > is any better?
>> >
>> > Of course, the idea of counting a *pointer* down to NULL is rather
>> > implausible in real code. Maybe you intended an integer variable.
I suspect, based on his "then they will get what they deserve!", that
he really was referring to counting down a pointer.
>> Hold on there. Is there any guarantee that any amount of -- applications
>> eventually yield a null pointer? Could this loop forever or does it
>> summon nasal demons?
>
> It's not guaranteed by the standard but on all implementations I know
> of, it will eventually get there, unless of course, p isn't a multiple
> of sizeof(*p) to begin with ;-) -- which can only arise through
> naughtiness anyway.
It's more than "not guaranteed by the standard". Repeatedly
decrementing a pointer will invoke undefined behavior as soon as the
location it points to is no longer within the original object. It may
happen to "work" on many systems; such is the nature of undefined
behavior.
Incidentally, there's no requirement for p to be a multiple of
sizeof(*p) (unless sizeof(*p)==1, of course). If the designated type
is sufficiently large, its required alignment is almost certainly
smaller than its size (1024-byte structures don't have to be aligned
on 1024-byte boundaries). Even for smaller types, alignment
requirements are system-specific; there's nothing non-conforming about
allowing 2-byte or 4-byte integers to be allocated on odd addresses.
Steve at fivetrees
news:840mj19ap7nskq10s...@4ax.com...
> On Wed, 28 Sep 2005 03:29:35 +0100, in comp.lang.c , "Joe Butler"
> <ffffh....@hotmail-spammers-paradise.com> wrote:
>
>>To Flash and Walter,
>
> Are you clinically thick? You're /still/ top posting. In CLC thats the
> height of rudeness. Stop it.
Who gives a shit? Why insult people over a minor matter of protocol? Sheesh!
Steve at fivetrees
news:3q0f1lF...@individual.net...
>
> A little alarm goes off in my brain every time I see an arithmetic
> variable
> (bit_ctr) used as the parameter of a logical expression (while).
>
> The following line better expresses what I think you mean:
> while (--bit_ctr != 0);
Whoa. As others have observed, --value/value-- as a boolean test is a common
idiom in C - check K&R's version of strcpy for an example.
There comes a point where one can be *too* explicit. I remember arguing over
a coding standards document with someone who insisted that all boolean tests
should be tested for equality with TRUE or FALSE (previously defined in
their own pet/preferred fashion, of course) - hence:
if ( boolean_flag == TRUE )
where I would have argued that:
if ( boolean_flag )
was safer, since it didn't depend on a specific value of TRUE. I pointed out
that his argument could be extended to:
if (((( boolean_flag == TRUE ) == TRUE ) == TRUE ) == TRUE ) // etc
which seemed dumb to me. He didn't understand the point.
> And please don't let me get started with the use of NULL pointers in
> similar
> situations.
That's a whole different situation, and not relevant/applicable to the
above.
Skarmander
<snip>
> There comes a point where one can be *too* explicit. I remember arguing over
> a coding standards document with someone who insisted that all boolean tests
> should be tested for equality with TRUE or FALSE (previously defined in
> their own pet/preferred fashion, of course) - hence:
>
> if ( boolean_flag == TRUE )
>
> where I would have argued that:
>
> if ( boolean_flag )
>
> was safer, since it didn't depend on a specific value of TRUE.
Yeah. Provided TRUE wasn't defined as, you know, 0. Of course you'd have
to be stupid or perverse to do that. But you did say "defined in their
own pet/preferred fashion".
> I pointed out that his argument could be extended to:
>
> if (((( boolean_flag == TRUE ) == TRUE ) == TRUE ) == TRUE ) // etc
>
> which seemed dumb to me. He didn't understand the point.
>
<snip>
Probably because (boolean_flag == TRUE) invokes == to yield a "C
boolean", which is by definition good to go in an if statement. No
further comparison necessary.
Mind you, I'm not encouraging or defending any of this. I'm not willing
to go any further than
typedef enum {false, true} bool;
But then, better use #define, or otherwise everything will break when
someone else defines the exact same enum. Sigh...
This is why I usually stick to 0, 1, and remembering when an int is used
as a pure boolean. "Extending" the language this way isn't worth it.
C99's bool is way overdue, but at least it's there.
S.
Richard Henry
"Steve at fivetrees" <st...@NOSPAMTAfivetrees.com> wrote in message
news:k_6dnXgkd6b...@pipex.net...
The use of a boolean flag as the target parameter of a boolean expression is
of course completely appropriate. What I was whining about (I admit it is a
pointless whine) was using an arithmetic object, as in if(--index). What
that really means is "if the decremented index now equals 0" and just takes
advantage of the fact that the if operator (or while operator) in C is
hinged on the 0 value (from the ubiquitous JMPZ (or similar) operator, I
would suppose). While it is correct in C grammar, and will "always work",
it is not clear what you mean by that. The longer statement if(--index ==
0) (or in better style, if (0 == --index)) gets the same result, possible in
the same amount of machine code, and is explicit about its meaning.
As for pointers: I was not talking about decrementing pointers, but their
use in while( and if( statements as above. When you write
if(ptr)
{
//do something
}
what you really mean is
if(ptr != NULL)
{
//do something
}
Jim Granville
> "Richard Henry" <rph...@home.com> wrote in message
> news:3q0f1lF...@individual.net...
>
>>A little alarm goes off in my brain every time I see an arithmetic
>>variable
>>(bit_ctr) used as the parameter of a logical expression (while).
>>
>>The following line better expresses what I think you mean:
>> while (--bit_ctr != 0);
>
>
> Whoa. As others have observed, --value/value-- as a boolean test is a common
> idiom in C - check K&R's version of strcpy for an example.
>
> There comes a point where one can be *too* explicit. I remember arguing over
> a coding standards document with someone who insisted that all boolean tests
> should be tested for equality with TRUE or FALSE (previously defined in
> their own pet/preferred fashion, of course) - hence:
>
> if ( boolean_flag == TRUE )
>
> where I would have argued that:
>
> if ( boolean_flag )
>
> was safer, since it didn't depend on a specific value of TRUE.
I'd agree the TRUE and FALSE instance are pedantic, but THIS form
if ( boolean_flag == RlyON )
can be safer and simpler, as any downstream logic inversion is
handled transparently.
Here, you have a common define setting RlyON is active Hi or Lo,
but the code is always clearer. ( and that may change with
PCB revision, for example )
Also note that not all compilers treat these the same !!
if ( boolean_flag == TRUE )
if ( boolean_flag )
-jg
toby
Keith Thompson wrote:
> "toby" <to...@telegraphics.com.au> writes:
> > Skarmander wrote:
> >> toby wrote:
> >> > Christian Bau wrote:
> >> >
> >> >>...
> >> >>Well, if anyone writes code like
> >> >>
> >> >>
> >> >>>> char* p = /* whatever */
> >> >>>> do
> >> >>>> {
> >> >>>> /* somestuff */
> >> >>>>
> >> >>>> } while (--p);
> >> >>
> >> >>then they will get what they deserve!
> >> >
> >> >
> >> > Do you really think
> >> >
> >> > for( p = /*whatever*/ ; p ; --p ){
> >> > /*somestuff*/
> >> > }
> >> >
> >> > is any better?
> >> >
> >> > Of course, the idea of counting a *pointer* down to NULL is rather
> >> > implausible in real code. Maybe you intended an integer variable.
>
> I suspect, based on his "then they will get what they deserve!", that
> he really was referring to counting down a pointer.
>
> >> Hold on there. Is there any guarantee that any amount of -- applications
> >> eventually yield a null pointer? Could this loop forever or does it
> >> summon nasal demons?
> >
> > It's not guaranteed by the standard but on all implementations I know
>
> It's more than "not guaranteed by the standard". Repeatedly
> decrementing a pointer will invoke undefined behavior as soon as the
> location it points to is no longer within the original object. It may
Which is all I intended to say. The code snippet made no real sense as
a pointer. I think the poster may have meant an integral type.
>
> Incidentally, there's no requirement for p to be a multiple of
> sizeof(*p) (unless sizeof(*p)==1, of course). ...
Agreeed there is no 'requirement', but as I said, the loop will not
actually terminate at NULL (on implementations where it happens to work
at all -- i.e. most of the ones we know) unless that condition is met.
Chris Torek
>Mark McIntyre <markmc...@spamcop.net> wrote:
>>For what its worth, arguments based on threading are bunk. Thread
>>members arrive out-of-order, not at all, and disappear from servers.
In article <missing@missing>, missing wrote:
>And sometimes the intermediates go missing entirely.
As in this case.
(Which, I admit, I faked. :-) But I have read followups to which
the ancestor was missing, and in many cases, the followup was
incomprehensible as a result.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
David Brown
I can't claim to speak for everyone in the group, obviously. Every
newsgroup post has an implicit "IMHO" attached. But I think it's a fair
summary of the opinions of the group, or at least of those who post
regularly. And very few people object to top-posting when it is
appropriate - it is just the definition of "appropriate" that they
disagree on...
Anyway, the key point with posting etiquette is to be (reasonably)
polite and informative, and to remember it's a conversation between real
people. If, as is normally the case, top-posting makes it unnecessarily
harder for people to follow the sense of a post, then it is impolite and
uninformative, just like posting in SMS or all caps. If top-posting
makes a reply easier to read, then it is appropriate (although usually
snipping would be far better).
pete
I prefer to compare Boolean values against zero or FALSE.
if (boolean_flag != 0)
means just exactly the same thing as
if ( boolean_flag )
and should be easy enough to read.
--
pete
pete
Actually, with values of a boolean nature,
I prefer to do it Steve's way:
#include <ctype.h>
int a_toi(const char *nptr)
{
int n;
n = 0;
while (isspace(*nptr)) {
++nptr;
}
if (*nptr != '-') {
if (*nptr == '+') {
++nptr;
}
while (isdigit(*nptr)) {
n = 10 * n - '0' + *nptr++;
}
} else {
++nptr;
while (isdigit(*nptr)) {
n = 10 * n + '0' - *nptr++;
}
}
return n;
}
--
pete
Default User
> "Mark McIntyre" <markmc...@spamcop.net> wrote in message
> news:840mj19ap7nskq10s...@4ax.com...
> > On Wed, 28 Sep 2005 03:29:35 +0100, in comp.lang.c , "Joe Butler"
> ><ffffh....@hotmail-spammers-paradise.com> wrote:
> >
> > > To Flash and Walter,
> >
> > Are you clinically thick? You're still top posting. In CLC thats the
> > height of rudeness. Stop it.
>
> Who gives a shit? Why insult people over a minor matter of protocol?
> Sheesh!
>
> Steve
> http://www.fivetrees.com
Don't disrespect our group wishes.
*plonk*
Brian
--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.
Keith Thompson
I'll ignore, for now, the built-in type _Bool and the standard header
<stdbool.h> introduced in C99.
A value used as a condition in C is treated as false if it's equal to
zero, true if it's non-zero. It's not 0 vs. 1, it's 0 vs. anything
other than 0.
If your variable "boolean_flag" is something other than zero-is-false,
non-zero-is-true, it shouldn't be called "boolean_flag".
Assuming boolean_flag is a proper condition, "boolean_flag == TRUE"
isn't just pedantic, it's positively dangerous. The relational
operators always yield 0 or 1, but other boolean expressions can have
any non-zero value; for example, the is*() functions in <ctype.h>
return 0 for false, but can return any arbitrary non-zero value for
true.
> Also note that not all compilers treat these the same !!
>
> if ( boolean_flag == TRUE )
> if ( boolean_flag )
Any compiler that does treat them the same is badly broken (unless the
compiler is able to prove that the value of boolean_flag is either 0
or 1).
This is a different issue from using something that's not a
boolean flag as a condition, such as "if (!ptr)" rather than
"if (ptr == NULL)", or "if (count)" rather than "if (count != 0)".
I prefer the more explicit comparison, but both forms are perfectly
valid and equally safe.
See also section 9 of the C FAQ.
Steve at fivetrees
news:3q2qf5F...@individual.net...
> Steve at fivetrees wrote:
>
>> "Mark McIntyre" <markmc...@spamcop.net> wrote in message
>> news:840mj19ap7nskq10s...@4ax.com...
>> > On Wed, 28 Sep 2005 03:29:35 +0100, in comp.lang.c , "Joe Butler"
>> ><ffffh....@hotmail-spammers-paradise.com> wrote:
>> >
>> > > To Flash and Walter,
>> >
>> > Are you clinically thick? You're still top posting. In CLC thats the
>> > height of rudeness. Stop it.
>>
>> Who gives a shit? Why insult people over a minor matter of protocol?
>> Sheesh!
>
Oh, so calling someone "clinically thick" over something so trivial is
somehow respectful?
Show some respect for others. *Then* you'd be entitled to talk to me on the
subject.
Joe Butler
If you are going to "*plonk*", why do you have to broadcast it. That's the
equivalent of putting your fingers in your ears and going, baaaa! bblaah!
I'm not listening!
Plonker.
"Default User" <defaul...@yahoo.com> wrote in message
news:3q2qf5F...@individual.net...
Steve at fivetrees
>
> Assuming boolean_flag is a proper condition, "boolean_flag == TRUE"
> isn't just pedantic, it's positively dangerous.
Exactly my point. Thanks for making it clearer than I managed to ;).
Richard Henry
Keith Thompson
I suggest you take a look at this thread to see what really happened.
Joe Butler was asked not to top-post. He replied with a top-posted
followup. Someone else again reminded him not to top-post. His
response, in article <4339ae2f$0$32652$da0f...@news.zen.co.uk>, was,
and I quote, "prick." (and it was, of course, top-posted).
There are good reasons for our convention (here in comp.lang.c) of
discouraging top-posting; I won't repeat them here. There are also
good reasons for not insulting people who are offering good advice.
If you've come into the middle of this discussion, it might not be
clear what's going on; groups.google.com can help you.
I suggest we drop this. I don't believe there are any relevant points
that haven't already been made.
Christian Bau
Skarmander <inv...@dontmailme.com> wrote:
Well, "toby" snipped too much of the previous post. What I wrote makes
only sense when you can read the bits that he removed as well.
(Hint: The last line of a joke is usually not very funny if the
beginning is missing).
Christian Bau
Keith Thompson <ks...@mib.org> wrote:
> "toby" <to...@telegraphics.com.au> writes:
> > Skarmander wrote:
> >> toby wrote:
> >> > Christian Bau wrote:
> >> >
> >> >>...
If you could see what toby replaced with three dots, then my post would
have made much more sense.
> >> >>Well, if anyone writes code like
> >> >>
> >> >>
> >> >>>> char* p = /* whatever */
> >> >>>> do
> >> >>>> {
> >> >>>> /* somestuff */
> >> >>>>
> >> >>>> } while (--p);
> >> >>
> >> >>then they will get what they deserve!
> >> >
> >> >
> >> > Do you really think
> >> >
> >> > for( p = /*whatever*/ ; p ; --p ){
> >> > /*somestuff*/
> >> > }
> >> >
> >> > is any better?
> >> >
> >> > Of course, the idea of counting a *pointer* down to NULL is rather
> >> > implausible in real code. Maybe you intended an integer variable.
>
> I suspect, based on his "then they will get what they deserve!", that
> he really was referring to counting down a pointer.
I suspect that "toby" didn't get the joke that was there before he
snipped the part that I had been responding to.
Steve at fivetrees
>
> Joe Butler was asked not to top-post. He replied with a top-posted
> followup. Someone else again reminded him not to top-post. His
> response, in article <4339ae2f$0$32652$da0f...@news.zen.co.uk>, was,
> and I quote, "prick." (and it was, of course, top-posted).
Ah. Mea culpa. If the disrespect I reacted to was in response to insulting
behaviour, then I apologise for leaping to the defence of the offender.
> There are good reasons for our convention (here in comp.lang.c) of
> discouraging top-posting; I won't repeat them here. There are also
> good reasons for not insulting people who are offering good advice.
Fully agreed.
FWIW: I understand and agree with the reasons for discouraging top-posting.
However I've grown far more tired of the flamefests that result from
top-posting than of top-posting itself. My patience ran out when I saw what
I thought was an over-the-top response. I was wrong; I apologise.
Christian Bau
"toby" <to...@telegraphics.com.au> wrote:
I think my post was mangled by some stupid idiot with a room temperature
IQ. And I mean Celsius.
Walter Banks
Default User wrote:
> Joe Butler wrote:
>
> > OK, point taken.
>
> [snip]
>
> > "Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
> > news:smdm03x...@brenda.flash-gordon.me.uk...
> > > Joe Butler wrote:
> > >
> > > Don't top post. Replies belong after the text you are replying to.
>
> You need to get the other point, the one about not top-posting.
>
> Brian
Anonymous 7843
I made it out of clay
And when it's dry and ready
Then dreidel I shall play!
It has a lovely body
With legs so short and thin
And when my dreidel's tired
It drops and then I win!
Oh dreidel, dreidel, dreidel
I made it out of clay
And when it's dry and ready
Then dreidel I shall play!
My dreidel's always playful
It loves to dance and spin
A happy game of dreidel
Come play now, let's begin!
Oh dreidel, dreidel, dreidel
I made it out of clay
And when it's dry and ready
Then dreidel I shall play!
Joe Butler
Althought I don't know how to verify this, I suspect many 100s, perhaps
1000s, of people read these posts.
Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
10,000? Who knows. That suggests to me that the vast majority of people
don't give a damn. Probably, like me, the vast majority are easily able to
deal with all the forms of posting and it is, therefore, not an issue for
them.
I understand that top-posting annoys some people. For me, when someone
who's only contribution is to butt in with something along the lines of
"space corp. directive one ex delta nine has been violated", that is
infinitely more annoying than any other person's posting style.
The only input 'Default User' (prick) gave at that point was, "You need to
get the other point, the one about not top-posting". If Default User had
any sense, he would have realised that I had chosen to ignore the advice
about top-posting, that it was not the first time that I had been told and,
therefore, it was a pretty pointless exercise to step in at that point.
Sincere regards to everyone.
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnfyrny...@nuthaus.mib.org...
toby
Apologies, you're right: I didn't realise that the error was
intentional. Too subtle for me at that moment...
--T
Tom
> Let's put this into perspective.
>
> Althought I don't know how to verify this, I suspect many 100s, perhaps
> 1000s, of people read these posts.
>
> Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
> 10,000? Who knows. That suggests to me that the vast majority of people
> don't give a damn. Probably, like me, the vast majority are easily able to
> deal with all the forms of posting and it is, therefore, not an issue for
> them.
Don't know about majority, personally when I see a post that hard to
make sense of I'll just skip it and jump to next one...
Tom
Mark McIntyre
<ks...@mib.org> wrote:
>Mark McIntyre <markmc...@spamcop.net> writes:
>[...]
>> I slightly agree with your conclusions tho. I'd modify (1) and (2) as
>> follows
>>
>> 1) Top Post (and totally remove the old message) if you are only
>> making 1 brief point which has no relation to any of the old message.
>> And then ask yourself why the hell you're replying to this post with
>> an irrelevant remark.
>
>Top-posting is posting new text *above* any quoted text; if there is
>no quoted text, it's not top-posting (or at best it's a degenerate
>case that could as easily be called bottom-posting or middle-posting).
>What you're describing is, or should be, simply posting a new article.
My point exactly.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Bob
news:90%_e.1371$96.1...@nasal.pacific.net.au...
Agreed. Life is too short to waste time un-mangling the conversation.
I have already kill-filed Joe Butler. (yes, I know that's is a rude thing to
say - it's part of my point, here) I have no idea how many more of the 100s
or 1000s who read c.a.e and c.l.c have also done so.
Oddly, the first post I see in this thread from him he has snipped and
bottom posted (unfortunately, without proper attribution for what he was
responding to). It is only his later posts that flaunt the etiquette of
these groups.
Bob
Michael N. Moran
> Let's put this into perspective.
>
> Althought I don't know how to verify this, I suspect many 100s, perhaps
> 1000s, of people read these posts.
>
> Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
Make that 4. I suspect that many others controlling themselves
and just waiting for this recurring flamefest to die.
Who knows why you cannot simply comply with the customs
of these groups. They are among the best usenet has to
offer.
<sigh>
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Paul Marciano
Robert Scott wrote:
> It amazes me how some people can claim to speak for the whole group
> with no documentation at all. I, for one, appreciate top-posting when
> it is appropriate.
Indeed. Having just read the thread it has only just dawned on me
(after 18 years reading USENET) what "top posting" is. I always
thought it was posting a reply to the first message in a thread instead
of replying to the specific one you were answering - something that
would throw anyone off the trail... especially with threadded
newsreaders.
But now it appears it's something so small - the order of text within a
message. My God... how anal some people are. Ok, that's unfair, but
only just.
I can see how a top-posting may be harder to speed-read than a
bottom-posting but kill files? Abuse? Posting nagging comments to the
thread without actually furthering the discussion?
You know, people are clever. They can figure out messages. I don't
see how your personal quests do anything but make you feel important.
I don't know. This thread amazes me. It simply amazes me.
Keith Thompson
> Robert Scott wrote:
>> It amazes me how some people can claim to speak for the whole group
>> with no documentation at all. I, for one, appreciate top-posting when
>> it is appropriate.
> I can see how a top-posting may be harder to speed-read than a
> bottom-posting but kill files? Abuse? Posting nagging comments to the
> thread without actually furthering the discussion?
Take a look at the context in groups.google.com. One poster (initials
JB) was asked not to top-post. He made a top-posted followup. He was
reminded again. He replied with personal abuse, and has continued to
do so.
Most of us don't killfile posters for top-posting. People are
killfiled for being rude and abusive, especially when they do so in
response to good advice.
If you joined this thread already in progress, I can see how you might
think we're heaping abuse on top-posters. That's not what's going on.
David Brown
> Let's put this into perspective.
>
> Althought I don't know how to verify this, I suspect many 100s, perhaps
> 1000s, of people read these posts.
>
> Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
> 10,000? Who knows. That suggests to me that the vast majority of people
> don't give a damn. Probably, like me, the vast majority are easily able to
> deal with all the forms of posting and it is, therefore, not an issue for
> them.
>
> I understand that top-posting annoys some people. For me, when someone
> who's only contribution is to butt in with something along the lines of
> "space corp. directive one ex delta nine has been violated", that is
> infinitely more annoying than any other person's posting style.
>
These groups have a high proportion of lurkers who seldom or never post,
a fair number who post semi-regularly, and a core who have been here for
years and contribute regularly for the benefit of all. It's often these
core posters that ask for usenet rules of courtesy to be followed - they
put a lot of time and effort into helping people here, and all they ask
in return is a little politeness. Personally, I can't see any reason
not to follow conventions - you say you understand that top-posting
annoys people, yet you continue to do it.
> The only input 'Default User' (prick) gave at that point was, "You need to
> get the other point, the one about not top-posting". If Default User had
> any sense, he would have realised that I had chosen to ignore the advice
> about top-posting, that it was not the first time that I had been told and,
> therefore, it was a pretty pointless exercise to step in at that point.
>
> Sincere regards to everyone.
>
Since you seem to have lost track of the history here, I'll summarise
it. A poster ("Flash Gordon") replied to your post with useful
information, along with a request that you follow usenet conventions to
make the thread easier for everyone. It's only when you completely
ignored that request that you got a curt reply - and you responded with
a personal insult. That's what got this thread rolling.
If you are on the phone to someone, and they ask you to speak a bit
louder, would you ignore the request? If they asked you a second time,
would you call them a "prick" ? If you are visiting someone's house, do
you put your feet on the table just because you do it at home? Or do
you light up a cigarette without asking, because that's your "personal
style" ? No, any time you interact with other people, you are polite
and respectful, and follow the conventions already established. Usenet
is nothing special in this regard.
Flash Gordon
<snip>
> Indeed. Having just read the thread it has only just dawned on me
> (after 18 years reading USENET) what "top posting" is. I always
> thought it was posting a reply to the first message in a thread instead
> of replying to the specific one you were answering - something that
> would throw anyone off the trail... especially with threadded
> newsreaders.
Yet you bottom post anyway. Probably because you have just followed the
convention because that is the normal and polite thing to do.
> But now it appears it's something so small - the order of text within a
> message. My God... how anal some people are. Ok, that's unfair, but
> only just.
Since the posts won't get read by a number of skilled people otherwise
it is useful advise, as well as the long standing practice.
> I can see how a top-posting may be harder to speed-read than a
> bottom-posting but kill files? Abuse? Posting nagging comments to the
> thread without actually furthering the discussion?
No, my initial reply contained one or two lines about posting style and
many lines of reply to the actual message. I was possibly a little short
in that one line but it was not kill filing or abuse and nor was it a
post not forwarding the discussion. I believe the same applies to most
if not all posts I have made where I have requested that people not top
post.
> You know, people are clever. They can figure out messages. I don't
> see how your personal quests do anything but make you feel important.
No, we do it because we are not prepared to put in the effort to deal
with the mess top-posting makes of a thread and would prefer that people
follow long standing conventions than that they were ignored and
received no assistance.
> I don't know. This thread amazes me. It simply amazes me.
It amazes me that people who defend top posters assume that those
requesting newcomers follow the long standing convention of bottom
posting assume that all we ever do is complain about peoples posting
style and abuse them for it without bothering to check.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Robert Scott
<da...@westcontrol.removethisbit.com> wrote:
>..These groups have a high proportion of lurkers who seldom or never post,
>a fair number who post semi-regularly, and a core who have been here for
>years and contribute regularly for the benefit of all. It's often these
>core posters that ask for usenet rules of courtesy to be followed - they
>put a lot of time and effort into helping people here, and all they ask
>in return is a little politeness. Personally, I can't see any reason
>not to follow conventions...
Conventions are standards that are agreed to by all or most of the
participants. The prohibition against top-posting is not one of them,
except in the mind of a few zelots. You are free to express your
opinion that you think top-posting is impolite, but when you try to
assign any authority to that opinion, don't be surprised if someone
like me calls you on it.
>...If you are on the phone to someone, and they ask you to speak a bit
>louder, would you ignore the request? If they asked you a second time,
>would you call them a "prick" ? If you are visiting someone's house, do
>you put your feet on the table just because you do it at home? Or do
>you light up a cigarette without asking, because that's your "personal
>style" ?
All these analogies are of one-on-one interactions. Usenet involves
many-to-one interactions. One person's request for what he thinks is
politeness has to be weighed with what others in the group think.
Just because one person is pissed whenever he sees top-posting that
does not mean everyone in the group, or even a majority of the group,
is similarly pissed. I just don't care. But I do care when people
who are self-appointed Internet cops try to make people feel like they
have done something wrong when in fact their crime was minimal or
non-existent.
-Robert Scott
Ypsilanti, Michigan
Rich Walker
> Let's put this into perspective.
>
> Althought I don't know how to verify this, I suspect many 100s, perhaps
> 1000s, of people read these posts.
>
> Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
> 10,000? Who knows. That suggests to me that the vast majority of people
> don't give a damn. Probably, like me, the vast majority are easily able to
> deal with all the forms of posting and it is, therefore, not an issue for
> them.
The vast majority of long-term Usenet readers have lost whatever faith
in the educability of the human race that they might ever have had.
So when another person starts top-posting and insisting that they have
some divine right to ignore long-standing protocols that have developed
to ease communication in these groups, we just make use of the scoring
features on our news-reading programs.
Those who don't use news-readers with scoring appear to use killfiles
instead.
You'll never hear them complain because they can't hear you talk
anymore.
There *is* a reason long-standing cultures develop protocols for
communication, and it's not just to annoy others.
cheers, Rich.
--
rich walker | Shadow Robot Company | r...@shadow.org.uk
technical director 251 Liverpool Road |
need a Hand? London N1 1LX | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml
David Brown
> On 30 Sep 2005 10:02:31 +0200, David Brown
> <da...@westcontrol.removethisbit.com> wrote:
>
>
>>..These groups have a high proportion of lurkers who seldom or never post,
>>a fair number who post semi-regularly, and a core who have been here for
>>years and contribute regularly for the benefit of all. It's often these
>>core posters that ask for usenet rules of courtesy to be followed - they
>>put a lot of time and effort into helping people here, and all they ask
>>in return is a little politeness. Personally, I can't see any reason
>>not to follow conventions...
>
>
> Conventions are standards that are agreed to by all or most of the
> participants. The prohibition against top-posting is not one of them,
> except in the mind of a few zelots. You are free to express your
> opinion that you think top-posting is impolite, but when you try to
> assign any authority to that opinion, don't be surprised if someone
> like me calls you on it.
>
As I said before, I can't speak for the group, but as a long-term reader
I can say what I see as a rough summary of opinions expressed here (in
c.a.e., at least). Of course, I can't summarise un-expressed opinions
of people who don't care one way or the other.
And again, it's not so much the top-posting itself that is impolite.
There are other groups where top-posting is considered the norm, and
receives no objections - just as there are probably groups where html
posting or SMS language is considered normal. It's the arrogant
disrespect for common conventions, and the "I don't care what others
think, I'll make my own rules" attitude that is impolite.
>
>>...If you are on the phone to someone, and they ask you to speak a bit
>>louder, would you ignore the request? If they asked you a second time,
>>would you call them a "prick" ? If you are visiting someone's house, do
>>you put your feet on the table just because you do it at home? Or do
>>you light up a cigarette without asking, because that's your "personal
>>style" ?
>
>
> All these analogies are of one-on-one interactions. Usenet involves
> many-to-one interactions. One person's request for what he thinks is
> politeness has to be weighed with what others in the group think.
The personal insult was a personal post to a single person, making the
analogies valid (IMHO, of course). But if you prefer, replace the phone
call or the house visit with a town-hall public meeting. We are still
talking about conversations between real people who dislike being
name-called.
> Just because one person is pissed whenever he sees top-posting that
> does not mean everyone in the group, or even a majority of the group,
> is similarly pissed. I just don't care. But I do care when people
No one claims that everyone in the group, or the majority in the group,
get annoyed by top-posting. But (based on this thread, and countless
others before it), the majority of those *who express an opinion*
dislike top-posting.
> who are self-appointed Internet cops try to make people feel like they
> have done something wrong when in fact their crime was minimal or
> non-existent.
>
Remember, the "crime" in question was not top-posting - it was
deliberate, repeated top-posting after receiving a polite request to
stop it, followed by a personal insult, although it's still minor in the
grand scheme of things.
Lanarcam
Paul Marciano wrote:
> Robert Scott wrote:
> > It amazes me how some people can claim to speak for the whole group
> > with no documentation at all. I, for one, appreciate top-posting when
> > it is appropriate.
>
>
> But now it appears it's something so small - the order of text within a
> message. My God... how anal some people are. Ok, that's unfair, but
> only just.
>
>
> You know, people are clever. They can figure out messages. I don't
> see how your personal quests do anything but make you feel important.
>
>
> I don't know. This thread amazes me. It simply amazes me.
Gulliver would perhaps have called that the battle of
top postians vs bottom postians ;)
Dave Hansen
Scott) wrote:
>On 30 Sep 2005 10:02:31 +0200, David Brown
><da...@westcontrol.removethisbit.com> wrote:
>
>>..These groups have a high proportion of lurkers who seldom or never post,
>>a fair number who post semi-regularly, and a core who have been here for
>>years and contribute regularly for the benefit of all. It's often these
>>core posters that ask for usenet rules of courtesy to be followed - they
>>put a lot of time and effort into helping people here, and all they ask
>>in return is a little politeness. Personally, I can't see any reason
>>not to follow conventions...
>
>Conventions are standards that are agreed to by all or most of the
>participants. The prohibition against top-posting is not one of them,
>except in the mind of a few zelots. You are free to express your
>opinion that you think top-posting is impolite, but when you try to
>assign any authority to that opinion, don't be surprised if someone
>like me calls you on it.
FWIW (very little, I suspect, I'm not sure why I'm bothering)...
I for one don't find top-posting "rude" per se, but I do find failure
to trim quoting "rude." IME, top-posters are the most egregious
offenders -- if they can't be bothered to put their comments in
context, they surely can't be bothered to trim irrelevent quotes.
I do find top-posts harder to read, and am more likely to skim and
skip them. That's really the choice every poster has to make. If the
post is hard to read, fewer people will put the effort into reading
it. If you don't want people to actually read your post, top-posting
is a good way to discourage them.
I am most reluctant to respond to top-posts, because the flow of the
conversation is all messed up, and it's usually not worth the effort
to reformat. So if you want the last word, perhaps its better to top
post.
Finally, I don't plonk posters, I plonk threads. I was hoping for a
little more useful content out of this one, but it's probably in vain.
I've held on longer than I normally do, and I won't be here much
longer.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Flash Gordon
> On 30 Sep 2005 10:02:31 +0200, David Brown
> <da...@westcontrol.removethisbit.com> wrote:
>
>>..These groups have a high proportion of lurkers who seldom or never post,
>>a fair number who post semi-regularly, and a core who have been here for
>>years and contribute regularly for the benefit of all. It's often these
>>core posters that ask for usenet rules of courtesy to be followed - they
>>put a lot of time and effort into helping people here, and all they ask
>>in return is a little politeness. Personally, I can't see any reason
>>not to follow conventions...
>
>
> Conventions are standards that are agreed to by all or most of the
> participants. The prohibition against top-posting is not one of them,
> except in the mind of a few zelots.
Most posts are *not* top posted, and this includes yours, therefore it
has been implicitly agreed upon by the majority of participants.
Had you checked the history of comp.lang.c you would find that this has
been the case for a long time, and also that the people who advocate
top-posting are *not* in general long time participants and that almost
every post by a long time participant in comp.lang.c on the subject has
been against top-posting and in favour of bottom and middle posting.
> You are free to express your
> opinion that you think top-posting is impolite, but when you try to
> assign any authority to that opinion, don't be surprised if someone
> like me calls you on it.
Feel free, but it is still true that the majority of the regulars on
comp.lang.c have only posted messages against top-posting and for
bottom/middle posting.
>>...If you are on the phone to someone, and they ask you to speak a bit
>>louder, would you ignore the request? If they asked you a second time,
>>would you call them a "prick" ? If you are visiting someone's house, do
>>you put your feet on the table just because you do it at home? Or do
>>you light up a cigarette without asking, because that's your "personal
>>style" ?
>
> All these analogies are of one-on-one interactions. Usenet involves
> many-to-one interactions. One person's request for what he thinks is
> politeness has to be weighed with what others in the group think.
And the majority of the regulars in comp.lang.c consider top posting to
be impolite.
> Just because one person is pissed whenever he sees top-posting that
> does not mean everyone in the group, or even a majority of the group,
> is similarly pissed. I just don't care. But I do care when people
> who are self-appointed Internet cops try to make people feel like they
> have done something wrong when in fact their crime was minimal or
> non-existent.
Most of the regulars do not respond because they agree with the posts
regulars (do I count as a regular yet?) or semi-regulars make against
top posting.
So far I have not seen any of those more knowledgeable than me from
comp.lang.c post in favour of top posting, and the posts from those
comp.lang.c regulars that have participated in this sub-thread have all
been against it.
Walter Roberson
Joe Butler <ffffh....@hotmail-spammers-paradise.com> wrote:
>Althought I don't know how to verify this, I suspect many 100s, perhaps
>1000s, of people read these posts.
>Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
>10,000? Who knows. That suggests to me that the vast majority of people
>don't give a damn.
I, for one, didn't see a need to post a "Me too!" signifying agreement
with the people who asked you not to top-post, as my -assumption- was
that you were a reasonable person who would be able to learn upon
hearing an idea once instead of having to have it repeated multiple
times. Was that a misjudgement on my part??
>Probably, like me, the vast majority are easily able to
>deal with all the forms of posting and it is, therefore, not an issue for
>them.
"the vast majority" don't read literally hundreds of technical
messages every day and try to keep them mentally straight so they
can give the right advice to the right person. "the vast majority"
don't spend hours every day doing free technical research and
consulting for other people.
--
University of Calgary researcher Christopher Auld has found that
milk is the most "rational addiction" amongst the several studied.
Paul Marciano
Lanarcam wrote:
> Gulliver would perhaps have called that the battle of
> top postians vs bottom postians ;)
True.
Forgive me for further reducing the signal to noise ratio in this
thread, but I did want to add a few more things.
I don't bottom post due to conforming with policy, I do so because...
well... it's good style. Question... answer. Quote... response.
I'm not defending top posters. I don't know them - they may all be
assholes for all I know.
I'm certainly not attacking individuals. I took a quick look at
previous posts by the anti-top-posters here and you're all very cool,
knowledgable people. If anything I'm attacking the message, not the
messenger.
What I see is a technical thread deteriorate into a style war, for top
posting vs. bottom posting is mearly a matter of style and, like those
who wear super baggy grunge jeans, some people just don't have it.
I agree that top posting is bad style, but make the point and move on.
It's helpful to point out the style faux pas, but to keep on and on and
on...
IT'S LIKE GETTING UPSET BECAUSE PEOPLE TYPE MESSAGES IN CAPITALS.
Don't do that - it's shouting. Well.. it's not actually shouting is
it? It's just poor style, like misusing, punctuation.
I bottom post. I prefer vim to emacs. I use both Windows and Linux.
I use both Linux and BSD. I respect the GPL but prefer the BSD
license. I agree with copyrights but disagree with software patents.
I like my coffee white and my cola black. People who can only program
in BASIC are ok.
People are different. If you can't accept the differences at least try
to tolerate them. If you can't bring yourself to tolerate them...
because... well... just God dammit why can't you just get a clue and
bottom post like everyone else... well... please be gentle whilst
trying to educate the unwashed.
(if you're still reading this... wow... you need to find a hobby).
Regards,
Paul.
Default User
> Conventions are standards that are agreed to by all or most of the
> participants. The prohibition against top-posting is not one of them,
> except in the mind of a few zelots. You are free to express your
> opinion that you think top-posting is impolite, but when you try to
> assign any authority to that opinion, don't be surprised if someone
> like me calls you on it.
And how many regulars from comp.lang.c have come out in favor of
top-posting? Exactly none. This has been hashed out so many times that
most feel no need to chime in.
We (c.l.c) don't presume to speak for comp.arch.embedded, of course.
Brian
Default User
> And again, it's not so much the top-posting itself that is impolite.
> There are other groups where top-posting is considered the norm, and
> receives no objections - just as there are probably groups where html
> posting or SMS language is considered normal. It's the arrogant
> disrespect for common conventions, and the "I don't care what others
> think, I'll make my own rules" attitude that is impolite.
Right. If a person is a jerk about something like this, he's likely
going to a jerk down the line about other stuff. HE is the one who
wants help, yet can't bring himself to behave in a vaguely polite
manner.
Why should any of us bother with him? I for one won't, as mentioned he
immediately went into the killfile.
Brian
Steve at fivetrees
news:1128101766.0...@o13g2000cwo.googlegroups.com...
>
> People are different. If you can't accept the differences at least try
> to tolerate them. If you can't bring yourself to tolerate them...
> because... well... just God dammit why can't you just get a clue and
> bottom post like everyone else... well... please be gentle whilst
> trying to educate the unwashed.
Well said - my feelings entirely.
> (if you're still reading this... wow... you need to find a hobby).
Ah. Erm. Hmmm. Ooops. Touché.
Dik T. Winter
> In article <433c6dc8$0$32652$da0f...@news.zen.co.uk>,
> Joe Butler <ffffh....@hotmail-spammers-paradise.com> wrote:
> >Only 2 or 3 people told me not to top post. That's 3 out of 1000? 3 out of
> >10,000? Who knows. That suggests to me that the vast majority of people
> >don't give a damn.
>
> I, for one, didn't see a need to post a "Me too!" signifying agreement
> with the people who asked you not to top-post, as my -assumption- was
> that you were a reasonable person who would be able to learn upon
> hearing an idea once instead of having to have it repeated multiple
> times. Was that a misjudgement on my part??
In general I ignore all articles that are toppostings and all articles
that do not quote anything from the article responded to.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
John Hudak
project does suffer from 'requirements creep'! While it *may* be an
interesting exercise to find the most efficient compiler, coding style
in the form of the for loop in this thread, will also impact the
efficiencies. I would bet there are plenty of other areas to save space
(i.e., how many useless libraries are being linked in?-a compiler issue,
or, what architectural changes should be made to your design such as
getting rid of large amounts of shared variables-do they really need to
be shared?). OTOH, if you are in the $10 retail produce area then
saving $0.20 over the next processor in the line may be worth all the
extra engineering time. Somehow, after living thought many sides of
this problem, throwing hardware at it is usually the best approach. Just
a personal opinion from experience, your mileage and situation may vary.....
John
Joe Butler wrote:
> OK, point taken. Although, when working with very small memories, it can
> make all the difference if a byte can be saved here and there. Afterall, 50
> such 'optimisations' could amount to 10% of the total memory available. I'm
> not necessarily suggesting this should be done from day 1, but have found it
> useful just to get a feel for what the compiler works best with.
>
> "Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
> news:smdm03x...@brenda.flash-gordon.me.uk...
>
>>Joe Butler wrote:
>>
>>Don't top post. Replies belong after the text you are replying to.
>>
>>
>>>"Flash Gordon" <sp...@flash-gordon.me.uk> wrote in message
>>>news:rq5m03x...@brenda.flash-gordon.me.uk...
>>>
>>>
>>>>Joe Butler wrote:
>>>>
>>>>
>>>>>>That is not an optimization, but a total waste of time. Read the first
>>>>>>example in "Elements of programming style" and learn...
>>>>>
>>>>>What if the difference is between fitting into memory and not?
>>>>
>>>>If you are hunting for that small an amount to get the program to fit
>>>>then you are in trouble anyway. Something will need changing making it
>>>>no longer fit!
>>>>--
>>>>Flash Gordon
>>>>Living in interesting times.
>>>>Although my email address says spam, it is real and I read it.
>>
>>Don't include peoples signatures unless you are commenting on them.
>>
>> > I think I disagree.
>> >
>> > If you can fit something into a cheaper processor model because you
>> > save a couple of bytes by changing 1 or two loops, then you are not in
>> > trouble anymore.
>>
>>I'll be more explicit then. EVERY SINGLE TIME I have come across a
>>system where people have tried to squeeze the code in believing it will
>>just about fit (either size or speed) one of the following has happened:
>>
>>1) Customer required a subsequent change which proved to be impossible
>> unless the card was redesigned because there was no space for the new
>> code.
>>2) A bug fix requires some additional code and oops, there is no more
>> space.
>>3) By the time all the required stuff was added that the person who
>> thought it would only just fit had forgotten it did NOT fit by a mile
>> so it did not even come close to meeting the customers requirements
>>4) It turned out there were massive savings to be had else where because
>> of higher level problems allowing me to save far more space/time than
>> you could possibly save by such micro-optimisations.
>>
>>Only with the third of those possibilities was it possible to meet the
>>requirements using the existing hardware, and meeting the requirements
>>involved fixing the algorithms or doing large scale changes where the
>>coding was just plain atrocious.
>>
>>So my experience is that it is never worth bothering with such
>>micro-optimisations.