c++ global function vs data member function according to memory

Question

Let's assume there is a kind of a function, which could be both global function or could be implemented as class member const function (not static, static means global). It depends on user's choice if the function will be called or not called at all. Let say - It is usually not called or called rare - in very special cases. I am not interested of the program's logic organization. My question is about the memory usage. I know that data member function costs a little bit more (one pointer more), since it is called trough an object. What about the case if the function is not called in runtime? If it is global function it will be resident in memory during program's lifelong no matter it is called or not. What about the case of data member function, since it is called through and object that is dynamically created, respectively - not created at all, what about the memory needed for the function, where it will be placed and what happens if an object is not created at all?

Thanks.

I think you misunderstand, all functions, member or not, have their code reside in memory. Member functions can be looked at (kinda, not at all accurate) as regular functions with an implicit parameter. — StoryTeller - Unslander Monica, Nov 21 '13 at 14:52
Then what is the sense of data member functions at all? Just to have more readable programs? I don't mean scope, virtual, friends, etc. According to memory point of view it is more useful all the functions to be global then? — Nickoleta Dimitrova, Nov 21 '13 at 14:54
Member functions represent strong relationship between data and code, with compiler support. And they also make expressing that connection easy and readable, yes. — StoryTeller - Unslander Monica, Nov 21 '13 at 14:56
Seems I have serious omissions in my knowledge. I was convinced that when an object is dynamically created, the needed memory for all its members (data members and functions) are dynamically allocated. — Nickoleta Dimitrova, Nov 21 '13 at 15:12
@NickoletaDimitrova, that's quite wasteful. Are we gonna create the same function, code an all, for every instance? :) — StoryTeller - Unslander Monica, Nov 21 '13 at 15:15
The functions' code is common to all your instances, its memory is allocated once — Drax, Nov 21 '13 at 15:15
I have never thought over that, thanks. I am confused. Then there is no memory difference between static member functions then and just member functions. The difference is just conceptual. — Nickoleta Dimitrova, Nov 21 '13 at 15:24

Fred Foo · Answer 1 · 2013-11-21T15:41:20.783

1

In typical C++ implementations:

A function is a function, regardless of whether it's a member function of some class, and it will reside in memory "forever" (disregarding demand-paging and all that).
A non-virtual member function is nothing more than an ordinary function that takes a hidden argument called this.
A virtual member function is a member function that has its address recorded in a dispatch table for the class that it belongs to.

So member functions are very much like ordinary functions, the main thing that changes is the way the call is done: with an additional argument, and possibly through a hidden function pointer.

edited Nov 21 '13 at 15:41

answered Nov 21 '13 at 15:20

Fred Foo

355,277
75
744
836

Where in memory it resides? In the data segment? – Nickoleta Dimitrova Nov 21 '13 at 15:29
@NickoletaDimitrova: typically in the text segment. Why would code live in a data segment? There's no way in the language to modify code. – Fred Foo Nov 21 '13 at 15:39

score 1 · Answer 2 · answered Nov 21 '13 at 15:23

As was mentioned in the comments, a class member function in C++ can be thought of as a normal C-style function which implicitly takes as an argument a pointer to the instance of the class from which it is called. For example, consider the following C++ code:

class foo {
 public:
  void set(int j);
 private:
  int i;
};

void foo::set(int j) {
  i = j;
}

The function foo::set can be thought of a C-style function which takes a (hidden) argument of type class foo *, and when you do foo a; a->set(3);, the class foo * that is (implicitly) passed is &a.

In summary, whether or not you ever call foo::set, it will be loaded into memory. (The only possible exception is if there are no calls to the function in your code at all, in which case an optimizer may remove it during compilation, but if it is possible to call it dynamically based on user input then it will be loaded.) On the other hand, no matter how many instances of class foo you have, only one copy of foo::set ever needs to exist in memory.

score 1 · Answer 3 · edited May 23 '17 at 12:12

If your function isn't virtual then there is no overhead of being a member function (aka method).

In fact, in generated object code there is no such notion of a "member function" (unless it's virtual, more on that later). All methods are functions with special variable this. Compiler at the compile time knows what method is to be called at the run time, so it can generate method-specific object code (with some handling of this). By the way, that's the case why the following code doesn't crash:

#include <iostream>

class Crashy {
public:
        void wouldItCrash() {
                std::cout << "Hey, I'm still alive!" << std::endl;
        }
};

int main() {
        Crashy* ptr = 0;
        ptr->wouldItCrash();
        return 0;
}

Despite of null pointer there, programs successively finishes and prints "Hey, I'm still alive!". And that's okay if you think about method wouldItCrash as some kind of a function with special parameter this:

#include <iostream>

void Crashy__wouldItCrash(Crashy *this) {
        std::cout << "Hey, I'm still alive!" << std::endl;
}

int main() {
        Crashy* ptr = 0;
        Crashy__wouldItCrash(ptr);
        return 0;
}

We don't dereference the pointer in function, so no problems happen.

Consider the following simple program:

#include <iostream>

void FunctionName__() {
        std::cout << "Hello from function!" << std::endl;
}

class ClassName__ {
public:
        void MethodName1__() {
                std::cout << "Hello from method 1!" << std::endl;
        }
        void MethodName2__() {
                std::cout << "Hello from method 2!" << std::endl;
        }
};

int main() {
        FunctionName__();

        ClassName__ a;
        a.MethodName1__();
        a.MethodName2__();
        return 0;
}

If you compile it without optimizations (just g++ main.cpp) and then look at the symbols table (nm a.out), you'll see

0804876d T _Z14FunctionName__v
...
0804882c W _ZN11ClassName__13MethodName1__Ev
08048858 W _ZN11ClassName__13MethodName2__Ev

That is, all methods became just plain functions with special names (so no conflict could happen, see name mangling)

Virtual functions

As I said earlier, there are some special rules applying to the virtual functions. Virtual functions cannot be resolved at the compile-time (compiler doesn't know which instance of derived class will be processed at the run-time), so it's delayed to the run-time. So in order to serve virtual functions, each class (with that kind of functions, of course) has a special lookup table named virtual method table (aka vtable). In that case you clearly pay some memory space: you need a pointer to the function in the vtable and a pointer to the vtable for each instance of your class.

c++ global function vs data member function according to memory

3 Answers3