C++ Template-Based ArrayList Implementation
Memory Allocation

This is a house built on sand, so to speak. Quite a bit of the house itself looks perfectly fine, but the foundation is completely rotten, so everything else is liable to fall over without notice.

The specific problem is using new [] to allocate storage. The problem with this is that it actually creates objects in the memory you allocate. If you're storing objects that are expensive to construct, this can impose unnecessary overhead. If you're storing objects that can't be default constructed...well, you're not storing those, because it just won't work.

The right (at least IMO) way to do this is to use the same strategy as vector does (at least by default). You allocate raw memory using operator new, and then construct objects in that raw memory using placement new. This means the unused part of the memory really is unused--i.e., it's just raw memory that doesn't contain any actual objects.

Naming

frontEndLength and backEndLength don't seem particularly descriptive, at least to me. Apparently they really mean something like "amount allocated" and "amount in use". If so, I'd change the names to reflect that more directly.

Exception Safety

Your assignment operator is written a lot like most of us typically wrote them in the '90s or so, before (for one example) Exceptional C++ was published. It has a number of problems. For example, if it ends up doing a self assignment:

ArrayList a;

// code that puts something into `a` goes here

a = a;


The self-assignment will often be somewhat indirect, such as passing the same collection as both the source and the destination of some function. Regardless of how it happens, it leads to a serious problem. It obviously shouldn't really do anything--but with your code, it destroys a. Nearly the first thing your operator= does is delete [] m_array;, so if the source and the destination are the same, you've just destroyed your source, and after that, everything breaks badly.

Quite a few people noticed this problem, so at one time it was pretty typical to see code that did something like this:

T &amp;operator=(T const &amp;r) { 
    if (this == &amp;r) // if source and dest are the same, do nothing
        return;
    // rest of the assignment goes here.
}


This fixes that particular problem, but leaves a more pernicious one. You'd typically like your assignment to either succeed entirely or fail entirely--but as it stands now, it might half-succeed, so you've lost the old contents, but gotten only part of the new contents. Worse, you aren't sure where in the copying process it was when the exception was thrown, so you don't have any way of knowing how much of the content is really valid.

One simple way of dealing with all of these is called the copy and swap idiom. It consists of creating a temporary copy of the source. Then when that's completed, you swap the destination with the temporary.

template&lt;typename T&gt;
ArrayList&lt;T&gt;&amp; ArrayList&lt;T&gt;::operator=(const ArrayList&lt;T&gt; &amp;arrayList){

    ArrayList&lt;T&gt; temp(arrayList);
    std::swap(*this, temp);
    return *this;    
}


You can also shorten this a tiny bit by using the parameter as the temporary object:

template&lt;typename T&gt;
ArrayList&lt;T&gt;&amp; ArrayList&lt;T&gt;::operator=(ArrayList&lt;T&gt; arrayList){

    std::swap(*this, arrayList);
    return *this;    
}


Either way, if an exception is thrown during the copying process, the temporary is never created, and the swap never happens. The original stays exactly as it was. We normally expect (and typically enforce) that the swap can't throw any exceptions (pretty trivial in this case, because all it's doing is copying pointers and ints around).

Once that's done, the temporary gets destroyed, releasing the memory that was previously used by the destination object.

Of course, there are other ways to write an exception-safe assignment operator--this is just one that's simple, well-known and idiomatic.

Expansion factor

Right now, when you run out of space, you multiply the size by two. That's a fairly reasonable approach, but there's a theoretical argument to be made in favor of making the expansion factor less than or equal to the golden mean. I wrote a little more about it in an earlier reply.