Stroustrup chapter 5, pointer to pointer to char

[arnuld]

i see the use of pointers, from K&R2 but what is the use of:


1. "pointer to pointer":

char c;
char** ppc;

2. pointer to function:

int (*fp) (char*);

3. function returning a pointer:

int* f(char*)

 

[mlimber]

i see the use of pointers, from K&R2 but what is the use of:

1. "pointer to pointer":

char c;
char** ppc;

A pointer to a char points to a char, and through it, you can modify
the char. A pointer to a pointer points to a pointer, and through it
you can modify the pointer. It is most often used for dynamically
allocated two-dimensional arrays (see
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.16)
and pointers that are passed to functions that need to modify the
pointer (e.g., a function that adds a node to the end of the linked
list may need to modify the pointer to the end of the list after
appending).

2. pointer to function:

int (*fp) (char*);

These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".

3. function returning a pointer:

int* f(char*)

It might be returning a pointer into a global lookup table based on an
input string, a dynamically allocated integer, or array of integers.

Note that pointers are useful, but you should avoid them when possible
in favor of less dangerous constructs. See
http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1.

Cheers! --M

 

[adrian.hawryluk]

i see the use of pointers, from K&R2 but what is the use of:

1. "pointer to pointer":

char c;
char** ppc;

Pointer to pointer is a way of going through two pointers to get to
the final type. This is most often used in 2D arrays. Originally in
C, 2D arrays are represented as a pointer to an array of pointers to a
type.

int const X = ...;
int const Y = ...;
int x;

char ** a = (char**)malloc(sizeof(char*)*X);
for(x=0; x<X; ++x) {
a[x] = (char*)malloc(sizeof(char)*Y);
}

Now you can access a as a 2D array: a[j]

However, Y doesn't necessarly need to be static in size. For
instance:

char * strings[] = { "hello", "there", "out", "there", "in", "la-
la", "land" };

will be deciphered as a char** as described above, but each string is
not the same length.

C and C++ has also a different array that can be allocated on the
stack or staticly. No going though pointers are required, the
compiler allocates an X*Y array on the stack and will calculate the
offset based on x+y*Y*sizeof(char).

char strings[][20] = { "hello", "there", "out", "there", "in", "la-
la", "land" };

will be have 7 elements each 20 chars in length, even though each
string is not 20 chars.

2. pointer to function:

int (*fp) (char*);

A pointer to a function is a way of indirectly calling a function.
The function that your fp can be assigned to in this case would be a
function that has an in return type and takes a char* as its only
parameter.

Example:

int myFn(char* str) {
return printf("%s", str);
}

int (*fp)(char*) = myFn;

int main()
{
myFn("hello");
fp("hello"); // does the same thing because calls the same function.
}

This is how virtual functions are done in C++ a vector table of
function pointers.

3. function returning a pointer:

int* f(char*)

This returns a pointer to an int. So perhaps f may want to pass
something that is to be modified by the caller, or it would be
expensive time-wise if passed by value to the caller (in this case,
int is usually the same size as a pointer so no real difference is
made here), or perhaps f is returning a pointer to an array of ints.

Does this make sense to you?


Adrian

 

[arnuld]

Pointer to pointer is a way of going through two pointers to get to
the final type. This is most often used in 2D arrays. Originally in
C, 2D arrays are represented as a pointer to an array of pointers to a
type.

int const X = ...;
int const Y = ...;
int x;

char ** a = (char**)malloc(sizeof(char*)*X);
for(x=0; x<X; ++x) {
a[x] = (char*)malloc(sizeof(char)*Y);

}

Now you can access a as a 2D array: a[j]

However, Y doesn't necessarly need to be static in size. For
instance:

char * strings[] = { "hello", "there", "out", "there", "in", "la-
la", "land" };

will be deciphered as a char** as described above, but each string is
not the same length.

C and C++ has also a different array that can be allocated on the
stack or staticly. No going though pointers are required, the
compiler allocates an X*Y array on the stack and will calculate the
offset based on x+y*Y*sizeof(char).

char strings[][20] = { "hello", "there", "out", "there", "in", "la-
la", "land" };

will be have 7 elements each 20 chars in length, even though each
string is not 20 chars.

out of my head. i guess, the reason is, onw ill understand them only
when he will develop some softwares.

right ?

A pointer to a function is a way of indirectly calling a function.

Is that the only reason ?

indirect call, what is its significance ?

The function that your fp can be assigned to in this case would be a
function that has an in return type and takes a char* as its only
parameter.



This returns a pointer to an int. So perhaps f may want to pass
something that is to be modified by the caller, or it would be
expensive time-wise if passed by value to the caller (in this case,
int is usually the same size as a pointer so no real difference is
made here), or perhaps f is returning a pointer to an array of ints.

Does this make sense to you?

yep, it made sense to me. i understood these from K&R2 some time ago.

 

[arnuld]

A pointer to a char points to a char, and through it, you can modify
the char. A pointer to a pointer points to a pointer, and through it
you can modify the pointer. It is most often used for dynamically
allocated two-dimensional arrays (seehttp://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.16)
and pointers that are passed to functions that need to modify the
pointer (e.g., a function that adds a node to the end of the linked
list may need to modify the pointer to the end of the list after
appending).

Hmmm.... a sofwtare-development issue, literally out of my head but i
do ot ask for clarification. i think this fog will clear-up when i
will start developing real-life softwares.

These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".
ok



It might be returning a pointer into a global lookup table based on an
input string, a dynamically allocated integer, or array of integers.

thanks for the simple and easy explanation of last 2 points

Note that pointers are useful, but you should avoid them when possible
in favor of less dangerous constructs. See
http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1.

i know, i am only trying to understand them.

 

[adrian.hawryluk]

A pointer to a char points to a char, and through it, you can modify
the char. A pointer to a pointer points to a pointer, and through it
you can modify the pointer. It is most often used for dynamically
allocated two-dimensional arrays (seehttp://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.16)
and pointers that are passed to functions that need to modify the
pointer (e.g., a function that adds a node to the end of the linked
list may need to modify the pointer to the end of the list after
appending).
Yup.



These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".

Noooooooooo! This is a function pointer. Functors are related to
objects as in:

class A {
int stateVar;
public: int operator()(int x, int y);
};

That is a functor, it allows an object to act like a function, and
since it has it's own state, it could be used in place of this model
of a function:

int A(int x, int y)
{
static int stateVar;

....
}
which has only one instance. The stateVar(s) are optional in
functors, of course.


A function pointer is like this:

void* (*myMalloc)(size_t) = malloc;

You can now use myMalloc to call malloc indirectly, you can also
change what myMalloc points at during runtime unless you state it like
this:

void* (* const myMalloc)(size_t) = malloc;

Which means that the function pointer is constant and non-changeable.

It might be returning a pointer into a global lookup table based on an
input string, a dynamically allocated integer, or array of integers.

Note that pointers are useful, but you should avoid them when possible
in favor of less dangerous constructs. Seehttp://www.parashift.com/c++-faq-lite/containers.html#faq-34.1.

Yup.


Adrian

 

[adrian.hawryluk]

Is that the only reason ?

indirect call, what is its significance ?

The significance is for late binding. This is also known as a
callback and is used primarily in event programming. In C++ (although
hidden in the compilers internals) it is used for virtual functions,
which if you think about it, is like event programming. You have an
object and you need to tell the object that something has happened,
i.e. an event has occurred. However, at compile time, a piece of code
may not know what function to call (because it is a generic piece of
code), but it would know at runtime. qsort() is a classic example and
can be seen at http://www.cplusplus.com/reference/clibrary/cstdlib/qsort.html.

I've wrote a significant part of a system in C using pseudo-objects
and callbacks to write OO code. It greatly reduces copy coding.


Adrian

 

[adrian.hawryluk]

yep, it made sense to me. i understood these from K&R2 some time ago.

Then why ask?


Adrian

 

[Lionel B]

[snip]

Noooooooooo! This is a function pointer. Functors are related to
objects as in:

class A {
int stateVar;
public: int operator()(int x, int y);
};

That is a functor, it allows an object to act like a function, and
since it has it's own state, it could be used in place of this model
of a function:

mlimber didn't say "This is a function pointer", s/he said "See also
functors" - but didn't say why! Perhaps there's a point to be made along
the lines that functors are frequently used in C++ to provide more elegant
solutions to callbacks, generic programming, etc. than can be achieved
with function pointers, or to "wrap" function pointers to hide ugly
implementation details or provide generic interfaces.

Just my tuppence worth.

[snip]

 

[mlimber]

mlimber didn't say "This is a function pointer", s/he said "See also
functors" - but didn't say why! Perhaps there's a point to be made along
the lines that functors are frequently used in C++ to provide more elegant
solutions to callbacks, generic programming, etc. than can be achieved
with function pointers, or to "wrap" function pointers to hide ugly
implementation details or provide generic interfaces.

Just my tuppence worth.

Precisely.

Cheers! --M

 

[adrian.hawryluk]

i see the use of pointers, from K&R2 but what is the use of:

[snip]

2. pointer to function:
int (*fp) (char*);
These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".

Noooooooooo! This is a function pointer. Functors are related to
objects as in:

class A {
int stateVar;
public: int operator()(int x, int y);
};

That is a functor, it allows an object to act like a function, and
since it has it's own state, it could be used in place of this model
of a function:

mlimber didn't say "This is a function pointer", s/he said "See also
functors" - but didn't say why! Perhaps there's a point to be made along
the lines that functors are frequently used in C++ to provide more elegant
solutions to callbacks, generic programming, etc. than can be achieved
with function pointers, or to "wrap" function pointers to hide ugly
implementation details or provide generic interfaces.

Just my tuppence worth.

[snip]

Sorry but he did, although it wasn't intentional.

These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".

Well, I found it unclear. The comma between "callback" and "generic
programming" is clearly an implied conjunction with the parenthesis
showing an example on how it can be used. I don't see what the etc
was referring to either. "These are useful for callbacks, generic
programming, "... and what? Are there other reasons to use a function
pointer? If I misunderstood the sentence, it was because it was just
poorly formed and was hard to read.

Oh, and although functors are perhaps a more 'elegant' way of
representing a function pointer, it is actually not a function
pointer. It is an object with a function *like* interface and is why
it is called a functor not a function pointer.

I personally find that they are mostly (though not entirely) a waste
of time, as it decouples the code a bit too much (in the case of a
loop, its body can be very far away from the loop which may be a one
shot deal), can be hard to read (because of the decoupling), can add
additional overhead (an additional object is created), adds a lot of
extra typing (a real pain when doing one shot loops), and they can
take some time to get your head around (using the algorithms, not the
functors). Additionally the operator()() syntax is not exactly pretty
either.

On the plus side, it is real neat cool stuff (impress your friends),
and if you use the functors more than 1 or 2 times, then it is a real
gain as you don't copy code your algorithm and its decoupled portion
(the true and only benefit that I see).


Adrian

 

[mlimber]

i see the use of pointers, from K&R2 but what is the use of: [snip]
2. pointer to function:
int (*fp) (char*);
These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".
Noooooooooo! This is a function pointer. Functors are related to
objects as in:

[snip]
mlimber didn't say "This is a function pointer", s/he said "See also
functors" - but didn't say why!

Sorry but he did, although it wasn't intentional.

Read it again. The OP called it a "pointer to function" and asked
"What's the use of it?" I said "These [antecedent: 'pointer to
function'] are useful for [sample uses]." I then suggested the OP
also look into functors, which have some definite affinities to
function pointer, particularly in generic programming. I did not in
any way say the two were identical.

(BTW, I think Lionel B. meant to say, "mlimber didn't say, 'This is a
functor.'")

Well, I found it unclear.
YMMV.

The comma between "callback" and "generic
programming" is clearly an implied conjunction with the parenthesis
showing an example on how it can be used.

Right. It was a list of uses. Stripping the parenthetical and
translating the abbreviation, the list was callbacks, generic
programming, and others.

I don't see what the etc
was referring to either. "These are useful for callbacks, generic
programming, "... and what? Are there other reasons to use a function
pointer?

You yourself gave other concrete examples -- one being a virtual
table, which one could also create explicitly, though not as
naturally, as a member of a struct.

If I misunderstood the sentence, it was because it was just
poorly formed and was hard to read.

I disagree, but you're certainly entitled to your opinion.

Oh, and although functors are perhaps a more 'elegant' way of
representing a function pointer, it is actually not a function
pointer. It is an object with a function *like* interface and is why
it is called a functor not a function pointer.

No one has said differently here.

[snip]

Cheers! --M

 

[Lionel B]

On Mar 5, 12:15 pm, "arnuld" <[email protected]> wrote:

i see the use of pointers, from K&R2 but what is the use of:
[snip]



2. pointer to function:

int (*fp) (char*);

These are useful for callbacks, generic programming (e.g. with
std::for_each), etc. See also "functors".

Noooooooooo! This is a function pointer. Functors are related to
objects as in:

class A {
int stateVar;
public: int operator()(int x, int y);
};

That is a functor, it allows an object to act like a function, and
since it has it's own state, it could be used in place of this model
of a function:

mlimber didn't say "This is a function pointer", s/he said "See also
functors" - but didn't say why! Perhaps there's a point to be made along
the lines that functors are frequently used in C++ to provide more elegant
solutions to callbacks, generic programming, etc. than can be achieved
with function pointers, or to "wrap" function pointers to hide ugly
implementation details or provide generic interfaces.

Just my tuppence worth.

[snip]

^^^^^^^^
Please don't quote signatures.

Sorry but he did, although it wasn't intentional.

Did what...?

Well, I found it unclear.

Strange, I found it perfectly clear.

[snip]

Oh, and although functors are perhaps a more 'elegant' way of
representing a function pointer, it is actually not a function
pointer.

I never said functors were an elegant way of _representing_ function
pointers and I certainly did not say they _were_ function pointers. Read
the paragraph I wrote again.

It is an object with a function *like* interface and is why
it is called a functor not a function pointer.

Of course.

I personally find that they are mostly (though not entirely) a waste
of time, as it decouples the code a bit too much (in the case of a
loop, its body can be very far away from the loop which may be a one
shot deal), can be hard to read (because of the decoupling), can add
additional overhead (an additional object is created), adds a lot of
extra typing (a real pain when doing one shot loops), and they can
take some time to get your head around (using the algorithms, not the
functors).

I actually find that "decoupling" quite clarifying, insofar as it allows
me to abstract the algorithm from the object it operates on (maybe
that's because I'm a mathematician, so I get off on that kind of thing).
And, with modern compilers, I've never found the overhead to be in the
least bit significant.

Additionally the operator()() syntax is not exactly pretty either.

It's like the Mona Lisa compared to (member) function pointer syntax.

Anyhow, functors certainly can be extremely powerful, elegant and provide
clean, generic interfaces. A nice example of that came up in a recent
thread here:

http://groups.google.co.uk/group/co...read/thread/af91e2e274c46011/10c43637fb187368

On the plus side, it is real neat cool stuff (impress your friends),

Unfortunately my work doesn't afford me the luxury of coding to impress my
friends. If I use functors at all it is strictly in anger.

and if you use the functors more than 1 or 2 times, then it is a real
gain as you don't copy code your algorithm and its decoupled portion
(the true and only benefit that I see).

I don't entirely disagree; but I find myself writing "generic" algorithms
often enough that functors have become pretty indispensable to my coding.

 

[adrian.hawryluk]

These are useful for callbacks, generic programming (e.g. with

Strange, I found it perfectly clear.

To each their own parse.

I never said functors were an elegant way of _representing_ function
pointers

Well you did say the following:

... Perhaps there's a point to be made along
the lines that functors are frequently used in C++ to provide more elegant
solutions to callbacks, generic programming, etc. than can be achieved
with function pointers, or to "wrap" function pointers to hide ugly
implementation details or provide generic interfaces.

That does seem to allude to it.

and I certainly did not say they _were_ function pointers. Read
the paragraph I wrote again.

Yes, you did not say that.

I actually find that "decoupling" quite clarifying, insofar as it allows
me to abstract the algorithm from the object it operates on (maybe
that's because I'm a mathematician, so I get off on that kind of thing).
And, with modern compilers, I've never found the overhead to be in the
least bit significant.


It's like the Mona Lisa compared to (member) function pointer syntax.

Hey, stop dissing the Mona Lisa.

Anyhow, functors certainly can be extremely powerful, elegant and provide
clean, generic interfaces. A nice example of that came up in a recent
thread here:

True, however, functors are just syntactic sugar; adapters are really
the only thing necessary to do the exact same thing.

http://groups.google.co.uk/group/comp.lang.c++/browse_thread/thread/a...

Interesting article, I'd really like to know about that new template
syntax.

Unfortunately my work doesn't afford me the luxury of coding to impress my
friends. If I use functors at all it is strictly in anger.

Don't get angry; just throw the monitor out the window.

I don't entirely disagree; but I find myself writing "generic" algorithms
often enough that functors have become pretty indispensable to my coding.

Fair enough.


Adrian