10.3 — Aggregation

In the previous lesson on Composition, we noted that object composition is the process of creating complex objects from simpler one. We also talked about one type of object composition, called composition. In a composition relationship, the whole object is responsible for the existence of the part.

In this lesson, we’ll take a look at the other subtype of object composition, called aggregation.


To qualify as an aggregation, a whole object and its parts must have the following relationship:

  • The part (member) is part of the object (class)
  • The part (member) can belong to more than one object (class) at a time
  • The part (member) does not have its existence managed by the object (class)
  • The part (member) does not know about the existence of the object (class)

Like a composition, an aggregation is still a part-whole relationship, where the parts are contained within the whole, and it is a unidirectional relationship. However, unlike a composition, parts can belong to more than one object at a time, and the whole object is not responsible for the existence and lifespan of the parts. When an aggregation is created, the aggregation is not responsible for creating the parts. When an aggregation is destroyed, the aggregation is not responsible for destroying the parts.

For example, consider the relationship between a person and their home address. In this example, for simplicity, we’ll say every person has an address. However, that address can belong to more than one person at a time: for example, to both you and your roommate or significant other. However, that address isn’t managed by the person -- the address probably existed before the person got there, and will exist after the person is gone. Additionally, a person knows what address they live at, but the addresses don’t know what people live there. Therefore, this is an aggregate relationship.

Alternatively, consider a car and an engine. A car engine is part of the car. And although the engine belongs to the car, it can belong to other things as well, like the person who owns the car. The car is not responsible for the creation or destruction of the engine. And while the car knows it has an engine (it has to in order to get anywhere) the engine doesn’t know it’s part of the car.

When it comes to modeling physical objects, the use of the term “destroyed” can be a little dicey. One might argue, “If a meteor fell out of the sky and crushed the car, wouldn’t the car parts all be destroyed too?” Yes, of course. But that’s the fault of the meteor. The important point is that the car is not responsible for destruction of its parts (but an external force might be).

We can say that aggregation models “has-a” relationships (a department has teachers, the car has an engine).

Similar to a composition, the parts of an aggregation can be singular or multiplicative.

Implementing aggregations

Because aggregations are similar to compositions in that they are both part-whole relationships, they are implemented almost identically, and the difference between them is mostly semantic. In a composition, we typically add our parts to the composition using normal member variables (or pointers where the allocation and deallocation process is handled by the composition class).

In an aggregation, we also add parts as member variables. However, these member variables are typically either references or pointers that are used to point at objects that have been created outside the scope of the class. Consequently, an aggregation usually either takes the objects it is going to point to as constructor parameters, or it begins empty and the subobjects are added later via access functions or operators.

Because these parts exist outside of the scope of the class, when the class is destroyed, the pointer or reference member variable will be destroyed (but not deleted). Consequently, the parts themselves will still exist.

Let’s take a look at a Teacher and Department example in more detail. In this example, we’re going to make a couple of simplifications: First, the department will only hold one teacher. Second, the teacher will be unaware of what department they’re part of.

In this case, teacher is created independently of dept, and then passed into dept’s constructor. When dept is destroyed, the m_teacher pointer is destroyed, but the teacher itself is not deleted, so it still exists until it is independently destroyed later in main().

Pick the right relationship for what you’re modeling

Although it might seem a little silly in the above example that the Teacher’s don’t know what Department they’re working for, that may be totally fine in the context of a given program. When you’re determining what kind of relationship to implement, implement the simplest relationship that meets your needs, not the one that seems like it would fit best in a real-life context.

For example, if you’re writing a body shop simulator, you may want to implement a car and engine as an aggregation, so the engine can be removed and put on a shelf somewhere for later. However, if you’re writing a racing simulation, you may want to implement a car and an engine as a composition, since the engine will never exist outside of the car in that context.

Rule: Implement the simplest relationship type that meets the needs of your program, not what seems right in real-life.

Summarizing composition and aggregation


  • Typically use normal member variables
  • Can use pointer values if the composition class automatically handles allocation/deallocation
  • Responsible for creation/destruction of parts


  • Typically use pointer or reference members that point to or reference objects that live outside the scope of the aggregate class
  • Not responsible for creating/destroying parts

It is worth noting that the concepts of composition and aggregation are not mutually exclusive, and can be mixed freely within the same class. It is entirely possible to write a class that is responsible for the creation/destruction of some parts but not others. For example, our Department class could have a name and a Teacher. The name would probably be added to the Department by composition, and would be created and destroyed with the Department. On the other hand, the Teacher would be added to the department by aggregation, and created/destroyed independently.

While aggregations can be extremely useful, they are also potentially more dangerous. Because aggregations do not handle deallocation of their parts, that is left up to an external party to do so. If the external party no longer has a pointer or reference to the abandoned parts, or if it simply forgets to do the cleanup (assuming the class will handle that), then memory will be leaked.

For this reason, compositions should be favored over aggregations.

A few warnings/errata

For a variety of historical and contextual reasons, unlike a composition, the definition of an aggregation is not precise -- so you may see other reference material define it differently from the way we do. That’s fine, just be aware.

One final note: In the lesson Structs, we defined aggregate data types (such as structs and classes) as data types that groups multiple variables together. You may also run across the term aggregate class in your C++ journeys, which is defined as a struct or class that has no provided constructors, destructors, or overloaded assignment, has all public members, and does not use inheritance -- essentially a plain-old-data struct. Despite the similarities in naming, aggregates and aggregation are different and should not be confused.

Quiz time

1) Would you be more likely to implement the following as a composition or an aggregation?
1a) A ball that has a color
1b) An employer that is employing multiple people
1c) The departments in a university
1d) Your age
1e) A bag of marbles

Show Solution

2) Update the Teacher/Dept example so the Dept can handle multiple Teachers. The following code should execute:

This should print:

Department: Bob Frank Beth
Bob still exists!
Frank still exists!
Beth still exists!

Hint: Use a std::vector to hold the teachers. Use the std::vector::push_back() to add Teachers. Use the std::vector::size() to get the length of the std::vector for printing.

Show Solution

10.4 -- Association
10.2 -- Composition

89 comments to 10.3 — Aggregation

  • Bac Dang

    Hi Alex !
    I have 2 code as below:


    The #1 build have error:
    Error    C4700    uninitialized local variable ‘test’ used    Test    e:\cpp\learnc\learnc\test\source.cpp    20    

    The #2 run as well.
    Can you explain why ?
    Thank you.

    • Alex

      In case 1, the compiler is able to detect that test has not been initialized. In case 2, the compiler is unable to detect that test hasn’t been initialized.

      Both are incorrect, even though the second one runs.

      • Bac Dang

        i’m run with visual studio 2017. That mean, it depend on the compiler.
        Thanks you

        • Alex

          Yes, modern compilers will try to detect when you’ve done certain things that you should not be doing, like using the value of an uninitialized variable. Sometimes they are able to do a good job of this. Other times, not so much.

  • Rapol

    Hello, I didn’t see your hint so i did your second quiz task with pointer of pointers, can I ask you a question: Are there any memory leaks in this code? Thanks 🙂 Your tutorials on C++ are the best I have ever seen!

  • Lim Che Ling

    I have finally made the program work and I found my code has different concept with the answer provided. One point to note here is that I have to make getName() const, or I get the error on line (out << ref.getName() << " ";) saying "function member getName not viable: ‘this’ argument has type const Teacher’ but function is not marked….".
    Any comment?

    Great tutorial! Thanks so much!

    #include <string>
    #include <iostream>
    #include <vector>

    class Teacher
        std::string m_name;
        Teacher(std::string name)
        : m_name(name)
        std::string getName() const { return m_name; }

    class Department
        std::vector<Teacher> m_teacher; // This dept holds only one teacher for simplicity, but it could hold many teachers
        void add(Teacher *teacher){
        friend std::ostream& operator<< (std::ostream &out, const Department &dept) {
            out << "Department: ";
            for (auto &ref: dept.m_teacher)
                out << ref.getName() << " ";
            out << "\n";
            return out;

    int main()
        // Create a teacher outside the scope of the Department
        Teacher *t1 = new Teacher("Bob"); // create a teacher
        Teacher *t2 = new Teacher("Frank");
        Teacher *t3 = new Teacher("Beth");
        {// Create a department and use the constructor parameter to pass the teacher to it.
            Department dept;// create an empty Department
            std::cout << dept;
        } // dept goes out of scope here and is destroyed
        // Teacher still exists here because dept did not delete m_teacher
        std::cout << t1->getName() << " still exists!\n";
        std::cout << t2->getName() << " still exists!\n";
        std::cout << t3->getName() << " still exists!\n";
        delete t1;
        delete t2;
        delete t3;
        return 0;

  • Brad

    In my code I had written an overloaded operator<< for both Teacher and Department because I didn’t setup my m_teacher vector with a pointer data type. My solution still worked but when I saw your solution I went on a few hour look at pointers and reducing redundancy in my code. Any day where I learn more about things I thought I understood is a good day! So thank you again for these great tutorials!

  • Dani

    Hello Alex,,,
    i try to understand the last question,it’s make me little confuse, i don’t know deference between
    " std::vector<Teacher*> m_teacher " and " std::vector<Teacher>*m_teacher; ".
    Can you explain me ?Thnks for the answer

    • Alex

      std::vector m_teacher declares a std::vector containing pointers to Teacher objects. This is a common way to implement an aggregation or association of Teachers.
      *m_teacher declares a pointer to a std::vector containing Teachers. I’m struggling to think of a case where you’d ever do this.

  • Milos

    Hello, you should include iostream in the above example.

  • KnowMore

    Consider The Following Snippet :-

    It Gives Me An Error :-

    Can You Tell Me, Why?
    Also, It works perfectly if I remove the const keyword !
    Thanks in Advance ! Reply ASAP.

    • Alex

      temp is a const Department, but you’re trying to call member function getName(), which is non-const. Instead of making temp non-const, you should make member function getName() const.

      • KnowMore

        Oh yes ! So Foolish !
        Sorry for Disturbing !
        Tysm 🙂

      • Help

        Hi Alex!
        In his code he doesn’t have std::vector <Teacher> m_TrackTeachers; in pointer and in urs u got Teacher*. what makes it diffrent is that when he does add he use m_TrackTeachers.push_back(*temp); and u dont have pointer to temp. It’s just something i really do have problem understanding, and the only thing that is diffrent is std::vector <Teacher> m_TrackTeachers;
        what is this called that i need to read about to understand this better?


        • Alex

          Basically, you use a non-pointer when you want the array to own (manage the existence of) the object. You use a pointer when you want the array to hold the object, but not manage it.

          • Help

            Hi Alex!
            I got one question and wounder. when u create a std::vector<Something> m_something; and when u do m_something.push_back u actually make a copy of the object and push it back? while u do std::vector<*Something> m_something; and just m_something.push_back u actually push back the pointing to that object so u dont make copy? thats why he is making a push_back(*temp) and u dont cause u already pointing to that object? He needs to point to object he wanna push back so it doesnt make a copy while u already pointing? I am correct?

            Thanks in advance!:)

            • Alex

              > when u create a std::vector m_something; and when u do m_something.push_back u actually make a copy of the object and push it back?

              Yes. And this can cause object slicing if you’re not careful.

              > while u do std::vector< *Something> m_something; and just m_something.push_back u actually push back the pointing to that object so u dont make copy?

              Yes, in that case we’re just pushing the pointer value itself.

              If you want to point at something that already exists elsewhere, you’ll want to use a pointer so you can point at the object (wherever it lives) rather than making a copy.

  • Omri

    In the following:
    "You may also run across the term “aggregate class” in your C++ journeys, which is defined as a struct or class that has only default constructors/destructors, no protected or private members, and no inheritance or virtual functions."
    A. Did we discuss the concepts of "protected member" "inheritance" or "virtual functions"?
    I understand this as follows:
    "You may also run across the term “aggregate class” in your C++ journeys, which is defined as a struct or class that has only *a* default *constructor/destructor* and public members  *(no other features such as: private members, overloaded constructors/destructors and, to be discussed,  protected members, inheritance or virtual functions)*."
    Is this correct?

    • Alex

      1) We haven’t covered protected members or inheritance yet -- that’s covered next chapter. I’ve updated the wording to speak more towards stuff we have covered.
      2) I also updated the text here a bit -- to be an aggregate class, you can’t define any constructors or destructors (not even a default constructor).

  • Omri

    "In the lesson Structs, we defined *an* aggregate data types (such as structs and classes) as *a* data types that *groups* multiple variables together."
    "In the lesson Structs, we defined ** aggregate data types (such as structs and classes) as ** data types that *group* multiple variables together."

  • Omri

    "Typically use pointer or reference members that point to or reference objects that *lives* outside the scope of the aggregate class."
    "Typically use pointer or reference members that point to or reference objects that *live* outside the scope of the aggregate class."

  • hi alex
    mujy tu opp ki samjh nhi ati koi hal tu bta yara
    i cannot understand opp tell me solution

Leave a Comment

Put C++ code inside [code][/code] tags to use the syntax highlighter