- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
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()); //черная магия :)
}
}
ForEveR 08.09.2014 18:02 # +2
Так конечно будет понятнее, но все же, причем тут черная магия в исходном тексте?
bormand 08.09.2014 18:32 # +2
Да ничего особо сложного. Для каждого из параметров смотрит, требует ли он особой (specific) обработки, и если да - заменяет значение на результат его обработки соответствующей функцией.
absolut 11.09.2014 07:09 # 0
bormand 11.09.2014 08:24 # 0
Всем похуй на эти копейки, ибо дальше еще хуже - 2 раза один и тот же ключ в мапе ищут (contains() и value()).
absolut 11.09.2014 08:55 # 0
bormand 11.09.2014 09:31 # 0
А т.к., скорее всего, это загрузка конфига при старте проги - то на оптимизации вообще насрать...
absolut 11.09.2014 09:49 # 0
поэтому добавим ещё туеву хучу нагрузочных циклов
bormand 11.09.2014 09:52 # +2
3.14159265 11.09.2014 09:58 # +1
Мелочь.
В большинстве случаев вменяемый компилятор высрет побайтово идентичный код.
bormand 11.09.2014 10:04 # +1
Ага. Потому что в 99.999% случаев постинкремент запилен как backup - increment - return copy, компилятор видит, что копия никому нахер не сдалась, и выпиливает ее вместе с бекапом.
Вся эта история чем-то напоминает пыхооптимизации: ' быстрее ", интерполяция быстрее подготовленных запросов и т.п.
roman-kashitsyn 11.09.2014 10:07 # 0
Если копирование имеет побочные эффекты, как он сможет это сделать?
Встречаются довольно жирные итераторы с нетривиальным состоянием внутри.
bormand 11.09.2014 10:24 # 0
Т.е., например, i/o итератор, который в себе хранит всю текущую запись? Ну ок, резонно.
P.S. Хотя из побочных действий при копировании тут будет разве что выделение памяти из кучи.
roman-kashitsyn 11.09.2014 10:31 # 0
Да и реализация конструктора копирования может быть скрыта от компилятора, если итератор не шаблонный.
bormand 11.09.2014 10:33 # 0
Я про такой случай - вдруг итератор выделил память под некие структуры данных в своём конструкторе, а в инкременте просто помещает в них новые значения. Вот такой итератор действительно дороговато копировать.
roman-kashitsyn 11.09.2014 10:37 # 0
Удивительно, но говорю о том же самом. Так работает, например, std::istream_iterator<T>.
bormand 11.09.2014 10:39 # 0
> А мы хотим выделять память из кучи на каждом инкременте?
А, всё, я не так распарсил эту фразу. Подумал, что она относится к внутренней логике самого инкремента, а не к последствиям копирования в постинкременте.
bormand 11.09.2014 10:40 # +2
bormand 11.09.2014 10:36 # 0
roman-kashitsyn 11.09.2014 10:41 # 0
bormand 11.09.2014 10:51 # 0
Я пару раз передавал по неконстантной ссылке.
roman-kashitsyn 11.09.2014 11:04 # 0
В стандартной библиотеке везде.
bormand 11.09.2014 12:31 # 0