1

i have an assignment to build a vector. The assignment have a huge testprogram, but the testprogram gives 0 information about memory leaks. At first i had an error message that said heap corruption detected but i think ive solved the problem with the last delete[] statement in this code:

template<typename T>
inline Vector<T>& Vector<T>::operator=(const Vector& other)
{
    if (other.m_nrOfElements > m_nrOfElements)
    {
        delete[] m_elements;
        m_capacity = other.m_capacity;
        m_elements = new T[other.m_nrOfElements];
    }
    for (int i = 0; i < other.m_nrOfElements; i++)
    {
        m_elements[i] = other.m_elements[i];
    }
    m_nrOfElements = other.m_nrOfElements;

    delete[] &other; //THIS LINE
    return *this;
}

But when i run the program now, i get read access violation in my destructor instead. It looks like this:

template<typename T>
inline Vector<T>::~Vector()
{
    delete[] m_elements;
}

And if i dont use the delete statement i get memory leaks. Is there any easy way to find memory leaks in Visual Studio 2022? As i said before, the assignment comes with a testprogram so i cant open the property page or anything like that.

Im posting the other constructors, operators and vaiables here under, if someone can find something that would help.

template <typename T>
class Vector
{
private:
    int m_capacity;
    int m_nrOfElements;
    T* m_elements;

public:

template<typename T>
inline Vector<T>::Vector()
    :m_nrOfElements(0),
    m_capacity(5),
    m_elements(new T[m_capacity])
{

}

template<typename T>
inline Vector<T>::Vector(const Vector& other)
    :m_nrOfElements(other.m_nrOfElements),
    m_capacity(other.m_capacity),
    m_elements(new T[m_capacity])
{
    for (int i = 0; i < other.m_nrOfElements; ++i)
    {
        m_elements[i] = other.m_elements[i];
    }
}

template<typename T>
inline Vector<T>::Vector(int index, T element)
    :m_nrOfElements(index),
    m_capacity(index + 5),
    m_elements(new T[m_capacity])
{
    for (int i = 0; i < m_nrOfElements; ++i)
    {
        m_elements[i] = element;
    }
}

template<typename T>
inline Vector<T>::Vector(Vector&& other)
    : m_nrOfElements(std::exchange(other.m_nrOfElements, 0)),
    m_capacity(std::exchange(other.m_capacity, 0)),
    m_elements(std::exchange(other.m_elements, nullptr))
{
}

template<typename T>
inline Vector<T>& Vector<T>::operator=(Vector&& other)
{
    delete[] m_elements;
    m_nrOfElements = other.m_nrOfElements;
    m_capacity = other.m_capacity;

    m_nrOfElements = std::exchange(other.m_nrOfElements, 0);
    m_capacity = std::exchange(other.m_capacity, 0);
    m_elements = std::exchange(other.m_elements, nullptr);

    return *this;
}

template<typename T>
inline T& Vector<T>::operator[](const int index) const
{
    if ((index < 0) || (index >= m_nrOfElements))
    {
        throw std::exception("Index out of range");
    }
    return m_elements[index];
}
  • The best way to avoid memory leaks is to use STL containers (like std::vector, std::array), and only if you MUST allocate memory yourself then use std::make_unique (or std::make_shared). In most cases (where you are not writing libraries yourself) the use of new/delete is no longer recommended. See : https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines. The assignment to write your own vector is understandable from a datastructures point of view (and to show how hard it is to do memory managment manually). But your teacher should mention std::vector or you should mention it to him. – Pepijn Kramer Aug 13 '22 at 14:09
  • I use this https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/crtdumpmemoryleaks – doug Aug 13 '22 at 14:20
  • The comments so far are missing the forest for the trees. Simply put, and at the beginning of the post, **I have an assignment to build a vector**. It's a data structures class. It's nice that in typical SO fashion the "just use a vector" meme is alive and well. – sweenish Aug 13 '22 at 14:56
  • As to the question at hand, I haven't (nor will I) thoroughly examined the code, but why would you delete `other` at all? You're assigning from it, not moving it. It's also a `const` parameter, so you're not allowed to modify it, let alone `delete` it. – sweenish Aug 13 '22 at 14:58
  • I'm not sure what else is wrong, but there's a potential bug in your assignment operator (aside from the already mentioned `delete`problem). In case you need a bigger allocation, you allocate `other.m_nrOfElements` elements but set `m_capacity`to `other.m_capacity`. This seems wrong to me. – Jacob Aug 13 '22 at 15:26

0 Answers0