Is it legal code?

[Paul]

news:0e0dc254-eccb-42aa-8ab7-35db4c4218e1@w21g2000yqm.googlegroups.com...

[...]

I don't quite follow you here. If I have a function:
void f(int&);
, it's undefined behavior for me to call f without a an object
of type int.
You must've forgot we are talking about *member functions*.
So what's the difference, with regards to your argument.

The difference is that the standard defines a rule for nonstatic member
functions. The same rule does not apply to normal functions.

The only difference defined by the standard is that nonstatic
member functions have an implicit first parameter, of type T&
(or T const&).

You said yourself:
"A member function has a special calling syntax, and special access rights
to member data".
Also:
A member function must be called on an object , or it produces UB, a normal
function does not have this requirement.
A member function is declared in a class scope, a normal function is not.

How is that different from calling any other function which
takes a reference without an object that the function refers to?

What does a reference have to do with anything?

Why? It obeys exactly the same rules as a static member
function, or a free function.

Because the standard lays down some rules specific to NSMF's.
A nonstatic member function has different rules than a static member
function or ordinary function.

It most certainly is the same function. The standard requires
it.

The local variables,parameter and return value in function1 are not the same
as those in function2, they are two seperate processes .
Plus you have access rights to member data.
To what do you refer when you suggest the standard requires them to be the
same?

An implementation is certainly allowed to make as many copies of
the function as it wishes. Member or otherwise. On the other
hand, the standard requires that all pointers to the function
compare equal. Member or otherwise. Even if the implementation
makes many "copies" of the function (as it typically does if the
function is inline), it has to ensure that all of the pointers
to the function compare equal.

This is very close, if not identical, with the OO concept of
identity. In C++, if two addresses (of objects) compare equal,
they are the same object. Comparison of address is the way you
test identity in C++.

ok so with:

#include <iostream>
class Base1{public: virtual void foo()=0; virtual void bar()=0;};
class Derived: public Base1{
public:
void foo(){std::cout<<"in foo"<< std::endl;}
void bar(){std::cout<<"in bar"<< std::endl;}
};


int main()
{
void (Base1::*fp1)() =&Base1::foo;
void (Base1::*fp2)() =&Base1::bar;

Base1* b1=new Derived;
std::cout<< "fp1 points to: " << fp1 << std::endl;
std::cout<< "fp2 points to: " << fp2 << std::endl;
(b1->*fp1)();
(b1->*fp2)();
}

Does this not prove the address can be the same but the functions are
different?

 

[Paul]

It is correct.


Your understanding of the computer science term "text segment" is at
fault. A text segment is simply a portion of memory or an executable file
that contains executable code and of course is compatible with the flat
memory model; a text segment does not require a segmented memory model.

Hold on you make two different claims here:
A text segment is;
a) simply a portion of memory
b) an executable file that contains executable code.

Now before you said a function can only exist in the text segment, which of
your definitions were you referring to?

It is obvious to all that it is you who is lacking a clue.


You are confusing Intel memory segmentation and segment registers with
"text segments".

What do you think is the intended use of the CS register? To point to the
*drum roll* code segment. duh.
I'm not confised kid you are.

Are you stupid? Of course I know that the Z80A has no segment registers;
I couldn't not know this if I wrote an emulator for it.


Who claimed that the Z80A CPU has segment registers? I certainly didn't

There is nothing to stop you having an executable file format which
includes a "text segment" and a "data segment" on a Z80A system.

The above statement suggests you agree that z80 programs do not normally
have segmented executables.

This seems to be proof that your statement ref:
"Functions only exist as machine code in the text segment".
is incorrect.

From Wikipedia:

"In computing, a code segment, also known as a text segment or simply as
text, is a *phrase* used to refer to a portion of memory or of an object
file that contains executable instructions."

Notice how I have emphasized the word "phrase" above? "Text segment" is
phrase which you are incorrectly decomposing and taking the word "segment"
to be equivalent to "segment register" or Intel memory segmentation.

WTF are you talking about you confused little chicken?
A text segment is a segment of memory, intel CPU's use registers names CS,
DS, SS etc to address segments.
I never said the register was a segment but it is certainly related to the
same memory model.
A flat model can be implemented with a vritual representation of a segmented
memory model but the underlying memory is just one big chunk of memory.
The only different between memory segments is read/write/exec priveledge,
what is your big fuss about memory segmentation, not all programs use this
type of addressing.
As I said in one of my earlier post the old DOS COM file type, which most of
us are familiar with, has a tiny memory model and there is no segmentation
involved, same as the z80. Yes I suppose its possible there could be a
system created with segemntation for this model , but there isn't.

 

[James Kanze]

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?

The above states exactly the same thing for both class and object types.

They're both subsets. Yes. They're not the same subset.

So, barring functions, what isn't an object in the context of
the standards?

Functions, references, templates, types...

[...]

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.

'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.

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" (§4.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 §8; the beginning of §8 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.

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]

On 02/22/11 03:54 AM, Stuart Redmann wrote:

Considering this is purely a metaphysical discussion, c) is an equally
plausible description. On this box, a standard library function like
puts() has existed for the 47 days, 17 hours and a few minutes, since
the system booted and loaded libC into memory.

But is your puts() a different function than the one on my
machine? Are are they the same function? And if they are the
same, then you'd probably have to say that the function has
existed since some time in the 1970's, when it was written.

Of course, one could argue many other definitions of "exists"
for a function, as well. (Does a function "exist" when the
pages where it resides are swapped out?)

 

[James Kanze]

I don't see the source of the confusion here. This is very simple.

A member function's lifetime spans from the completion of its
constructor to the beginning of its destructor.

Functions don't have constructors or destructors. Since they
are neither objects nor references, they don't even have
lifetimes.

 

[James Kanze]

news:[email protected]...

news:0e0dc254-eccb-42aa-8ab7-35db4c4218e1@w21g2000yqm.googlegroups.com...

[...]

I don't quite follow you here. If I have a function:
void f(int&);
, it's undefined behavior for me to call f without a an object
of type int.
You must've forgot we are talking about *member functions*.
So what's the difference, with regards to your argument.
The difference is that the standard defines a rule for nonstatic member
functions. The same rule does not apply to normal functions.

The only difference defined by the standard is that nonstatic
member functions have an implicit first parameter, of type T&
(or T const&).

You said yourself:
"A member function has a special calling syntax, and special access rights
to member data".

Friend functions also have special access rights. And what if C++
had adopted a unified calling syntax (like IIRC Ada does)?
I don't see how syntax could make a difference.

Also:
A member function must be called on an object, or it produces UB, a normal
function does not have this requirement.

Yes it does, if it takes a reference to object parameter. All
non-static member functions have an implicit reference to object
parameter, but the requirement to be called with an object
depends on this parameter, not on the fact that they're
a member.

A member function is declared in a class scope, a normal
function is not.

And what does that have to do with anything? (For that matter,
I have non-member functions which are both declared and defined
in class scope.)

What does a reference have to do with anything?

Because that's how member functions behave: as if they had an
implicit first parameter which is a reference.

Because the standard lays down some rules specific to NSMF's.

Such as? What I'm pointing out is that there aren't any rules
specific to NSMF's.

A nonstatic member function has different rules than a static
member function or ordinary function.

The "rules" I think you're refering to depend on the types of
the function's parameters.

The local variables,parameter and return value in function1
are not the same as those in function2, they are two seperate
processes. Plus you have access rights to member data. To
what do you refer when you suggest the standard requires them
to be the same?

The standard specifies the semantics of function call. It
specifies them to be the same for both member and non-member
functions. A non-member function can also have access rights to
member data.

ok so with:

#include <iostream>
class Base1{public: virtual void foo()=0; virtual void bar()=0;};
class Derived: public Base1{
public:
void foo(){std::cout<<"in foo"<< std::endl;}
void bar(){std::cout<<"in bar"<< std::endl;}

};

int main()
{
void (Base1::*fp1)() =&Base1::foo;
void (Base1::*fp2)() =&Base1::bar;

Base1* b1=new Derived;
std::cout<< "fp1 points to: " << fp1 << std::endl;
std::cout<< "fp2 points to: " << fp2 << std::endl;
(b1->*fp1)();
(b1->*fp2)();
}

Does this not prove the address can be the same but the functions are
different?

How have you defined << for a pointer to member function.
Without any additional code, this shouldn't compile. (Curiously
enough, it does with both g++ and VC++. But in both cases, the
output is more or less arbitrary, and reading it back in won't
give you the same pointer.) Try adding
std::cout << "fp1 == fp2: " << (fp1 == fp2 ? "true" : "false") <<
std::endl;
to your code, and see what it says. If it says "true", your
compiler is not conformant. (Also, be wary of VC++ here. By
default, it's handling of pointer to member functions is broken.
You need the option /vmg for it to work. Not that it changes
anything here.)

 

[itaj sherman]

Functions don't have constructors or destructors. Since they
are neither objects nor references, they don't even have
lifetimes.

First of all, you trimmed half my paragraph. That might be misquoted.

Secondly, this is just my way of expressing that I tried my best. But
there's no way. It's all a waste of time. And it will troll on
forever.

itaj

 

[Paul]

First of all, you trimmed half my paragraph. That might be misquoted.


Secondly, this is just my way of expressing that I tried my best. But
there's no way. It's all a waste of time. And it will troll on
forever.

itaj

You selectively choose when you want to be strict in use of definitions from
the Standard, for example:
You made big post here someplace about how , in order to successfully
communicate we all must use terms as defined in the standard etc etc. Then
in another post you go on about how calling a member function is exaclty the
same as calling a normal function , which is in direct contradiction to the
standard: see my other thread.

If anyone is getting tired trying its me.

 

[itaj sherman]

You selectively choose when you want to be strict in use of definitions from
the Standard, for example:
You made big post here someplace about how , in order to successfully
communicate we all must use terms as defined in the standard etc etc. Then
in another post you go on about how calling a member function is exaclty the
same as calling a normal function , which is in direct contradiction to the
standard: see my other thread.

If anyone is getting tired trying its me.

LOL

 

[Paul]

news:[email protected]...

[...]
I don't quite follow you here. If I have a function:
void f(int&);
, it's undefined behavior for me to call f without a an object
of type int.
You must've forgot we are talking about *member functions*.
So what's the difference, with regards to your argument.
The difference is that the standard defines a rule for nonstatic
member
functions. The same rule does not apply to normal functions.
The only difference defined by the standard is that nonstatic
member functions have an implicit first parameter, of type T&
(or T const&).

You said yourself:
"A member function has a special calling syntax, and special access
rights
to member data".

Friend functions also have special access rights. And what if C++
had adopted a unified calling syntax (like IIRC Ada does)?
I don't see how syntax could make a difference.

With regards to all comments about member functions being the same as normal
function please use my other post on that subject.

How have you defined << for a pointer to member function.
Without any additional code, this shouldn't compile. (Curiously
enough, it does with both g++ and VC++. But in both cases, the
output is more or less arbitrary, and reading it back in won't
give you the same pointer.) Try adding
std::cout << "fp1 == fp2: " << (fp1 == fp2 ? "true" : "false") <<
std::endl;
to your code, and see what it says. If it says "true", your
compiler is not conformant. (Also, be wary of VC++ here. By
default, it's handling of pointer to member functions is broken.
You need the option /vmg for it to work. Not that it changes
anything here.)

--

Sorry I started playing around and the code got changed. I mean this:

#include <iostream>
class Base1{public: virtual void foo()=0; };
class Base2{public: virtual void foo()=0; };

class Derived: public Base1, public Base2{
public:
void foo(){std::cout<<"in foo"<< std::endl;}
};


int main()
{
void (Base1::*fp1)() =&Base1::foo;
void (Base2::*fp2)() =&Base2::foo;

Base1* b1 = new Derived;
Base2* b2 = new Derived;
(b1->*fp1)();
(b2->*fp2)();
}


Two addresses one function?


BTW Java sun docs are good references , I will look at that other post
later , when I have time.

 

[Paul]

I am referring to both of the above meanings when I use the term "text
segment". Your grasp of the English language is either very poor or you
are deliberately trying to corrupt what people say to try and strengthen
your own very weak position.

I'm not gonna bother getting into a nitpicky bickering about *your* bad use
of English .

Whilst there can be a correspondence between the "text segment" and a
"segment register" there doesn't have to be as not all systems have
segment registers.

You obviously don't know what a segment register is( note: its not intel
specific as you wrongly imply), I will explain :
Do you know what a flip-flop switch is? No.. ok well skip that part.
A segment register is 'a register' that holds the address of *fanfare* a
segment.
Any system with GPR's can have segment registers. What do you not understand
about the fact that any register can be used as a segment register?

It is obvious to all that it is you who is confused.


It suggests no such thing; it is simply a factual assertion; I will repeat
it:

There is nothing to stop you having an executable file format which
includes a "text segment" and a "data segment" on a Z80A system.

I have made it clear that z80 programs do not normally have this program
format .
You cannot disagree,because you don't know what you are talking about, so
instead you reply with "there is nothing to stop them doing that".

Obviously this is agreeing with the fact that they don't normally have this
program format. If you disagree with this fact, and knew what you were
talking about, you would've said why it was incorrect.

Whilst there can be a correspondence between "text segment" and "segment
register" and "segmented memory model" there doesn't have to be as not all
systems have segment registers or a segmented memory model. The term
"text segment" is not system specific; it is a general computer science
term.

The term text segment is only applicable in systems with that format of
program.

The term text segment does not exist on my z80 claculator, but I can still
make asm sub routines.

Again you are incorrectly assuming that the term "text segment" refers to
segment registers and a segmented memory model; it doesn't.

LOL
You are a confused little puppy.

<snip>

 

[Paul]

You continue to make it obvious to all that you have no clue.

It was *you* who brought up Intel segment registers not me; if a
particular CPU has segment registers then obviously the term "segment
register" refers to those registers not to a general purpose register that
happens to be holding the "address" of a segment; context is King. It was
*me* who told you that there does not have to be a correspondence between
"text segment" and a "segment register" for any sane definition of
"segment register".

I never mentioned intel.

There is a pattern emerging of you deliberately obfuscating your arguments
by using ambiguous terms which you change the meaning of when you are
losing the argument.

The pattern emerging is that I am teaching you so much about segments you
ought to be paying me.

 

[Paul]

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.

The Java documentation makes a clear definition of the term object I repost
the link as it seems to have been lost, 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."

This is absolutely clear, please don't try to confuse things by suggesting
its not the vocabularly used in the standards.

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.

'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.

Please do a word search for 'method' on this document.
http://www2.research.att.com/~bs/whatis.pdf

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.

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" (§4.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 §8; the beginning of §8 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.

James WTF are you talking about I have already provided a link that clearly
describes what an object is in Java.

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.

I once again refer to the Stroustrup paper I referenced above:

This document goes into great detail about this. I think it is clear that
Bjarne Stroustrup thinks C++ supports OOP, and I think most porgrammers
worldwide would agree.
Does it really make any difference to us if one or two smalltalk fantaics
disagree?

 

[Paul]

This sentence speaks volumes: it means you either have short term memory
problems or you are plain deceitful.


I don't believe that you have taught anyone anything whatsoever since you
started trolling in this newsgroup; you are simply a waste of
space/bandwidth.

Whatever Leigh,
Your trolling is creating and source of education for you, I no longer
support this FOC.

 

[Paul]

On 22/02/2011 17:00, Paul wrote:

If anybody paid you to do anything after seeing your posts in this
newsgroup then they, like you, need their head examining. Virtually all
your posts in this newsgroup have had no value whatsoever.

Please killfile me *again*.

No need to reply.

 

[James Kanze]

--"James Kanze" <[email protected]> wrote in message

<snip>

--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.

The Java documentation makes a clear definition of the term object I repost
the link as it seems to have been lost, refhttp://java.sun.com/docs/glossary.html#O:
"object
The principal building blocks of object-oriented programs. Each object isa
programming unit consisting of data (instance variables) and functionality
(instance methods). See also class."

This is absolutely clear, please don't try to confuse things by suggesting
its not the vocabularly used in the standards.

Except that the document you cite isn't part of the Java
specification. It's just a document that someone wrote, with no
official weight. (At least as I can see.) And it's
contradictory, since for member, it says "A field or method of
a class." No mention of object.

--*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.

Please do a word search for 'method' on this
document.http://www2.research.att.com/~bs/whatis.pdf

Done. First note that the article is 20 years old; it dates to
before Java corrupted the vocabulary. According to the
definition of method Stroustrup uses in it, Java doesn't have
methods, but (like C++) member functions. And while he might
not like it, I'd be very surprised if Stroustrup didn't take
this change in the meaning of method into account if he were
writing this today.

At any rate, it does sort of back up my intuitive feeling, that
Stroustrup chose the word member function rather than method
because it was radically different from a method in Smalltalk.

--The definition in the Java specification is "An object is
--a class instance or an array" (§4.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 §8; the beginning of §8 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.

James WTF are you talking about I have already provided a link that clearly
describes what an object is in Java.

You have not presented a link to the specification, as far as
I can see. You have presented a link to some list of
definitions (which even if it were in the specification, would
probably not be considered normative---although when the
specification is from a private company, rather than ISO, who
knows what is normative).

Usage varies. As I've said, my impression is that people from
a Smalltalk background do consider methods as belonging to
objects; people from a Simula (and C++) background don't. A lot
of people working on Java today come from a Smalltalk
background, because Smalltalk seems to be dying, and they
consider Java (everything derives from Object, etc.) a better
substitute than C++. And of course, Java has "methods", and not
"member functions" (even if its methods behave more like C++
member functions than like Smalltalk methods).

--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.

I once again refer to the Stroustrup paper I referenced above:

This document goes into great detail about this. I think it is clear that
Bjarne Stroustrup thinks C++ supports OOP, and I think most porgrammers
worldwide would agree.
Does it really make any difference to us if one or two smalltalk fantaics
disagree?

They're a vocal community.

My only real point, of course, is that people disagree largely
in their definition of OOP, and saying C++ is (or supports) OOP
using one definition of OOP, then trying to use definitions
derived from a community which uses a radically different
definition of OOP, is going to result in some contradictions.

 

[James Kanze]

"itaj sherman" <[email protected]> wrote in message

You are probably correct, I find it difficult to think about member
functions without objects.

And yet, you declare them in a class definition, not in an
object definition.

Seriously, I don't see any real problem in speaking of functions
being members of an object, even in C++, *IF* you're speaking
informally. But if you speak formally, C++ uses a fairly
extensive static type system: what determines the legality of an
operation on an object is defined by that object's type.
A member function may only be called on an object with a class
type of which it is a member. But that's because the object has
that specific type. (You wouldn't say that the + operator is
a member of an int object, would you? It's an operation defined
on int.)

 

[Paul]

--"James Kanze" <[email protected]> wrote in message

<snip>

--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.

The Java documentation makes a clear definition of the term object I
repost
the link as it seems to have been lost,
refhttp://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."

This is absolutely clear, please don't try to confuse things by suggesting
its not the vocabularly used in the standards.

--Except that the document you cite isn't part of the Java
--specification. It's just a document that someone wrote, with no
--official weight. (At least as I can see.) And it's
--contradictory, since for member, it says "A field or method of
--a class." No mention of object.

Don't be unresonable, its the official Java documentation. From what is now
the oracle site

If a member of a class is nonstatic it logically follows it is also a menber
of an object instanciated from the class. This is not a contradicition.

--*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.

Please do a word search for 'method' on this
document.http://www2.research.att.com/~bs/whatis.pdf

--Done. First note that the article is 20 years old; it dates to
--before Java corrupted the vocabulary.

-- According to the
--definition of method Stroustrup uses in it, Java doesn't have
--methods, but (like C++) member functions. And while he might
--not like it, I'd be very surprised if Stroustrup didn't take
--this change in the meaning of method into account if he were
--writing this today.

--At any rate, it does sort of back up my intuitive feeling, that
--Stroustrup chose the word member function rather than method
--because it was radically different from a method in Smalltalk.

Yes ok but it's still generally accepted that member function( in C++ ) and
method(in other langs) is interchangeable when comparing the languages

--The definition in the Java specification is "An object is
--a class instance or an array" (§4.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 §8; the beginning of §8 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.

James WTF are you talking about I have already provided a link that
clearly
describes what an object is in Java.

--You have not presented a link to the specification, as far as
--I can see. You have presented a link to some list of
--definitions (which even if it were in the specification, would
--probably not be considered normative---although when the
--specification is from a private company, rather than ISO, who
--knows what is normative).

It's the official Java documentation, cmon get serious , its a perfectly
acceptble link.


--Usage varies. As I've said, my impression is that people from
--a Smalltalk background do consider methods as belonging to
--objects; people from a Simula (and C++) background don't. A lot
--of people working on Java today come from a Smalltalk
--background, because Smalltalk seems to be dying, and they
--consider Java (everything derives from Object, etc.) a better
--substitute than C++. And of course, Java has "methods", and not
--"member functions" (even if its methods behave more like C++
--member functions than like Smalltalk methods).

--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.

I once again refer to the Stroustrup paper I referenced above:

This document goes into great detail about this. I think it is clear that
Bjarne Stroustrup thinks C++ supports OOP, and I think most porgrammers
worldwide would agree.
Does it really make any difference to us if one or two smalltalk fantaics
disagree?

--They're a vocal community.

--My only real point, of course, is that people disagree largely
--in their definition of OOP, and saying C++ is (or supports) OOP
--using one definition of OOP, then trying to use definitions
--derived from a community which uses a radically different
--definition of OOP, is going to result in some contradictions.

I believe that argument is reserved for extreme fanatics, the *normal*
programming community are more relaxed with their ideas of OOP concepts.

 

[Paul]

And yet, you declare them in a class definition, not in an
object definition.

Yes
When I create a class though, I write it as though I am defining a template
for for an object. I consider static members as exceptions to the norm.
Technically it could be said that a class is a precompile time object +
static members.
So because of this to state something is a member of a class it is often
implied that it is also a member of the instanciated object of that class.
Everytime a document defined something as a member of a class, it would be
very impracticacle to also add (and object instances of that class)
everwhere this was the case.

Seriously, I don't see any real problem in speaking of functions
being members of an object, even in C++, *IF* you're speaking
informally. But if you speak formally, C++ uses a fairly
extensive static type system: what determines the legality of an
operation on an object is defined by that object's type.
A member function may only be called on an object with a class
type of which it is a member. But that's because the object has
that specific type. (You wouldn't say that the + operator is
a member of an int object, would you? It's an operation defined
on int.)

But even speaking formally , when we say something like "a NSMF is a member
of an Object". It is obvious from the context that we mean an object(as an
instance of a class type).
To say that this is incorrect has no supporting evidence because the C++
standard does not suggest this.
As I have said before I think it is not in the interest of C++ to strictly
state this as it would suggest C++ does not support OOP, IMHO.
I can't see any problem with using this term as long as it's clear from the
context the meaning of 'object'.

I remeber having this gripe with the standards use of 'object' many years
ago. I think its totally ridiculous that they use this word , in a different
meaning from its common meaning, when it is such a commonly used word in the
realm of modern computer programming. It's not as if there is a shortage of
words in the english vocabularly and if necessarry they could even create a
new word , but why hyjack this word?
Or is it a case that following from old C they used it first?
So my conclusion is that whilst they are drafting this new C++0x thing , why
not sort all these issues(size_t etc and there's bound to be a few more) and
just release a new version of C++?
Make a compiler switch for backward compatability and compiling old code..
Or at least make a plan for this when 64-bit programs are the norm.

 

[Paul]

The default "context" of this newsgroup is C++; in C++ an object is simply
a region of storage.

If this is an attempt to irritate me then its simply another one of your
trollings.

You are, of course, incorrect but there is nothing new there.
The beauty of Leighs posts is how he manages to make so many errors in such
a short string of words.

Firstly to say this newsgroup has a default *context* is bad english unless
the words 'this newsroup' are used as part of a larger statement.
Secondly you either misinterpret the standard or you are trying to make your
own definition by changing the definition of an 'object' from that defined
in the C++ standard..