So I was reading Accelerated c++ and there is a statement like:

"A variable is an object that has a name".

That made me go into fog.

So if I have a class:

class x

{

public:

int i;

}

and i create:

x here;

is here called an object or a variable? According to accelerated c++ it's a variable,but what is an object then?!

A variable is just a piece of data. It can be a number, some words, or an object.

No, in C++ the term "variable" refers to named objects. Not every piece of data is a variable; only declared object are variables. "Just a piece of data" would be what C++ calls "entities". In this case "here" is the name for an object, so it is both an object and a variable. If you had Object obj = new Object;. obj would be a variable and what obj points to would be an object, but it wouldn't be a variable.

SiCrane has the right of it.

In the OP example, "here" is a variable. It represents an object. So it is both.

EDIT: made consistent with frob's quoting of the standard below.

Some of those are not quite right, in subtle ways. An object does not need to have a name. An object is not necessarily a variable.

Since this gets into the language-lawyer side of things, let's go strait to the language standard:

• A name is a use of an identifier ... that denotes an entity or label.
• ... [it does not meet the definition of a label, therefore it is an entity] ...
• Every name that denotes an entity is introduced by a declaration. ...
• A variable is introduced by the declaration of a reference other than a non-static data member or of an object. The variable's name denotes the reference or object.
• An object is a region of storage. ... An object is created by a definition, by a new-expression or by the implementation when needed. The properties of an object are determined when the object is created. An object can have a name.

So as SiCrane pointed out, "here" is a name, and it denotes an entity. That entity is a variable, and it is an object, all at the same time.

No. That's just a different syntax for variable declarations.

Assuming that code goes in a function, that declares 2 objects on the stack(an object of type Object, and one of type pointer to Object), and one on the heap (of type Object). It also declares two variables, that denote the two stack objects. So obj and obj1 are variables, that denote specific and different stack objects.

Contrast that example with this:

Object obj; 
Object &obj1(obj);

This declares just one object, but two variables. The second line declares a reference to the first object, which makes it not an object declaration; it technically doesn't declare anything on the stack. obj and obj1 refer to the same object.

I say it technically doesn't declare on the stack, because it can be useful to think of a reference as syntax for a restricted kind of pointer. From that point of view, obj1 implies the declaration of a pointer object. So two stack objects are created, but any use of the second variable will access the object represented by obj. Also, under this view, the second object (the pointer) is surely optimized out when compiled.

Either way of describing this code is consistent with the behavior of C++, and won't mislead, but the former is the wording used by the standard, and therefore technically more correct. I hope I'm not confusing the issue by explaining thoroughly. If this and the previous paragraph confuse more than help, they can be jointly ignored.

Here is an example:

You can think of a variable like a box that stores one thing. The data that this box or variable can store depends on what the data type is. The way you know how to refer to a variable or know what the variable is, is by its name.

Example:

Dog sparky = new Dog();

sparky would be the variable. sparky is of type Dog.

An object is an instance of a class. What that means is that object is an example of a class.

For example: Dog is an instance of the class Pet. Cat is an instance of the class Pet.

Instance are examples. Dog is an example of a Pet. Cat is an example of a Pet.

warnexus and Daaark are talking about the definition of a object in the context of object oriented programming, which is an abstract way to think about and design code. That's not the definition that sentence is using. It is related, because OOP objects are C++ objects, but not all c++ objects need to be treated as OOP objects.