Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Understanding the program that has pointers to two_dimensional arrays |
| Date | 2016-12-05 17:03 +0000 |
| Organization | Fix this later |
| Message-ID | <o246iv$8m7$1@dont-email.me> (permalink) |
| References | <481da833-61f6-4f1c-973b-1b129118c682@googlegroups.com> |
On 05/12/16 15:45, Alla _ wrote:
>
> Hello!
>
> Please, take a look at my reading of the program (in comments to each statement)
> that uses pointers to two-dimensional arrays.
No, it doesn't. Not at any point. What it does use is a pointer to
pointer to int, which you point at the beginning of storage suitable for
storing several int * objects. And those int * are used for pointing at
the beginning of storage that is suitable for storing several int objects.
> Is my understanding correct, i.e. do
> correctly interpret the given code? And, please, help me to understand one part closer
> to the end of the program.
>
>
> #include <stdio.h>
> #include <stdlib.h>
> int main(void)
> {
> // define the number of rows and columns
> int nrows = 5;
> int ncols = 10;
> int row;
>
> // initialise a pointer, which points to a pointer, which, in turn, points to type int,
> // i.e. stores the address of an integer value
> int **rowptr;
Yes, rowptr is suitable for pointing to objects of type int *, which are
in turn suitable to pointing to objects of type int.
> /*** define rowptr pointer
No, it's already defined. What you're about to do is assign to it.
> by assigning to it the value of the address of the array,
> allocated by the call to malloc for nrows (5 in this case) pointers to type int;
That's one way to say it, yes. You are asking for enough storage to
store 5 objects of type int *.
> therefore the value of the rowptr after the call to malloc will be the address,
> at which the first element in the array of pointers to integer type could be stored;
> of course, none of these pointers yet point anywhere
> ***/
Correct.
>
> rowptr = malloc(nrows * sizeof(int *));
Better: rowptr = malloc(nrows * sizeof *rowptr);
which will still be correct even if you later change the type of rowptr.
>
> /** check of the memory has been allocated; if not, print the info message,
> and exit **/
> if (rowptr == NULL)
> {
> puts("\nFailure to allocate room for row pointers.\n");
> exit(0);
> }
Yes. Not /quite/ how I would do it, but you are correctly checking that
the storage allocation request succeeded. If it didn't, you have to take
evasive action. Terminating the program, as you are doing, is generally
acceptable in student code.
> // Print the title
> printf("\n\n\nIndex Pointer(hex) Pointer(dec) Diff.(dec)");
>
> /** Allocate memory for an array of ncols integers for every row, and store the value of the
> allocated address of the first element of each array at the pointer rowptr[row],
> such that rowptr[row] now points to corresponding address of the first element
> in the array of ncols integers **/
Yes.
>
> for (row = 0; row < nrows; row++)
> {
> rowptr[row] = malloc(ncols * sizeof(int));
Better: rowptr[row] = malloc(ncols * sizeof *rowptr[row]);
>
> /** check of the memory has been allocated; if not, print the info message,
> and exit **/
> if (rowptr[row] == NULL)
> {
> printf("\nFailure to allocate for row[%d]\n",row);
> exit(0);
> }
Yes, that's fine.
> /** Here is the difficult part: print the number of the current row "row",
> print the hexadecimal address of the pointer that now has the value
> of the address of the first element of the array of integers;
> and the third element should the same address of the pointer
> but its decimal value;
>
> When I tried to compile this, I have received an error message,
> which I solved by casting (void *)
If the compiler is complaining that int * doesn't match void * in a call
to printf, then the cast is (saints preserve us) actually correct! This
is one of the very, very, very few times that a cast is not a completely
hopeless idea.
> to the first call to rowptr[row]
> (see my new printf below the original one), which is specified
> by %p; but I can't solve the second error message (see below)
> and I don't understand why the author has not mentioned anything
> about it:
> error: format specifies type 'int' but the argument has
> type 'int *' [-Werror,-Wformat]
> printf("\n%d %p %d", row, rowptr[row], rowptr[row]);
> ~~ ^~~~~~~~~~~
>
> **/
>
> /** original printf function:
> printf("\n%d %p %d", row, rowptr[row], rowptr[row]); **/
What is this horrible thing you are doing? \n is a line end character,
not a line beginning character! Ouch eek ow ow bad! (It's not against
the rules or anything. It just shows a complete disregard for the
semantics of \n.)
>
> // partially corrected printf
> printf("\n%d %p %d", row, (void *)rowptr[row], rowptr[row]);
You have been asked to do something too difficult. It's not impossible,
of course, but it's difficult.
Printing the address with %p is correct. But /how/ it is printed is
entirely up to the implementation. For example, on one early system it
might print something like "DS:04E0", which is part-hexadecimal and
part-abbreviation.
If you want to print it in hexadecimal (and then decimal), you're going
to need to get to the object representation of the pointer value. And
/that/ is a major distraction from learning about pointers to pointers.
>
> /** print the difference between the value of addresses of each row **/
>
> if (row > 0)
> printf(" %d",(int)(rowptr[row] - rowptr[row-1]));
And that's just broken. rowptr[row] and rowptr[row - 1] point to
different areas of memory. The subtraction invokes undefined behaviour.
What book is this, and why haven't you burned it yet? What happened to
your reading of K&R?
--
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
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-05 07:45 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-05 17:03 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-05 09:43 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-05 18:16 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-05 22:46 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 10:23 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-06 02:53 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 10:58 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-06 03:42 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-06 06:31 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 14:49 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-06 08:22 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 16:48 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-06 09:15 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Keith Thompson <kst-u@mib.org> - 2016-12-06 08:20 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-05 22:53 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Keith Thompson <kst-u@mib.org> - 2016-12-05 09:26 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-05 09:47 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Keith Thompson <kst-u@mib.org> - 2016-12-05 12:10 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Alla _ <modelling.data@gmail.com> - 2016-12-05 10:00 -0800
Re: Understanding the program that has pointers to two_dimensional arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 19:11 +0000
Re: Understanding the program that has pointers to two_dimensional arrays Keith Thompson <kst-u@mib.org> - 2016-12-05 12:21 -0800
Re: Understanding the program that has pointers to two_dimensional arrays "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-05 12:50 -0500
csiph-web