Всякий раз, когда вы вызываете конструктор/деструктор, вы несете затраты. Эта стоимость оправдана до тех пор, пока вы используете объект. Но не тогда, когда вы никогда не будете использовать объект. Например, взгляните на функцию ниже:

void function(int arg){
	Point point; //Object Point
	if(arg==0){
	  return;
	}
}

После входа в функцию первое, что мы делаем, — это создаем экземпляр Point, тем самым вызывая конструктор. Предположим, что arg равен нулю. Это заставит нас выйти из функции, даже не используя объект Point. Таким образом, мы понесли затраты на вызов конструктора/деструктора без всякой причины.

Поэтому вам лучше отложить определение Point до тех пор, пока вы не поймете, что оно вам понадобится. Например:

void function(int arg){
 if(arg==0){
 return;
 }

 Point point; //postpone the construction of Point
 //..continue on 
}

Как насчет того, когда вы работаете с циклами? Когда вы должны определить объект, вне цикла или внутри цикла?

Давайте рассмотрим подход A:

//Approach A: define outside loop
Point p;

for(int i=0;i<n;i++){
//use p here
}

Стоимость подхода A составляет:

  • 1 конструктор + 1 деструктор + n присваиваний

Теперь давайте взглянем на Подход B:

//Approach B: define inside loop

for(int i=0;i<n;i++){
Point p;
//use p here
}

Стоимость подхода B составляет:

  • n конструкторов + n деструкторов

В своей книге Effective C++ Скотт Мейерс утверждает, что в случаях, когда вы знаете, что присваивание стоит меньше, чем пара конструктор/деструктор, подход A более эффективен. Таким образом, если вы не знаете, что (1) присваивание менее затратно, чем пара конструктор/деструктор, и (2) вы имеете дело с чувствительной к производительности частью кода, вам следует по умолчанию использовать подход B.

Итак, вот совет:

Откладывайте строительство объектов до тех пор, пока они действительно не понадобятся.

Получите больше советов по разработке на haroldserrano.com