Despite teaching the C language, I still find myself at odds with pointers. Specifically, it’s the double pointers that remind me of my mortality. I found myself getting into the double pointer polka recently when I tried to work with an array of strings, passing each one individually to a function. O! The pain!
\n
\nAs it turns out, my frustration was misplaced. Still, I’d like to impart my journey of woe and teach a bit more about double pointers.<\/p>\n
My desire is to process a series of strings in a function. Each string is stored in an array, which makes it a pointer-pointer thing. Anyhoo. The first step is to write a smaller version of the program that passes a single string without manipulating that string. To keep things simple, I use array notation:<\/p>\n
\r\n#include <stdio.h>\r\n\r\nvoid output(char a[])\r\n{\r\n int x = 0;\r\n\r\n while( a[x] )\r\n {\r\n putchar( a[x]);\r\n x++;\r\n }\r\n putchar('\\n');\r\n}\r\n\r\nint main()\r\n{\r\n char string[] = \"Hello, world!\";\r\n\r\n output(string);\r\n\r\n return(0);\r\n}<\/pre>\nLine 17 declares string[]<\/code> and assigns it text. This string is passed directly to the output()<\/em> function at Line 19.<\/p>\nThe output() <\/em>function specifies array notation in its argument list. This notation is used throughout the function, which should be easy to understand for all C programmers.<\/p>\nHere is the same code, but using pointers:<\/p>\n
2021_08_21-Lesson-b.c<\/a><\/h3>\n\r\n#include <stdio.h>\r\n\r\nvoid output(char *a)\r\n{\r\n int x = 0;\r\n\r\n while( *(a+x) )\r\n {\r\n putchar(*(a+x));\r\n x++;\r\n }\r\n putchar('\\n');\r\n}\r\n\r\nint main()\r\n{\r\n char string[] = \"Hello, world!\";\r\n\r\n output(string);\r\n\r\n return(0);\r\n}<\/pre>\nThe main()<\/em> function is the same for both versions of the program; you can pass a pointer to a string or a char<\/em> array to the function. My focus was on the function — which might have been my first mistake.<\/p>\nThe output()<\/em> function’s argument is a pointer, char *a<\/code>. In the function, I’ve translated array notation into pointer notation: a[x]<\/code> is similar to *(a+x)<\/code>, a topic I cover in my books. Otherwise the two versions of the function operate the same and generate identical output.<\/p>\nAfter these programs worked, my next step is to update the code so that multiple strings are processed from an array. The output()<\/em> function need not change, so the following update reflects updates in the main()<\/em> function:<\/p>\n2021_08_21-Lesson-c.c<\/a><\/h3>\n\r\n#include <stdio.h>\r\n\r\nvoid output(char *a)\r\n{\r\n int x = 0;\r\n\r\n while( *(a+x) )\r\n {\r\n putchar(*(a+x));\r\n x++;\r\n }\r\n putchar('\\n');\r\n}\r\n\r\nint main()\r\n{\r\n char *string[3] = {\r\n \"Hello, world!\",\r\n \"This is a string test\",\r\n \"Once upon a time, there was a string\"\r\n };\r\n int x;\r\n\r\n for( x=0; x<3; x++ )\r\n {\r\n output(string[x]);\r\n }\r\n\r\n return(0);\r\n}<\/pre>\nIn this code, three strings are declared at Line 17. Technically, what’s declared is an array of char<\/em> pointers, each of which references a string stored in memory. This note is important to remember, something that I eventually forgot.<\/p>\nA for<\/em> loop passes each string to the output()<\/em> function, which uses pointer notation as shown earlier. Everything works; the three strings are output properly.<\/p>\nAt this point, I proved my code worked. But my goal is to modify the strings. This update is where I encountered my frustration with pointers. An array of strings *string[]<\/code> is really **string<\/code>. This relationship plays out in how a function can access and manipulate characters in the strings. Do things wrong and . . . BOOM<\/em>!<\/p>\nYou might be able to see my problem right away. I can now, and it’s painful to me. Still, in next week’s Lesson<\/a>, I explore how the manipulation process works in an updated version of the code, and how I screwed up.<\/p>\n","protected":false},"excerpt":{"rendered":"Passing strings to functions the easy way — but don’t count in it being easy for long. Continue reading