И еще, связанный вопрос про std::set.
Почему оставлена возможность изменить элемент set'а? Это для компаратора по части элемента?
Если в простом примере поменять элемент, то контейнер умирает:
Если бы разыменование итератора возвращало константную ссылку, то такой проблемы бы не возникало.
При этом не константный итератор позволял бы удалять и вставлять элементы.
В общем, как с ключом в std::map.
Т.е. правильно ли я понимаю, что в map элемент явно разделяется на ключ и нагрузку,
а в set элемент не рассматривается как неизменный ключ?
Здравствуйте, qaz77, Вы писали:
Q>И еще, связанный вопрос про std::set. Q>Почему оставлена возможность изменить элемент set'а? Это для компаратора по части элемента? Q>Если в простом примере поменять элемент, то контейнер умирает: Q>
Q>Если бы разыменование итератора возвращало константную ссылку, то такой проблемы бы не возникало.
А если изменения ключа не приводит к изменению порядка, то зачем платить больше?
Q>При этом не константный итератор позволял бы удалять и вставлять элементы.
У вставки/удаления сложность не константная.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, qaz77, Вы писали:
Q>Вразумите, как можно алгоритмом stl выполнить действие над контейнером с модифицирующим доступом к элементам.
<skip> Q>Получается ровно реализация std::for_each, но для него запрещена модификация элемента. Q>Кто-нибудь знает из каких соображений?
кривая реализация STL!?
возможность можифицировать элементы во время for_eachопределяется типом итератора: const не-const...
Q>И еще, связанный вопрос про std::set. Q>Почему оставлена возможность изменить элемент set'а? Это для компаратора по части элемента?
изменение элемента в set'e может привести к необходимости изменить порядок элементов -- поэтому set::iterator по факту тоже самое что и set::const_iterator
(об этом разумеется пишут авторы книжек про С++\STL)
Q>Если в простом примере поменять элемент, то контейнер умирает: Q>
Q>В общем, как с ключом в std::map. Q>Т.е. правильно ли я понимаю, что в map элемент явно разделяется на ключ и нагрузку, Q>а в set элемент не рассматривается как неизменный ключ?
Здравствуйте, Vain, Вы писали:
Q>>Если бы разыменование итератора возвращало константную ссылку, то такой проблемы бы не возникало. V>А если изменения ключа не приводит к изменению порядка, то зачем платить больше?
Тут все в компайл тайм. Чего платить-то?
А вот в ногу выстрелить шанса меньше. Как с it->first в std::map.
Q>>При этом не константный итератор позволял бы удалять и вставлять элементы. V>У вставки/удаления сложность не константная.
Это-то здесь причем.
Я имею в виду, что у iterator операторы * и -> возвращали бы константную ссылку, как у const_iterator.
При этом, для iterator можно было бы звать erase и т.п., как обычно.
Здравствуйте, qaz77, Вы писали:
Q>Вразумите, как можно алгоритмом stl выполнить действие над контейнером с модифицирующим доступом к элементам. Q>Т.е. что-то вроде этого: Q>
Q>void trim(std::string& str);
Q>void foo()
Q>{
Q> std::vector<std::string> v;
Q> //...
Q> for (std::vector<std::string>::iterator it = v.begin(); it != v.end(); ++it)
Q> {
Q> trim(*it);
Q> }
Q>}
Q>
Q>Получается ровно реализация std::for_each, но для него запрещена модификация элемента. Q>Кто-нибудь знает из каких соображений?
Здравствуйте, zaufi, Вы писали:
Z>возможность можифицировать элементы во время for_eachопределяется типом итератора: const не-const...
Да, что-то я туплю. C std::for_each можно менять элементы.
Смутила фраза в старом MSDN:
template<class InIt, class Fun>
Fun for_each(InIt first, InIt last, Fun f);
The template function evaluates f(*(first + N)) once for each N in the range [0, last - first).
It then returns f. The call f(*(first + N)) must not alter *(first + N).
Z>изменение элемента в set'e может привести к необходимости изменить порядок элементов -- поэтому set::iterator по факту тоже самое что и set::const_iterator Z>(об этом разумеется пишут авторы книжек про С++\STL)
Ну не совсем то же. const_iterator в erase и т.п. не пойдет...
Z>вообще говоря это не должно компилиться! Z>если у тебя это не так, значит твой STL или компилятор
VS 2008
Здравствуйте, qaz77, Вы писали:
Q>>>Если бы разыменование итератора возвращало константную ссылку, то такой проблемы бы не возникало. V>>А если изменения ключа не приводит к изменению порядка, то зачем платить больше? Q>Тут все в компайл тайм. Чего платить-то? Q>А вот в ногу выстрелить шанса меньше. Как с it->first в std::map.
Потому-что изменения ключа не обязательно ломает внутренние структуры, это вообще-то зависит от реализации.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, Valen, Вы писали:
V>>Стесняюсь показаться ламером, но http://ideone.com/wo9Z6 Q>Вы правы, меня подвел косяк в старой майкрософтовской доке