What is the definition of Object in C++ ?

[Reetesh Mukul]

What is the definition of object in C++? Does the standards define it ?

 

[imuaplease]

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

 

[Reetesh Mukul]

Reetesh Mukul ha scritto:


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

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.

 

[Thomas J. Gritzan]

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.

 

[Daniel T.]

Daniel T. schrieb:

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?

 

[Fred Zwarts]

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?

 

[Matthias Buelow]

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

 

[Reetesh Mukul]

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

 

[Bo Persson]

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]

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

 

[Daniel T.]

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.

 

[Grizlyk]

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?

 

[Daniel T.]

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

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?

 

[Thomas J. Gritzan]

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.

 

[James Kanze]

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]

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

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]

[...]

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

 

[Reetesh Mukul]

    [...]

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:[email protected]
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

 

[P. Lepin]

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

That's so unvonneumannly.