comp.lang.c - 26 new messages in 6 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Skybuck's Payment Method to Develop Software On Time. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a187e34d6200722d?hl=en
* function composition, sequence point, and unsuspected side effects - 11
messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/f5faf6835090b8c2?hl=en
* The Name of Our Religion Is Islam - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/6611d43b1edfbea1?hl=en
* "C pulls away from Java among top programming languages" - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/8057128b2146a884?hl=en
* Why can't use fgetc() in SWITCH with CASE? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/1279c6c07a48f677?hl=en
* optimize if (where first two if-branches have some statements in common) -
11 messages, 8 authors
http://groups.google.com/group/comp.lang.c/t/fecaab4479942b98?hl=en

==============================================================================
TOPIC: Skybuck's Payment Method to Develop Software On Time.
http://groups.google.com/group/comp.lang.c/t/a187e34d6200722d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Nov 18 2013 8:17 am
From: nick.keighley.zczc@gmail.com


On Sunday, 10 November 2013 11:52:41 UTC, Skybuck Flying wrote:

> If you have a big software company which doesn't achieve deadlines for
> software releases then here is my method to get it done on time the next
> time:
>
> Step 1. Give software developers a steady salary.
>
> Step 2. For each second the software is late they pay X ammount of money
> back to the company.
>
> Step 3. For each second the software is on time they get X ammount of bonus
> money from the company. (Optional).
>
> I am pretty sure this will work wonders.
> This will make the software programmer feel involved and will give
> incencitives to perform on time if they wanna get rich ! ;) =D

fix priced contract iff fixed requirements

[I recomend you use some sort of formal specification (I quite like VDM)]
[don't forget to specify timing requirements, memory occupancy etc.]
[better agree the hardware platform in advance]

Note by nailing the requirement down this well you remove some of the benefits of implementing your system in software in the first place






==============================================================================
TOPIC: function composition, sequence point, and unsuspected side effects
http://groups.google.com/group/comp.lang.c/t/f5faf6835090b8c2?hl=en
==============================================================================

== 1 of 11 ==
Date: Mon, Nov 18 2013 8:27 am
From: Keith Thompson


nick.keighley.zczc@gmail.com writes:
> On Friday, 15 November 2013 10:37:45 UTC, Tim Rentsch wrote:
>> Based on the numbering it looks like you are using an ANSI (ie,
>> pre-ISO) document. For reference here are some pointers to
>> drafts of later versions of the ISO C standard:
>>
>> Pre-C99
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n843.pdf
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n843.htm
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.pdf.gz
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.txt.gz
>>
>> Post-C99
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
>>
>> Pre-C11
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>>
>
> you don't have a link to a C89 definition/draft (I suppose you'd call
> it C90) do you?. PDF would be nice...

http://flash-gordon.me.uk/ansi.c.txt is a pre-ANSI draft (as the name
implies, it's plain text). I think it's already been mentioned in this
thread.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"




== 2 of 11 ==
Date: Mon, Nov 18 2013 8:35 am
From: James Kuyper


On 11/18/2013 08:50 AM, 88888 Dihedral wrote:
> On Monday, November 18, 2013 5:15:42 AM UTC+8, Ian Collins wrote:
>> 88888 Dihedral wrote:
>>>
>>> To write C programs in manny platforms
>>> are basic trainings in the
>>> IT industry.

Unless I've missed something (which is entirely possible) the code you
object to is perfectly fine C90 code (the feature that you object to
doesn't disprove that, because its a feature fully supported by C90).
C90 is one of the most widely implemented computer languages in the
world - so targeting C90 meets the goal you specify: to "write C
programs [for many] platforms".

>> What was wrong with the code you criticised?
>>
>> Will you ever learn how to post?
>>
>> --
>> Ian Collins
>
> I did lousy writing in English when
> I saw lousy source codes in C.

I've been having trouble with my news server for a couple of days now,
or I would have responded to your earlier message.

What makes you think this is lousy source code? The feature you seem to
be objecting to has been a part of standard C for as long as there has
been a C standard, and appears to be used correctly, in a reasonably
idiomatic fashion.





== 3 of 11 ==
Date: Mon, Nov 18 2013 8:42 am
From: Noob


James Kuyper wrote:

> I've been having trouble with my news server for a couple of days now,

I haven't been able to post via eternal-september for a while.
It returned NNTP error 220. Does it work better now?





== 4 of 11 ==
Date: Mon, Nov 18 2013 8:48 am
From: Keith Thompson


Noob <root@127.0.0.1> writes:
> James Kuyper wrote:
>> I've been having trouble with my news server for a couple of days now,
>
> I haven't been able to post via eternal-september for a while.
> It returned NNTP error 220. Does it work better now?

I had a problem the other day. If you see this, it's working now.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"




== 5 of 11 ==
Date: Mon, Nov 18 2013 9:03 am
From: "James Harris"


"Noob" <root@127.0.0.1> wrote in message news:l6dg01$1a0$1@dont-email.me...
> James Kuyper wrote:
>
>> I've been having trouble with my news server for a couple of days now,
>
> I haven't been able to post via eternal-september for a while.
> It returned NNTP error 220. Does it work better now?

ES had a problem. All OK now. Incidentally, if it's the same as I had I
think the error code was 441 (which doesn't really tell us anything). Code
220 is just for indicating the message.

http://tools.ietf.org/html/rfc3977

James






== 6 of 11 ==
Date: Mon, Nov 18 2013 9:04 am
From: James Kuyper


On 11/18/2013 11:42 AM, Noob wrote:
> James Kuyper wrote:
>
>> I've been having trouble with my news server for a couple of days now,
>
> I haven't been able to post via eternal-september for a while.
> It returned NNTP error 220. Does it work better now?

I had been using the port 80 server; switching to the port 119 server
was my work-around. If you got it work without having to switch servers,
then my "success" may have simply been a matter of changing something
irrelevant at the same time that the real problem got solved.





== 7 of 11 ==
Date: Mon, Nov 18 2013 10:21 am
From: Seebs


On 2013-11-18, 88888 Dihedral <dihedral88888@gmail.com> wrote:
> I did lousy writing in English when
> I saw lousy source codes in C.

It's poetry, but you have not yet offered any example of something wrong
with the source in question. You've made a vague assertion about
portability, but there's nothing obviously non-portable about returning
a struct from a function. Returning the *address of* an automatic variable
is bad style; returning the automatic variable itself is fine.

-s
--
Copyright 2013, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
Autism Speaks does not speak for me. http://autisticadvocacy.org/
I am not speaking for my employer, although they do rent some of my opinions.




== 8 of 11 ==
Date: Mon, Nov 18 2013 11:10 am
From: regis


On 11/18/13 19:21, Seebs wrote:
> On 2013-11-18, 88888 Dihedral <dihedral88888@gmail.com> wrote:
>> I did lousy writing in English when
>> I saw lousy source codes in C.
>
> It's poetry, but you have not yet offered any example of something wrong
> with the source in question. You've made a vague assertion about
> portability, but there's nothing obviously non-portable about returning
> a struct from a function. Returning the *address of* an automatic variable
> is bad style; returning the automatic variable itself is fine.


Broken code with undefined behevior is a bit beyond style issues ;o)







== 9 of 11 ==
Date: Mon, Nov 18 2013 11:37 am
From: Seebs


On 2013-11-18, regis <regis.barbanchon@free.fr> wrote:
> On 11/18/13 19:21, Seebs wrote:
>> On 2013-11-18, 88888 Dihedral <dihedral88888@gmail.com> wrote:
>>> I did lousy writing in English when
>>> I saw lousy source codes in C.
>>
>> It's poetry, but you have not yet offered any example of something wrong
>> with the source in question. You've made a vague assertion about
>> portability, but there's nothing obviously non-portable about returning
>> a struct from a function. Returning the *address of* an automatic variable
>> is bad style; returning the automatic variable itself is fine.

> Broken code with undefined behevior is a bit beyond style issues ;o)

I think strictly speaking, it's not undefined behavior to return the
address of an automatic variable, it's just undefined behavior to do
anything at all with that return value, including storing it or comparing
it to anything.

-s
--
Copyright 2013, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
Autism Speaks does not speak for me. http://autisticadvocacy.org/
I am not speaking for my employer, although they do rent some of my opinions.




== 10 of 11 ==
Date: Mon, Nov 18 2013 3:12 pm
From: Stephen Sprunk


On 16-Nov-13 21:37, Richard Damon wrote:
> On 11/16/13, 9:21 PM, Stephen Sprunk wrote:
>> On 16-Nov-13 19:28, Tim Rentsch wrote:
>>> (10, x = 1, 30) + (20, x = 2, 40)
>>>
>>> is still undefined behavior, despite there being a sequence point
>>> both before and after each access to x.
>>
>> I trust that you are correct, but I don't understand why. I thought
>> those sequence points would establish that x=1 and x=2 were ordered,
>> even if that order is unspecified.
>
> The key is to notice that the sequence points establish that
> 10 is before x = 1 is before 30 and that
> 20 is before x = 2 is before 40
> but that there is NO sequence points between the first set and the
> second, and no rule to prevent interleaving, so on possible execution
> sequence is:
>
> 10, 20; x=1, x=2; 30, 40
> where here , separates items without a sequence point, and the ; mark
> sequence points. Thus the x=1 and the x=2 are not separated by a
> sequence point.

Ah. I had assumed that the unspecified ordering between (10,x=1,30) and
(20,x=2,40) meant that one had to be evaluated and then the other, i.e.
they couldn't be interleaved like you show, even if we don't know which
of the two will be evaluated first.

>> That seems strange to me. I thought the sequence points before and
>> after the function calls here:
>>
>> set_x(1) + set_x(2)
>>
>> would be enough to establish that one call must finish before the
>> other could start, even if it's unspecified which order they happen
>> in. To interpret it that way doesn't require extra rules about
>> non-overlap of function bodies.
>
> Again, the points could occur in the order:
> Sequence point before calling set_x(1)
> Sequence point before calling set_x(2)
> calling set_x(1) and set_x(2)
> Sequence point after calling set_x(1)
> Sequence point after calling set_x(2)
>
> You need some further specification to make sure that the functions
> don't overlap in execution.

Similarly, I had assumed that evaluating either function, including its
sequence points, was indivisible. In fact, I thought that was the
entire purpose of specifying there were sequence points before/after a
function call!

(All of the above being subject to the as-if rule, of course.)

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking




== 11 of 11 ==
Date: Mon, Nov 18 2013 3:12 pm
From: Stephen Sprunk


On 17-Nov-13 04:07, Tim Rentsch wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
>> On 16-Nov-13 19:28, Tim Rentsch wrote:
>>> Having a sequence point before and after each common access does
>>> not prevent undefined behavior if there is no other ordering
>>> between those sequence points. For example
>>>
>>> (10, x = 1, 30) + (20, x = 2, 40)
>>>
>>> is still undefined behavior, despite there being a sequence point
>>> both before and after each access to x.
>>
>> I trust that you are correct, but I don't understand why. I thought
>> those sequence points would establish that x=1 and x=2 were ordered,
>> even if that order is unspecified.
>
> [ very helpful explanation ]
>
> Unfortunately the Standard expresses these rules by talking about
> an interval "Between the previous and next sequence point". This
> sounds like such intervals are uniquely determined (which they
> aren't), or perhaps like there is an unspecified total ordering of
> sequence points (which there isn't). What's intended is a partial
> ordering determined by the operators in an expression (and in fact
> two partial ordering relationships, one for 'value computations'
> that involve only reading, and another for operations that store
> into objects). How C90 and C99 express this is misleading at
> times; it's more reliable (meaning more consistent with the C11
> wording) to ask the question in terms of what the diagram looks
> like.

I think this is where I got turned around. I thought there _was_ a
total ordering, at least to the extent that anything separated by
sequence points happens in the specified order and anything between
sequence points happens in an unspecified order. (All subject to the
as-if rule, of course.)

Following that (apparently flawed) logic, I concluded that since there
was a sequence point before and after a function call, nothing outside
the function call could overlap with it because that would violate the
function's own internal ordering, even if the ordering of its parent
expression was unspecified.

> I realize this answer may not be completely satisfactory, because it
> doesn't directly respond to your intuition about how sequence points
> work. The best I can think of to say is that other people have had
> reactions much like yours, and it's taken the better part of 20
> years to figure out how to say how evaluation sequencing is meant to
> work (or not, in the cases where there is undefined behavior).

Well, at least I'm not alone in my confusion.

Could it be said that it was always _intended_ to work how I thought it
did, but the Standard didn't actually say so until C11?

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking





==============================================================================
TOPIC: The Name of Our Religion Is Islam
http://groups.google.com/group/comp.lang.c/t/6611d43b1edfbea1?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Nov 18 2013 8:43 am
From: BV BV


The Name of Our Religion Is Islam

Publication Date: 9 Safar 1434 (12/22/12)
This article was written in response to the following question:

Your religion orders the worship of a man because Muslims are called Muhammadans. How to handle this?

The name of our religion is Islam, and those who follow it are Muslims. The name Muslim is given in the Quran (22:78) to the followers of Islam, and never did the Quran or Prophet Muhammad (blessings and peace be upon him) call the followers of the religion "Muhammadans". Moreover, the Muslims never used the word "Muhammadan" as a name or title to describe all Muslims.

Etymologically, the name "Muhammadans" has been given to us, Muslims, by the Europeans of the Middle Ages. This labeling may have been out of spite and animosity, to imply that we are a cult of followers of one man.[i] Some may, also, have done that out of ignorance, or because they were Christians, and being called after the Christ (blessings and peace be upon him), they may have, through analogy, thought of us as "Muhammadans".

In the history of Europe during the Middle Ages, the distortion of names had been a common occurrence. The Europeans of the Middle Ages have, also, called us "Saracens" and "Moors" amongst other more offensive names.

The fact that Islam emphasizes the worship of God alone and forbids, with utmost condemnation, the ascribing of partners to Him, regardless of their status, should be beyond debate. No serious intellectual or writer of our times would contest that.

The Quran affirmed the humanity of Prophet Muhammad (blessings and peace be upon him) in many verses, including the following,

( قُلْ إِنَّمَا أَنَا بَشَرٌ مِّثْلُكُمْ يُوحَى إِلَيَّ أَنَّمَا إِلَهُكُمْ إِلَهٌ وَاحِدٌ ) الكهف/110 .

"Say (O Muhammad): I am only a man like you. It has been revealed to me that your God is One God" [Quran 18/110]

"وَمَا مُحَمَّدٌ إِلَّا رَسُولٌ قَدْ خَلَتْ مِنْ قَبْلِهِ الرُّسُلُ أَفَإِنْ مَاتَ أَوْ قُتِلَ انْقَلَبْتُمْ عَلَى أَعْقَابِكُمْ وَمَنْ يَنْقَلِبْ عَلَى عَقِبَيْهِ فَلَنْ يَضُرَّ اللَّهَ شَيْئاً وَسَيَجْزِي اللَّهُ الشَّاكِرِينَ" آل عمران/ 144.

"Muhammad is no more than an apostle: many were the apostle that passed away before him. If he died or were slain, will ye then turn back on your heels? If any did turn back on his heels, not the least harm will he do to Allah. But Allah (on the other hand) will swiftly reward those who (serve Him) with gratitude." [Quran 3:144]

The Prophet (blessings and peace be upon him) said,

‏( لاْ تُطْرُونِيْ كَمَا أُطرِيَ عِيْسَى ابْنُ مَرْيَمَ ، وَقُولُوْا عَبدُ اللهِ وَرَسُولُهُ ) رواه البخاري . ‏

"Do not exaggerate about me as was exaggerated about 'Eesa ibn Maryam (Jesus, son of Mary). Say: the slave of Allah and His Messenger." [Narrated by al-Bukhari, the mostauthentic collection of the Prophetic sayings.]

The Muslims didn't betray that legacy of Prophet Muhammad, which was also the legacy of Prophet Jesus (blessings and peace be upon them both.) The first successor of the Prophet, Abu Bakr as-Siddeeq (Allah be pleased with him), clearly highlighted this fact, upon the death of the Prophet (blessings and peace be upon him), in his famous speechin which he said,

"من كان يعبد محمدا فإن محمدا قد مات ومن كان يعبد الله فإن الله حي لا يموت ".

"Whoever used to worship Muhammad, Muhammad has died. But he who used to worship Allah, Allah is alive and never dies." [al-Bukhari]

Allah, the Most High, instructed us to do and say the following,

"وَلَا تُجَادِلُوا أَهْلَ الْكِتَابِ إِلَّا بِالَّتِي هِيَ أَحْسَنُ إِلَّا الَّذِينَ ظَلَمُوا مِنْهُمْ ۖ وَقُولُوا آمَنَّا بِالَّذِي أُنزِلَ إِلَيْنَا وَأُنزِلَ إِلَيْكُمْ وَإِلَـٰهُنَا وَإِلَـٰهُكُمْ وَاحِدٌ وَنَحْنُ لَهُ مُسْلِمُونَ"

"And argue not with the people of the Scripture (Jews and Christians), unless it be in (a way) that is better (with good words and in good manner, inviting them to Islamic Monotheism with His Verses), except with such of them as do wrong; and say (to them): "We believe in that which has been revealed to us and revealed to you; our God and your God is One (i.e. Allah), and to Him we have submitted (as Muslims)." [Quran al-'Ankaboot 29:46]

I hope you will find, here above, an answer to your inquiry.

http://en.islamway.net/article/13957
thank you




==============================================================================
TOPIC: "C pulls away from Java among top programming languages"
http://groups.google.com/group/comp.lang.c/t/8057128b2146a884?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Nov 18 2013 9:58 am
From: Ken Brody


On 11/14/2013 6:04 AM, Noob wrote:
> Lynn McGuire wrote:
>
>> "C pulls away from Java among top programming languages"
>> http://www.infoworld.com/t/application-development/c-pulls-away-java-among-top-programming-languages-230603
>>
>> The actual programming language index is at:
>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>
>> 1 1 C 18.155% -1.07% A
>> 2 2 Java 16.521% -0.93% A
>
> How can C "pull away" if the margin is shrinking?

Must've been written by a real estate agent:

http://www.gocomics.com/nonsequitur/2013/11/14






==============================================================================
TOPIC: Why can't use fgetc() in SWITCH with CASE?
http://groups.google.com/group/comp.lang.c/t/1279c6c07a48f677?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Nov 18 2013 11:28 am
From: Barry Schwarz


On Mon, 18 Nov 2013 01:47:19 -0800 (PST), kuoyang.hu@gmail.com wrote:


< snip 100 lines of obsolete code>

>
>I wrote a simple program to test the switch command with FILE (called file3 & file4). If I put the "file4" out of "switch" command, compiler OK & executable. If I put the "file4" after the "switch" command, compiler fail & couldn't generate execute file.

More people might be willing to help if you deleted unneeded text from
you message and limited you line length to something less than 80.

Since you seem unwilling to tell us what the error message is, one
might think you are not really interested in solving the problem. This
is reinforced since you have not corrected any of the errors you were
previously told about (e.g., you are still closing file 4 twice).

>
>Below is my simple test program.
>#include <stdio.h>
>#include <string.h>
>#include <time.h>
>
>main ()
>{
>char Ext_001[512];
>int IWHi, IWLo;
>int ImgLenHi, ImgLenLo;
>int FCount = 1, R200=0, R300=0, Rot=0;
>int Res;
>FILE *file3 = fopen("d:\\mtif2stif\\transout\\ORGgotfile21381.ok","rb");
>FILE *file4 = fopen("d:\\mtif2stif\\transout\\ORGgotfile21381_001.tif","rb"); //Put here compiler OK & execuateable
>if ( file3 != NULL )
> {
> printf ("Found : d:\\mtif2stif\\transout\\gotfile21381.ok\n");
> fclose(file3);
> for (FCount; FCount <=3; FCount++)
> {
> switch (FCount)
> {
> case 1:
> break;
> default:
>// FILE *file4 = fopen("d:\\mtif2stif\\transout \\ORGgotfile21381_001.tif","rb"); //Put here compiler failed
> if ( file4 != NULL )
> {
> printf("Open getfileHHMMSS_001.tif\n");
> if (fseek(file4,0,SEEK_SET) == 0)
> {
> if (fseek(file4,31,SEEK_SET) == 0)
> {
> printf("Check point 1 ...\n");
> IWLo = fgetc(file4);
> printf("IWLo = %X\n",IWLo);
> fclose(file4);
> }
> }
> fclose(file4);
> }
> break;
> }
> }
> return 0;
> }
>printf("Can't open file\n");
>return 0;
>}

--
Remove del for email





==============================================================================
TOPIC: optimize if (where first two if-branches have some statements in common)

http://groups.google.com/group/comp.lang.c/t/fecaab4479942b98?hl=en
==============================================================================

== 1 of 11 ==
Date: Mon, Nov 18 2013 1:50 pm
From: jononanon@googlemail.com


Hi there,

how would you optimize this:


if (a) {
x = v + size;
} else if (b) {
v = buf;
x = v + size;
} else {
fun();
}

Note the common line
x = v + size;
in the first two if-branches.



How do you like this, using comma-operator:

if (a || b && (v=buf, 1)) {
x = v + size;
} else {
fun();
}


Thanks for your comments.




== 2 of 11 ==
Date: Mon, Nov 18 2013 2:04 pm
From: jononanon@googlemail.com


On Monday, November 18, 2013 10:50:13 PM UTC+1, jono...@googlemail.com wrote:
> Hi there,
>
>
>
> how would you optimize this:
>
>
>
>
>
> if (a) {
>
> x = v + size;
>
> } else if (b) {
>
> v = buf;
>
> x = v + size;
>
> } else {
>
> fun();
>
> }
>
>
>
> Note the common line
>
> x = v + size;
>
> in the first two if-branches.
>
>
>
>
>
>
>
> How do you like this, using comma-operator:
>
>
>
> if (a || b && (v=buf, 1)) {
>
> x = v + size;
>
> } else {
>
> fun();
>
> }
>
>
>
>
>
> Thanks for your comments.

Or in a similar way ... how do you like this:

if (a || (b ? (v=buf, 1) : 0)) {
x = v + size;
} else {
fun();
}



A goto would also do the trick, right?

if (a) {
goto label_here;
} else if (b) {
v = buf;
label_here:
x = v + size;
} else {
fun();
}




== 3 of 11 ==
Date: Mon, Nov 18 2013 2:07 pm
From: Siri Cruz


In article <4b544477-9c7b-4e58-91c1-7b1c145954af@googlegroups.com>,
jononanon@googlemail.com wrote:

> Hi there,
>
> how would you optimize this:
>
>
> if (a) {
> x = v + size;
> } else if (b) {
> v = buf;
> x = v + size;
> } else {
> fun();
> }

I would use cc -O3.

There might be predicates p and q that would more clearly express their relation
to the statements so

if (p) v = buf;
if (q) x = v+size; else func();

is the most easily understood presentation, but it really should be about what
makes the most sense in six months when you have to fix some bug in your now
forgotten code.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
They hung there dependent from the sky
Like some heavy metal fruit
These bombers, ripened, ready to tilt




== 4 of 11 ==
Date: Mon, Nov 18 2013 2:23 pm
From: Fuseblower


On Mon, 18 Nov 2013 14:04:57 -0800 (PST), jononanon@googlemail.com
wrote:

>> how would you optimize this:
>>
>> if (a) {
>> x = v + size;
>> } else if (b) {
>> v = buf;
>> x = v + size;
>> } else {
>> fun();
>> }

>> if (a || b && (v=buf, 1)) {
>> x = v + size;
>> } else {
>> fun();
>> }

>if (a || (b ? (v=buf, 1) : 0)) {
> x = v + size;
>} else {
> fun();
>}

>if (a) {
> goto label_here;
>} else if (b) {
> v = buf;
> label_here:
> x = v + size;
>} else {
> fun();
>}

These aren't optimizations. These are obfuscations!

Anyway, I would use a LUT and do the whole thing in Assembly (portable
Assembly, of course ;)





== 5 of 11 ==
Date: Mon, Nov 18 2013 2:31 pm
From: Eric Sosman


On 11/18/2013 4:50 PM, jononanon@googlemail.com wrote:
> Hi there,
>
> how would you optimize this:
>
>
> if (a) {
> x = v + size;
> } else if (b) {
> v = buf;
> x = v + size;
> } else {
> fun();
> }
>
> Note the common line
> x = v + size;
> in the first two if-branches.

I'd concentrate on correctness and readability, and let
the compiler attend to the optimizing. Compilers are pretty
good at recognizing and rearranging shared code stretches.

If the "common line" were a larger bunch of code I might
think about rearranging things, not to optimize but to make
more readable (less material for the reader to digest) and
more maintainable (fixes and changes need be applied only once
and not twice; a single stretch of code can't get out of sync
with itself). One likely rearrangement might be:

if (b) {
v = buf;
}
if (a || b) {
// the "common line" section of code
} else
fun();
}

This supposes that the expressions `a' and `b' are not themselves
expensive to evaluate, and don't have side-effects that must occur
exactly as in the original. If they're expensive but the side-
effects don't matter I might cache the result of `b':

_Bool bresult = b; // only one expensive evaluation
if (bresult) {
v = buf;
}
if (bresult || a) { // avoid expensive `a' if unneeded
// the "common line" section of code
} else {
fun();
}

Finally, if `a' and/or `b' have side-effects whose occurrence and
ordering are important, I might well write

if (a) {
commonCode();
} else if (b) {
v = buf;
commonCode();
} else {
fun();
}

... so the "common line" is easily readable and there's still only
one version of its innards floating around.

> How do you like this, using comma-operator:
>
> if (a || b && (v=buf, 1)) {
> x = v + size;
> } else {
> fun();
> }

Not very much: It's too clever by half, and cleverness is not
usually a good thing in computer programs. Also, it requires that
the "special line" after `b' be an expression, and won't work if
it's a statement instead.

(Aside: When you mix || and && in the same expression, it's
a *very* good idea to be generous with parentheses. Even if you
know what the parse tree looks like, the next person to work on
the code might not know you knew, and might wonder whether you
really meant what you actually wrote. Use the extra parens to
allay his doubts.)

--
Eric Sosman
esosman@comcast-dot-net.invalid




== 6 of 11 ==
Date: Mon, Nov 18 2013 2:37 pm
From: James Kuyper


On 11/18/2013 04:50 PM, jononanon@googlemail.com wrote:
> Hi there,
>
> how would you optimize this:
>
>
> if (a) {
> x = v + size;
> } else if (b) {
> v = buf;
> x = v + size;
> } else {
> fun();
> }
>
> Note the common line
> x = v + size;
> in the first two if-branches.

I wouldn't ordinarily bother with rearranging it unless "x = v + size;"
was replaced with a much more complicated block of code. But the
re-write I'd go for would be:

if(!a && b)
v = buf;

if(a || b)
x = v + size;
else
fun();

> How do you like this, using comma-operator:
>
> if (a || b && (v=buf, 1)) {
> x = v + size;
> } else {
> fun();
> }

Not very much at all. It's "cleverness" is achieved at the expense of
clarity.





== 7 of 11 ==
Date: Mon, Nov 18 2013 2:39 pm
From: James Kuyper


On 11/18/2013 05:31 PM, Eric Sosman wrote:
> On 11/18/2013 4:50 PM, jononanon@googlemail.com wrote:
>> Hi there,
>>
>> how would you optimize this:
>>
>>
>> if (a) {
>> x = v + size;
>> } else if (b) {
>> v = buf;
>> x = v + size;
>> } else {
>> fun();
>> }
>>
>> Note the common line
>> x = v + size;
>> in the first two if-branches.
>
> I'd concentrate on correctness and readability, and let
> the compiler attend to the optimizing. Compilers are pretty
> good at recognizing and rearranging shared code stretches.
>
> If the "common line" were a larger bunch of code I might
> think about rearranging things, not to optimize but to make
> more readable (less material for the reader to digest) and
> more maintainable (fixes and changes need be applied only once
> and not twice; a single stretch of code can't get out of sync
> with itself). One likely rearrangement might be:
>
> if (b) {

This block gets executed even if a!=0, which differs from the original code.

> v = buf;
> }
> if (a || b) {
> // the "common line" section of code
> } else
> fun();
> }





== 8 of 11 ==
Date: Mon, Nov 18 2013 2:40 pm
From: Keith Thompson


jononanon@googlemail.com writes:
> how would you optimize this:
>
> if (a) {
> x = v + size;
> } else if (b) {
> v = buf;
> x = v + size;
> } else {
> fun();
> }
>
> Note the common line
> x = v + size;
> in the first two if-branches.
>
> How do you like this, using comma-operator:
>
> if (a || b && (v=buf, 1)) {
> x = v + size;
> } else {
> fun();
> }

Sometimes a little bit of duplicated code is better than the gyrations
you'd have to go through to eliminate it. On the other hand, even one
duplicated line opens the risk that you'll eventually modify one and
forget to modify the other.

I presume your conditions aren't really "a" and "b". If you can come up
with meaningful names for them, you might consider something like this:

const bool cond0 = a;
const bool cond1 = !a && b;
const bool cond2 = !a && !b;

if (cond0) {
v = buf;
}
if (cond0 || cond1) {
x = v + size;
}
if (cond2) {
fun();
}

This avoids the repetition by refactoring the conditions rather than the
code controlled by them. I don't think I'm entirely happy with this
approach, but I offer it as an alternative.

Or you could do:

if (a) {
if (b) {
v = buf;
}
x = v + size;
}
if (!a && !b) {
fun();
}

Which if these (including the original) is clearer is going to depend on
how meaningful the conditions are going to be to future readers of the
code.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"




== 9 of 11 ==
Date: Mon, Nov 18 2013 2:55 pm
From: Barry Schwarz


On Mon, 18 Nov 2013 13:50:13 -0800 (PST), jononanon@googlemail.com
wrote:

>Hi there,
>
>how would you optimize this:
>
>
>if (a) {
> x = v + size;
>} else if (b) {
> v = buf;
> x = v + size;
>} else {
> fun();
>}
>
>Note the common line
> x = v + size;
>in the first two if-branches.
>
>
>
>How do you like this, using comma-operator:
>
>if (a || b && (v=buf, 1)) {
> x = v + size;
>} else {
> fun();
>}

Do you think the comma helps? If buf is not NULL, then the comma and
subsequent expression serve no purpose since v = buf is equivalent to
true. If buf is NULL, then the expression v + size is probably not
going to do you very much good when you evaluate x. On those systems
where NULL is actually represented as 0, the resulting address is
probably somewhere in the kernel of the operating system.


--
Remove del for email




== 10 of 11 ==
Date: Mon, Nov 18 2013 2:57 pm
From: Andrew Smallshaw


On 2013-11-18, jononanon@googlemail.com <jononanon@googlemail.com> wrote:
> Hi there,
>
> how would you optimize this:
>
>
> if (a) {
> x = v + size;
> } else if (b) {
> v = buf;
> x = v + size;
> } else {
> fun();
> }

> How do you like this, using comma-operator:
>
> if (a || b && (v=buf, 1)) {
> x = v + size;
> } else {
> fun();
> }

As others have noted, I'd leave it in the original form unless the
two statements x = v + size and v = buf are replaced by something
a lot larger in terms of code put down - i.e. they could call some
vastly complex function and I'd still leave it as is. All of your
optimisations take two conditional branches (the two ifs) and
replace them with three (an if, and shortcut logical operators).
That increases the chances of a branch prediction miss and those
are becoming ever more costly as pipelines get longer and longer.

--
Andrew Smallshaw
andrews@sdf.lonestar.org




== 11 of 11 ==
Date: Mon, Nov 18 2013 3:06 pm
From: Fuseblower


On Mon, 18 Nov 2013 13:50:13 -0800 (PST), jononanon@googlemail.com
wrote:

>Hi there,
>
>how would you optimize this:
>
>
>if (a) {
> x = v + size;
>} else if (b) {
> v = buf;
> x = v + size;
>} else {
> fun();
>}

Okay then, I'll bite (because everybody else takes it so seriously)

c = a | b;
v = v - v * b + buf * b;
x = x + c * (v + size);
if (!c)
fun();

There you are! Of course, I made some gross assumptions about the
types of the variables and their values (like a and b being either 0
or 1).

The whole objective was, of course, to eliminate as many if's as
possible (a false branch prediction is costly with nowadays long
pipelines).

Hmmm.... perhaps I should have done something with the shift
operators. Shifting is faster than multiplication but I bet the
mythical C optimizer will recognize the idiom and optimize it for me

;)





==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en