Is it legal code?

[Paul]

I am, of course, correct and you are, of course, incorrect yet again.


What errors?


No; the default "context" of this newsgroup is the C++ language as defined
by the C++ Standard so when one uses the term "object" without
qualification (and the context of a post doesn't indicate otherwise) one
is using the term "object" as defined by the C++ Standard.

No. The *topic* of this newsgroup is the C++ langauge, as defined by the C++
standard.
This does not mean the use of language outside the context of the C++
standard are disallowed.
The default language of this newsgroup is English, not some fictional
standardesque language.

The C++ Standard's definition of an object is "a region of storage" ergo
in C++ an object is simply a region of storage.

In the context of the C++ standard the word 'object' is defined as 'a region
of storage'. This however does not translate to 'simply a region of storage'
or 'a simple region of storage'.
It could be a complex region of storage. You are a proven serial
misinterpreter, please stop trolling.

Please try to understand the two completely different contexts:
1) The context of text in the C++ standard is to construct a document to
define the langauge.
2) The context of our posts in this newsgroup is general discussions on the
C++ language.

 

[Paul]

Correct.;

I know

the topic of this newsgroup is equivalent to the default "context" of
posts in this newsgroup.

Your wording is erroneous , "default context" is a bit of an oxymoron
(fitting).

Of course not; Certainly

however one must qualify a term if the term means other than what it means
in the C++ Standard if the post's context does not do this; you seem to
thrive on ambiguity however.

The standard defines some terms but they are only defined for use within the
standard.
Obviously any use of these terms outwith the standard is undefined(by the
standard).

Correct; it certainly isn't Welsh.


You have just misinterpreted what I said and you call me a misinterpreter;
this is either blatant hypocrisy or you are an idiot of the highest order.
How can "simply a region of storage" possibly mean "a simple region of
storage"? I would be surprised if English was your first language.

In C++ an object is simply a region of storage.

Nonsense:
int x;
is 'x' an object?
Nothing is stored there.

Its not *simply* a region of storage. .

You are attempting to over-simplify the standards definition of a C++
object. If the word 'object ' is used in the context of ...
'an objects member data', it is obvious the intended meaning of an object
is...... an instance of a class type.

The C++ standards definiton of an object is very complex and it is not
written in such a way that it should be interpetation as:
an object is simply a region of storage. PERIOD(excuse the american lingo)

The standard follows up on this definiton with many additional clauses and
sub clauses.

Correct.

I know.

As defined by the C++ Standard which defines a set of terms which we use
in this newsgroup; without a common frame of reference there would be more
noise than even you are causing.

No.
The context of our posts in this newsgroup is general discussion of the C++
language. PERIOD.

The addition of "as defined by the C++ standard" does not apply here because
we are talking about the context of our posts, not the topic of the
newsgroup.
The C++ standard does not define the terms we use in our discussion, it
defines terms as used in the standard itself.

 

[Öö Tiib]

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

It talks about methods not member functions.

[...]
/////////////////////////////////////////////////////////////////////////// //////////////
dam indenting again
/////////////////////////////////////////////////////////////////////////// ///////////////

That to me is an ignorant reply. A method is generally accepted to mean the
same thing as a member function(nonstatic respectively implied)

"Method" is OOP term that i think was originally about Smalltalk style
OOP where "method" was invoked when object received a message. Then
Sun did screw all terminology up making quite C++ like member
functions and calling them "methods". So perhaps at the moment indeed
there are no difference anymore.

Now that is a good article of how contradicting and dim the views
about OOP are. I try to pick a quote there:

<quote>
By contrast, the object-oriented approach encourages the programmer to
place data where it is not directly accessible by the rest of the
program. Instead the data is accessed by calling specially written
'functions', commonly called methods, which are either bundled in with
the data or inherited from "class objects" and act as the
intermediaries for retrieving or modifying that data.
</quote>

Yes, so in C++ we have member functions inherited from class instead
of methods bundled in with the data. Class is type. There are no
reflection in C++ and no "class objects" in C++. Instead one can get
some sort of typeid that is a dim implementation-specific thing or
mess with templates to attach traits to types. Still that "member
function" of C++ is close enough to "method" of OOP to call it "OOP
support".

/////////////////////////////////////////////////////////////////////////// ////////////////////////////
I don't see what you are trying to state here. I understand that text on OOP
perfectly; It describes the concept of data protection and accessor
functions.
Why is it contradicting and dim?

Because it say that the methods may be either inherited from classes
(like in C++ or Java) or be bundled together with data (like in
Javascript) and yet you "understand it perfectly" and yet you continue
to argue that member functions are somehow bundled with data in C++.
So it is too dim and contradicting and anyone can read what he wants
from it.

When you speak of methods "bundled" with objects , this is an OOP concept..

There are two different alternative styles: methods "bundled" with
types of objects and methods "bundled" with data of objects. C++ is
quite explicit about objects consisting of data (storage) and member
functions being part of class (type).

If the programming language supports OOP then it has mechanisms which
support this concept, it doesn't really matter what the underlying technical
implementations are.

It is not about underlying mechanics. It is about different styes of
OOP.

The C++ language is defined in such a way that if a class declares a
nonstatic method then this method will be available as a member of an
object(instance of the class).

You repeat and repeat that. It does not make that more true. The
objects of class type may have only "member subobjects" and "base
subobjects" by C++ standard. If you need "method subobjects" then you
perhaps make some "member subobjects" of functor type (with operator()
() overloaded) or may be use boost::bind() to bind some functionality
to object. Function pointers and member function pointers are also
possibility but these have so nasty syntax that first novice
maintainer will eyeball it for some hours and then run away crying.
Member functions however are part of class and inherited from class
and class is not object in C++.

Note: deliberate use of method here to emphasise the association with OOP..

The C++ standard cannot fully define the mechanisms because it chooses to
leave this up to the implementation, for a good reason. If the C++ standard
was to try and define this for every possible and future computer system ,
it would need to be rewritten before it was drafted for comments.

Actually C++ standard is grown so fat of quirks and details that there
are not so lot of freedom in implementation like you seem to suggest.
Borland does still compile only subset of C++ and for Microsoft it
took years to get C++ to compile more or less.

 

[Joshua Maurice]

Really guys - Ian, James, Leigh, why are we still talking with Paul?
It's the same argument he's been stirring up since he's been here,
with little to no resolution. It took me a while myself to recognize
that he is beyond reason, but surely you all know this by now.

Also, one minor legitimate question, after reading all of this. Are
suicide member functions UB? Ex:

class T
{
public:
void delete_me() { delete this; }
};
int main()
{
T* x = new T;
x->delete_me();
}

What about the following code, which I'm sad to say I've seen in real
production code:
class T
{
public:
//not static
T* create() { return new T; }
};
int main()
{
T* x = 0;
x = x->create();
}

The second is horrible atrocious code, whereas the first example is at
best sketchy. This is Paul's original question, I think, and I really
haven't been able to parse an answer to that question out of this
discussion.

 

[Paul]

Yes 'x' is an object; 'x' is an uninitialized object.

If no data is stored there how can your next statement also be true?

 

[Paul]

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

It talks about methods not member functions.

[...]
///////////////////////////////////////////////////////////////////////////
//////////////
dam indenting again
///////////////////////////////////////////////////////////////////////////
///////////////

That to me is an ignorant reply. A method is generally accepted to mean
the
same thing as a member function(nonstatic respectively implied)

--"Method" is OOP term that i think was originally about Smalltalk style
--OOP where "method" was invoked when object received a message. Then
--Sun did screw all terminology up making quite C++ like member
--functions and calling them "methods". So perhaps at the moment indeed
--there are no difference anymore.

Now that is a good article of how contradicting and dim the views
about OOP are. I try to pick a quote there:

<quote>
By contrast, the object-oriented approach encourages the programmer to
place data where it is not directly accessible by the rest of the
program. Instead the data is accessed by calling specially written
'functions', commonly called methods, which are either bundled in with
the data or inherited from "class objects" and act as the
intermediaries for retrieving or modifying that data.
</quote>

Yes, so in C++ we have member functions inherited from class instead
of methods bundled in with the data. Class is type. There are no
reflection in C++ and no "class objects" in C++. Instead one can get
some sort of typeid that is a dim implementation-specific thing or
mess with templates to attach traits to types. Still that "member
function" of C++ is close enough to "method" of OOP to call it "OOP
support".

///////////////////////////////////////////////////////////////////////////
////////////////////////////
I don't see what you are trying to state here. I understand that text on
OOP
perfectly; It describes the concept of data protection and accessor
functions.
Why is it contradicting and dim?

--Because it say that the methods may be either inherited from classes
--(like in C++ or Java) or be bundled together with data (like in
--Javascript) and yet you "understand it perfectly" and yet you continue
--to argue that member functions are somehow bundled with data in C++.
--So it is too dim and contradicting and anyone can read what he wants
--from it.

No I'm not arguing that member functions are somehow bundled in with data in
C++.

When you speak of methods "bundled" with objects , this is an OOP concept.

--There are two different alternative styles: methods "bundled" with
--types of objects and methods "bundled" with data of objects. C++ is
--quite explicit about objects consisting of data (storage) and member
--functions being part of class (type).

OOP is a programming style(programming paradigm). You are highlighting
different ways of implementing OOP.

If the programming language supports OOP then it has mechanisms which
support this concept, it doesn't really matter what the underlying
technical
implementations are.

--It is not about underlying mechanics. It is about different styes of
--OOP.

I think OOP already is a programming style.I dont understand what you mean
by different styles of OOP.

The C++ language is defined in such a way that if a class declares a
nonstatic method then this method will be available as a member of an
object(instance of the class).

--You repeat and repeat that. It does not make that more true.

Do you mean you think its incorrect(not true)?

-- The objects of class type may have only "member subobjects" and "base
--subobjects" by C++ standard. If you need "method subobjects" then you
--perhaps make some "member subobjects" of functor type (with operator()
--() overloaded) or may be use boost::bind() to bind some functionality
--to object. Function pointers and member function pointers are also
--possibility but these have so nasty syntax that first novice
--maintainer will eyeball it for some hours and then run away crying.
--Member functions however are part of class and inherited from class
--and class is not object in C++.

To save repitition I define my meaning of 'object' from now on to mean: an
instance of class type, unless I state otherwise.

When you say "an object is not a class" you seem to completely dissassociate
the two terms(object and class). An object is a runtime entity, a class is
precompile time entity and these two entities are intimately related in C++.
A class is the template for an object(exception of statics) so any nonstatic
members declared in a class will also be member of an object of that
class-type.
Please can you explain why you have a problem with this analogy.

Note: deliberate use of method here to emphasise the association with OOP.

The C++ standard cannot fully define the mechanisms because it chooses to
leave this up to the implementation, for a good reason. If the C++
standard
was to try and define this for every possible and future computer system ,
it would need to be rewritten before it was drafted for comments.

--Actually C++ standard is grown so fat of quirks and details that there
--are not so lot of freedom in implementation like you seem to suggest.
--Borland does still compile only subset of C++ and for Microsoft it
--took years to get C++ to compile more or less.

 

[Paul]

Really guys - Ian, James, Leigh, why are we still talking with Paul?

<plonk -snip>

 

[Paul]

What do you not understand? I thought I was clear:

I understand perfectly that you are trolling a perfectly legit thread.

int x;

'x' is an object; 'x' is an uninitialized object.

'x' is a region of storage; 'x' is an uninitialized region of storage.

You don't understand that if it doesn't store anything it can't be a region
of storage.
It can be a region put aside for storage, but its not a region of storage.

 

[Paul]

When you say "an object is not a class" you seem to completely
dissassociate the two terms(object and class). An object is a runtime
entity, a class is precompile time entity and these two entities are
intimately related in C++. A class is the template for an object(exception
of statics) so any nonstatic members declared in a class will also be
member of an object of that class-type.
Please can you explain why you have a problem with this analogy.

++++++++++ If you do have a problem with it+++++++++++++++++++
<snip>

 

[red floyd]

Really guys - Ian, James, Leigh, why are we still talking with Paul?
It's the same argument he's been stirring up since he's been here,
with little to no resolution. It took me a while myself to recognize
that he is beyond reason, but surely you all know this by now.

Why?

http://xkcd.com/386/

 

[Öö Tiib]

--There are two different alternative styles: methods "bundled" with
--types of objects and methods "bundled" with data of objects. C++ is
--quite explicit about objects consisting of data (storage) and member
--functions being part of class (type).

OOP is a programming style(programming paradigm). You are highlighting
different ways of implementing OOP.

There are several OOP styles that have some things in common. The
styles with static strong types are called class-oriented the styles
with dynamic types are called prototype-oriented. OOP itself is style
(or sub-paradigm) of Structured Programming.

--You repeat and repeat that. It does not make that more true.

Do you mean you think its incorrect(not true)?

"member of object" sounds like "part of object". Every C++ object has
type. That type is not part of object, it is like meta-information
about object. If it is class type then the member functions of type
are available to object. I am unsure about them being therefore
members of object. For me they remain still members of class.

-- The objects of class type may have only "member subobjects" and "base
--subobjects" by C++ standard. If you need "method subobjects" then you
--perhaps make some "member subobjects" of functor type (with operator()
--() overloaded) or may be use boost::bind() to bind some functionality
--to object. Function pointers and member function pointers are also
--possibility but these have so nasty syntax that first novice
--maintainer will eyeball it for some hours and then run away crying.
--Member functions however are part of class and inherited from class
--and class is not object in C++.

To save repitition I define my meaning of 'object'  from now on to mean: an
instance of class type, unless I state otherwise.

When you say "an object is not a class" you seem to completely dissassociate
the two terms(object and class).

I said "class is not object". In most OOP languages (where there are
classes) the classes are objects of special type, but unfortunately
not in C++. I am not denying relations only that "object has a class"
is somewhat different from "object is a class".

An object is a runtime entity, a class is
precompile time entity and these two entities are intimately related in C++.
A class is the template for an object(exception of statics) so any nonstatic
members declared in a class will also be member of an object of that
class-type.
Please can you explain why you have a problem with this analogy.

It is only the little issue that it may feel from such description
that each object of same class will have its own member functions
based on that template. In reality if you take pointers to same member
functions of different objects of same type then these do compare
equal. The member functions belong to something that is shared between
objects. That is the class. Each instance has that class as its type
and that makes the member functions callable.

 

[Joshua Maurice]

Why?

http://xkcd.com/386/

Too true, too true. I suffer from that as well, hence my lasting
participation in previous thread /of exactly the same subject and
arguments/. However, even I reach a point where it's no longer in my
enjoyment to have discussions with a wall.

I suppose everyone else is welcome to talk with Paul. However, for the
time being, if I see him flagrantly wrong somehow somewhere, once per
thread I'll post a quick correction and a disclaimer that he is a
troll, and everyone would do their best to ignore him. I don't know
how trolls really operate, and if he is acting maliciously or out of
pure ignorant bliss. Either way I have no better recourse.

 

[Paul]

--There are two different alternative styles: methods "bundled" with
--types of objects and methods "bundled" with data of objects. C++ is
--quite explicit about objects consisting of data (storage) and member
--functions being part of class (type).

OOP is a programming style(programming paradigm). You are highlighting
different ways of implementing OOP.

--There are several OOP styles that have some things in common. The
--styles with static strong types are called class-oriented the styles
--with dynamic types are called prototype-oriented. OOP itself is style
--(or sub-paradigm) of Structured Programming.

Ok fair enough, I tend not to get that deeply involved in styles of styles
of styles

--You repeat and repeat that. It does not make that more true.

Do you mean you think its incorrect(not true)?

--"member of object" sounds like "part of object". Every C++ object has
--type. That type is not part of object, it is like meta-information
--about object. If it is class type then the member functions of type
--are available to object. I am unsure about them being therefore
--members of object. For me they remain still members of class.

The term 'member of an object' is perfectly acceptable in C++.
I think it's a very clear and concise term, and it doesn't imply the
function code is stored inside the object, very rare occasssions when
someone's gonna be daft enough to think that.
..

-- The objects of class type may have only "member subobjects" and "base
--subobjects" by C++ standard. If you need "method subobjects" then you
--perhaps make some "member subobjects" of functor type (with operator()
--() overloaded) or may be use boost::bind() to bind some functionality
--to object. Function pointers and member function pointers are also
--possibility but these have so nasty syntax that first novice
--maintainer will eyeball it for some hours and then run away crying.
--Member functions however are part of class and inherited from class
--and class is not object in C++.

To save repitition I define my meaning of 'object' from now on to mean: an
instance of class type, unless I state otherwise.

When you say "an object is not a class" you seem to completely
dissassociate
the two terms(object and class).

--I said "class is not object". In most OOP languages (where there are
--classes) the classes are objects of special type, but unfortunately
--not in C++. I am not denying relations only that "object has a class"
--is somewhat different from "object is a class".

I have only used Java and C++, both these languages have the same basic
'class is a template for an object' principle.
I used Javascript too but thats a scripting language and a bit odd

I have never considered a class as an object exception of Java binaries, but
thats a completely different runtime thought process. Inner workings of JVM
etc :-S arghh too early for that.

An object is a runtime entity, a class is
precompile time entity and these two entities are intimately related in
C++.
A class is the template for an object(exception of statics) so any
nonstatic
members declared in a class will also be member of an object of that
class-type.
Please can you explain why you have a problem with this analogy.

--It is only the little issue that it may feel from such description
--that each object of same class will have its own member functions
--based on that template.
It does, in a way.
You need to think of a function as a sub-process and not as a block of
memory.
And also with:
obj.membfunct();
The syntax implies the function is a member of the object.

--In reality if you take pointers to same member
--functions of different objects of same type then these do compare
--equal. The member functions belong to something that is shared between
--objects. That is the class. Each instance has that class as its type
--and that makes the member functions callable.


It could be said that the relationship between :
One class(definition)-> Many objects(runtime concept). /*if this is
acceptable*/
is very similar to:
One set of function opcodes(definiton) -> Many function invocations(runtime
concept)./*Why is this not acceptable?*/


Ty
Paul.

 

[James Kanze]

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

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

I don't think it is. At least I saw nothing at the site to
suggest that it was part of the official specification.

From what is now the oracle site

There is a lot on Java at that site. All the way from the
official specification to tutorials.

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.

I have no problem with using the wording "member of object"
informally, with the sense of "member of the type of the
object". There is obviously a link: the type of an object
defines the set of legal operations on it, and the set of
possible states.

[...]

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

This harks back to the discussion on the meaning of STL.
Originally (and clearly in Stroustrup's mind in 1991), there was
a clear distinction between member functions and methods; Alan
Kay (the inventor of Smalltalk) also insists on the difference
(and doesn't consider C++ or Java "OO" languages). As you say,
however, most people use the terms as synonyms, and we've lost
an important distinction in the language.

[...]

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

I'm not even sure that the "normal" programming community has
any opinions on OO, or even knows what it might be. People who
have learned OO through C++ obviously consider it an OO
language; a lot of people who learned OO through Java or C#
probably do as well. As does Booch. Bertrand Meyers, and most
of the Eiffel community along with him, doesn't. And Alan Kay
(who was the first to use the term) and the Smalltalk community
don't either. I think, in fact, that most OO fanatics would
deny that C++ supports OO (since they often seem to confuse
"supports" and "imposes").

 

[James Kanze]

[...]

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

Because those are the only types of objects which can have
member functions (in C++---other languages, like CLOS, have
fundamentally different concepts).

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.

The C standard did use object in its (then) commonly accepted
meaning. It's the OO group which have restricted the
meaning.

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?

They followed from C. The C++ object model, for everything but
non-POD class types, is meant to be exactly the same as that of
C.

 

[Paul]

I don't think it is. At least I saw nothing at the site to
suggest that it was part of the official specification.

I don't give a **** what you think , its an official document you are being
unreasonable ,.

ANd I cannot be fuckin arsed with the idiots in this newsgroup anymore.

goodbye.

 

[Paul]

[...]

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

Because those are the only types of objects which can have
member functions (in C++---other languages, like CLOS, have
fundamentally different concepts).

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.

The C standard did use object in its (then) commonly accepted
meaning. It's the OO group which have restricted the
meaning.

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?

They followed from C. The C++ object model, for everything but
non-POD class types, is meant to be exactly the same as that of
C.

I have concluded that you are incapable of a reasonable debate.

I wonder why you people are so ridiculously unreasonable all the time, is it
because you don't want to come to the turth because you are afraid of what
you might find there?


I simply trash you because I am sick of your unreasonablness.

 

[Gerhard Fiedler]

It could be said that the relationship between :
One class(definition)-> Many objects(runtime concept). /*if this is
acceptable*/
is very similar to:
One set of function opcodes(definiton) -> Many function invocations(runtime
concept)./*Why is this not acceptable?*/

If you said this, it probably would be accepted by most. But that's not
what you are saying (so far, at least).

If you said "a function invocation is, sort of, a 'member' of an object"
-- there is something to it. But it is way outside the C++ standard, and
more a very personal terminology and way of thinking of how OOP
principles can be implemented in C++.

But what you are saying is "a function is a member of an object",
equating "function invocation" (from your analogy above) with "function"
(from your previous posts).

The step that probably most have some difficulty with is when you equate
"function invocation" and "function". Most C++ programmers probably
associate "function" (when used alone) with "function definition" --
which, if you plug it into the analogy above, makes the "function" the
"function definition", therefore part of the class.

Gerhard

 

[Paul]

If you said this, it probably would be accepted by most. But that's not
what you are saying (so far, at least).

If you said "a function invocation is, sort of, a 'member' of an object"
-- there is something to it. But it is way outside the C++ standard, and
more a very personal terminology and way of thinking of how OOP
principles can be implemented in C++.

A function instance is a viable entity according to the C++ standard ref:
"3 An entity is a value, object, subobject, base class subobject, array
element, variable, function, instance of a
function, enumerator, type, class member, template, or namespace."

What exactly is meant by this is unclear to me , it could be something to do
with inline functions and not what it appears to mean.

But what you are saying is "a function is a member of an object",
equating "function invocation" (from your analogy above) with "function"
(from your previous posts).

The step that probably most have some difficulty with is when you equate
"function invocation" and "function". Most C++ programmers probably
associate "function" (when used alone) with "function definition" --
which, if you plug it into the analogy above, makes the "function" the
"function definition", therefore part of the class.

I also generally think of a function as a sequence of opcodes in memory(
function definition), however that is not the *only* way I can think of a
function.
I am also able to think of a function as a sub-process, a runtime entity.
Most of the people here who argue with me seem to lack this ability.

I don't know if you are just another one who will say anything to stick
with the majority or if you have a mind of your own so I do not direct the
following at you:
Those who have argued against me so far have shown nothing more than the
ability to repeatedly state misinterpretations form the standard. They have
provided no reasonable explanation to suggest why a member function cannot
be considered part of an object. They repeatedly quote from the standard
about classes, obviously a pre-compile time entity, and apply this to a
runtime entity.
Most of their references to the C++ standard are out of context, as you seem
to understand the standard does not say alot about the runtime rules. They
are obviously unable to understand the very basic concept of a function as a
sub-process, so I see no point in further arguing with them as I consider
them idiots tbh.

 

[Öö Tiib]

I also generally think of a function as a sequence of opcodes in memory(
function definition), however that is not the *only* way I can think of a
function.
I am also able to think of a function as a sub-process, a runtime entity.
Most of the people here who argue with me seem to lack this ability.

That is perfectly valid to think about function invocations as part of
process. However on one hand an object is not that process or part of
it (so how can such invocation be part of object?) and on other hand
same function may be invoked hundreds of times during program run from
different parts of process (so function feels not a single thing but
whole cloud of invocations by that view).