What is a Class and Object in C++?
Can we say that a Class is an Object?
A Class is like a blueprint, an object is like a house built from that blueprint.
You can have many houses with the same layout/floorplan (read class), but each is it's own instance (read object). Each has it's own owner, furniture, etc.
Note that there are also objects whose blueprint is not a class (e.g. integers).
An object is an instance of a class.
An object is some data, which has an address in run-time memory.
There are different types of object (e.g. int, float, etc.). You can create user-defined types, called 'classes'.
For example, I can define Dog as a class ...
class Dog {};
... and then create several objects, each of which is one instance of that class ...
Dog fido;
Dog spot;
I will try to give more technical explanation rather than an abstract one. I think that definitions like "a class is a blueprint and an object is something made from this blueprint" are impossible to understand for newbies simply because these kind of definitions are abstract and context-less.
Classes and objects have a pure abstract meaning in the object oriented world but for simplicity I will reduce the definition to a more practical one.
Consider the following statement:
int a;
"int" is a type and is "a" is a variable which has the type "int".
C++ provides various ways to let the programmer define new types; for example:
typedef int* int_ptr;
int_ptr a;
In this example , a new type is defined int_ptr.
"int_ptr" is a type , "a" is a variable which has the type "int_ptr".
Another example:
struct Point
{
int x;
int y;
};
Point a;
Here, a new type is defined, "Point", and "a" is a variable which has the type "Point".
So what is a class in C++? A class is another way to define a new type, just like the other ways mentioned above.
What is an object? An object is a variable which has a type that was defined using the class keyword.
For example:
class SmartPoint
{
public:
Point(x,y);
Move(x,y);
protected:
int x,y ;
};
SmartPoint a;
In this example, a new type is defined, "SmartPoint", and "a" is a variable which has the type "SmartPoint".
You may ask then what is different between a type defined by using the "class" keyword or "struct" keyword or "typedef" — but that is a matter for another discussion.
No, an object is an instance of a class.
No, an object is an instance of a class...
Unless...
If you are implementing a software design tool that allows you to represent classes, interfaces, properties, inheritance, associations, aggregations, etc., then at runtime, yes, each class you place in the designer will be an object instance of the Class class. Ok, couldn't help myself finding an example so twisted and meta.
Now seriously, a class is not an object.
Class is a collection of data member and member function.
Class is a user define data type.
Object is a class type variable.
Objects are also called instance of the class.
Each object contains all members(variables and functions) declared in the class. We can access any data member or member function from object of that class using . operator.
Here is an anology.
we have a classification called vehicles. Each vehicle will have some properties like :
seating capacity
fuel capacity
fuel consumption
type of transmission
Car, bike, truck, are some instances of vehicles. Each may have different set of properties.
Here vehicles is a class and all the properties are it's members and car, bike, truck are objects of the class vehicles.
No,class is not a object.
A class is a data type and object is the variable(instance) of class data type.
C++ supports many paradigms, but not the 'everything is an object' style of object-oriented programming. Classes exist in the source code, but do not exist at run time. Even runtime type information doesn't preserve Classes as object, but only provides a capability to get opaque ids which correspond to the type.
Class: A class defines a particular type's behaviours and properties.
Object: An object is an instance of a class.
For example, if you have a Dog named Bingo.
Dog would be the class defining its behaviours and properties
Bingo would be an object that is an instance of the Dog class
Strictly speaking, a Class is not an Object in C++.
But in languages such as C# and Java that supports reflection, classes can be used like objects but that is a more advance topic and probaly not what the original question is asking.
A class is not an object.
In simpler C language, a class is like a struct type, but more complex.
Using a C struct example as analogy:
struct class_ {
int attribute00;
float attribute02;
...
}
struct class_ object_ = {0, 0.0, ...};
struct class_ is act like a class and object_ is act like an object.
struct class_ has no physical storage in memory, object_ has physical storage in memory.
In human language, a word 'house' (as class) can defined in dictionary as place to stay, with doors, with windows, and rooms that you can only speak with your mouth to tell other people what is a house. A physical house (as object) is a solid build house on a land that you can move in and stay with your family.
A word 'house' take no physical occupation of land or space.
A physical house occupy land and space.
Class is collection of data and functions,its user defined data type.Class is specification for object.So you can say that object is variable for class or object is instance of class.
A class is a logical construct while object is its physical copy.
A class can be thought of as a mould from which multiple objects are created which appear identical to the class
Objects can be thought of as carbon copies of the class.
A perfect example of inheritance principle.
A class can be thought of as a parent of its children - objects
Object is an data or a function which has an adress in run time memory and are also called as instances of class .
Thus object is an class type variable or entity of c++ programming language.
In object-oriented programming , a class is a template definition of the method s and variable s in a particular kind of object . ... Subclasses can also define their own methods and variables that are not part of their superclass. The structure of a class and its subclasses is called the class hierarchy.
This is analogous to asking if a cat is a "My Kitten Mittens".
In C++, Objects are essentially the variables and Classes are the types of their values.
Short Answer: In Languages C++, Java: No.
In Languages like Python: Yes
When you define a class, you define a blueprint for a data type. This doesn't actually define any data, but it does define what the class name means, that is, what an object of the class will consist of and what operations can be performed on such an object.
A class definition starts with the keyword class followed by the class name; and the class body, enclosed by a pair of curly braces. A class definition must be followed either by a semicolon or a list of declarations. For example, we defined the Box data type using the keyword class as follows:
class Box
{
public:
double length; // Length of a box
double breadth; // Breadth of a box
double height; // Height of a box
};
The keyword public determines the access attributes of the members of the class that follow it. A public member can be accessed from outside the class anywhere within the scope of the class object. You can also specify the members of a class as private or protected which we will discuss in a sub-section.
A class is a user-defined blueprint or prototype from which objects are created. It represents the set of properties or methods that are common to all objects of one type.
Example:
class Person {
//..properties
//..methods
}
An Object is an instance of a Class or created from a class.
Example:
Person John = new Person(); //Creating an object of Person class
John.property1 = value; //setting value of property1 for John which is of Person
//Type
Both classes and instances are objects, but object oriented programming doesn't force the language to have classes & instances.
Related
I've created a C++ class that has a public member that is a pointer to an unrelated class. Here it is:
class ADS_1x15 : public Sensors {
public:
ADS_1x15(uint8_t addr = 0x48, adsGain_t gain = GAIN_TWOTHIRDS, String = "");
Adafruit_ADS1115* ads;
};
It's the base class for some other classes that do different things with the Adafruit ADS1115 ADC, so the member ads is used in any descendent class.
There is a very similar Adafruit ADC called an ADS1015, and I'd like for my classes to work with either of the two ADC's. Of course, an Adafruit_ADS1015 is a very different object than an Adafruit_ADS1115. In my base class, I want to be able to pass in a parameter that tells the class "include a pointer to EITHER an Adafruit_ADS1015 OR an Adafruit_ADS1115, but whichever one is used, make the variable name for the pointer be the same: ads". All the methods for the two objects are identical, so once I get ads pointed to the correct object, everything in my classes will work, regardless of which ADS is used.
Is this possible?
How to have a pointer to class A OR class B in my class?
Is this possible?
Yes. It is possible. You are describing dynamic polymorphism. If Adafruit_ADS1115 and Adafruit_ADS1015 share a base class B, then B* can point to (base sub object of) either child class.
There is also another form of dynamic polymorphism which doesn't require inheritance: Type erasure. There is unconstrained type erasure that can be achieved with std::any, which allows your class to contain objects of any type. And there is constrained type erasure that allows a finite set of types that can be achieved with a tagged union (std::variant). There are also specialised type-erasure wrappers for particular use cases such as std::function for storing any type of callable.
Note that dynamic polymorphism typically involves some amount of overhead which might not be necessary in your case.
An alternative is static polymorphism that can be achieved through the use of templates. In this case for example, you might define a following template:
template<class Adafruit_ADS1x15>
struct ADS_1x15 : Sensors {
Adafruit_ADS1x15* ads;
I'm new to object oriented programming and am struggling a bit with how best to write classes.
I am trying to abstract the idea of sorting to objects that are not just lists of numbers. I have an abstract base class, SortableContainer, which contains all the necessary virtual functions for comparing and swapping elements, along with some overloaded operators. I then have two classes derived from that, MVector and CoordinateArray. Both of these derived classes have proper definitions for all the virtual functions in the base class. Everything up to this point has worked just fine. MVector just stores vector-like objects and CoordinateArray stores vectors of coordinates onto which a notion of 'less than' has been defined.
My problem now is that I have created a new class, Life, which I want to use to implement the game of life using a CoordinateArray object to store the alive cells. The outline of my Life class looks like this:
class Life
{
public:
CoordinateArray LiveCells;
Life();
};
When I create a Life object and initialise it with the coordinates of some alive cells, none of the member functions defined in the CoordinateArray derived class will work. How can I fix this? Do I have to derive the Life class from the SortableContainer class and then override all the pure virtual functions? Any help or direction to help will be much appreciated.
To answer your question simply and in a pragmatical way, yes, if you want your Life object to have some member functions they need to come from somewhere, the most straight forward way is to derive it from a class containing those member functions, composition does not transfer members to the owner, inheritance does that:
class Life : public CoordinateArray
{
public:
Life();
};
Now you can use your Life objects as a CoordinateArray object. If anything is pure virtual in the parent class you will indeed need to implement it in the derived class, but even if something is not you can still reimplement it in the child class to overwrite the parent behaviour.
I avoided conception and design problematics on purpose, this is mainly a technical answer, judging this from a design point of view requires more context and has some subjective side too so that's another story altogether.
It would be useful to see the declaration of CoordinateArray. However, I suspect you need to make public methods in CoordinateArray. If the methods are declared private (i.e., they come after private: in your class declaration), then they can only be used inside the class's own scope. If they're declared public (underneath public:), then they can be used in any scope. (As a sidenote, there is one other classification, protected, which means they can be used by the class and any of its subclasses.)
In order to initialize co-ordinates of some live cells declare the class CoordinateArray LiveCells public to Life
class Life::public CoordinateArray{ }
I was reading "Design Patterns: Elements of Reusable Object-Oriented Software", (specifically the chapter about the prototype design pattern) and it stated that...
"Prototype is particularly useful with static languages like C++ where classes are not objects, and little or no type information is available at run-time." (pg 121)
(emphasis mine)
I had always thought that classes were synonymous to objects, and I'm confused as to what this statement means. How are classes not objects, and why does it matter if a language is static?
A class in C++ is not an object: a class is a description of how to build an object, and a reference to a type of an object.
Compare with a language like Python: in python, like in C++, you instantiate an object from a class. Unlike C++, the class you used is also an object: it usually has type type, and you can create new ones at runtime, manipulate them like any other object, or even create objects which are classes which themselves have different types.
You may be wondering why you'd want this, and usually you don't need it -- it's like C++ template meta-programming, you only need it when you need it because you can't achieve your goal in any other way. It's probably also the case that problems you'd solve in Python with meta-classes you'd solve in C++ using template meta-programming.
In C++, this declares a class:
class A {
public:
int a;
};
whereas this declares an object:
A a;
One cannot interrogate a class a run-time, as one can interrogate an object. It makes sense to say, "object 'a', what is your address? Please invoke operator+. etc." In C++, with its static typing, it makes no sense to say, "Class A, what is your list of members? Please add a new member, "b"."
In other languages (Python comes to mind), one can manipulate classes in this way, because each class is also an object. In addition to serving as a template for objects, the class itself is an object -- it can be printed, modified, etc.
For example, a class could describe what a book is: Name, Author, Date of Publishing, Description.
An object of the "Book" class would be a specific book: C++ Primer Plus, Stephen Prata, 2005, A book that teaches C++.
So, classes are not the same as objects.
To expand on what Andrew Aylett said.
A class in C++ is not an object: a class is a description of how to build an object, and a reference to a type of an object.
Furthermore, in languages like Python or smalltalk. Everything is an object. A function is a object, a class is a object. As such these languages are Dynamically Typed, meaning that types are checked during runtime and variables can take on any type.
C++ is statically typed. Variables can only take on one type, and type checking is performed at compile time.
So in python for instance, you can modify a class on the fly. Add functions and fields, because it is an object, and can be modified.
What that sentence refers is to is the fact that classes are not first-order entities in a language like C++. In other languages, you can pass a class as a parameter to a function, e.g., the same way as you can pass an object or a function as a parameter.
There are many more implications of being classes first-order entities or not, e.g., the possibility of modifying a class at runtime, or inspecting the full internals of a class, etc.
Usually classes are found to be first-order entities in dynamic languages like ruby, or in the meta object protocol for lisp, etc.
Hope this clarifies it a bit.
Classes are not the same as Objects. A class is (more or less) the type, and an Object is the instance, simmiliar to the following:
int i;
YourClass object;
Here you wouldn't say i and int are the same -- neither are YourClass and object.
What the statement wants to say: Many object orientated languages are very object orientated, so that they start making everything (or nearly everything) an object (of one or another class). So in many languages a class would be an instance (hence an object) of some class class (which can be confusing).
This sometimes has advantages, as you can treat classes (that's types) in such languages like you could treat any other object. You can than do very dynamic stuff with them, like store them in variables or even manipulate the classes during runtime (e.g. to create new classes your program finds the need to have).
Take a look at this c++-similiar pseudo code:
YourClass myObject = new YourClass(); // creates an object (an instance)
Class baseClass = myObject.get_class(); // store the class of myObject in baseClass. That's storing a type in a variable (more or less)
Class subClass = myObject.inherit(); // dynamically create a new class, that only exists in variable subClass (a Class-object), inheriting from baseClass
subClass.add_method(some_function); // extend the new class by adding a new method
subClass.get_class() subClass.create_instance(); // declare a new variable (object) of your newly created type
BaseClass another_onne = subClass.create_instance(); // also valid, since you inherited
This obviously doesn't translate well to c++, because of c++'s strict typing. Other languages are more dynamic in typing, and there this flexibility can come in handy (and make thinks more complicated; sometimes both at the same time). Still I think it explains the principle, if you understand c++.
I had always thought that classes were synonymous to objects
The language in OOP literature is sometimes not specific. It doesn't help either that programming languages have somewhat different notions of what an object is.
A class is a template or definition from where objects (instances of that class) are created. That is, a class provides the structure, type signatures and behaviors that objects of that class (or type... more on that later.)
An object is just a location in memory of an instance of that class.
Wikipedia provides good documentation on this. I suggest you read it:
http://en.wikipedia.org/wiki/Class_(computer_programming)
http://en.wikipedia.org/wiki/Object_(object-oriented_programming)
Also, there is the concept of a type. A type (or interface as sometimes called in some literature or programming languages) is typically the collection of type/method signatures (and possibly behavior). Things like Java interfaces and C++ pure virtual classes tend to represent types (but aren't exactly the same).
Then a class that conforms to that type (be it interface or pure virtual class) is an implementation of that type.
That class, that type implementation is just a recipe of how to construct objects of that class/type in memory.
When you instantiate a class/type, you reify, construct an instance (object) of that class in memory.
In C++, a class is not an object since a class itself is not instantiated. A C++ class is not an instance of some other class (see the definitions I put above.)
OTH, in languages like Java, a class itself is represented by instances of a primordial class (java.lang.Class). So a class X has an object in memory (an java.lang.Class instance) associated with it. And with it, with that "class" object, you can (in theory) instantiate or manufacture another instance (or object) of class/type X.
It can get confusing. I strongly suggest you search and read the literature on classes, types, prototypes and objects/instances.
and I'm confused as to what this statement means. How are classes not
objects,
As explained above. A class is not an object. An object is an instance, a piece of memory constructed and initialized by the "recipe" of a class or type.
and why does it matter if a language is static?
That part of the book is a bit misleading because Java, for example, is statically typed and yet, classes can be object themselves. Perhaps the text is refering to dynamically typed languages (like JavaScript) where classes can also be objects or instances.
My suggestion is to never use the word object, and to simply limit the vocabulary to "classes" and "instances". But that's my personal predilection. Other people might disagree, and so be it.
The simpler I can put it for you to understand it:
An object is a "physical" instance of a class. It consumes memory while the program is running.
A class describes an object: Hierarchy, properties, methods. A class it's like a "template" for creating objects.
When a class is said to be an object, it means that there's an object that represents that class at runtime. In C++, classes are dissolved at compile time. Their instances (i.e. objects) are merely sequences of bytes holding the object's fields, without any reference to the class itself. Now, C++ does provide some type information at runtime via RTTI, but that's only for polymorphic types, and is not considered a class object.
The lack of having objects that represent classes at runtime is the reason there's no reflection in C++ - there's just no way to get information about a certain class, as there's no object that represent it.
BTW, C++ is considered a 2-level language: objects are instances of classes, but classes are not instances of anything, because they only exist at compile type. On 3-level languages such as C# and Java, classes are also objects at runtime, and as such, are themselves instances of yet another class (Class in Java, Type in C#). The last class is an instance of itself, hence the language only has 3 levels. There are languages with more levels, but that's beyond the scope of this question...
In C++ there are just objects and classes, where objects are instances of classes.
In Python, a class definition (i.e., the body of a class) is called an object.
And, the object in C++ is called instance in python.
Check this
Am I wrong?
EDIT : Actually can someone explain with example difference of object vs instance
EDIT : In python, everything will inherit from object class & hence everything is an object (i.e object of object class).
A Class is also an object (i.e object of object class).
Instance is the name used to call the object of any class.(a.k.a c++ object).
Please refer this
In Python, a class definition (i.e., the body of a class) is called an object
Actually, this is still called a class in Python. That's why you define it like this:
class Foo(object):
pass
The class keyword is used because the result is still called a class.
The word object is in parentheses to show that Foo is derived from the class called object. Don't be confused -- any existing class could be used here; more than one, in fact.
The reason you usually derive classes from object is a historical accident but probably is worth a detail. Python's original object implementation treated user-defined classes and built-in types as slightly different kinds of things. Then the language's designer decided to unify these two concepts. As a result, classes derived from object (or from a descendant of object) behave slightly differently from classes that are not derived from object and are called new-style classes. Old-style classes, on the other hand, were ones defined like this:
class Foo:
pass
class Bar(Foo):
pass
Note these do not inherit from object or from anything else that inherits from object. This makes them old-style classes.
When working with Python 2.x, your classes should almost always inherit from object, as the new-style objects are nicer to work with in several small but important ways.
To further confuse things, in Python 3.0 and later, there are no old-style classes, so you don't have to derive from object explicitly. In other words, all the above classes would be new-style classes in Python 3.x.
Now, back to the matter at hand. Classes are objects because everything is an object in Python. Lists, dictionaries, integers, strings, tuples... all of these are objects, and so are the building blocks of Python programs: modules, functions, and classes. You can create a class using the class keyword and then pass it to a function, modify it, etc. (For completeness, you can also create a class using the type() function.)
A class is a template for building objects, which are referred to as instances. This part you already know. You instantiate objects similar to calling a function, passing in the initial values and other parameters:
mylist = list("abc") # constructs ["a", "b", "c"]
Behind the scenes, this creates an instance, then calls the new instance's __init__() method to initialize it. Since everything's an object in Python, instances of a class are also objects.
One last thing you might want to know is that just as classes are templates for building objects, so it is possible to have templates for building classes. These are called metaclasses. The base metaclass is called type (that is, an ordinary new-style class is an instance of type).
(Yes, this is the same type that I mentioned earlier can be used to create classes, and the reason you can call it to create classes is that it's a metaclass.)
To create your own metaclass, you derive it from type like so:
class mymeta(type):
pass
Metaclasses are a fairly advanced Python topic, so I won't go into what you might use them for or how to do it, but they should make it clear how far Python takes the "everything's an object" concept.
Terminology-wise, classes and instances are both called objects in Python, but for you as a regular Python programmer this is of no importance. You can see Python's classes and instances pretty much as C++'s classes and instances:
class MyClass:
data = 1
mc = MyClass()
MyClass is a class and mc is an instance of class MyClass.
Python is much more dynamic in nature than C++ though, so its classes are also objects. But this isn't something programmers usually are exposed to, so you can just not worry about it.
Everything in Python is an object. Even classes, which are instances of metaclasses.
Since you asked for "english please", I'll try to make it simple at the cost of detail.
Let's ignore classes and instances at first, and just look at objects.
A Python object contains data and functions, just like objects in every other object oriented programming language. Functions attached to objects are called methods.
x = "hello" #now x is an object that contains the letters in "hello" as data
print x.size() #but x also has methods, for example size()
print "hello".size() #In python, unlike C++, everything is an object, so a string literal has methods.
print (5).bit_length() #as do integers (bit_length only works in 2.7+ and 3.1+, though)
A class is a description (or a recipe, if you will) of how to construct new objects. Objects constructed according to a class description are said to belong to that class. A fancy name for belonging to a class is to be an instance of that class.
Now, earlier I wrote that in Python everything is an object. Well, that holds for stuff like functions and classes as well. So a description of how to make new objects is itself an object.
class C: #C is a class and an object
a = 1
x1 = C() #x1 is now an instance of C
print x1.a #and x1 will contain an object a
y = C #Since C is itself an object, it is perfectly ok to assign it to y, note the lack of ()
x2 = y() #and now we can make instances of C, using y instead.
print x2.a #x2 will also contain an object a
print C #since classes are objects, you can print them
print y #y is the same as C.
print y == C #really the same.
print y is C #exactly the same.
This means that you can treat classes (and functions) like everything else and, for example, send them as arguments to a function, which can use them to construct new objects of a class it never knew existed.
In a very real sense, everything in Python is an object: a class (or any
type) is an object, a function is an object, a number is an object...
And every object has a type. A "type" is a particular type of object (a
class, if you wish), with additional data describing the various
attributes of the type (functions, etc.). If you're used to C++, you
can think of it as something like:
struct Type;
struct Object // The base class of everything.
{
Type* myType;
// Some additional stuff, support for reference counting, etc.
};
struct Type : Object
{
// Lots of additional stuff defining type attributes...
};
When you define a new class in Python, you're really just creating a new
instance of Type; when you instantiate that class, Python initializes
the myType member with a pointer to the correct instance of Type.
Note, however, that everything is dynamic. When you define a type
Toto (by executing a class definition—even defining a type is a
runtime thing, not compile time, as in C++), the Python interpreter
creates an instance of Type, and puts it in a dictionary
(map<string, Object*>, in C++ parlance) somewhere. When the interpreter
encounters a statement like:
x = Toto()
, it looks up Toto in the dictionary: if the Object referred to has
the type Type, it constructs a new instance of that object, if it has
type Function (functions are also objects), it calls the function.
(More generally, a type/class may be callable or not; if the type of the
Object found in the dictionary under Toto is callable, the Python
interpreter does whatever the object has defined "call" to mean. Sort
of like overloading operator()() in C++. The overload of
operator()() for Type is to construct a new object of that type.)
And yes, if you come from a classical background—strictly procedural,
structured, fully-compiled languages, it can be pretty confusing at
first.
I'm learning C++ and moving my project from C to C++. In the process, I stumbled on this problem: how to save/update variables that are in use in several classes? In C I used global variables, but it is not good for C++.
So, let's assume we have 4 classes:
class Main_Window
{
//...
void load_data_menu_selected();
}
class Data
{
//...
double *data;
}
class Load_Data
{
//...
double *get_filename_and_load();
}
class Calculate
{
//...
int do_calculation()
}
So, Main_Window is class for application's main window where it interacts with user input etc.
I want to do:
create an instance of class Data in the Main_Window
use Load_Data for loading data from file and store it in the Data
use Calculation class for doing something with read data in Data class
The question is: where I should create classes, to make Data class members available from other classes. Should I use Inheritance?
Start from observing what are possible relations between instances of two classes. Let us say a is an instance of class A and b is an instance of class B. If a uses b, class A can have as its member instance of class B (b), pointer to b (which is of type B*), or reference of b (which is of type B&). If only one method of class A uses b, you have again same three options: B, B* or B& can be method's arguments. Having B* and B& as class members suggests that a does not control b's lifetime so class A must have a method that sets these members through its parameters. The question of ownership (objects' lifetimes) has a big role in design of relationship between classes. Main relationships are briefly described in this article.
I think you only want to have a Main_Window class, and the rest should be members of that class.
class Main_Window
{
private:
DataObject windowData;
public:
void loadData(string fileName);
void calculate();
}
Inside the loadData and calculate methods, you will be able to access the same data with this->windowData . Sorry if my syntax is bad, my c++ is rusty
Typically, you would pass (const) Data& around as an argument. If do_calculation() needs a Data to work with, then it takes Data&. But I can't really be more specific or useful unless you post more of your design.
You need to know how to design in OO. Thinking in C is different from thinking in c++. You can that your classes have many methods. Well, that sound like a bad design.
I can recommend you to start with the SOLID principle.
Then start writing unit tests for your classes. TDD could help you improve your design even further.
It sounds like you should not use inheritance here. The main reason for saying so is that you have a number of classes (Window, Calculator, etc.) using or doing something to an entity (i.e. Data). Inheritance is used to denote an "is a" relationship (i.e. if A inherits from B, A "is a" B).
In this case, you use composition, which denotes a "has a" relationship. So each class takes a reference to an instance of Data, and acts upon that object.
Who owns the Data object? To share a single Data object, you might want to look into Boost shared_ptr, which allows multiple reference-counting pointers to share an object allocated with "new".