About member function pointers...

I finally got into making member function pointers and it took me a while because of the small difference with the other pointers, but there's one thing I don't understand: it's the way the function's address are allocated, they seem to follow no logic at all... Let's take for example a class with 2 ints in it:

Code:

---

class X {
        int a, b;
};

---

So the address to the class could be 1000, (example) so then the first int should be at address 1000 too, and the other one, "b", should be at 1004... But as for functions, they are placed in memory to places that doesn't even follow the class's begeninng address, and there is no way to find a pattern to that....

But was is really going on with all this? Can we decide to place the member functions at address that follows the class?

I know for instance that when you copy (entirely) a variable of any class, it just copies all bytes from "&X" to "&X + sizeof(X)" (if X was a var. of a class) So for this if the functions were "inside" the class it would copy unnecessary infos. But then where does the functions address comes from, and why don't they are in a pattern of fixed step of memory???

>But was is really going on with all this?
You're confusing the blueprint for an object with the actual object. Member functions don't take up any storage in an object. In fact, they're instructions and as such are stored in a different location than data.

So there's no real way of figuring out what its address should be if we looked up at the addresses of other member-functions of that same class?

>So there's no real way of figuring out what its address should be if we looked up at the
>addresses of other member-functions of that same class?
What's "it"? The only way to obtain the address of a member function is with a pointer to a member function, and that address is completely independent of the other member functions in the class. Just because you have one address it doesn't mean you can accurately resolve the other addresses. Likewise, the address of a member function won't let you calculate the address of the object, because there's simply not enough information to do so.

With sufficient "inside" knowledge of how your compiler organizes the object code, you can certainly do these things, but it's not portable, and I honestly can't imagine why you would need such functionality.

It was just to build up an array of member function pointers faster, like what I had in mind:

Code:

---

some_class ABC;

for (int x = 0; x < number_of_func; x++)
{
        array_of_ptrs[x] = &ABC + x * address_difference_between_funcs;
}

---

Well, I was hoping for something like that, maybe not usefull, but it was to test the language again... but in this case at least all the member functions would be of the same signature...

You are trying to dwelve too much into the language specifics.

Give me a second while I look for the best advise that can be given to you. By the inventor of C++ programming language himself... ...

Here it is...

Quote:

---

From Stroustrup's C++ Programming Language, 3rd Edition (13th printing).
Section 2.9 (page 43)

[1] Don't panic! All will become clear in time;
[2] You don't have to know every detail of C++ to write good programs;
[3] Focus on programming techniques, not on language features;

---

Lol! But I would like to know alll the language!

I'v got some other question, and though now I'm all mixed up...

Code:

---

struct ABC {
        bool A;
        int B;
};

---

Why does sizeof(ABC) would return 8, and not 5?
And why isn't a "long" var not 8 bytes, I learned at school that
it should be 8, but now I get 4 (sizeof), so I believe that a long int
must be the same thing as an int?

Quote:

---

Originally Posted by mikahell

Why does sizeof(ABC) would return 8, and not 5?

---

http://c-faq.com/struct/endpad.html

Quote:

---

Originally Posted by mikahell

And why isn't a "long" var not 8 bytes, I learned at school that it should be 8, but now I get 4 (sizeof), so I believe that a long int must be the same thing as an int?

---

Sizes of both int and long are implementation dependent.

Good! Now I see why it works this way, I followed the link and figured it out...
So thanks a lot because I was getting puzzeled since it worked sometimes before,
it only had to depend what is the order of the types....

>But I would like to know alll the language!
I doubt anyone knows every detail of C++. More important is to learn the most useful parts of the language and library, then you can work towards becoming more of an expert. In reality, only about 10% of the language is what you'll use 90% of the time. So master that stuff first. :)

>I learned at school that it should be 8
You learned wrong, I'm afraid. The actual sizeof any primitive type but char is not set in stone. char is always 1.

>so I believe that a long int must be the same thing as an int?
It can be, but it doesn't necessarily have to be.

Quote:

---

Originally Posted by mikahell

Lol! But I would like to know alll the language!

---

You shouldn't consider implementation details part of the language. The exact size of structures, the way classes and code are organized, that's all implementation details.