Should operations that could take some time be performed in a constructor or should the object be constructed and then initialised later.
For example when constructi
Arrays of objects will always use the default (no-arguments) constructor. There's no way around that.
There are "special" constructors: The copy constructor and operator=().
You can have a lot of constructors! Or wind up with a lot of constructors later on. Every now and then Bill out in la-la land wants a new constructor with floats rather than doubles to save those 4 lousy bytes. (Buy some RAM Bill!)
You can't call the constructor like you can an ordinary method to re-invoke that initialization logic.
You can't make the constructor logic virtual, and change it in a subclass. (Though if you are invoking an initialize() method from the constructor rather than manually, virtual methods won't work.)
.
All these things create a lot of grief when significant logic exists in the constructor. (Or at least duplication of code.)
So I, as a design choice, prefer to have minimal constructors that (optionally, depending on their parameters and the situation) invoke an initialize() method.
Depending on the circumstances, initialize() may be private. Or it may be public and support multiple invocations (e.g. re-initializing).
.
Ultimately, the choice here varies based on the situation. We have to be flexible, and consider the tradeoffs. There is no one-size-fits-all.
The approach we'd use to implement a class with single solitary instance that's using threads to talk to a piece of dedicated hardware and that has to be written in 1/2 an hour is not necessarily what we'd use to implement of a class representing mathematics on variable-precision floating-point numbers written over many months.