Frasncis Glassboro wrote.

J

Joshua Maurice

A dog type IS an OBJECT TYPE?

HOW CAN FIDO BE AN OBJECT BUT NOT AN OBJECT TYPE??????????

Correct. Fido is an object. Fido is not an (object) type. Dog is an
(object) type. Fido is of (object) type Dog.

The colloquial "is a" English phrase is not transitive. For example, a
stop sign is red, and red is a color. However, a stop sign is not a
color. Equivalently, Fido is a Dog, and Dog is an (object) type, but
Fido is not an object type.
 
P

Paul

A dog type IS an OBJECT TYPE?

HOW CAN FIDO BE AN OBJECT BUT NOT AN OBJECT TYPE??????????

Correct. Fido is an object. Fido is not an (object) type. Dog is an
(object) type. Fido is of (object) type Dog.

The colloquial "is a" English phrase is not transitive. For example, a
stop sign is red, and red is a color. However, a stop sign is not a
color. Equivalently, Fido is a Dog, and Dog is an (object) type, but
Fido is not an object type.
..................................................................................
This is not an accurate comparison. If you were to say sign were types as in
green type signs
red type signs
blue type signs
Someone could phone the roads dept and order 20 signs , you know the green
type.

Fido's type is not actually a real Dog , its a type of computer variable(for
lack of a better word).

The variable is fido and fido is an object type or Dog type varaible , he is
not a real fuckin dog.
 
G

Garrett Hartshaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Kanze said:
[...]
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?
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJ5fwAAoJEO0SzzQOdchN7x0P/j9jO/ptm/i8ir1LzUI9WhpN
P1n/A3rjYALl3i6oj/+MzE91+yuWcPgA0raXHnHITUDldfg9IdDXq0x8M/hDupWG
nrvGCOEmkXmHWn6cw6lMgGS9TlGtyvWcR9wcDAAC2Zq/b6NcctSWKWbWhSOiJ5Im
zC3mx0b4n+lh22S78nCHLy+9Nsx2+3Czmrwjo5D6X4kI4uUQ837NwMuEIf0w5Wlt
rDCxg0/694yukocZomnaOveZJNt8GXVcwrQQEdI4o87CVGTKWLLNLzXN8F8Aa7vr
QpdZrL8U7PyTBofQNoHUzFJDuIkBno7zWGNR7Y3Ql9yu8fhx9MHubTvv4mfUrTab
gM5vj2HmLI00EflOhpczx1EN9McBvWOga+CPoetzf0ovauO/n2aOjhrAkeGMYKZY
dmVmrSyhXnCaGw2SfhWduRn2aY/yMOUdEoT28/MFI1ruNWj6DKyOtvJiKm3MB3Za
+5u5yO/XH2+CZIpXhCEQrYi6wwIAzv1pfMGhUV2tylO/ZSiP0toItZr3vm7JuBEK
8TSs+KvmLeJ+97XmThfPoPWMThHfLXmLqy/3WasmvDkTdiIrI1brf0gugQuAugHw
xjfcfzrRGtm6yaL8CSlAlqb/vmJiafi8m6Qjju1WuJTtaS+YQGAP5gAdQ2a2W3/S
FbMuQtdtJm6baWiB455Z
=u89w
-----END PGP SIGNATURE-----
 
S

stan

Paul said:
"Juha Nieminen" <[email protected]> wrote in message

The fact that you have began your posting with a direct insult to me leaves
me no other opinion than you are actually nothing more than an other
clueless idiot who has nothing more than an UNREASONABLE argument to put
forward.

"No other opinion" would seem to suggest that our opinions, or more
precisely your ability to form an opinion, are limited. I find that
somewhat surprising because your performance to date suggests that you
are indeed exceptionally skilled at forming very strong opinions. You
have persistently denied any limits to your abilities or knowledge,
yet here you appear to concede a minor point. Typo?
 
G

Garrett Hartshaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You cannot have an object of type class.

With:
Dog fido;

fido is not an 'integer type'
fido is not a 'double type'
fido is NOT a 'class type'
fido IS an 'object type'

You will always remain confused if you think an integer and an object is
the same thing.

Your problem is that you obviously seem to think that programming should
be discussed in the same context as the standards. As I have said to you
before this is very narrow minded.
It is also innaccurate and incorrect to quote things out of context , as
you reapeatedly do.

fido is *not* an 'object type'
fido *is* a 'object'
Dog is a 'object type'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJ5sfAAoJEO0SzzQOdchN7WkP/AhugBgBIeoNax/eHR3p9w5k
Fyg1bqewuvP/FQzZ+NGC+iCU1hXiRvGQARJe/b56OguErjYhTSBvk/FHWUflFKe3
NaML8e5KOTyQ18peI2YcjWT2yVRS2J2G5lYcRD9jHSQvzO1gYIiW8duC2moPXgEJ
n8ixECrfuOAA0+l4ZX+NqYrUSIiQJjUUyBmEyrE4fW4MQyF7hEjKQdcyXbiwRo1q
O3X/8hNhaWc8WAVzHwheFH0D/2D9XbefwCJygAsSyK/yZEa52N7bjFDG2Bq8PeKN
Oty1Kn+Ko6AEq+S1+c5iPFTHT7QFpGFjRKtMZ1IhyGNMNA4Ho3CFV3hqM9KcL+6G
5cSnHjC0Y6zzGGTJsy/KJhPa9jQqaNNNfyAX4ZS60Mw9O2FRg+zGJt1uIcWr9Ehx
pnDaEIdq5RJh+kE1O4HAbcEFxG1loOSSGIQVM5vnjVDft/xrfIlcV087ZvoFd84w
LP3kEGbqpaghxD9rf50SAzFdcZEliXHTylNSx6eLGE9j2dLwNHCFu567nKm9B/kI
UoUwIhG3jF5Epcjtdm/GZZfGcZusQnmH8CXw8J2pWn4uKxqg3DPlPpOodYFTNr5y
e/mxS97Pm1rYQz/FrAxT8sXSG/1/TBV77PYpHK4nLh6Dok856WTySCpi483ewVzM
ii0wyYzk+pb/gGKOl6PI
=v3tX
-----END PGP SIGNATURE-----
 
P

Paul

Pete Becker said:
For some meaning of "ownership". Usually that means that the owning object
manages the lifetime of the owned resource. That's definitely not the case
for C++ member functions. There's (typically) one copy of the code of a
non-inline member function, used by all objects of the corresponding type.
The code lives in the code segment from program startup until program
termination. Even if no objects of the corresponding type are ever
created. That's a pretty thin meaning of "ownership".

A functions lifetime begins when it's invoked and ends when it returns,
there may be exceptions to this but this is generally the case.
Objects(in the context of variables etc) within the scope of the function
can only exist while the function exists, but these objects do not live
within the functions code segment.
I wouldn't say the function 'manages' their lifetime but I do think the
existence of these objects is dependant on the existence of the function.
Do you think it's fair to say that these objects are 'part of the function'
or 'owned by the function' or 'within the function' or anything along these
lines that imply they can only exist during the lifetime of that function?

Now consider two functions being invoked for two different objects at
exactly the same time, although there is only one piece of function code in
the programs code segment.
We have:
frisky.Meow(); // running on thread1
oscar.Meow(); //running on thread2

frisky.Meow() cannot exist unless frisky exists. Therefore there could be
some sense of ownership.
The objects inside frisky.Meow() only exist while both frisky and
frisky.Meow() exists.

Note: I said the objects *inside* frisky.Meow(), some may disagree with this
as the objects are not actually stored in the same program segmen, stack or
register or wherever they happen to be stored.

oscar has no idea what is going on here BTW.

so a typical process tree can be as follows:
[Program strarts]
[Program creates frisky] [Program creates oscar] objects exist
simultaneously
[frisky.Meow() is invoked] [oscar.Meow() is invoked] invoked simultaneously
[frisky.Meow() does its thing] [oscar.Meow() does its thing] Each process
goes off and does it own thing.

The term 'member function' implies it's a member of something.
You cannot seriously say it is a member of the code segment.
You cannot say it's a member of a class yet not a member of an object
because this would imply its a static function. Also given the argument that
the functions code is not actually in an object the same can be said for a
class.

If a member function is declared in a class, then surely it's a reasonable
interpretation to say that the object type is defined to 'contain' a member
function or the member function is deifned to be a member of that object
type.
Or something along these lines that imply ownership of that member function.

It is more correct to say it is a member of the object. And this seems like
the ONLY fitting explanation.
 
P

Paul

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Kanze said:
[...]
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."
 
S

stan

Paul said:
What part of "you lack such knowlege of the language" do you not understand
to be an insult?

Don't bother replying because I'll just tell ya to **** off anyway.

Control issues?
 
S

stan

Garrett said:
On 01/07/2011 02:06 PM, Paul wrote:


#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
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

Did you hear that? Sounded like "I'm mmeelllllllttttting"
 
P

Paul

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


fido is *not* an 'object type'
fido *is* a 'object'
Dog is a 'object type'

Dog is a class
More fully:
Dog is a class,that is the definition of an object type.

If fido is an object, and Dog is a class
How can fido be a Dog , because an object is not a class?

You can juggle these terms around till the cows come home.
But you cannot state that "fido is *not* an object type" because fido is an
object type in the same sense it's a Dog type'

Consider someone asking the question , what type is fido?
You could reply ... fido is an object type.


You are changing the context :
Dog fido;
to
type-name identifier;

You can say that the identifier fido is not an object type, but then its not
an object either because you have defined it as an identifier.
You implicitly imply a new context.
:)
 
G

Garrett Hartshaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[...]
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJ9I/AAoJEO0SzzQOdchNNt8QAIt7B8Hfsc+2iYiN1wanHNxQ
2rWmra66snapd+37ZO3efBkuaBEpggJrwiGYr7zmRV6+kmGSff0f5HoITBQxv0wP
IR9AahmQdD0bBRDpMXFM+W2TW/2BFCIfYxxNkHe7PZaiKYOhSCBsIcOEH7kc87YZ
dOYVtdEYQrLVyBF+cJhIZgCt8zfbhMUi24c0qwrdsC/ZLdTmWfPqnCRKgUw5bcuy
3UPygLpq+9LEsUUzW/VpG/CnNGj6Ftke+2xXVJFcJsEtb8YWQLHJEy0F3xqRperP
HBN5Bt1kiLN/NBmy9d+3nUsvBf5T6PHGtoPvgABIOORD2uUD+8Nk1bpKqHvYN6O8
pXRUdnkdRhiAPpjNKpAQ9ofcnkwbHbyq5+clEPCdf734vuea2aK+Llt8rLFcEqsC
w5NDbrQ5/4lFxQPRushBZqxDaSgCW33w+YEtBmrQIx8BYC63Dx6sDPKyQBfgBZDj
xr/Os/y1zPVFQS3waG5a+GO2bsduUqFBVNNkoFmvvIqeXoES/hUTrkfmD6T8UasY
dSbwihNm+QL8Tx/iNQ95KwWC5C6XrOrgXfR23DwbQOtw6Sehzcx7pldE/O9F4GAF
a98GPBZd1gat4m6ON+oj68yOudXJurjjDEb+s2DQHgwHgasIld1LMoy+IbXtBosT
twwDeuyGBgd0PRLaOi7e
=d+WZ
-----END PGP SIGNATURE-----
 
G

Garrett Hartshaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dog is a class
More fully:
Dog is a class,that is the definition of an object type.

If fido is an object, and Dog is a class
How can fido be a Dog , because an object is not a class?

You can juggle these terms around till the cows come home.
But you cannot state that "fido is *not* an object type" because fido is
an object type in the same sense it's a Dog type'

Consider someone asking the question , what type is fido?
You could reply ... fido is an object type.


You are changing the context :
Dog fido;
to
type-name identifier;

You can say that the identifier fido is not an object type, but then its
not an object either because you have defined it as an identifier.
You implicitly imply a new context.
:)

Fido is a *instance* of class Dog.
The identifier fido is an identifier.
It identifies a *object* of type Dog.
The type Dog is an object type, because it is a type that describes an
object.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJ9LaAAoJEO0SzzQOdchNUa0P/38cvqIp35iF5Pq9G/RY5l6o
Hoyhgbh1/Puq9kuhfund/oiYyL5dCUNz1XhyuRUbcVoHVUks2bEL98DMaMEdODeo
0oKH+DnmWc4hSk1EwqXpnERCe6hyZri3vbYOZZx4Y3FYXgIkN6VUhnXrVFyzA+8/
FLB0zsexnydWicE7+e2EHnT0BtSpxzRjpH3f9OcfL4vOG6M7rFN1V7the0ePkfPn
+dv8d46khpkziV7VBo85CJy0IF0Vfvbfxsr2IYenQo+jVK9BQzGI6N3IGnnZZaAV
S8ozOiDdvxan98odxAEt2P3I1YcDJ0IFYc2Ix63FDzn0reLrh1SXtcEME52Sr3e6
IIwkbTVH5deZUVnYmRTUQSiIrMXF3xW2hl37lVVfLNiHrqTiXIFwQwrB98A4pbVM
IrbTgx4e1g74Iti86ELHGYtkWbzOVIaMpmpNS78du0yN0BdIyu4gn4gGYF9jr+z+
IyEN+dxU7ORqee1Dg34iHcU0gK0i4sIe0IcJLxCsemYGAF54p/rIVDgM8FBA7dd9
xSdHz8kM3RGj4oCAEOIWNwEVBuVGwLGzSq6y9EuwMmoext6BkBgewSJmv94kEdrM
MYx2SFS/LKKOR5QBuH2rKk80I2aTfDhPpfKlg52eJbi98uJhQeeVLpaExyKmkATM
cOyuZbikLw5VhYkS/r7+
=NivO
-----END PGP SIGNATURE-----
 
U

Ulrich Eckhardt

Paul said:
Yup so outside the context of the C++ standards , which is where we are
here.
A built-in type is NOT an object type as defined by its respective
class.

What is a built-in type outside the C++ standard? Nothing. Python has
built-in types like int or boolean, and they both have a class and can be
inherited from. Either you stay inside the C++ context, and then the C++
object model clearly conflicts with your claims, or you don't, then
reality proves you wrong.

I would be very surprised if the standards described a built-in type as
an object type

Region of storage, remember? I'd say this matches the an int matches the
object definition pretty well.
 
U

Ulrich Eckhardt

Paul said:
Consider someone asking the question , what type is fido?

The question is already wrong. You mean "of what type is fido?" or "what
is the type of fido?" or "what is fido's type?". For most conversations in
real life, this distinction can be ignored and the actual meaning inferred
from the context, but for a standard or a discussion about one this is
inappropriate, since the distinction between a type and an object is
necessary there.

You could reply ... fido is an object type.

No, it's an object, not a type, let alone an object type.
 
P

Paul

Leigh Johnston said:
No you said that member functions are part of objects which that are not;
member functions are part of classes. A vtable pointer only relates to
virtual member functions and not all member functions are virtual.


In C++ a member function is part of a class not part of an object; this is
a fact; everybody apart from you who has contributed to these threads
created by you concurs that this is a fact.
You can't just make statements to define the C++ language as you interpret
it. You state them as a fact with nothing to support it.
If *everyone* else agrees with you it doesn't mean you are correct.


Wrong; the member function Meow() is part of Cat not part of felix.

Please note the difference between felix.Meow() and simply Meow().
My comment implies felix.Meow() belongs to felix not simply Meow(), which is
what you have said to be wrong.
Whatever the calling mechanisms, there is a connection to suggest
felix.Meow() is bound to felix. And of course the obvious calling syntax
which also implies this.
felix.Meow() has no connection(see note) to class Cat and it's certainly not
physically inside the class.

Note: felix.Meow() is a function that has been invoked for the given object
felix. Please do not confuse this with the function declaration in the Cat
class

By your theory it cannot be 'part of' something unless it physically exists
within it.
felix.Meow() does not exist inside class Cat anymore than it exists inside
the object felix.


Also with:
felix.Meow();

There is only an object and a member function in this statement.
You state that this member function is a member of a class and not a member
of an object. But that is surely incorrect as there is no class in this
statement.
A class is not an object, so where does your class come from?








You couldn't be any more wrong.

oscar.Meow() is a completely different function than felix.Meow().
They do not exist in the same process.

You provide no argument or evidence to suggest otherwise.

Is this a last resort to escape from the argument without:
a) admitting you were wrong.
b) risking the possibility of showing your true level of knowledge.
c) having to accept the fact that you are not in the majority, when it comes
to the wider programming community.
 
P

Paul

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Garrett Hartshaw said:
-----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 . ????
 
G

Garrett Hartshaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJ/FsAAoJEO0SzzQOdchNkDAP/1Grv4JS8ytSK9QwAC5LYzRg
rAIIUWTmqfffisXZDP4URiJ6tXxu2FPcBtibr11q3s1xj96EKU08Wq3HsejeIsxk
r85Zu4WFIg1mo9VbOCd89Dqmt1TH1nqV1jyNB3H2Bj3fl5ZffAY0oIpwRSs1rRQi
dh2qurUz0ZLe3YY3Md4GNXqKqlBHH0eJm6Hagp6pzuqsRLNmCyxXFU8bxNzZJ3iX
eMAnZuLPMoKgK88LKx4h48eAp12HU1E1YZ9ycEeRp9Id/EFo3Ia1os5VGTacVHjw
tA7bZl/FDJEq21KCrRP7CZzdPLY6VIqzmN5EB6LprFfDE+7NDR2V+AxJ7P7KX9DR
3G+Tml/K2IPu7rhKc2Of4JlTfpFtBO22vX10g3GxmfIqKZpyeCyuug7CaaR+1DYI
ZcxxdnQLiFB7M6npTlLg8GiXNwO5DBXDMPcV8U9ZqEw0DJ/chOcLJxfnFR5/4RfQ
lufFSTI1vdpUlck4F7+wvPkJAHnWeNXW33DSYjlznMH8MbI4a5TkzhK1SnoK31rb
CVSizXZqo0j85cb3NxDTIA7nU+A4Zi5JAyBkeT0So1ThwmtgVIKwUTWCUz7c/8kU
Yz2IOHschxQtm2b8BUu4HoHPoVWcbpO3lWQflHKTHSZNm8l8hz8GSF0rGDIZxjXi
51WvaYzdoWQSJfrBNkNM
=d/p5
-----END PGP SIGNATURE-----
 
G

Garrett Hartshaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You can't just make statements to define the C++ language as you
interpret it. You state them as a fact with nothing to support it.
If *everyone* else agrees with you it doesn't mean you are correct.




Please note the difference between felix.Meow() and simply Meow().
My comment implies felix.Meow() belongs to felix not simply Meow(),
which is what you have said to be wrong.
Whatever the calling mechanisms, there is a connection to suggest
felix.Meow() is bound to felix. And of course the obvious calling syntax
which also implies this.
felix.Meow() has no connection(see note) to class Cat and it's certainly
not physically inside the class.

Note: felix.Meow() is a function that has been invoked for the given
object felix. Please do not confuse this with the function declaration
in the Cat class

By your theory it cannot be 'part of' something unless it physically
exists within it.
felix.Meow() does not exist inside class Cat anymore than it exists
inside the object felix.


Also with:
felix.Meow();

There is only an object and a member function in this statement.
You state that this member function is a member of a class and not a
member of an object. But that is surely incorrect as there is no class
in this statement.
A class is not an object, so where does your class come from?


oscar.Meow() is a completely different function than felix.Meow().
They do not exist in the same process.

You provide no argument or evidence to suggest otherwise.


Is this a last resort to escape from the argument without:
a) admitting you were wrong.
b) risking the possibility of showing your true level of knowledge.
c) having to accept the fact that you are not in the majority, when it
comes to the wider programming community.

Just to clarify, would you say that in the following, meow( &oscar ) is
a different function than meow( &felix )?

class Cat;
void meow( Cat * );
Cat oscar;
Cat felix;

meow( &oscar );
meow( &felix );

If not, know that a member function is usually implemented as if the
object it is called on is passed as an implicit first parameter. For
example, the following does the same thing.

class Cat {
void meow();
};

oscar.meow(); // oscar is passed as an implicit parameter
felix.meow(); // felix is passed as an implicit parameter

In fact, if they are implemented the same they will both do the same thing.

void meow( Cat * this ) {
std::cout << this << std::endl; //print out the address of
//the cat
}

void Cat::meow() {
std::cout << this << std::endl; //print out the address of
//the cat (passed implicitly)
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJ/SdAAoJEO0SzzQOdchNaR0P/1m95Z1GXtpjSyjMpumwGebu
O/AuNJpesrdhxgHYob2PwwVuCYWb8LH4UpCUSUQ+vkZt5uwzJWOm7SZRWyqVlwby
QC6bu5itsvuIJev3yfm4P9hBDnN59npK34/vDKj41AGg1qSOW8u16O1xQd0cZ3pg
8p/ExvP/pHDHIYk0CwGGfZsiJaGmzqdnpLzYG6893qLP/MXr44G/m8YrSxBzSVtQ
yaYKT6jnFrJbJmilTxtpV+D2l92v4w40dVCihmIrdeqoC+DzFz4ViQDwudKj3iuy
4OAyqMgNftDVAP3UpCaR8SqhedrxHdFwVcojrIZ+wp7bYTXD1ommxIKjxwQ6Wka7
PsrgIyg3uKPDd2Wkq0UINfAJEWaFx1P/GcJuYk3xiMYzNemagNQ9uq9zvdws2V5Q
mHJxbRYPb5rc9A1T/i72ViMRS+/cH5iQEYPWz/jSektp7UOQPC/L2HWxJa7wXUil
kcXi2NK5ku6viStvujRiADf/UJZIYafLHtENawfNj00PSL5wJlwR/aV7T1asPT11
Pn96RnIWIOv1s8ppUfXeFJeliaqScLezAlCDEf4IBsVdDU8YC6Tt5V6FP2zxVLBs
XxcqPCRVDJMi6O5N79U9oh5YFq68XVDVeX9URc5qvah1dR0T3OOByNdTyBb9Nr1o
GySGi8TK1ZEcJNmYdn9E
=vBPx
-----END PGP SIGNATURE-----
 
P

Paul

Ulrich Eckhardt said:
What is a built-in type outside the C++ standard?

Do you want me to list all the C++ built-in types ?
I could easily just link you any upto date C++ tutorial.
Nothing. Python has
built-in types like int or boolean, and they both have a class and can be
inherited from. Either you stay inside the C++ context, and then the C++
object model clearly conflicts with your claims, or you don't, then
reality proves you wrong.
We *are* staying in the C++ context , you are the only one who is suggesting
otherwise.
What *claims* have I made that the C++ object model conflicts with?

The standards are written in a context that is to define the C++ language.
I am certainly not here to try and define the C++ language, therefore I will
not be attempting to write in the context of the standards.
Alot of people around here seem to think:
a) there is some rule that states we can only speak in the context of the
standards
b) any words used in the standard , will also be used be used in same
context here.
c) they are capable of defining the C++ language, when they're not.

People do make mistakes and can find the standards confusing, which is a
good reason why we don't speak in that context when having general C++
programming discussions

For example with:
int x;
Its too easy for people to say x is not an integer type because the standard
says an integer type is an object, or whatever argument they put across.....
.. They think because they are speaking in the context of the standards they
must be correct.
Obviously x *is* an integer type. To suggest the standards would state
otherwise is completely ridiculous but this does actually happen. These
people usually quote some text out of context, which is an indirect
misinterpreatation of the standards. There are quite a few direct
misinterpretations too.

The standards have to be interpreted correctly to be usefull.

Region of storage, remember? I'd say this matches the an int matches the
object definition pretty well.
Are you suggesting the standards describe a built-in type as an object type?
or just implying it might do in some round about way?
If you are trying to raise some sort of argument here about built-in types
please make it clear what you are trying to say.
I'm not afraid to enter a discussion on this and *if* I'm wrong about it, I
won't be afraid to accept that. Can you say the same ?
 
J

Joshua Maurice

If fido is an object, and Dog is a class
How can fido be a Dog , because an object is not a class?

"If a stop sign is a sign, and red is a color, how can a stop sign be
red, because a sign is not a color. "

There. That makes about as much sense as what you just said.

A stop sign is a sign. A stop sign is red. A sign is not a color. Red
is a color. A stop sign is not a color. The "is a" English phrase is
not transitive.

int x;
x is an object. x is an int. int is a type. Specifically, int is a
type which describes objects, aka an object type. Moreover, int is a
primitive type. Objects are not types. x is not a type. x is not a
class. x is an instance of a primitive type. x is an instance of int.
x is an object of type int.

class foo {};
foo x;
x is an object. x is a foo. foo is a type. Specifically, foo is a type
which describes objects, aka an object type. Moreover, foo is a class
type. Objects are not types. x is not a type. x is not a class. x is
an instance of a class. x is an instance of foo. x is an object of
type foo.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top