Frasncis Glassboro wrote.
Paul
So, in C++ an object is a very primitive thing; just a region of memory.
Note that this region might not have an address (think of temporaries)
</quote>
This was used in the context of an attempt tojustify the argument that an
object cannot contain member functions.
I state that what Francis Glassboro is implying here is nothing more than
complete nonsense for the reasons I give below.
An object type is defined by its class and can be defined to contain member
functions.
A member function is specifically connected to the object on which it was
called.
The C++ standards state that an object is a region of memory but they do not
state that it is JUST a region of memory. The C++ standards then go on to
state that objects can contain member subobjects, these are defined within
the class. The fact that the standard goes on to describe or define objects
in greater detail is evidence that the C++ obviously do not imply an object
is JUST a region of storage.
I repeat....An object is definied in the standard as a region, not JUST a
region, of memory.
If you choose to interpret an object as JUST a region of memory, as you
clearly have then It's a blatent misinterpretation from the standards.
lets just add words in to change the meaning of the standards when it suits
us shall we?s
If the object type is defined to contain a member function then all
instances of that object has the said member function. The calling
mechanisms or where that function is stored in a programs memory is
irrellevant.
It is technically wrong to suggest that an member function is not part of an
object. You attempt to prove this by trying to prove that a member function
does not live within an objects memory.
The fact that a member functions is defined in the objects class definition
is suffice to support my generally accepted view.
Also note that, altohugh you refuse to acknowledge anything other than the
C++ standards here, there is a massive amount of OOP documents and reference
that supportmy terminology.
Alf P. Steinbach /Usenet
Don't start threads with the name of a person in the subject line.
Otherwise everybody will plink you.
That means, that all your articles are automatically sent to the big bit bucket
in the sky, by the newsreader software, so that they are not even seen.
"plink" and "plonk" both means taking the abovementioned measure, but the words
carry different connotations.
"plink" is the sound of a lightweight troll being flushed down the toilet.
"plonk" is used for a troll that has gained some respect, or for a person that
one just disagrees so violently with that one wishes to avoid confrontation,
i.e. a somewhat heavier mass being flushed down.
Cheers & hth.,
- Alf
--
blog at <url: http://alfps.wordpress.com>
Alf P. Steinbach /Usenet
Just adding to that, Paul, I don't see your articles in
[alt.comp.lang.learn.c-c++], but I see lots of replies to them, so apparently I
have already plinked you in that newsgroup -- or plonked you, whatever.
Paul
"Alf P. Steinbach /Usenet" <alf.p.stein...@gmail.com> wrote in
message news:ig4pce$9lc$1...@news.eternal-september.org...
Paul
>* Paul, on 06.01.2011 16:25:
>
> Don't start threads with the name of a person in the subject line.
>
Leigh Johnston
You obviously have a serious mental condition; I suggest you see a
doctor and get prescribed some medication; either that or you are still
an angry hormonal teenager which would also explain a lot.
/Leigh
Bo Persson
>
> An object type is defined by its class and can be defined to
> contain member functions.
> A member function is specifically connected to the object on which
> it was called.
>
> The C++ standards state that an object is a region of memory but
> they do not state that it is JUST a region of memory. The C++
> standards then go on to state that objects can contain member
> subobjects, these are defined within the class. The fact that the
> standard goes on to describe or define objects in greater detail is
> evidence that the C++ obviously do not imply an object is JUST a
> region of storage.
The standard actually says exactly that:
"An *object* is a region of storage." (§1.8)
The fact that the word "object" is in italics means that this is the
definition of the term "object".
The standard then goes on to say "Note: A function is not an object,
regardless of whether or not it occupies storage in the way that
objects do."
Had the committee decided that member functions should be objects,
even though other functions are not, they would certainly have stated
that. And if they are not objects, they cannot be sub-objects of other
objects, because a sub-object is also required to be an object:
"Objects can contain other objects, called *subobjects*."
Here again, the word "subobject" in italics means that this is the
definition of the term.
Bo Persson
Paul
"Paul" <pchr...@yahoo.co.uk> wrote in message
news:QRlVo.8354$MD5...@newsfe23.ams2...
If he states Im not worthy of a reply then I have no choice but to talk
about him.
It is also very insulting to say someone is not worthy, and this is the type
of insults and arrogance I have had to deal with since this argument was
created by Francesco and Francis.
Paul
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:QNudnQsCq5Upb7jQ...@giganews.com...
Ulrich Eckhardt
Well, at least you should not document your professionalism by spelling it
wrongly. I consider it a mixture of you showing a lack of respect or
skills. Didn't you yourself try to diss someone on the base of them making
a spelling mistake?
Paul
"Bo Persson" <b...@gmb.dk> wrote in message
news:8omaej...@mid.individual.net...
> Paul wrote:
>>
>> An object type is defined by its class and can be defined to
>> contain member functions.
>> A member function is specifically connected to the object on which
>> it was called.
>>
>> The C++ standards state that an object is a region of memory but
>> they do not state that it is JUST a region of memory. The C++
>> standards then go on to state that objects can contain member
>> subobjects, these are defined within the class. The fact that the
>> standard goes on to describe or define objects in greater detail is
>> evidence that the C++ obviously do not imply an object is JUST a
>> region of storage.
>
> The standard actually says exactly that:
>
> "An *object* is a region of storage." (§1.8)
>
> The fact that the word "object" is in italics means that this is the
> definition of the term "object".
>
> The standard then goes on to say "Note: A function is not an object,
> regardless of whether or not it occupies storage in the way that objects
> do."
>
>
> Had the committee decided that member functions should be objects, even
> though other functions are not, they would certainly have stated that.
THIS IS CRAZY.
A function is not an object, caps not inteded but not rewriting it .
>And if they are not objects, they cannot be sub-objects of other objects,
>because a sub-object is also required to be an object:
>
Since when was a subobject required to be an object? You state that its
REQUIRED as if the standards state this.
>Objects can contain other objects, called *subobjects*."
>
> Here again, the word "subobject" in italics means that this is the
> definition of the term.
>
>
> Bo Persson
>
>
>tHE STANDARD SEEMS to define a member subobject in section 9.2, ref section
>1. para 2:
"Objects can contain other objects, called subobjects. A subobject can be a
member subobject (9.2), a base
class subobject (Clause 10), or an array element. An object that is not a
subobject of any other object is
called a complete object."
If you goto section 9.2 :
"9.2 Class members [class.mem]
member-specification:
member-declaration member-specificationopt
access-specifier : member-specificationopt
member-declaration:
attribute-specifieropt decl-specifier-seqopt
member-declarator-listopt ;
function-definition ;opt
::opt nested-name-specifier templateopt unqualified-id ;
using-declaration
static_assert-declaration
template-declaration
alias-declaration
member-declarator-list:
member-declarator
member-declarator-list , member-declarator
member-declarator:
declarator pure-specifieropt
declarator brace-or-equal-initializeropt
identifieropt attribute-specifieropt : constant-expression
pure-specifier:
= 0
1 The member-specification in a class definition declares the full set of
members of the class; no member
can be added elsewhere. Members of a class are data members, member
functions (9.3), nested types,
and enumerators. Data members and member functions are static or non-static;
see 9.4. Nested types are
classes (9.1, 9.7) and enumerations (7.2) defined in the class, and
arbitrary types declared as members by use
of a typedef declaration (7.1.3). The enumerators of an unscoped enumeration
(7.2) defined in the class are
members of the class."
This is how the standard defines the term member subobject.
Andy Champ
Paul
"Andy Champ" <no....@nospam.invalid> wrote in message
news:XJ-dnRdCzKlCsrvQ...@eclipse.net.uk...
> You are a troll and ICMFP.
>
Juha Nieminen
> A member function is specifically connected to the object on which it was
> called.
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 similar concept in some other programming languages
*is* always tied to a specific object, but not in C++.)
You can then call that function using that pointer, giving it an object
of that class type as parameter (well, effectively at least; the syntax
is obviously a bit different from a regular function call).
That would indicate that the member function is not, in fact,
inherently tied to any object in particular, but a free function
which is tied to the *class* in particular. Technically speaking
the only difference between a member function and a class function
(ie. one declared as 'static') is that the former takes an object
as parameter (through a special syntax) while the latter doesn't.
I think that you have some confusion about what "class", "object" and
"member function" mean in the context of C++. The OO paradigm in C++ is
slightly different from that of certain other OO languages where the
distinction between objects and classes is absent (iow. there are only
objects, no classes per se).
Paul
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:4d263f48$0$32136$7b1e...@news.nbl.fi...
> In comp.lang.c++ Paul <pchr...@yahoo.co.uk> wrote:
>> A member function is specifically connected to the object on which it was
>> called.
>
> 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 similar concept in some other programming languages
> *is* always tied to a specific object, but not in C++.)
>
a) how do you get the address of a member function?
b) what happens if this member function is virtual?
c) what happens if this member function is overridden?
I accept that it probably is possible to directly address a member function
but I do not know if this would be a valid program.
> You can then call that function using that pointer, giving it an object
> of that class type as parameter (well, effectively at least; the syntax
> is obviously a bit different from a regular function call).
>
And what exactly would 'this' point to?
> That would indicate that the member function is not, in fact,
> inherently tied to any object in particular, but a free function
> which is tied to the *class* in particular. Technically speaking
> the only difference between a member function and a class function
> (ie. one declared as 'static') is that the former takes an object
> as parameter (through a special syntax) while the latter doesn't.
This does suggest that a member function need not be tied to an object.
It does not imply that a member cannot be tied to an object.
>
> I think that you have some confusion about what "class", "object" and
> "member function" mean in the context of C++. The OO paradigm in C++ is
> slightly different from that of certain other OO languages where the
> distinction between objects and classes is absent (iow. there are only
> objects, no classes per se).
>
You talk about a function not associated with an object , but I was
obviously talking about a member function that is associated with an object.
I don't see where any confusion comes from.
Johannes Schaub (litb)
> <quote>
> So, in C++ an object is a very primitive thing; just a region of memory.
> Note that this region might not have an address (think of temporaries)
> </quote>
>
>
> This was used in the context of an attempt tojustify the argument that an
> object cannot contain member functions.
> I state that what Francis Glassboro is implying here is nothing more than
> complete nonsense for the reasons I give below.
>
An object is a region of memory. But unlike most definitions in the
Standard, this one isn't bidirectional: Not every region of memory is an
object. An object:
- Can not exist.
- Exist but isn't completely constructed yet (this is true when it's still
within its constructor body). Lifetime at this point hasn't started yet.
- Exists and is alive.
- Exists but is in the process of being destroyed. At this point, lifetime
already has stopped. This is true when it's in its destructor body.
- Can not exist anymore.
Item 1 and the last item don't need memory obviously. But the other three
items need memory. For all types except class types or array of class types,
you only have the first, third and last state.
Now when you have a raw piece of memory, you can't have all but the first
and last state, because all others need a type. For an object to exist in
C++, I think you at least need a type (this is different in C. In C types
aren't attributed to objects, but only to accesses to them. That's why it
talks about "effective" type only).
In the spec, "memory" is called "storage" - I think that's because C
actually enforced different storage areas for objects: registers and memory.
Both are called "storage". C++ doesn't enforce this difference anymore.
I have no idea how the rules are in detail for lifetime starting of class
type and non-class type objects. In my opinion, the Standard isn't clear
enough on that.
> An object type is defined by its class and can be defined to contain
> member functions.
> A member function is specifically connected to the object on which it was
> called.
>
An object doesn't "contain" member functions. An object also isn't
necessarily of class type.
Classes just declare member functins. Those functions are completely
"normal" functions in any other aspects. Even their type doesn't contain
anything specific to their class. For example a "void f() { }" member
function has type "void()".
Paul
"Johannes Schaub (litb)" <schaub-...@web.de> wrote in message
news:ig5ik6$9r1$02$1...@news.t-online.com...
be part of that object type. Given that a class is the definition of an
object type.
Geoff
In Paul's case I'd make it more of a "ploik" vs. the heavier "plop".
Where ploik connotes the lightweight piece into a confined liquid
environment prior to flushing. I can't believe you guys persist in
feeding this troll.
A member function defines the interface to an object of the class,
there is no "member is a part of or contained in an object". In fact,
in Harvard architecture machines it is physically impossible for
member code to reside in the same memory space (segment) as the object
it interfaces. It is also perfectly acceptable for an implementation
to use the same code (member function) to access a different object of
the same class. Gee, could that be inheritance? The abstraction of
members and objects is entirely different from the implementation.
Juha Nieminen
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>> function pointer of the proper type), and it will *not* be tied to any
>> specific object. (The similar concept in some other programming languages
>> *is* always tied to a specific object, but not in C++.)
>>
> I can understand the concept you express but
> a) how do you get the address of a member function?
> b) what happens if this member function is virtual?
> c) what happens if this member function is overridden?
>
> I accept that it probably is possible to directly address a member function
> but I do not know if this would be a valid program.
I find it a bit ironic that you protest so loudly abour common concepts
of C++ programming, yet you lack such knowledge of the language.
C++ "inherits" the notion of function pointers from C: You can take the
address of a function and eg. assign it to a variable of the function
pointer type. For example "void(*fptr)() = &f;" where f() is a function
with the signature "void f()". (Now you can call f() using fptr, simply
as "fptr()", as if 'fptr' had become a synonym for 'f'. In fact, you can
effectively think of 'f' as being literally a pointer to that function
as well.)
C++ also expands the concept to support pointers to member functions as
well, by expanding the function pointer syntax. For example, suppose you
have a class A with a "void f()" member function. You can create a pointer
to that function like "void(A::*fptr)() = &A::f;". Now you can call that
function with an object of type A eg. like: "A a; (a.*fptr)();". (What
this effectively does is that it calls the function pointed by 'fptr'
giving it the 'a' object as the 'this' parameter.)
If A::f() is virtual, the call using the pointer will work properly
(in other words, dynamic binding will be obeyed appropriately, in other
words, if the object is of a derived type which overrides f(), calling
the function using 'fptr' will call the derived implementation).
>> You can then call that function using that pointer, giving it an object
>> of that class type as parameter (well, effectively at least; the syntax
>> is obviously a bit different from a regular function call).
>>
> And what exactly would 'this' point to?
What do you think?
>> That would indicate that the member function is not, in fact,
>> inherently tied to any object in particular, but a free function
>> which is tied to the *class* in particular. Technically speaking
>> the only difference between a member function and a class function
>> (ie. one declared as 'static') is that the former takes an object
>> as parameter (through a special syntax) while the latter doesn't.
>
> This does suggest that a member function need not be tied to an object.
> It does not imply that a member cannot be tied to an object.
What do you mean by "member" here?
James Kanze
> In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote:
> > A member function is specifically connected to the object on
> > which it was called.
> 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 similar concept in some
> other programming languages *is* always tied to a specific
> object, but not in C++.)
You can also take the address of a member variable, and assign
it to a pointer to member. I don't think that that's an
argument for anything particular.
I think that the issue is clear to everyone but Paul: in C++ (in
the vocabulary used in the standard), classes have members,
objects have subobjects. A function can be a member of a class,
but since it is not an object, it isn't be a subobject of an
object. This corresponds to the general vocabulary used in the
standard. Now, it's quite possible that the standard itself
slips up in its wording here or there, but those places should
probably be considered bugs in the standard (and in fact, when
Leigh pointed out one place in the draft standard, Pete
immediately corrected it, so the bug won't be in the next draft,
or in the final version).
[...]
> I think that you have some confusion about what "class", "object" and
> "member function" mean in the context of C++. The OO paradigm in C++ is
> slightly different from that of certain other OO languages where the
> distinction between objects and classes is absent (iow. there are only
> objects, no classes per se).
I think it would be fairly accurate to say that C++ doesn't have
an OO paradigm. Or any other paradigm, for that manner. C++ is
a tool, which provides a number of structures which can be used
to *implement* various paradigms in your own code. (In
particular, derivation in C++ is *not* always OO inheritance;
think of things like inheriting from std::iterator or from
std::unary_function.)
--
James Kanze
James Kanze
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
> news:4d263f48$0$32136$7b1e...@news.nbl.fi...> In comp.lang.c++ Paul <pchris...@yahoo.co.uk> wrote:
> >> A member function is specifically connected to the object on which it was
> >> called.
> > 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 similar concept in some other programming languages
> > *is* always tied to a specific object, but not in C++.)
> 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).
> c) what happens if this member function is overridden?
Overload resolution occurs, in exactly the same way that it does
in the case of non-member functions.
> I accept that it probably is possible to directly address
> a member function but I do not know if this would be a valid
> program.
I'm not sure what you mean by "directly" in this case, but the
above is definitely legal C++.
> > You can then call that function using that pointer, giving
> > it an object of that class type as parameter (well,
> > effectively at least; the syntax is obviously a bit
> > different from a regular function call).
> And what exactly would 'this' point to?
The class object you used in the dereferencing expression.
None of this has anything to do with the original question, but
it is standard C++, and any one claiming to know C++ should
certainly know it, even if it isn't the sort of thing you use on
a daily basis. (I've used pointers to member functions perhaps
two or three times in the twenty years I've been programming in
C++.)
--
James Kanze
Paul
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
> In comp.lang.c++ Paul <pchr...@yahoo.co.uk> wrote:
>> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>>> 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 similar concept in some other programming
>>> languages
>>> *is* always tied to a specific object, but not in C++.)
>>>
>> I can understand the concept you express but
>> a) how do you get the address of a member function?
>> b) what happens if this member function is virtual?
>> c) what happens if this member function is overridden?
>>
>> I accept that it probably is possible to directly address a member
>> function
>> but I do not know if this would be a valid program.
>
> I find it a bit ironic that you protest so loudly abour common concepts
> of C++ programming, yet you lack such knowledge of the language.
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.
SO I won't even borther to read any more of your SHITE.
>
<snip>
Marc
> <quote>
> So, in C++ an object is a very primitive thing; just a region of
> memory. Note that this region might not have an address (think of
> temporaries) </quote>
>
>
> This was used in the context of an attempt tojustify the argument
> that an object cannot contain member functions.
I've read the standards documents only enough to get the gist of what is
there. I can relate though to 'object' being used with different meanings
in different concepts. I can also hold off on deciding how terminology is
being used until the message is clear, a clarity that any isolated
statement may not provide. The calculator on my desk is an object, but I
can't derive from it or compile it along with my programs. The use of
'object' has rather well-defined and accepted meaning when used in an OO
context. For the language lawyers/committee members who drafted the
standards, way before OO was in vogue (remember, C++ is "derived" from
C), 'object' has a more traditional meaning in the larger context of
programming languages. Note how compiler developers talk about
"constructors" that have different meaning than a C++ class's
constructors. As technology changes, terms get reused and reassigned but
that doesn't always happen immediately and in the mean time, one has to
rely on the "fuzzy" meaning of the terms and extract as best as one can
from the usage of the terms in the context, and that context means what
was meant by the conveyor of the message which may not necessarily be
what the conveyor wrote, as communication is a subtle thing and note that
language is pretty paltry and then text only is even worse. Now if you
want to be opportunistically evil and exploit that paltryness, run for
state's attorney!
Paul
"James Kanze" <james...@gmail.com> wrote in message
news:65a55b13-8ec3-49d4...@l32g2000yqc.googlegroups.com...
> On Jan 6, 11:14 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>
>> news:4d263f48$0$32136$7b1e...@news.nbl.fi...> In comp.lang.c++ Paul
>> <pchris...@yahoo.co.uk> wrote:
>> >> A member function is specifically connected to the object on which it
>> >> was
>> >> called.
>
>> > 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 similar concept in some other programming
>> > languages
>> > *is* always tied to a specific object, but not in C++.)
>
>> 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 ?
You cannot do this with virtual functions and you are wrong to suggest it
works correctly.
A virtual function calling mechanism requires an object.
>
>> c) what happens if this member function is overridden?
>
> Overload resolution occurs, in exactly the same way that it does
> in the case of non-member functions.
>
>> I accept that it probably is possible to directly address
>> a member function but I do not know if this would be a valid
>> program.
>
> I'm not sure what you mean by "directly" in this case, but the
> above is definitely legal C++.
>
>> > You can then call that function using that pointer, giving
>> > it an object of that class type as parameter (well,
>> > effectively at least; the syntax is obviously a bit
>> > different from a regular function call).
>
>> And what exactly would 'this' point to?
>
> The class object you used in the dereferencing expression.
A class is not an object.
No object was ever declared in your code.
Once again you appear confused about classes an objects.
>
> None of this has anything to do with the original question, but
> it is standard C++, and any one claiming to know C++ should
> certainly know it, even if it isn't the sort of thing you use on
> a daily basis. (I've used pointers to member functions perhaps
> two or three times in the twenty years I've been programming in
> C++.)
>
> --
> James Kanze
>
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.
Paul
"Marc" <xmar...@spot.net> wrote in message
news:ig7586$1kh$1...@speranza.aioe.org...
In the context of C++ prgramming this is how we define an object:
With:
namespace{
ObjType AnObject;
}
AnObject is considered the object here and it is considered to be of type,
object type.
The object type , being ObjType, is defined in its respective class.
It's pretty simple and there are lots of programming texts that use this
terminology
If the 'term' object is used within the standards to describe an integer
type, it is not correct to use the term object in that context when you are
talking about an object as above. To do so is nothing more than a blatant
misinteprestation of the standards.
To suggest that, the standards define an object to be simply a region of
storage therefore an objects identifier cannot be condsidered an object, is
completely unreasonable and a total misinterpreation of the standards.
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
[...]
> >> 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:-).
> 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?
--
James Kanze
Bart van Ingen Schenau
> "James Kanze" <james.ka...@gmail.com> wrote:
> > On Jan 6, 11:14 pm, "Paul" <pchris...@yahoo.co.uk> 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 ?
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.
<snip>
> >> And what exactly would 'this' point to?
>
> > The class object you used in the dereferencing expression.
>
> 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.
<snip>
> 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
Paul
> On Jan 7, 2:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "James Kanze" <james.ka...@gmail.com> wrote in message
>
> [...]
>> >> 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.
>
>> A virtual function calling mechanism requires an object.
>
> Using a pointer to a member requires an object. So?
>
> --
> James Kanze
>
The point was to show that a member function can be called *without * an
object.
Juha Nieminen
>> I find it a bit ironic that you protest so loudly abour common concepts
>> of C++ programming, yet you lack such knowledge of the language.
>
> 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
>>
>> 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 ?
> 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.
Paul
"Bart van Ingen Schenau" <ba...@ingen.ddns.info> wrote in message
news:a39be560-9159-4e83...@o4g2000yqd.googlegroups.com...
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
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
> In comp.lang.c++ Paul <pchr...@yahoo.co.uk> wrote:
>>> I find it a bit ironic that you protest so loudly abour common concepts
>>> of C++ programming, yet you lack such knowledge of the language.
>>
>> 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?
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 fuck off anyway.
Paul
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
> In comp.lang.c++ Paul <pchr...@yahoo.co.uk> wrote:
>> "James Kanze" <james...@gmail.com> wrote in message
>>> &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 ?
>> 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?
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.
Garrett Hartshaw
Hash: SHA1
#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-----
stan
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>> I find it a bit ironic that you protest so loudly abour common concepts
>> of C++ programming, yet you lack such knowledge of the language.
>
> 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?
Paul
"Garrett Hartshaw" <ghar...@gmail.com> wrote in message
news:ig855p$ec1$1...@speranza.aioe.org...
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':
stan
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
> news:4d276e5a$0$12283$7b1e...@news.nbl.fi...
>> In comp.lang.c++ Paul <pchr...@yahoo.co.uk> wrote:
>>>> I find it a bit ironic that you protest so loudly abour common concepts
>>>> of C++ programming, yet you lack such knowledge of the language.
>>>
>>> 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?
>
> 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 fuck off anyway.
Control issues?
stan
> On 01/07/2011 02:06 PM, Paul wrote:
<snip>
Did you hear that? Sounded like "I'm mmeelllllllttttting"
Garrett Hartshaw
Hash: SHA1
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-----
Paul
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 . ????
Garrett Hartshaw
Hash: SHA1
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-----
Juha Nieminen
>
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
> news:4d276e5a$0$12283$7b1e...@news.nbl.fi...
>> In comp.lang.c++ Paul <pchr...@yahoo.co.uk> wrote:
>>>> I find it a bit ironic that you protest so loudly abour common concepts
>>>> of C++ programming, yet you lack such knowledge of the language.
>>>
>>> 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?
>
> What part of "you lack such knowlege of the language" do you not understand
> to be an insult?
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.
> Don't bother replying because I'll just tell ya to fuck off anyway.
You are still trying to play the "you insulted me" card, probably so
that you don't have to discuss the actual arguments presented.
Juha Nieminen
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.)
Rui Maciel
> 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.
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
Paul
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:4d28710e$0$8918$a729...@news.telepac.pt...
object related.
The fact that someone has *claimed* they can be used without the prescence
of an objcet does no tmean I have to prove otherwise.
The only thing *backwards* here completely incorrect interpretation..
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:7148a492-1586-4421...@w29g2000vba.googlegroups.com...
> > On Jan 7, 2:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> >> "James Kanze" <james.ka...@gmail.com> wrote in message
> > [...]
> >> >> 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.
> >> 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.
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).
> >> A virtual function calling mechanism requires an object.
> > 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.
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++.
--
James Kanze
James Kanze
> On 01/07/2011 11:35 PM, Paul wrote:
[...]
> > 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).
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.
--
James Kanze
Paul
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
Leigh Johnston
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).
>
> 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
Wrong yet again; member functions exist within the code segment before
any objects are created at runtime.
> 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
I suggest you read a C++ book or two and stop trolling your ignorance in
this newsgroup wasting people's time.
/Leigh
Leigh Johnston
>>
>> 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).
>
It is important to note however that the use of vtables is an
implementaiton specific way of doing things (vtables are not mentioned
by the standard AFAIK). I do not know of any implementations that do
not use vtables however; this is down to the fact that the vtable
solution to the problem of dynamic dispatch is efficient and not memory
intensive (requiring only a single pointer in an object when using
single inheritance).
/Leigh
Paul
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:dY6dnRGj2q1NELXQ...@giganews.com...
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!.
>>
>> 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
>
> Wrong yet again; member functions exist within the code segment before any
> objects are created at runtime.
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.
>
>> 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
>
> I suggest you read a C++ book or two and stop trolling your ignorance in
> this newsgroup wasting people's time.
>
> /Leigh
The level of intelligence displayed by your insult is your problem.
Paul
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.
Paul
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.
Paul
> On Jan 7, 7:06 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "James Kanze" <james.ka...@gmail.com> wrote in message
>
>> news:7148a492-1586-4421...@w29g2000vba.googlegroups.com...
>> > On Jan 7, 2:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> >> "James Kanze" <james.ka...@gmail.com> wrote in message
>
>> > [...]
>> >> >> 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.
>
>> >> 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.
>
> 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.
Leigh Johnston
I never said otherwise.
>
> 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.
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).
>
> 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.
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).
/Leigh
Paul
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 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++?
Leigh Johnston
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.
>
> Once again you demonstrate your tendancy to misinterpet words
Another lie.
/Leigh
Paul
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
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
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.
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
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.
Leigh Johnston
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.
/Leigh
James Kanze
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
James Kanze
> On 08/01/2011 16:07, Paul wrote:
[...]
> > 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++.
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.
[...]
> > 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
> 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
James Kanze
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:v_KdnTNgnatkErXQ...@giganews.com...
[...]
> > It is important to note however that the use of vtables is
> > an implementaiton specific way of doing things (vtables are
> > not mentioned by the standard AFAIK). I do not know of any
> > implementations that do not use vtables however; this is
> > down to the fact that the vtable solution to the problem of
> > dynamic dispatch is efficient and not memory intensive
> > (requiring only a single pointer in an object when using
> > single inheritance).
> 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
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
[...]
> >> >> > 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.
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?
> >> >> 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.
> > 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.
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++.
--
James Kanze
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
> James Kanze wrote:
>
>> 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?
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.
--
Ian Collins
stan
<snip>
> 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
> On 01/10/11 02:38 PM, LR wrote:
>> James Kanze wrote:
>>
>>> 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?
>
> 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
Francis Glassborow
> Ian Collins wrote:
>> On 01/10/11 02:38 PM, LR wrote:
>>> James Kanze wrote:
>>>
>>>> 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?
>>
>> 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.
However, in the strict sense that code does invoke the function even
though the consequence is undefined behaviour :) Instead of 'cannot' the
statement needs qualification 'you cannot, without invoking undefined
behaviour, ...
Yes I know I am being pedantic :) But the C++ Standard does not lay down
special meanings for 'invoke' and 'cannot' so they must be used in the
plain English meanings.
BTW the C++ Standard _does_ give a special (extended) meaning to 'use'
when applied to an entity. For example; a virtual function is always
used even if it is never called. That is why it must be defined (or
explicitly marked with '=0'. In practical terms the address of the
virtual function is needed for the vftable.