Pull to refresh

Comments 10

Регулярно читаю ваши статьи, спасибо.

Позвольте спросить, а вот в функции очистки Clear, не следует ли ещё советовать присваивать NULL / nullptr? Я просто почитал поверхностно этот тред на SO, и поэтому спрашиваю вас?

Я сейчас посмотрел код в репозитории, этот блок переписали на smart pointers. Поэтому рекомендация по поводу delete, возможно уже устарела, но всё равно интересно ваше мнение.
Здравствуйте, с точки зрения человека, читающего код — это безусловно полезная практика, как минимум может защитить от двойного освобождения памяти (выстрел в ногу, защита). Но по факту такое обнуление компилятор, скорее всего, оптимизирует. А, вообще, я бы порекомендовал пользоваться умными указателми с явной семантикой владения и выделения памяти.
Спасибо за статью!

Извините, а рекомендация анализатора 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 как раз-таки не помешает, поскольку укоротит код, и позволит действительно создать подобъекты внутри вектора, а не копировать их снаружи.

В код самой игры лезть времени, к сожалению, не было, поэтому контекст не учитывал.
Спасибо за замечание, вы действительно правы, просто замена push_back на emplace_back не даст выигрыша в производительности и по моему описанию предупреждения было не особо понятно что я имел в виду. Более подробно расписал пример N1.
Также, если не хочется создавать строчку через итераторы, как я в примере, то можно позвать ещё одну перегрузку и написать, так:

list.emplace_back(str, pos1, pos2 - pos1);

В предупреждении 6, кстати, вероятно раньше вектор был статической переменной и проверкой на пустоту проверяли, нужно ли инициализировать палитру или она уже инициализирована

Можно, на будущее, попросить размещать General Analysis до блока с микрооптимизациями?
Может я не прав, но читать основные предупреждения полезнее и хотелось бы их видеть в начале статьи, а не в конце.
UFO just landed and posted this here
Sign up to leave a comment.