James Kanze said:
"James Kanze" <
[email protected]> wrote in message
[...]
In practice, as someone else has pointed out in this thread, you
can take the address of a non-static member function, with or
without the presense of an object. Which seems like
a conclusive argument that whatever non-static member functions
might be, and whether they exist or not, their reality or status
or whatever is independent of any object.
I have pointed this out , but I aslo pointed out this would
not be standard complaint. I disagree with your analysis,
I think the standard defines a rule that means a function
cannot exists without an object, the opposite of your
conclusion.
So what am I taking the address of, when I take its address.
You are in a gray area where you have a pointer to a functions
definition, but you can't invoke the function, so does the
function exist?
It depends on your definition of "exists", I suppose. But the
issue is not restricted to non-static member functions; the same
question could be asked of any function which requires an lvalue
(and thus an object). Given:
struct Toto
{
void titi();
};
void tata(Toto&);
, what is the existential difference between Toto::titi and
tata?
Its the address InstrPointer will point to when the the function is
invoked. (for an assumed machine architecture).
The pointer already exists, and has a fixed value. What does it
mean to be the address something will point to when the function
is called?
&Toto::titi is the location where the function is defined.
It's the address of the function. As far as the standard is
concerned, there is no "location".
No there are two pointers.
Toto::titi is part of the class/object-type defiition, there is only one
definiton for all instances of this class/object-type.
(whether this is guaranteed to be the case on all implementations, I think
is undefined).
Note: I am not talking about breaking the one definition rule , I am
thinking of possible implementations of virtual functions.> }
If you are going to give a function a lifetime then consider
a function as a sub-process. What is the lifetime of that
sub-process? It seems stupid to speak about the lifetime of
a function, where every function has the same lifetime(that of
program execution).
But that's the only way you can speak about it and be conform
with what the standard says. C++0x doesn't link functions with
threads (I presume that's what you mean by "sub-process") any
more than it links them to objects. A member function is
a function like any other, except that it has a special calling
syntax, and special access rights to member data.
The rules suggest that a NSMF cannot be called unless called
on an object. This supports my argument that C++ supports the
OOP concept that NSMF's are members of an object.
The rules say explicitly that *no* function, member or
otherwise, can be called without being passed valid arguments.
Any function taking a reference requires an object. There's
nothing special about member functions here.
If you are suggesting C++ does not support OOP, this seems
like a pretty bold statement to make considering the
overwhelming evidence to suggest otherwise. I don't see how
you can brush this of as 'purely lexical'.
I'm not sure what you mean by "supporting OOP". C++ provides
adequate support for OOP, and for a number of other paradigms as
well. But the usual language of OOP doesn't talk about members
of objects (at least not in OOP languages with static
typechecking); it talks about members of classes; Java, for
example, has class members (§8.2 of the Java specification), not
object members. It's frequent as well to use the term "members
of an object" as a shorthand for "members of the object's type",
but this is just that, a shorthand.
No I can find hundreds of quotes to support me, the fact that
nobody in here seems to be speaking up against the majority(in
here) doesn't mean you are the real majority.
And where do you find those quotes? I can't find them, and I've
read quite a bit of the OO literature. None of my collegues,
past or present, describe things in terms you use, and that
represents a lot of very competent people.
You and a few other in here have claimed that a NSMF is
a member of a class but not an object. You have given no
evidence at all to support your claim except for the fact that
you are in the majority therefore you are correct.
We cite other uses, such as that of the C++ standard. (I've
also cited the Java standard, just to prove that it's not
a particularity of C++.) As we are clearly in the majority
here, and in the majority in the C++ committee, it's up to you
to find support elsewhere---in which case, the best you can do
is prove that the use is ambiguous; that different communities
use the language differently.
C++ is a language where the class is the definition of an
object, so to say something is a member of a class but not
part of an object doesn't make sense, bar the exception of
static members.
No. A class is not the definition of an object, neither in C++
nor in Java (the other "OO" language I know well). A class is
a definition of a type, and an object has a type---in C++, that
type is not even necessarily a class type.
Note the distinction---it's a typically OO one between isA
(a class isA type) and containment (an object hasA type). In
many (most?) OO languages, each type is represented by a specific
object, but this is not the case of C++, and it is still
a distinct object, with its own type, and not the object which
has the type.
Member functions as part of an object are a well defined OOP
concept
It's such a well defined concept that I can find no mention of
it in the literature. A quick search for member functions turns
up:
-- Member functions are operators and functions that are
declared as members of a class. (IBM)
-- Classes can contain data and functions. These functions are
referred to as "member functions." (Microsoft)
and so on.
and if a language doesn't support this, it cannot be
said to support OOP.
In which case, I know of no language which supports OOP. The
Java specification makes the distinction even clearer than the
C++ one.
However C++ does support OOP so therefore
it follows that C++ supports the concept of member functions
as members of an object. The argument you have put forward is
very non supportive of OOP, and if your argument was correct
it would mean C++ did not support OOP.
For starters, you've got things backwards. C++ has a set of
functionalities; it is this set which can be used to determine
whether C++ supports OOP or not (and some prominent
practitioners---Bertrand Meyers for examnple---have proclamed
that it doesn't). Whether a feature is OOP or not has no
influence on the language---only on how you view the language.
Can you at least agree that a language must support this
concept to support OOP?
No, since Java explicitly doesn't, and Java is definitly OOP
(and not much else).
).