Simple array implementation without bounds-checking

@Martin (in particular) has already given some excellent advice on a number of points, but I think there are a few more that are worth mentioning.

First of all, you've used the thrice-accursed array new expression to allocate your memory. Although this works (for a sufficiently loose definition of "works") it's not ideal, at least in my opinion.

I'd prefer to use ::operator new to allocate "raw" memory, and then using placement new to copy objects into the array.

Second, you've provided both an explicit constructor to create uninitialized storage, and an two-parameter constructor to create an Array initialized to a specified value. I think I'd prefer to condense the two into a single constructor with a default argument for the initial value, so you can never (even accidentally) create an Array of uninitialized data.

Third, if (for whatever reason) the user's copy ctor throws an exception while we're initializing our data, we want to ensure that we destroy (only) the objects we've created. Incorporating those, we end up with a ctor something like this:

template <class T>
Array<T>::Array(size_t init_size, const T& init_value) : 
    arr((T *)::operator new(init_size * sizeof(T))),
{
    for (size = 0; size<init_size; ++size)
        new(arr+size) T(init_value);
}

Note that instead of a local variable to walk through the array and initialize the values, we use size, so if an exception got thrown during the loop, size will contain a count of the items we successfully initialized. Of course, we need to modify the copy ctor to match:

template <class T>
Array<T>::Array(const Array &original) :
    arr((T *)::operator new(original.size * sizeof(T))),
{
    for (size = 0; size < original.size; ++size) 
        new(arr+size) T(original.arr[size]);
}

Then in our dtor, we can make use of that to destroy exactly/only the objects that were successfully constructed. To fit normal conventions, we destroy those in reverse order of creation:

template <class T>
Array<T>::~Array() {
    for (size_t i=size+1; i>0; --i)
        arr[i-1].~T();
    ::operator delete(arr);
}

To go with this, you (of course) need to modify your class definition to match:

template <class T>
class Array {
    T* arr;
    size_t size;
public:
    explicit Array(size_t, const T& init_value = T());
    Array(const Array&);
    ~Array();
    T& operator[] (size_t);
    Array& operator= (Array);
};

One last minor detail: you had your dtor marked as virtual, but since the class contains no other virtual functions, it doesn't seem to be particularly suited to use as a base class. That being the case, I've made the dtor non-virtual.

The other thing I think I'd do if I were writing a class like this would be to add enough for it to act as a container, as that's defined by the standard (define an iterator type, value_type, begin() and end() that return iterators, etc.)

Seeing as you provide operator[], you do not need to make operator<< a friend: you can be fairly certain that operator[] will be inlined, anyway (although you should provide a const version of it, as someone suggested).

Personally, I would use a scoped pointer for arr in order to make it more exception-safe (with NDEBUG enabled, it should not cause any runtime overhead). (The copy-and-swap idiom works for this, too.)

By the way, I'm guessing your operator[] taking a T was a typo -- it should take size_t, as should pretty much everything that currently takes int.

I don't see an issue with your getVal and setVal functions -- they do exactly the same thing as operator[], and are just a more verbose way of writing things out (more normal is an at function that does out-of-bounds checking and returns a reference, but not a big deal).

I wouldn't call your class Array, as this, in my mind, associates with things of a compile-time size -- at least DynArray would be more accurate.

Finally, a function that would be trivial to implement is size, and I think the lack of it could be very troublesome.

Any reason why you pass integers as const references - it will merely slow down your code, and possible confuse the reader, for no benefit.

I'm rusty on templates, so I could be wrong, but doesn't

  Array(const Array&);

Allow you to try to construct an Array from an Array - shouldn't it be

  Array(const Array<T>&);

Likewise for assignment operator.

Just a couple of thoughts off the top of my head on a Sunday evening.