Help me to understand this, If I consider all the C++ standards, including C++11, it's correct to say that the only object that I can deal with is an instance of a class ?
what about other players such as lambdas ? an instance of a POD is considered an object ?
I know that this sounds like a small detail but most of the times I found concepts from other languages hard to compare when I have this kind of problems defining what is an object and what is not, especially in functional OOP languages.
If I consider all the C++ standards, including C++11, it's correct to say that the only object that I can deal with is an instance of a class ?
No, this is not correct.
In C++, the term "object" refers to a region of storage which is given a particular interpretation according to properties (such as its type) which are conferred to the object.
Per Paragraph 1.8/1 of the C++11 Standard:
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.
So basically an int
is an object, an instance of a POD is an object, and of course an instance of a class type is an object. In OOP, the term "object" is usually meant to denote just the latter entity - but in C++ this is not the case.
what about other players such as lambdas ?
Lambdas are actually syntactic sugar to define unnamed functors (Paragraph 5.1.2/1):
Lambda expressions provide a concise way to create simple function objects. [...]
Also (per Paragraph 5.1.2/2):
The evaluation of a lambda-expression results in a prvalue temporary (12.2). This temporary is called the closure object. [...] [ Note: A closure object behaves like a function object (20.8). —end note ]
Therefore, lambdas are expressions whose evaluation results in the creation of a temporary object (so yes, in some sense one could say lambdas are also objects, or rather that they yield an object).
in c++ an object is a region of storage with an associated type
e.g. an int
the region needs not necessarily be contiguous
as an example, with virtual multiple inheritance parts of an object can be (in the sense of, some situations exist where it has to be) spread around
Traditional OOP tends to define the notion of "object" as a "polymorphic entity" that carries methods and data, and can be referenced from other objects an algorithms.
The C++ definition of object is -in essence- "whatever thing takes a space to retain a state". This lead to the main difference that C++ "objects" have "value behavior" and that "methods" are not necessarily members, and object don't need to necessarily support runtime polymorphism.
C++ program following the traditional OOP definition, ends up with classes referred by (smart)-(base)-(pointers|reference), using the indirection mechanism as a key to resolve polymorphism at runtime.
Modern C++ uses object as having value-copy or move semantics, and tends to address polymorphism at compile time with templates and generic algorithms and type traits.
The two things are not one against the other, but C++ is intentionally the merging of both of them, hence reducing the definition of "object" the traditional OOP one (instance of a class to be referenced), is -in fact- cutting away one half of the C++ features and possibilities.
About lambdas, it strict sense they are expressions (not objects themselves) returning anonymous typed objects.
So saying they are objects is improper: a+b
it is not itself an object: it produces an object (the result of the expression). The same is for [](){}
: it is not itself an object: it produces an object, you can even store, like in
auto fn = [](){}; //create a lambda and assign to fn.
fn(); //just calls it
The fn type is something like
class lambda_uniquename
{
public:
void operator()()
{}
};
The object, here, is not the lambda
class, but the fn
variable.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With