Frasncis Glassboro wrote.

[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?

From the object you call the pointer on.

Then you are calling the function on an object.
You can't have a virtual function without an object ,end of story.

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).

The fact that you cannot provide code to suggest what you claimed proves the
opposite. And it suggests that your claims are pretty weak and innaccurate.

 

[Garrett Hartshaw]

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.

The answer to that question is that fido is not a type, it is an
object. Fido is *of* type Dog. Dog is a type that describes an object
(object type).

 

[Paul]

It was an indication that I am fed up with your trolling nothing more. As
far as a) is concerned you are the one who has been wrong multiple times
in these threads you have created; as far as b) is concerned my level of
knowledge has been revealed multiple times by my postings and as far as c)
is concerned I am in the majority of posters in these threads of yours who
are actually understand the concepts involved unlike yourself.

/Leigh

You have been proven to be incapable of a reasonble discussion in C++,
without making incorrect definitions.
I don't give a shit if you are in the majority .

You have defined member function as part of a class and not an object..
A class does not exist when a member function is invoked therefore you are
technically incorrect.

If you were speaking about 'function definitons' there *might* be some sense
of an argument on your behalf
How can a member function be part of something that doesn't exist? duh

definition of you = idiot!

 

[Paul]

I never said otherwise.


Not irrelevant to these bullshit threads of yours unfortunately; why? we
have to hold your hand and give examples to try and explain things to you
(without success so far).


Wrong yet again. Objects *can* contain pointers to vtables so
*indirectly* contain pointers to virtual member functions. Objects
*never* contain pointers to non-virtual member functions (directly or
indirectly). It was me that pointed out the difference between virtual
and non-virtual member functions and vtables to you (on more than one
occasion).

What I said was true for a VMF and correct in that context.
You have applied what I said,out of context, to a Non-VMF and claimed it as
inccorect.

Once again you demonstrate your tendancy to misinterpet words

 

[Juha Nieminen]

You can't have a virtual function without an object ,end of story.

You don't seem to understand the difference between "having a virtual
function" and "calling a virtual function".

Maybe you should learn English before you learn C++?

 

[Paul]

Now you are lying. Your original claim was that member functions are part
of objects; they are not. You made no mention of virtual member functions
and vtables until after I mentioned them. Multiple objects can contain a
pointer to the *same* vtable which makes a nonsense of your claim even if
we only consider virtual member functions.

My original claim did not state that all onjects contains pointers to their
member functions, as you wrongly imply.
..Here( in this last couiple of psts), we have been discussing virtual
functions.

It is obvious that you are a serial misinterpreter and you cannot string a
paragraph together without including a s misquote or misinterpretation
someplace.

 

[Paul]

You don't seem to understand the difference between "having a virtual
function" and "calling a virtual function".

Maybe you should learn English before you learn C++?

Another unjustified insult.
Obviously this guy misunderstands something I wrote so he decides to insult
me by implying I dont understand English. When its obviously him that
doenst understand something.

 

[Paul]

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



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)
}

This suggests that you do not recognise the difference between:
* a member function invoked for an object
and
* and function that takes an object as an argument.

This code seems to have been written in a deliberate attempt to be
confusing, and obviously it is confusing *to you*.

 

[Garrett Hartshaw]

This suggests that you do not recognise the difference between:
* a member function invoked for an object
and
* and function that takes an object as an argument.

This code seems to have been written in a deliberate attempt to be
confusing, and obviously it is confusing *to you*.

If they do the exact same thing, and are (usually) implemented the
same way, and (if inline with sufficient optimization) compile to
almost the same machine code (I haven't checked, but would be
surprised if they did not), then the only difference is the scope of
the function, and the syntax for calling it.

 

[Juha Nieminen]

Another unjustified insult.
Obviously this guy misunderstands something I wrote so he decides to insult
me by implying I dont understand English. When its obviously him that
doenst understand something.

Yes, keep playing the "you insulted me" card. You will surely win the
argument that way.

 

[David Hutto]

Why do the alleged intellectuals keep lecturing on why not to respond
to the 'trolls' keep saying not to egg them on, tehn egg them on by
calling them trolls.

They further keep saying how not to respond, but further respond
themselves, and demonstrate their own ignorance.

 

[James Kanze]

On 09/01/2011 21:24, David Hutto wrote:

A troll gets a "win" if it gets the last word. Replying to a
troll is probably a bit childish but if the troll post
potentially confuses newbies then a reply is possibly
justified.

I'm curious: what is the currently accepted meaning for troll?
Back when I started in newsgroups, the definition of a troll was
someone who posted a contentious statement to a newsgroup, in
order to provoke an incredible amount of traffic, but who didn't
participate in the discussions after that. By that definition,
Paul isn't a troll. (Which doesn't mean that he isn't a childish
idiot, or any other pejorative terms which might apply.) But
that was some time ago, and such definitions tend to evolve.
(Wikipedia, for example, doesn't mention the fact that a troll
doesn't participate in the "discussion", once he's triggered
it.)

 

[James Kanze]

On 08/01/2011 16:07, Paul wrote:

[...]

You are wrong yet again; you obviously do not know C++.

Actually, he's right in the above (except for the last sentence,
which is completely irrelevant). You cannot invoke a virtual
function (or any non-static member function, for that matter)
without an object. You also cannot invoke a function which has
reference parameters without an object (or objects, if there is
more than one reference parameter). I don't see how that's
relevant to the discussion, but as you've surely notices, Paul
likes to throw out a lot of irrelevant junk, to try to confuse
the issues.

The address of
a virtual function is contained within a vtable;

That's one implementation technique. By far the most prevelant,
and I suspect, the only one actually used in practice. But at
least theoretically, others are possible. But vtables and vptr
are all behind the scenes issues, which only concern the
compiler writer, and not the language as it is defined.

I'll repeat my position (you can agree or not): objects do not
have members (function members or data members); classes have
members. It is, however, a convenient shortcut to speak of
non-static data members as members of the object, since they
have the same lifetime (more or less) as the object which
contains them. The key here is lifetime: functions don't have
lifetime, so it makes no sense to speak of them as members of an
object.

[...]

Wrong yet again; member functions exist within the code
segment before any objects are created at runtime.

In practice. The C++ standard doesn't say anything about the
lifetime of functions. Functions just "are", independently of
any objects.

[...]

I suggest you read a C++ book or two

Maybe "You Can Program in C++", by Francis Glassboro. Rated
"highly recommended" by the ACCU.

 

[James Kanze]

news:[email protected]...

[...]

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.

Bullshit.

Leigh speaks about what is certainly the most common
implementation technique; I don't know of a C++ compiler which
uses anything else (and I've actually spoken with most of the
people who've actually written C++ compilers). Within the
standards committee, however, the possibility of other
implementations was discussed, and the typical alterative to a
vptr was to use a map, mapping object address to function
address.

All of which is completely irrelevant. Classes have members,
and objects have subobjects. At least according to the
standard.

The important point here is that an OBJECT contains the
pointer, not a CLASS.

Obviously, an object doesn't contain a class, since classes are
a compile time concept, and objects a runtime concept.

 

[James Kanze]

news:6579bbb8-5ddb-46c0-920b-065d697b0ffe@a10g2000vby.googlegroups.com...

[...]

Then you are calling the function on an object.

Obviously. If a function takes parameters, you have to provide
those parameters. That's true for any function, member or not.
The only real particularity concerning member functions is the
call syntax.

You can't have a virtual function without an object ,end of
story.

You can't call a non-static member function (virtual or not)
without an object. You can't call a function which has a
reference parameter without an object either. So?

The fact that you cannot provide code to suggest what you
claimed proves the opposite.

I didn't bother providing code, because someone else had already
done so. It's standard C++.

And it suggests that your claims are pretty weak and
innaccurate.

The fact that you doubt it rather proves that you don't know
C++.

 

[LR]

You cannot invoke a virtual
function (or any non-static member function, for that matter)
without an object.

I don't understand this.

I've tried this code with two compilers and gotten "X::f()" as output.

#include <iostream>
struct X {
void f() {
std::cout << "X::f()" << std::endl;
}
};

int main() {
X *p = 0;
p->f();
}

Perhaps, since you say "an object" and not an object of the type that
has the invoked function as a member, you mean that p is the object that
is used to call the function?

Or perhaps I didn't understand the qualifiers you suggest for the kinds
of functions that can be called?

Or is this code just plain wrong per the standard?

LR

 

[Ian Collins]

I don't understand this.

I've tried this code with two compilers and gotten "X::f()" as output.

#include<iostream>
struct X {
void f() {
std::cout<< "X::f()"<< std::endl;
}
};

int main() {
X *p = 0;
p->f();
}

Perhaps, since you say "an object" and not an object of the type that
has the invoked function as a member, you mean that p is the object that
is used to call the function?

p is a pointer to an X. The undefined behaviour is using a NULL value.

In this case you aren't accessing any member variables in f, so nothing
bad happens. If f was a virtual function, or you attempted to access a
member variable, your toilet could explode.

 

[stan]

James Kanze wrote:

I'm curious: what is the currently accepted meaning for troll?
Back when I started in newsgroups, the definition of a troll was
someone who posted a contentious statement to a newsgroup, in
order to provoke an incredible amount of traffic, but who didn't
participate in the discussions after that. By that definition,
Paul isn't a troll. (Which doesn't mean that he isn't a childish
idiot, or any other pejorative terms which might apply.) But
that was some time ago, and such definitions tend to evolve.
(Wikipedia, for example, doesn't mention the fact that a troll
doesn't participate in the "discussion", once he's triggered
it.)

In the early times that was generally true, but there were
exceptions. A significant difference between then and now is that back
then most trolls actually had intent and many were intelligent and
even clever and funny once in awhile; even while stirring the pot. I
won't claim to understand others motives but they seemed to do it for
sport.

Today I think most people accused of being a troll are giving them a
bad name. Most dont have a clue or a plan, and they dont seem to have
the mental capacity to form intent to mischief. Mostly they seem
troubled, confused, and desperate, and childish. Basically today's
crop is a very poor imitation of the troll that once roamed usenet. I
don't know if the definition evolved but the behavior has clearly
devolved.

 

[LR]

p is a pointer to an X. The undefined behaviour is using a NULL value.

I don't know why I keep forgetting that for this case.

Thank you.

In this case you aren't accessing any member variables in f, so nothing
bad happens. If f was a virtual function, or you attempted to access a
member variable, your toilet could explode.

LR