«

On Jan 5, 10:59*pm, Keith Thompson <ks...@mib.org> wrote:
> Öö Tiib <oot...@hot.ee> writes:
> > On Jan 5, 6:36*pm, Keith Thompson <ks...@mib.org> wrote:
> >> Öö Tiib <oot...@hot.ee> writes:
>
> >> [...]> We discuss C++ here and so we use C++ object model where member
> >> > functions and data members are described by and belong to class and
> >> > are not objects or parts of objects. Types are not objects in C++,
> >> > functions and member functions are not objects in C++.
>
> >> [...]
>
> >> I think you misspoke here. *Data members are parts of objects.
>
> > Yes, i meant that the data member declarations are part of class and
> > can not be altered during program run by C++ language.
>
> You mean the declarations cannot be altered, right? *Of course the data
> members themselves (the values stored in them) can be altered.

Yes the values of member subobjects and base subobjects can be
modified. C++ instructions are not data so you can not alter object's
type or function's behavior dynamically. There are other languages
that allow such run-time metaprogramming, but not C++.

"Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
> To add nothing to this otherwise useless conversation of this thread:
> This entire argument is one over the definition of the term "a part
> of". Let me take a stab at it. Consider the following:
> * class Foo { void bar(){} };
> * Foo x;
> In the common, standard, etc., abstraction and terminology of C++ and
> statically typed programming languages - it's quite silly to say that
> Foo::bar is a part of x. This is an argument over definition, and thus
> I have only two options - appeal to authority, or appeal to consensus.
> Either way, for any reputable authority and any relevant consensus, I
> win.
>
> In short, "a part of" implies some sort of containment or ownership
> relation. A class does "contain and "own" its member functions - a
> member function is contained by exactly one class, and it makes sense
> only in the context of that class. An object does not "contain" nor
> "own" its type, and an object does not "contain" nor "own" its
> associated member functions - there often are multiple objects of a
> specific type or a specific member function. Thus member functions are
> not part of objects, in the common lingo.

On Jan 5, 6:58 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> If a child is PART OF a sunday school group there is no containment or
> ownership.
>
> To be PART OF a group does not imply containment or ownership as you seem to
> think. Your definintion of "PART OF" is very wrong as would your definition
> of anything else *probably be.

That's the problem. "A part of" is rather ambiguous and has overloaded
meanings.

A school group is an aggregation of children. Thus the children are "a
part of" the school group. A class is an aggregation of its members
and a name. Thus it seems right to say that the members are "a part
of" the class.

However, that still doesn't really work well because of the domain
specific usage. The domain is C++, and to a lesser extent all
statically typed programming languages. In that domain specific
discourse, to say X is a part of an object implies that X resides in
the memory region of that object, or there is some ownership
relationship via encapsulation.

James Kanze wrote:
> On Jan 3, 9:29 pm, Leigh Johnston <le...@i42.co.uk> wrote:

<snip>

> Given the way he quotes, he clearly doesn't know how to use this
> medium. Other than that, all I've seen is vague claims on his
> part---and a declaration that's he's right, and that anyone who
> disagrees with him is incompetent. But no facts to support his
> position, whereas all of the people disagreeing with him are
> quoting parts of the standard, or basing their statements on
> work they've done on the standard, or with the standard
> committee.

I think the American Indians talked about judging a warrior by the
quality of his enemies. I can't recall the last time someone could
muster the same quality of opposition as Paul; even with his
demonstrated lack of usenet and people skills.

He's chosen some of the who's who in C++ to charge with
incompetence. Reminds me of the type who hang out in the physics
groups and insist that Newton and Einstein just really didn't get
physics.

From my point of view, I find it really hard to determine if he's
arguing semantics or if he really doesn't get c++ programming.

On 01/ 6/11 11:35 AM, PaulR wrote:
> On Jan 5, 8:37 pm, Paavo Helde<myfirstn...@osa.pri.ee> wrote:
>> "Paul"<pchris...@yahoo.co.uk> wrote innews:7f3Vo.66960$2:
>>
>>> More to the point a class is the definition of an object.
>>
>> An example of a class:
>>
>> class A {
>> int x;
>> int y;
>>
>> };
>>
>> There is no object of type A defined here by this class. The objects, if
>> any, are defined later in other parts of the program, e.g.
>>
>> A a;
>>
>> This line is the definition of an object a (by the C++ standard). It is a
>> single line which contains the name of the class. However, this line does
>> not "contain" the class A, it only refers to the class A. So it does not
>> make any sense to say that "a class is the definition of an object".
>> Besides, there may be many objects of the same class, one does not create
>> a new class for each new object.
>
>
> THe C++ standards states the following:
>
> "2 A class is considered a completely-defined object type (3.9) (or
> complete type) at the closing } of the
> class-specifier. "

The important word there is 'type'.

A is a type, a is an instance of that type.

--
Ian Collins

On Jan 5, 1:46*pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Paavo Helde" <myfirstn...@osa.pri.ee> wrote in message
>
> news:Xns9E64E6338AD30myfirstnameosapriee@216.196.1 09.131...
>
>
>
> > "Paul" <pchris...@yahoo.co.uk> wrote in
> >news:7f3Vo.66960$2:
>
> >> More to the point a class is the definition of an object.
>
> > An example of a class:
>
> > class A {
> > * *int x;
> > * *int y;
> > };
>
> > There is no object of type A defined here by this class. The objects, if
> > any, are defined later in other parts of the program, e.g.
>
> > A a;
>
> Section 9.2 of the C++ standards states that....
>
> "2 A class is considered a completely-defined object type (3.9) (or complete
> type) at the closing } of the
> class-specifier. Within the class member-specification, the class is
> regarded as complete within function
> bodies, default arguments, exception-specifications, and
> brace-or-equal-initializers for non-static data members
> (including such things in nested classes). Otherwise it is regarded as
> incomplete within its own class
> member-specification."
>
> > This line is the definition of an object a (by the C++ standard). It is a
> > single line which contains the name of the class. However, this line does
> > not "contain" the class A, it only refers to the class A. So it does not
> > make any sense to say that "a class is the definition of an object".
> > Besides, there may be many objects of the same class, one does not create
> > a new class for each new object.
>
> see above quote from C++ standards.

Ok. Now we're getting somewhere. I potentially see where your
confusion lies. Consider the terms:

"object of type"
"object type"
"type"
"class"

Paavo effectively said that:
class Foo {};
did not define an object. These are entirely consistent rephrasings:
1- This does not define an object.
3- This does not define an object of Foo.
2- This does not define an object of type Foo.

In "This does not define an object of type Foo.", the word "type" is a
modifier of the word "Foo". It adds emphasis and clarity that "Foo"
refers to a type and not something else.

You quoted the standard "2 A class is considered a completely-defined
object type (3.9) (or complete type) at the closing }". The key
phrasing is "object type". Here, the word "object" is a modifier of
the word "type". The word "object" adds emphasis and clarity that the
"type" only describes objects - as opposed to a /function/ type.
(Functions are not objects. Objects are not functions.)

Thus, the section you quoted from the standard clearly agrees with and
is consistent with Paavo. The quoted section of the standard states
that a class definition defines a type, specifically an object type.
It does not say that it defines an object.

Öö Tiib <> writes:
> On Jan 5, 10:59Â*pm, Keith Thompson <ks...@mib.org> wrote:
>> Öö Tiib <oot...@hot.ee> writes:
>> > On Jan 5, 6:36Â*pm, Keith Thompson <ks...@mib.org> wrote:
>> >> Öö Tiib <oot...@hot.ee> writes:
>>
>> >> [...]> We discuss C++ here and so we use C++ object model where member
>> >> > functions and data members are described by and belong to class and
>> >> > are not objects or parts of objects. Types are not objects in C++,
>> >> > functions and member functions are not objects in C++.
>>
>> >> [...]
>>
>> >> I think you misspoke here. Â*Data members are parts of objects.
>>
>> > Yes, i meant that the data member declarations are part of class and
>> > can not be altered during program run by C++ language.
>>
>> You mean the declarations cannot be altered, right? Â*Of course the data
>> members themselves (the values stored in them) can be altered.
>
> Yes the values of member subobjects and base subobjects can be
> modified. C++ instructions are not data so you can not alter object's
> type or function's behavior dynamically. There are other languages
> that allow such run-time metaprogramming, but not C++.

Ok. I knew all that; I just wanted to make sure it was being stated
clearly.

--
Keith Thompson (The_Other_Keith) kst- <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"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/04/2011 10:56 PM, Paul wrote:
>
> "Garrett Hartshaw" <> wrote in message
> news:ifvr1i$kl9$...
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/04/2011 08:46 AM, Paul wrote:
>>>
>>> "Ulrich Eckhardt" <> wrote in message
>>> news:...
>>>> Paul wrote:
>>>>> The problem is you can't accept that the member function called on an
>>>>> object is specific to that object.
>>>> [...]
>>>>> 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.
>>>>
>>>> So first a member function is specific to an object but another
>>>> object of
>>>> the same class may use the same function? That is a contradiction.
>>>>
>>>
>>> Consider 2 instances of the same Object,
>>> You could say that is a condradiction but you don't when you
>>> understand it.
>>>
>>
>> An object is an instance of a *class*. You cannot have 2 *instances* of
>> an object because you can't even have one.
> I think you'll find you can have an array of objects if you choose, each
> object being a different entity.
> If you cannot understand this please do not make obscure statemets that
> imply the negative.

Yes, you can have multiple objects (instances of a class), what you
cannot have is multiple "instances of the same Object", because that is
nonsensical (instances of the same instance of a class).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJQZSAAoJEO0SzzQOdchN460QALRQisuqRI Rkxd+NKH3W4imA
bjjL6jW45dQ4pFfqcu+2N3MQGJTXsObTa4Sky+mtDkMNVihtnj iUWFpX2rB/u5O3
qXHDKK0HuXhAyztk0ns3WLBHdYOnlV142s73DVw6paYqx6yCiM QWb8zArViJINgh
WG8NKJgpMgh0dDwDR1TT7TozQmMUcDWuDuMJlPNbQoVbkebz6t v3bfd4nK01IRIN
XiQmHCF7D/8gzMvYcnNkH6FurRiNwYii/45XLL177at5Q3tIUN/2NNhsPi/KpSb6
hGUXAj7+umeBQIJwdZnuema7BzvuyIWp3qENEkN1lcATuSLRIT yEYleoJZnO6P/D
oD0dVQpg9tbgXhN09TAwj6N2Ybw/sXq6qzaXMTb5UXaC0ShAKoIn5lkkN2aJoo6r
shosFd4769S+qT0ujJ4TqEtZrL/n9LFMNDn4HPevUDXFjrQO20aPuSGDMJOiOJJp
T3rCcYyhMIlkaOHH2HDwJA3ah+OgtWvO3mgLwwL/XU2FswvgYCm9gpuz9/fXJMIO
pz+5UqeNu/w4Nl3pH/q1uSh00pYk/3xyN7npAEP+G3FABmq7OMNx2LEFgAdGC/0N
gkjHgxojPEojgWl372L0DnElv9/n9qGZM3h94LC4NvmURAzXhKVw2/WRcLC9/9VG
riyIrAPr0dfy7+4MdXOT
=eVe3
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/05/2011 12:44 PM, Paul wrote:
>
> "Ulrich Eckhardt" <> wrote in message
> news:...
>> Paul wrote:
>>> "Garrett Hartshaw" <> wrote in message
>>> news:ifvr1i$kl9$...
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 01/04/2011 08:46 AM, Paul wrote:
>>>>>
>>>>> Consider 2 instances of the same Object,
>>>>> You could say that is a condradiction but you don't when you
>>>>> understand it.
>>>>>
>>>>
>>>> An object is an instance of a *class*. You cannot have 2 *instances* of
>>>> an object because you can't even have one.
>>> I think you'll find you can have an array of objects if you choose, each
>>> object being a different entity.
>>
>> So? An array of distinct objects, each of the same type. This doesn't
>> contradict Garret's statement in the least.
>>
>>> If you cannot understand this please do not make obscure statemets that
>>> imply the negative.
>>
>> Read it again, expert, you talk about instances of an object, but that
>> term itself doesn't make sense. An object is an instance of a type. You
>> can not have instances of an object. You can have multiple instances of
>> the same type as an object, but that's not what you said.
>>
>
> So what happens if you copy an object?
> You create a new instance of that object.
> What part of that do you find difficult to understand?
>

When you copy an object, you get a new instance of the class that that
object was based on with that same values for all of the members. As a
class is defined by the C++ standard to be a region of storage, it is
nonsensical to say that you have a new instance of that region of
storage. What you have is a different region of storage that happens to
be storing the same thing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJQpkAAoJEO0SzzQOdchNegQP/0bBECQc72RZL1dHasUOjgAd
Iwexzts156+2Xz0r7qVk+yR8Upqm3g3P8HWhcYrhewqPFVMngD wqUhMZa2GQlFH/
odfn0h4VyL2rp10TYBFWkR84fNYg/wmT27Ae06mFtLSNXtkQoYz1MaROeWdO5TQ7
HbI7IwKzfId6OMk7Uh7ogBk41kNpwaA2fEgNiRNJatLNfrVPTN jRl02KV6cGumXl
tele56xO6JlosX3Dvv98V/nqvZPcpv/7AEvmadxMtUYYotaXp9z5aV+WawynXfaV
pENfk5oJZF3Nny/1fvgPCRPlVbmFsm7czAyjlitEwemuaJCD5CGaonPVj9Mc+BXD
46Idq4X0VVnw5qG+UuucuIzGNiUDJ2e6E7MQLGKaTx5wD/Uxpt1RDUDOcY0TkljY
EmiM0R7iw4tkVmBuDWygZ8UQ1AlVylS7zVi73Ru+M3mq6D0oFC zZpjhyFTout4VM
GNwGA6qeAPwekA315PnBuTOhmxlo6XjWRCFEinpgA+t6vUdC8q sQJ0sSPXc2vU6s
of0l+u4V6UxFsuFO4jT2NXXzwcip9+QcNF2XWU2cAIZO57NtO4 p2Qc3LN6BCjDgN
lDiDgIgT/W+FHMjyaMrxyaOkPB/NNtLHz/l+ERzb/DSyoVI+UY4/ykSlQngUzWKV
ay/Igexpa/k+OEOkK/Zw
=xxrN
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/05/2011 04:46 PM, Paul wrote:
>
> "Paavo Helde" <> wrote in message
> news:Xns9E64E6338AD30myfirstnameosapriee@216.196.1 09.131...
>> "Paul" <> wrote in
>> news:7f3Vo.66960$2:
>>
>>> More to the point a class is the definition of an object.
>>
>> An example of a class:
>>
>> class A {
>> int x;
>> int y;
>> };
>>
>> There is no object of type A defined here by this class. The objects, if
>> any, are defined later in other parts of the program, e.g.
>>
>> A a;
>>
>
> Section 9.2 of the C++ standards states that....
>
> "2 A class is considered a completely-defined object type (3.9) (or
> complete type) at the closing } of the
> class-specifier. Within the class member-specification, the class is
> regarded as complete within function
> bodies, default arguments, exception-specifications, and
> brace-or-equal-initializers for non-static data members
> (including such things in nested classes). Otherwise it is regarded as
> incomplete within its own class
> member-specification."
>

An object type, is a type that *describes* an object, not the object
itself. An object is an instance of the class (object type).
>
>> This line is the definition of an object a (by the C++ standard). It is a
>> single line which contains the name of the class. However, this line does
>> not "contain" the class A, it only refers to the class A. So it does not
>> make any sense to say that "a class is the definition of an object".
>> Besides, there may be many objects of the same class, one does not create
>> a new class for each new object.
>>
>
> see above quote from C++ standards.
>
>>> Classes and objects are not completely different entities as you
>>> suggest.
>>
>> Classes exist only at compile time. Objects exist only at run time. I
>> think one cannot get much more different than that.
>>
>> In other languages the terminology may be different and the borders
>> between compile and run time less clear or nonexistant, but this does not
>> concern these C++ groups at all.
>>
>> Paavo
>>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJQxlAAoJEO0SzzQOdchNKAAP/RcelcRD5TOwMOp79x+UcyaQ
5aWBqUGntbESambjcLAFVNtUNVfolmqwQ1+s18+vcZki7ink3h iepzWi4JCwM4qT
lNLnyn1JChx9/6uNEn2BVQx0Qog8fU+lMNpwbHcqhFbXhsxfNVLwHfreenssNsh b
206pEYGoJMIo8Y1hofxDHkThPFxP1ZYP1YFJ+EZb+MQBHzkyur DTXJoSm8KhAzmh
q0P+kmarLBOxQ1SxYCaQFcRYOhrt/zLCPyOm3Bj53+EQMqrhc6FDsoC9uCp39Vsh
iCzMu46CzO+dqLk1DpJHtOHOZGYGWC8LRVOwolAz8EpCW6n2gl eEgEmC4lNkn2Jw
89VJnENkdtpBfGMpCpMK2Yjfd/4uP0L1GJIYnlrM3XZypcqI+ga+PKMyyGTTBASt
agODq6p0uYxtKHaccv1yLchjjQoq/AF4snp97IgJG+sWi1CAWtuyGkT/WuK/eGTQ
gEacXw8P7Q1tce1qacrM0KzBoGnSPpfxz5f9vbE3Ho5HEzSkMi GQ1ISnM776t5+D
SbuI194YA/Q0xESY1hbE2kYqlDnJ1SBDMviecfXC+Qnm3dAF/6qPwbb6DWMd7QWO
8VPFfZDsyd7cP7m351nUreX7NvJwvNvn2GeruYvs2y8bIJQV11 VSMPzm6RrtB+GS
uVlEGRaLRa6IAbLL8HDA
=Ts/D
-----END PGP SIGNATURE-----

Garrett Hartshaw <> writes:
[...]
> When you copy an object, you get a new instance of the class that that
> object was based on with that same values for all of the members. As a
> class is defined by the C++ standard to be a region of storage, it is
> nonsensical to say that you have a new instance of that region of
> storage. What you have is a different region of storage that happens to
> be storing the same thing.

Correction: an *object*, not a class, is defined to be a region of
storage. (I'm sure it was just a typo.)

Note also that the type of an object needn't be a class. For example:

int x;

creates an object (a region of storage than can hold values of type int).

--
Keith Thompson (The_Other_Keith) kst- <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"