Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Frasncis Glassboro wrote.

Reply
Thread Tools

Frasncis Glassboro wrote.

 
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-06-2011
"Paul Reid" <(E-Mail Removed)> wrote:
> 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.

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


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?

 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-06-2011

"Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-berlin.de...
> "Paul Reid" <(E-Mail Removed)> wrote:
>> 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.
>
>>>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?

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

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.

 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-06-2011

"Andy Champ" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> You are a troll and ICMFP.
>

thanks for the insult

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-06-2011
Paul Reid wrote:
> "Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
>> 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.

 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      01-06-2011
In comp.lang.c++ Paul <(E-Mail Removed)> wrote:
> 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).
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-06-2011

"Juha Nieminen" <(E-Mail Removed)> wrote in message
news:4d263f48$0$32136$(E-Mail Removed)...
> In comp.lang.c++ Paul <(E-Mail Removed)> wrote:
>> 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++.)
>

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.

 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      01-06-2011
Paul wrote:

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

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-06-2011

"Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-berlin.de...
> Paul Reid wrote:
>> "Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
>>> 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.

My momma is dead. How is your momma doing?


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

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.

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

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.

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

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

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.

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-06-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 06/01/2011 21:56, Ulrich Eckhardt wrote:
>> Paul Reid wrote:
>>> "Ulrich Eckhardt"<(E-Mail Removed)> wrote in message
>>>> 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 *******s; 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".


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-06-2011
On 01/ 7/11 12:43 PM, Paul wrote:

> The standards states what it states,


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

--
Ian Collins
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
looking for scott from Glassboro State Fran Duffy Python 0 06-23-2007 10:12 AM



Advertisments