Is function copy possible?

[WaterWalk]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

Don't consider optimization or performance,
1. Is such an implementation possible?
2. Does such an implementation conform to the ISO C++ standard?

 

[Ian Collins]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

Don't consider optimization or performance,
1. Is such an implementation possible?

You could be describing JavaScript, where functions can be used as objects.

2. Does such an implementation conform to the ISO C++ standard?

No, for one, how could you take the address of one of these object's
member functions?

 

[WaterWalk]

You could be describing JavaScript, where functions can be used as objects.


No, for one, how could you take the address of one of these object's
member functions?

Member function address can still be calculated by adding the class
object's address and the member function offset inside the object.
When calling a function ,just put the function starting address into
the instruction register.

 

[anon]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

Don't consider optimization or performance,
1. Is such an implementation possible?
2. Does such an implementation conform to the ISO C++ standard?

This is possible if you have a function pointer in a class, and you call
it from a class member. Deallocating a class object, you deallocate this
function pointer.

Is this what you had on your mind?

 

[anon]

Member function address can still be calculated by adding the class
object's address and the member function offset inside the object.
When calling a function ,just put the function starting address into
the instruction register.

LOL
I would like to see someone actually using this.

Can you write an example?

 

[WaterWalk]

You could be describing JavaScript, where functions can be used as objects.

Member functions in my imaginary implementation need not to be like
those in JavaScript. I mean, member functions can be copied
implicitly, and thus is opaque to users. Users don't know functions
are copied for each class object.

 

[WaterWalk]

This is possible if you have a function pointer in a class, and you call
it from a class member. Deallocating a class object, you deallocate this
function pointer.

Is this what you had on your mind?

Not exactly. I mean the whole function body is copied, not the
function pointer.

 

[WaterWalk]

LOL
I would like to see someone actually using this.

Can you write an example?

This is just an imaginary one. I don't know if it's possible and
conform to the c++ standard.

 

[anon]

Member functions in my imaginary implementation need not to be like
those in JavaScript. I mean, member functions can be copied
implicitly, and thus is opaque to users. Users don't know functions
are copied for each class object.

Oh sorry, I completely misunderstood you. In my imaginary c++ standard,
thats exactly what happens.

 

[Matthias Buelow]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

Don't consider optimization or performance,
1. Is such an implementation possible?
2. Does such an implementation conform to the ISO C++ standard?

I'm not a C++ language lawyer but this should be possible; you can only
take a pointer to a static member function anyway (one that doesn't need
a hidden pointer to the object). An advantage of your model would be
that one could omit this implicit object pointer for all member function
calls; then one could also take the address of any member function
without any trickery; the huge disadvantage of course would be that
every class instantiation would have to allocate the functions (code) on
the heap; if you only have a few objects and a low instantiation rate,
this might be ok but if you have many objects or a high instantiation
rate, it might quickly become prohibitively expensive.
Some programming language implementations dynamically allocate new
functions on the heap (e.g. if you create new functions at runtime) but
usually not methods for every object instantiation (if such a mechanism
exists) because of the above-mentioned space/time performance.

 

[Guest]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

Don't consider optimization or performance,
1. Is such an implementation possible?
2. Does such an implementation conform to the ISO C++ standard?

I can see no reason why this should not be conformant, the standard does
not tell you how the programs should work, just how they should behave.
Of course there is no practical use for such a scheme since the objects
are not allowed to change the functions in any way, which means that you
would waste a lot of memory on multiple instances of code for the same
function.

 

[James Kanze]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

Don't consider optimization or performance,
1. Is such an implementation possible?
2. Does such an implementation conform to the ISO C++ standard?

The standard only describes the behavior of the program; it
doesn't say anything about how the implementation obtains that
behavior. Several aspects of the behavior, however, could make
such an implementation difficult, for example, the fact that all
&Class::function must compare equal, regardless of from where
they were obtained.

Pragmatically, such a strategy would increase the size of
objects enormously, for no gain; it would also mean that the
layout of std::complex<float> could no longer be compatible with
Fortran, which would be a killer for scientific applications.
It's senseless to discuss it much, because it just isn't
reasonable.

 

[James Kanze]

You could be describing JavaScript, where functions can be used as objects.

That's true in a lot of interpreted languages, I think. (It's
certianly the case in lisp and the lisp dialects.) But it's not
quite the same thing: in such languages, the "object" which can
be used as a function is either a string with the code for the
function, or a more or less compiled version of the same.
There's still only one instance of each function.

No, for one, how could you take the address of one of these
object's member functions?

That may or may not be a problem. All that is required is that
the semantics of pointer to member be respected. And the
pointer to member function can have an arbitrary structure, with
all kinds of data, to allow it to find the correct instance of
the function. It might be more complex to implement (since you
have to guarantee that pointers to the same member function
compare equal), but I'm not convinced that it's not doable.

Another problem might be the fact that POD objects can have
member functions. You can use memcpy to copy POD objects, but
on a machine with absolute addresses, you'd have to relocate the
copy if the function contained any jumps (conditionals or
loops). Even on machines which use relative addresses for jumps
(e.g. Intel), the implementation of dense switches will often
involve a jump table with absolute addresses. (But it's
possible to avoid that as well, and many compilers have a PIC
option for position independent code.)

It would also have interesting implications for "delete this".
(But again, I can think of an implementation that could be made
to work.)

The real question is why anyone would want to do this.

 

[Juha Nieminen]

Hello. Suppose there is an implementation of C++, in which when a
class object is allocated, its member functions are also allocated in
addition to its data members. So that every class object has a copy
of all of its member functions. When a member function is called, it's
the object's copy that When a class object is deallocated, the
corresponding member functions are also deallocated.

From a technical point of view you might run into problems
implementing that. Many operating systems (such as, AFAIK, linux) do not
allow running data as code by default. Copying the contents of a
function would effectively mean that you are copying the machine code of
the function implementation to a data memory block, after which you
would need to tell the OS that that memory block is ok for execution. In
linux this can be done with a system call (which, naturally, is not very
C++ standard).
This is, in fact, how JIT-compiling works.

OTOH, what would be the point? Unless you are planning in creating
self-modifying code (not a very good idea nowadays), all the functions
would be completely identical. It would just be a waste of memory. (Not
to talk about things like cache inefficiency...)

 

[Joel Yliluoma]

Member function address can still be calculated by adding the class
object's address and the member function offset inside the object.

No, it cannot.
You seem to have misunderstood something.

When you have a class, say:

class test
{
int a;
void b() { }
int c;
};

And you instantiate the class:
test x;

What happens is NOT that you have an object with layout like this:
00000000-00000003 a
00000004-00000011 b
00000014-00000017 c

Functions are not part of the object's data.

What happens when the class is compiled, is that the code in the
program, will include a function called "test::b()" among all
the other functions, ignoring the question whether they're member
functions or not.
The class instance will only contain memory allocated
for "a" and "c", not for "b" or for a pointer to "b".

For example, say you have this code:
test x;
test y;
std::cout << (void*)&(x.a) << std::endl;
std::cout << (void*)&(x.b) << std::endl;
std::cout << (void*)&(x.c) << std::endl;
std::cout << (void*)&(y.a) << std::endl;
std::cout << (void*)&(y.b) << std::endl;
std::cout << (void*)&(y.c) << std::endl;

Assuming the complain accepted without problem,
you might get this output:
0x13508160
0xE0913500
0x13508164
0x13508170
0xE0913500
0x13508174

Which demonstrates how the function is in the same address for all
instances and separate from where the data of the instance is stored.
(The syntax for member function pointers is different
though, so it won't compile.)


*) Virtual functions are a bit different: each class instance contains
a hidden pointer to a "vtable", which is a constant structure within
the data of the program describing where the virtual functions for
this particular type are located; and the value of the pointer depends
on the type instantiated.


Disclaimer: Implementations may vary for different systems.

 

[Joel Yliluoma]

Member function address can still be calculated by adding the class
object's address and the member function offset inside the object.

No, it cannot.
You seem to have misunderstood something.

When you have a class, say:

class test
{
int a;
void b() { }
int c;
};

And you instantiate the class:
test x;

What happens is NOT that you have an object with layout like this:
00000000-00000003 a
00000004-00000011 b
00000014-00000017 c

Functions are not part of the object's data.

What happens when the class is compiled, is that the code in the
program, will include a function called "test::b()" among all
the other functions, ignoring the question whether they're member
functions or not.
The class instance will only contain memory allocated
for "a" and "c", not for "b" or for a pointer to "b".

For example, say you have this code:
test x;
test y;
std::cout << (void*)&(x.a) << std::endl;
std::cout << (void*)&(x.b) << std::endl;
std::cout << (void*)&(x.c) << std::endl;
std::cout << (void*)&(y.a) << std::endl;
std::cout << (void*)&(y.b) << std::endl;
std::cout << (void*)&(y.c) << std::endl;

Assuming the compiler accepted the code, you might get this output:
0x13508160
0xE0913500
0x13508164
0x13508170
0xE0913500
0x13508174

Which demonstrates how the function is in the same address for all
instances and separate from where the data of the instance is stored.
(The syntax for member function pointers is different
though, so it won't compile.)


*) Virtual functions are a bit different: each class instance contains
a hidden pointer to a "vtable", which is a constant structure within
the data of the program describing where the virtual functions for
this particular type are located; and the value of the pointer depends
on the type instantiated.


Disclaimer: Implementations may vary for different systems.

 

[Juha Nieminen]

Functions are not part of the object's data.

Believing that adding a function to a class will increase its size
seems to be a quite common misconception. (No need to split hairs with
adding a virtual function to a class which hadn't any, thanks.)

I think it's also one of the common misconceptions many C++ hating C
hackers have, and consequently one of the flawed arguments against using
C++.

(Quite ironically, many obsessed C++-hating C hackers will emulate
dynamic binding of structs by literally adding function pointers to
structs. Thus each added function will indeed increase the size of the
struct by a function pointer. And then they will be all happy because
they didn't need C++ for that.)

 

[Matthias Buelow]

Believing that adding a function to a class will increase its size
seems to be a quite common misconception. (No need to split hairs with
adding a virtual function to a class which hadn't any, thanks.)

Yeah but the discussion is about (hypothetically) adding a function's
_code_ to each instance, that is, copying the function itself, not a
pointer to it.

And then they will be all happy because
they didn't need C++ for that.)

If that's all that is needed in a certain situation, why not. Keep
things simple.

 

[Juha Nieminen]

Yeah but the discussion is about (hypothetically) adding a function's
_code_ to each instance, that is, copying the function itself, not a
pointer to it.

The original poster seemed to assume in a subsequent post that the
pointer to the function is stored in the object.

If that's all that is needed in a certain situation, why not. Keep
things simple.

Manually adding function pointers to structs (and manually updating
them according to "dynamic bounding") is not something I would call
simple (especially not when compared to C++).