Variable pointers and function pointers

I started studying pointers and i am becoming confused...
When you have pointer and that pointer has adress of another variable you need to use * derefrencing operator to access the value that is stored at that adress,
how come you don't need * operator when using function pointers?
example with regular pointers

Code:

---

int i(10),c;
int *b = &i;
c = *b;
// Now c is equal to i

---

example with function pointers

Code:

---

int IncOne(int var) {

return ++var;

}

int (*inc_one)(int) = &IncOne;
result = inc_one(1);
// now result is 2;

---

Is that right or am I missing something?
Following the pattern, wouldn't you expect that you have to use * operator to access
IncOne(int var) function?

Yes, it is one of the "strange" things about C (and thus C++, since it takes after C in most aspects) - you can get the address of a function without & [except if it's a class member function] and use a function pointer without * [whether it points to a member function or not].

--
Mats

Actually, the real syntax is:
result = (*inc_one)(1);
But since it's a bit awkward, a new syntax was developed:
result = inc_one(1);

This shortcut only works for "normal" function pointers and not for class member pointers:

Code:

---

class A { public: void foo(); };
int main()
{
    void (A::* fooptr)() = &A::foo; // Simply A::foo will cause a compile error
    A a;
    (a.*fooptr)(); // OK
    a.*fooptr(); // Error
}

---

Quote:

---

Originally Posted by Elysia

This shortcut only works for "normal" function pointers and not for class member pointers:

Code:

---

class A { public: void foo(); };
int main()
{
    void (A::* fooptr)() = &A::foo; // Simply A::foo will cause a compile error
    A a;
    (a.*fooptr)(); // OK
    a.*fooptr(); // Error
}

---

---

But a.fooptr() would be correct too, as far as I know.

--
Mats

No, fooptr() is not a member for A:
2>g:\w00t\visual studio 2008\projects\temp\temp3.cpp(13) : error C2039: 'fooptr' : is not a member of 'A'
2> g:\w00t\visual studio 2008\projects\temp\temp3.cpp(7) : see declaration of 'A'
You have to dereference the pointer, or it won't work.
Of course, the following syntax also works:

(&a->*fooptr)();

So in other words, * operator as well as & operator are optional for normal functions and are mandatory for class functions?
Is * mandatory for class functions? Since a.fooptr(); is wrong?
Hmm I would understand making the parentheses around *inc_one optional, but operators? Hmm what a strnge language C++ is.
I would make
result = *inc_one(1);
mandatory

Quote:

---

Originally Posted by Luciferek

So in other words, * operator as well as & operator are optional for normal functions and are mandatory for class functions?

---

Yes.

Quote:

---

Hmm I would understand making the parentheses around *inc_one optional, but operators? Hmm what a strnge language C++ is.

---

It's for backwards compatibility for no & before functions and the no need for * for functions is to make it possible to invoke them as if there were functions.
Both these traits are inherited from C.

And btw, the paranthesises are mandatory because of operator precedence.

result = *inc_one(1);

Basically does

1) inc_one(1)
2) *
3) result = result;

Therefore, you must force it to dereference the pointer first.

Quote:

---

I would make
result = *inc_one(1);
mandatory

---

Well, shrug. I wouldn't because I'm quite fond of calling function pointers using function syntax.

Quote:

---

result = *inc_one(1);

Basically does

1) inc_one(1)
2) *
3) result = result;

---

How does result = result?

I don't really get operator precedence in this case either;
if inc_one(1) is a pointer, and pointer is considered a variable
So it would make more sense to me that * would have higher precedence than a function call
Bjarne Strostrup really did not impress me here,
I wonder how backward compatible( read screwed up) will C++oX be!

Quote:

---

Originally Posted by Luciferek

How does result = result?

I don't really get operator precedence in this case either;
if inc_one(1) is a pointer, and pointer is considered a variable
So it would make more sense to me that * would have higher precedence than a function call
Bjarne Strostrup really did not impress me here,
I wonder how backward compatible( read screwed up) will C++oX be!

---

Elysia means that (variable) result = result (of what just happened).

The big thorn here is that inc_one(1) is not, in fact, a pointer, since inc_one returns an int. Trying to dereference an int doesn't work.

Function calls have the highest precedence of everything (well, they're equal to [], ., and ->). If you want to have *inc_one(1) with the * only seeing inc_one, you wouldn't be able to do this either:

Code:

---

foo = -inc_one(1);

---

because the - would only see the function name (and who knows what it means to negate a function pointer?) and bad things.

Quote:

---

if inc_one(1) is a pointer, and pointer is considered a variable

---

I think the point is that inc_one is the pointer, inc_one(1) is a function call (through a function pointer). And as dereference has lower precedence than grouping, *inc_one(1) should mean dereference the result of calling inc_one with value 1.

Quote:

---

Originally Posted by Luciferek

So it would make more sense to me that * would have higher precedence than a function call
Bjarne Strostrup really did not impress me here,

---

That's what you would think, but it's a matter of eye candy and all that.

Quote:

---

I wonder how backward compatible( read screwed up) will C++oX be!

---

It won't change much. In the real world, it's a good thing, but unfortunately, I cannot help but to agree to a certain degree with you - some backward compatibility is stupid.

Even more mind-boggling to me, than being optional, is that you can dereference a function pointer as many times as you want to:

Code:

---

whoie$ cat foo.cc
int foo() { return 1; }
int main() {
  int i = (**********foo)();
}
whoie$ g++ -c foo.cc
whoie$

---

Look ma! No errors, and quirky grammar! ;) But it isn't Stroustrup's doing, C++ inherited this, along with it's declaration syntax, from C. Blame Ritchie. :)