Re: Is it legal code?
<snip>
This is too long a post to manually indent everything. Please re-raise any
issues if you think I am trying to avoid anything
But when you see what i have to post you will realise I am not avoiding
anything.
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 think
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.
Here I am speaking about a function as a sub-routine or sub-process, I'm not
talking about thread processes.
Please note your final sentence in the above paragraph. Its a contradiction
in terms. You state that a member function is like any normal function
except......blah blah. This means its not the same as a normal function. I
would refer back to this in the many instances where you suggest there is
nothing special about member functions, if it weren't for my skipping over
because of indenting probs.
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 (?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.
<quote ref =http://java.sun.com/docs/glossary.html#O>
"object
The principal building blocks of object-oriented programs. Each object is a
programming unit consisting of data (instance variables) and functionality
(instance methods). See also class."
</quote>
I have nothing more to say about your above paragraph except.. complete
rubbish.
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.
..>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
One above and here's another, there are hundreds if not thousands:
http://en.wikipedia.org/wiki/Object-oriented_programming
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.
"We"? Are you skitzo, or royal?
You are speaking nonsense James, see my quote from Java above.
<snip rest>