C++ dynamic array implementation
Welcome to C++, and welcome to Code Review.
C++ memory management is, as you probably have realized, tough and
error-prone.  There are many things that can easily go wrong.
Assuming that no exception is thrown, I don't see obvious memory leaks
in your code; however, there are still some issues worth discussing.
You can take a look at my implementation of a non-resizable dynamic
array or a stack-based full-fledged vector for some
inspiration.
Special member functions
You have not defined copy constructors or move constructors, so the
compiler will synthesize corresponding constructors that simply copy
all the members — which is completely wrong, as now the two
dynamic arrays will point to the same memory.  Not only are the
elements shared between the copies, causing modifications to one array
to affect the other, but the two copies will attempt to free the same
memory upon destruction, leading to a double-free error, which is
way more serious than a memory leak.
Initialization semantics
It is generally expected that the constructor of the element type is
called \$n\$ times if \$n\$ elements are pushed into the dynamic
array.  In your code, however, this is not the case, whre the amount
of constructors called is determined by the capacity of the dynamic
array.  Elements are first default initialized, and then copy-assigned
to.
The correct way to solve this problem requires allocating an
uninitialized buffer, and using placement new (or equivalent features)
to construct the elements, which is another can of worms.
Exception safety
Think of what happens when the construction of an element throws an
exception — your code will halt halfway, and there will be a
memory leak.  Resolving this problem would require a manual try
block, or standard library facilities like
std::uninitialized_copy (which essentially do the same under
the hood) if you switched to uninitialized buffers and manual
construction.
Move semantics
All of the elements are copied every time, which is wasteful.  Make
good use of move semantics when appropriate.
Miscellaneous
Used std::size_t instead of int to store sizes and indexes.1
get, size, and print should be const.  Moreover, get should
return a const T&amp;.  In fact, get and set would idiomatically be
replaced by operator[].
Don't throw a const char*.  Use a dedicated exception class like
std::out_of_range instead.
Manual loops like
for (int i = 0; i &lt; m_length; i++) {
    new_arr[i] = m_arr[i];
}

are better replaced with calls to std::copy (or
std::move).
Re-allocating every time insert is called doesn't seem like a good
idea.  A better trade-off might be to append an element and then
std::rotate it to the correct position (assuming rotation
doesn't throw).
Also, print might take an std::ostream&amp; (or perhaps
std::basic_ostream&lt;Char, Traits&gt;&amp;) argument for extra flexibility.

1 As Andreas H. pointed out in the comments, this recommendation is subject to debate, since the use of unsigned arithmetic has its pitfalls.  An alternative is to use std::ptrdiff_t and std::ssize (C++20) instead.  You can write your own version of ssize as shown on the cppreference page if C++20 is not accessible.