What is the definition of Object in C++ ?

Discussion in 'C++' started by Reetesh Mukul, Jan 6, 2009.

  1. What is the definition of object in C++? Does the standards define it ?
    Reetesh Mukul, Jan 6, 2009
    #1
    1. Advertising

  2. Reetesh Mukul

    Guest

    On Jan 6, 10:58 am, Reetesh Mukul <> wrote:
    > What is the definition of object in C++? Does the standards define it ?


    So what is object ?
    It is an entity
    It is thing
    A chair,
    A table, a human being
    a pancake Mr Hung eats at midnight on bed
    a hambuger you enjoy everytime you have an urge to

    It's an object.
    Object can have a function
    A human knows best if it has a function
    A pancake has properties for Mr Hung to enjoy
    Such as 2 skinny layers
    one slot to enter
    full of juices

    Thart is an object
    , Jan 6, 2009
    #2
    1. Advertising

  3. On Jan 6, 1:29 pm, Christian Hackl <> wrote:
    > Reetesh Mukul ha scritto:
    >
    > > What is the definition of object in C++? Does the standards define it ?

    >
    > Your subject line makes it sound as if you were searching for a
    > Java-like "Object" base class. However, there is no such general purpose
    > base class in C++. Here's an explanation:
    >
    > http://www.research.att.com/~bs/bs_faq2.html#object
    >
    > --
    > Christian Hackl
    >


    No. That is not the case. Bjarne in his book talks about how objects
    can be created. This is similar to what Klein has explained. This
    suggests that built-in types, int, float are also objects. Though I
    had the idea(I did not knew C++ definition for Objects) that classes
    are the only objects in C++, often supported by the idea that only
    they can be inherited.
    Reetesh Mukul, Jan 6, 2009
    #3
  4. Daniel T. schrieb:
    > Jack Klein <> wrote:
    >> For some context, here is all of that paragraph:
    >>
    >> "The constructs in a C++ program create, destroy, refer to, access,
    >> and manipulate objects. An object is a region of storage. [Note: A
    >> function is not an object, regardless of whether or not it occupies
    >> storage in the way that objects do. ] An object is created by a
    >> definition (3.1), by a new-expression (5.3.4) or by the implementation
    >> (12.2) when needed. The properties of an object are determined when
    >> the object is created. An object can have a name (clause 3). An object
    >> has a storage duration (3.7) which influences its lifetime (3.8). An
    >> object has a type (3.9). The term object type refers to the type with
    >> which the object is created."

    >
    > That's funny that they except a function from the definition despite the
    > fact that it satisfies it. Makes me wonder, is a class an "object" by
    > the above definition? It satisfies the criteria and was not specifically
    > excepted like a function is.)
    >
    > Of course I might be wrong in that a class might not satisfy the
    > criteria, if it doesn't then how doesn't it?


    A class doesn't have a storage duration which influences its lifetime. A
    class doesn't have a type, but it _is_ a type.

    So a class is not an object. However, an instance of a class is an object.

    --
    Thomas
    Thomas J. Gritzan, Jan 6, 2009
    #4
  5. Reetesh Mukul

    Daniel T. Guest

    On Jan 6, 8:08 am, "Thomas J. Gritzan" <> wrote:
    > Daniel T. schrieb:


    > > That's funny that they except a function from the definition
    > > despite the fact that it satisfies it. Makes me wonder, is a class
    > > an "object" by the above definition? It satisfies the criteria and
    > > was not specifically excepted like a function is.)
    > >
    > > Of course I might be wrong in that a class might not satisfy the
    > > criteria, if it doesn't then how doesn't it?

    >
    > A class doesn't have a storage duration which influences its
    > lifetime. A class doesn't have a type, but it _is_ a type.
    >
    > So a class is not an object. However, an instance of a class is an
    > object.


    Good point, I wonder why they excepted function definitions as
    objects?
    Daniel T., Jan 6, 2009
    #5
  6. Reetesh Mukul

    Fred Zwarts Guest

    "Thomas J. Gritzan" <> wrote in message news:gjvl57$aft$...
    > Daniel T. schrieb:
    >> Jack Klein <> wrote:
    >>> For some context, here is all of that paragraph:
    >>>
    >>> "The constructs in a C++ program create, destroy, refer to, access,
    >>> and manipulate objects. An object is a region of storage. [Note: A
    >>> function is not an object, regardless of whether or not it occupies
    >>> storage in the way that objects do. ] An object is created by a
    >>> definition (3.1), by a new-expression (5.3.4) or by the implementation
    >>> (12.2) when needed. The properties of an object are determined when
    >>> the object is created. An object can have a name (clause 3). An object
    >>> has a storage duration (3.7) which influences its lifetime (3.8). An
    >>> object has a type (3.9). The term object type refers to the type with
    >>> which the object is created."

    >>
    >> That's funny that they except a function from the definition despite the
    >> fact that it satisfies it. Makes me wonder, is a class an "object" by
    >> the above definition? It satisfies the criteria and was not specifically
    >> excepted like a function is.)
    >>
    >> Of course I might be wrong in that a class might not satisfy the
    >> criteria, if it doesn't then how doesn't it?

    >
    > A class doesn't have a storage duration which influences its lifetime. A
    > class doesn't have a type, but it _is_ a type.
    >
    > So a class is not an object. However, an instance of a class is an object.


    Does an instance of a class always have a storage?
    Can a class have a size of 0?
    Fred Zwarts, Jan 6, 2009
    #6
  7. Daniel T. wrote:

    > Good point, I wonder why they excepted function definitions as
    > objects?


    C++ functions are not first class entities; for example, you can't
    construct new ones at runtime (portably, at least).
    Matthias Buelow, Jan 6, 2009
    #7
  8. On Jan 6, 8:07 pm, "Fred Zwarts" <> wrote:
    > "Thomas J. Gritzan" <> wrote in messagenews:gjvl57$aft$...
    >
    >
    >
    > > Daniel T. schrieb:
    > >> Jack Klein <> wrote:
    > >>> For some context, here is all of that paragraph:

    >
    > >>> "The constructs in a C++ program create, destroy, refer to, access,
    > >>> and manipulate objects. An object is a region of storage. [Note: A
    > >>> function is not an object, regardless of whether or not it occupies
    > >>> storage in the way that objects do. ] An object is created by a
    > >>> definition (3.1), by a new-expression (5.3.4) or by the implementation
    > >>> (12.2) when needed. The properties of an object are determined when
    > >>> the object is created. An object can have a name (clause 3). An object
    > >>> has a storage duration (3.7) which influences its lifetime (3.8). An
    > >>> object has a type (3.9). The term object type refers to the type with
    > >>> which the object is created."

    >
    > >> That's funny that they except a function from the definition despite the
    > >> fact that it satisfies it. Makes me wonder, is a class an "object" by
    > >> the above definition? It satisfies the criteria and was not specifically
    > >> excepted like a function is.)

    >
    > >> Of course I might be wrong in that a class might not satisfy the
    > >> criteria, if it doesn't then how doesn't it?

    >
    > > A class doesn't have a storage duration which influences its lifetime. A
    > > class doesn't have a type, but it _is_ a type.

    >
    > > So a class is not an object. However, an instance of a class is an object.

    >
    > Does an instance of a class always have a storage?
    > Can a class have a size of 0?


    Since the discussion has entered an area which I am very much
    interested in ... Let us talk Mathematics a bit.

    In Mathematics, it is assumed that everything can be constructed out
    of Sets( Although this also is controversial). Thus Numbers are
    Sets ... Magma, Groups, Monoids all are Sets. A hierarchy of Sets can
    be created right from the beginning by tacitly using Null Sets.

    Lets assume that we have the notion of objects with null storage also,
    {}.

    Now what can be the Mathematical definition of an "object" and "object
    type". Is an object a "tuple" or it is just a "set" ?

    I have thought of a scheme. A very rough, crude and minimal
    illustration is here:-

    A type say, int, means the set of integers, {{},{{}},{{},{{}}},....}

    While when we write int q; q will mean an element of above set.

    A class A{ int a; char b; int c;};

    will mean the set {{a1,b1,c1},{a2,b2,c2},...} I am assuming it to be
    set of sets only in place of tuples, by easing up the order
    preference. A more rigorous approach can be done by giving storage to
    be a defining parameter. So "int a" can mean in that case
    {@Storage_,@Value_a}

    Similarly a template class, will mean set of all types. So, if

    template<typename T>class Q{ BOOST_STATIC_ASSERT
    (is_applicable<T>::value) };

    will mean Q is a set of types, {int,float,char,X_,Y_,...}

    Multiple inheritance is then union of sets.

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

    I know what I have written above may have been illustrated in better
    way at some other place, but take me as a novice.

    One more point, the more I think on "Objects" in C++ or otherwise, it
    looks an abstract idea. It looks like something on which "Action" can
    be done. But we can act on Functions also. And if we think we cannot
    act on functions then at the same time we cannot act on const data
    also. If things boil down on storage, and if functions are just
    _start_ and _end_ addresses ( ofcourse practically start address only)
    then so for classes. They can also thought as _begin_ and _end_
    address of some memory.

    With Regards,
    Reetesh Mukul
    Reetesh Mukul, Jan 6, 2009
    #8
  9. Reetesh Mukul

    Bo Persson Guest

    Fred Zwarts wrote:
    > "Thomas J. Gritzan" <> wrote in message
    >>
    >> A class doesn't have a storage duration which influences its
    >> lifetime. A class doesn't have a type, but it _is_ a type.
    >>
    >> So a class is not an object. However, an instance of a class is an
    >> object.

    >
    > Does an instance of a class always have a storage?


    Yes. It must have an address, which must be unique for objects of its
    type. That's how we can tell that two instances are separate objects.

    > Can a class have a size of 0?


    No. The smallest possible object is a char, which has size 1 by
    definition.


    Bo Persson
    Bo Persson, Jan 6, 2009
    #9
  10. Reetesh Mukul

    Bo Persson Guest

    Jeff Schwab wrote:
    > Bo Persson wrote:
    >> Fred Zwarts wrote:
    >>> "Thomas J. Gritzan" <> wrote in message
    >>>> A class doesn't have a storage duration which influences its
    >>>> lifetime. A class doesn't have a type, but it _is_ a type.
    >>>>
    >>>> So a class is not an object. However, an instance of a class is
    >>>> an object.
    >>> Does an instance of a class always have a storage?

    >>
    >> Yes. It must have an address, which must be unique for objects of
    >> its type. That's how we can tell that two instances are separate
    >> objects.
    >>> Can a class have a size of 0?

    >>
    >> No. The smallest possible object is a char, which has size 1 by
    >> definition.

    >
    > Those are mostly true, except that an object can have the same
    > address as one or more sub-objects. In particular, a C++ object
    > can take up zero space if it is an empty base of some other object.


    Yes, but I didn't want to go into that. That's why I said "must be
    unique for objects of its type". :)

    Obviously an object of a struct type will have the same address as its
    first member, but they will be of different types (and have non-zero
    sizes!).


    Bo Persson
    Bo Persson, Jan 6, 2009
    #10
  11. Reetesh Mukul

    Daniel T. Guest

    On Jan 6, 11:23 am, Matthias Buelow <> wrote:
    > Daniel T. wrote:
    > > Good point, I wonder why they excepted function definitions as
    > > objects?

    >
    > C++ functions are not first class entities; for example, you can't
    > construct new ones at runtime (portably, at least).


    But the definition of "object" doesn't require that it be
    constructable at runtime...

    "An object is created by a definition (3.1), by a new-expression
    (5.3.4) or by the implementation (12.2) when needed."

    A function is created by a definition, so it conforms to the above
    sentence as written.
    Daniel T., Jan 6, 2009
    #11
  12. Reetesh Mukul

    Grizlyk Guest

    On Jan 7, 1:18 am, "Daniel T." wrote:
    > A function is created by a definition, so it conforms to the above
    > sentence as written.


    What do you want to get with a function treated as an object?
    Grizlyk, Jan 7, 2009
    #12
  13. Reetesh Mukul

    Daniel T. Guest

    On Jan 6, 8:38 pm, Grizlyk <> wrote:
    > On Jan 7, 1:18 am, "Daniel T." wrote:
    >
    > > A function is created by a definition, so it conforms to the above
    > > sentence as written.

    >
    > What do you want to get with a function treated as an object?


    What can an object do or have done to it that a pointer can't?
    Daniel T., Jan 7, 2009
    #13
  14. Reetesh Mukul

    Daniel T. Guest

    On Jan 6, 5:37 pm, Jeff Schwab <> wrote:
    > Daniel T. wrote:
    > > On Jan 6, 8:08 am, "Thomas J. Gritzan" <> wrote:
    > >> Daniel T. schrieb:

    >
    > >>> That's funny that they except a function from the definition
    > >>> despite the fact that it satisfies it. Makes me wonder, is a class
    > >>> an "object" by the above definition? It satisfies the criteria and
    > >>> was not specifically excepted like a function is.)

    >
    > >>> Of course I might be wrong in that a class might not satisfy the
    > >>> criteria, if it doesn't then how doesn't it?
    > >> A class doesn't have a storage duration which influences its
    > >> lifetime. A class doesn't have a type, but it _is_ a type.

    >
    > >> So a class is not an object. However, an instance of a class is an
    > >> object.

    >
    > > Good point, I wonder why they excepted function definitions as
    > > objects?

    >
    > Unlike a static type, a function does "occupy a region of storage."
    > Given that a functions are not objects, I can see why they are
    > specifically excepted.  The obvious question then is why functions
    > aren't objects.
    >
    > One thing that springs to mind is that their addresses don't support
    > pointer arithmetic, nor casting to data pointer types; in particular, &a
    > + 1 is a valid expression for any object a, but not if a is a function.


    AFAIK, the above is not true:

    int main() {
    int a;
    int* p = &a + 1; // undefined behavior
    }

    Pointer arithmetic is not universally supported by all objects, not
    even by all pointers to objects.

    > Similarly, function pointers are not castable to or from void*, dlsym
    > notwithstanding.


    Why not? What is fundamentally different with a function pointer that
    it can't be cast to a void pointer?
    Daniel T., Jan 7, 2009
    #14
  15. Daniel T. schrieb:
    > On Jan 6, 8:38 pm, Grizlyk <> wrote:
    >> On Jan 7, 1:18 am, "Daniel T." wrote:
    >>
    >>> A function is created by a definition, so it conforms to the above
    >>> sentence as written.

    >> What do you want to get with a function treated as an object?

    >
    > What can an object do or have done to it that a pointer can't?


    A pointer is an object.
    I assume you meant "...that a function can't?"

    An object has a value and a type. You can read and modify the value, and
    the type determines what values are valid.
    You can reinterpret any object as array of unsigned char and read that.

    What value does a function have (no pun intended)? You can't read it,
    and you can't modify it.
    Technically, on some platform there might not be a memory representation
    of a function, or the memory pages might be marked as executable, but
    not as readable.

    --
    Thomas
    Thomas J. Gritzan, Jan 7, 2009
    #15
  16. Reetesh Mukul

    James Kanze Guest

    On Jan 6, 11:37 pm, Jeff Schwab <> wrote:
    > Daniel T. wrote:
    > > On Jan 6, 8:08 am, "Thomas J. Gritzan" <> wrote:
    > >> Daniel T. schrieb:


    > >>> That's funny that they except a function from the
    > >>> definition despite the fact that it satisfies it. Makes me
    > >>> wonder, is a class an "object" by the above definition? It
    > >>> satisfies the criteria and was not specifically excepted
    > >>> like a function is.)


    > >>> Of course I might be wrong in that a class might not
    > >>> satisfy the criteria, if it doesn't then how doesn't it?
    > >> A class doesn't have a storage duration which influences
    > >> its lifetime. A class doesn't have a type, but it _is_ a
    > >> type.


    > >> So a class is not an object. However, an instance of a
    > >> class is an object.


    > > Good point, I wonder why they excepted function definitions
    > > as objects?


    > Unlike a static type, a function does "occupy a region of
    > storage." Given that a functions are not objects, I can see
    > why they are specifically excepted. The obvious question then
    > is why functions aren't objects.


    > One thing that springs to mind is that their addresses don't
    > support pointer arithmetic, nor casting to data pointer types;
    > in particular, &a + 1 is a valid expression for any object a,
    > but not if a is a function.
    > Similarly, function pointers are not castable to or from
    > void*, dlsym notwithstanding.


    Functions are in a funny situation; they have an address, but
    they are not required to occupy memory. They do not (in the C++
    model) occupy a region of storage; in particular, they do not
    have a size, nor storage duration. They are just "there". (Of
    course, in just about any implementation, they will occupy a
    finite number of bytes in memory. But this is just an
    implementation detail.)

    I think that part of the reasoning behind this may be to allow
    implementations on a Harvard architecture; the functions may be
    in something that you would consider memory from a hardware
    standpoint, but it isn't accessible as memory in any way from
    the program.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jan 7, 2009
    #16
  17. Reetesh Mukul

    James Kanze Guest

    On Jan 7, 3:04 am, "Daniel T." <> wrote:
    > On Jan 6, 5:37 pm, Jeff Schwab <> wrote:
    > > Daniel T. wrote:
    > > > On Jan 6, 8:08 am, "Thomas J. Gritzan" <> wrote:
    > > >> Daniel T. schrieb:


    > > >>> That's funny that they except a function from the definition
    > > >>> despite the fact that it satisfies it. Makes me wonder, is a class
    > > >>> an "object" by the above definition? It satisfies the criteria and
    > > >>> was not specifically excepted like a function is.)


    > > >>> Of course I might be wrong in that a class might not satisfy the
    > > >>> criteria, if it doesn't then how doesn't it?
    > > >> A class doesn't have a storage duration which influences its
    > > >> lifetime. A class doesn't have a type, but it _is_ a type.


    > > >> So a class is not an object. However, an instance of a class is an
    > > >> object.


    > > > Good point, I wonder why they excepted function definitions as
    > > > objects?


    > > Unlike a static type, a function does "occupy a region of storage."
    > > Given that a functions are not objects, I can see why they are
    > > specifically excepted. The obvious question then is why functions
    > > aren't objects.


    > > One thing that springs to mind is that their addresses don't
    > > support pointer arithmetic, nor casting to data pointer
    > > types; in particular, &a + 1 is a valid expression for any
    > > object a, but not if a is a function.


    > AFAIK, the above is not true:


    > int main() {
    > int a;
    > int* p = &a + 1; // undefined behavior
    > }


    No, although dereferencing the pointer would be. And of course,
    &a+0 is not only legal, but allows dereferencing.

    > Pointer arithmetic is not universally supported by all
    > objects, not even by all pointers to objects.


    Pointer arithmetic, per se, is defined for all pointers to
    objects. That doesn't mean, of course, that you can just add
    any arbitrary value and get meaningful results. But the
    semantics are defined, and that definition is related to the
    fact that sizeof(T) is defined for all object types (but not for
    functions).

    > > Similarly, function pointers are not castable to or from
    > > void*, dlsym notwithstanding.


    > Why not?


    Because it can't be made to work on all systems. I've worked on
    systems where pointers to functions were 32 bits, but pointers
    to objects only 16 bits, for example. I've also worked on
    systems (but not in C++) where the same bit pattern, when used
    as a pointer to a function, addressed different memory that it
    would when used as a pointer to an object (Harvard
    architectures).

    > What is fundamentally different with a function pointer that
    > it can't be cast to a void pointer?


    What is fundamentally the same between pointers to functions and
    pointers to data?

    The standard does require that you can convert any data pointer
    to a void*, then to a char*, and access the underlying data.
    This imposes some additional overhead on some systems, but has
    enough important practical uses that it is deemed "necessary".
    What would making this requirement apply to function pointers as
    well bring? Except additional overhead on some systems. (The
    system with 16 bit data pointers but 32 bit function pointers
    was one of the most widespread systems around at one time.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jan 7, 2009
    #17
  18. Reetesh Mukul

    James Kanze Guest

    On Jan 7, 4:54 am, Jack Klein <> wrote:

    [...]
    > One basic underlying characteristic of C++ is that a pointer
    > to any object type can be converted to a pointer to void and
    > then, with a suitable cast, be converted back to a pointer to
    > the original object type. The resulting pointer must point to
    > the original object, assuming it is still within its lifetime.
    > There are architectures where such equivalence is not
    > possible.


    Just a nit, but that's sort of begging the question. If the
    standard required this of function pointers, implementations
    would do it. It might impose that void* be bigger than any
    other pointer, but that's all. Actually, the standard requires
    char* and void* to have the same size and representation, so it
    would also impose that char* be bigger than necessary. (And of
    course, there are, or at least have been, real machines where
    char* is bigger than int*.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jan 7, 2009
    #18
  19. On Jan 7, 3:05 pm, James Kanze <> wrote:
    > On Jan 7, 4:54 am, Jack Klein <> wrote:
    >
    >     [...]
    >
    > > One basic underlying characteristic of C++ is that a pointer
    > > to any object type can be converted to a pointer to void and
    > > then, with a suitable cast, be converted back to a pointer to
    > > the original object type.  The resulting pointer must point to
    > > the original object, assuming it is still within its lifetime.
    > > There are architectures where such equivalence is not
    > > possible.

    >
    > Just a nit, but that's sort of begging the question.  If the
    > standard required this of function pointers, implementations
    > would do it.  It might impose that void* be bigger than any
    > other pointer, but that's all.  Actually, the standard requires
    > char* and void* to have the same size and representation, so it
    > would also impose that char* be bigger than necessary.  (And of
    > course, there are, or at least have been, real machines where
    > char* is bigger than int*.)
    >
    > --
    > James Kanze (GABI Software)             email:
    > Conseils en informatique orientée objet/
    >                    Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


    So, can we say,

    1] Any abstraction is *not* an object. So, class definition, function
    - which basically mean what behavior a layout of memory has, are not
    objects.

    2] Any data on which the abstraction is imposed is an Object.

    With Regards,
    Reetesh Mukul
    Reetesh Mukul, Jan 7, 2009
    #19
  20. Reetesh Mukul

    P. Lepin Guest

    Jeff Schwab wrote:
    > Daniel T. wrote:
    >> What is fundamentally different with a function pointer that
    >> it can't be cast to a void pointer?

    >
    > Code and data may be stored in different types of memory, depending on
    > the processor architecture.


    That's so unvonneumannly.

    --
    Waterfall: One Process To Rule Them All
    P. Lepin, Jan 7, 2009
    #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. Jianli Shen
    Replies:
    1
    Views:
    567
    Victor Bazarov
    Mar 13, 2005
  2. Ark
    Replies:
    1
    Views:
    405
    Chris Torek
    Aug 7, 2004
  3. Jon Slaughter
    Replies:
    4
    Views:
    433
    Jon Slaughter
    Oct 26, 2005
  4. Pierre Yves
    Replies:
    2
    Views:
    473
    Pierre Yves
    Jan 10, 2008
  5. Steve Litt
    Replies:
    2
    Views:
    177
    Dejan Dimic
    Sep 29, 2008
Loading...

Share This Page