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

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

Pointers: misunderstanding

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

Contents

  Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-05 09:09 -0800
    Re: Pointers: misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 17:44 +0000
      Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 00:49 -0800
        Re: Pointers: misunderstanding Philip Lantz <prl@canterey.us> - 2015-11-06 03:01 -0800
          Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 03:09 -0800
    Re: Pointers: misunderstanding Barry Schwarz <schwarzb@dqel.com> - 2015-11-05 11:40 -0800
    Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 03:08 -0800
      Re: Pointers: misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 11:33 +0000
      Re: Pointers: misunderstanding Keith Thompson <kst-u@mib.org> - 2015-11-06 08:53 -0800
    Re: Pointers: misunderstanding Philip Lantz <prl@canterey.us> - 2015-11-06 03:16 -0800
      Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 03:30 -0800
        Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 03:32 -0800
          Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 04:58 -0800
            Re: Pointers: misunderstanding Keith Thompson <kst-u@mib.org> - 2015-11-06 09:00 -0800
              Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 09:25 -0800
              Re: Pointers: misunderstanding supercat@casperkitty.com - 2015-11-06 10:07 -0800
                Re: Pointers: misunderstanding Keith Thompson <kst-u@mib.org> - 2015-11-06 12:31 -0800
                Re: Pointers: misunderstanding Philip Lantz <prl@canterey.us> - 2015-11-06 20:08 -0800
          Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 04:59 -0800
        Re: Pointers: misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 13:06 +0000
          Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 08:50 -0800
            Re: Pointers: misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 17:00 +0000
              Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 09:17 -0800
                Re: Pointers: misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 17:22 +0000
                  Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 09:29 -0800
                Re: Pointers: misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 17:53 +0000
              Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 09:22 -0800
                Re: Pointers: misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 17:24 +0000
                  Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 09:33 -0800
                    Re: Pointers: misunderstanding Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 18:29 +0000
                      Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 23:42 -0800
              Re: Pointers: misunderstanding Philip Lantz <prl@canterey.us> - 2015-11-06 20:24 -0800
            Re: Pointers: misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 17:51 +0000
              Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 23:37 -0800
                Re: Pointers: misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-07 13:36 +0000
                  Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-07 08:17 -0800
                    Re: Pointers: misunderstanding Philip Lantz <prl@canterey.us> - 2015-11-07 12:04 -0800
      Re: Pointers: misunderstanding Keith Thompson <kst-u@mib.org> - 2015-11-06 08:55 -0800
        Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 09:23 -0800
    Re: Pointers: misunderstanding Philip Lantz <prl@canterey.us> - 2015-11-06 03:26 -0800
    Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 23:48 -0800
      Re: Pointers: misunderstanding Barry Schwarz <schwarzb@dqel.com> - 2015-11-07 00:35 -0800
    Re: Pointers: misunderstanding Alla _ <modelling.data@gmail.com> - 2015-11-06 23:48 -0800
      Re: Pointers: misunderstanding Keith Thompson <kst-u@mib.org> - 2015-11-07 12:24 -0800

Page 1 of 3  [1] 2 3  Next page →

#74985 — Pointers: misunderstanding

Hello!

I have to write a pointer version of a sort () function from 
this program:

// Program to sort an array of integers into ascending order

#include <stdio.h>

void sort (int a[], int n)
{
    int i, j, temp;
    
    for (i = 0; i < n-1; i++)
        for (j = i + 1; j < n; j++)
            if (a[i] > a[j])
            {
                temp = a[i];
                a[i] = a[j];
                a[j] = temp;
            }
}

int main (void)
{
    int i;
    int array[6] = {34, -5, 6, 0, 12, 100};
    
    printf("The array before the sort:\n");
    
    for (i = 0; i < 6; i++)
        printf("%i ", array[i]);
    
    sort(array, 6);
    
    printf("\nThe array after the sort: \n");
    
    for (i = 0; i < 6; i++)
        printf("%i ", array[i]);

    printf("\n");

    return 0;
}

I have failed to produce a correct version, although I thought
that I have understood everything I've read on pointers.

Please, take a look at my version and my explanations. What am
I misunderstanding? 
This is the incorrect result I get:

The array before the sort:
34 -5 6 0 12 100 
The array after the sort: 
-5 6 0 12 34 6 

// Program to sort an array of integers into ascending order

#include <stdio.h>

void sort (int* array_int, int n)

/** is equivalent to void sort (int array_int, int n) because
when the name of the variable, which contains an array, is used
as an argument of a function, then the compiler treats this name
as a pointer to the array **/
{
    int* temp;
    int* pointer = array_int;

/** variable 'pointer' points to the address of the first element
in array_int **/

    int* array_end = &array_int[n + 1];

/** array_end points to the element beyond the last element in the 
array_int; I have also tried to use 'int* array_end = *(array_int + n);'**/
    
    
/** iterate through entire array **/

    for (pointer; pointer < array_end; pointer++)
    {
        
/** if the value at a certain position in the array, to which variable
'pointer' points to, is bigger then the next value in the array, to which
(pointer + 1) points to, then swap those values **/

        if (*pointer > *(pointer + 1))
        {
            *temp = *pointer;
            *pointer = *(pointer + 1);
            *(pointer + 1) = *temp;
        }
    }
}
/** It should give the following result:

int array[6] = {34, -5, 6, 0, 12, 100};
if (*pointer > *(pointer + 1)) swap

array[0] = 34, array[1] = -5, swap
array[1] = 34, array[2] = 6, swap
array[2] = 34, array[3] = 0, swap
array[3] = 34, array[4] = 12, swap
array[4] = 34, array[5] = 100, done **/

int main (void)
{
    int i;
    int array[6] = {34, -5, 6, 0, 12, 100};
    
    printf("The array before the sort:\n");
    
    for (i = 0; i < 6; i++)
        printf("%i ", array[i]);
    
    sort(array, 6);
 /** I assume I don't need to write sort(&array, 6) here **/
  
    printf("\nThe array after the sort: \n");
    
    for (i = 0; i < 6; i++)
        printf("%i ", array[i]);
    
    printf("\n");
    
    return 0;
}

Thank you!

[toc] | [next] | [standalone]

#74992

Alla _ <modelling.data@gmail.com> writes:

> I have to write a pointer version of a sort () function from 
> this program:

I'm not sure what that means.  Was anything else said?  I think you are
being asker to get rid of the numerical indexes, i and j.  The reason
I'm a bit confused is that the version you were given uses pointers:

> // Program to sort an array of integers into ascending order
>
> #include <stdio.h>
>
> void sort (int a[], int n)

'a' is a pointer.

> {
>     int i, j, temp;
>     
>     for (i = 0; i < n-1; i++)
>         for (j = i + 1; j < n; j++)
>             if (a[i] > a[j])

and these are just pointer arithmetic and de-reference hidden behind []s.

>             {
>                 temp = a[i];
>                 a[i] = a[j];
>                 a[j] = temp;
>             }
> }
<snip>
> I have failed to produce a correct version, although I thought
> that I have understood everything I've read on pointers.
>
> Please, take a look at my version and my explanations. What am
> I misunderstanding? 
> This is the incorrect result I get:
>
> The array before the sort:
> 34 -5 6 0 12 100 
> The array after the sort: 
> -5 6 0 12 34 6 
>
> // Program to sort an array of integers into ascending order
>
> #include <stdio.h>
>
> void sort (int* array_int, int n)
>
> /** is equivalent to void sort (int array_int, int n) because

No!  It's just a typo, but if you are going to write comments you need
to take care with them.

> when the name of the variable, which contains an array, is used
> as an argument of a function, then the compiler treats this name
> as a pointer to the array **/

It does so in almost every single case.  It's more important to know the
exceptions rather than state the rule.  The two you will need to know
(eventually) are sizeof array and &array.

> {
>     int* temp;
>     int* pointer = array_int;
>
> /** variable 'pointer' points to the address of the first element
> in array_int **/
>
>     int* array_end = &array_int[n + 1];
>
> /** array_end points to the element beyond the last element in the 
> array_int;

No.  It's an invalid pointer pointing one further than that.  Imagine
and array with, say, 3 elements.  The first is &array_int[0], the second
is &array_int[1] and the last is &array_int[2].  A pointer just after
the end of the array is &array_int[3].  Note the 3 there -- that's your
n.  &array_int[4] is too far.

> I have also tried to use 'int* array_end = *(array_int + n);'**/

*(array_int + n) means array_int[n].  That's an int.  You can't assign
and it to a pointer.  Maybe you meant array_int + n?  Or even the rather
complex (but valid) &*(array_int + n)?
 
> /** iterate through entire array **/
>
>     for (pointer; pointer < array_end; pointer++)

It's not usual to put the first unnecessary expression there.  I'd write
any of:

  while (pointer < array_end) { ... // and then add ++pointer in the loop }
  for (; pointer < array_end; pointer++)
  for (pointer = array_int; pointer < array_end; pointer++)
  for (int *pointer = array_int; pointer < array_end; pointer++)
  
>     {
>         
> /** if the value at a certain position in the array, to which variable
> 'pointer' points to, is bigger then the next value in the array, to which
> (pointer + 1) points to, then swap those values **/
>
>         if (*pointer > *(pointer + 1))

I'd write pointer[1] rather than *(pointer + 1) but that just a style
thing.

Much more importantly, you have a sort function with one loop.  It makes
just one single pass over the array.  The original had a loop in a loop
so there's is no way your single pass can be doing the same work as the
original.

>         {
>             *temp = *pointer;
>             *pointer = *(pointer + 1);
>             *(pointer + 1) = *temp;
>         }
>     }
> }

<snip>
-- 
Ben.

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

#75054

<snip>
> Much more importantly, you have a sort function with one loop.  It makes
> just one single pass over the array.  The original had a loop in a loop
> so there's is no way your single pass can be doing the same work as the
> original.
> 
> >         {
> >             *temp = *pointer;
> >             *pointer = *(pointer + 1);
> >             *(pointer + 1) = *temp;
> >         }
> >     }
>
Thank you. 
I am not sure I understand why the swap wouldn't work for the entire
array, if I have only one loop. Why my assumption, described below,
is erroneous?

34 , -5,  6, 0, 12, 10

*pointer > *(pointer + 1)

34 > -5 swap, hence the next iteration of the loop
with start at the incremented pointer that points to
array_int[1] and its value is now 34. The value of 
array_int[0] is now -5.

second round of the loop:
34 > 6 where 6 is the value of array_int[2]; swap,
and the third iteration of loop compares the value of array_int[2], 
which is now 34, and the value of array_int[3].

the same process happens until all values are sorted.
 

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

#75065

Alla _ wrote:
> 
> <snip>
> > Much more importantly, you have a sort function with one loop.  It makes
> > just one single pass over the array.  The original had a loop in a loop
> > so there's is no way your single pass can be doing the same work as the
> > original.
> > 
> > >         {
> > >             *temp = *pointer;
> > >             *pointer = *(pointer + 1);
> > >             *(pointer + 1) = *temp;
> > >         }
> > >     }
> >
> Thank you. 
> I am not sure I understand why the swap wouldn't work for the entire
> array, if I have only one loop. Why my assumption, described below,
> is erroneous?
> 
> 34 , -5,  6, 0, 12, 10
> 
> *pointer > *(pointer + 1)
> 
> 34 > -5 swap, hence the next iteration of the loop
> with start at the incremented pointer that points to
> array_int[1] and its value is now 34. The value of 
> array_int[0] is now -5.
> 
> second round of the loop:
> 34 > 6 where 6 is the value of array_int[2]; swap,
> and the third iteration of loop compares the value of array_int[2], 
> which is now 34, and the value of array_int[3].
> 
> the same process happens until all values are sorted.
>  

This shows how 34 might get into the right place, but then how
would the 6 get moved to the right place? It gets left behind at
array_int[1].

I suggest you study the original sort, with two nested loops, and
understand how it works on this array. Then hopefully you will
see that it is impossible to sort using a single pass over the data.

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

#75068

On Friday, November 6, 2015 at 3:01:22 PM UTC+4, Philip Lantz wrote:
> Alla _ wrote:
> > 
> > <snip>
> > > Much more importantly, you have a sort function with one loop.  It makes
> > > just one single pass over the array.  The original had a loop in a loop
> > > so there's is no way your single pass can be doing the same work as the
> > > original.
> > > 
> > > >         {
> > > >             *temp = *pointer;
> > > >             *pointer = *(pointer + 1);
> > > >             *(pointer + 1) = *temp;
> > > >         }
> > > >     }
> > >
> > Thank you. 
> > I am not sure I understand why the swap wouldn't work for the entire
> > array, if I have only one loop. Why my assumption, described below,
> > is erroneous?
> > 
> > 34 , -5,  6, 0, 12, 10
> > 
> > *pointer > *(pointer + 1)
> > 
> > 34 > -5 swap, hence the next iteration of the loop
> > with start at the incremented pointer that points to
> > array_int[1] and its value is now 34. The value of 
> > array_int[0] is now -5.
> > 
> > second round of the loop:
> > 34 > 6 where 6 is the value of array_int[2]; swap,
> > and the third iteration of loop compares the value of array_int[2], 
> > which is now 34, and the value of array_int[3].
> > 
> > the same process happens until all values are sorted.
> >  
> 
> This shows how 34 might get into the right place, but then how
> would the 6 get moved to the right place? It gets left behind at
> array_int[1].
> 
> I suggest you study the original sort, with two nested loops, and
> understand how it works on this array. Then hopefully you will
> see that it is impossible to sort using a single pass over the data.

Thank you!
Strangely enough, I do understand the original one very well. Maybe
it's this pointer theme that has distracted my that much. 

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

#75006

On Thu, 5 Nov 2015 09:09:16 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>void sort (int* array_int, int n)
>
>/** is equivalent to void sort (int array_int, int n) because
>when the name of the variable, which contains an array, is used
>as an argument of a function, then the compiler treats this name
>as a pointer to the array **/

There are some terminology issues you should get straight before they
become ingrained bad habits;

In the line of code that the comment refers to, there are no
arguments.  The two expressions inside the parentheses are parameters.
The corresponding expressions in the statement that calls this
function are the arguments.  The function call pass arguments to the
function which receives them (by value) as parameters.  (The point you
are trying to make applies to both arguments and parameters.  In
either case, an expression of type array is converted to type
pointer.)

There is a difference between pointer to an array and pointer to a
scalar type.  In the situation being described, the array expression
is converted to a pointer expression with a type and value that points
to the first element of the array.  If array_int is an array of N int,
then a pointer to the array has type pointer to array of N int and
that is expressed syntactically as int (*)[N].  The actual conversion
that is performed is pointer to first element of the array which has
type pointer to int which is expressed syntactically as int*.  I find
it makes things clearer to me to visualize that, in this context, the
expression "array_int" is converted to the expression "&array_int[0]".

Finally, it is not the presence of the array name that causes the
conversion.  It is the presence of an expression that has array type.
There are cases where the expression has array type even without the
name of the array and cases where the expression does not have array
type even with the array name present.  For example:
    int x[6];           //an array of int
    int *pi, pj;       //a scalar pointer to int
    int (*px)[6];    //a scalar pointer to an array of int
    pi = x;             //array expression converted to pointer
    pj = &x[0];     //exactly the same as pi
    px = &x;         //array operand not converted
    func1(x)          //expression converted to pointer and passed
    func1(*px)      //ditto even without name of array
    func1(pi);        //expression already pointer, no conversion
//func1 receives exact same value for all cases
    func2(x[0]);    //no conversion, int passed
    func2(*x);      //ditto
    func2(*pi);     //ditto
    func2(pi[0]);  //ditto
//func2 receives exact same value for all cases

-- 
Remove del for email

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

#75067

I wonder why the following is incorrect: 

int* array_end = &array_int[n - 1];

Based on the knowledge I received from numerous pages I have 
read and studied these days, I understand it as :

- array_end is a variable of a pointing to an integer type;

- by "&array_int[n - 1];" I assign the variable array_end to point
at the address of the element at of an array that is at [n - 1];

- before an error message from a compiler, I was sure that the following
are all equivalents; for example for an array of 6 elements, all should
point at the address of a 6th element in the array, i.e. array[5]; point 
at the address and not at the value that is stored there:

 int* array_end = &array_int[n - 1];  

 int* array_end = array_int + (n - 1);

 int* array_end = &array_int[0] + (n - 1);

But the first one in the above list (int* array_end = &array_int[n - 1];  )
caused the compiler to produce an error message: 

error: subscripted value is neither array nor pointer.


Also, another issue:

int* pointer = array_int;

According to all materials I have studied, the above 'phrase' 
means that a variable pointer of a pointing to an int type points
at the first element of the array_int[], i.e. at &array_int[0].

But the compiler tells me that by such declaration I :

warning: initialization makes pointer from integer without a cast

I don't understand it. 

It was wonderful reading and re-typing programs from books
and other sources - the pointer theme looked clear and easy-peasy; 
well, only until I did try to use it within a very simple
program ))) 

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

#75078

On 06/11/15 11:08, Alla _ wrote:
> I wonder why the following is incorrect:
>
> int* array_end = &array_int[n - 1];

So do I. Presumably array_int is an array of int, or at least a pointer 
to int, and n - 1 is a valid index for array_int.

> Based on the knowledge I received from numerous pages I have
> read and studied these days, I understand it as :
>
> - array_end is a variable of a pointing to an integer type;

Yes. Specifically, it's a pointer to int.

> - by "&array_int[n - 1];" I assign the variable array_end to point
> at the address of the element at of an array that is at [n - 1];

Yes.

> - before an error message from a compiler, I was sure that the following
> are all equivalents; for example for an array of 6 elements, all should
> point at the address of a 6th element in the array, i.e. array[5]; point
> at the address and not at the value that is stored there:

"Points at" can be read as "stores the address of".

Your code attempts to point array_end at the last int in the array. That 
is, it attempts to store the address of that last int.

>   int* array_end = &array_int[n - 1];

That looks fine to me, but maybe I'm just not seeing the problem (it 
happens).

>
>   int* array_end = array_int + (n - 1);

So does that.

>
>   int* array_end = &array_int[0] + (n - 1);

So does that.

>
> But the first one in the above list (int* array_end = &array_int[n - 1];  )
> caused the compiler to produce an error message:
>
> error: subscripted value is neither array nor pointer.

Can you show us a complete C program that causes this problem? Please 
include the whole of the program source, so that we can compile it 
ourselves. That's a much quicker way to find the problem than our 
guessing how your declarations go.

> Also, another issue:
>
> int* pointer = array_int;
>
> According to all materials I have studied, the above 'phrase'
> means that a variable pointer of a pointing to an int type points
> at the first element of the array_int[], i.e. at &array_int[0].
>
> But the compiler tells me that by such declaration I :
>
> warning: initialization makes pointer from integer without a cast
>
> I don't understand it.

Nor do I, but I will as soon as you post the complete program.

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

#75124

Alla _ <modelling.data@gmail.com> writes:
> I wonder why the following is incorrect: 
>
> int* array_end = &array_int[n - 1];
[...]
> But the first one in the above list (int* array_end = &array_int[n - 1];  )
> caused the compiler to produce an error message: 
>
> error: subscripted value is neither array nor pointer.

You're getting that error message because array_int is neither an array
nor a pointer.

I can only infer that from the error message because you haven't shown
us the declaration of array_int (*hint*).

I would have assumed, given the name, that it's defined as an array of
int, but apparently it isn't.  Whatever it is, it's probably misnamed --
but the compiler doesn't care about that.

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

#75069

Alla _ wrote:

> I have to write a pointer version of a sort () function from 
> this program:

I would interpret this description to mean that the sort routine should
sort an array of pointers to the data, rather than an array of the data
itself. If that really is what was meant, the declaration of the sort
routine would be:

void sort(const int *a[], int n);

Each member of the array would point at an int value. The pointers would
be rearranged so that the int values they point to are ordered, but the
int values themselves would never be changed.
 
This is a useful technique if the data to be sorted is large, because it
is way faster to swap pointers to a chunk of data that to copy the data
itself.

The solution is almost exactly the same as sorting the array of ints,
except that instead of comparing a[i] with a[j], you compare *a[i] with
*a[j]. If they are out of order, you swap a[i] with a[j], just like in
the original.

In the main function you might initialize the pointer array like this:
    const int array[6] = {34, -5, 6, 0, 12, 100};
    const int *ptr_array[6];
    for (i = 0; i < 6; i++)
        ptr_array[i] = &array[i];

Note, I added the consts to make it clear that the original array of ints
doesn't change. They could be omitted, of course.

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

#75075

On Friday, November 6, 2015 at 3:17:06 PM UTC+4, Philip Lantz wrote:
> Alla _ wrote:
> 
> > I have to write a pointer version of a sort () function from 
> > this program:
> 
> I would interpret this description to mean that the sort routine should
> sort an array of pointers to the data, rather than an array of the data
> itself.

I guess that it reflects what the author of the task meant. 


> This is a useful technique if the data to be sorted is large, because it
> is way faster to swap pointers to a chunk of data that to copy the data
> itself.
> 
yes, that is what I have learned these days :) 

Also, according to what Ben has suggested (I am not sure I have understood
it clearily), and what Barry has explained, I have tried to rewrite
the sort function. The program now works.

But what I still not clear to me is why

void sort (int* array_int, int n) is different 

from void sort (int array_int, int n), if in both cases

array_int is a pointer to the address of the first element
in the given array. Sorry for being slow in understanding 
these basics. 

// Program to sort an array of integers into ascending order

#include <stdio.h>

void sort (int* array_int, int n)
{
    int* temp;
    int* pointer_1 = array_int;
    int* array_end = &array_int[n - 1];
    int* pointer_2;
    
    while (pointer_1 < array_end - 1)
    {
        for (pointer_2 = pointer_1 + 1; pointer_2 < array_end; pointer_2++)
        {
            if (*pointer_1 > *pointer_2)
            {
                *temp = *pointer_1;
                *pointer_1 = *pointer_2;
                *pointer_2 = *temp;
            }
            pointer_1++;
        }
    }
        
}

int main (void)
{
    int i;
    int array[6] = {34, -5, 6, 0, 12, 100};
    
    printf("The array before the sort:\n");
    
    for (i = 0; i < 6; i++)
        printf("%i ", array[i]);
    
    sort(array, 6);
    
    printf("\nThe array after the sort: \n");
    
    for (i = 0; i < 6; i++)
        printf("%i ", array[i]);
    
    printf("\n");
    
    return 0;
}

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

#75076

On Friday, November 6, 2015 at 3:30:50 PM UTC+4, Alla _ wrote:
> On Friday, November 6, 2015 at 3:17:06 PM UTC+4, Philip Lantz wrote:
> > Alla _ wrote:
> > 
> > > I have to write a pointer version of a sort () function from 
> > > this program:
> > 
> > I would interpret this description to mean that the sort routine should
> > sort an array of pointers to the data, rather than an array of the data
> > itself.
> 
> I guess that it reflects what the author of the task meant. 
> 
> 
> > This is a useful technique if the data to be sorted is large, because it
> > is way faster to swap pointers to a chunk of data that to copy the data
> > itself.
> > 
> yes, that is what I have learned these days :) 
> 
> Also, according to what Ben has suggested (I am not sure I have understood
> it clearily), and what Barry has explained, I have tried to rewrite
> the sort function. The program now works < EDIT >partially - I have forgotten 
to write 'partially'.
> 
> But what I still not clear to me is why
> 
> void sort (int* array_int, int n) is different 
> 
> from void sort (int array_int, int n), if in both cases
> 
> array_int is a pointer to the address of the first element
> in the given array. Sorry for being slow in understanding 
> these basics. 
> 
> // Program to sort an array of integers into ascending order
> 
> #include <stdio.h>
> 
> void sort (int* array_int, int n)
> {
>     int* temp;
>     int* pointer_1 = array_int;
>     int* array_end = &array_int[n - 1];
>     int* pointer_2;
>     
>     while (pointer_1 < array_end - 1)
>     {
>         for (pointer_2 = pointer_1 + 1; pointer_2 < array_end; pointer_2++)
>         {
>             if (*pointer_1 > *pointer_2)
>             {
>                 *temp = *pointer_1;
>                 *pointer_1 = *pointer_2;
>                 *pointer_2 = *temp;
>             }
>             pointer_1++;
>         }
>     }
>         
> }
> 
> int main (void)
> {
>     int i;
>     int array[6] = {34, -5, 6, 0, 12, 100};
>     
>     printf("The array before the sort:\n");
>     
>     for (i = 0; i < 6; i++)
>         printf("%i ", array[i]);
>     
>     sort(array, 6);
>     
>     printf("\nThe array after the sort: \n");
>     
>     for (i = 0; i < 6; i++)
>         printf("%i ", array[i]);
>     
>     printf("\n");
>     
>     return 0;
> }

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

#75086

Richard,
Thank you for your answer. Below is the program.
 
I have figured out what has caused the compiler to produce
those error messages - it is my declaration of the function
itself. Below I post my question on this issue. The program that 
had not been compiled contained "void sort (int array_int, int n)"
declaration (without an asterisk after int).

> > here is what is still not clear to me: why
> > 
> > void sort (int* array_int, int n) is different 
> > 
> > from void sort (int array_int, int n), if in both cases
> > 
> > array_int is a pointer to the address of the first element
> > in the given array. Sorry for being slow in understanding 
> > these basics. 
> > 
> > // Program to sort an array of integers into ascending order
> > 
> > #include <stdio.h>
> > 
> > void sort (int* array_int, int n)
> > {
> >     int* temp;
> >     int* pointer_1 = array_int;
> >     int* array_end = &array_int[n - 1];
> >     int* pointer_2;
> >     
> >     while (pointer_1 < array_end - 1)
> >     {
> >         for (pointer_2 = pointer_1 + 1; pointer_2 < array_end; pointer_2++)
> >         {
> >             if (*pointer_1 > *pointer_2)
> >             {
> >                 *temp = *pointer_1;
> >                 *pointer_1 = *pointer_2;
> >                 *pointer_2 = *temp;
> >             }
> >             pointer_1++;
> >         }
> >     }
> >         
> > }
> > 
> > int main (void)
> > {
> >     int i;
> >     int array[6] = {34, -5, 6, 0, 12, 100};
> >     
> >     printf("The array before the sort:\n");
> >     
> >     for (i = 0; i < 6; i++)
> >         printf("%i ", array[i]);
> >     
> >     sort(array, 6);
> >     
> >     printf("\nThe array after the sort: \n");
> >     
> >     for (i = 0; i < 6; i++)
> >         printf("%i ", array[i]);
> >     
> >     printf("\n");
> >     
> >     return 0;
> > }

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

#75128

Alla _ <modelling.data@gmail.com> writes:
> Richard,
> Thank you for your answer. Below is the program.
>  
> I have figured out what has caused the compiler to produce
> those error messages - it is my declaration of the function
> itself. Below I post my question on this issue. The program that 
> had not been compiled contained "void sort (int array_int, int n)"
> declaration (without an asterisk after int).
>
>> > here is what is still not clear to me: why
>> > 
>> > void sort (int* array_int, int n) is different 
>> > 
>> > from void sort (int array_int, int n), if in both cases

I posted a followup a few minutes ago saying that you hadn't shown us
the declaration of array_int.  I see that you had posted it, just not in
the same article.  As you apparently now know, you defined array_int as
an int rather than as an int*, and that's the cause of the error
message.

The article I replied to didn't provide enough context to answer your
question about the error message.  Knowing just how much quoted material
to retain when posting a followup can be tricky.

One more point:

>> > array_int is a pointer to the address of the first element
>> > in the given array. Sorry for being slow in understanding 
>> > these basics. 

array_int (assuming it's defined as int*) is not "a pointer to the
address" of the first element.  It's a pointer to the first element.

A pointer doesn't point to an address.  A pointer *is* an address.
More precisely, the terms "address" and "pointer value" are very
nearly synonymous.  A (non-null) pointer points to an object; that
object has an address, and a pointer object may contain that address.

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

#75134

<snip>
> >> > array_int is a pointer to the address of the first element
> >> > in the given array. Sorry for being slow in understanding 
> >> > these basics. 
> 
> array_int (assuming it's defined as int*) is not "a pointer to the
> address" of the first element.  It's a pointer to the first element.
> 
> A pointer doesn't point to an address.  A pointer *is* an address.
> More precisely, the terms "address" and "pointer value" are very
> nearly synonymous.  A (non-null) pointer points to an object; that
> object has an address, and a pointer object may contain that address.
> 
Thank you. 

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

#75142

On Friday, November 6, 2015 at 11:01:00 AM UTC-6, Keith Thompson wrote:
> A pointer doesn't point to an address.  A pointer *is* an address.
> More precisely, the terms "address" and "pointer value" are very
> nearly synonymous.  A (non-null) pointer points to an object; that
> object has an address, and a pointer object may contain that address.

The contents of a pointer *identify* an object or a portion thereof.
Typically a pointer will contain nothing more nor less than the hardware
address of that object or portion thereof, but there is no requirement
that the bit patterns held within a pointer bear any relation to anything
having to do with the underlying hardware.  It would be permissible, for
example, for an implementation to assign an index to every object [for
efficiency, it might have a separate range of indices for things of static,
automatic, or heap duration], and have each pointer hold an index of the
containing object along with an offset measured from the start of that
object.  Such an implementation might run code much more slowly than one
which uses hardware addresses directly, but might be able to trap most
forms of improper pointer usage such that they terminate the program rather
than allowing it to cause potentially-unbounded destruction.

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

#75178

supercat@casperkitty.com writes:
> On Friday, November 6, 2015 at 11:01:00 AM UTC-6, Keith Thompson wrote:
>> A pointer doesn't point to an address.  A pointer *is* an address.
>> More precisely, the terms "address" and "pointer value" are very
>> nearly synonymous.  A (non-null) pointer points to an object; that
>> object has an address, and a pointer object may contain that address.
>
> The contents of a pointer *identify* an object or a portion thereof.
> Typically a pointer will contain nothing more nor less than the hardware
> address of that object or portion thereof, but there is no requirement
> that the bit patterns held within a pointer bear any relation to anything
> having to do with the underlying hardware.
[...]

I'm using the word "address" in the way it's used by the Standard.  For
example, the unary & operator "yields the address of its operand".

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

#75211

supercat@casperkitty.com wrote:
> 
> On Friday, November 6, 2015 at 11:01:00 AM UTC-6, Keith Thompson wrote:
> > A pointer doesn't point to an address.  A pointer *is* an address.
> > More precisely, the terms "address" and "pointer value" are very
> > nearly synonymous.  A (non-null) pointer points to an object; that
> > object has an address, and a pointer object may contain that address.
> 
> The contents of a pointer *identify* an object or a portion thereof.
> Typically a pointer will contain nothing more nor less than the hardware
> address of that object or portion thereof, but there is no requirement
> that the bit patterns held within a pointer bear any relation to anything
> having to do with the underlying hardware.  It would be permissible, for
> example, for an implementation to assign an index to every object [for
> efficiency, it might have a separate range of indices for things of static,
> automatic, or heap duration], and have each pointer hold an index of the
> containing object along with an offset measured from the start of that
> object.  Such an implementation might run code much more slowly than one
> which uses hardware addresses directly, but might be able to trap most
> forms of improper pointer usage such that they terminate the program rather
> than allowing it to cause potentially-unbounded destruction.

This is all true, but I don't think Alla _ is at the point to appreciate
the nuances yet.

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

#75087

<snip>
The output of the program is only partially correct:

The array before the sort:
34 -5 6 0 12 100 
The array after the sort: 
-5 6 0 12 34 100 

For some reason the program didn't manage to swap
0 and 6.

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

#75089

Alla _ <modelling.data@gmail.com> writes:

> On Friday, November 6, 2015 at 3:17:06 PM UTC+4, Philip Lantz wrote:
>> Alla _ wrote:
>> 
>> > I have to write a pointer version of a sort () function from 
>> > this program:
>> 
>> I would interpret this description to mean that the sort routine should
>> sort an array of pointers to the data, rather than an array of the data
>> itself.
>
> I guess that it reflects what the author of the task meant.

Sure but I, for one, want to know what was meant by the author!  Philip
has introduced another possibility (which I also considered) but it's
not what you've been doing.

>> This is a useful technique if the data to be sorted is large, because it
>> is way faster to swap pointers to a chunk of data that to copy the data
>> itself.
>> 
> yes, that is what I have learned these days :)

I've not seen anything in the recent discussion that could have lead to
to that conclusion.  It's correct (so well done if you have worked out
the value of what is sometimes called indirect sorting) but it has
nothing to do with what you have been doing, which it re-writing indexed
loops with pointer loops.

> Also, according to what Ben has suggested (I am not sure I have understood
> it clearily), and what Barry has explained, I have tried to rewrite
> the sort function. The program now works.
>
> But what I still not clear to me is why
>
> void sort (int* array_int, int n) is different 
>
> from void sort (int array_int, int n), if in both cases

You mean void sort (int array_int[], int n)

> array_int is a pointer to the address of the first element
> in the given array. Sorry for being slow in understanding 
> these basics.

There is no difference.  None at all.  For various historical reasons
and accidents of design, they mean exactly the same thing.

But did you read the declaration that Philip Lantz wrote carefully?  He
was suggesting something else entirely:

  void sort(int *array_int[], int n);

> // Program to sort an array of integers into ascending order
>
> #include <stdio.h>
>
> void sort (int* array_int, int n)
> {
>     int* temp;
>     int* pointer_1 = array_int;
>     int* array_end = &array_int[n - 1];

When n is zero, this is not a permitted operation.  Worse, you then
subtract 1 from array_end in the while loop.  C has a funny rule that
you can make pointers to the elements of an array, and also a pointer
just past the end (there's no element there, but you can make the
pointer) but no other pointers can even be constructed.

>     int* pointer_2;
>     
>     while (pointer_1 < array_end - 1)

You two loops are very similar.  Whatever you do, you should write them
both in the same style.  Both with for or both with while.  And if you
use for, both for loops should have the same shape.

>     {
>         for (pointer_2 = pointer_1 + 1; pointer_2 < array_end; pointer_2++)
>         {
>             if (*pointer_1 > *pointer_2)
>             {
>                 *temp = *pointer_1;

EEK!  temp is a pointer you have not set to point anywhere.  *temp is
therefore what we call "undefined behaviour".  But what type is
*pointer_1?  What sort of variable should you use to hold something of
that type?

>                 *pointer_1 = *pointer_2;
>                 *pointer_2 = *temp;
>             }
>             pointer_1++;
>         }
>     }
>         
> }

<snip>
-- 
Ben.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web