Array of complex numbers
The code isn't well indented, but maybe that's only your post on codereview (if it isn't, please consider indenting your code, that helps!)

There's a flaw in your code: you thought about reimplementing Array's copy constructor (which is good), but you didn't think about the copy assignment operator (which is implicitly defined).
Currently, this code is legal, and is very likely to cause undefined behaviour (that may or may not "work", you don't know, usually you'll get a segfault when it doesn't):

#include "array.hpp" // let's say you moved the array definition there

void uselessAssignment(const Array&amp; a) {
  Array b;
  b = a; // call to the implicitly defined assignment operator!
  // call to b destructor (you just deleted the memory allocated by a)
}

int main(int, char*[]) {
  complex complexNumbers[42];
  Array a(42, complexNumbers);
  uselessAssignment(a);
  a.printArray();
  return 0;
}


To correct that, either redefine the implicit assignment operator or mark it as delete.

Otherwise that seems like a fine minimal implementation, it could be improved though:
- you forgot a delete in the main, that's not extremely important because the OS will free the memory anyway when the program terminates, but that's not really clean
- i've learnt today that you should avoid prefixing your names with an underscore (stack overflow link)
- in complex.cpp you can use the initializer list to initialize the real and imaginary parts (your code works fine, i just personally find it cleaner):  

complex::complex(float a, float b) : 
real(a), 
imaginary(b) {}


- you may want your complex number to use something else than a float to store the real and imaginary parts:  

template&lt;class Real = float, class Imaginary = Real&gt;
struct complex {
  //...
  Real real;
  Imaginary imaginary;
};


- you can use std::vector to handle your array rather than allocating/deallocating yourself, it's a bit safer (you wouldn't have the problem with the copy assignment), but i often directly use dynamic allocation myself so i'm not one to talk
- rather than this:  

float a, b;
for(int i=0;i&lt;length;i++){
  cin&gt;&gt;a&gt;&gt;b;
  numbers[i]=complex(a,b);
}


you can overload operator&gt;&gt; for complex rather than using the assignment operator:

std::ostream&amp; operator&gt;&gt;(std::ostream&amp; output, complex&amp; number) {
  float a, b;
  output &gt;&gt; a &gt;&gt; b;
  number = complex(a, b);
  return output;
}
// ...
int main(int, char*[]) {
  // ...
  for(int i = 0; i &lt; length ; ++i )
    cin &gt;&gt; numbers[i];
  // ...
}


(you can also declare the operator&gt;&gt; as a friend in complex so that it can directly access its members; when the assignment isn't trivial, it may also slightly improve performance, but not here)
- of course you could define arithmetic operations on complex numbers  

...and probably other changes, but that's a rather long list already (and that also depends on what you expect from your classes).

Edit:
Ah something important if you manually handle memory in your class, you may want to define the move constructor and the move assignment operator, that may improve performance in some cases:  

Let's say you have some function which doubles each complex number in an array and returns a new array (it doesn't modify the original one), let's say its protoype is Array doubleEachComplex(Array&amp;);
If you use it like this:

Array array;
// ...
array = doubleEachComplex(array);


The compiler will:
- construct array
- do things with array (initialize it for instance)
- call doubleEachComplex
- create a fresh Array object
- call the copy assignment operator of Array (if no move assignment operator is defined)
- delete the fresh Array object (used by the copy)  

But the copy assignment operator can't modify the "source" object, so it will usually perform a deep copy. A better solution would be to swap the contents of each array since the second one is a temporary (that's what a move constructor could do).
Actually, in that case an even better solution would have been to modify it in place, but that's not always possible/a good idea.