Frasncis Glassboro wrote.

[James Kanze]

"James Kanze" <[email protected]> wrote in message

[...]

What would your pointer point to ?

That's the compiler writers problem, not mine.

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.

A virtual function calling mechanism requires an object.

Using a pointer to a member requires an object. So?

 

[Bart van Ingen Schenau]

What would your pointer point to ?

The pointer points to the member function.

You cannot do this with virtual functions and  you are wrong to suggest it
works correctly.
A virtual function calling mechanism requires an object.

It is required to work also with virtual member functions. To make
this possible, you have to specify an object when dereferencing the
pointer to a member function.

If I were to implement such pointers, they would consist of the
following:
- A flag indicating if dynamic dispatch (for virtual member functions)
is needed or not, and
- The address of the function, for non-virtual member functions, or
- The offset in the vtable, for virtual functions.

A class is not an object.

I will give you this nitpick.

To answer the question again:
'this' points to the object, of class type, that was used in the
dereferencing expression.

No object was ever declared in your code.

Once again you appear confused about classes an objects.

To me, it appears more like careless writing.

If you intend using a function as a standalone function why would you define
it as a member function of an object type. This seems like bad program
design.

Who is talking about using member functions as stand-alone functions?

Bart v Ingen Schenau

 

[Ulrich Eckhardt]

The fact that you have began your posting with a direct insult to me

It is indirect, and just an expression of an opinion about your skills or
the lack thereof.

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.

Wait, that reminds me of something....

<quote>
I had an argument with some guy [...] When he is wrong but will not, and
cannot, admit he is wrong, he can be nothing more than a wanking idiot.
</quote>

So what would your opinion of the person saying that be, other than that
he or she must be a clueless idiot who has nothing more than an
unreasonable argument to put forward?

 

[Ulrich Eckhardt]

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'

'fido' is not a type at all. Dog is a type. The first three of your
statements are right, the last one is wrong. Maybe it's just that you
don't speak or understand English well enough (your spelling shows...) but
saying "x is type y" and "x is of type y" are different things.

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

An integer is a very simple object, an object nonetheless. Are you really
so narrow minded that an object must have a class type for you?

Your problem is that you obviously seem to think that programming
should be discussed in the same context as the standards.

Who is discussing programming here?

 

[Paul]

[...]

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.

Using a pointer to a member requires an object. So?

The point was to show that a member function can be called *without * an
object.

 

[Ulrich Eckhardt]

It seems pretty clear that YOU do not support OOP.

I wouldn't say so, he has until now not made a statement in that
direction.

C++ is a language that *supports* OOP.
Real C++ programmers also support OOP.

Naw, real programmers pick the best programming paradigm for the problem
at hand, and they have more than one of them in their toolset.

 

[Paul]

[...]

You cannot have an object of type class.

But you can have an object with class type. There is no type
"class", but (when discussing C++) class can be used as
a modifier of type, to specify a subset of types (those defined
by a class definition).

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'

With "Dog fido;", fido is not a type. Period. This is more
general than C++; this is part of the fundamental vocabulary of
computer science. If you don't understand this, then there is
no hope of your ever becoming a computer scientist.

I didn't say 'fido is a type' , I said *fido is an object type*.
I could also say fido is a Dog type.

Because you don't understand , please don't suggest I don't understand.

You're the one who seems to be confusing this. "int" is a type,
not an object. (But an object can have type "int".)

An int isn't an object type, an int is a built-in type.

Are you for real? Are you seriously suggesting that an int is an object
type? LOL

 

[Juha Nieminen]

The fact that you have began your posting with a direct insult to me

How exactly is it "a direct insult" for me to find your behavior
ironic?

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.

What that makes me think is that you are playing the "you insulted me"
card in order to get yourself out of having to actually answer the
objections presented to your claims.

Perhaps if instead of playing that card you would actually demonstrate
how what I wrote is wrong, we could have a conversation. If you won't,
I can only conclude that you accept my points as valid and have no
response.

 

[Juha Nieminen]

What would your pointer point to ?
You cannot do this with virtual functions and you are wrong to suggest it
works correctly.

I find it really amusing who you are telling to that he is wrong
about C++.

If you think that virtual function pointers cannot work, care to give
an example code which demonstrates your claim?

You know, before making a claim it's usually a good idea to actually
test that the claim is valid.

 

[crisgoogle]

An int isn't an object type, an int is a built-in type.

Are you for real? Are you seriously suggesting that an int is an object
type? LOL

"int" is an object type. Any particular int (say, 'x', when defined
int x is an object. I honestly can't tell from your above statement
whether you get this or not (it's not entirely clear whether, when
you say "an int", you're referring to the built-in _type_ or an
instance _of_ that type).

If you don't get this, then you have no business telling anyone
what they do or don't understand about C++.

 

[Paul]

The fact that you have began your posting with a direct insult to me

It is indirect, and just an expression of an opinion about your skills or
the lack thereof.

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.

Wait, that reminds me of something....

<quote>
I had an argument with some guy [...] When he is wrong but will not, and
cannot, admit he is wrong, he can be nothing more than a wanking idiot.
</quote>

So what would your opinion of the person saying that be, other than that
he or she must be a clueless idiot who has nothing more than an
unreasonable argument to put forward?

Francis Glassboro was well aware of the preceding argument re: input
He is well aware of the way himslef and Francesco behaved, by that a mean
snidey arrogant comments , implying my unworthiness, etc etc.
They ganged up on me , much the same way the people gang up on me here. But
they didn't have a reason too the first time. They instigated it , not me.

If I seen such a post I would realise that it wasn't my argument and keep
clear. this is why I didn't really expect any replies.
The fact that there is a mob-rule bully-like culture has evolved from that
post I find quite amusing.
All the people who need security of being in the majority.
Its quite amusing to watch it develop, gets kinda gray and depresssing to
think of all those people negative emotions after a while.
ALthough saying that I never get bored ridiculing them as they attemp to
outwit me in technical discussions.

 

[Juha Nieminen]

"int" is an object type. Any particular int (say, 'x', when defined
int x is an object. I honestly can't tell from your above statement
whether you get this or not (it's not entirely clear whether, when
you say "an int", you're referring to the built-in _type_ or an
instance _of_ that type).

I think that the problem is that built-in types don't behave like
classes, which makes them not-quite-object-oriented.

OTOH, if you think about built-in types as classes that cannot be
inherited from (like eg. the 'final' classes in Java), they actually
have a surprising amount of class-like behavior: They have "constructors"
and "destructors" (you can actually "construct" and "destruct" an int
with the same syntax you would use with a class, including calling its
default constructor and copy constructor), and many "member" operators
(such as copy assignment and many "operator overloads").5C

The reason for this in C++ is that this way built-in types can be
used in templated code in the same way as most classes, without requiring
special separate syntax (constructing, copying, assigning and destructing
objects of these types can be done with the exact same syntax regardless
of whether they are built-in or class types).

From a syntactic point of view built-in types are actually closer to
classes than one would hastily think. (As said, the major difference is
that built-in types are 'final', iow. cannot be inherited from.)

 

[Paul]

What would your pointer point to ?

The pointer points to the member function.

You cannot do this with virtual functions and you are wrong to suggest it
works correctly.
A virtual function calling mechanism requires an object.

It is required to work also with virtual member functions. To make
this possible, you have to specify an object when dereferencing the
pointer to a member function.

If I were to implement such pointers, they would consist of the
following:
- A flag indicating if dynamic dispatch (for virtual member functions)
is needed or not, and
- The address of the function, for non-virtual member functions, or
- The offset in the vtable, for virtual functions.

A class is not an object.

I will give you this nitpick.

To answer the question again:
'this' points to the object, of class type, that was used in the
dereferencing expression.

No object was ever declared in your code.

Once again you appear confused about classes an objects.

To me, it appears more like careless writing.

If you intend using a function as a standalone function why would you
define
it as a member function of an object type. This seems like bad program
design.

Who is talking about using member functions as stand-alone functions?

Bart v Ingen Schenau
..........................................................................

I thought that was the whole point of their argument...
To express the use of a member function , without it being connected to an
object.?

If this is not the case maybe I missed something.

 

[Paul]

It seems pretty clear that YOU do not support OOP.

I wouldn't say so, he has until now not made a statement in that
direction.

C++ is a language that *supports* OOP.
Real C++ programmers also support OOP.

Naw, real programmers [snip].............. blah blah blah.

So you disagree that real C++ programmers support OOP.
That is quite clear.

 

[Paul]

Yes I already said that, why repeat it?


I never said otherwise.


I already told you that objects can contain vtable pointers in one of

No I was the one who first suggested objects can contain a reference to a
function.

the other bullshit threads you started; any vtable pointer or RTTI pointer
will be present in the object's storage region. An object is simply a
region of storage as far as C++ is concerned; you can deny this all you
want. "C++ object" is not the same as "OOP object".

/Leigh

The bullshit threads are fuelled by your bullshit argument that a member
function is not part of and object.

its simple.....

Cat felix;
felix.Meow();
//The member function Meow() belongs to felix
Cat oscar;
oscar.Meow();
//oh look oscar also has a member function Meow()

Is oscars Meow the same as felix's meow? No because each Meow belongs to a
different cat.

There is a concept of ownership between the object and the meberfunction.
If you cant understand this concept please say so and I will try to explain
further.
The fact that that the function is not actually stored within the objects
memory area is pretty irrellevant. Allthough I can see how a person of low
intelligence would be confused by this..

 

[Paul]

I think that the problem is that built-in types don't behave like
classes, which makes them not-quite-object-oriented.

OTOH, if you think about built-in types as classes that cannot be
inherited from (like eg. the 'final' classes in Java), they actually
have a surprising amount of class-like behavior: They have "constructors"
and "destructors" (you can actually "construct" and "destruct" an int
with the same syntax you would use with a class, including calling its
default constructor and copy constructor), and many "member" operators
(such as copy assignment and many "operator overloads").5C

The reason for this in C++ is that this way built-in types can be
used in templated code in the same way as most classes, without requiring
special separate syntax (constructing, copying, assigning and destructing
objects of these types can be done with the exact same syntax regardless
of whether they are built-in or class types).

From a syntactic point of view built-in types are actually closer to
classes than one would hastily think. (As said, the major difference is
that built-in types are 'final', iow. cannot be inherited from.)

A few peole have just flown in from Mars I see.

 

[Paul]

Not at all object-oriented. <g> The term "object" as it's used in the C++
standard comes from compiler writers' vocabulary: an object is a region of
memory, and its type tells you what operations you can do on that memory.

--

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.


I would be very surprised if the standards described a built-in type as an
object type anyway seems pretty stupid , confusing and unneccessarry when it
can easily be called a built-in type. But I guess all you guys seem to say
it does so I will accpet that is true.

 

[Paul]

How exactly is it "a direct insult" for me to find your behavior
ironic?

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.

 

[Paul]

I find it really amusing who you are telling to that he is wrong
about C++.

If you think that virtual function pointers cannot work, care to give
an example code which demonstrates your claim?

I am not 'claiming' they don't work without objects , I am *telling* you
they don't.

The onus is on you to show us an example of using a virtual function without
an object, since you think it works.

 

[Paul]

Paul wrote:
It seems pretty clear that YOU do not support OOP.

I wouldn't say so, he has until now not made a statement in that
direction.


C++ is a language that *supports* OOP.
Real C++ programmers also support OOP.

Naw, real programmers [snip].............. blah blah blah.

So you disagree that real C++ programmers support OOP.
That is quite clear.

Don't put my name in the subject line of a bullshit thread; you are a
troll albeit a successful one if one measures a troll's success by the
amount of garbage it outputs that generates responses.

/Leigh

This thread has been continued by you, I'm simply replying to your bullshit
aerguments.