Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #77065 > unrolled thread

qsort() function misunderstanding

Back to article view | Back to comp.lang.c

Contents

  qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-24 01:48 -0800
    Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-24 10:32 +0000
      Re: qsort() function misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-24 11:08 +0000
        Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-24 12:03 +0000
          Re: qsort() function misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-24 16:12 +0000
      Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-24 03:33 -0800
        Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-24 12:05 +0000
          Re: qsort() function misunderstanding glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-24 13:52 +0000
            Re: qsort() function misunderstanding Ken Brody <kenbrody@spamcop.net> - 2015-11-24 10:01 -0500
          Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-24 06:04 -0800
            Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-24 14:16 +0000
        Re: qsort() function misunderstanding James Kuyper <jameskuyper@verizon.net> - 2015-11-24 07:32 -0500
          Re: qsort() function misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-24 16:43 +0000
            Re: qsort() function misunderstanding glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 05:58 +0000
              Re: qsort() function misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-25 11:34 +0000
                Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-25 12:45 +0000
                  Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-26 02:18 -0800
                    Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-26 10:45 +0000
                Re: qsort() function misunderstanding glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 14:46 +0000
            Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-25 00:51 -0800
              Re: qsort() function misunderstanding James Kuyper <jameskuyper@verizon.net> - 2015-11-25 08:12 -0500
                Re: qsort() function misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-25 14:02 +0000
                  Re: qsort() function misunderstanding James Kuyper <jameskuyper@verizon.net> - 2015-11-25 11:37 -0500
                    Re: qsort() function misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-25 17:36 +0000
    Re: qsort() function misunderstanding Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-24 03:30 -0800
      Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-24 03:48 -0800
        Re: qsort() function misunderstanding Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-24 06:29 -0800
      pre/post increments (was Re: qsort() function misunderstanding) Ken Brody <kenbrody@spamcop.net> - 2015-11-24 09:55 -0500
    Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-24 06:06 -0800
    Re: qsort() function misunderstanding Barry Schwarz <schwarzb@dqel.com> - 2015-11-24 07:33 -0800
    Re: qsort() function misunderstanding Keith Thompson <kst-u@mib.org> - 2015-11-24 09:04 -0800
      Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-24 17:17 +0000
        Re: qsort() function misunderstanding Geoff <geoff@invalid.invalid> - 2015-11-24 10:03 -0800
          Re: qsort() function misunderstanding Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-24 13:31 -0500
            Re: qsort() function misunderstanding Geoff <geoff@invalid.invalid> - 2015-11-24 12:34 -0800
              Re: qsort() function misunderstanding Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-24 16:02 -0500
                Re: qsort() function misunderstanding supercat@casperkitty.com - 2015-11-24 15:18 -0800
                  Re: qsort() function misunderstanding Chad <cdalten@gmail.com> - 2015-11-24 16:15 -0800
                    Re: qsort() function misunderstanding Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-24 23:51 -0800
              Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-25 01:01 -0800
                Re: qsort() function misunderstanding glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 12:53 +0000
                  Re: qsort() function misunderstanding supercat@casperkitty.com - 2015-11-25 10:15 -0800
                    Re: qsort() function misunderstanding glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 23:14 +0000
                      Re: qsort() function misunderstanding supercat@casperkitty.com - 2015-11-25 16:33 -0800
                        Re: qsort() function misunderstanding glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-26 08:18 +0000
        Re: qsort() function misunderstanding Ian Collins <ian-news@hotmail.com> - 2015-11-25 10:41 +1300
          Re: qsort() function misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-24 22:08 +0000
      Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-25 00:53 -0800
    Re: qsort() function misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-25 09:07 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#77160

On 11/25/2015 03:51 AM, Alla _ wrote:
...
> Ben, thank you very much. You are the only one who did actually understand 
> the idea of the course, and what it gives one. And, yes, I am trying to 
> understand more than is required, because I would feel more comfortable 
> doing the majority of problems discussed at the course, if I have a 
> better knowledge on C - that is my choice. 

That would be fine, if you were actually understanding it. In reality,
you're manifestly trying to cover this material too fast to for you to
actually understand it. You earlier gave the pace of your course as the
reason why you are forced to go through this material so fast. If going
through it this fast is in fact your own choice, and not forced by your
course work, you have no such justification. You should choose to slow
down, in fact, back up, and don't even start a new chapter until you've
fully mastered all of the previous ones. Otherwise, in the long run you
won't actually learn anything but frustration.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#77161

James Kuyper <jameskuyper@verizon.net> writes:

> On 11/25/2015 03:51 AM, Alla _ wrote:
> ...
>> Ben, thank you very much. You are the only one who did actually understand 
>> the idea of the course, and what it gives one. And, yes, I am trying to 
>> understand more than is required, because I would feel more comfortable 
>> doing the majority of problems discussed at the course, if I have a 
>> better knowledge on C - that is my choice. 
>
> That would be fine, if you were actually understanding it. In reality,
> you're manifestly trying to cover this material too fast to for you to
> actually understand it. You earlier gave the pace of your course as the
> reason why you are forced to go through this material so fast. If going
> through it this fast is in fact your own choice, and not forced by your
> course work, you have no such justification. You should choose to slow
> down, in fact, back up, and don't even start a new chapter until you've
> fully mastered all of the previous ones. Otherwise, in the long run you
> won't actually learn anything but frustration.

Not everyone learns the same way.  I'm not saying I'm right and you are
wrong -- without getting to know a student in person I think it's
impossible to tell what style will suite them -- but your strict "don't
take another step until you've understood the motivation for the last
one, the kinetics of your foot swing and the chemical composition of the
pavement" is not for everyone.  Some people are repeat scanners -- they
take the same time to absorb a book, but they do it by reading it from
front to back many times.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#77169

On 11/25/2015 09:02 AM, Ben Bacarisse wrote:
...
> Not everyone learns the same way.  I'm not saying I'm right and you are
> wrong -- without getting to know a student in person I think it's
> impossible to tell what style will suite them -- but your strict "don't
> take another step until you've understood the motivation for the last
> one, the kinetics of your foot swing and the chemical composition of the
> pavement" is not for everyone.  Some people are repeat scanners -- they
> take the same time to absorb a book, but they do it by reading it from
> front to back many times.

If her way of learning was working for her, I wouldn't care how she did
it - she could read the chapters in alphabetical order by chapter title,
for all I care. But her way doesn't appear to be working very well.

[toc] | [prev] | [next] | [standalone]

#77172

James Kuyper <jameskuyper@verizon.net> writes:

> ... But her way doesn't appear to be working very well.

I don't know how you can possible know it's not working.  For one
thing you don't know her objectives.

(It seems a bit rude to have a conversation about a third party, so I've
tried to keep my remarks general, but I can't do that here.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#77077

On Tuesday, November 24, 2015 at 9:49:17 AM UTC, Alla _ wrote:
> Hello!
> 
> Please, help me to understand the qsort function, which I publish below
> my walkthrough. I have a few questions but I will ask them gradually, in
> a hope that some might become clear on the way. 
> 
> Consider an array v[] = {8,1,10,7,5}
> 
>     void qsort(int v[], int left, int right)
> 
> 1. Before entering the body of the function, I have to choose values 
> for left and right. Let left = 0, right = 2.
> 
> 2. First if condition doesn't hold, therefore the program moves further.
> if (left >= right) 
>     return;
> 
> 3. swap(v, left, (left + right)/2)
> By calling swap() function the program swaps v[0] and v[2].
> The array now looks this way: {10,1,8,7,5}
> 
> 4. The program assigns 0 (value of left) to variable last.
> 
> 5. For loop starts first iteration from i = left + 1 = 1, and iterates
> until i = 2
>    for (i = left+1; i <= right; i++)
> 6. Condition in the body of the loop checks if the value at v[i], i.e. v[1]
> at the first iteration, is less than the value of v[left], i.e. v[0].
> 
> Yes, it is; therefore these values should be swapped:
> if (v[i] < v[left])
>     swap(v, ++last, i);
> Given last = left, the argument ++last passed to the swap function, implies
> that last has been incremented before used by the function. Is it a correct
> assumption? If last has been incremented by one, then this swap function 
> doesn't seem to make sense, because it will intent to swap one element at
> v[1] (++last would equal 1).
> 
Pre-increments happen before anything else, post-increments after.
But pre-increments tend to make code hard to read. If you've any doubt
at all, simply break the logic into two lines. 

The logic seems right to me. But create lots of random arrays to test.

Incidentally it's best to call the function quicksort() to avoid using the same
name as standard library function.
 

[toc] | [prev] | [next] | [standalone]

#77079

On Tuesday, November 24, 2015 at 3:30:39 PM UTC+4, Malcolm McLean wrote:
> On Tuesday, November 24, 2015 at 9:49:17 AM UTC, Alla _ wrote:
> > Hello!
> > 
> > Please, help me to understand the qsort function, which I publish below
> > my walkthrough. I have a few questions but I will ask them gradually, in
> > a hope that some might become clear on the way. 
> > 
> > Consider an array v[] = {8,1,10,7,5}
> > 
> >     void qsort(int v[], int left, int right)
> > 
> > 1. Before entering the body of the function, I have to choose values 
> > for left and right. Let left = 0, right = 2.
> > 
> > 2. First if condition doesn't hold, therefore the program moves further.
> > if (left >= right) 
> >     return;
> > 
> > 3. swap(v, left, (left + right)/2)
> > By calling swap() function the program swaps v[0] and v[2].
> > The array now looks this way: {10,1,8,7,5}
> > 
> > 4. The program assigns 0 (value of left) to variable last.
> > 
> > 5. For loop starts first iteration from i = left + 1 = 1, and iterates
> > until i = 2
> >    for (i = left+1; i <= right; i++)
> > 6. Condition in the body of the loop checks if the value at v[i], i.e. v[1]
> > at the first iteration, is less than the value of v[left], i.e. v[0].
> > 
> > Yes, it is; therefore these values should be swapped:
> > if (v[i] < v[left])
> >     swap(v, ++last, i);
> > Given last = left, the argument ++last passed to the swap function, implies
> > that last has been incremented before used by the function. Is it a correct
> > assumption? If last has been incremented by one, then this swap function 
> > doesn't seem to make sense, because it will intent to swap one element at
> > v[1] (++last would equal 1).
> > 
> Pre-increments happen before anything else, post-increments after.
> 
Yes, that's what I have written; last is first incremented and then used by 
swap function. In the first iteration of the for loop, i = 1 and last = 0 (
= left). If 'if statement' is true, and it is, then the program calls 
swap function and before passing 'last' to it the program increments it, hence 
last = 1. Is it correct? If yes, how can v[1] be swapped with v[1]? 

> 
> Incidentally it's best to call the function quicksort() to avoid using the same
> name as standard library function.

I will rename it, thank you. 

[toc] | [prev] | [next] | [standalone]

#77096

On Tuesday, November 24, 2015 at 11:48:59 AM UTC, Alla _ wrote:
> On Tuesday, November 24, 2015 at 3:30:39 PM UTC+4, Malcolm McLean wrote:
>
> Yes, that's what I have written; last is first incremented and then used by 
> swap function. In the first iteration of the for loop, i = 1 and last = 0 (
> = left). If 'if statement' is true, and it is, then the program calls 
> swap function and before passing 'last' to it the program increments it, hence 
> last = 1. Is it correct? If yes, how can v[1] be swapped with v[1]? 
> 
Swapping something with itself is a null operation. You do actually get into subtle
problems when two pointers refer to the same object, but leave that for now.
We set last to the object after the pivot point. Then we go through the array,
and every time we see an object smaller than  the pivot, we swap it with last
and increment last. So with this algorithm, last will quite often be swapped with itself,
especially if the array is short.
(You can optimise the code to avoid that, but that's something for after you're happy
with the basic algorithm. 

[toc] | [prev] | [next] | [standalone]

#77099 — pre/post increments (was Re: qsort() function misunderstanding)

On 11/24/2015 6:30 AM, Malcolm McLean wrote:
> On Tuesday, November 24, 2015 at 9:49:17 AM UTC, Alla _ wrote:
[...]
>> doesn't seem to make sense, because it will intent to swap one element at
>> v[1] (++last would equal 1).
>>
> Pre-increments happen before anything else, post-increments after.
> But pre-increments tend to make code hard to read. If you've any doubt
> at all, simply break the logic into two lines.
[...]

Close, but your statement implies things that aren't guaranteed.

A pre-increment returns the value of the incremented variable, but the only 
guarantee of when the increment actually happens is "sometime before the 
next sequence point".  There is no guarantee that it will happen "before 
anything else", just that "++something" will increment "something" before 
the next sequence point, and that its value is that of the incremented 
value, even if that increment has not actually happened yet.

Perhaps I'm being a bit picky, but saying that they "happen before anything 
else" leads to people writing code like "array[i++] = i;".

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#77093

Questions in this thread are designed to help me to understand issues
that I still don't. Therefore, I do hope to get to grips with this qsort() -
it is based on basic concepts, nothing fancy in it. 

[toc] | [prev] | [next] | [standalone]

#77103

On Tue, 24 Nov 2015 01:48:58 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>Hello!
>
>Please, help me to understand the qsort function, which I publish below

The quicksort algorithm is much too complex for your current
understanding of both C and programming in general.

You need to give us a reference for the function that we can look at
and see if you copied correctly for us.

Why do you claim in other messages in this thread that you are rushed
to look at this function by some CS50 course when in actuality it is
from page 87 or K&R II.  You are racing through this reference
material as if it was a work of literature.  You will not learn the
details that you need with this approach.  You should be spending days
on each section.  In some cases on a single page.  You are plunging
into recursion when you still lack an understanding of many C
fundamentals.

How many times do we have to tell you to slow down?  Continuing to
ignore the best advice you have received will lead many of us to stop
offering any advice.  SLOW DOWN!

>my walkthrough. I have a few questions but I will ask them gradually, in
>a hope that some might become clear on the way. 
>
>Consider an array v[] = {8,1,10,7,5}
>
>    void qsort(int v[], int left, int right)
>
>1. Before entering the body of the function, I have to choose values 
>for left and right. Let left = 0, right = 2.

Did you realize before I mention it now that the function you publish
sorts a SELECTED PORTION of the array and not necessarily the whole
array?  If so, why is your sample an array of 5 elements if you will
only sort 3?

>2. First if condition doesn't hold, therefore the program moves further.
>if (left >= right) 
>    return;
>
>3. swap(v, left, (left + right)/2)
>By calling swap() function the program swaps v[0] and v[2].

You say left is 0 and right is 2 and somehow conclude that (0+2)/2 is
2.  You may as well stop your analysis here because you already
introduced what may be a fatal error.

>The array now looks this way: {10,1,8,7,5}

No it doesn't and I will stop here.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#77109

Alla _ <modelling.data@gmail.com> writes:
> Please, help me to understand the qsort function, which I publish below
> my walkthrough. I have a few questions but I will ask them gradually, in
> a hope that some might become clear on the way. 
>
> Consider an array v[] = {8,1,10,7,5}
>
>     void qsort(int v[], int left, int right)

Don't call your function qsort.  That's the name of a standard library
function with a different declaration.  That might be causing problems
for you; when you try to call your own function, the compiler might
generate a call to the predefined qsort() -- with incorrect parameters.

If you're implementing the Quicksort algorithm, just call it
"quicksort".

-- 
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"

[toc] | [prev] | [next] | [standalone]

#77113

On 24/11/15 17:04, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
>> Please, help me to understand the qsort function, which I publish below
>> my walkthrough. I have a few questions but I will ask them gradually, in
>> a hope that some might become clear on the way.
>>
>> Consider an array v[] = {8,1,10,7,5}
>>
>>      void qsort(int v[], int left, int right)
>
> Don't call your function qsort.

After Ben slapped my wrist elsethread, I took a closer look. In Alla's 
defence, this code appears to come from p87 of K&R2. Alla has rightly 
been told that K&R know what they're talking about, and /they/ call the 
function qsort, so it's not surprising that she kept that name.

It is of course true that the name clashes with that of a standard 
library function, and yes, it's advisable to change the name.

So why did K&R name it qsort in the first place? Well, I'm only 
guessing, but it's quite likely that the standard library function has 
its origins in K&R (1, rather than 2, although I lack a K&R1 so I can't 
check that this code is also in that edition of the book). And, if that 
is the case, K&R would be quite within their rights to reason "we 
thought of it first, so it stays".

Yes, Alla should change the name of her version of the function - I'm 
just pointing out that it was a reasonable name for her to choose, which 
just happens to be - or rather, *to have become* - a bad choice.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#77119

On Tue, 24 Nov 2015 17:17:28 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>On 24/11/15 17:04, Keith Thompson wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>> Please, help me to understand the qsort function, which I publish below
>>> my walkthrough. I have a few questions but I will ask them gradually, in
>>> a hope that some might become clear on the way.
>>>
>>> Consider an array v[] = {8,1,10,7,5}
>>>
>>>      void qsort(int v[], int left, int right)
>>
>> Don't call your function qsort.
>
>After Ben slapped my wrist elsethread, I took a closer look. In Alla's 
>defence, this code appears to come from p87 of K&R2. Alla has rightly 
>been told that K&R know what they're talking about, and /they/ call the 
>function qsort, so it's not surprising that she kept that name.
>
>It is of course true that the name clashes with that of a standard 
>library function, and yes, it's advisable to change the name.
>
>So why did K&R name it qsort in the first place? Well, I'm only 
>guessing, but it's quite likely that the standard library function has 
>its origins in K&R (1, rather than 2, although I lack a K&R1 so I can't 
>check that this code is also in that edition of the book). And, if that 
>is the case, K&R would be quite within their rights to reason "we 
>thought of it first, so it stays".
>
>Yes, Alla should change the name of her version of the function - I'm 
>just pointing out that it was a reasonable name for her to choose, which 
>just happens to be - or rather, *to have become* - a bad choice.

In defense of Alla_ and K&R2, on page 87 they cite Hoare 1962 as the
source of quicksort, they state that their qsort is sub-optimal but a
simple implementation of quicksort and it's intended to demonstrate
recursion which is what section 4.10 that begins on page 86 is all
about. You can't use qsort as a demo of recursion without writing it
out somewhere for the student to inspect. Furthermore, it doesn't
appear they actually intended it to be compiled. It's only another
example of a recursive function of which their printd was their first
example.

On page 88 after defining the swap function for their qsort they
state:

"The standard library includes a version of qsort that can sort
objects of any type."

I suspect they named it qsort and not quicksort because at the time
ANSI C was being defined only the first six characters of an object
name were unique and pre-ANSI and ANSI C programmers had the nasty
habit of chopping off function names in the standard library. (e.g.,
creat)

I'm rather disappointed by the attitudes expressed in this group. I
see a lot of nit picking and esoteric citation and wild tangents and
asides that do the student a disservice. Anyone who gives advice to
Alla_ should at least be expressly familiar with the chapter, code and
principles she is dealing with and not be caught up in the
trivialities of the names of functions in the examples. Especially
since K&R themselves have already said it in the book.

[toc] | [prev] | [next] | [standalone]

#77121

On 11/24/2015 1:03 PM, Geoff wrote:
>[... K&R called their non-Standard sorter `qsort' ...]
>
> I'm rather disappointed by the attitudes expressed in this group. I
> see a lot of nit picking and esoteric citation and wild tangents and
> asides that do the student a disservice. Anyone who gives advice to
> Alla_ should at least be expressly familiar with the chapter, code and
> principles she is dealing with and not be caught up in the
> trivialities of the names of functions in the examples. Especially
> since K&R themselves have already said it in the book.

     Telling Alla "Don't call your own function qsort" is good advice,
and useful even to a student.  If the student names a function qsort
(or exit or sqrt or ...), mystifying things are more likely to occur
that if it were named quicksort (or leave or root2 or ...).  Saving a
beginner from mystery is a good thing.

     As to the esoteric tangents, though, I agree with you.  A beginner
is not yet ready to confront the DeathStation 9000.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#77126

On Tue, 24 Nov 2015 13:31:05 -0500, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>On 11/24/2015 1:03 PM, Geoff wrote:
>>[... K&R called their non-Standard sorter `qsort' ...]
>>
>> I'm rather disappointed by the attitudes expressed in this group. I
>> see a lot of nit picking and esoteric citation and wild tangents and
>> asides that do the student a disservice. Anyone who gives advice to
>> Alla_ should at least be expressly familiar with the chapter, code and
>> principles she is dealing with and not be caught up in the
>> trivialities of the names of functions in the examples. Especially
>> since K&R themselves have already said it in the book.
>
>     Telling Alla "Don't call your own function qsort" is good advice,
>and useful even to a student.  If the student names a function qsort
>(or exit or sqrt or ...), mystifying things are more likely to occur
>that if it were named quicksort (or leave or root2 or ...).  Saving a
>beginner from mystery is a good thing.
>
>     As to the esoteric tangents, though, I agree with you.  A beginner
>is not yet ready to confront the DeathStation 9000.

I don't object to saying, "This function shouldn't be named qsort."
But it should be said in the context of the book, which up to that
point has seldom included standard library headers beyond stdio.h and
has already defined functions like atoi, strlen, strcat, itoa, atof,
getch and ungetch without the standard library all while usually, (I
have not found any instances yet, where they haven't) mentioning
instances where the functions mentioned are standard library
functions. Where they don't explicitly talk about what are now
standard library functions, I believe those functions weren't yet in
the standard library. Yet, the student is easily advised to refer to
Appendix B. For compilation of the examples in K&R2, the student will
never encounter name collisions with library functions unless they
include headers they weren't intended to include if they are following
the text.

As an instructor, I'd prefer to confine myself to answering the direct
questions, explain what the particular example is trying to show and
Socratically get the student to explain his own understanding and only
warn against name collisions when the student is surprised by one.

[toc] | [prev] | [next] | [standalone]

#77127

On 11/24/2015 3:34 PM, Geoff wrote:
> [...]
> I don't object to saying, "This function shouldn't be named qsort."
> [...] For compilation of the examples in K&R2, the student will
> never encounter name collisions with library functions unless they
> include headers they weren't intended to include if they are following
> the text.

     You're wrong on that last point, unless the student is also
told to use `static' on all the colliding names.  The library's
external-linkage names are reserved in the external-linkage space,
whether the program uses them or not, includes their headers or not.

     I have used a C implementation in which the entire library was
delivered as a single, indivisible shared-library "package," and
if you tried to reuse any of the package's externally-linked names
you'd get a linker error.  This particular implementation was pre-
ANSI, I admit, but post-ANSI implementations are allowed to use
similar techniques and impose similar restrictions.

     The mysteries we're trying to steer the student away from
won't vanish simply because the student doesn't know of them --
and they may appear if the student names a function qsort().
(Or they may not: The essence of undefined behavior is that
it's not defined ...)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#77134

On Tuesday, November 24, 2015 at 3:02:28 PM UTC-6, Eric Sosman wrote:
>      You're wrong on that last point, unless the student is also
> told to use `static' on all the colliding names.  The library's
> external-linkage names are reserved in the external-linkage space,
> whether the program uses them or not, includes their headers or not.

I wonder if there would have been any problem with having C include a standard
means for defining separate internal and external names and indicating that
external names C00L0A through C99L9Z were reserved by the implementation for
mapping to standard library functions in unspecified order?  That would have
made it possible to add new header files which include functions with "normal-
seeming" names without breaking existing code, and would also have eliminated
the need to have library functions with overly-truncated names even on systems
where external linkage limited names to six characters.

[toc] | [prev] | [next] | [standalone]

#77138

I've only met one person who could learn a programming language at a breakneck speed. He was able to learn and master the Ruby Programming language in three days. However he had a Ph.D in Computer Science from Harvard and spent thirty years as a professional programmer. I guess what also helped was that his IQ hovered around the 180 mark.

[toc] | [prev] | [next] | [standalone]

#77148

On Wednesday, November 25, 2015 at 12:15:52 AM UTC, Chad wrote:
> I've only met one person who could learn a programming language at
> a breakneck speed. He was able to learn and master the Ruby Programming 
> language in three days. However he had a Ph.D in Computer Science from
> Harvard and spent thirty years as a professional programmer. I guess 
> what also helped was that his IQ hovered around the 180 mark.
>
I'd expect any professional programmer to be able to understand,
modify, and start from scratch a small program in any language,
with decent or halfway competent language documentation.

That's actually a test I use for good programming and a good
language. If a person with only very slight familiarity with
the language would struggle with a construct, take it out.

[toc] | [prev] | [next] | [standalone]

#77153

> 
> As an instructor, I'd prefer to confine myself to answering the direct
> questions, explain what the particular example is trying to show and
> Socratically get the student to explain his own understanding and only
> warn against name collisions when the student is surprised by one.

Thank you. This is the approach that I would apply if I were 
to help someone to get through the material (and actually did apply to 
my employees, in my now "previous" life). 
This is why I am not simply asking "Why and please explain", but I am trying
to show how I read and interpret the code; and when being corrected and/or
directed, I get much deeper understanding.
No wonder Socratic method is widely used and praised.  

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web