2013-05-11 2 views
0

Например:Как программисты решают дилемму использования старых переменных вместо новых переменных?

... некоторый код

int sizeOfSomeObject = someObject.length(); 

... некоторый код, sizeOfSomeObject не нужно больше

теперь нужна другая ИНТ переменная для других действий (например, для позиция в каком-то объекте), и у меня есть дилемма: создайте новую переменную или используйте для этого размер sizeOfSomeObject. В первом случае я буду продолжать читать, но теряю производительность. Во втором случае - наоборот. Что обычно делают программисты в этой ситуации?

+4

Почему вы думаете, что потеряете производительность? В этом случае ваш компилятор почти наверняка достаточно умен, чтобы «поступить правильно». –

ответ

0

Это зависит от того, как часто такой инициализируется int. Если это не в каком-то чрезвычайно вложенном цикле, большинство (всех) программистов пойдут на первое. Кроме того, на большинстве современных языков программирования есть сборщик мусора, который очищает оставшиеся объекты.

+0

«Если это не в каком-то чрезвычайно вложенном цикле» - обратите внимание, что сегодняшние компиляторы будут достаточно умны, чтобы перемещать переменные цикла вне цикла, так что распределение не происходит при каждой итерации. – 2013-05-11 15:29:57

+0

Действительно, спасибо. –

+0

Добро пожаловать. Крошечная деталь, которая может принести большие выгоды, о ней стоит знать. – 2013-05-11 15:33:22

1

Я бы использовал разные именованные переменные для разных вещей.

С точки зрения чего-то подобного, я не думаю, что только одна переменная вызовет мощный удар производительности. На большинстве языков у вас есть возможность как-то очистить переменные от памяти, когда они больше не используются, поэтому я бы рекомендовал сделать это, чтобы код что-то означал для вас или других, когда вы читаете это позже.

4

В первом случае я сохраню читаемость, но потеряю производительность. Во втором случае - наоборот.

Вы так оценили его? Я подозреваю, что нет, вы этого не сделали. Большинство современных компиляторов делают много агрессивного анализа во время распределения регистров, поэтому, если оптимизатор видит, что есть переменная, которая больше не используется, но есть новая переменная того же типа, она просто объединит две переменные в одну и ту же область памяти или процессорный регистр. Не нужно беспокоиться о штрафах за производительность.


И вообще, не делайте преждевременной оптимизации (что это такое). В 90% случаев читаемость важнее, чем «производительность».

В общем, сделайте новую переменную с соответствующим, различным описательным именем. И просто для удовольствия, скомпилируйте эту версию и версию, в которой вы использовали одно и то же имя переменной, и посмотрите на сгенерированную сборку (или байт-код или ...) - и узнайте, что они идентичны.

0

Приличный компилятор оптимизирует вашу вторую переменную, так что это не должно быть проблемой.

Тем не менее, существуют ситуации, когда переменное повторное использование имеет смысл. Например, у вас может быть какая-то переменная, которая содержит общий вывод, заполненный от вызова к внешнему API. В соответствии с контекстом и параметрами, переданными API, вы будете обрабатывать данные по-разному, но, вероятно, лучше (более читабельными и т. Д.) Повторно использовать одну и ту же переменную данных.

Например, что-то вроде этого:

void* data = getSomeData(params); 
//process data 
//change params 
data = getSomeData(params); 
//process data 
//change params 
data = getSomeData(params); 
1

В C++, вы можете использовать блоки для объектов, которые будут уничтожены, как только они больше не нужны:

void some_function() { 
    { 
     MyClass c; 
     // ... here we use c ... 
    } 
    // now c has been destroyed 
    { 
     MyClass d; 
     // ... here we use d ... 
    } 
    // now d has been destroyed 
} 

В вашем примере (с переменными int), нет причин беспокоиться о производительность. Самое худшее, что могло бы произойти, - это память для использования двух переменных вместо одного, но (i) это пренебрежимо мало, и (ii) int, вероятно, будет жить в регистре CPU. Если вы действительно беспокойство, используйте подход блока для вашего примера int.