technical correctness

Ö

Öö Tiib

Öö Tiib said:
[...]> 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++.
 
J

Joshua Maurice

Joshua Maurice said:
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.

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

stan

James said:
On Jan 3, 9:29 pm, Leigh Johnston <[email protected]> wrote:

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

Ian Collins

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

Joshua Maurice

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


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

Keith Thompson

Öö Tiib said:
Öö Tiib said:
Öö Tiib <[email protected]> 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.
 
G

Garrett Hartshaw

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

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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/

iQIcBAEBAgAGBQJNJQZSAAoJEO0SzzQOdchN460QALRQisuqRIRkxd+NKH3W4imA
bjjL6jW45dQ4pFfqcu+2N3MQGJTXsObTa4Sky+mtDkMNVihtnjiUWFpX2rB/u5O3
qXHDKK0HuXhAyztk0ns3WLBHdYOnlV142s73DVw6paYqx6yCiMQWb8zArViJINgh
WG8NKJgpMgh0dDwDR1TT7TozQmMUcDWuDuMJlPNbQoVbkebz6tv3bfd4nK01IRIN
XiQmHCF7D/8gzMvYcnNkH6FurRiNwYii/45XLL177at5Q3tIUN/2NNhsPi/KpSb6
hGUXAj7+umeBQIJwdZnuema7BzvuyIWp3qENEkN1lcATuSLRITyEYleoJZnO6P/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-----
 
G

Garrett Hartshaw

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

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+yR8Upqm3g3P8HWhcYrhewqPFVMngDwqUhMZa2GQlFH/
odfn0h4VyL2rp10TYBFWkR84fNYg/wmT27Ae06mFtLSNXtkQoYz1MaROeWdO5TQ7
HbI7IwKzfId6OMk7Uh7ogBk41kNpwaA2fEgNiRNJatLNfrVPTNjRl02KV6cGumXl
tele56xO6JlosX3Dvv98V/nqvZPcpv/7AEvmadxMtUYYotaXp9z5aV+WawynXfaV
pENfk5oJZF3Nny/1fvgPCRPlVbmFsm7czAyjlitEwemuaJCD5CGaonPVj9Mc+BXD
46Idq4X0VVnw5qG+UuucuIzGNiUDJ2e6E7MQLGKaTx5wD/Uxpt1RDUDOcY0TkljY
EmiM0R7iw4tkVmBuDWygZ8UQ1AlVylS7zVi73Ru+M3mq6D0oFCzZpjhyFTout4VM
GNwGA6qeAPwekA315PnBuTOhmxlo6XjWRCFEinpgA+t6vUdC8qsQJ0sSPXc2vU6s
of0l+u4V6UxFsuFO4jT2NXXzwcip9+QcNF2XWU2cAIZO57NtO4p2Qc3LN6BCjDgN
lDiDgIgT/W+FHMjyaMrxyaOkPB/NNtLHz/l+ERzb/DSyoVI+UY4/ykSlQngUzWKV
ay/Igexpa/k+OEOkK/Zw
=xxrN
-----END PGP SIGNATURE-----
 
G

Garrett Hartshaw

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

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).
see above quote from C++ standards.

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

iQIcBAEBAgAGBQJNJQxlAAoJEO0SzzQOdchNKAAP/RcelcRD5TOwMOp79x+UcyaQ
5aWBqUGntbESambjcLAFVNtUNVfolmqwQ1+s18+vcZki7ink3hiepzWi4JCwM4qT
lNLnyn1JChx9/6uNEn2BVQx0Qog8fU+lMNpwbHcqhFbXhsxfNVLwHfreenssNshb
206pEYGoJMIo8Y1hofxDHkThPFxP1ZYP1YFJ+EZb+MQBHzkyurDTXJoSm8KhAzmh
q0P+kmarLBOxQ1SxYCaQFcRYOhrt/zLCPyOm3Bj53+EQMqrhc6FDsoC9uCp39Vsh
iCzMu46CzO+dqLk1DpJHtOHOZGYGWC8LRVOwolAz8EpCW6n2gleEgEmC4lNkn2Jw
89VJnENkdtpBfGMpCpMK2Yjfd/4uP0L1GJIYnlrM3XZypcqI+ga+PKMyyGTTBASt
agODq6p0uYxtKHaccv1yLchjjQoq/AF4snp97IgJG+sWi1CAWtuyGkT/WuK/eGTQ
gEacXw8P7Q1tce1qacrM0KzBoGnSPpfxz5f9vbE3Ho5HEzSkMiGQ1ISnM776t5+D
SbuI194YA/Q0xESY1hbE2kYqlDnJ1SBDMviecfXC+Qnm3dAF/6qPwbb6DWMd7QWO
8VPFfZDsyd7cP7m351nUreX7NvJwvNvn2GeruYvs2y8bIJQV11VSMPzm6RrtB+GS
uVlEGRaLRa6IAbLL8HDA
=Ts/D
-----END PGP SIGNATURE-----
 
K

Keith Thompson

Garrett Hartshaw said:
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).
 
P

Paul

Ian Collins said:
The important word there is 'type'.

A is a type, a is an instance of that type.
So it follows that, as 'a' is of type 'A', 'a' is defined in class A.
There is only one definition for all A's.
Are you suggesting that each instance has a seperate definition?
 
U

Ulrich Eckhardt

Paul said:
Ulrich Eckhardt said:
[...] 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.

No, you create a new instance from that object. One started its life based
on the other. They are not two instances of the same object, as that very
term makes no sense. Get on the web and try to get a thorough
understanding of the difference between "identity" and "equality".
What part of that do you find difficult to understand?

I find you hard to understand, because several things have been explained
to you multiple times and you still don't get them. Even worse, you call
people idiots and bullies just because they tend to get fed up with you,
but you obviously don't spend much time understanding other people's point
in the first place.
 
J

Joshua Maurice

So it follows that, as 'a' is of type 'A', 'a' is defined in class A.
There is only one definition for all A's.
Are you suggesting that each instance has a seperate definition?

For fear of repeating some horrible behavior I recently did in C, IMHO
this is how it goes.

A declaration introduces a name into scope and gives a particular
meaning to that name.

A definition is some "thing" which gives a particular meaning to some
entity which is not a name. Such things include classes, types,
functions, objects, and so on. Usually there is exactly one definition
of any particular "thing" in any one program, aka the One Definition
Rule.

A definition is usually a declaration - a definition usually brings
into scope a new name with a particular meaning.
class Foo {};
The above is a declaration of the name Foo. It is also a definition of
the type with name Foo. It is a definition of a type, of a class, of a
class type, of an object type, of a user-defined type, and so on.
Usually we use shorthand and say it's the definition of Foo.

class Foo;
The above is a declaration of the name Foo. It declares that the name
Foo refers to a class type. It is not a definition of a type.

extern Foo bar;
The above is a declaration of the name bar. It declares that the name
bar refers to an object of type Foo. It is not a definition of a type.
It is not a definition of an object.

Foo baz = Foo();
The above is a declaration of the name baz. It declares that the name
baz refers to an object of type Foo. It is also a definition of an
object with the name baz. Usually we use shorthand and say it's the
definition of baz. This is not a declaration nor definition of the
type Foo.

Questions?
 
J

James Kanze

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

[...]
More to the point a class is the definition of an object.
Classes and objects are not completely different entities as you suggest.

"Class" and "object" are two different words, with very
different meanings. Object is a runtime concept: objects have
lifetime. And an object may be of any type, not just a class
type. Class is a compile time concept: a class has scope, for
example, which an object doesn't, but it doesn't have lifetime.
The two things are quite different.
 
G

Garrett Hartshaw

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

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).
Yes that was a typo, and I was trying to narrow it down to objects with
a type defined by a class, not that I really expect that to help.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJhRzAAoJEO0SzzQOdchNWlQQAI1jKDKele55KccRO3bp+vXC
0sxixa9cmvTpox35z9XXpgJxgX3IAK9SC7eHDvNnChR48ITd5JfXTUK9Q+ckSNQK
wbf7DzZPHyex0jLbE+hEpfcg9yjs+RI9TaoITs89t++7iRzcc8Bw0ztuy8Kjl7rB
X9i6QkPDCsMhp4yTHMBYqUJl9PFXI4OQjL9sDqLiM1RIGOVYNa8+RKeQQi5OLW70
Qt3dm4Jfv+Su9xbcyCCrXzp/HQK5jSwqOZb2RYlbBuTC2hsMBCllIboqqf/hKQwo
kxVSddornQfhiS35NA7LZZ6/SONlc+z7tw0bBMPyAekyJNFPC5dTPGSHOeeNtazK
/oALIxvhZuZBxmc6QlIsn3eHtNoEMlQ1sUS2WGLx2OijpFSwyxDE2JIOqjd+8m16
CqYHJA3FZbyoJb1OZea/lTyzOHcJiqssBJJ+iFE9F0KCGfROtaRfcA2k1x/dm0BL
9xMnXhC/ASXgBjZmNe/Olgw1XOY4R4FCp+3ynFNShFtk/fo9bUrCK2UPTDsqRCCV
hjAyCSYvnFMiEe+s4opXOUt2LDUPNVJIIOQlL+zQMtTIGZb2UvUpLXBucfnarSjf
2bGBErqJi/kKquYlLdoufVEp8sPgIiJj9X8R0KttnTTAl0HHsi61LIyH2orDG+XM
IoNnzEDvAZeb/1qmbA18
=Vd1f
-----END PGP SIGNATURE-----
 
U

Ulrich Eckhardt

Paul said:
A class is an object type as the C++ standards clearly state:

Yes, a class is a type, just like an enumeration. A type is not an object.
An object type is also not an object, but a type. Instantiating it will
yield an object.

Simple thing, at least for those willing to understand.
 
N

Niklas Holsti

Paul said:
A non-static
member function declared within an objects class is exclusivelly related
to that object and no other object.

So, assume a class C, a non-static member function foo() defined within
C, and two different objects x and y, both instances of class C.

By your reasoning, since foo() is defined within the class of object x,
foo() is exclusively related to x and to no other object.

By the same reasoning, since C is also the class of object y, foo() is
also exclusively related to y and to no other object.

That is a contradiction, since x and y are different objects. Thus your
statement above is wrong.
 
P

Paul

Niklas Holsti said:
So, assume a class C, a non-static member function foo() defined within C,
and two different objects x and y, both instances of class C.

By your reasoning, since foo() is defined within the class of object x,
foo() is exclusively related to x and to no other object.

No foo() is not neccessarily defined within the class, it is declared in the
class.
The class defines the type-C. That is, the class defines that all objects of
type-C will have a member function foo();
Note this is not the same as saying the member function foo() is deifned in
the class.
:)
By the same reasoning, since C is also the class of object y, foo() is
also exclusively related to y and to no other object.


That is a contradiction, since x and y are different objects. Thus your
statement above is wrong.


I dont even know what you are trying to say I am wrong about here and I dont
really care much anymore but.....
I think you will find it's obviously you thats wrong .
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top