J
Joshua Maurice
Yes, you can of can. In fact, that's the only way. The only way to
define terms is by consensus or by authority. If everyone agreed on
definition X, then that is the definition of the term.
Yes, you can of can. In fact, that's the only way. The only way to
define terms is by consensus or by authority. If everyone agreed on
definition X, then that is the definition of the term.
I
Ian Collins
You're assuming his intent is to make sense and not to keep this thread
going as long as possible!
J
Joshua Maurice
But we're in comp.lang.c++, and the discussion has always been about
the C++ standard, and what object means in the C++ community. If you
want to persist in this argument: "what object should mean across
languages", I direct you to:
http://c2.com/cgi/wiki?DefinitionsForOo
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
They might care a little more for your trolling. (Well, they almost
certainly wouldn't, but I hope you see that there is a great deal of
confusion of what exactly OO means. I honestly don't care.)
That's because Java and what you would call "OO" languages are
different than C++. In C++, objects with polymorphic behavior, and
objects of user defined types, are not special compared to primitive
types as they are in Java.
For example, in Java, there are the primitive types and the object
types. (Java) object types exist only on the heap. All variables are
primitives, never objects. Such a primitive could be a reference to an
object. You can have a stack variable which is a reference to a (Java)
object, but never a stack variable which is a (Java) object.
In C++, we can talk about the parallels.
class foo {};
foo x;
This line has no parallel in Java. You cannot create a stack variable
which is a user defined type.
foo* y = new foo;
foo& z = y;
All you can do is the analogous of the above two lines. You 'new' the
object from the heap, and you have a stack variable which is a pointer
(aka Java 'reference') to the object.
In Java, there is a strict separation between user defined types and
primitive types. In Java, all variables are primitives, and all user
defined types are (Java) object types, which are allocated only from
the heap. In C++, there is no such dichotomy. All user defined types
are object types. All primitives are object types. All (named)
variables are objects, and all things allocated off the heap are
objects. There is no special magic that distinguishes between them,
unlike in Java. I can have a C++ polymorphic object or user defined
object on the stack, and on the heap. I can also have a primitive int
object on the stack, and a primitive int object on the heap.
Does this make C++ not OO? I would argue that C++ still natively
supports all of the important parts of OO, though I recognize that
others would disagree with me. Again, see:
http://c2.com/cgi/wiki?DefinitionsForOo
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
Again, do I particularly care? No.
J
Juha Nieminen
Paul said:
Care to give some actual arguments why that is so, besides the fact
that built-in types cannot be inherited from (as already stated)?
J
Juha Nieminen
Paul said:A few peole have just flown in from Mars I see.
Care to actually explain what is wrong with what I wrote?
J
Juha Nieminen
In comp.lang.c++ Paul said:
If someone told me that I lack knowledge on quantum mechanics, which is
absolutely true, why would I feel insulted? I *do* lack a lot of knowledge
about quantum mechanics. Someone stating so, especially after I openly have
admitted so, would simply be telling the truth. Where exactly is the insult?
You clearly stated that you don't know about member function pointers.
Hence, rather obviously, you lack knowledge about them. Hence what I said
was a true statement.
You are still trying to play the "you insulted me" card, probably so
that you don't have to discuss the actual arguments presented.
J
Juha Nieminen
In comp.lang.c++ Paul said:
Now you are changing your claim. You claimed in your earlier post that
"virtual function pointers cannot work", without mentioning anything about
objects. Now you are moving the goalposts and changing the claim to
"virtual function pointers cannot be called without an object", which is
a completely different statement.
If you actually *read* what I wrote earlier, I gave you the exact syntax
of how you can create a member function pointer and how you call it with
an object. Nobody claimed that you can *call* the function without an
object. What I said was that you can refer to a member function (in other
words, take its address and assign it to a pointer) without an object,
which would indicate that the function is not, in fact, tied to any
specific object, but a free function which is only tied to a specific
*class*. The function in question takes implicitly an object as
parameter, which is why you have to supply one when you call it (while
the syntax for this is special, it's in principle no different from
calling a regular function which takes an object as parameter in the
regular way).
In other words, there's little difference between this:
class A { public: void foo(); };
and this:
class A {};
void foo(A*);
(The major difference is the scope in which 'foo' is declared. In the
former case 'foo' is specifically tied to the scope of A.)
U
Ulrich Eckhardt
Paul said:
Yep, please provide a list of those C++ types that are defined outside the
C++ standard.
Interesing is also ...
...while just two postings earlier you suggest
You have claimed that objects contain memberfunctions.
If there is no well-agreed base where you draw your terminology from,
there is no guarantee either that what you say will be understood in the
way you meant it. Isn't that kind of stupid?
Not only, but discussions about the finer details of a standard should
rather be based on that standard's definitions. When talking about
precisely the C++ object model, general OOP lingo is a bad choice, see
above why it's stupid.
The standard defines C++. This newsgroup is about C++. Can you make the
connection? See also my response to your claim a) above.
Interpreting != defining
That may be so, but making claims about the content of the standard should
be made with a greater "technical correctness" than general programming
discussions, exactly because implications of precise definitions are not
easy to understand and change their meaning if you slightly change their
wording.
x is an instance of an integer type, it is not a type. That distinction
exists in pretty much any language that has a type concept even. You have
been given several explanations of this fact, but you fail to listen.
If it was, I could create an alias for that type:
typedef x integer_type;
Try it, explanations are already given above.
Sorry, pal, but the C++ standard does state otherwise.
Yes. You have been told that the C++ object model considers even non-class
types as objects. Get over it, it isn't going to change, no matter how
much you bitch and complain that it doesn't make sense [to you, that is].
I just intended to remind you of the fact that your expectation ("I would
be very surprised if..") above has been shattered multiple times in this
thread already and that you missed that. I did explicitly not want to
explain it to you again.
R
Rui Maciel
Paul said:
You got it backwards. If you claim that they don't work then you are
responsible to provide a concrete case where they don't work, so that
those interested in helping you can analyse your example and, from there,
provide an answer.
Rui Maciel
J
James Kanze
[...]
From where did you get this? In the C++ standard, functions
don't have lifetime. They just are. Only objects have
lifetime, and a function isn't an object.
[...]
Yes. The class.
Why?
You continually make assertions with no justification, which are
contrary to the actual text in the C++ standard.
[...]
Certainly. Given that in this case, object type and class are
synonyms.
One doesn't usually use the term ownership for membership, but
the function is certainly a member of the class.
Once again, you're confusing object and type. The two are quite
distinct: types exist within the compiler (in C++, at
least---other languages do evaluate types at runtime), where as
objects are purely runtime.
From where did you get this? In the C++ standard, functions
don't have lifetime. They just are. Only objects have
lifetime, and a function isn't an object.
[...]
Yes. The class.
Why?
You continually make assertions with no justification, which are
contrary to the actual text in the C++ standard.
[...]
Certainly. Given that in this case, object type and class are
synonyms.
One doesn't usually use the term ownership for membership, but
the function is certainly a member of the class.
Once again, you're confusing object and type. The two are quite
distinct: types exist within the compiler (in C++, at
least---other languages do evaluate types at runtime), where as
objects are purely runtime.
J
James Kanze
An object type is not necessarily a class type. int is an
object type, but not a class type.
Why don't you read it and see. An object type is a type which
defines an object: i.e. something other than a function type or
a reference type.
The standard needs a term for the collection of types which are
objects, as opposed to types which are functions or references.
The expression "object type" seems very natural for that.
It's vocabulary. Established by consensus or authority. In the
case of the standard, by authority: within the standard, words
mean what the standard defines them to mean. Some common sense
is expected, but given the standard's definition of object
(which, as Pete says, is that of a compiler writer), its use of
"object type" is emminently coherent.
J
James Kanze
[...]
fido has type Dog.
You cannot reasonably state that fido is an object type, because
fido is not a type, it is an object. This is just plain basic
logic.
No. The type of fido is an object type. fido is an object, not
a type.
Do you understand the difference between types (compiler
entities) and objects (runtime entities)?
fido has type Dog.
You cannot reasonably state that fido is an object type, because
fido is not a type, it is an object. This is just plain basic
logic.
No. The type of fido is an object type. fido is an object, not
a type.
Do you understand the difference between types (compiler
entities) and objects (runtime entities)?
J
James Kanze
[...]That's the compiler writers problem, not mine
From the object you call the pointer on.
Your guarantees aren't worth much, since you obviously aren't
familiar with C++. It does work, and I've done it. Several
types, with different compilers (Sun CC, g++ and VC++, at
least---although you need special compiler options with VC++ if
everything isn't in the same translation unit).
Whose point, where and when? You're just making things up as
you go along, trying to bluff your way out, rather than just
admitting that you really don't know C++.
J
James Kanze
[...]
Maybe. That's one implementation technique. In other
implementations, the pointer actually points to some other
function entirely, which then makes the virtual function call.
The important thing, I think, is that these functions (however
many) live independently of any objects.
P
Paul
Garrett Hartshaw said:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Garrett Hartshaw said:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 08:55 PM, Paul wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 02:06 PM, Paul wrote:
[...]
I can understand the concept you express but
a) how do you get the address of a member function?
&ClassName::functionName
Concretely:
struct C { void f(); };
void (C::*pf)() = &C::f;
b) what happens if this member function is virtual?
It works correctly. That's why pointer to member functions are
often larger than any other pointer types (but there are other
ways of solving the problem).
What would your pointer point to ?
That's the compiler writers problem, not mine
It certainly is a problem for the compiler, and perhaps the program
too.
Especially if you didn't initialised the empty pointer.
Let me put it another way, where would you get the address for the
virtual function?
You cannot do this with virtual functions and you are wrong
to suggest it works correctly.
It does work, and I've done it. More than once.
It simply can't be done as the concept of virtual functions only
lives
in the world of objects.
Please show some basic code. I guarantee you cannot.
#include <iostream>
class C1 {
public:
virtual void f() {
std::cout << "C1::f" << std::endl;
}
};
class C2 : public C1 {
public:
virtual void f() {
std::cout << "C2::f" << std::endl;
}
};
int main () {
void (C1::*p)() = &C1::f; //create a pointer to a member function
C1 a; //create a object of type C1
C1 * b; //create a object of type pointer to C1
The challenge put forward was to invoke a virtual function without
creating an object. Here you have created an object.
I applaud your abilities nonetheless, assuming the code is correct.
b = new C2(); //allocate a object of type C2
(a.*p)(); //call the member function pointed to
//by p, with &a as this
(b->*p)(); //call the member function pointed to
//by p (virtually), with b as this
return 0;
}
This code prints the following.
C1::f
C2::f
The very nature of virtual functions require objects and perhaps you
have demostrated this.
This was what i was referring when I initially stated 'it won't work
with virtual functions':
"You can take the address of a member function (and assign it to a
function pointer of the proper type), and it will *not* be tied to any
specific object."
The (virtual) member function was *not* tied to a specific object, as it
(the same function) was used by two different objects. If it was *a part
of* the object, you would not be able to have a pointer to it.
With:
(a.*p)(); //call the member function pointed to by p, with &a as this
(b->*p)(); //call the member function pointed to by p (virtually),
with b as this
There are two functions here.
As I understand it you seem to think there is only one function . ????
Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object). However, if we had another object of (dynamic) type C2
(e.g. C1 * c = new C2(); ), and call the function ( (c->*p)(); ), then
we have 3 objects ( a, b, c ), and only 2 functions ( C1::f, and C2::f
). This would not be possible if the function itself was part of the
object.
No, you cannot use a virtual function without an object.
A virtual function is basically a pointer that exists within an object, a
virtual function never actually exists as a function hence *virtual*
function.
It is impossible to invoke a virtual function without the existence of an
object. The object contains the pointer (that is the virtual function).
Hope this makes sense to you.
Some peope are obviously confused between a precompile time entity(class)
and an object.
A function is not contained within a class anymore than it is contained
within an object, with:
wanda.blowBubbles();
This statement contains an object and a member function, there is no class
here. This member function does not exist until it's invoked on an object.
The function is exclusively tied to the object, (*not the class*), the class
is stored on some file on an old dusty computer on the other side of the
world.
After the code is compiled a class no longer exists , a class is a
precompile time entity in C++, a class in C++ is not the same as Java class.
I don't know what is wrong these people who cannot understand this , they
are obviously very very ignorant and confused, please don't be one of them
P
Paul
I don't know what type of implementation you are trying to define here, butLeigh Johnston said:Garrett Hartshaw said:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 11:35 PM, Paul wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 08:55 PM, Paul wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2011 02:06 PM, Paul wrote:
[...]
I can understand the concept you express but
a) how do you get the address of a member function?
&ClassName::functionName
Concretely:
struct C { void f(); };
void (C::*pf)() = &C::f;
b) what happens if this member function is virtual?
It works correctly. That's why pointer to member functions are
often larger than any other pointer types (but there are other
ways of solving the problem).
What would your pointer point to ?
That's the compiler writers problem, not mine
It certainly is a problem for the compiler, and perhaps the program
too.
Especially if you didn't initialised the empty pointer.
Let me put it another way, where would you get the address for the
virtual function?
You cannot do this with virtual functions and you are wrong
to suggest it works correctly.
It does work, and I've done it. More than once.
It simply can't be done as the concept of virtual functions only
lives
in the world of objects.
Please show some basic code. I guarantee you cannot.
#include <iostream>
class C1 {
public:
virtual void f() {
std::cout << "C1::f" << std::endl;
}
};
class C2 : public C1 {
public:
virtual void f() {
std::cout << "C2::f" << std::endl;
}
};
int main () {
void (C1::*p)() = &C1::f; //create a pointer to a member function
C1 a; //create a object of type C1
C1 * b; //create a object of type pointer to C1
The challenge put forward was to invoke a virtual function without
creating an object. Here you have created an object.
I applaud your abilities nonetheless, assuming the code is correct.
b = new C2(); //allocate a object of type C2
(a.*p)(); //call the member function pointed to
//by p, with &a as this
(b->*p)(); //call the member function pointed to
//by p (virtually), with b as this
return 0;
}
This code prints the following.
C1::f
C2::f
The very nature of virtual functions require objects and perhaps you
have demostrated this.
This was what i was referring when I initially stated 'it won't work
with virtual functions':
"You can take the address of a member function (and assign it to a
function pointer of the proper type), and it will *not* be tied to
any
specific object."
The (virtual) member function was *not* tied to a specific object,
as it
(the same function) was used by two different objects. If it was *a
part
of* the object, you would not be able to have a pointer to it.
With:
(a.*p)(); //call the member function pointed to by p, with &a as this
(b->*p)(); //call the member function pointed to by p (virtually),
with b as this
There are two functions here.
As I understand it you seem to think there is only one function . ????
Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object). However, if we had another object of (dynamic) type C2
(e.g. C1 * c = new C2(); ), and call the function ( (c->*p)(); ), then
we have 3 objects ( a, b, c ), and only 2 functions ( C1::f, and C2::f
). This would not be possible if the function itself was part of the
object.
No, you cannot use a virtual function without an object.
A virtual function is basically a pointer that exists within an object,
a virtual function never actually exists as a function hence *virtual*
function.
It is impossible to invoke a virtual function without the existence of
an object. The object contains the pointer (that is the virtual
function).
You are wrong yet again; you obviously do not know C++. The address of a
virtual function is contained within a vtable; it doesn't exist within an
object; all that exists within an object is a pointer to the vtable if the
object is of class type and the class contains at least one virtual
function. Objects do not contain member functions (virtual or not);
classes contain member functions (virtual or not).
on my implementaion a function is a process that begins when an instruction
is loaded into a cpu register,
A function is normally invoked on the stack and uses stack pointers and/or
offsets to reference any objects within its scope.
A virtual function is a psuedonym for the function that is represented by
the pointer inside the object.
A virtual function does not have an address, a function is not a region of
memory as you seem to think.
A class is a precompile time entity, a function is a runtime entity.
To suggest that a function belongs to a class is complete nonsense, becuase
the class does not even exist when the function is invoked.
You seem to be talking about a function definition , not a function.
This is C++, not Java!.
Utter bullshit.
Functions exist in a cpu not in a region of memory.
An object is a region of memory, a function is not a region of memory.
And remeber an object is definately not a function
Please don't state I am wrong *again* as if I have previously been proven
wrong about something .
It is apparent you have strange ideas about functions living in memory and
it is indeed more likely to be you that is wrong.
The level of intelligence displayed by your insult is your problem.
G
Garrett Hartshaw
In the phrase object type, object is a adjective that modifies the
noun type. Therefore, when you said that 'fido is an object type', it
was read the same as 'fido is a type. That type describes an object',
not, as I think you meant, 'fido is an object'.
P
Paul
Leigh Johnston said:
The function calling mechanisms for any given implementation is *obviously*
not defined in the standards.
The point here is that you seen to have eaten a book that contains the word
'vtable' and now you are an expert on the function calling mechanism for
all implemenmtations.
Most of your babblings about your idea of how things work on some
implementation of yours, is pretty irrellevant.
But there is one important point, that the object contains a pointer to the
function, whether it be a direct or indirect.
The important point here is that an OBJECT contains the pointer, not a
CLASS.
P
Paul
James Kanze said:
The functions are not independant of the objects as James incorrectly
states. The important point is that the object contains a pointer to the
function, whether direct or indirect.
When a function is invoked it exists within a CPU. I don't know what James
is confused about but he seems to think a function is a region of memory or
something. Maybe he thinks C++ has classes in the same context as a java
class because he seems to think the function is part of a class.
In C+ a class is not a runnable entity, a class is basically a set of
declarations grouped together in precompiled code.
The object is the entity on which the member function is invoked, not the
class.
G
Garrett Hartshaw
Actually, 'x' is both an integer and an object. 'int' is both an
integer type (type that describes an integer) and object type (type
that describes an object).