Frasncis Glassboro wrote.

Discussion in 'C++' started by Paul, Jan 6, 2011.

  1. Paul

    Paul Guest

    <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.
    Paul, Jan 6, 2011
    #1
    1. Advertising

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

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Jan 6, 2011
    #2
    1. Advertising

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

    --
    blog at <url: http://alfps.wordpress.com>
    Alf P. Steinbach /Usenet, Jan 6, 2011
    #3
  4. Paul

    Paul Guest

    "Alf P. Steinbach /Usenet" <> wrote in
    message news:ig4pce$9lc$-september.org...
    >* 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, Jan 6, 2011
    #4
  5. Paul

    Paul Guest

    "Alf P. Steinbach /Usenet" <> wrote in
    message news:ig4p18$6fr$-september.org...
    >* 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?
    Paul, Jan 6, 2011
    #5
  6. Paul

    Bo Persson Guest

    Paul wrote:
    >
    > 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
    Bo Persson, Jan 6, 2011
    #6
  7. Paul

    Paul Guest

    "Paul" <> wrote in message
    news:QRlVo.8354$2...
    >
    > "Alf P. Steinbach /Usenet" <> wrote in
    > message news:ig4p18$6fr$-september.org...
    >>* 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?
    >


    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, Jan 6, 2011
    #7
  8. Paul

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 06/01/2011 16:12, Paul wrote:
    >>
    >> "Alf P. Steinbach /Usenet" <> wrote in
    >> message news:ig4p18$6fr$-september.org...
    >>> * 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?
    >>
    >>

    >
    > 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.
    Paul, Jan 6, 2011
    #8
  9. Paul wrote:
    > "Alf P. Steinbach /Usenet" <> wrote in
    > message news:ig4p18$6fr$-september.org...
    >>* 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?


    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?
    Ulrich Eckhardt, Jan 6, 2011
    #9
  10. Paul

    Paul Guest

    "Bo Persson" <> wrote in message
    news:...
    > Paul wrote:
    >>
    >> 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.

    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
    ::eek: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.
    Paul, Jan 6, 2011
    #10
  11. Paul Reid's object model (was: Re: Frasncis Glassboro wrote.)

    "Paul Reid" <> 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?
    Ulrich Eckhardt, Jan 6, 2011
    #11
  12. Paul

    Paul Guest

    Re: Paul Reid's object model (was: Re: Frasncis Glassboro wrote.)

    "Ulrich Eckhardt" <> wrote in message
    news:-berlin.de...
    > "Paul Reid" <> 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.
    Paul, Jan 6, 2011
    #12
  13. Paul

    Paul Guest

    "Andy Champ" <> wrote in message
    news:...
    > You are a troll and ICMFP.
    >

    thanks for the insult
    Paul, Jan 6, 2011
    #13
  14. Re: Paul Reid's object model

    Paul Reid wrote:
    > "Ulrich Eckhardt" <> 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.
    Ulrich Eckhardt, Jan 6, 2011
    #14
  15. In comp.lang.c++ Paul <> 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).
    Juha Nieminen, Jan 6, 2011
    #15
  16. Paul

    Paul Guest

    "Juha Nieminen" <> wrote in message
    news:4d263f48$0$32136$...
    > In comp.lang.c++ Paul <> 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.
    Paul, Jan 6, 2011
    #16
  17. 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()".
    Johannes Schaub (litb), Jan 6, 2011
    #17
  18. Paul

    Paul Guest

    Re: Paul Reid's object model

    "Ulrich Eckhardt" <> wrote in message
    news:-berlin.de...
    > Paul Reid wrote:
    >> "Ulrich Eckhardt" <> 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.
    Paul, Jan 6, 2011
    #18
  19. Paul

    Paul Guest

    Re: Paul Reid's object model

    "Leigh Johnston" <> wrote in message
    news:...
    > On 06/01/2011 21:56, Ulrich Eckhardt wrote:
    >> Paul Reid wrote:
    >>> "Ulrich Eckhardt"<> 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 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".
    Paul, Jan 6, 2011
    #19
  20. Paul

    Ian Collins Guest

    Re: Paul Reid's object model

    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
    Ian Collins, Jan 6, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Saul

    ASP.NET Game I wrote...

    Saul, May 1, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    428
  2. Hans-Marc Olsen

    I wrote my own Java in BASIC ! ! !

    Hans-Marc Olsen, Nov 18, 2004, in forum: Java
    Replies:
    11
    Views:
    499
    Sudsy
    Nov 27, 2004
  3. Nolan Martin
    Replies:
    1
    Views:
    316
    Christopher Benson-Manica
    Jul 26, 2004
  4. Fran Duffy
    Replies:
    0
    Views:
    286
    Fran Duffy
    Jun 23, 2007
  5. c
    Replies:
    43
    Views:
    1,517
    Richard
    Dec 15, 2007
Loading...

Share This Page