Frasncis Glassboro wrote.

[Paul]

An object is a region of memory. But unlike most definitions in the
Standard, this one isn't bidirectional: Not every region of memory is an
object. An object:

- Can not exist.
- Exist but isn't completely constructed yet (this is true when it's still
within its constructor body). Lifetime at this point hasn't started yet.
- Exists and is alive.
- Exists but is in the process of being destroyed. At this point, lifetime
already has stopped. This is true when it's in its destructor body.
- Can not exist anymore.

Item 1 and the last item don't need memory obviously. But the other three
items need memory. For all types except class types or array of class
types,
you only have the first, third and last state.

Now when you have a raw piece of memory, you can't have all but the first
and last state, because all others need a type. For an object to exist in
C++, I think you at least need a type (this is different in C. In C types
aren't attributed to objects, but only to accesses to them. That's why it
talks about "effective" type only).

In the spec, "memory" is called "storage" - I think that's because C
actually enforced different storage areas for objects: registers and
memory.
Both are called "storage". C++ doesn't enforce this difference anymore.

I have no idea how the rules are in detail for lifetime starting of class
type and non-class type objects. In my opinion, the Standard isn't clear
enough on that.


An object doesn't "contain" member functions. An object also isn't
necessarily of class type.

Classes just declare member functins. Those functions are completely
"normal" functions in any other aspects. Even their type doesn't contain
anything specific to their class. For example a "void f() { }" member
function has type "void()".

If the member function is declared in the class then it is surely defined to
be part of that object type. Given that a class is the definition of an
object type.

 

[Paul]

Now you really are muddling up your singulars and plurals, aren't you?

lol

 

[Geoff]

* Paul, on 06.01.2011 16:25:

Don't start threads with the name of a person in the subject line.

Otherwise everybody will plink you.

That means, that all your articles are automatically sent to the big bit bucket
in the sky, by the newsreader software, so that they are not even seen.

"plink" and "plonk" both means taking the abovementioned measure, but the words
carry different connotations.

"plink" is the sound of a lightweight troll being flushed down the toilet.

"plonk" is used for a troll that has gained some respect, or for a person that
one just disagrees so violently with that one wishes to avoid confrontation,
i.e. a somewhat heavier mass being flushed down.

In Paul's case I'd make it more of a "ploik" vs. the heavier "plop".
Where ploik connotes the lightweight piece into a confined liquid
environment prior to flushing. I can't believe you guys persist in
feeding this troll.

A member function defines the interface to an object of the class,
there is no "member is a part of or contained in an object". In fact,
in Harvard architecture machines it is physically impossible for
member code to reside in the same memory space (segment) as the object
it interfaces. It is also perfectly acceptable for an implementation
to use the same code (member function) to access a different object of
the same class. Gee, could that be inheritance? The abstraction of
members and objects is entirely different from the implementation.

 

[Paul]

On 06/01/2011 21:56, Ulrich Eckhardt wrote:
Paul Reid wrote:
So just because the standard doesn't add an explicit exclusion,
anything else can be part of an object? Like Your Momma, for example?

Exactly,

I warmheartedly welcome Your Momma as a subobject.

the standard does not explicitly state that member functions
are not members of an object.

That is not how you should read this. In any case, it would require
adding
the term "..and nothing else" in hundreds of places. Look up e.g. the
definition of natural numbers. Does it explicitly exclude the others or
does it just specify those contained? You're obviously unused to
scientific and technical language, so this might be weird to you, but
it
is common and everybody understands it as such, once they are used to
it.


The standard states a subobject can be zero size, this is not coherent
with the statement that an object is a region of storage.

Right, this seems inconsistent. Read up on the exception when a
subobject
can occupy no additional storage. You need to understand the whole
image
first, then you can start arguing.


Also referneces are made to subobjects and MEMBER subobjects, so these
are obviously 2 different concepts according to the standards.

I didn't make these references. In any case, the definition of a
subobject
was already quoted elsewhere, in short it can be a member, baseclass or
array element. It is an object though, not a function.


These member subobjects are defined in section 9.2:

"1 The member-specification in a class definition declares the full
set
of members of the class;[...]"

Class members are not object members (member subobjects).


The standards clearly state a member function as a member of a class
so
it follows the member function is exclusively associated with that
object type, as the class is a definition of the object type.
If the definition of the object type defines a member function then
the
member function is part of the object because it was defined to be.

No that doesn't follow and the C++ standard explicitly says so, once
you
accept the lingo, that is.


The function code is the same for all instances of that object type so
it makes no sense, and would be very inneficient, to store a seperate
version of the function inside each objects storage region.

So the function is not contained inside the object's storage region.
Since
the object is defined as storage region, the function is not contained
inside the object. You can waffle all you want, switching between C++
standardese and colloquial use of terms, you are not documenting
inconsistencies in the C++ standard or other peoples' understanding
thereof but only your own lack of understanding.


Interestingly the C++0x draft standard states the following:

28.13/2
"Objects of type specialization of basic_regex store within themselves
a default-constructed instance of
their traits template parameter, henceforth referred to as
traits_inst. This traits_inst object is used
to support localization of the regular expression; basic_regex *object
member functions* shall not call any
locale dependent C or C++ API, including the formatted string input
functions. Instead they shall call the
appropriate traits member function to achieve the required effect."

It should probably say "basic_regex *member functions*" instead.
Relaxing the definition of what the term "object" means within the
draft document is a minor error but one that the troll Paul will
probably now pounce on, unfortunately.

Oh the lulz of it all; new year bollocks; I blame Holiday alcoholic
brain damage.

/Leigh

Obviously this guy doesn't have the brain capacity to understand the
difference between the terms
"object" and "object member function".

The term "object member function" does not exist in the C++ standard; as I
pointed out it did exist in the draft C++0x standard (although one can
argue it is a compound term) but this was an error which has now been
fixed by Pete. The default terminology of this newsgroup should be the
terminology defined by the C++ standard if available otherwise you need to
define your terms. In C++ member functions are part of classes not
objects.

The C++ standards do not define programming terms as they are used in this
or any other forum or newsgroup.
That fact that you seem to think so makes you appear very narrow minded.

Also "object type" does not mean the same thing as "object"; an object is
an *instance of* an object type; an object type does not have to be a
class.

int object;

How can this be an object when your definiton of an object is an *instance
of* an object type
You don't make sense and you seem completely confused about objects.

 

[Paul]

On 06/01/2011 23:50, Paul wrote:

On 06/01/2011 21:56, Ulrich Eckhardt wrote:
Paul Reid wrote:
So just because the standard doesn't add an explicit exclusion,
anything else can be part of an object? Like Your Momma, for
example?

Exactly,

I warmheartedly welcome Your Momma as a subobject.

the standard does not explicitly state that member functions
are not members of an object.

That is not how you should read this. In any case, it would require
adding
the term "..and nothing else" in hundreds of places. Look up e.g. the
definition of natural numbers. Does it explicitly exclude the
others or
does it just specify those contained? You're obviously unused to
scientific and technical language, so this might be weird to you,
but it
is common and everybody understands it as such, once they are used to
it.


The standard states a subobject can be zero size, this is not
coherent
with the statement that an object is a region of storage.

Right, this seems inconsistent. Read up on the exception when a
subobject
can occupy no additional storage. You need to understand the whole
image
first, then you can start arguing.


Also referneces are made to subobjects and MEMBER subobjects, so
these
are obviously 2 different concepts according to the standards.

I didn't make these references. In any case, the definition of a
subobject
was already quoted elsewhere, in short it can be a member,
baseclass or
array element. It is an object though, not a function.


These member subobjects are defined in section 9.2:

"1 The member-specification in a class definition declares the
full set
of members of the class;[...]"

Class members are not object members (member subobjects).


The standards clearly state a member function as a member of a
class so
it follows the member function is exclusively associated with that
object type, as the class is a definition of the object type.
If the definition of the object type defines a member function
then the
member function is part of the object because it was defined to be.

No that doesn't follow and the C++ standard explicitly says so,
once you
accept the lingo, that is.


The function code is the same for all instances of that object
type so
it makes no sense, and would be very inneficient, to store a
seperate
version of the function inside each objects storage region.

So the function is not contained inside the object's storage region.
Since
the object is defined as storage region, the function is not
contained
inside the object. You can waffle all you want, switching between C++
standardese and colloquial use of terms, you are not documenting
inconsistencies in the C++ standard or other peoples' understanding
thereof but only your own lack of understanding.


Interestingly the C++0x draft standard states the following:

28.13/2
"Objects of type specialization of basic_regex store within themselves
a default-constructed instance of
their traits template parameter, henceforth referred to as
traits_inst. This traits_inst object is used
to support localization of the regular expression; basic_regex *object
member functions* shall not call any
locale dependent C or C++ API, including the formatted string input
functions. Instead they shall call the
appropriate traits member function to achieve the required effect."

It should probably say "basic_regex *member functions*" instead.
Relaxing the definition of what the term "object" means within the
draft document is a minor error but one that the troll Paul will
probably now pounce on, unfortunately.

Oh the lulz of it all; new year bollocks; I blame Holiday alcoholic
brain damage.

/Leigh

Obviously this guy doesn't have the brain capacity to understand the
difference between the terms
"object" and "object member function".


The term "object member function" does not exist in the C++ standard;
as I pointed out it did exist in the draft C++0x standard (although
one can argue it is a compound term) but this was an error which has
now been fixed by Pete. The default terminology of this newsgroup
should be the terminology defined by the C++ standard if available
otherwise you need to define your terms. In C++ member functions are
part of classes not objects.

The C++ standards do not define programming terms as they are used in
this or any other forum or newsgroup.
That fact that you seem to think so makes you appear very narrow minded.

Also "object type" does not mean the same thing as "object"; an object
is an *instance of* an object type; an object type does not have to be
a class.

int object;

How can this be an object when your definiton of an object is an
*instance of* an object type
You don't make sense and you seem completely confused about objects.

*I* am confused??? Are you completely thick?

Yes you are confused and no I'm not thick but you obviously are, you said :

"an object is an *instance of* an object type; an object type does not have
to be a class."

You imply that an object can be a class, yet you also state that an object
is an instance of an object type, and you also give an example of an integer
as an object.
You don't seem to know what an object is. Maybe it's whatever you want it to
be.

 

[Ian Collins]

Yes you are confused and no I'm not thick but you obviously are, you said :

"an object is an *instance of* an object type; an object type does not
have to be a class."

You imply that an object can be a class

Where?

 

[Ulrich Eckhardt]

I can understand the concept you express but
a) how do you get the address of a member function?
b) what happens if this member function is virtual?
c) what happens if this member function is overridden?


I accept that it probably is possible to directly address a member
function but I do not know if this would be a valid program.

This is in the advanced section, but any good C++ book should explain the
syntax and semantics.

And what exactly would 'this' point to?

Why do you think you have to pass "an object of that class type" to the
call? Go away and learn what you are talking about, then come back and
argue.

 

[Ulrich Eckhardt]

My momma is dead. How is your momma doing?

I redraw my welcome, I don't like dead people.

In any case, it [not implying exclusion] would require adding the
term "..and nothing else" in hundreds of places.

No it wouldn't require adding "and nothing else" in hundreds of places.
It would require one line stating that an member function is not part of
an object.

But then, Your Momma would still be part an object, and I don't want dead
people as part of my objects!

Why dont you quote the definition of a subobject instead of giving your
re-definiton.

You quoted that part already. Go back and reread all your postings.

These member subobjects are defined in section 9.2:

"1 The member-specification in a class definition declares the full
set of members of the class;[...]"

Class members are not object members (member subobjects).

Who says so? YOU?

It is written there. It may not be obvious to you, but there is a
distinction between an object and a class. These terms are not used
interchangeably in the C++ standard for a reason.

A member function, defined in an objects class, can be considered a part
of that object, regardless of where the function code is stored in
memory.

This is completely true. Note the distinction between "can be considered"
and "is contained in". The former admits that it's not 100% correct but
for ease of use that view can be used. The latter makes a much stronger
claim, which then also conflicts with the C++ object model and has been
refuted already, only that you call those who did idiots and refuse to
acknowledge this fact.

 

[Ulrich Eckhardt]

28.13/2
"[...] basic_regex *object member functions* shall not call any
locale dependent C or C++ API[...]"

It should probably say "basic_regex *member functions*" instead.

I'd group this as "(basic_regex object) (member functions) shall ..". What
puzzles me is whether the "object" is supposed to exclude class-static
functions, or if it has a meaning at all.

Oh the lulz of it all; new year bollocks; I blame Holiday alcoholic
brain damage.

Possibly over multiple generations. I find this an interesting
sociological case study still.

Regards

Uli

 

[Juha Nieminen]

I can understand the concept you express but
a) how do you get the address of a member function?
b) what happens if this member function is virtual?
c) what happens if this member function is overridden?

I accept that it probably is possible to directly address a member function
but I do not know if this would be a valid program.

I find it a bit ironic that you protest so loudly abour common concepts
of C++ programming, yet you lack such knowledge of the language.

C++ "inherits" the notion of function pointers from C: You can take the
address of a function and eg. assign it to a variable of the function
pointer type. For example "void(*fptr)() = &f;" where f() is a function
with the signature "void f()". (Now you can call f() using fptr, simply
as "fptr()", as if 'fptr' had become a synonym for 'f'. In fact, you can
effectively think of 'f' as being literally a pointer to that function
as well.)

C++ also expands the concept to support pointers to member functions as
well, by expanding the function pointer syntax. For example, suppose you
have a class A with a "void f()" member function. You can create a pointer
to that function like "void(A::*fptr)() = &A::f;". Now you can call that
function with an object of type A eg. like: "A a; (a.*fptr)();". (What
this effectively does is that it calls the function pointed by 'fptr'
giving it the 'a' object as the 'this' parameter.)

If A::f() is virtual, the call using the pointer will work properly
(in other words, dynamic binding will be obeyed appropriately, in other
words, if the object is of a derived type which overrides f(), calling
the function using 'fptr' will call the derived implementation).

And what exactly would 'this' point to?

What do you think?

This does suggest that a member function need not be tied to an object.
It does not imply that a member cannot be tied to an object.

What do you mean by "member" here?

 

[James Kanze]

You can take the address of a member function (and assign it
to a function pointer of the proper type), and it will *not*
be tied to any specific object. (The similar concept in some
other programming languages *is* always tied to a specific
object, but not in C++.)

You can also take the address of a member variable, and assign
it to a pointer to member. I don't think that that's an
argument for anything particular.

I think that the issue is clear to everyone but Paul: in C++ (in
the vocabulary used in the standard), classes have members,
objects have subobjects. A function can be a member of a class,
but since it is not an object, it isn't be a subobject of an
object. This corresponds to the general vocabulary used in the
standard. Now, it's quite possible that the standard itself
slips up in its wording here or there, but those places should
probably be considered bugs in the standard (and in fact, when
Leigh pointed out one place in the draft standard, Pete
immediately corrected it, so the bug won't be in the next draft,
or in the final version).

[...]

I think that you have some confusion about what "class", "object" and
"member function" mean in the context of C++. The OO paradigm in C++ is
slightly different from that of certain other OO languages where the
distinction between objects and classes is absent (iow. there are only
objects, no classes per se).

I think it would be fairly accurate to say that C++ doesn't have
an OO paradigm. Or any other paradigm, for that manner. C++ is
a tool, which provides a number of structures which can be used
to *implement* various paradigms in your own code. (In
particular, derivation in C++ is *not* always OO inheritance;
think of things like inheriting from std::iterator or from
std::unary_function.)

 

[James Kanze]

"Juha Nieminen" <[email protected]> wrote in message

I can understand the concept you express but
a) how do you get the address of a member function?

&ClassName::functionName

Concretely:

struct C { void f(); };
void (C::*pf)() = &C::f;

b) what happens if this member function is virtual?

It works correctly. That's why pointer to member functions are
often larger than any other pointer types (but there are other
ways of solving the problem).

c) what happens if this member function is overridden?

Overload resolution occurs, in exactly the same way that it does
in the case of non-member functions.

I accept that it probably is possible to directly address
a member function but I do not know if this would be a valid
program.

I'm not sure what you mean by "directly" in this case, but the
above is definitely legal C++.

And what exactly would 'this' point to?

The class object you used in the dereferencing expression.

None of this has anything to do with the original question, but
it is standard C++, and any one claiming to know C++ should
certainly know it, even if it isn't the sort of thing you use on
a daily basis. (I've used pointers to member functions perhaps
two or three times in the twenty years I've been programming in
C++.)

 

[Paul]

I find it a bit ironic that you protest so loudly abour common concepts
of C++ programming, yet you lack such knowledge of the language.

The fact that you have began your posting with a direct insult to me leaves
me no other opinion than you are actually nothing more than an other
clueless idiot who has nothing more than an UNREASONABLE argument to put
forward.

SO I won't even borther to read any more of your SHITE.<snip>

 

[Marc]

<quote>
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) </quote>


This was used in the context of an attempt tojustify the argument
that an object cannot contain member functions.

I've read the standards documents only enough to get the gist of what is
there. I can relate though to 'object' being used with different meanings
in different concepts. I can also hold off on deciding how terminology is
being used until the message is clear, a clarity that any isolated
statement may not provide. The calculator on my desk is an object, but I
can't derive from it or compile it along with my programs. The use of
'object' has rather well-defined and accepted meaning when used in an OO
context. For the language lawyers/committee members who drafted the
standards, way before OO was in vogue (remember, C++ is "derived" from
C), 'object' has a more traditional meaning in the larger context of
programming languages. Note how compiler developers talk about
"constructors" that have different meaning than a C++ class's
constructors. As technology changes, terms get reused and reassigned but
that doesn't always happen immediately and in the mean time, one has to
rely on the "fuzzy" meaning of the terms and extract as best as one can
from the usage of the terms in the context, and that context means what
was meant by the conveyor of the message which may not necessarily be
what the conveyor wrote, as communication is a subtle thing and note that
language is pretty paltry and then text only is even worse. Now if you
want to be opportunistically evil and exploit that paltryness, run for
state's attorney!

 

[Paul]

&ClassName::functionName

Concretely:

struct C { void f(); };
void (C::*pf)() = &C::f;


It works correctly. That's why pointer to member functions are
often larger than any other pointer types (but there are other
ways of solving the problem).

What would your pointer point to ?
You cannot do this with virtual functions and you are wrong to suggest it
works correctly.
A virtual function calling mechanism requires an object.

Overload resolution occurs, in exactly the same way that it does
in the case of non-member functions.


I'm not sure what you mean by "directly" in this case, but the
above is definitely legal C++.



The class object you used in the dereferencing expression.

A class is not an object.
No object was ever declared in your code.

Once again you appear confused about classes an objects.

None of this has anything to do with the original question, but
it is standard C++, and any one claiming to know C++ should
certainly know it, even if it isn't the sort of thing you use on
a daily basis. (I've used pointers to member functions perhaps
two or three times in the twenty years I've been programming in
C++.)

If you intend using a function as a standalone function why would you define
it as a member function of an object type. This seems like bad program
design.

 

[Paul]

I've read the standards documents only enough to get the gist of what is
there. I can relate though to 'object' being used with different meanings
in different concepts. I can also hold off on deciding how terminology is
being used until the message is clear, a clarity that any isolated
statement may not provide. The calculator on my desk is an object, but I
can't derive from it or compile it along with my programs. The use of
'object' has rather well-defined and accepted meaning when used in an OO
context. For the language lawyers/committee members who drafted the
standards, way before OO was in vogue (remember, C++ is "derived" from
C), 'object' has a more traditional meaning in the larger context of
programming languages. Note how compiler developers talk about
"constructors" that have different meaning than a C++ class's
constructors. As technology changes, terms get reused and reassigned but
that doesn't always happen immediately and in the mean time, one has to
rely on the "fuzzy" meaning of the terms and extract as best as one can
from the usage of the terms in the context, and that context means what
was meant by the conveyor of the message which may not necessarily be
what the conveyor wrote, as communication is a subtle thing and note that
language is pretty paltry and then text only is even worse. Now if you
want to be opportunistically evil and exploit that paltryness, run for
state's attorney!

In the context of C++ prgramming this is how we define an object:

With:
namespace{
ObjType AnObject;
}

AnObject is considered the object here and it is considered to be of type,
object type.
The object type , being ObjType, is defined in its respective class.
It's pretty simple and there are lots of programming texts that use this
terminology



If the 'term' object is used within the standards to describe an integer
type, it is not correct to use the term object in that context when you are
talking about an object as above. To do so is nothing more than a blatant
misinteprestation of the standards.

To suggest that, the standards define an object to be simply a region of
storage therefore an objects identifier cannot be condsidered an object, is
completely unreasonable and a total misinterpreation of the standards.

 

[Paul]

On 07/01/2011 02:03, Paul wrote:

On 06/01/2011 23:50, Paul wrote:

On 06/01/2011 21:56, Ulrich Eckhardt wrote:
Paul Reid wrote:
So just because the standard doesn't add an explicit exclusion,
anything else can be part of an object? Like Your Momma, for
example?

Exactly,

I warmheartedly welcome Your Momma as a subobject.

the standard does not explicitly state that member functions
are not members of an object.

That is not how you should read this. In any case, it would require
adding
the term "..and nothing else" in hundreds of places. Look up e.g.
the
definition of natural numbers. Does it explicitly exclude the
others or
does it just specify those contained? You're obviously unused to
scientific and technical language, so this might be weird to you,
but it
is common and everybody understands it as such, once they are
used to
it.


The standard states a subobject can be zero size, this is not
coherent
with the statement that an object is a region of storage.

Right, this seems inconsistent. Read up on the exception when a
subobject
can occupy no additional storage. You need to understand the whole
image
first, then you can start arguing.


Also referneces are made to subobjects and MEMBER subobjects, so
these
are obviously 2 different concepts according to the standards.

I didn't make these references. In any case, the definition of a
subobject
was already quoted elsewhere, in short it can be a member,
baseclass or
array element. It is an object though, not a function.


These member subobjects are defined in section 9.2:

"1 The member-specification in a class definition declares the
full set
of members of the class;[...]"

Class members are not object members (member subobjects).


The standards clearly state a member function as a member of a
class so
it follows the member function is exclusively associated with that
object type, as the class is a definition of the object type.
If the definition of the object type defines a member function
then the
member function is part of the object because it was defined to
be.

No that doesn't follow and the C++ standard explicitly says so,
once you
accept the lingo, that is.


The function code is the same for all instances of that object
type so
it makes no sense, and would be very inneficient, to store a
seperate
version of the function inside each objects storage region.

So the function is not contained inside the object's storage
region.
Since
the object is defined as storage region, the function is not
contained
inside the object. You can waffle all you want, switching between
C++
standardese and colloquial use of terms, you are not documenting
inconsistencies in the C++ standard or other peoples' understanding
thereof but only your own lack of understanding.


Interestingly the C++0x draft standard states the following:

28.13/2
"Objects of type specialization of basic_regex store within
themselves
a default-constructed instance of
their traits template parameter, henceforth referred to as
traits_inst. This traits_inst object is used
to support localization of the regular expression; basic_regex
*object
member functions* shall not call any
locale dependent C or C++ API, including the formatted string input
functions. Instead they shall call the
appropriate traits member function to achieve the required effect."

It should probably say "basic_regex *member functions*" instead.
Relaxing the definition of what the term "object" means within the
draft document is a minor error but one that the troll Paul will
probably now pounce on, unfortunately.

Oh the lulz of it all; new year bollocks; I blame Holiday alcoholic
brain damage.

/Leigh

Obviously this guy doesn't have the brain capacity to understand the
difference between the terms
"object" and "object member function".


The term "object member function" does not exist in the C++ standard;
as I pointed out it did exist in the draft C++0x standard (although
one can argue it is a compound term) but this was an error which has
now been fixed by Pete. The default terminology of this newsgroup
should be the terminology defined by the C++ standard if available
otherwise you need to define your terms. In C++ member functions are
part of classes not objects.

The C++ standards do not define programming terms as they are used in
this or any other forum or newsgroup.
That fact that you seem to think so makes you appear very narrow
minded.


Also "object type" does not mean the same thing as "object"; an object
is an *instance of* an object type; an object type does not have to be
a class.

int object;

How can this be an object when your definiton of an object is an
*instance of* an object type
You don't make sense and you seem completely confused about objects.


*I* am confused??? Are you completely thick?

Yes you are confused and no I'm not thick but you obviously are, you said
:

"an object is an *instance of* an object type; an object type does not
have to be a class."

You imply that an object can be a class, yet you also state that an
object is an instance of an object type, and you also give an example of
an integer as an object.
You don't seem to know what an object is. Maybe it's whatever you want
it to be.

I did not imply that an *object* can be a class at all (an *object type*
can be a class); I said that an *object type* does not have to be a class
(I gave an example of int). You don't seem to be able to understand
simple logic represented by the English language. "OBJECT TYPE" IS NOT
THE SAME AS "OBJECT"; AN "OBJECT" IS A "REGION OF STORAGE" NOT A TYPE.

/Leigh

You cannot have an object of type class.

With:
Dog fido;

fido is not an 'integer type'
fido is not a 'double type'
fido is NOT a 'class type'
fido IS an 'object type'

You will always remain confused if you think an integer and an object is the
same thing.

Your problem is that you obviously seem to think that programming should be
discussed in the same context as the standards. As I have said to you before
this is very narrow minded.
It is also innaccurate and incorrect to quote things out of context , as you
reapeatedly do.

 

[RaZiel]

Yes you are confused and no I'm not thick but you obviously are, you said :

"an object is an *instance of* an object type; an object type does not
have to be a class."

You imply that an object can be a class, yet you also state that an
object is an instance of an object type, and you also give an example of
an integer as an object.
You don't seem to know what an object is. Maybe it's whatever you want
it to be.

Hahaha. Noone can be this slow unintentionally.

 

[Paul]

On 07/01/2011 02:43, Paul wrote:

On 07/01/2011 02:03, Paul wrote:

On 06/01/2011 23:50, Paul wrote:

On 06/01/2011 21:56, Ulrich Eckhardt wrote:
Paul Reid wrote:
So just because the standard doesn't add an explicit exclusion,
anything else can be part of an object? Like Your Momma, for
example?

Exactly,

I warmheartedly welcome Your Momma as a subobject.

the standard does not explicitly state that member functions
are not members of an object.

That is not how you should read this. In any case, it would
require
adding
the term "..and nothing else" in hundreds of places. Look up e.g.
the
definition of natural numbers. Does it explicitly exclude the
others or
does it just specify those contained? You're obviously unused to
scientific and technical language, so this might be weird to you,
but it
is common and everybody understands it as such, once they are
used to
it.


The standard states a subobject can be zero size, this is not
coherent
with the statement that an object is a region of storage.

Right, this seems inconsistent. Read up on the exception when a
subobject
can occupy no additional storage. You need to understand the
whole
image
first, then you can start arguing.


Also referneces are made to subobjects and MEMBER subobjects, so
these
are obviously 2 different concepts according to the standards.

I didn't make these references. In any case, the definition of a
subobject
was already quoted elsewhere, in short it can be a member,
baseclass or
array element. It is an object though, not a function.


These member subobjects are defined in section 9.2:

"1 The member-specification in a class definition declares the
full set
of members of the class;[...]"

Class members are not object members (member subobjects).


The standards clearly state a member function as a member of a
class so
it follows the member function is exclusively associated with
that
object type, as the class is a definition of the object type.
If the definition of the object type defines a member function
then the
member function is part of the object because it was defined
to be.

No that doesn't follow and the C++ standard explicitly says so,
once you
accept the lingo, that is.


The function code is the same for all instances of that object
type so
it makes no sense, and would be very inneficient, to store a
seperate
version of the function inside each objects storage region.

So the function is not contained inside the object's storage
region.
Since
the object is defined as storage region, the function is not
contained
inside the object. You can waffle all you want, switching between
C++
standardese and colloquial use of terms, you are not documenting
inconsistencies in the C++ standard or other peoples'
understanding
thereof but only your own lack of understanding.


Interestingly the C++0x draft standard states the following:

28.13/2
"Objects of type specialization of basic_regex store within
themselves
a default-constructed instance of
their traits template parameter, henceforth referred to as
traits_inst. This traits_inst object is used
to support localization of the regular expression; basic_regex
*object
member functions* shall not call any
locale dependent C or C++ API, including the formatted string
input
functions. Instead they shall call the
appropriate traits member function to achieve the required
effect."

It should probably say "basic_regex *member functions*" instead.
Relaxing the definition of what the term "object" means within the
draft document is a minor error but one that the troll Paul will
probably now pounce on, unfortunately.

Oh the lulz of it all; new year bollocks; I blame Holiday
alcoholic
brain damage.

/Leigh

Obviously this guy doesn't have the brain capacity to understand
the
difference between the terms
"object" and "object member function".


The term "object member function" does not exist in the C++
standard;
as I pointed out it did exist in the draft C++0x standard (although
one can argue it is a compound term) but this was an error which has
now been fixed by Pete. The default terminology of this newsgroup
should be the terminology defined by the C++ standard if available
otherwise you need to define your terms. In C++ member functions are
part of classes not objects.

The C++ standards do not define programming terms as they are used in
this or any other forum or newsgroup.
That fact that you seem to think so makes you appear very narrow
minded.


Also "object type" does not mean the same thing as "object"; an
object
is an *instance of* an object type; an object type does not have
to be
a class.

int object;

How can this be an object when your definiton of an object is an
*instance of* an object type
You don't make sense and you seem completely confused about objects.


*I* am confused??? Are you completely thick?

Yes you are confused and no I'm not thick but you obviously are, you
said :

"an object is an *instance of* an object type; an object type does not
have to be a class."

You imply that an object can be a class, yet you also state that an
object is an instance of an object type, and you also give an example
of
an integer as an object.
You don't seem to know what an object is. Maybe it's whatever you want
it to be.


I did not imply that an *object* can be a class at all (an *object
type* can be a class); I said that an *object type* does not have to
be a class (I gave an example of int). You don't seem to be able to
understand simple logic represented by the English language. "OBJECT
TYPE" IS NOT THE SAME AS "OBJECT"; AN "OBJECT" IS A "REGION OF
STORAGE" NOT A TYPE.

/Leigh

You cannot have an object of type class.

With:
Dog fido;

fido is not an 'integer type'
fido is not a 'double type'
fido is NOT a 'class type'
fido IS an 'object type'

Wrong; fido is an "object" not an "object type". The "object type" of
fido is Dog.

A dog type IS an OBJECT TYPE?

HOW CAN FIDO BE AN OBJECT BUT NOT AN OBJECT TYPE??????????

Because you are quoting stuff from the standards out of context you are the
one who is wrong not me.

The standards definition of object is 'region of storage' so it's definiton
of object type is a
'region of storage' type.

YOur definition of objects is inconsistent , sloppy and makes no snese.

From the standard:

"The term object type refers to the type with which the object
is created."

An object is defined as a region of storage.
The standards definition of an object type is a
'region of storage' type.
You can't change your definition of words whenever you decide to reinterpret
the standard.

How can you suggest fido is an object , but not an object type.

You are the one who continues to show confusion. "int" is a valid "object
type"; so an "object" can be of type "int". Technically you have to
realize that the phrase "x can be of type y" is different to the phrase "x
is a y"; this difference may be subtle but it nevertheless exists.

In the context we are speaking of objects with member functions.
An integer is NOT an object, Out of context quotes from the standards are
not rellevant here.
An Integer Object can be created from an Integer class, but you obviously
speak about built-in integer types.
So technically you are talking complete irrellevant bool.

typedef int foo_type; // foo_type *is an* int
foo_type foo; // foo *is of type* int

You might be confused because in non-technical English (not in a C++
programming context) the phrase "apple can be of type fruit" and "apple is
a fruit" are both correct


Wrong; the context of this newsgroup is C++ not object oriented
programming; it is therefore correct that the default terminology used in
this newsgroup is the same as that in the C++ standard if the standard
contains the terms in question.

It seems pretty clear that YOU do not support OOP.

C++ is a language that *supports* OOP.
Real C++ programmers also support OOP.

C++ is not an object oriented language; C++ is a multi-paradigm language
which includes support for object oriented programming.
/Leigh

The point is that C++ *supports* OOP.
This means that C++ provides the mechanisms for OOP concepts like
encapsulation and virtual member functions.
This means that to think of an object as a simple block of memory and
nothing else is incorrect as long as C++ supports OOP.

 

[James Kanze]

[...]

You cannot have an object of type class.

But you can have an object with class type. There is no type
"class", but (when discussing C++) class can be used as
a modifier of type, to specify a subset of types (those defined
by a class definition).

With:
Dog fido;

fido is not an 'integer type'
fido is not a 'double type'
fido is NOT a 'class type'
fido IS an 'object type'

With "Dog fido;", fido is not a type. Period. This is more
general than C++; this is part of the fundamental vocabulary of
computer science. If you don't understand this, then there is
no hope of your ever becoming a computer scientist.

You will always remain confused if you think an integer and an
object is the same thing.

You're the one who seems to be confusing this. "int" is a type,
not an object. (But an object can have type "int".)