Frasncis Glassboro wrote.

[Paul]

<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 state that what Francis Glassboro is implying here is nothing more than
complete nonsense for the reasons I give below.

An object type is defined by its class and can be defined to contain member
functions.
A member function is specifically connected to the object on which it was
called.

The C++ standards state that an object is a region of memory but they do not
state that it is JUST a region of memory. The C++ standards then go on to
state that objects can contain member subobjects, these are defined within
the class. The fact that the standard goes on to describe or define objects
in greater detail is evidence that the C++ obviously do not imply an object
is JUST a region of storage.

I repeat....An object is definied in the standard as a region, not JUST a
region, of memory.
If you choose to interpret an object as JUST a region of memory, as you
clearly have then It's a blatent misinterpretation from the standards.
lets just add words in to change the meaning of the standards when it suits
us shall we?s


If the object type is defined to contain a member function then all
instances of that object has the said member function. The calling
mechanisms or where that function is stored in a programs memory is
irrellevant.
It is technically wrong to suggest that an member function is not part of an
object. You attempt to prove this by trying to prove that a member function
does not live within an objects memory.


The fact that a member functions is defined in the objects class definition
is suffice to support my generally accepted view.
Also note that, altohugh you refuse to acknowledge anything other than the
C++ standards here, there is a massive amount of OOP documents and reference
that supportmy terminology.

 

[Alf P. Steinbach /Usenet]

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


Cheers & hth.,

- Alf

 

[Alf P. Steinbach /Usenet]

* Alf P. Steinbach /Usenet, on 06.01.2011 17:01:

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

Just adding to that, Paul, I don't see your articles in
[alt.comp.lang.learn.c-c++], but I see lots of replies to them, so apparently I
have already plinked you in that newsgroup -- or plonked you, whatever.


Cheers & hth.,

- Alf

 

[Paul]

* Alf P. Steinbach /Usenet, on 06.01.2011 17:01:

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

Just adding to that, Paul, I don't see your articles in
[alt.comp.lang.learn.c-c++], but I see lots of replies to them, so
apparently I have already plinked you in that newsgroup -- or plonked
you, whatever.


Cheers & hth.,

- Alf

--

Goodbye Alf have a nice life.

 

[Paul]

* Paul, on 06.01.2011 16:25:

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

Why not that if that is the subject of the thread?

 

[Bo Persson]

An object type is defined by its class and can be defined to
contain member functions.
A member function is specifically connected to the object on which
it was called.

The C++ standards state that an object is a region of memory but
they do not state that it is JUST a region of memory. The C++
standards then go on to state that objects can contain member
subobjects, these are defined within the class. The fact that the
standard goes on to describe or define objects in greater detail is
evidence that the C++ obviously do not imply an object is JUST a
region of storage.

The standard actually says exactly that:

"An *object* is a region of storage." (§1.8)

The fact that the word "object" is in italics means that this is the
definition of the term "object".

The standard then goes on to say "Note: A function is not an object,
regardless of whether or not it occupies storage in the way that
objects do."


Had the committee decided that member functions should be objects,
even though other functions are not, they would certainly have stated
that. And if they are not objects, they cannot be sub-objects of other
objects, because a sub-object is also required to be an object:

"Objects can contain other objects, called *subobjects*."

Here again, the word "subobject" in italics means that this is the
definition of the term.


Bo Persson

 

[Paul]

Why not that if that is the subject of the thread?

If he states Im not worthy of a reply then I have no choice but to talk
about him.

It is also very insulting to say someone is not worthy, and this is the type
of insults and arrogance I have had to deal with since this argument was
created by Francesco and Francis.

 

[Paul]

You obviously have a serious mental condition; I suggest you see a doctor
and get prescribed some medication; either that or you are still an angry
hormonal teenager which would also explain a lot.

/Leigh

thankyou for your insults.

 

[Ulrich Eckhardt]

Why not that if that is the subject of the thread?

Well, at least you should not document your professionalism by spelling it
wrongly. I consider it a mixture of you showing a lack of respect or
skills. Didn't you yourself try to diss someone on the base of them making
a spelling mistake?

 

[Paul]

The standard actually says exactly that:

"An *object* is a region of storage." (§1.8)

The fact that the word "object" is in italics means that this is the
definition of the term "object".

The standard then goes on to say "Note: A function is not an object,
regardless of whether or not it occupies storage in the way that objects
do."


Had the committee decided that member functions should be objects, even
though other functions are not, they would certainly have stated that.

wHY ARE YOU EVEN CONSIDERING THE FACT THAT A FUNCTION MIGHT BE AN OBJECT ,
THIS IS CRAZY.
A function is not an object, caps not inteded but not rewriting it .

And if they are not objects, they cannot be sub-objects of other objects,
because a sub-object is also required to be an object:

Since when was a subobject required to be an object? You state that its
REQUIRED as if the standards state this.

Objects can contain other objects, called *subobjects*."

Here again, the word "subobject" in italics means that this is the
definition of the term.


Bo Persson


tHE STANDARD SEEMS to define a member subobject in section 9.2, ref section
1. para 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."

If you goto section 9.2 :

"9.2 Class members [class.mem]
member-specification:
member-declaration member-specificationopt
access-specifier : member-specificationopt
member-declaration:
attribute-specifieropt decl-specifier-seqopt
member-declarator-listopt ;
function-definition ;opt
:pt nested-name-specifier templateopt unqualified-id ;
using-declaration
static_assert-declaration
template-declaration
alias-declaration
member-declarator-list:
member-declarator
member-declarator-list , member-declarator
member-declarator:
declarator pure-specifieropt
declarator brace-or-equal-initializeropt
identifieropt attribute-specifieropt : constant-expression
pure-specifier:
= 0
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."


This is how the standard defines the term member subobject.

 

[Ulrich Eckhardt]

wHY ARE YOU EVEN CONSIDERING THE FACT THAT A FUNCTION MIGHT BE AN OBJECT
, THIS IS CRAZY.
A function is not an object,

A function sure can be an object, just like a class can. Neither can in
C++ though, just as a function is not part of an object there.

Since when was a subobject required to be an object?

Because it is an object? You even quoted ...

"Objects can contain other objects, called subobjects."

....but fail to understand that?

You state that its REQUIRED as if the standards state this.

So just because the standard doesn't add an explicit exclusion, anything
else can be part of an object? Like Your Momma, for example?

 

[Paul]

A function sure can be an object, just like a class can. Neither can in
C++ though, just as a function is not part of an object there.


Because it is an object? You even quoted ...

"Objects can contain other objects, called subobjects."

...but fail to understand that?



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, the standard does not explicitly state that member functions are
not members of an object.

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

Also referneces are made to subobjects and MEMBER subobjects, so these are
obviously 2 different concepts according to the standards. 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; no member
can be added elsewhere. Members of a class are data members, member
functions (9.3), nested types,
and enumerators."

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

The compiler knows what functions are defined for each object type, So if
you try to call a function that is not defined it wont work. Only functions
that belong to the object, or are defined in that objects class file, can be
explicitly called on said object.

 

[Paul]

You are a troll and ICMFP.

thanks for the insult

 

[Ulrich Eckhardt]

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.

 

[Juha Nieminen]

A member function is specifically connected to the object on which it was
called.

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 then call that function using that pointer, giving it an object
of that class type as parameter (well, effectively at least; the syntax
is obviously a bit different from a regular function call).

That would indicate that the member function is not, in fact,
inherently tied to any object in particular, but a free function
which is tied to the *class* in particular. Technically speaking
the only difference between a member function and a class function
(ie. one declared as 'static') is that the former takes an object
as parameter (through a special syntax) while the latter doesn't.

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

 

[Paul]

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

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.

You can then call that function using that pointer, giving it an object
of that class type as parameter (well, effectively at least; the syntax
is obviously a bit different from a regular function call).

And what exactly would 'this' point to?

That would indicate that the member function is not, in fact,
inherently tied to any object in particular, but a free function
which is tied to the *class* in particular. Technically speaking
the only difference between a member function and a class function
(ie. one declared as 'static') is that the former takes an object
as parameter (through a special syntax) while the latter doesn't.

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.

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

You talk about a function not associated with an object , but I was
obviously talking about a member function that is associated with an object.
I don't see where any confusion comes from.

 

[Johannes Schaub (litb)]

<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 state that what Francis Glassboro is implying here is nothing more than
complete nonsense for the reasons I give below.

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 type is defined by its class and can be defined to contain
member functions.
A member function is specifically connected to the object on which it was
called.

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

 

[Paul]

I warmheartedly welcome Your Momma as a subobject.

My momma is dead. How is your momma doing?

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.

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.

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.



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.

The standards makes these referneces not you.
Why dont you quote the definition of a subobject instead of giving your
re-definiton.

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?
The quote from the standards that you seem to have snipped , is the
standards definition of member subobject.
If you disagree then you disagree with the standards.

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

The standards states what it states, I will requote Section 9.2 as you seem
to have snipped it, if you disagree with the standards that your problem,.

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

This is what the standard states

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.

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.
If you cannot understand this concept its a reflection of your intellectual
capabilites, not mine.

 

[Paul]

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

 

[Ian Collins]

The standards states what it states,

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