Частое создание экземпляров

[alexeyvanzhula]

Пример:
в функции paintEvent постоянно создают, например, новый QPoint для использования в каких то опирациях рисования.
Если я знаю что QPoint в программе будет использоваться очень часто, почему бы мне не создать в конструкторе один экземпляр QPoint и пользоваться им везде, используя методы setX\Y для новых значений. Зачем в часто вызываемых методах создавать его заново?

[Пантер]

А ты уверен, что создать экземпляр QPoint будет медленнее вызова двух методов?

[alexeyvanzhula]

А ты уверен, что создать экземпляр QPoint будет медленнее вызова двух методов?

а если вызывать только один метод постоянно (не важно какого типа) тогда вероятнее всего что создание экземпляра каждый раз накладнее чем вызов метода?

[Пантер]

Скорее всего, накладнее, но различие настолько мизерное, что тут даже не на спичках экономия. Это все преждевременная оптимизация, что есть зло.

[Igors]

а если вызывать только один метод постоянно (не важно какого типа) тогда вероятнее всего что создание экземпляра каждый раз накладнее чем вызов метода?

В случае QPoint создание не медленнее, а может и быстрее присваивания (т.к. подаются сразу 2 аргумента).

.. почему бы мне не создать в конструкторе один экземпляр QPoint и пользоваться им везде, используя методы setX\Y для новых значений. Зачем в часто вызываемых методах создавать его заново?

Такой экземпляр делает класс "not thread-safe", т.е. он не сможет работать корректно при параллельном выполнении. Хоть для paint это и не актуально, но в общем случае плохо

[alexeyvanzhula]

Такой экземпляр делает класс "not thread-safe", т.е. он не сможет работать корректно при параллельном выполнении. Хоть для paint это и не актуально, но в общем случае плохо

почему?

[ammaximus]

Есть несколько правил, которыми следует пользоваться в таких ситуациях.
1. Переменные должны быть видимы только в месте использования. То есть нет смысла засорять пространство класса, если переменная используется только в одной функции и совсем не нужна снаружи. Такой подход позволяет минимизировать количество ошибок и снизить связность кода.
2. Оптимизировать следует только то, что действительно нуждается в оптимизации. Если функция не тормозит на целевой платформе ничего делать не нужно.
3. Понятность кода важнее скорости работы. В настоящую эпоху важнее сделать код понятным, а следовательно снизить вероятность ошибок. Быстрая не правильно работающая программа никому не нужна.
4. С опытом появляется набор подходов, которые косвенно будут оптимизировать код. Например, не очень хорошо в пэйнт эвенте читать какието параметры из файла. Но вы уже используете конструктор и инициализируетесь там и это логично, и когда вы вернетесь к этому коду в первую очередь полезете именно в кокструктор. Просто потомучто это общепринятый подход. Выносить поинт не общепринято и при возвращении к коду у вас будут трудности.
5. Самое важное - то что вы написали в программе никогда не выполняется процессором дословно. Компиляторы настолько умны, что сами в состоянии сообразить когда вызывать конструктор а когда нет. И они закладываются на общепринятые принципы написания кода - если мудрить можно наоборот все испортить -компилятор вас не поймет и не выполнит автооптимизацию которая в разы круче всего, что можно наваять руками.
6. И наконец то что вы предлагаете не оптимально. Конструктор структуры QPoint выполняет те же операции присваивания, но делает это на стеке который точно в близком кеше или вообще в активных регистрах процессора, а за вашим QPoint придется лезть в оперативку грузить оттуда страницу и т.п.
Кстати, размер структуры 8 байт, так что вообще стоило ли заводить этот разговор? :-)

[alexeyvanzhula]

Кстати, размер структуры 8 байт, так что вообще стоило ли заводить этот разговор? :-)

Наверное стоило, потому что я кое что узнал
Спасибо !!!