To me a member funtion is part of an object by definition.
However some people like to argue that a member function is not considered
part of an object.. They've suggested that because a function is not stored
within an object in memory thisa is evidence to suggest that an object does
not have member functions.
A member function is definined in an objects class
An objects' class is the definition of an object type and any functions
defined within that class are member of that given object type.
A member function IS by definition a member of an object.
It seems some people cannot see past the fact that a paragraph in the
standards states an object to be a region of memory. They seem to interpet
this to mean that nothing can be part of that object unless it is stored
within the same region of memory.
I have and I still do argue with these people as I think its quite clear
they're view is very narrow minded and not a good way to think about objects
and object types.
False.
A member function is part of a class. A class is not the same as an
object, but rather defines a possible type for an object.
A class provides a blueprint for the layout of an object and it tells
the compiler in which constructions an object of that type can be
used.
>
> To me a member funtion is part of an object by definition.
Then you are using different definitions that I am and the other C++
programmers that I know.
>
> However some people like to argue that a member function is not considered
> part of an object.. They've suggested that because a function is not stored
> within an object in memory thisa is evidence to suggest that an object does
> not have member functions.
>
> A member function is definined in an objects class
> An objects' class is the definition of an object type and any functions
> defined within that class are member of that given object type.
> A member function IS by definition a member of an object.
Sorry, but that conclusion does not follow from the preceding
statements.
First, member functions do not have to be defined in a class. It is
also possible to declare members in the class and define them outside
the class.
Secondly, a class provides indeed a definition of an object type, and
any function declared in the class is a member of the class. This is
true for both static and non-static members.
If your conclusion followed logically from the preceding statements,
then static member functions would also be members of an object, even
though they can be used without ever declaring an object of that type.
Additionally, there is a step missing where you show that members of a
class are by necessity also members of an instance of that class,
instead of operating on such an instance.
Bart v Ingen Schenau
>False.
You are entitled to your opinion.
GL!
What does it have to do with opinions? A member function is a kind of
function. A function isn't an object, and as such cannot be a part of
another object.
V
--
I do not respond to top-posted replies, please don't ask
You refer to functions as objects yet in the same statement you clearly
state a function is not an object.
What you have stated here is nothing more than some twisted double negative
You also seem to have no regard for opinions
> state a function is not an object.
It is not, and I am basically repeating what the Standard says (see the
first Note in [intro.object/1]).
> What you have stated here is nothing more than some twisted double negative
Is English a language you've mastered? Perhaps I ought to use shorter
sentences? Let's try it again:
Only an object can be a part of another object. A function is NOT an
object. Hence a function cannot be a part of an object. There is
nothing in this that is an opinion. Those are just two facts and a
corollary.
> You also seem to have no regard for opinions
That's inconsequential to the matter at hand.
In the context of the C++ object model, you have been given the answer
over and over.
Why are you asking again? Just read the existing answers.
> To me a member funtion is part of an object by definition.
By what definition?
He does no such thing.
> You also seem to have no regard for opinions
Well, I wouldn't say so, he just doesn't have any for your opinions.
Judging from what the OP has shown so far, I wouldn't be surprised if he
derived (no pun intended) that conclusion from your sentence: "A member
function is a kind of function." IOW, you must only use the construction
"is a kinf of" to refer to objects in the OO sense; nowhere else. <g>
Haven't all this gone too far? Paul is surely entitled to his opinion. I
just think that his apparent goal of pushing his understanding of the
relationship between member functions and objects in the context of C++
will lead him nowhere.
Regards,
--
Ney André de Mello Zunino
Are you people for real.
I havent shown you anything so far.
You are obviously just another hostile asshole who is trying to jump on the
bandwagon.
Please note I object to idiots like you participating in my threads.
And yet I was right on the money with my assumption. Thanks for
confirming that. Your trolling efforts had been merely pathetic up to
this point. They've now become predictable and boring.
Worry not. This idiot will not reply to any of your posts from now on.
Have a good one!
--
I have been given 'a' answer not 'the' answer .
>
> Why are you asking again? Just read the existing answers.
>
>> To me a member funtion is part of an object by definition.
>
> By what definition?
>
>
The definition of an Object type. Generally referred to as a class.
Go away you nasty horrible person .....
Victor just employed a way of speaking where one refers to some other's view.
You can read the last part as a quote or paraphrase, ... like, <<as such cannot
be a "part of another object">> (quoting or paraphrasing you, seeing things from
your point of view). It's funny in its own way, you taking Victor's words
literally, and most people here taking your words literally. :-)
As I wrote earlier, it's just about terminology, and possibly about ways of
thinking about things.
That's mostly off-topic in C++ newsgroups, because that terminology and/or way
of thinking has nothing to do with any particular programming language: you can
think that way and talk that way about things when using Java or Python or
whatever programming language. "Mostly": it can be on-topic to ask whether this
way of talking/thinking is common or suitable for C++ programming, and there you
have your answer, namely that it's not common, and that it is in conflict with
the standard's terminology, i.e. it's easy to misunderstand so it's not suitable
either. So if you want people to understand you, then better define what you
mean, or switch to the common terminology / way of thinking.
Cheers & hth.,
- Alf
--
blog at <url: http://alfps.wordpress.com>
Sorry, but that's wrong. You have been quoted the relevant section of the
definition all over, you just don't want to or can't listen.
>>> To me a member funtion is part of an object by definition.
>>
>> By what definition?
>>
> The definition of an Object type. Generally referred to as a class.
To me, too, methods are *generally* part of objects. However, in the
context of the *C++ object model*, it isn't, by its definition the C++
standard.
Do you understand the difference between "in general" and "in the context
of the C++ object model"?
As with the text from the standards that defines an object as region of
storage. This is incorrectly being retranslated to mean something along the
lines of ...
an object cannot contain a member function.
The standard also states that an object or subobject can be zero size, so
how can a zero sized object be a region of storage? As this demonstrates the
standards are not always simple to interpret, and peraps not always
coherent.
The problem with your argument is that selective quotes or one particular
selective quote is being repeated misquoted to mean something it doesn't
mean.
All other statements in the standards seem to be ignored.
For example paragraph 9.2 to which the standards seem to refer to as the
definition of a member subobject:
"1 The member-specification in a class definition declares the full set of
members of the class; no member
can be added elsewhere. Members of a class are data members, member
functions (9.3), nested types,
and enumerators."
A member subobject is not necessarily the same thing as an object, defined
as a region of storage.
The term member is self descriptive and automatically implies that it's part
of something.
Another good point here is that the standard refers to class members to
define objects or subobjects, therefore the standards clearly recognise the
relationship between classes and objects , some people shun this idea.
I think this makes my point clear that I am using the terminology as per the
standards.
The fact that a member function is listed where the standard defines the
term member subobject can open up a whole new debate as to whether or not
the standards regard a member function as a membersubobject. But as it
stands it seems to do so.
Please look at this quote from an OOP paper by Bjarne Strousup.
"The function to be called depends on the type of the object for which it is
called. This type cannot in general be determined until run time. Typically,
the pointerp will be of some base classB and the object will be an object of
some derived classD (as was the case with the base classshape and the
derived classcircle above). The call mechanism must look into the object and
find some information placed there by the compiler to determine which
functionf is to be called"
The author of the above quote suggests a call mechanism must look into an
object to find some information regarding the function.
All this evidence weighs strongly in favour that a member function can be
considered part of an object.
You suggest otherwise but you have not provided any quote to reference.
Please can you give a quote from the standards that supports your claim.
> A member functions is part of an object. true or false?
False. It's part of a class.
> To me a member funtion is part of an object by definition.
You're wrong. Deal with it already - I'm tired of seeing your endless
whining on the subject.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
Anybody who fucks with Francis G fucks with us! Back off, motherfuckers ;)
I'm not whining about anything ,
You are the one doing the whining.
The leve of intellect here is simply astonishing
What references can you cite that support your interpretation of the
word whining?
<snip>
>> Judging from what the OP has shown so far,
>
> I havent shown you anything so far.
I'll have to agree with Paul on this point.
So from the statement "an apple is not a brick, and as such cannot
be a part of a load of bricks" you would conclude that an apple is a brick?
Was it the contraction that confused you?
Then you got the definition of the term 'object type' wrong. There are
more kinds of object types than just classes. For example, integers
and pointers are also object types.
I don't have the standard here to provide the exact definition, but
'object type' is roughly defined as "a type that describes the
properties of objects".
Bart v Ingen Schenau
§1.8/1 [...] An object has a type (3.9). The term /object type/ refers
to the type with which the object is created. Some objects are
polymorphic (10.3); the implementation generates information
associated with each such object that makes it possible to determine
that object’s type during program execution. For other objects, the
interpretation of the values found therein is determined by the type
of the expressions (clause 5) used to access them.
And related to object
§5/7 An expression designating an object is called an object-
expression.
§5.2.5/2 For the first option (dot) the type of the first expression
(the object expression) shall be “class object” (of a complete type).
For the second option (arrow) the type of the first expression (the
pointer expression) shall be “pointer to class object” (of a complete
type). In these cases, the id-expression shall name a member of
the class or of one of its base classes. [Note: <snip>] [Note: 3.4.5
describes how names are looked up after the . and -> operators. ]
And finally:
1 In a class member access expression (5.2.5), if the . or -> token is
immediately followed by an identifier followed by a < [snip template
or compare]. The identifier is first looked up in the class of the
object expression. If the identifier is not found, it is then looked
up in the context of the entire postfix-expression and shall name a
class or function template. If the lookup in the class of the object
expression finds a template, the name is also looked up in the context
of the entire postfix-expression and
— if the name is not found, the name found in the class of the object
expression is used, otherwise
— if the name is found in the context of the entire postfix-expression
and does not name a class template, the name found in the class of the
object expression is used, otherwise
— if the name found is a class template, it must refer to the same
entity as the one found in the class of the object expression,
otherwise the program is ill-formed.
So, for the call of a member function, "the identifier is first looked
up in the class of the object expression"
For all the good it will do to.
You can lead a horse to water, but you can't make it drink
--
Michael
> > "Ulrich Eckhardt" <dooms...@knuut.de> wrote in
> > messagenews:8omd68...@mid.uni-berlin.de...
> > > Paul wrote:
> > >> To me a member funtion is part of an object by definition.
> > > By what definition?
> > The definition of an Object type. Generally referred to as a class.
> Then you got the definition of the term 'object type' wrong. There are
> more kinds of object types than just classes. For example, integers
> and pointers are also object types.
> I don't have the standard here to provide the exact definition, but
> 'object type' is roughly defined as "a type that describes the
> properties of objects".
"Object type" is a subset of "type". A type can be an object
type, a function type or a reference type. Or perhaps something
else which I've forgotten, but those are the three principle
types of types. An object has object type (or perhaps rather,
an entity which has object type is an object). An object can
contain subobjects (which must be objects). As far as the C++
standard is concerned, that's it.
--
James Kanze
...................................................................
Section 9.2
"2 A class is considered a completely-defined object type (3.9) (or complete
type) at the closing } of the
class-specifier."
Obviously we are talking about object types as objects defined by classes,
that contain member functions etc.
To say that an integer is also an object, as sometimes used in the context
of the standards, seems to suggest that you are nothing more than a
brainless idiot.
Whether you are or not will be probably be proven by your next post, if
there is one.