One source of confusion among new C programmers is pointers. At first glance, there doesn't seem to be much usefulness in using them. But, it is cr...
For further actions, you may consider blocking this person and/or reporting abuse
Probably worth noting as well, one of the more common uses:
In this case, it's used as an array of
char *
, your program arguments.Couldn't
getline
have returned a struct? Why is an output parameter necessary to begin with?I think it's obvious I'm not a
C
guy, get over it ;-)A
struct
is several bytes long, and you'd need to add in the cost of getline's return value as well. These values have to be pushed onto the stack, and then pulled back off and copied again into the receivingstruct
. That costs valuable processor cycles, but also it's a hidden cost that's not intuitive from reading the code, and therefore goes against C's design.What might have been better is you have passed in a pointer to a
struct
, which would have involved fewer pushes and pops to stack - though with modern calling conventions the function arguments and return are in registers anyway, I think.The cost is not intuitive, I see.
Maybe, but the POSIX people decided to use an output parameter.
That's not a maybe ;-)
I was asking about the design decision itself.
The return value of
getline()
is the number of characters read. Because this return value is already in use, they decided an output parameter for the contents would be sufficient.A comment above made sense. It was in use doesn't justify the design.
It might be worth emphacising the value of typedefs to represent the semantics of the pointer "types". This reduces errors resulting from the confusion that your article alludes to by making double pointers look and act like single pointers. More a topic for the value of typedefs, but their usage can keep clear in one's mind, the usage and intent of the elements, pointer, double pointer, n-pointer, or no pointer.
In C++, there is another way to code a double pointer (*&). See stackoverflow.com/a/5789842/5652483
That's a reference to a pointer, not a double pointer.
I remember the first time, i saw pointers, they were mysterious and a little scary but the idea of directly dealing with the underlying memory was very captivating, so i ended up learning quite a lot about pointers.
Very well explained, remember learning them and It just blew me into oblivion. Would be interesting to see how someone could explain double pointers in the #explainlikeimfive way
Arrows and boxes, a good old fashioned diagram is what is called for. :)
I might take that challenge on another day.