[Mrk]

Are integers objects? I know instances of a class are objects, but what about everything else? And if integers are objects, are they ever really referred to as objects, or does "objects" generally refer to a class object? A function wouldn't be an object, right? Does an object have to be something that can hold data?

[r.stiltskin]

According to the ISO standard "an object is a region of storage", and fundamental types (int, char, ...) are referred to as objects.

The standard explicitly states that functions are not objects. However, there are comparison objects associated with STL containers which are defined as classes but contain nothing but a constructor and a function call operator that returns a bool to indicate how to order two objects in the container. So the comparison object seems to be an exception to the general rule.

[Oler1s]

To clarify, the types themselves are not objects. Example:

int * a = new int;

There are two objects. In using new, I allocate a region of memory. That's one object. In defining a, I have allocated another region of memory. That's the second.

"Comparison objects", which are functors, are not an exception at all. They are storage regions (there is a type and storage duration). Note that the size of the storage region or the type is irrelevant.

[r.stiltskin]

Oler1s, on 29 December 2011 - 02:13 AM, said:

"Comparison objects", which are functors, are not an exception at all. They are storage regions (there is a type and storage duration). Note that the size of the storage region or the type is irrelevant.

What is being stored in an instance of a comparison object? Or in other words, how does it differ, in terms of storage, from a function?

[CTphpnwb]

Mrk, on 29 December 2011 - 01:34 AM, said:

Does an object have to be something that can hold data?

It seems to me that an object needs to hold data and/or method(s).

r.stiltskin, on 29 December 2011 - 02:57 AM, said:

The standard explicitly states that functions are not objects. However, there are comparison objects associated with STL containers which are defined as classes but contain nothing but a constructor and a function call operator that returns a bool to indicate how to order two objects in the container. So the comparison object seems to be an exception to the general rule.

The function isn't an object but the container holding it is.

[Oler1s]

> Or in other words, how does it differ, in terms of storage, from a function?

A function doesn't have a type and storage duration.

EDIT: Or rather, you can argue that functions do have type and storage duration, but C++ explicitly excludes functions from the definition of an object.

> It seems to me that an object needs to hold data and/or method(s).

It doesn't.

This post has been edited by Oler1s: 29 December 2011 - 07:37 AM

[r.stiltskin]

Oler1s, on 29 December 2011 - 09:38 AM, said:

> Or in other words, how does it differ, in terms of storage, from a function?

A function doesn't have a type and storage duration.

EDIT: Or rather, you can argue that functions do have type and storage duration, but C++ explicitly excludes functions from the definition of an object.

So then you are saying that it's not functors, but functions, that are the exception to the general rule?

[CTphpnwb]

Oler1s, on 29 December 2011 - 10:38 AM, said:

> It seems to me that an object needs to hold data and/or method(s).

It doesn't.

The what would it be made of?

[r.stiltskin]

CTphpnwb, on 29 December 2011 - 10:07 AM, said:

Oler1s, on 29 December 2011 - 10:38 AM, said:

> It seems to me that an object needs to hold data and/or method(s).

It doesn't.

The what would it be made of?

The ISO standard is very explicit. (These quotes are from the draft SC22-N-4411. Hopefully the final standard doesn't differ significantly.) Section 1.8 says

Quote

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. —end note ] 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. Some objects are polymorphic (10.3); the implementation generates information associated with
each such object that makes it possible to determine that object’s type during program execution. For other
objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 5)
used to access them.

But in Section 23.1.4 (Storage Containers) it talks about comparison objects:

Quote

Each associative container is parameterized on Key and an ordering relation Compare that induces a strict
weak ordering (25.3) on elements of Key. In addition, map and multimap associate an arbitrary type T
with the Key. The object of type Compare is called the comparison object of a container. This comparison
object may be a pointer to function or an object of a type with an appropriate function call operator. If the
Compare type uses an allocator, then it conforms to the same rules as a container item; the container will
construct the comparison object with the allocator appropriate to the allocator-related traits of the Compare
type and whether is_scoped_allocator is true for the container’s allocator type.

[baavgai]

CTphpnwb, on 29 December 2011 - 10:34 AM, said:

It seems to me that an object needs to hold data and/or method(s).

Not exactly. The methods are function that are associated with type. They aren't carried around.

You write something like this:

class Person {
private:
	string name;
public:
	Person(const string &s) : name(s) { }
	string getName() const { return name; }
};
//
Person bob("Bob");
cout << bob.getName() << endl;

Internally, you'll have something that looks a little more Cish:

struct _cPerson {
	string name;
};
void _cPerson_create(_cPerson &p, const string &s) { p.name = s; }
string _cPerson_getName(const _cPerson &p) { return p.name; }
//
_cPerson bob;
_cPerson_create(bob, "Bob");
cout << _cPerson_getName(bob) << endl;

It's actually worse than that. You'd see all other operator overloads doped out and probably some pointers. This is one of the reason C++ errors dumps are hideous.

When you look at a C++ class, imagine all the methods stripped out and just the declared variables in there. Thats the data load. The object. Everything else is syntax niceness.