Re: Is it legal code?
On Feb 21, 4:42 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:443b644a-bf36-49b1-aa71-fd5e4a422f54@d12g2000vbz.googlegroups.com...
On Feb 21, 11:48 am, "Paul" <pchris...@yahoo.co.uk> wrote:
"James Kanze" <james.ka...@gmail.com> 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?
Given something like:
struct Toto
{
void titi();
};
int
main()
{
void (Toto::*pmf1)() = &Toto::titi;
// What does pmf1 point to, if Toto::titi
// doesn't exit?
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".
Toto* p1 = new Toto;
Toto* p2 = new Toto;
void (Toto::*pmf2)() = &Toto::titi;
// And what about here, since according to
// your logic, there are now two Toto::titi?
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 thin=
k
is undefined).
Note: I am not talking about breaking the one definition rule , I am
thinking of possible implementations of virtual functions.> }
No matter how you cut it: if existance has any meaning for
a member function, it exists for the entire time the program
runs, regardless of the presence or absence of instances.
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.
But in the end, who cares?
What kind of attitude is that? If you don't accept the rules
of the language, that's hardy good pr for you as
a professional.
What does your argumentation have to do with the rules of the
C++ language? It's purely a lexical dispute.
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 (=A78.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.
The whole discussion sounds more like metaphysics than
anything useful. Pragmatically, if you want to
communicate, you use the same vocabulary as everyone
else, even if you think it less than ideal. And if you
don't want to communicate, why bother posting at all?
People around here keep thinking they speak for the
majority but this is not the case.
Except that you can't find anyone speaking differently, at
least where C++ is concerned.
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.
Just take alook at your argument in the stl thread James
, you originally started of arguing with the majority
, then later it evolves that you don't even support that
cause. You just argued on-sdie with Pete becker etc because
they seemed like the stronger side to be on., this doesn't
mean everyone arguing against you has a failure to
communicate.
In the case of the STL argument, I've argued consistently
that the term is ambiguous. Unlike the current discussion,
there is no consensus among C++ practitionners as to what
STL means. In some ways, this is regretable, but neither
I nor anyone else can force consensus. (Luckily, in the
case of the meaning of STL, the distinction isn't really
important.)
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).
--
James Kanze