Which is more efficient in Qt: constructors with arguments or default constructors with setters afterwards?

Question

The question is as in the title.

For example:

QPropertyAnimation *animation;
animation = new QPropertyAnimation(this, "windowOpacity", this);

or

QPropertyAnimation animation;
animation.setTargetObject(this);
animation.setPropertyName("windowOpacity");
animation.setParent(this);

Which is more efficient?

edit: though it has no significant difference unless done repeatedly, i would still like to know, i would rather want answers than opinions -as stackoverflow's guidelines suggest.

Answer 1

First, why new in the first example? I'll assume that you will create both variables on the same storage (heap / stack).

Second, this isn't a matter of Qt, it applies to C++ in general.

Without any prior knowledge about the class you are creating, you can be sure of one thing: The constructor with arguments version is at least as efficient as the setter version.

This is because, in the worst case, the constructor might look like this:

QPropertyAnimation(QObject* target, const QByteArray & prop_name, QObject* parent = 0)
{
  // members are default initializer, now explicitly set
  this->setTargetObject(target);
  this->setPropertyName(prop_name);
  this->setParent(parent)
}

However, any person that has atleast worked through a good book will write the constructor like this:

QPropertyAnimation(QObject* target, const QByteArray & prop_name, QObject* parent = 0)
  : m_target(target)
  , m_prop_name(prop_name)
  , m_parent(parent)
{
  // members explicitly initialized
}

Answer 2

At to whether the one call or three (OK, 2.5, since the first call is implicit) is "better" (ignoring the heap issue), it's worthwhile thinking about the conceptual flow of the program, and your intellectual control over it. And it's also worth considering practical issues related to coding.

On the caller side, if all the appropriate parameters are already at hand where the object is being created, then the single call makes it more obvious that, indeed, all the parameters "belong" to that object, and it's being created "in one piece". On the other hand, if using a single call means that the calling code must gather up parameters over time and then spit out a single "pent up" call, then it may be a better choice to create the object and then set the corresponding properties one at a time, as their values are developed.

And, on the callee side, there may be practical considerations. For instance, it may be that there are a dozen properties, with different uses of the object likely to use different combinations. Rather than provide dozens of different constructors, providing a single constructor (or a small number of them) combined with multiple property setters is both more efficient of programmer time and less apt to be confusing to the user of the object. But if the same combination of a relatively small number of parameters is (almost) always used then the single call is probably a better use of programmer resources.

(Of some importance here is the fact that C++ does not implement true keyword parameters, so when parameter lists get beyond 4-5 items one loses intellectual control over which parameter is which, especially if there are several forms of the constructor. In such a case using separate property setters gives the (rough) effect of keyword parameters and reduces the chance of confusion.)

Efficiency isn't always about CPU cycles. Efficient use of programmer time (including reduced time spent debugging) is, in many ways, far more important.

Answer 3

All else being equal one function call is better than 3.

Answer 4

You're comparing apples and oranges. In the first case you're constructing an object from heap, while in the second case you're constructing an object "in place", in another object or in automatic storage, so there's no heap overhead. Has nothing to do with whether you use a single constructor call or a (implicit) constructor plus two setters.