comp.lang.c - 25 new messages in 5 topics - digest

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

comp.lang.c@googlegroups.com

Today's topics:

* how to get out of double for loops? - 17 messages, 11 authors
http://groups.google.com/group/comp.lang.c/t/535cb24e8f02aec3?hl=en
* Got stuck with quicksort code from the "Unleashed C". - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
* Stylistic questions on UNIX C coding. - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* help: gcc compilation difference - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
* efficiency question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ac42317db6371cec?hl=en

==============================================================================
TOPIC: how to get out of double for loops?
http://groups.google.com/group/comp.lang.c/t/535cb24e8f02aec3?hl=en
==============================================================================

== 1 of 17 ==
Date: Fri, Mar 5 2010 4:25 am
From: Mark Bluemel

On 5 Mar, 12:08, Tom St Denis <t...@iahu.ca> wrote:
> On Mar 5, 4:04 am, MBALOVER <mbalov...@gmail.com> wrote:
>
>
>
> > Hi all,
>
> > I want to quit of both "for" loop whenever I find x[i][j]=1;
>
> > Do you know how to do it?
>
> > Right now, I am using the following code but I believe there should be
> > a much more efficient way for this task.
>
> > flag=0;
> > for (i=0;i<H;i++)
> > {
> >       for (j=0;j<H;j++)
> >           if (x[i][j]==1)
> >           {
> >                flag=1;
> >                break;
> >           }
> >         if( flag)
> >              break
>
> > }
>
> STANDBACK I'M ABOUT TO PERFORM MAGIC:
>
> for (i=0;i<H;i++) {
>    for (j=0;j<H;j++) {
>       if (x[i][j] == 1) {
>          goto AFTER_LOOP;
>       }
>    }}
>
> AFTER_LOOP:
>    // more code here

"Any references to Goto (an obscure Japanese admiral) are obscene,
unfit for your eyes and anyway don't mean what you think they do -
delete them" (notes on the Algol manual from a university course in
the 1970s).

I'm allergic to gotos - if I managed to write COBOL without goto for
many years, I think I can manage to write C without goto. (My primary
language these days is Java, which doesn't even have goto).

== 2 of 17 ==
Date: Fri, Mar 5 2010 4:57 am
From: Ben Bacarisse

MBALOVER <mbalover9@gmail.com> writes:

> I want to quit of both "for" loop whenever I find x[i][j]=1;
>
> Do you know how to do it?
>
> Right now, I am using the following code but I believe there should be
> a much more efficient way for this task.

I am not sure, but I doubt you mean efficient. If you do, that is
whole other ball game.

> flag=0;
> for (i=0;i<H;i++)
> {
> for (j=0;j<H;j++)
> if (x[i][j]==1)
> {
> flag=1;
> break;
> }
> if( flag)
> break
> }

I won't repeat the good suggestions but I'll add few more to think
about. You can get rid of your flag, because what you are looking for
acts like a flag:

for (i = 0; i < H; i++) {
for (j = 0; j < H && x[i][j] != 1; j++);
if (j < H)
break;
}

There is no shame in using a goto here. A simple and clear jump
forward is not going to confuse anyone:

for (i = 0; i < H; i++) {
for (j = 0; j < H; j++)
if (x[i][j] == 1)
goto outer_break;
}
outer_break:

The trouble with gotos is the temptation! You could be drawn into
using it for more than a double break and that is the start of a
slippery slope. I would not be happy with:

for (i = 0; i < H; i++) {
for (j = 0; j < H; j++)
if (x[i][j] == 1)
goto found;
}
/* code here to what to do when the element is not found */
found:
/* code here for a successful search */

especially if the "not found" code is long and complex.

Finally, you could put the search in a function. This becomes, for
me, the first choice solution if you have more than one of these
loop pairs. Even with only one I'd probably use it.

The trouble with giving you an example is that there are lots of
options (what type is x? do you need C99's VLAs? do you really need
the indexes or would a pointer to the found element do?). Anyway, one
simple version might look like this:

bool find_eq1(int (*x)[H], int *rowp, int *colp)
{
for (int i = 0; i < H; i++)
for (int j = 0; j < H; j++)
if (x[i][j] == 1) {
*rowp = i;
*colp = j;
return true;
}
return false;
}

which you'd use like this:

if (find_eq1(x, &i, &j))
/* ... */

[This uses C99 'for' loop syntax and needs #include <stdbool.h>.]

--
Ben.

== 3 of 17 ==
Date: Fri, Mar 5 2010 5:17 am
From: Rob Kendrick

On Fri, 5 Mar 2010 04:25:25 -0800 (PST)
Mark Bluemel <mark.bluemel@googlemail.com> wrote:

> I'm allergic to gotos - if I managed to write COBOL without goto for
> many years, I think I can manage to write C without goto. (My primary
> language these days is Java, which doesn't even have goto).

What do you think break is, if not another word for goto?

B.

== 4 of 17 ==
Date: Fri, Mar 5 2010 5:35 am
From: "christian.bau"

On Mar 5, 12:25 pm, Mark Bluemel <mark.blue...@googlemail.com> wrote:

> "Any references to Goto (an obscure Japanese admiral) are obscene,
> unfit for your eyes and anyway don't mean what you think they do -
> delete them" (notes on the Algol manual from a university course in
> the 1970s).
>
> I'm allergic to gotos - if I managed to write COBOL without goto for
> many years, I think I can manage to write C without goto. (My primary
> language these days is Java, which doesn't even have goto).

That was written at a time when primitive language like BASIC and
FORTRAN 66 didn't have any decent control structures, and goto
statements had to be used to simulate control structures. Nowadays you
have languages like Java and C++ that provide "exceptions" which are
really the mother-fucking-goto-statement-from-hell.

And then there was the proof that any program can be written without
using "goto" - by labelling every statement, turning all control
structures into gotos, introducing a variable holding the variable,
and ending up with a program like

int label = 1;
for (;;) {
if (label == 1) { statement1; label = 2; }
else if (label == 2) { statement2; label = 3; }
else if (label == 3) { statement3; if (condition) label = 1; else
label = 4; } // That would be a simulated goto
...
}

If some article from the '70s causes you allergies, then maybe you
should seek medical help.

== 5 of 17 ==
Date: Fri, Mar 5 2010 5:54 am
From: Mark Bluemel

On 5 Mar, 13:17, Rob Kendrick <n...@rjek.com> wrote:
> On Fri, 5 Mar 2010 04:25:25 -0800 (PST)
>
> Mark Bluemel <mark.blue...@googlemail.com> wrote:
> > I'm allergic to gotos - if I managed to write COBOL without goto for
> > many years, I think I can manage to write C without goto. (My primary
> > language these days is Java, which doesn't even have goto).
>
> What do you think break is, if not another word for goto?

I recognise that, and I'm no great fan of break (or continue).

My suggested code used neither break nor continue.

== 6 of 17 ==
Date: Fri, Mar 5 2010 6:01 am
From: Mark Bluemel

On 5 Mar, 13:35, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
> On Mar 5, 12:25 pm, Mark Bluemel <mark.blue...@googlemail.com> wrote:
>
> > "Any references to Goto (an obscure Japanese admiral) are obscene,
> > unfit for your eyes and anyway don't mean what you think they do -
> > delete them" (notes on the Algol manual from a university course in
> > the 1970s).
>
> > I'm allergic to gotos - if I managed to write COBOL without goto for
> > many years, I think I can manage to write C without goto. (My primary
> > language these days is Java, which doesn't even have goto).

> If some article from the '70s causes you allergies, then maybe you
> should seek medical help.

What makes you think my allergy comes from the article?

I've been programming in various languages for over 30 years, and I
found by experience very early on that goto was rarely useful and
could be, as the man said, harmful. I can't remember the last time I
used one.

== 7 of 17 ==
Date: Fri, Mar 5 2010 6:05 am
From: Noob

Christian Bau wrote:

> That was written at a time when primitive language like BASIC and
> FORTRAN 66 didn't have any decent control structures, and goto
> statements had to be used to simulate control structures. Nowadays you
> have languages like Java and C++ that provide "exceptions" which are
> really the mother-fucking-goto-statement-from-hell.

So that makes setjmp and longjmp... what? Demonic abominations?

== 8 of 17 ==
Date: Fri, Mar 5 2010 6:08 am
From: Richard Heathfield

Mark Bluemel wrote:
> On 5 Mar, 13:17, Rob Kendrick <n...@rjek.com> wrote:
>> On Fri, 5 Mar 2010 04:25:25 -0800 (PST)
>>
>> Mark Bluemel <mark.blue...@googlemail.com> wrote:
>>> I'm allergic to gotos - if I managed to write COBOL without goto for
>>> many years, I think I can manage to write C without goto. (My primary
>>> language these days is Java, which doesn't even have goto).
>> What do you think break is, if not another word for goto?
>
> I recognise that, and I'm no great fan of break (or continue).

Although I agree with every word you say (above), I defend your right to
say it!

Having said that, I am quite content to use break within switch, and
quite content to use continue in an otherwise empty loop.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 9 of 17 ==
Date: Fri, Mar 5 2010 6:17 am
From: cri@tiac.net (Richard Harter)

On Fri, 05 Mar 2010 12:57:41 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>The trouble with gotos is the temptation! You could be drawn into
>using it for more than a double break and that is the start of a
>slippery slope. I would not be happy with:
>
> for (i = 0; i < H; i++) {
> for (j = 0; j < H; j++)
> if (x[i][j] == 1)
> goto found;
> }
> /* code here to what to do when the element is not found */
>found:
> /* code here for a successful search */
>
>especially if the "not found" code is long and complex.

If my not terribly reliable understanding is correct, variables
and labels are in different name spaces so you could write:

int found = 0;
for (i = 0; i < H; i++) {
for (j = 0; j < H; j++) {
if (x[i][j] == 1) {
found = 1;
goto found;
}
}
}
found:
if (found) {/* found stuff */}
else {/* not found stuff */}

I don't mind if you can't. :-)

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 10 of 17 ==
Date: Fri, Mar 5 2010 6:21 am
From: Tim Rentsch

MBALOVER <mbalover9@gmail.com> writes:

> I want to quit of both "for" loop whenever I find x[i][j]=1;
>
> Do you know how to do it?
>
> Right now, I am using the following code but I believe there should be
> a much more efficient way for this task.
>
> flag=0;
> for (i=0;i<H;i++)
> {
> for (j=0;j<H;j++)
> if (x[i][j]==1)
> {
> flag=1;
> break;
> }
> if( flag)
> break
> }

At some level there is really just one loop conceptually, iterating
over a square set of elements in the 2-dimensional array x. So you
might try combining the two 'for()' statements to make a single
loop, as for example:

for( i = 0, j = 0; i < H; ++j < H || (j = 0, i++) ){
if( x[i][j] == 1 ) break;
}

The "next value" expression is a little clunky, but that's a
byproduct of C's operator set more than anything else.

== 11 of 17 ==
Date: Fri, Mar 5 2010 6:35 am
From: cri@tiac.net (Richard Harter)

On Fri, 05 Mar 2010 15:05:04 +0100, Noob <root@127.0.0.1> wrote:

>Christian Bau wrote:
>
>> That was written at a time when primitive language like BASIC and
>> FORTRAN 66 didn't have any decent control structures, and goto
>> statements had to be used to simulate control structures. Nowadays you
>> have languages like Java and C++ that provide "exceptions" which are
>> really the mother-fucking-goto-statement-from-hell.
>
>So that makes setjmp and longjmp... what? Demonic abominations?

Now that you mention it ...

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 12 of 17 ==
Date: Fri, Mar 5 2010 7:03 am
From: REH

On Mar 5, 7:08 am, Tom St Denis <t...@iahu.ca> wrote:
> On Mar 5, 4:04 am, MBALOVER <mbalov...@gmail.com> wrote:
>
>
>
> > Hi all,
>
> > I want to quit of both "for" loop whenever I find x[i][j]=1;
>
> > Do you know how to do it?
>
> > Right now, I am using the following code but I believe there should be
> > a much more efficient way for this task.
>
> > flag=0;
> > for (i=0;i<H;i++)
> > {
> >       for (j=0;j<H;j++)
> >           if (x[i][j]==1)
> >           {
> >                flag=1;
> >                break;
> >           }
> >         if( flag)
> >              break
>
> > }
>
> STANDBACK I'M ABOUT TO PERFORM MAGIC:
>
> for (i=0;i<H;i++) {
>    for (j=0;j<H;j++) {
>       if (x[i][j] == 1) {
>          goto AFTER_LOOP;
>       }
>    }}
>
> AFTER_LOOP:
>    // more code here
>

I agree. I think the lengths people go to (no pun intended) to avoid a
simple goto statement is asinine. For a language without "named
breaks," I think this is the simplest construct. This is one of two
uses that I can think of where I find a goto as the simplest solution.
I don't believe the goto is inherently bad, but like any feature, can
be abused.

I've seen some god-awful code written because someone was allergic to
a particular programming construct (e.g., goto, do loops, break,
continue, threads, multiply inheritance, exceptions, recursive
mutexes, etc. not all are relevant to C, but you get my point). I once
saw some code written for Windows by a guy that railed against
threads. It was a mess of timer events, asynchronous I/O, and an
overly complex state machine, all to avoid creating a simple
background thread.

REH

== 13 of 17 ==
Date: Fri, Mar 5 2010 7:05 am
From: Tom St Denis

On Mar 5, 9:01 am, Mark Bluemel <mark.blue...@googlemail.com> wrote:
> What makes you think my allergy comes from the article?
>
> I've been programming in various languages for over 30 years, and I
> found by experience very early on that goto was rarely useful and
> could be, as the man said, harmful. I can't remember the last time I
> used one.

As someone pointed out exceptions in Java are really just goto,
consider the two blocks

// statements that allocate ram/resources/etc
if (something() != OK) { goto error; }
if (somethingelse() != OK) { goto error; }
// ... and so on
return OK;
error:
// clean up code
return BAD;

Then compare that to

try {
something();
somethingelse();
} catch (exception e) {
// clean up
return BAD;
}
return OK;

How are they any diff [other than presentation]? "anti-goto" rules
are fairly stupid as any strict "anti-whatever" rule kinda omits the
possibility for ... exceptions to the rule ... :-)

I'm all against backwards goto in general [that's what continue is
for]. But forward goto's are perfectly fine provided they're used
when needed [exception handling and exiting a deeply nested loop being
two prime examples].

Tom

== 14 of 17 ==
Date: Fri, Mar 5 2010 7:08 am
From: cri@tiac.net (Richard Harter)

On Fri, 05 Mar 2010 06:21:47 -0800, Tim Rentsch
<txr@x-alumni2.alumni.caltech.edu> wrote:

>MBALOVER <mbalover9@gmail.com> writes:
>
>> I want to quit of both "for" loop whenever I find x[i][j]=1;
>>
>> Do you know how to do it?
>>
>> Right now, I am using the following code but I believe there should be
>> a much more efficient way for this task.
>>
>> flag=0;
>> for (i=0;i<H;i++)
>> {
>> for (j=0;j<H;j++)
>> if (x[i][j]==1)
>> {
>> flag=1;
>> break;
>> }
>> if( flag)
>> break
>> }
>
>At some level there is really just one loop conceptually, iterating
>over a square set of elements in the 2-dimensional array x. So you
>might try combining the two 'for()' statements to make a single
>loop, as for example:
>
> for( i = 0, j = 0; i < H; ++j < H || (j = 0, i++) ){
> if( x[i][j] == 1 ) break;
> }
>
>The "next value" expression is a little clunky, but that's a
>byproduct of C's operator set more than anything else.

And, of course, the termination condition could be put within the
for loop, i.e.:

for(i = 0, j= 0;
(i < H) && (x[i][j] != 1);
(++j < H) || (j = 0, i++));

To get the true spirit of C it would be better to remove all of
the spaces and put the whole thing on one line.

for(i=0,j=0;(i<H)&&(x[i][j]!=1);(++j<H)||(j=0,i++));

....

An issue that OP does not raise is the place where he quits may
depend on whether he is doing a row major or column major search;
usually it will if there is more than 1 in the array. Sometimes
it is best to do a diagonal traversal or a subsquares traversal.

Diagonal traversals look like this:

0 1 3
2 4 6
5 7 8

And subsquares traversals look like this:

0 2 4
1 3 5
6 7 8

Obviously either pattern can be reflected along the main
diagonal. Writing the corresponding loops is left as a simple
exercise for the reader.

Also one can use a function to convert the search into a search
of a one dimensional array, but this ends up being rather
cumbersome in C.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 15 of 17 ==
Date: Fri, Mar 5 2010 7:18 am
From: Tom St Denis

On Mar 5, 8:54 am, Mark Bluemel <mark.blue...@googlemail.com> wrote:
> On 5 Mar, 13:17, Rob Kendrick <n...@rjek.com> wrote:
>
> > On Fri, 5 Mar 2010 04:25:25 -0800 (PST)
>
> > Mark Bluemel <mark.blue...@googlemail.com> wrote:
> > > I'm allergic to gotos - if I managed to write COBOL without goto for
> > > many years, I think I can manage to write C without goto. (My primary
> > > language these days is Java, which doesn't even have goto).
>
> > What do you think break is, if not another word for goto?
>
> I recognise that, and I'm no great fan of break (or continue).
>
> My suggested code used neither break nor continue.

Except that you have to add a test at every nested level which
ultimately slows it down. Why isn't a simple jump out of the loop
once you hit the particular exit condition sufficient?

Worse, your solution on exits AFTER the innermost for compound
statement is finished. What if he had

// inner loop
for (j = 0; j < H && !found; j++) {
if (x[i][j] == 1) { found = 1; }
x[i][j] += 5; // or whatever...
}

He'd now have to nest it

// inner loop
for (j = 0; j < H && !found; j++) {
if (x[i][j] == 1) {
found = 1;
} else {
x[i][j] += 5; // or whatever...
}
}

Yes, clearly that's much simpler than a simple goto out of the
nesting.

Tom

== 16 of 17 ==
Date: Fri, Mar 5 2010 7:28 am
From: Ben Bacarisse

cri@tiac.net (Richard Harter) writes:

> On Fri, 05 Mar 2010 12:57:41 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>
>>The trouble with gotos is the temptation! You could be drawn into
>>using it for more than a double break and that is the start of a
>>slippery slope. I would not be happy with:
>>
>> for (i = 0; i < H; i++) {
>> for (j = 0; j < H; j++)
>> if (x[i][j] == 1)
>> goto found;
>> }
>> /* code here to what to do when the element is not found */
>>found:
>> /* code here for a successful search */
>>
>>especially if the "not found" code is long and complex.
>
> If my not terribly reliable understanding is correct, variables
> and labels are in different name spaces so you could write:
>
> int found = 0;
> for (i = 0; i < H; i++) {
> for (j = 0; j < H; j++) {
> if (x[i][j] == 1) {
> found = 1;
> goto found;
> }
> }
> }
> found:
> if (found) {/* found stuff */}
> else {/* not found stuff */}

You could, but I don't think I'd bother. Because of the way I think
about loops, the natural test after the loop is

if (i < H) /* found what we wanted */

Another small worry I'd have is that you've labeled a position in the
source with a misleading name. OK, you only jump there when the item
is found, but I prefer to use neutral names to label location one can
simply arrive at.

<snip>
--
Ben.

== 17 of 17 ==
Date: Fri, Mar 5 2010 7:29 am
From: Fred

On Mar 5, 1:04 am, MBALOVER <mbalov...@gmail.com> wrote:
> Hi all,
>
> I want to quit of both "for" loop whenever I find x[i][j]=1;
>
> Do you know how to do it?
>
> Right now, I am using the following code but I believe there should be
> a much more efficient way for this task.
>
> flag=0;
> for (i=0;i<H;i++)
> {
>       for (j=0;j<H;j++)
>           if (x[i][j]==1)
>           {
>                flag=1;
>                break;
>           }
>         if( flag)
>              break
>
> }
>

int findOne(int**x, int H, int *ip, int *jp) {
int i,j;
for (i=0;i<H;i++) {
for (j=0;j<H;j++) {
if (x[i][j]==1) {
*ip = i;
*jp = j;
return 1;
}
}
}
return 0;
}

--
Fred K

==============================================================================
TOPIC: Got stuck with quicksort code from the "Unleashed C".
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 5 2010 5:22 am
From: Eric Sosman

On 3/5/2010 1:56 AM, grishin-mailing-lists@minselhoz.samara.ru wrote:
> Hello,
>
> I'm trying to cope with quick sorting algorithm (I've been doing it
> for a week at least).
> My target is to write my own version.
> I decided to learn&& implement simplified algorithm first (that's why
> Vol.3 of Knuth is not a proper source).
> Now I'am absolutely confused because algorithms from Wirth's book,
> McConnel book and wikipedia seem to be not working (or weird-working
> at least) and I'm going to ask in a proper algorithms group.
> [... code snipped ...]

This isn't a "proper algorithms group" at all, but a group
about the C programming language. One possible PAG might be
comp.programming. But anyhow ...

The missing piece (or a missing piece) in your version is
the failure to put the pivot element itself into the right
position after partitioning. You're just leaving it where you
found it, which happens to be at the leftmost position in the
array. Then the recursive call for that portion of the array
finds the pivot still at the left, followed by a solid block
of elements all <= the pivot -- so its partitioning work does
nothing at all. And then it calls a still deeper recursion
with exactly the same situation, the deeper recursion does
nothing and calls a still deeper recursion, ...

When you can't figure something out by inspection, a very
simple (even crude) technique is startlingly effective: Add a
few printf() calls at strategic spots. In this instance, a
fairly obvious spot is the start of each QSORTB invocation:
print out the values of l,r to indicate which part of the
array is being worked on -- You would have seen a progression
like [0,15], [0,7], [0,7], [0,7], [0,7], ..., crash, and you
would have figured out pretty quickly that the recursive calls
were making no progress. It wouldn't tell you *why* they were
making no progress, but it would have focused your attention.

Two further suggestions: In a recursive setting it's often
helpful to print the recursion depth along with the interesting
values, which would require that you change the code a little
to adjust the depth as you call and return (you can rip the
extra code out later). Second, in a situation where a crash
is expected or likely, it may be better to fprintf(stderr,...)
than to printf(), to avoid issues with buffering on stdout.
(For the topicality police: That last bit is, I claim, about C.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 2 of 2 ==
Date: Fri, Mar 5 2010 5:36 am
From: Ben Bacarisse

grishin-mailing-lists@minselhoz.samara.ru writes:

> I'm trying to cope with quick sorting algorithm (I've been doing it
> for a week at least).
> My target is to write my own version.

Is this coursework?

> I decided to learn && implement simplified algorithm first (that's why
> Vol.3 of Knuth is not a proper source).
> Now I'am absolutely confused because algorithms from Wirth's book,
> McConnel book and wikipedia seem to be not working (or weird-working
> at least) and I'm going to ask in a proper algorithms group.
>
> In addition,
> the code of simplified quick sort gives "stack overflow" too!
>
> #include <stdio.h>
>
> #define N (sizeof k / sizeof k[0])

I'd prefer this to be a function-like macro:

#define SZ(a) (sizeof (a) / sizeof (a)[0])

> void QSORTB(int * A, int l, int r)
> {
> int loc;
>
> if (l < r) {
> int i = l,
> j = r;
> int tmp,
> pivot = A[l];

Strange layout. This discourages people from reading the code!

> /* Divide piles into partitions */
> for (;;) {
> while ((A[j] >= pivot) && (j > l))
> j--;
> while ((A[i] <= pivot) && (i < r))
> i++;
> if (i < j) {
> tmp = A[i];
> A[i] = A[j];
> A[j] = tmp;
> } else {
> loc = j;
> break;
> }
> }
> /* Recurse */
> QSORTB(A, l, loc);
> QSORTB(A, loc + 1, r);
> }
> }

The "shape" of the code is right but the details are wrong. Take a
simple example and work it through on paper (or in a debugger). Try
sorting { 11, 10 }. If you get stuck post again with what you think
happens in this case.

You get more answers in comp.programming since this is not really (at
least not yet) a C question.

<snip>
--
Ben.

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Mar 5 2010 6:22 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <OIidndrfAtccKg3WnZ2dnUVZ8sCdnZ2d@bt.com>,
Richard Heathfield <rjh@see.sig.invalid> writes:

> Seebs wrote:
>
> <snip>
>
>> When I see "if (x != y)" in C, I
>> unconsciously perceive it to be the case that x could vary and y couldn't.
>
> Why?

Because he pronounces it as "x is not equal to y", and the subject of
that sentence is "x". "x" is the actor, the variable that is acting. "y"
is part of the prepositional phrase, it is static.

>> Consider:
>> for (i = 0; i < 10; ++i)
>>
>> Why do we write "i < 10" rather than "10 >= i"?
>
> Good question.

... It's either me, or now two of you not noticing (or ignoring) that
"10 == i" satisfies the second but not the first.

>> Because i's the one that
>> varies, so "i is less than ten" is more idiomatic than "ten is greater than
>> or equal to i".
>
> Why?

Because programmatically, "i" changes over time, 10 does not, and when
one reads out loud the controlling expression in English, the subject of
that sentence ("the actor") should be the entity that is acting.

>
>> Now consider:
>> for (i = 0; i < max; ++i)
>>
>> even though "max" may vary over time, the assumption is that, for this loop,
>> i changes and max doesn't.
>
> Why?

Because when read out loud, "i" is the subject.

>> The time when that technique caught something compilers wouldn't catch
>> is long gone. I don't think it's needed anymore.
>
> You'd be amazed at the antiquity of some compilers. At one recent site,
> I was somewhat surprised to find an entire project team still using
> MSC5.00a (and they seemed perfectly contented, too).

The following version of gcc:

gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

displays no warning for the following:

$ gcc -Wall -Wextra -ansi -pedantic -fsyntax-only try.c

----v----
static int
f(int a)
{
return a = 3;
}

static int
g(int a)
{
return (a = 3);
}
----^----

(Yes, we could fix that by taking "a" as const.)

Another example, showing that extra parentheses can shut up gcc:

----v----
int f(void);

static void
g(void)
{
int a;

a = f();
if ((a = 2) || (a = 3)) {
/* ... */
}
}
----^----

This produces no warnings either. Although the parentheses are not
needed for the intended meaning, that is, for

a == 2 || a == 3

some people might find the parenthesized version more readable, and when
they combine that with typing assignment instead of equality, then (this
version of) gcc won't warn them.

Cheers,
lacos

== 2 of 4 ==
Date: Fri, Mar 5 2010 6:59 am
From: Tim Rentsch

Keith Thompson <kst-u@mib.org> writes:

> Ian Collins <ian-news@hotmail.com> writes:
>> Tim Rentsch wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>>>> Anand Hariharan wrote:
>>>>> <snip>
>>>>>> Haven't seen anyone point this out:
>>>>>>
>>>>>> Rather than -
>>>>>>
>>>>>> #define MAXNUMFILES 1024
>>>>>>
>>>>>> - prefer -
>>>>>>
>>>>>> const int MaxNumFiles = 1024;
>>>>>>
>>>>>>
>>>>>> That way your preprocessor won't do as much damage.
>>>>> Fine in C99, I think, but an issue in C90 if he's using it to define
>>>>> an array size.
>>>> It's a problem in C99 too, if the array is defined at file scope or it
>>>> has internal linkage. There are other reasons why it's not a great
>>>> idea in C99. They stem from the fact that MaxNumFiles is not
>>>> permitted as part of a constant expression. [snip elaboration]
>>>
>>> Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
>>> expression, albeit an implementation-specific constant expression;
>>> it just isn't _required_ to be a portable constant expression.
>>
>> What? You could say just about any nonsense is permitted as part of
>> an implementation-specific expression.
>>
>> That doesn't alter that fact that in C90 or C99, MaxNumFiles is not
>> permitted as part of a constant expression.
>
> I think Tim is referring to C99 6.6p10:
>
> An implementation may accept other forms of constant expressions.

Quite so.

> (I just noticed that this doesn't use the term
> "implementation-defined" implying, I think, that an implementation
> can accept other forms of constant expressions but isn't required
> to document them.)

My belief is that such forms of constant expressions still count
as language extensions. If they are they must be documented,
because extensions are required to be documented.

> My understanding is that code that uses extensions in general (as
> permitted by C99 4p6) still require diagnostics if the code violates a
> constraint, but code that uses "other forms of constant expressions"
> does not.

Yes, diagnostics are still required for using any extensions that
is a syntax error or a constraint violation, but not not if they
don't, and that also includes "other forms of constant expressions".
(In other words my assessment here agrees with Keith's.)

> I'd say Tim's statement is correct, but I'd place the emphasis very
> differently: MaxNumFiles is not permitted as part of a constant
> expression (unless the implementation permits it under C99 6.6p10).

What I was trying to express is that this form of CE is allowed
in the sense of not being forbidden. Some forms of CE are
"forbidden" in the sense that they would be constraint violations
even if they were language extensions, although of course they
could be accepted if a diagnostic were produced. So in saying
MaxNumFiles is permitted as a CE, what I meant was it can be
accepted by an implementation without requiring any diagnostic
(with the additional qualifier, already explained, that there is
no portable requirement that it be accepted).

> Are there any real-world C implementations that take advantage of this
> permission? Specifically, is there a C compiler that accepts
> additional forms of constant expressions in (what it claims to be)
> conforming mode?

Yes, I believe (some versions of?) gcc to be in this category.

> And why is that permission there in the first place? What benefit
> does it really provide beyond the existing permission to provide
> extensions?

It seems clear that the point is to allow additional forms of
constant expression without absolutely insisting on generating a
diagnostic; in other words to leave the question of diagnostics
up to the discretion of the implementation. Without 6.6p10 any
other forms of constant expression wouldn't meet the Standard's
definition, and if used in places that need constant expressions
would cause constraint violations.

== 3 of 4 ==
Date: Fri, Mar 5 2010 7:13 am
From: Ben Bacarisse

lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> In article <OIidndrfAtccKg3WnZ2dnUVZ8sCdnZ2d@bt.com>,
> Richard Heathfield <rjh@see.sig.invalid> writes:
>
>> Seebs wrote:
<snip>
>>> Consider:
>>> for (i = 0; i < 10; ++i)
>>>
>>> Why do we write "i < 10" rather than "10 >= i"?
>>
>> Good question.
>
> ... It's either me, or now two of you not noticing (or ignoring) that
> "10 == i" satisfies the second but not the first.

I assumed that the "good question" reply was intended to draw Seebs's
attention to that fact; otherwise I'd have pointed it out. Looking
at it now, with all of Richard's "why" questions, it seems possible
that the reply was not meant the way I assumed it was.

Either way, it's not really at the heart of the question unless you
think the switch *caused* the typo.

<snip>
--
Ben.

== 4 of 4 ==
Date: Fri, Mar 5 2010 7:26 am
From: Jerry Friedman

On Mar 4, 5:54 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-05, Keith Thompson <ks...@mib.org> wrote:
>
> > I suggest that in cases where "is" is used to denote equality,
> > usage is more symmetric than you might think.  "My brother is Fred
> > Thompson" and "Fred Thompson is my brother" seem equally clear to me
> > (and equally false, since that's not my brother's name).
>
> They're both equally clear, but they are communicating different things.
> One of them is telling us something we might not already know, about an
> entity already known to be your brother.  The other is telling us something
> we might not already know, about an entity already known to be Fred Thompson.
>
> Similarly, there's a big difference between "the person who committed the
> murder was the butler" and "the butler committed the murder".  The former
> is giving you information about a murder you already know about, the other
> is giving you information about a butler you already know about.
...

For those interested in what linguists have said about this, the terms
seem to be "topic" and "comment" or "theme" and "rheme". In English,
the topic usually goes before the comment. Of course even in a single
language the matter is complicated, and different linguists use
different approaches and different terminology.

--
Jerry Friedman

==============================================================================
TOPIC: help: gcc compilation difference
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 6:34 am
From: Tim Rentsch

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>
> I agree with what you've written but want to raise a detail so
> forgive me for snipping so much of a helpful reply...
>
>> First, about unions. Suppose we have a union containing just a
>> signed integer member, eg,
>>
>> union { signed int si; } siu;
>>
>> where both sizeof siu == 4 and sizeof siu.si == 4 are true.
>>
>> In such a case there are in fact two distinct objects, even though
>> they happen to occupy exactly the same area of memory -- there is
>> 'siu', and 'siu.si'. We know these are different because the
>> object designated by 'siu' can never be a trap representation,
>> (because it's a union, which are never trap representations) even
>> though 'siu.si' holds a trap representation.
>>
>> (Editorial side note: the language the Standard uses relating to
>> the term "object" in various places is among the poorest sets of
>> phrasings the Standard employs. At some point I might write
>> something more about that, but right now I'd like to gloss over
>> those problems.)
>>
>> Similarly, in the example union mentioned above
>>
>> union { int si; unsigned ui; } u;
>>
>> there actually are three distinct objects -- u, u.si, and u.ui.
>> That at least two of these three occupy exactly the same bytes of
>> memory doesn't alter the number, since unions are described as
>> _overlapping_ objects.
>
> This is obviously the intent from the wording about unions but there
> is a problem with the == operator. 6.5.9 p6 reads:
>
> Two pointers compare equal if and only if both are null pointers,
> both are pointers to the same object (including a pointer to an
> object and a subobject at its beginning) or function, both are
> pointers to one past the last element of the same array object, or
> one is a pointer to one past the end of one array object and the
> other is a pointer to the start of a different array object that
> happens to immediately follow the first array object in the address
> space.
>
> So unless we stretch the meaning of the parenthetical remark, we would
> have to conclude that (void *)&u.si == (void *)&u.ui must be false
> since these two are not the same object.
>
> Of course, both u.si and u.ui are subobjects at the same object's
> beginning, but that case is not explicitly covered.
>
> <snip>

This comment illustrates one of my complaints with how the
term "object" is used in the Standard. Sometimes (as in the
cited paragraph) it means just a region of storage and nothing
more than that. Other times it means a kind of association
between an identifier and a region of storage, almost but
not quite what "variable" means in most programming languages.

I absolutely agree with your comment about the cited paragraph,
but I attribute the problem more to sloppy use of language
for the term "object" than indicating any deeper problem
in the C language requirements. In other words the problem
is with how the specifications are written, not with what
I believe to be what the specifications are meant to express.

==============================================================================
TOPIC: efficiency question
http://groups.google.com/group/comp.lang.c/t/ac42317db6371cec?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 5 2010 7:11 am
From: Bob

Hello,

Please see my question below :

type 'data2' is defined :

typedef struct data2
{
int m;
float n;

} data2;

data1 is defined :

typedef struct data1
{
int a;
float b;
data2 *d2 // pointer to a data2 type

} data1;

I have a function with 3 arguments :

void func(data1 *x, data2* y, char z)
{
.
.
.
}

I can also write this function as

void func(data1 *x, char z)
{
data2 *y = x->d2
.
.
.
}

I use the function 'func' millions of times,
which implementation from the above two, will be quicker ?

(the first variation allocates 3 places on the stack, the second only
2, but it also has an extra line for assigning the pointer of data2)

Thanks :-)

Bob

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

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