Re: Is it legal code?
On Feb 21, 7:16 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:7b02a644-2a89-4db9-9630-138986448e3e@k18g2000vbq.googlegroups.com...
[...]
And what does "existence [..] is undefined" mean?
I actually covered two things by this:
1)The existence/lifetime of a function is a gray area and is undefined=
..
2)When a function is invoked on an object its behaviour is defined,
otherwise it is undefined.
I don't think that there's any disagreement there. But there is
no difference between member functions and free functions in
either case.
Good this one is indenting :-S
There is a difference , you are trying implement standaresque
language which is confusing. A NSMF must be called on an
object(instance of class type object) , this is not the same
as calling a normal function with an int object(confusing
standaresque object) argument.
I'm afraid the only difference I see is in the calling syntax.
And if you don't like int objects (although int *is* an object
in C++), then consider "void f(MyClass&)". It's illegal to call
this function without an instance of MyClass. Make f a friend
of MyClass, and the *only* different between this an a member
function is the calling syntax. What exactly is the difference
between titi and tata below:
struct Toto
{
void titi();
friend void tata(Toto&);
};
The calling sequence is different (and there have been proposals
to unify them, allowing titi(obj) as well as obj.titi()), but
otherwise?
This doesn't mean they are not members of an object but
members of a class, they don't exist inside a class either.
The class doesn't even exist anymore, its as precompile
time entity. The class-type or object-type( means the same
thing), is defined. If this type is defined to have a NSMF
then the NSMF is a member of the object and the class-type.
Within the C++ standard, class type and object type are two very
different concepts. A "class type" is a subset of all possible
types. An "object type" is a much larger subset: int in not
a class type, but it is an object type.
What you say above seems illogical to me i.e the following are
incoherent.:
1) a class type is a subset of all possible types
2) object type is a larger subset, int is not a class type.
How can you get larger subset than *all possible* types?
Class types are a subset of all possible subsets. Object types
are a subset of all possible subsets.
The above states exactly the same thing for both class and object types.
They're both subsets. Yes. They're not the same subset.
The cardinality of
"object types" is larger than the cardinality of "class types".
Thus, if I write:
class Toto {};
typedef int Titi;
typedef void Tata(); // (And yes, this is legal. Even if
// I've never found a use for it.)
Then Toto, Titi and Tata are names of types: all three are in
the set of all possible types. Toto and Titi are object types,
and only Toto is a class type.
This is the usual C++ terminology.
IMO the standards loose use of the word 'object' to mean
almost anything imaginable is confusing.
It doesn't use it to mean almost anything. It uses "object" for
a specific set of types, which have instances guaranteed to be
represented as a contiguous set of bytes in memory.
So, barring functions, what isn't an object in the context of
the standards?
Functions, references, templates, types...
[...]
The article in question talks about "class variable", and
compares it with "instance variable". There's nothing in it
which says that "instance variables" aren't members of a class;
it doesn't even speak of "members".
I'm not trying to say instance members aren't members of the
class. I acknowledge the class/object(not in the ISO std
context) relationship. A member declared in a class , is
*also* a member of an object instanciated from that class, and
vice versa, with the exception of class variables declared
static.
OK. But it's not the vocabulary used by the C++ standard (nor
by the Java standard), and I'm not sure what it buys you. From
more recent searches, I find it is used in some circles. I find
it leads to more confusion, unless it's only used as a sort of
shorthand, where "member of object" is actually used to mean
"member of the type of the object", and only used in cases where
there is no ambiguity.
As the above link explains class methods/variables is a term
usually applied to member functions/variables that are
declared static. A nonstatic memberfuncion/variable is
different altogether.
More generally, however, I have found some respectable sites
which do use your terminology. From an admittedly very quick
scan of the text, my impression is that people from a Smalltalk
background think in terms of objects having members (and don't
think much in terms of types at all); people from a Simula
background think in terms of classes having members (and are
very concerned about types). Stroustrup, of course, studied
with the creators of Simula, and has long cited Simula as his
major source, along side of C. And types are a very important
concept in C++. So the Simula vocabulary seems more
appropriate. Also, most people from the Smalltalk school deny
C++, and even Java, the qualification of an OOP language. And
also, they don't talk about functions, period---functions don't
exist in Smalltalk, only methods, which are members of the
object (since there isn't any type system in the sense we
understand it in C++), and react to messages.
'Methods' and 'member functions' are generally considered
interchangeable when talking about OOP across languages.
*That* depends on who you ask. Alan Key definitely makes
a distinction. And I think Stroustrup's choice of function
rather than method was a conscious (or maybe an inconscious) way
of stressing the similarities between member functions and
non-member functions.
As per Stroustrup I can produce quotes, and I have in the
past, from his documents on OOP which support my argument,
please read these docs.
Anyway, that's not the way most people speak about C++.
Curiously enough, a lot more Java experts use the term "members
of an object", despite the Java standard very explicitly
describing members as "of a class".
This is completely incorrect see my other post where I posted
the definition of an object from the Java sun docs.
The definition in the Java specification is "An object is
a class instance or an array" (=A74.3.1). In that section, there
is no reference to "members of an object"; the closest it comes
is "Most objects have state, stored in the fields of the objects
that are instances of classes[...]". I wouldn't normally
consider functions "state", and the Java standard doesn't not
consider functions to be a "field". Classes and members are
described in =A78; the beginning of =A78 clearly refer to members as
members of the class, not of the object (usually called instance
in the Java specification).
And I don't recall any quote from the Java specification from
you.
My experience is largely
C++ (with some Java), so I use the vocabulary that is current in
the C++ community, and especially in the C++ standards
committee. When talking about C++, it certainly facilitates
communication. (Maybe part of your problem is that you consider
C++ an OOP language, while using a vocabulary generally used by
people who don't consider C++ OOP.)
C++ supports OOP, its debatable what *is* a true OOP language,
so C++ seems unsure if it is or not. But it most certainly
supports it.
In my opinion, yes. It supports what I understand as OOP. But
you'll find a lot of disagreement about it. People from the
Smalltalk tradition, in particular, dispute it, and these seem
to be the ones most strongly favoring your vocabulary.
--
James Kanze