Комментарии 10
Регулярно читаю ваши статьи, спасибо.
Позвольте спросить, а вот в функции очистки Clear, не следует ли ещё советовать присваивать NULL / nullptr? Я просто почитал поверхностно этот тред на SO, и поэтому спрашиваю вас?
Я сейчас посмотрел код в репозитории, этот блок переписали на smart pointers. Поэтому рекомендация по поводу delete, возможно уже устарела, но всё равно интересно ваше мнение.
Позвольте спросить, а вот в функции очистки Clear, не следует ли ещё советовать присваивать NULL / nullptr? Я просто почитал поверхностно этот тред на SO, и поэтому спрашиваю вас?
Я сейчас посмотрел код в репозитории, этот блок переписали на smart pointers. Поэтому рекомендация по поводу delete, возможно уже устарела, но всё равно интересно ваше мнение.
0
Здравствуйте, с точки зрения человека, читающего код — это безусловно полезная практика, как минимум может защитить от двойного освобождения памяти (выстрел в ногу, защита). Но по факту такое обнуление компилятор, скорее всего, оптимизирует. А, вообще, я бы порекомендовал пользоваться умными указателми с явной семантикой владения и выделения памяти.
0
Спасибо за статью!
Извините, а рекомендация анализатора N1 точно поможет хоть что-то улучшить? По идее, для вызова конструкторов копирования/перемещения emplace_back и push_back ведут себя практически эквивалентно.
Функция substr вернёт rvalue, push_back практически у всех контейнеров имеет перегрузку, принимающую правостороннюю ссылку, а значит, в контейнер вставится объект всего лишь с двумя вызовами конструктора (внутри substr, и move-конструктор при запихивании объекта в список).
Ну а emplace_back примет аргумент по универсальной ссылке, которая так же преобразуется в rvalue reference, и явно вызовет конструктор копирования с этой ссылкой. То есть опять конструктор внутри substr и move-конструктор.
Попробовал проверить на вот таком вот коде, моё предположение вроде как подтверждается.
С другой стороны, если в коде из предложения N3 optionAreas — это std::vector<fheroes2::Rect>, то здесь emplace_back как раз-таки не помешает, поскольку укоротит код, и позволит действительно создать подобъекты внутри вектора, а не копировать их снаружи.
В код самой игры лезть времени, к сожалению, не было, поэтому контекст не учитывал.
Извините, а рекомендация анализатора N1 точно поможет хоть что-то улучшить? По идее, для вызова конструкторов копирования/перемещения emplace_back и push_back ведут себя практически эквивалентно.
Функция substr вернёт rvalue, push_back практически у всех контейнеров имеет перегрузку, принимающую правостороннюю ссылку, а значит, в контейнер вставится объект всего лишь с двумя вызовами конструктора (внутри substr, и move-конструктор при запихивании объекта в список).
Ну а emplace_back примет аргумент по универсальной ссылке, которая так же преобразуется в rvalue reference, и явно вызовет конструктор копирования с этой ссылкой. То есть опять конструктор внутри substr и move-конструктор.
Попробовал проверить на вот таком вот коде, моё предположение вроде как подтверждается.
С другой стороны, если в коде из предложения N3 optionAreas — это std::vector<fheroes2::Rect>, то здесь emplace_back как раз-таки не помешает, поскольку укоротит код, и позволит действительно создать подобъекты внутри вектора, а не копировать их снаружи.
В код самой игры лезть времени, к сожалению, не было, поэтому контекст не учитывал.
0
Спасибо за замечание, вы действительно правы, просто замена push_back на emplace_back не даст выигрыша в производительности и по моему описанию предупреждения было не особо понятно что я имел в виду. Более подробно расписал пример N1.
0
Также, если не хочется создавать строчку через итераторы, как я в примере, то можно позвать ещё одну перегрузку и написать, так:
list.emplace_back(str, pos1, pos2 - pos1);
0
В предупреждении 6, кстати, вероятно раньше вектор был статической переменной и проверкой на пустоту проверяли, нужно ли инициализировать палитру или она уже инициализирована
0
Можно, на будущее, попросить размещать General Analysis до блока с микрооптимизациями?
Может я не прав, но читать основные предупреждения полезнее и хотелось бы их видеть в начале статьи, а не в конце.
Может я не прав, но читать основные предупреждения полезнее и хотелось бы их видеть в начале статьи, а не в конце.
0
НЛО прилетело и опубликовало эту надпись здесь
Захотелось сразу же поиграть.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Free Heroes of might and magic 2 – open-source проект, в котором хочется участвовать