A suggestion

[Ulrich Eckhardt]

How can the reason a member function exists in C++ not be relevant.

This may be of historic relevance to the standard, but it is irrelevant
inside the standard itself. For a standard to be worth its money, it must
be internally consistent. In order to achieve that, any terms that might
be ambiguous must be defined first, so that any ambiguities are resolved.
This is necessary because later definitions based on other earlier
definitions would otherwise suffer in precision, too.

The C++ object model *is* restriced , not by me , by the fact the C++
standard does not go into implementation specifics.

Not requiring any specific implementation is actually freedom, not
restriction. What are you trying to say here?

The tiny piece of the document that describes the C++ object model
is by no means a complete description of how C++ objects work.

Yes it is, and for above reason it must be. Otherwise any opinion on what
is or is not an object would be relevant to the interpretation of the
standard. In order to be free of such interpretation variance, the
standard first defines its terms.

Additionally the C++ standard cannot and never will state that a member
function is not a member of an object.

Concerning the C++ object model, it can, should and does. Concerning other
uses of that term, it can't and doesn't.

The C++ is does not define an object in an opposite context from an OOP
object,

Yes it does.

the C++ is very carefull not to do this becuase it would directly
imply C++ did not support OOP.

No, that does not follow. Different contexts, different meanings.

I don't need to know what the rest of the standards say, and by the
looks of thing I don't want to if they cannot make a clear distintion
between objects of a UDT and objects at compiler level.

So here you finally admit that there are two different meanings to the
term object. So why can the C++ standard not choose one of them? In any
case, it is very narrow-minded and arrogant to say that you don't need to
know the rest but still understand the full picture. You need to
understand a much bigger part of the picture and leave the OOP picture out
of it first before you can argue about it.

Im not changing any context. Im talking cleary about objects in the
sense of OOP.

Yes, that means you are very clearly changing the context, since the
statement you falsely tried to refute was made in the context of the C++
object model.

A member function is called so because it is a member of a object.

You are aware of the distinction between static and non-static member
functions? This distinctions is made between these functions that are part
of a class. BTW: In OOP jargon, there are no member functions, the closest
to them are methods. Maybe there's a reason for that difference?

What else is would it be a member of? Do you want to suggest its a
member of a class again, please do so I can once again prove that a C++
class doesn't even exist at runtime.

Neither do OOP objects or functions, your "proof" isn't even one. You have
been shown to similarities between functions and memberfunctions in C++
code. After compilation, the remaining differences will be gone
completely, just to illustrate your invalid argument further.

The very fact that you call me a troll is in itself an insult ,
I have not insulted you and to suggest I have been violent towards
you is just laughable.

Okay, let's assume that you didn't...

When I have a large group of morons all ganging up on me and not only
insulting me , but my recently dead mom, and continuing to insult her
after I said.
I am quite within my right to give some back. So don't give me that one
sided nonsense.
And also you seem to forget the original argument that started with
numerous insults towards me.

....so why justify that you did? BTW, can you quote where I called you a
troll? If not, I expect an excuse for this, because your claim would then
be a lie.

 

[Stuart Redmann]

Stuart Redmann wrote:
[snip]

AFAIS this would be some kind of dynamic/multiple instance linkage
which is not covered by the C++ standard. This is no longer C++.

The question is whether the C++ standard does not cover it or whether
it makes some statements that would actually forbid such a feature. As
I don't have a copy of the standard I have to rely on the kindness of
others who can look this up for me.

Regards,
Stuart

 

[James Kanze]

You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

 

[Paul]

This may be of historic relevance to the standard, but it is irrelevant
inside the standard itself. For a standard to be worth its money, it must
be internally consistent. In order to achieve that, any terms that might
be ambiguous must be defined first, so that any ambiguities are resolved.
This is necessary because later definitions based on other earlier
definitions would otherwise suffer in precision, too.

If you think something is of no relevance to the standards , why do you
persist in talking about the standard.
Why don't you talk about the subject in hand instead of continually blabbing
on about your holy standards? This is not std.c++.

Not requiring any specific implementation is actually freedom, not
restriction. What are you trying to say here?

Here you twist things around to suggest that C++ has the freedom to not
require any implementation. Don't speak rubbish, the implementation comes
first in any program design.
The C++ standard does not go into any details about implementation specific
C++, this does not mean that implementation specific C++ is, illegal or
unworthy of any discussion.
You are restricting the the discussion to the scope of the C++ standards.

Yes it is, and for above reason it must be. Otherwise any opinion on what
is or is not an object would be relevant to the interpretation of the
standard. In order to be free of such interpretation variance, the
standard first defines its terms.

C++ is not *free* as you wrongly imply. C++ does not exist unless there is
an implemenntation to deploy it on.
If there is no implementation there is no C++, its simple as that.

Concerning the C++ object model, it can, should and does. Concerning other
uses of that term, it can't and doesn't.

No you are wrong. The C++ standard does not go into any details about the
mechanics of calling member functions. Therefore the C++ standard does not
fully define the implementation of a C++ program on any given
implementation.

Yes it does.

Can you quote where it does ?
Or is this just another negative unjustified meaningless statement you are
making?

No, that does not follow. Different contexts, different meanings.

Of course it follows. It's obvious C++ *must* support mechanics that support
OOP. Otherwise C++ does not support OOP.

So here you finally admit that there are two different meanings to the
term object.

I don't finally admit anything, I have never disputed the fact that the
standards used the term object in a different context.

So why can the C++ standard not choose one of them? In any
case, it is very narrow-minded and arrogant to say that you don't need to
know the rest but still understand the full picture. You need to
understand a much bigger part of the picture and leave the OOP picture out
of it first before you can argue about it.

No you don't *need* to leave out OOP. The problem is that you define
everything in the context of the standards, as if C++ wouldn't exist without
the standards. Typically changing around the chiken and egg scenario. The
standards only exist because of the language, not vice-versa.

Yes, that means you are very clearly changing the context, since the
statement you falsely tried to refute was made in the context of the C++
object model.

Im not changing any context , I am talking about objects(onbjects that
contain member functions) in C++. THat is obviously an object in the OOP
context, you are attempting to change to the context
of an object in the context of the standard.

You are aware of the distinction between static and non-static member
functions? This distinctions is made between these functions that are part
of a class. BTW: In OOP jargon, there are no member functions, the closest
to them are methods. Maybe there's a reason for that difference?

Well I think Bjarne stroutsrup would disagree with this, If you want some
quotes I will gladly post but I dont have time for you right now.
A method and member function are interchangeable terms, a method is
generally used in Java and other languages and in C++ the term member
ufnction is used to mean the same thing.
<snip><notime>

 

[Michael Doubez]

An object is the concept of a data structure which consists of member data
and member functions. This is as much a fact as the fact that the sky is
blue.

No it is not, except in vulgarisation magazines. A more precise
definition is "an object is an instance of the data structure and
behaviour defined by the object's class". You cannot make abstraction
of the class concept, otherwise, you don't have the model for the
object's state, methods and interaction; even if the class is not
expressed by the language (in some languages where functions are in
fact data members, like in javascript).

C++ was designed to be, or support, object orientated programing in the
context of my above definition. This is the main reason why member functions
exist and this is primarily what a member function is used for. Any use of a
member function, other than as an objects member function, is not its
primary intended use.

And I cannot call a function if I don't have an instance of the
parameters. That doesn't make the function part of the parameters.

For this reason alone a member function is part of an object as much as the
sky is blue.

Actually, it is not but I won't talk about dipole physics here

C++ did *not* set out to support the idea that an object was simply a region
of stroage and did not contain member functions. This is simply bollocks.

The first name of C++ (1979) was C With class
See http://www2.research.att.com/~bs/hopl2.pdf
<quote>
Even though support of concurrency and Simula-s tyle simulations was a
primary aim of C with
Classes, the language contained no primitives for expressing
concurrency; rather, a combination
of inheritance (class hierarchies) and the ability to define class
member functions with special
meanings recognized by the pre-p rocessor was used to write the
library that supported the desired
styles of concurrency.
</quote>

And commenting code from 1980
<quote>
Clearly, the most important aspect of C with Classes - and later of C+
+ - was the class concept.
Many aspects of the C with Classes class concept can be observed by
examining a simple example
from [Stroustrup,1980a]:
class stack {
char s[SIZE]; /* array of characters */
char * min; /* pointer to bottom of stack */
char * top; /* pointer to top of stack */
char * max; /* pointer to top of allocated space */
void new(); /* initialization function (constructor) */
public:
void push(char);
char pop();
};

A class is a user-d efined data type. A class specifies the type of
the class members that define the
representation of a variable of the type (an object of the class),
specifies the set of operations
(functions) that manipulate such objects, and specifies the access
users have to these members.
Member functions are typically defined ''elsewhere:''
</quote>

That's pretty explicit. I won't quote the wholde document and I engage
you to read it.

People can argue the sky is not blue and its only the refracted light that
enters our eyeballs that appears to be blue. But they are wrong, the sky
*IS* blue.

Actually the dipoles of the high atmosphere vibrate and emit all
colour but inversoerse proportionnal to the power of 4 of the wave
length. Thus blus is predominates.

People can argue that a member function is not part of an object because the
opcode of the function is not actually stored inside the object. But they
are wrong because an object *does* contain functions.

In the conext of C++, functions are member in the same sense as
someone is the member of a club. Being a member of a clud does't me
the club contains you. They are the privileged function that can
access all members and even can use the this keyword in their
definition.

The fact that a small group of people cannot understand the obvious and
misinterpet the standards by quoting out of context does not make them
correct.
Please do not be influenced by their idiotic and moronic way of thinking.

Repeating something like a psittacidea doesn't make it true.

Because something is not covered by the C++ standards does not mean it is
not C++. To state this suggests you do not understand what a standard is, or
it's intended purpose.

Something not in the standard of the C++ language is by definition no
longer standard C++ and since it is the only authoritative document on
a language called c++, it is no longer C++.

 

[Stuart Redmann]

The question is whether the C++ standard does not cover it or whether
it makes some statements that would actually forbid such a
feature [OP is referring to separate "copies" of member functions].

C++ has something called 'the one definition rule' which requires that
non-inline functions (whether member functions or free functions) have
effectively at most one definition in the entirety of the code for a
program.

I was not intending to violate the ODR. What I wanted to achieve is
that the run-time would create copies of the member function, quite
similar to the Unix fork command using the copy-on-write semantics of
the paging system. Effectively, each object would get the same
implementation of the member function. Only when an object decides to
manipulate its own member function, the run-time would provide a
separate copy.

It is perfectly possible for every object in a program to have its own
unique set of functions but in that case every object also has to have
its own unique type.

The last paragraph is (hopefully) meant with regard to the the C++
object model.

Data types in C++ have associated behaviour. When those are class types
the behaviour is provided by member and friend functions. The difference
between those functions and all other functions is that they define
behaviour for instances of the class. However from the perspective of
functions rather than data, member functions are no different to any
other function, they have parameter lists that must be satisfied at call
time by suitable arguments. The special calling syntax for member
functions is nothing more than some syntactic sugar. Like many cases of
syntactic sugar it is helpful to programmers but not to implementations
(they have to work that much harder to support the feature)

In case it is still unclear, yes the C++ Standard does implicitly ban
alternative (per object) definitions.

Thanks for the clarification.

Regards,
Stuart

 

[Stuart Redmann]

An object is the concept of a data structure which consists of
member data and member functions. [snip]
C++ was designed to be, or support, object orientated programing
in the context of my above definition. This is the main reason
why member functions exist and this is primarily what a member
function is used for.

As far as I remember, C++ was also designed to be an extension of the
C programming language. From this point of view it seems as if the
exisiting features of C have been expanded in such a way that we get
object-orientation: The "class"-feature can be considered just as the
expansion of the "struct"-feature with access modifiers, and member
functions can be considered as special functions with an hidden
argument.

From the point of view of a programmer who uses the objects, the
member functions are most often considered as part of the object. If I
type the member access operator in my IDE, it will pop up a list of
member variables and member functions. The IDE would not do this if it
didn't consider the methods also as "part" of the object. But this is
just another view-point.

C++ did *not* set out to support the idea that an object was simply a region
of stroage and did not contain member functions. This is simply bollocks.

I'm not so sure. Maybe we should ask Bjarne.

Regards,
Stuart

 

[Paul]

No it is not, except in vulgarisation magazines. A more precise
definition is "an object is an instance of the data structure and
behaviour defined by the object's class". You cannot make abstraction
of the class concept, otherwise, you don't have the model for the
object's state, methods and interaction; even if the class is not
expressed by the language (in some languages where functions are in
fact data members, like in javascript).

I don't abstract the class I have stated many times that an object is
defined by the class.
Whether you call it objects behaviour , method , or member function you
cannot deny that the member function is the objects behaviour.

And I cannot call a function if I don't have an instance of the
parameters. That doesn't make the function part of the parameters.


Actually, it is not but I won't talk about dipole physics here

The sky is blue, obviously in daytime( for those who choose to observe the
sky at night)
I don't know what color the sky is in your world, if not blue.

The first name of C++ (1979) was C With class
See http://www2.research.att.com/~bs/hopl2.pdf
<quote>
Even though support of concurrency and Simula-s tyle simulations was a
primary aim of C with
Classes, the language contained no primitives for expressing
concurrency; rather, a combination
of inheritance (class hierarchies) and the ability to define class
member functions with special
meanings recognized by the pre-p rocessor was used to write the
library that supported the desired
styles of concurrency.
</quote>

Are you trying to suggest that C++ does not support OOP?
I can provide a hell of alot of quotations that prove C++ does support OOP,
if you really want to raise an argument about this.

And commenting code from 1980
<quote>
Clearly, the most important aspect of C with Classes - and later of C+
+ - was the class concept.
Many aspects of the C with Classes class concept can be observed by
examining a simple example
from [Stroustrup,1980a]:
class stack {
char s[SIZE]; /* array of characters */
char * min; /* pointer to bottom of stack */
char * top; /* pointer to top of stack */
char * max; /* pointer to top of allocated space */
void new(); /* initialization function (constructor) */
public:
void push(char);
char pop();
};

A class is a user-d efined data type. A class specifies the type of
the class members that define the
representation of a variable of the type (an object of the class),
specifies the set of operations
(functions) that manipulate such objects, and specifies the access
users have to these members.
Member functions are typically defined ''elsewhere:''
</quote>

That's pretty explicit. I won't quote the wholde document and I engage
you to read it.

What are you supposed to be proving with this quote?
Again , are you suggesting C++ does not support OOP?

Actually the dipoles of the high atmosphere vibrate and emit all
colour but inversoerse proportionnal to the power of 4 of the wave
length. Thus blus is predominates.

So the sky is blue? or blus? Make your mind up earlier you said the sky
wasn't blue.
What actually is the colour of the sky in your world?

In the conext of C++, functions are member in the same sense as
someone is the member of a club. Being a member of a clud does't me
the club contains you. They are the privileged function that can
access all members and even can use the this keyword in their
definition.

If you are a member of something you belong to it , or are part of it,
associated with it . Whatever term you use it just seems like pernickety
pedantic babbling to argue against this general meaning.

Repeating something like a psittacidea doesn't make it true.

Are you suggesting something is untrue? If so what?

Something not in the standard of the C++ language is by definition no
longer standard C++ and since it is the only authoritative document on
a language called c++, it is no longer C++.

Because sometihng is UB or IS does not mean it is no longer C++, thats pure
bollocks.
You are another person who doesnt seem to understand what a standard is or
its purpose.


Note: I apologise if I offend anyone with use of the vulgar word bollocks.
I'm sure Michael will not be offended if he reads those sort of magazines.

 

[Paul]

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

Ok well fair enough if thats how the progressive history of it all actually
was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact that
the member function, virtual or not, is bound to the object in some way or
another. What other purpose does a member function have but to be part of an
object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?

 

[Paul]

An object is the concept of a data structure which consists of
member data and member functions. [snip]
C++ was designed to be, or support, object orientated programing
in the context of my above definition. This is the main reason
why member functions exist and this is primarily what a member
function is used for.

As far as I remember, C++ was also designed to be an extension of the
C programming language. From this point of view it seems as if the
exisiting features of C have been expanded in such a way that we get
object-orientation: The "class"-feature can be considered just as the
expansion of the "struct"-feature with access modifiers, and member
functions can be considered as special functions with an hidden
argument.

From the point of view of a programmer who uses the objects, the
member functions are most often considered as part of the object. If I
type the member access operator in my IDE, it will pop up a list of
member variables and member functions. The IDE would not do this if it
didn't consider the methods also as "part" of the object. But this is
just another view-point.

Hally...loo...yah.. One person has actually acknowledged this.

I'm not so sure. Maybe we should ask Bjarne.

I don't think Bjarne would impose such a restriction on the language.
In fact here is one quote from Bjarne. Many quotes can be found on the
internet explaining this exact same description of how a member function
works in C++:

"An object of a C++ class is represented by a contiguous region of memory. A
pointer to an object of a class points to the first byte of that region of
memory. The compiler turns a call of a member function into an ''ordinary''
function call with an ''extra'' argument; that ''extra'' argument is a
pointer to the object for which the member function is called."

It's clear that Bjarne does not dis-associate member functions and objects.
The opposite seems to be the consensus for the majority of this group.

 

[Paul]

[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact
that the member function, virtual or not, is bound to the object in some
way or another. What other purpose does a member function have but to be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?

The only binding between an object and a member function is the vtable
pointer present in an object of class type which includes at least one
virtual function; an object of class type without any virtual functions
will not have a vtable pointer present; this only applies to
implementations that use vtables which is likely to be all implementations
in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the definition of
an object type" suggests that any function declared in said class is bound
to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to call the
member function also suggests its bound.

Obviously the above depends on your defintion of bound. And naturally it
requires a certain level of intelligence to realise its not true for static
members.

 

[Paul]

On 13 Jan., "Paul" wrote:
An object is the concept of a data structure which consists of
member data and member functions. [snip]
C++ was designed to be, or support, object orientated programing
in the context of my above definition. This is the main reason
why member functions exist and this is primarily what a member
function is used for.

As far as I remember, C++ was also designed to be an extension of the
C programming language. From this point of view it seems as if the
exisiting features of C have been expanded in such a way that we get
object-orientation: The "class"-feature can be considered just as the
expansion of the "struct"-feature with access modifiers, and member
functions can be considered as special functions with an hidden
argument.

From the point of view of a programmer who uses the objects, the
member functions are most often considered as part of the object. If I
type the member access operator in my IDE, it will pop up a list of
member variables and member functions. The IDE would not do this if it
didn't consider the methods also as "part" of the object. But this is
just another view-point.

Hally...loo...yah.. One person has actually acknowledged this.

C++ did *not* set out to support the idea that an object was simply a
region
of stroage and did not contain member functions. This is simply
bollocks.

I'm not so sure. Maybe we should ask Bjarne.

I don't think Bjarne would impose such a restriction on the language.
In fact here is one quote from Bjarne. Many quotes can be found on the
internet explaining this exact same description of how a member function
works in C++:

"An object of a C++ class is represented by a contiguous region of
memory. A pointer to an object of a class points to the first byte of
that region of memory. The compiler turns a call of a member function
into an ''ordinary'' function call with an ''extra'' argument; that
''extra'' argument is a pointer to the object for which the member
function is called."

It's clear that Bjarne does not dis-associate member functions and
objects. The opposite seems to be the consensus for the majority of this
group.

No the majority of this group disagree with your claim that a member
function is part of an object; your Bjarne quote does not indicate that a
member function is part of an object; it indicates that a member function
is invoked on an object.

The calling mechanics described in the above quote make it clear that a
member function is directly associated with an object.
What makes you think the opposite?
Or are you trying to twist the context of 'part of' to mean 'literally
contained within'?

 

[Jeff Flinn]

[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact
that the member function, virtual or not, is bound to the object in some
way or another. What other purpose does a member function have but to be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?

The only binding between an object and a member function is the vtable
pointer present in an object of class type which includes at least one
virtual function; an object of class type without any virtual
functions will not have a vtable pointer present; this only applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the definition
of an object type" suggests that any function declared in said class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to call the
member function also suggests its bound.

void SomeGlobalScopeFunction(const SomeClass&, int );

Requires an object. Is this a member function?

Jeff

 

[Paul]

On 14/01/2011 15:33, Paul wrote:

[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact
that the member function, virtual or not, is bound to the object in
some
way or another. What other purpose does a member function have but to
be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?


The only binding between an object and a member function is the vtable
pointer present in an object of class type which includes at least one
virtual function; an object of class type without any virtual
functions will not have a vtable pointer present; this only applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the definition
of an object type" suggests that any function declared in said class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to call the
member function also suggests its bound.

Obviously the above depends on your defintion of bound. And naturally it
requires a certain level of intelligence to realise its not true for
static members.

Wrong yet again; again in C++ an object is simply a region of storage (in
the data segment or stack);

You really don't have a clue.
Funnily enough your misinterpretation of the standards reminds me of someone
else.
Normally objects are created on the heap, where do this totally bollocks
idea of an implementation specific program format?

a member function after compilation/linking is just machine code in the
text segment no longer existing as a separate entity;

What is this bollocks all about? You could say any part of a program is
*just* machine code.
Dunno what you are on about seperate entities , seperate from what?

in C++ a member function is part of a class not part of an object; in C++
an object type does not have to be a class type ergo in C++ an object does
not have to be an instance of a class. Member functions are invoked *on*
objects; they are not *part* of objects.

A member function is *declared* in a class, how can the function itself be
part of a class when the class is simply source code and discarded after
compilation?
I can compile and link an object from a precompiled library, hence create an
object(with member functions) when the class file has been deleted.

Your narrowmindedness cannot see that a member function can be considered
part of both a class and an object. This is apparent as you obviously think
it must be one or the other.

We are treading old ground and not getting anywhere; I suggest you accept
the opinion of the majority and agree to disagree.

I suggest you stop making incorrect statements and generally speaking crap.

 

[Paul]

On 14/01/2011 15:33, Paul wrote:

[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact
that the member function, virtual or not, is bound to the object in
some
way or another. What other purpose does a member function have but to
be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?


The only binding between an object and a member function is the vtable
pointer present in an object of class type which includes at least one
virtual function; an object of class type without any virtual functions
will not have a vtable pointer present; this only applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the definition
of an object type" suggests that any function declared in said class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to call the
member function also suggests its bound.

void SomeGlobalScopeFunction(const SomeClass&, int );

Requires an object. Is this a member function?

Jeff

?^_^?
Is that supposed to be the calling syntax of a member function called for an
object?

dunno what that is exactly looks like some const reference.

 

[Paul]

On 14/01/2011 15:33, Paul wrote:

[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact
that the member function, virtual or not, is bound to the object in
some
way or another. What other purpose does a member function have but to
be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?


The only binding between an object and a member function is the vtable
pointer present in an object of class type which includes at least one
virtual function; an object of class type without any virtual functions
will not have a vtable pointer present; this only applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the definition
of an object type" suggests that any function declared in said class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to call the
member function also suggests its bound.

void SomeGlobalScopeFunction(const SomeClass&, int );

Requires an object. Is this a member function?

Jeff

?^_^?
Is that supposed to be the calling syntax of a member function called for an
object?

dunno what that is exactly looks like some const reference.

 

[Paul]

.

On 13 Jan., "Paul" wrote:
An object is the concept of a data structure which consists of
member data and member functions. [snip]
C++ was designed to be, or support, object orientated programing
in the context of my above definition. This is the main reason
why member functions exist and this is primarily what a member
function is used for.

As far as I remember, C++ was also designed to be an extension of the
C programming language. From this point of view it seems as if the
exisiting features of C have been expanded in such a way that we get
object-orientation: The "class"-feature can be considered just as the
expansion of the "struct"-feature with access modifiers, and member
functions can be considered as special functions with an hidden
argument.

From the point of view of a programmer who uses the objects, the
member functions are most often considered as part of the object. If I
type the member access operator in my IDE, it will pop up a list of
member variables and member functions. The IDE would not do this if it
didn't consider the methods also as "part" of the object. But this is
just another view-point.

Hally...loo...yah.. One person has actually acknowledged this.

C++ did *not* set out to support the idea that an object was simply a
region
of stroage and did not contain member functions. This is simply bollocks.

I'm not so sure. Maybe we should ask Bjarne.

I don't think Bjarne would impose such a restriction on the language.
In fact here is one quote from Bjarne. Many quotes can be found on the
internet explaining this exact same description of how a member function
works in C++:

"An object of a C++ class is represented by a contiguous region of memory. A
pointer to an object of a class points to the first byte of that region of
memory. The compiler turns a call of a member function into an ''ordinary''
function call with an ''extra'' argument; that ''extra'' argument is a
pointer to the object for which the member function is called."

It's clear that Bjarne does not dis-associate member functions and objects.
The opposite seems to be the consensus for the majority of this

group.

It's clear Bjarne also believes that an object is a region of memory
(storage) and that the compiler treats member function as regular
functions with different syntax. E.g. it changes this:

Yes he does believe an object is a region of memory because an object *is* a
region of memory.
But what you have said about a compiler treating a member function as a
regular function is not true.

What he says clarifies a member function is *not* the same as a regular
function. When talks of changing the function call to an ordinary function
call he is describing the calling mechanics and the very fact that he says
the function call is converted to an ordinary call implies the function is
not ordinary.

class C {
void fun();
};

into something like this:

class C;
void fun( C * );

And then changes this:

C obj;
obj.fun();

into this:

C obj;
fun( &obj );

I don't think it's possible to explain the calling mechanisms using C++
code.

 

[Öö Tiib]

No it is not, except in vulgarisation magazines. A more precise
definition is "an object is an instance of the data structure and
behaviour defined by the object's class". You cannot make abstraction
of the class concept, otherwise, you don't have the model for the
object's state, methods and interaction; even if the class is not
expressed by the language (in some languages where functions are in
fact data members, like in javascript).

"A class" (like in class-based OO languages) makes no sense in
Javascript. Class is other (less flexible) concept than that language
supports. Javascript's prototypes are not classes. Objects have full
freedom to change their data model and behavior during their lifetime
(and may do same to other objects that they know of). The objects of
Javascript are not forced to stay in prototype where they started in
and so they simply have no class.

 

[Öö Tiib]

The calling mechanics described in the above quote make it clear that a
member function is directly associated with an object.
What makes you think the opposite?
Or are you trying to twist the context of 'part of' to mean 'literally
contained within'?

Ok. Lets take OO then. Favorite object, me. I can (1) eat and i may
(2) be eaten. Eating is therefore behavior that can be associated with
me, yes. Does it mean eating is part of me? In what of given two
associations it is part of me?

The only programming language i know a bit where the borders between
behavior and state are dim is Lisp and that language is rather far
from C++.

 

[Paul]

On 14/01/2011 17:21, Paul wrote:

On 14/01/2011 15:33, Paul wrote:


[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the fact
that the member function, virtual or not, is bound to the object in
some
way or another. What other purpose does a member function have but
to be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?


The only binding between an object and a member function is the vtable
pointer present in an object of class type which includes at least one
virtual function; an object of class type without any virtual
functions will not have a vtable pointer present; this only applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the
definition
of an object type" suggests that any function declared in said class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to call
the
member function also suggests its bound.

Obviously the above depends on your defintion of bound. And naturally
it
requires a certain level of intelligence to realise its not true for
static members.


Wrong yet again; again in C++ an object is simply a region of storage
(in the data segment or stack);

You really don't have a clue.
Funnily enough your misinterpretation of the standards reminds me of
someone else.
Normally objects are created on the heap, where do this totally bollocks
idea of an implementation specific program format?

Again it is not a specific program format; "segment" is a computer science
term; "data segment" includes the "heap".

Absolute shite , an implementation is free to name memory segments as it
choses.

Functions (member or not) are compiled into machine code which lives in
the text segment. There is no difference between a member function and a
non-member function as far as the resultant executable is concerned (it is
all just machine code in the text segment).

Again absolute shite.
The invokation mechanism for a member function is different from that of a
non member function.

You are wrong; member functions are part of classes not of objects; after
compilation/linking member functions and classes cease to exist, all that
is left is machine code in the text segment which includes the addresses
of the start of what were functions during compilation.

So how can its be possible to invoke a member function?
How come I can link and lib that contains member functions?

You are talking complete crap.

You are the one who refuses to accept what is valid and agreed on by the
majority.

To say a member function does not exist after compilation is so untrue that
it is even beyond the majority in here to agree with you.
The very fact that people like Bjarne Stroustrup speak of invokation of a
member function on an object, is enough proof that member functions do exist
after compile time.

I think you are stretching the limits of bullshit with this post