SMP question

[sluijten]

I understand why some data needs to be copied for multithreading to work.
What happens with member functions of structures that are being copied?
Are they copied too? Do they *need* to be copied (I guess not) ?
If not, then why implement member functions at all? Would it be more efficient (in the context of SMP) to NOT have any member functions and keep all the coding shared?

[rbarreira]

I understand why some data needs to be copied for multithreading to work.
What happens with member functions of structures that are being copied?
Are they copied too? Do they *need* to be copied (I guess not) ?
If not, then why implement member functions at all? Would it be more efficient (in the context of SMP) to NOT have any member functions and keep all the coding shared?

Which programming language are you talking about?

In C/C++ there's usually only one copy of each function, structures only contain the data. Unless your program is generating code at runtime (which very few programs do), there should be never any function copying.

[Sven]

A member function (in C++) is nothing that can be copied, so you don't have to worry about it. If you write e.g.

Code: Select all

struct C {
    int x;

    C();
    void setX(int x_);
};

C::C() : x(0) {}

void C::setX(int x_) { x = x_; }

int main() {
    C cInst;
    cInst.x = 11;   // accesses the data member x
    cInst.setX(47); // accesses the member function setX()
    return 0;
}

then the instance 'cInst' contains as many bytes as the size of an 'int' is, but nothing related to the member function setX(). The expression cInst.x accesses data that exists once per instance. However, cInst.setX(47) uses code that exists once per program.

Things change slightly if you talk about virtual functions. But even then, each object instance has an additional table ("vtable") containing one function pointer per virtual function of the class - but also here, the code of the function itself is not part of the instance, just a pointer to it.

Since virtual functions are rarely used in chess programming I doubt that you will have to deal with it.

Regarding your final question "why implement member functions at all": there are a lot of good reasons for it. Perhaps the most important one is "encapsulation" which means that, in a good OO design, you should not expose the internal implementation of objects but provide access through interfaces only. The common way of hiding implementation details is to define member functions.

EDIT: Some more reasons for writing member functions are:
- code that uses a class can become much shorter and also much easier to maintain;
- you can define abstractions;
- you can define consistency rules by restricting the way how data can be changed;
- by adding the 'const' property to member functions you can detect some kinds of unwanted write access at compile time (within the implementation of a 'const' member function a data member must not be modified).

Sven

[sluijten]

A member function (in C++) is nothing that can be copied, so you don't have to worry about it.

(...)

Regarding your final question "why implement member functions at all": there are a lot of good reasons for it.

(...)

Agree Sven, in this case I see only advantages of using member functions.
Thanks for explaining.

[AlvaroBegue]

When I first heard about objects, they were described as an entity that contained both the code and the data, which is just a horrible description that leads to the type of confusion you found yourself in. I'll give you different explanations for a couple of features of objects, at least the way C++ implements them.

Think of an object as being a data structure. We then define methods, which are functions that take a first argument that is a pointer to the structure. In order to invoke a method, instead of calling `my_method(&my_object, arg1, arg2)' we call `my_object.my_method(arg1,arg2)', but the difference is just syntactic. If instead of a pointer to the object we want to pass a const pointer object, we say that it's a const method. The name of this implicit first argument that is a pointer to the objects is `this'.

By the way, if you wanted to use OOP in C, you could basically just do it by passing pointers to objects as I described above.

Simple inheritance (the only type that you'll probably ever need) basically consists of having a first member of the class which has the type of the parent class. Methods that were defined for the parent class can be called on objects of the derived class, which again is not much more than syntactic sugar.