technical correctness

[Paul]

More to the point, C++ very distinctly distinguishes between
"object" and "class", with an object being an instance of
a class. Formally, it is the class which has members, not the
object, although it makes sense in less formal speech to speak
of the members of an object when one is referring to the members
of the class which have a separate instance in each object (e.g.
the non-static data members).

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

 

[Paul]

message

[snip]

So, in C++ an object is a very primitive thing; just a region of
memory.
Note that this region might not have an address (think of
temporaries)

No it's not JUST a primative region of memory. THe standards themselves
stAte that an object can contain member subobjects

And ?
It is just a matter of memory layout, duration and order of
initialisation/destruction.

Typically, int he next standard, you will have standard-layout class
what are basically POD with member functions.

Yes, writing about C++ can lead to considerable confusion which is
exactly
why we should try to use the terms in the way C++ has defined them
even
if
those terms might have other meanings in the broader context of
programming.

The problem is you misinterpret the standards as you have clearly done
in
this post by stating:
" So, in C++ an object is a very primitive thing; just a region of
memory."

This is commpletely different from what the standards state. In fact it
is
almost the oppisite meaning.

I will dutifuly quote the standard just has many have done.
"1.8 The C++ object model
The constructs in a C++ program create destroy, refer to, access, and
manipulate objects. And "object" is a region of storage. [Note: A
function is not an object, regardless of whether it occupies storage
in the way that objects do]. [...]
An object can have a name[...]has a storage duration[...]has a type.
[...]"

A function is not an object and as such cannot be a subobject.

In the last part, it is not said that an object can have a function
(only name,duration,type).

IMO Paul is often right in the broader context but does not seem to
grasp
that that can make him mistaken in the narrower context of C++.

If you think I'm incorrect please point out where.
I don't see how I can be incorrect when I am simply going with what is
stated in the standards.

I must have missed the relevant post in which you quote the standard
supporting your point. ...................................................................................................................................................
Well once again we seem to have a newsreader that doesn't like to indent
your txt.

You seem the only one to have this problem.

However this will not stop me form replying to your post.

You have dutifu quoted form the standads a part of the following re:
<quote>
[snip]

[ Note: A function is not an object, regardless of
whether or not it occupies storage in the
way that objects do. -end note ]

From the quote you copy paste, you see that functions are not object.
Right ?

[snip]

Please note that you have only quoted a small part of the standards and
that

I quoted only the relevant part in order to keep it short (and I have
here only my compagny's old C++98 standard pdf which doesn't allow
copy/paste). And while you quote the full text, don't give your
interpretation.

your interpretation of the standards is very incorrect.

Really ? Please elaborate ... after all don't.

If you were to read the next paragraph of the standards re~:
<quote>
2 Objects can contain other objects, called subobjects. A subobject can
be a
member subobject (9.2), a base
class subobject (Clause 10), or an array element. An object that is not a
subobject of any other object is
called a complete object
</quote>

Which is basically a way to see that the memory area of an object is
an agregation of the memory areas of its suboject. Not great news, it
is already the same for struct in C (except for base class).

And we have seen from your quote that functions are not objects and
thus are not part of an object.

Now we see what the standards clearly states.
Please would you refrain form misinterpeting the C++ standards in this
newsgroup or any other newsgroup I chose to view as your
misinterpretations
can be very confusing for someone less knowledgeable than myself. You
have
chosen a small snippet of text from the standards and you have tried to
interpret it in such a way to mean something other than its intended
meaning. This suggests to me that you
a) do not understand the standards and the C++ programming language.
b) chose to misinterpret the standards to support an argument in which
you
are fundamentally wrong.

So you are basically telling me that I am incompetent and dishonest.

That pretty much sums things up yup

Really, I don't see the point in continuing this thread.

Good you were wrong anyway.

 

[Paul]

Exactly what are your credentials to claim to be an expert (the often
lecturing tone of many of your posts clearly show that in your own mind
you are an expert). Your continued ignorance of who you are talking about
reveals that you actually have very little knowledge as to who have
credentials as C++ experts (though few of those who are would be arrogant
enough to claim that they were)

My credentials are proving you guys wrong on here and being the one who is
technically correct.

I do not claim to be an expert though my credentials include representing
my country at ISO meetings for both C and C++ over almost two decades and
frequently being designated by my country's Standards body (BSI) as being
the Principle UK Expert at those meetings.

Nonetheless I do not consider myself an expert just someone who had the
time and the inclination to attempt to contribute constructively to the
development of C++.

You've made an incorrect technical statement.
I don't care if you've been knighted by the queen, it doesn't make you
right all the time.

As usual you trivialise by ignoring the wider context.

What is the wider context?
People are refusing to accept that objects can contain member functions, and
you are one of those people.
It is not my fault you're wrong. Just because I happen to be the one who is
correcting you.

Yes and I guess it is only the current season that has encouraged so many
others to attempt to persuade you to understand more than you do. Does it
not seem strange to you that not a single person here (in a.c.l.c-c++) has
supported your views? At least half of the contributors to this thread are
highly respected and widely acknowledged experts.

I don't give a shit who supports me or who doesn't , I know what is
technically correct and what isn't.

If anyone thinks I am being unfair to you I hope they will now post their
disagreement with me. That you will disagree is a foregone conclusion so
do not waste your time by replying.

Why can't you just accept what is technically correct, that is :
a) objects can contain MEMBER functions.
b) input does not mean to extract from stream to a variable or object.

Why do you choose to be wrong about this? What do you find so difficult to
understand?
It's pretty clear, simple and straightforward to me.

You don't even have a clue who I am yet you automatically dismiss me as a
nobody and refuse to accept that I can possible correct you. That is your
choice not mine
You refuse to accept what is clearly stated in the C++ standards and any
other document I produce as proof of technical correctness, you are
obviously so high and mighty that you will decide what is wrong and right.

 

[Keith Thompson]

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.

 

[Paul]

If anyone thinks I am being unfair to you I hope they will now post
their disagreement with me. That you will disagree is a foregone
conclusion so do not waste your time by replying.

What can be said has been said in many ways many times. At this
point the OP is acting like a troll. For trolls it best to just
call bs and then ignore. Any extra attention simply fuels their
trolling.

KHD

HAHAHA

You have been defeated technically so will try to dismiss this whole thing
as me being a troll ?
LOL
Yeah you go slither away and teach yourself what an object is.

 

[Keith Thompson]

While this might be correct with a most broad reading of the standard,
it cannot be on any sane implementation. Simple placement-new usage
makes such an implementation impossible or perverse (perverse w.r.t.
the spirit and intent of C++ and its design goals). All sub-objects on
all non-perverse implementations exist in the memory region of the
complete object.

The source of confusion, I think, is that you and Paul are using
the same words to refer to different things.

Paul apparently believes that a member function is a "subobject".
If his usage of the term "subobject" were correct, his statement that
a subobject "does not necessarilly reside within the same storage
region as its respective complete object" would be absolutely
correct.

I think he understands perfectly well that a member function don't
reside within the same storage region as an object. The confusion
comes from his incorrect use of terminology and from his refusal
to accept the possibility that he might be wrong about anything,
not from any real misunderstanding of what's going on.

And I see from followups that he believes that others believe that
member functions may reside within the same storage region as an
object; this is a complete misunderstanding on his part about the
basis of the disagreement.

[...]

Paul, one last thing. Have you ever been mistaken about anything?
(I'm not necessarily referring to anything discussed in this thread.)
If so, what was your reaction when someone pointed out your mistake
and you realized that you had been wrong? Did you acknowledge the
correction and change your mind, or did you continue to assert that
you were right all along and everyone else was wrong?

 

[Paul]

Can you please elaborate on what you mean by this?
Please note that this is outside the scope of the C++ standards, The C++
standard does not define the storage of runtime objects on any given
system.

Any given system does not matter, nature and contents of storage of
object are described by type of object in C++. There are languages
where you can alter objects run-time and add new member functions and
new data members to objects (like Javascript). In such languages
members, their existence and nature are described by object. Such
languages are better to discuss elsewhere, because C++ does not have
such capabilities.

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

............................................................................

You fail to understand that a class is the definition of an object.
Please understand what a class is before dictating the rules of C++.

............................................................................
Objects whose type is a class are merely instances of that class. Data
members of class describe subobjects of each instance. Such subobjects
are contained in the region of storage of object and are part of that
object. Types can not be modified run-time by C++ program, functions
can not be modified by C++ program. Once object is instantiated it has
a type and can be used in (related to that type) functions. If you
need to achieve something more dynamic than that then you have to use
pointers to other objects (or member objects) or pointers to functions
(or member functions).
...........................................................................................................
I breifly sped read this .

blah blah blah m yeah yeah yeah

 

[Ulrich Eckhardt]

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.

 

[Paul]

Can you please elaborate on what you mean by this?
Please note that this is outside the scope of the C++ standards, The C++
standard does not define the storage of runtime objects on any given
system.

Any given system does not matter, nature and contents of storage of
object are described by type of object in C++. There are languages
where you can alter objects run-time and add new member functions and
new data members to objects (like Javascript). In such languages
members, their existence and nature are described by object. Such
languages are better to discuss elsewhere, because C++ does not have
such capabilities.

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

Objects whose type is a class are merely instances of that class. Data
members of class describe subobjects of each instance. Such subobjects
are contained in the region of storage of object and are part of that
object. Types can not be modified run-time by C++ program, functions
can not be modified by C++ program. Once object is instantiated it has
a type and can be used in (related to that type) functions. If you
need to achieve something more dynamic than that then you have to use
pointers to other objects (or member objects) or pointers to functions
(or member functions).



You seem very confused.
A class is an object type as the C++ standards clearly state:

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


The C++ standard implies you don't know what you are talking about. Perhaps
the standard is wrong and you are correct, But I doubt it .

 

[Paul]

So? An array of distinct objects, each of the same type. This doesn't
contradict Garret's statement in the least.


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?

 

[Paul]

And where did I say that it did? All I said is that the subobjects (both
member and base) must occupy storage that is part of the contiguous
storage that makes up the complete object.

It is incorrect to suggest that all subobjects MUST occupy storage, whether
it be contiguous within the objects region of storage or not.
A subobject can be zero in size and not occupy any storage re:

"6 Unless an object is a bit-field or a base class subobject of zero size,
the address of that object is the address
of the first byte it occupies. Two distinct objects that are neither
bit-fields nor base class subobjects of zero
size shall have distinct addresses.4"


Once again I have corrected you on a simple technicality, as always you will
refuse to accept this.

To suggest anything else is to fail to understand the requirements laid
down by the C++ Standard.

huh?
Its you that seems to be misunderstanding the C++ standards.

No an objects type is defined by its declaration. Actually we allow
something that C calls an effective type which is the type the storage is
being used for.

Again you disagree with the standards I quote section 9.2 paragraph 2:

"2 A class is considered a completely-defined object type (3.9) (or complete
type) at the closing } of the
class-specifier."

It's just ridiculously inconceivable that you should be arguing with these
very basic thing, you seem to be trying to argue just for the sake of
arguing.

For example we can take a raw block of storage (normally handled vis a
void pointer) and construct an instance of a class in that storage. At the
completion of the constructor the raw storage takes on the behaviour
provided by the class functions and friend functions.

dunno what your going on about here?

If an object contains 99 pointers those pointers are 99 subobjects. The
storage they point to is not the subobject. You may be unhappy with that
but that is the way that it is in C++. Memory acquired either dynamically
or provided externally (as when a pointer represents ownership) is NOT
part of the object.

I didnt say the memory location was a subobject but thats what you're trying
to say.
It is you who is associating subobjects with memory locations, not me.

No, a member subobject is one of two types of subobject that C++
recognises; the other is a base subobject. The C++ Standard tells me what
a complete object is in C++. In other contexts a subobject might mean
something quite different but in C++ it is exactly what the Standard says
it is.

A member subobject is defined in the C++ standard. Section 9.2
<quote>
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. Data members and member functions are static or non-static;
see 9.4. Nested types are
classes (9.1, 9.7) and enumerations (7.2) defined in the class, and
arbitrary types declared as members by use
of a typedef declaration (7.1.3). The enumerators of an unscoped enumeration
(7.2) defined in the class are
members of the class. Except when used to declare friends (11.4) or to
introduce the name of a member of a
base class into a derived class (7.3.3, 11.3), member-declarations declare
members of the class, and each such
member-declaration shall declare at least one member name of the class. A
member shall not be declared
twice in the member-specification, except that a nested class or member
class template can be declared and
then later defined, and except that an enumeration can be introduced with an
opaque-enum-declaration and
later redeclared with an enum-specifier.
</quote>


Note that the C++ standards clearly lists member function here surprisingly
enough as a member of the class.
..

Now we could have an interesting discussion about what a reference member
is. Here I suspect that the C++ Standard may be confused. However until
you can discuss things without throwing insults around I have no intention
of discussing it with you. In addition this is the wrong place for such a
discussion (comp.std.c++ would seem the appropriate place). If anyone
likes to raise the issue in csc++ I would be happy to explore the issue
there.

Suddenly you decide I'm not worthy again LOL
I have proven that you are technically incorrect and if you chose to slither
off an hide thats your prob not mine.

 

[Paul]

The source of confusion, I think, is that you and Paul are using
the same words to refer to different things.

Paul apparently believes that a member function is a "subobject".

No I don't

If his usage of the term "subobject" were correct, his statement that
a subobject "does not necessarilly reside within the same storage
region as its respective complete object" would be absolutely
correct.

I think he understands perfectly well that a member function don't
reside within the same storage region as an object.
The confusion
comes from his incorrect use of terminology and from his refusal
to accept the possibility that he might be wrong about anything,
not from any real misunderstanding of what's going on.

And I see from followups that he believes that others believe that
member functions may reside within the same storage region as an
object; this is a complete misunderstanding on his part about the
basis of the disagreement.

The fact that a member function is not stored within an object does NOT
prove that an object has no member functions.

[...]

Paul, one last thing. Have you ever been mistaken about anything?
(I'm not necessarily referring to anything discussed in this thread.)
If so, what was your reaction when someone pointed out your mistake
and you realized that you had been wrong? Did you acknowledge the
correction and change your mind, or did you continue to assert that
you were right all along and everyone else was wrong?

--

Objects can and do have member functions.
It is ridicuous to try an argue otherwise but this seems to be what you are
trying to do.

I'm sorry to be the one to tell you you are wrong.

 

[Dombo]

Exactly what are your credentials to claim to be an expert (the often
lecturing tone of many of your posts clearly show that in your own mind
you are an expert). Your continued ignorance of who you are talking
about reveals that you actually have very little knowledge as to who
have credentials as C++ experts (though few of those who are would be
arrogant enough to claim that they were)

Paul is an typical example of the Dunning-Kruger effect. As entertaining
as this thread may be, it also very unproductive as the chances of
improving Paul's understanding of C++ and (more importantly) his
interpersonal skills are about zero. It is better to ignore his posts.

 

[Balog Pal]

What can be said has been said in many ways many times. At this
point the OP is acting like a troll. For trolls it best to just
call bs and then ignore. Any extra attention simply fuels their
trolling.

That was the case from the very first post.
Other forums seem to go ahead of the problem and just deleted
Paul/virginmedia's threads for good.

 

[Ian Collins]

"Leigh Johnston" <[email protected]> wrote:

You don't seem to understand that a class is the definition of an
object. The fact that a member function is defined within the class
means that the function is part of that objects definition.

You don't appear to understand that the definition of an object isn't an
object.

Youstill haven't explained what type of program you think uses text and
data segments.

He doesn't have to. The terms are well known.

You are the one who is wrong.

So everyone else who agrees with him isn't?

Yes and I have done so.
The fact that a member function is declared in the scope of a class
should be evident enough.

No one is disputing that a member function is declared in the scope of a
class.

You seem to think a class has nothing to do with an object however I
accept that a class is the definition of an object. You don't seem to
know what you are talking about.

You are deliberately misinterpreting what others are writing to continue
an argument. No one is claiming what you say they are.

Congratulations on the first decent troll of 2011.

 

[Öö Tiib]

[...]> 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.

 

[Keith Thompson]

[...]> 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.

 

[Paul]

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.

 

[James Lothian]

That pretty much sums things up yup


Good you were wrong anyway.

At some point in the future, you will apply for a highly-paid
job, possibly involving C++. The manager for whom you would be
working will idly type your email address into google, and will
find this thread. He will read through it with a growing sense
of horror, and will decide that he doesn't want to interview you
after all.

Making a full-on arse of yourself in public isn't such a great idea.

James

 

[PaulR]

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


I HTH

Classes exist only at compile time. Objects exist only at run time. I
think one cannot get much more different than that.

I dont disagree with this.