R
Reetesh Mukul
What is the definition of object in C++? Does the standards define it ?
What is the definition of object in C++? Does the standards define it ?
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
Daniel said:Jack Klein said: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?
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.
Thomas J. Gritzan said:Daniel said:Jack Klein said: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 said:Good point, I wonder why they excepted function definitions as
objects?
Daniel said: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 said:Does an instance of a class always have a storage?
Can a class have a size of 0?
Jeff said: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.
C++ functions are not first class entities; for example, you can't
construct new ones at runtime (portably, at least).
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?
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.
Daniel said:What can an object do or have done to it that a pointer can'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.
Similarly, function pointers are not castable to or from
void*, dlsym notwithstanding.
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.
Why not?
What is fundamentally different with a function pointer that
it can't be cast to a void pointer?
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.
[...]
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
Jeff said:Code and data may be stored in different types of memory, depending on
the processor architecture.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.