Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+54
Exchange::Params pars = rawParams;
for(Exchange::Params::const_iterator i = rawParams.constBegin(); i!= rawParams.constEnd(); i++){
LOGN() << "Work with " << i.key() << "=" << i.value();
if(m_specific.contains(i.key())){
pars[i.key()] =
(this->*m_specific.value(i.key())) (i.value()); //черная магия :)
}
}
Наследие из большого рабочего проекта.
Чтобы сохранить ясность ума на весь день решил не пытаться понять что оно делает.
Запостил: 
FlySnake,
08 Сентября 2014
Follow us!
Так конечно будет понятнее, но все же, причем тут черная магия в исходном тексте?
Да ничего особо сложного. Для каждого из параметров смотрит, требует ли он особой (specific) обработки, и если да - заменяет значение на результат его обработки соответствующей функцией.
Всем похуй на эти копейки, ибо дальше еще хуже - 2 раза один и тот же ключ в мапе ищут (contains() и value()).
А т.к., скорее всего, это загрузка конфига при старте проги - то на оптимизации вообще насрать...
поэтому добавим ещё туеву хучу нагрузочных циклов
Мелочь.
В большинстве случаев вменяемый компилятор высрет побайтово идентичный код.
Ага. Потому что в 99.999% случаев постинкремент запилен как backup - increment - return copy, компилятор видит, что копия никому нахер не сдалась, и выпиливает ее вместе с бекапом.
Вся эта история чем-то напоминает пыхооптимизации: ' быстрее ", интерполяция быстрее подготовленных запросов и т.п.
Если копирование имеет побочные эффекты, как он сможет это сделать?
Встречаются довольно жирные итераторы с нетривиальным состоянием внутри.
Т.е., например, i/o итератор, который в себе хранит всю текущую запись? Ну ок, резонно.
P.S. Хотя из побочных действий при копировании тут будет разве что выделение памяти из кучи.
Да и реализация конструктора копирования может быть скрыта от компилятора, если итератор не шаблонный.
Я про такой случай - вдруг итератор выделил память под некие структуры данных в своём конструкторе, а в инкременте просто помещает в них новые значения. Вот такой итератор действительно дороговато копировать.
Удивительно, но говорю о том же самом. Так работает, например, std::istream_iterator<T>.
> А мы хотим выделять память из кучи на каждом инкременте?
А, всё, я не так распарсил эту фразу. Подумал, что она относится к внутренней логике самого инкремента, а не к последствиям копирования в постинкременте.
Я пару раз передавал по неконстантной ссылке.
В стандартной библиотеке везде.