Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > technical correctness

Reply
Thread Tools

technical correctness

 
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Paul" <(E-Mail Removed)> writes:
> [...]
>> Its quite simple and clear what I mean, I will explain:
>> Objects can and, more often than not, do contain member functions. To
>> suggest that objects do not contain functions is complete nonsense.
>> My newsreader doesnt like to indent your text so sorry about that.

> [...]
>
> Your newsreader's failure to quote properly makes it difficult to
> figure out who wrote what, so I'll just respond to this one paragraph.
> You might want to investigate why your newsreader is malfunctioning,
> and perhaps consider using a different one. You might also consider
> trimming excessive quoted material.
>
> Yes, what you mean is quite simple and clear. It's also quite wrong, at
> least if you use the word "object" as it's defined by the C++ standard.
>
> Quoting the 2003 version of the ISO C++ standard, section 1.8:
>
> An object is a region of storage. [Note: A function is not an
> object, regardless of whether or not it occupies storage in the way
> that objects do.]
>
> (The word "object" is in italics, indicating that this is the standard's
> definition of the word. The second sentence does not directly refute
> your claim; I include it for completeness.)
>

And what part of this do you interpret to mean ... objects cannot contain
member functions?
All this says is that an object is a region of storage.
I can't understand why you think this says something other than that.



> Member functions do not exist within objects. Member functions can
> certainly be associated with objects, but they are not contained within
> them.


An object can contain a method function , yet the two entities can be stored
at different memory locations.
If you would prefer to say a member function was associated with an object
then thats fine , but I think it's more generally considered to be part of
the object.


>
> It's possible, I suppose, to construct a consistent model of the C++
> language in which member functions are contained within objects. But
> doing so would probably require a non-standard meaning for "contained
> within", or perhaps for "member function".
>
> The syntax of C++ does tend to imply that member functions are
> contained within objects the way member data is ("obj.func()"
> vs. "obj.data"), but that's an abstraction, not a reflection of
> what's actually going on.


Why do you think this is not a reflection of what is going on?
Member functions are a part of the object, they are in the objects scope and
have access to that objects members, the way these things are stored in
memory does not change this. You probably dont know where in memory that
object will be stored anyway and you will not be accessing its members using
pointer arithmetic or anything silly like that.

>
> Leigh Johnston also makes a good point. Suppose a class "C" defines a
> member function "func", and suppose you have 10 objects of type C:
>
> C arr[10];
>
> If member functions are contained within objects, doesn't that imply
> that there are 10 distinct member functions, one for each object C[0]
> through C[9]?


If you delve into the calling mechanics of specific systems you will
probably find that calls to a member function are passed and additional
argument which is a reference to their object. virtual functions and derived
classes and overriding functions get more complicated and have lookup tables
and stuff.
>
> If a member function is contained within an object, does the existence
> of a member function contribute to the size of that object as reported
> by sizeof? Why or why not?
>
> --
> Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed)
> <http://www.ghoti.net/~kst>
> Nokia
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"
>

Please do not confuse a member function being part of an object as meaning
the functions code is stored within the object in memory.

 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-berlin.de...
> Paul wrote:
>> As an example I will quote some of the nonsense I have to deal with:
>> <snippet ref=...>
>>
>> Extremely wrong. Functions are NOT part of an object.
>> Remember that we are speaking in the context of the C++ Standard, where
>> an "object" is defined as a region of storage:
>> <citation>
>> 1.8 The C+ + object model [intro.object]
>> 1 The constructs in a C++ program create, destroy, refer to, access, and
>> manipulate objects. An object is a region of storage. [Note: A function
>> is not an object, regardless of whether or not it occupies storage in
>> the way that objects do. ]
>> </citation>
>> Please find me a quote from the standard that expresses the same concept
>> of this extremely wrong sentence of yours: "function is an integral part
>> of an object".
>> You wanted to get technical, didn't you? Chapter and verse please.
>> </ snippet>
>>
>> It is complete nonsense to assume the standards or any other OOP
>> documentation implies that functions are not an integral part of an
>> object.

>
> Why? The precise definition (if such a precise definition exists!) of an
> object differs between languages, e.g. in some a type itself is an object,
> in others it isn't. The C++ standard defines what "object" means in its
> context, hence the title "The C++ object model". The C++ standard is
> independent, it doesn't make any claims concerning the meaning of the term
> "object" in different contexts and it isn't affected by the meaning of the
> term "object" in different contexts either. The C++ standard is not
> affected by other standards as it is unaffected by other OOP docs. To put
> it differently, the C++ standard doesn't define what an object is, it only
> defines what the term "object" means in the context of the C++ standard
> itself.
>

You make out its all very confusing and difficult and undefined but I don't
see it like that at all.
It's a pretty simple concept and there are many texts on OOP if you find it
difficult to understand.

> BTW: C++ doesn't claim to be an OOP language, hence for example it doesn't
> have methods but memberfunctions. So common OOP jargon can't be applied
> unconditionally either.
>

According to Bjarne Stroustrup:
<quote>
"The reason for this is partly to introduce C++ and partly because C++ is
one of the few languages that supports both data abstraction and
objectoriented
programming in addition to
traditional programming techniques."
</quote>

<snip content="idiotic nonsense">

 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 03/01/2011 20:12, Paul wrote:
>>>>
>>>> The internal workings of a systems memory,CPU and how the function is
>>>> stored within an object is irrellevant. The point is that somehow that
>>>> object contains some kind of reference to the function and that
>>>> function
>>>> is an integral part of the object.
>>>> As I said before an object can and usually does contain functions or
>>>> methods. This is not wrong and you have not given any evidence to
>>>> support that. The fact that you think an object cannot contain
>>>> functions
>>>> is wrong however and if you want me to start posting links to prove
>>>> that, I can do. But I think it is best that you realise your error and
>>>> waken up to the facts.
>>>
>>> Your wrongness gets worse. Functions live in the text segment; objects
>>> live in the data segment. If you instantiate 100 identical objects do
>>> you think you will create 100 function "references" for each class
>>> member function? Wrong. What about inlined inline member functions?
>>> What about member functions which only have a declaration and no
>>> definition? Try thinking.

>>
>> By your own words objects are created at runtime so how can it live in
>> any segment?

>
> Well static and heap objects live in the data segment, stack based objects
> don't, however all of them are created at runtime.
>

a data segment is created at compile time or link time, so surely anything
that lives there is also created then.

>> You try thinking about that and please dont suggest what I think and
>> mark it as wrong as if I had said it.

>
> You are wrong though.
>
>>
>>>
>>> The closest an object gets to storing function "references" is the
>>> storage of a vtable pointer. You can have function pointer member
>>> variables but this is not the same as "an object containing functions".
>>>

>> Who said an object STORES a function? It's only you who is saying that.
>> I said a member function is an integral part of an object. This is a
>> completely different concept from what you are saying.

>
> struct a { char c; };
> struct b { char c; void f() {} };
>
> You will find that sizeof(a) == sizeof(b); i.e. the function "f" (or any
> reference to it) is not stored in any b objects, ergo a member function is
> *not* an integral part of an object.
>
>>
>> As you seem to think that a function cannot be part of an object(or
>> instance) do you think all member functions are static?. Obviously they
>> are not, so wakey wakey.
>>

>
> I already said that an object can store a vtable pointer which is what is
> used for dynamic dispatch; also this is a pointer to a table; there are
> not multiple function references stored in an object which is what you are
> asserting. Try reading what I wrote; you are the one who is asleep.
>

I am not saying that objects store multiple function references.
I didn't go into any details of calling mechanics because it only becomes an
issue if you are trying to argue about what is STORED within objects.
Is it impossible to understand that a member function can be part of an
object, yet that function is stored in a different area of memory?

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On 03/01/2011 20:28, Leigh Johnston wrote:
>> On 03/01/2011 20:12, Paul wrote:
>>>
>>> As you seem to think that a function cannot be part of an object(or
>>> instance) do you think all member functions are static?. Obviously they
>>> are not, so wakey wakey.
>>>

>>
>> I already said that an object can store a vtable pointer which is what
>> is used for dynamic dispatch; also this is a pointer to a table; there
>> are not multiple function references stored in an object which is what
>> you are asserting. Try reading what I wrote; you are the one who is
>> asleep.
>>

>
> If you disagree with what I said you asserted here is a reminder of what
> you actually said:
>
> "The point is that somehow that object contains some kind of reference to
> the function and that function is an integral part of the object."
>

I wasn't implying this is the only way it worked, and it certainly isn't an
attempt to go into details about the calling mechanics.
You are trying to argue that functions are not stored inside objects and I
was trying to get away from that scenario by introducing the concept that
functions and object can exist together yet in seperate areas of memory.

> The only function references that are *indirectly* contained by objects
> are the entries in a vtable a pointer to which will be contained by the
> object if the class of which the object is an instance contains any
> virtual functions. Any non-virtual class member functions will not have
> an entry in any vtable; i.e. NO REFERENCE TO SUCH MEMBER FUNCTIONS EXIST
> WITHIN AN OBJECT.
>
> BTW you were not arguing about "virtual member functions"; you were
> arguing about "member functions"; don't try and now pretend that you were.
>

I'm talking about all non static member functions I guess but Im not trying
to argue that they are actually stored within the objects memory as you try
to imply.

How difficult is it to understand the concept that the member function is
part of the object although they live in different places. There will be
some connection between function and object and the exact calling mechanics
are pretty irrellevant.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2011
"Paul" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "Paul" <(E-Mail Removed)> writes:
>> [...]
>>> Its quite simple and clear what I mean, I will explain:
>>> Objects can and, more often than not, do contain member functions. To
>>> suggest that objects do not contain functions is complete nonsense.
>>> My newsreader doesnt like to indent your text so sorry about that.

>> [...]
>>
>> Your newsreader's failure to quote properly makes it difficult to
>> figure out who wrote what, so I'll just respond to this one paragraph.
>> You might want to investigate why your newsreader is malfunctioning,
>> and perhaps consider using a different one. You might also consider
>> trimming excessive quoted material.
>>
>> Yes, what you mean is quite simple and clear. It's also quite wrong, at
>> least if you use the word "object" as it's defined by the C++ standard.
>>
>> Quoting the 2003 version of the ISO C++ standard, section 1.8:
>>
>> An object is a region of storage. [Note: A function is not an
>> object, regardless of whether or not it occupies storage in the way
>> that objects do.]
>>
>> (The word "object" is in italics, indicating that this is the standard's
>> definition of the word. The second sentence does not directly refute
>> your claim; I include it for completeness.)
>>

> And what part of this do you interpret to mean ... objects cannot
> contain member functions?
> All this says is that an object is a region of storage.
> I can't understand why you think this says something other than that.


Yes, all it says is that an object is a region of storage. What makes
you think I think it says anything else?

It also says that functions to not necessarily occupy storage in the way
that objects do.

>> Member functions do not exist within objects. Member functions can
>> certainly be associated with objects, but they are not contained within
>> them.

>
> An object can contain a method function , yet the two entities can be
> stored at different memory locations.
> If you would prefer to say a member function was associated with an
> object then thats fine , but I think it's more generally considered to
> be part of the object.


Ok, I think I see the source of the confusion. You're using the word
"contain" and the phrase "part of" in a different sense than the rest of
us are.

Let me explain to you again how I (and I think, most other people)
understand the use of those terms.

An object is a region of storage. That's all it is. For something to
be *part of* an object (or, equivalently to be contained within an
object), it has to be somewhere within that region of storage.
Something outside the region of storage may well be associated with the
object, but it's not *part of* the object.

For example, a data member really is *part of* an object.

Can you at least understand that the sense in which a data member
is part of an object does not entirely apply to a member function?

[...]
> Please do not confuse a member function being part of an object as
> meaning the functions code is stored within the object in memory.


That's exactly what most of us thought you were trying to say, which is
why we've been telling you you're wrong.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On 03/01/2011 22:12, Paul wrote:
>>
>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> On 03/01/2011 20:12, Paul wrote:
>>>>>>
>>>>>> The internal workings of a systems memory,CPU and how the function is
>>>>>> stored within an object is irrellevant. The point is that somehow
>>>>>> that
>>>>>> object contains some kind of reference to the function and that
>>>>>> function
>>>>>> is an integral part of the object.
>>>>>> As I said before an object can and usually does contain functions or
>>>>>> methods. This is not wrong and you have not given any evidence to
>>>>>> support that. The fact that you think an object cannot contain
>>>>>> functions
>>>>>> is wrong however and if you want me to start posting links to prove
>>>>>> that, I can do. But I think it is best that you realise your error
>>>>>> and
>>>>>> waken up to the facts.
>>>>>
>>>>> Your wrongness gets worse. Functions live in the text segment; objects
>>>>> live in the data segment. If you instantiate 100 identical objects do
>>>>> you think you will create 100 function "references" for each class
>>>>> member function? Wrong. What about inlined inline member functions?
>>>>> What about member functions which only have a declaration and no
>>>>> definition? Try thinking.
>>>>
>>>> By your own words objects are created at runtime so how can it live in
>>>> any segment?
>>>
>>> Well static and heap objects live in the data segment, stack based
>>> objects don't, however all of them are created at runtime.
>>>

>> a data segment is created at compile time or link time, so surely
>> anything that lives there is also created then.

>
> Segments are defined at compile/link time and created at runtime.
>
>>
>>>> You try thinking about that and please dont suggest what I think and
>>>> mark it as wrong as if I had said it.
>>>
>>> You are wrong though.
>>>
>>>>
>>>>>
>>>>> The closest an object gets to storing function "references" is the
>>>>> storage of a vtable pointer. You can have function pointer member
>>>>> variables but this is not the same as "an object containing
>>>>> functions".
>>>>>
>>>> Who said an object STORES a function? It's only you who is saying that.
>>>> I said a member function is an integral part of an object. This is a
>>>> completely different concept from what you are saying.
>>>
>>> struct a { char c; };
>>> struct b { char c; void f() {} };
>>>
>>> You will find that sizeof(a) == sizeof(b); i.e. the function "f" (or
>>> any reference to it) is not stored in any b objects, ergo a member
>>> function is *not* an integral part of an object.
>>>
>>>>
>>>> As you seem to think that a function cannot be part of an object(or
>>>> instance) do you think all member functions are static?. Obviously they
>>>> are not, so wakey wakey.
>>>>
>>>
>>> I already said that an object can store a vtable pointer which is what
>>> is used for dynamic dispatch; also this is a pointer to a table; there
>>> are not multiple function references stored in an object which is what
>>> you are asserting. Try reading what I wrote; you are the one who is
>>> asleep.
>>>

>> I am not saying that objects store multiple function references.
>> I didn't go into any details of calling mechanics because it only
>> becomes an issue if you are trying to argue about what is STORED within
>> objects.
>> Is it impossible to understand that a member function can be part of an
>> object, yet that function is stored in a different area of memory?

>
> For the last time: a member function is part of a *class* not part of an
> *object*.

A function definition is a member of a class or a static member function.
When the member function is used by an object it is integral to that object
only.
>
> This is a C++ newsgroup so the C++ Standard's definitions of "object" and
> "member function" are de rigueur here in this newsgroup. An "object" is a
> region of storage; not a region of storage plus a collection of member
> functions.
>
> /Leigh


Correct the standards do not say that, an object is a region of storage plus
a collection of member functions, and neither did I.
Its pretty simple the member function lives in a diff place but it's still a
part of the object. It's a part of the object because it is within the
objects scope and it has accesss to the objects properties. The member
function also has access to the "this" keyword which is a pointer to the
object which that member function belongs.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2011
"Paul" <(E-Mail Removed)> writes:
[...]
> How difficult is it to understand the concept that the member function is
> part of the object although they live in different places. There will be
> some connection between function and object and the exact calling mechanics
> are pretty irrellevant.


It's not difficult at all to understand that concept, once you get
around to explaining that that's what you meant.

For most of this discussion, you've been asserting that member
functions are "part of" objects, *not* explaining what you meant,
and asserting that anyone who doesn't agree with your particular
use of terminology must be stupid.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On 03/01/2011 21:19, Paul wrote:
>> Please do not confuse a member function being part of an object as
>> meaning the functions code is stored within the object in memory.
>>

>
> Stop repeatedly saying that others are confused when it is you who is
> confused. Member functions (references or otherwise) are not "part of an
> object"; vtables only apply to virtual member functions and are only used
> for dynamic dispatch not static dispatch.
>
> Maybe the problem is that you are unable to express yourself properly on
> this medium.
>
> /Leigh
>

The problem is you can't accept that the member function called on an object
is specific to that object. The physical memory layout is irrellevant as are
the calling mechanics.
Another object of the same class may use the same function but in the second
instance the function does not have priveleges to the first object.

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-03-2011

"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Paul" <(E-Mail Removed)> writes:
> [...]
>> How difficult is it to understand the concept that the member function is
>> part of the object although they live in different places. There will be
>> some connection between function and object and the exact calling
>> mechanics
>> are pretty irrellevant.

>
> It's not difficult at all to understand that concept, once you get
> around to explaining that that's what you meant.
>
> For most of this discussion, you've been asserting that member
> functions are "part of" objects, *not* explaining what you meant,
> and asserting that anyone who doesn't agree with your particular
> use of terminology must be stupid.
>

I'm glad you understand and I have not intended to assert you as stupid , I
am sorry if I did.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2011
"Paul" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "Paul" <(E-Mail Removed)> writes:
>> [...]
>>> How difficult is it to understand the concept that the member function is
>>> part of the object although they live in different places. There will be
>>> some connection between function and object and the exact calling
>>> mechanics
>>> are pretty irrellevant.

>>
>> It's not difficult at all to understand that concept, once you get
>> around to explaining that that's what you meant.
>>
>> For most of this discussion, you've been asserting that member
>> functions are "part of" objects, *not* explaining what you meant,
>> and asserting that anyone who doesn't agree with your particular
>> use of terminology must be stupid.
>>

> I'm glad you understand and I have not intended to assert you as stupid , I
> am sorry if I did.


That's a good start. Apology accepted.

Now I suggest you apologize to everyone else you've insulted in
this thread. Admitting the possibility that their point of view
might be as valid as yours would also be a nice gesture.

Please understand that, although I think I understand what you're
saying, I still disagree with you. I think your use of the terms
"contained in" and "part of" are inappropriate in the context of C++.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
technical correctness 2 PaulR C++ 19 01-07-2011 09:41 PM
stl list, const correctness Jim Strathmeyer C++ 2 03-20-2005 12:37 AM
A technical question from a non-technical person. Any suggestions appreciated. Graham Cross VOIP 2 01-27-2005 09:13 PM
convert the content of a string to an expression to check its correctness spiros C++ 7 07-20-2004 09:41 PM
Correctness of code for box with header Ryan Stewart HTML 9 03-07-2004 07:53 PM



Advertisments