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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#75123

> 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.
> 
My bad ))) Here is the text of the task:
Write a pointer version of the sort() function from Chapter 7, "Working with Functions." Be certain that pointers are exclusively used by the function, including index variables in the loops.

(he is talking about the original program I posted above).

> >> 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 :)
> 

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

I see my fundamental mistake. I have not used [].

I wonder why, if, for example:

int values [100];
int* values_pointer;
values_pointer = values;

name 'values' means that values_pointer points at the first element of 
the array values, hence the pure name of the array indicates the address 
of the first element within that array. 

Why then if I use the same 'technique' for a function parameter 
(Barry, I've learned the difference :) ), is it a mistake? Why 
"void sort (int array_int, int n)" is not the same as "void sort (int array_int[], int n)"?

> 
> But did you read the declaration that Philip Lantz wrote carefully?  He
> was suggesting something else entirely:
> 
>   void sort(int *array_int[], int n);
> 
Yes, I did, but I have not yet fully understood it. Working on it. 
I don't yet understand the difference between what I am doing with this 
function and what Philip has suggested: I thought that in both cases 
ints in the initial array are sorted (rearranged) by pointers - pointers
point at those values, and if the program 'moves' pointers, it in fact
sorts original values (because I use *pointer... notation).

> > // 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.
> 
I don't test for zero, though I should have. True. May I skip this for now?
> >     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.
> 
>
I have corrected it. The output is:
The array before the sort:
34 -5 6 0 12 100 
The array after the sort: 
-5 6 0 12 34 100 

Something's wrong with 0 and 6. 

// 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 = pointer_1 + 1;
    
    while (pointer_1 < array_end - 1)
    {
        while(pointer_2 < array_end)
        {
            if (*pointer_1 > *pointer_2)
            {
                *temp = *pointer_1;
                *pointer_1 = *pointer_2;
                *pointer_2 = *temp;
            }
            pointer_1++;
            pointer_2++;
        }
    }
        
}

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;
}

>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++; 

*pointer_1 has a type of a pointer to an integer, as pointer_2 and temp.
Do you mean that to declare *temp I need to allocate a memory for it with 
malloc? 

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

#75127

On 06/11/15 16:50, Alla _ wrote:
>
<snip>

> Why
> "void sort (int array_int, int n)" is not the same as "void sort (int array_int[], int n)"?

Look at them next to each other:

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

Do you see the difference?

One is an int. The other is a pointer to int.

int array_int defines an int, not an array of int.

The type of the object is determined by the type information you 
provide, not by an optimistic hint in the name.

int my_float; is an int, not a float.
int my_char; is an int, not a char.
int my_array; is an int, not an array.


>> But did you read the declaration that Philip Lantz wrote carefully?  He
>> was suggesting something else entirely:
>>
>>    void sort(int *array_int[], int n);
>>
> Yes, I did, but I have not yet fully understood it.

You're not ready for that yet. Plenty of people in here are trying to 
teach you how to run. That's a bad idea. First you need to learn how to 
walk. (You'd think these people had been born knowing C, and hadn't had 
to undergo a learning process themselves.)

<snip>

> I have corrected it. The output is:
> The array before the sort:
> 34 -5 6 0 12 100
> The array after the sort:
> -5 6 0 12 34 100
>
> Something's wrong with 0 and 6.
>
> // Program to sort an array of integers into ascending order

Before you even think about doing this program, you need to understand 
the non-array version.

<snip>

> *pointer_1 has a type of a pointer to an integer, as pointer_2 and temp.
> Do you mean that to declare *temp I need to allocate a memory for it with
> malloc?

Don't even *think* about that yet.

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

#75129

> > *pointer_1 has a type of a pointer to an integer, as pointer_2 and temp.
> > Do you mean that to declare *temp I need to allocate a memory for it with
> > malloc?
> 
> Don't even *think* about that yet.

Too late :) It's been already part of the lecture (CS50 one) I've listened,
and part of some very simple exercises they offered. Doing problem set I 
have to use malloc. If I understood it correctly, but happily forgotten, until
Ben has reminded (though, I am not sure Ben was talking about this) me, 
whenever I declare a variable of a pointer type that doesn't point anywhere
yet, I have to allocate a memory for it with malloc. As with temp,
int* temp = malloc(sizeof(int))?

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

#75131

On 06/11/15 17:17, Alla _ wrote:
>
>>> *pointer_1 has a type of a pointer to an integer, as pointer_2 and temp.
>>> Do you mean that to declare *temp I need to allocate a memory for it with
>>> malloc?
>>
>> Don't even *think* about that yet.
>
> Too late :) It's been already part of the lecture (CS50 one) I've listened,

Then you're going too fast. I keep telling you about this. I understand 
the temptation to race ahead, but giving in to that temptation is not 
helping you.

> and part of some very simple exercises they offered. Doing problem set I
> have to use malloc. If I understood it correctly, but happily forgotten, until
> Ben has reminded (though, I am not sure Ben was talking about this) me,
> whenever I declare a variable of a pointer type that doesn't point anywhere
> yet, I have to allocate a memory for it with malloc. As with temp,
> int* temp = malloc(sizeof(int))?

No, that's not right. (It's not even wrong!) Whenever you define (not 
declare, but *define*) an object of pointer type, you should ensure that 
it is in one of two states:

1) it points somewhere valid;
2) it has the value NULL.

Assigning to it the return value of a malloc call is certainly one way 
of doing this, but it isn't the only way.

The malloc function is very powerful, but it is also a very good way to 
confuse you horribly at this stage in your education. You need to learn 
*first* how to use pointers safely and wisely. *Then* you can start in 
on malloc.

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

#75136

On Friday, November 6, 2015 at 9:22:37 PM UTC+4, Richard Heathfield wrote:
> On 06/11/15 17:17, Alla _ wrote:
> >
> >>> *pointer_1 has a type of a pointer to an integer, as pointer_2 and temp.
> >>> Do you mean that to declare *temp I need to allocate a memory for it with
> >>> malloc?
> >>
> >> Don't even *think* about that yet.
> >
> > Too late :) It's been already part of the lecture (CS50 one) I've listened,
> 
> Then you're going too fast. I keep telling you about this. I understand 
> the temptation to race ahead, but giving in to that temptation is not 
> helping you.
> 
> > and part of some very simple exercises they offered. Doing problem set I
> > have to use malloc. If I understood it correctly, but happily forgotten, until
> > Ben has reminded (though, I am not sure Ben was talking about this) me,
> > whenever I declare a variable of a pointer type that doesn't point anywhere
> > yet, I have to allocate a memory for it with malloc. As with temp,
> > int* temp = malloc(sizeof(int))?
> 
> No, that's not right. (It's not even wrong!) Whenever you define (not 
> declare, but *define*) an object of pointer type, you should ensure that 
> it is in one of two states:
> 
> 1) it points somewhere valid;
> 2) it has the value NULL.
> 
> Assigning to it the return value of a malloc call is certainly one way 
> of doing this, but it isn't the only way.
> 
> The malloc function is very powerful, but it is also a very good way to 
> confuse you horribly at this stage in your education. You need to learn 
> *first* how to use pointers safely and wisely. *Then* you can start in 
> on malloc.
>
Your advises are heeded, as usual; I hope you know that. 
I agree that I have to understand pointers; it is one of the most
important issues, and this is why I am doing some exercises
on them, after I have read many pages on this topic. 

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

#75139

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

>> > *pointer_1 has a type of a pointer to an integer, as pointer_2 and temp.
>> > Do you mean that to declare *temp I need to allocate a memory for it with
>> > malloc?
>> 
>> Don't even *think* about that yet.
>
> Too late :) It's been already part of the lecture (CS50 one) I've listened,
> and part of some very simple exercises they offered. Doing problem set I 
> have to use malloc. If I understood it correctly, but happily forgotten, until
> Ben has reminded (though, I am not sure Ben was talking about this) me, 
> whenever I declare a variable of a pointer type that doesn't point anywhere
> yet, I have to allocate a memory for it with malloc. As with temp,
> int* temp = malloc(sizeof(int))?

I've answered elsewhere, but no.  You don't need to do that at all.
malloc should not be involved in this exercise.

-- 
Ben.

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

#75130

> 
> Look at them next to each other:
> 
> void sort (int array_int, int n)
> void sort (int array_int[], int n)
> 
> Do you see the difference?
> 
> One is an int. The other is a pointer to int.
> 
> int array_int defines an int, not an array of int.
> 
> The type of the object is determined by the type information you 
> provide, not by an optimistic hint in the name.
> 
> int my_float; is an int, not a float.
> int my_char; is an int, not a char.
> int my_array; is an int, not an array.
> 
> 
Yes, indeed. Embarrassing - such obvious things, and I have completely
mixed them.
 
> >> But did you read the declaration that Philip Lantz wrote carefully?  He
> >> was suggesting something else entirely:
> >>
> >>    void sort(int *array_int[], int n);
> >>
> > Yes, I did, but I have not yet fully understood it.
> 
> You're not ready for that yet. Plenty of people in here are trying to 
> teach you how to run. That's a bad idea. First you need to learn how to 
> walk. (You'd think these people had been born knowing C, and hadn't had 
> to undergo a learning process themselves.)
> 
Well, sad but true - I am definitely not running, not even toddling, I am
doing, yet unsuccessful, attempts to crawl, and for a few months already. 

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

#75133

On 06/11/15 17:22, Alla _ wrote:
>
<snip>
>
>>>> But did you read the declaration that Philip Lantz wrote carefully?  He
>>>> was suggesting something else entirely:
>>>>
>>>>     void sort(int *array_int[], int n);
>>>>
>>> Yes, I did, but I have not yet fully understood it.
>>
>> You're not ready for that yet. Plenty of people in here are trying to
>> teach you how to run. That's a bad idea. First you need to learn how to
>> walk. (You'd think these people had been born knowing C, and hadn't had
>> to undergo a learning process themselves.)
>>
> Well, sad but true - I am definitely not running, not even toddling, I am
> doing, yet unsuccessful, attempts to crawl, and for a few months already.

You'll learn faster if you slow down a bit. Well, actually you need to 
slow down a *lot*. Take the time to learn the basics thoroughly before 
you rush on to the cool stuff. Otherwise, the cool stuff will just 
confuse you instead of enabling you.

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

#75137

On Friday, November 6, 2015 at 9:24:34 PM UTC+4, Richard Heathfield wrote:
> On 06/11/15 17:22, Alla _ wrote:
> >
> <snip>
> >
> >>>> But did you read the declaration that Philip Lantz wrote carefully?  He
> >>>> was suggesting something else entirely:
> >>>>
> >>>>     void sort(int *array_int[], int n);
> >>>>
> >>> Yes, I did, but I have not yet fully understood it.
> >>
> >> You're not ready for that yet. Plenty of people in here are trying to
> >> teach you how to run. That's a bad idea. First you need to learn how to
> >> walk. (You'd think these people had been born knowing C, and hadn't had
> >> to undergo a learning process themselves.)
> >>
> > Well, sad but true - I am definitely not running, not even toddling, I am
> > doing, yet unsuccessful, attempts to crawl, and for a few months already.
> 
> You'll learn faster if you slow down a bit. Well, actually you need to 
> slow down a *lot*. Take the time to learn the basics thoroughly before 
> you rush on to the cool stuff. Otherwise, the cool stuff will just 
> confuse you instead of enabling you.
> 
Yes, I see. I am doing so by re-reading material, and doing some exercises.
But I am also limited in time for finishing the CS50 online course. 
I have decided to go on with that course, do what is required,
and meanwhile continue learning and revising the basics. Although 
not the best tactics, at least I am sure it will eventually pay off. 
I do hope you will also see the progress. 

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

#75148

On 06/11/15 17:33, Alla _ wrote:

<snip>

> But I am also limited in time for finishing the CS50 online course.

Ah, then I misunderstood. For some reason I was under the impression 
that you were not working to deadlines.

Welcome, then, to the wonderful world of Functionality, Quality, 
Deadline (Pick Any Two).

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

#75218

On Friday, November 6, 2015 at 10:29:53 PM UTC+4, Richard Heathfield wrote:
> On 06/11/15 17:33, Alla _ wrote:
> 
> <snip>
> 
> > But I am also limited in time for finishing the CS50 online course.
> 
> Ah, then I misunderstood. For some reason I was under the impression 
> that you were not working to deadlines.
> 
I wasn't until recently. I have realized that it's worth to finish what's
offered - they offer these materials for anyone in the world, and I decided
that it would be erroneous not to take it. Though, I assume only bright 
people can make it; therefore, I am not yet sure I will be capable of 
finishing it. Given its a self-paced online free course, I am doing my
best to understand the basics until moving any further; but they indeed
have limited the time during which this course is available. 

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

#75212

Richard Heathfield wrote:
> Alla _ wrote:
[> > Ben wrote: ]
> >> But did you read the declaration that Philip Lantz wrote carefully?  He
> >> was suggesting something else entirely:
> >>
> >>    void sort(int *array_int[], int n);
> >>
> > Yes, I did, but I have not yet fully understood it.
> 
> You're not ready for that yet. Plenty of people in here are trying to 
> teach you how to run. That's a bad idea. First you need to learn how to 
> walk.

I agree, and I apologize for that.

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

#75138

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

I'll just comment on a couple of things so far not commented on...
<snip>
> I don't test for zero, though I should have. True. May I skip this for
> now?

Yes -- you certainly don't want to test for zero.  Just remember only to
make pointers in the range &array[0] to &array[size_of_the_array] and
that the last one does not point to an element of the array -- it points
"just after".

<snip>
>>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++; 
>
> *pointer_1 has a type of a pointer to an integer, as pointer_2 and
> temp.

No.  *pointer_1 has type int.

> Do you mean that to declare *temp I need to allocate a memory for it with 
> malloc?

No, you don't need a pointer here at all.  You can, I'm sure, come up
with a way to swap *pointer_1 and *pointer_2 without using another
pointer.

-- 
Ben.

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

#75217

On Friday, November 6, 2015 at 9:51:22 PM UTC+4, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> I'll just comment on a couple of things so far not commented on...
> <snip>
> > I don't test for zero, though I should have. True. May I skip this for
> > now?
> 
> Yes -- you certainly don't want to test for zero.  Just remember only to
> make pointers in the range &array[0] to &array[size_of_the_array] and
> that the last one does not point to an element of the array -- it points
> "just after".
> 
> <snip>
> >>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++; 
> >
> > *pointer_1 has a type of a pointer to an integer, as pointer_2 and
> > temp.
> 
> No.  *pointer_1 has type int.
> 
> > Do you mean that to declare *temp I need to allocate a memory for it with 
> > malloc?
> 
> No, you don't need a pointer here at all.  

I see: it's because *pointer_1 is an int, i.e. the actual value of the 
element in the array; hence, temp can be of an int type, no need for a 
pointer here. 

>You can, I'm sure, come up
> with a way to swap *pointer_1 and *pointer_2 without using another
> pointer.

Done:

#include <stdio.h>

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

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

#75257

Alla _ <modelling.data@gmail.com> writes:
<snip>
>>You can, I'm sure, come up
>> with a way to swap *pointer_1 and *pointer_2 without using another
>> pointer.
>
> Done:

What an odd choice!  That adding a subtracting is not the clear and
simple way to swap two integers, and it can fail in some cases when the
arithmetic overflows.  You've written code to swap integers before but
because you now have pointers it's confused you.

How would you swap two integer objects calls 'one' and 'two'.  You'd
write

  int t = one;
  one = two;
  two = t;

You can do exactly the same thing when the two integer objects are
called '*pointer_1' and '*pointer_2'.  The point is that when you have a
pointer, p, to a thing, *p is that thing, pretty much as if you had a
name for it.

> #include <stdio.h>
>
> void sort (int* array_int, int n)
> {
>     int* pointer_1 = array_int;
>     int* array_end = &array_int[n - 1];
>     int* pointer_2 = pointer_1 + 1;
>     
>     while (pointer_1 < array_end - 1)

Both &array_int[n - 1]; and then array_end - 1 are problematic when the
array does not have enough elements.

Part of the problem is caused by your declaring all the pointers at the
top of the function whist at the same time insisting that they be
initialised.  That's going to give you grief.

>     {
>         while(pointer_2 < array_end)
>         {
>             if (*pointer_1 > *pointer_2)
>             {
>                 *pointer_1 += *pointer_2;
>                 *pointer_2 = *pointer_1 - *pointer_2;
>                 *pointer_1 -= *pointer_2;
>             }
>             pointer_1++;
>             pointer_2++;
>         }
>     }
>         
> }
>

-- 
Ben.

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

#75266

On Saturday, November 7, 2015 at 5:36:16 PM UTC+4, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> >>You can, I'm sure, come up
> >> with a way to swap *pointer_1 and *pointer_2 without using another
> >> pointer.
> >
> > Done:
> 
> What an odd choice!  That adding a subtracting is not the clear and
> simple way to swap two integers, and it can fail in some cases when the
> arithmetic overflows.  You've written code to swap integers before but
> because you now have pointers it's confused you.
> 
> How would you swap two integer objects calls 'one' and 'two'.  You'd
> write
> 
>   int t = one;
>   one = two;
>   two = t;
> 
Yes, I understand that. I thought you said not to use any third variable )
That is why I did it with only given variables - two pointers )

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

#75289

Alla _ wrote:
> 
> On Saturday, November 7, 2015 at 5:36:16 PM UTC+4, Ben Bacarisse wrote:
> > Alla _ <modelling.data@gmail.com> writes:
> > <snip>
> > >>You can, I'm sure, come up
> > >> with a way to swap *pointer_1 and *pointer_2 without using another
> > >> pointer.
> > >
> > > Done:
> > 
> > What an odd choice!  That adding a subtracting is not the clear and
> > simple way to swap two integers, and it can fail in some cases when the
> > arithmetic overflows.  You've written code to swap integers before but
> > because you now have pointers it's confused you.
> > 
> > How would you swap two integer objects calls 'one' and 'two'.  You'd
> > write
> > 
> >   int t = one;
> >   one = two;
> >   two = t;
> > 
> Yes, I understand that. I thought you said not to use any third variable )
> That is why I did it with only given variables - two pointers )

He didn't say to not use a third variable. He said to not use a third
pointer. But kudos for an ingenious solution to what you thought he said.

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

#75125

Philip Lantz <prl@canterey.us> writes:
> 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.
[...]

Possible, but that's not how I'd interpret it.  I'd assume that the
intent is to write a function to sort an array of integers using pointer
notation rather than using the [] operator.

This illustrates the importance of precise problem descriptions.  There
are too many things that "a pointer version of a sort() function" could
mean.

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

#75132

On Friday, November 6, 2015 at 8:55:14 PM UTC+4, Keith Thompson wrote:
> Philip Lantz <prl@canterey.us> writes:
> > 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.
> [...]
> 
> Possible, but that's not how I'd interpret it.  I'd assume that the
> intent is to write a function to sort an array of integers using pointer
> notation rather than using the [] operator.
> 
> This illustrates the importance of precise problem descriptions.  There
> are too many things that "a pointer version of a sort() function" could
> mean.
> 
> -- 
> 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"

Yes, I am sorry, I have posted the full version of the task, though
a bit later. 

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

#75071

Alla _ wrote:
>     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);'**/

Ben already mentioned this, but I want to emphasize that this
initialization of array_end is the most serious problem in your
program other than the sort loop itself. &array_int[n + 1] points
*two* past the end of the array, and it will likely cause very
strange behavior even if the sort loop is coded perfectly.

[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