Здравствуйте, _hum_, Вы писали:
__>с дубляжом идентификатора контейнера (который обычно немаленький, а потому смотрится громоздким). ведь так и просится __>
Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно.
Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
EP>Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно.
ладно, наверное, соглашусь. спасибо.
EP>Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так: EP>
EP>if(auto x = find_value(some_map, value))
EP>{
EP>}
EP>
да уж простую (еще и optional приплетать и разруливать возврат по ссылки и по значению)
Re[3]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, _hum_, Вы писали:
EP>>Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно. __>ладно, наверное, соглашусь.
А почему наверное? Например у std::vector итератором может быть обычный указатель — он не знает где конец
EP>>Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так: EP>>
EP>>if(auto x = find_value(some_map, value))
EP>>{
EP>>}
EP>>
__>да уж простую (еще и optional приплетать и разруливать возврат по ссылки и по значению)
Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием.
Re[4]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
EP>>>Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно. __>>ладно, наверное, соглашусь.
EP>А почему наверное? Например у std::vector итератором может быть обычный указатель — он не знает где конец
потому что сразу не очевидно, что недостающую информацию нельзя передать на этапе компиляции..
EP>>>Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так: EP>>>
EP>>>if(auto x = find_value(some_map, value))
EP>>>{
EP>>>}
EP>>>
__>>да уж простую (еще и optional приплетать и разруливать возврат по ссылки и по значению)
EP>Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием.
ну, все равно придется писать случаи для констатного и неконстантного указателя. в общем, все равно неудобно
Re[5]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, _hum_, Вы писали:
EP>>Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием. __>ну, все равно придется писать случаи для констатного и неконстантного указателя.
Не придётся, оно получится всё автоматом.
__>в общем, все равно неудобно
Что конкретно неудобно?
Re[6]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
EP>>>Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием. __>>ну, все равно придется писать случаи для констатного и неконстантного указателя.
EP>Не придётся, оно получится всё автоматом.
__>>в общем, все равно неудобно
EP>Что конкретно неудобно?
что приходится писать свои функции, да еще и на каждый контейнер
Re[7]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, _hum_, Вы писали:
__>>>в общем, все равно неудобно EP>>Что конкретно неудобно? __>что приходится писать свои функции,
Так ты её напишешь один раз, можешь даже в библиотеку какую-нибудь отослать.
Впрочем я тебя понял — тебе лишь бы к чему-нибудь придраться. Если у тебя предвзято-негативное отношение к C++ — переходи на другой язык, в чём проблема-то?
__>да еще и на каждый контейнер
Почему на каждый?
Re[8]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>>>в общем, все равно неудобно EP>>>Что конкретно неудобно? __>>что приходится писать свои функции,
EP>Так ты её напишешь один раз, можешь даже в библиотеку какую-нибудь отослать. EP>Впрочем я тебя понял — тебе лишь бы к чему-нибудь придраться. Если у тебя предвзято-негативное отношение к C++ — переходи на другой язык, в чём проблема-то?
почти как "не нравится, сделай лучше" я спрашивал, почему с с++ не сделано так, как удобнее, вы ответили. все, я понял суть проблемы, и это немного сняло недовольство. спасибо.
__>>да еще и на каждый контейнер
EP>Почему на каждый?
потому что в мапе поиск ведется по ключам, запакованным в пары, а, например, в векторе, по значениям, из-за чего функция сравнения будет разной.
Re[9]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, _hum_, Вы писали:
__>почти как "не нравится, сделай лучше" я спрашивал, почему с с++ не сделано так, как удобнее, вы ответили. все, я понял суть проблемы, и это немного сняло недовольство. спасибо.
С чего вы взяли, что можно сделать удобнее? Какие критерии удобства?
__>>>да еще и на каждый контейнер EP>>Почему на каждый? __>потому что в мапе поиск ведется по ключам, запакованным в пары, а, например, в векторе, по значениям, из-за чего функция сравнения будет разной.
Поиск ведётся по ключу. Мапа — это дерево. Почитайте хотя-бы основы по структурам данных. Пригодится и не только в С++, это базовые вещи для программиста. А ещё есть такая замечательная штука, как шаблоны.
Re: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, _hum_, Вы писали:
__>>почти как "не нравится, сделай лучше" я спрашивал, почему с с++ не сделано так, как удобнее, вы ответили. все, я понял суть проблемы, и это немного сняло недовольство. спасибо.
SaZ>С чего вы взяли, что можно сделать удобнее? Какие критерии удобства?
я же привел момент неудобства — необходимо два раза писать идентификатор контейнера — один раз при вызове функции поиска, второй раз при проверке результативности поиска.
__>>>>да еще и на каждый контейнер EP>>>Почему на каждый? __>>потому что в мапе поиск ведется по ключам, запакованным в пары, а, например, в векторе, по значениям, из-за чего функция сравнения будет разной.
SaZ>Поиск ведётся по ключу. Мапа — это дерево. Почитайте хотя-бы основы по структурам данных. Пригодится и не только в С++, это базовые вещи для программиста. А ещё есть такая замечательная штука, как шаблоны.
в нашем же разговоре речь шла про написание универсальной (применимой к любому stl-контейнеру) функции.
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
const auto& c = myVeryLongContainerName;
auto it = c.find(...)
if (it != c.end())
{
...
}
2) использовать visual assist, т.к. он сразу подсказывает имя контейнера, причем именно того с которого был взят исходный итератор
подозреваю что IntelliSense тоже
3) использовать code snippets
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, rm822, Вы писали:
R>2) использовать visual assist, т.к. он сразу подсказывает имя контейнера, причем именно того с которого был взят исходный итератор R> подозреваю что IntelliSense тоже R>3) использовать code snippets
Использовать решения на стороне редактора — самые топорные варианты, и трудноподдерживаемые. К ним следует прибегать только когда другие пути отсутствуют, либо труднодоступны.
Здесь же лучше всего написать простую функцию-обёртку с требуемым интерфейсом.
Re[11]: есть ли средства от громоздкой проверки конечной позиции std-итератора
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, _hum_, Вы писали:
__>>в нашем же разговоре речь шла про написание универсальной (применимой к любому stl-контейнеру) функции.
К>Это будет не одна функция, а большое семейство. К>Для разных контейнеров. К>Для диапазонов прямых и обратных. К>Для поиска значений и предикатов.
я об этом и сказал выше — что одной универсальной не получится
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
Здравствуйте, _hum_, Вы писали:
__>я об этом и сказал выше — что одной универсальной не получится
Имя может быть одно, например через перегрузку (UPD: хотя в этом случае тут семантика разная, это не просто оптимизация).
А вот реализация разная, потому что это контейнеры разных концепций. Точнее ты можешь сделать одну универсальную реализацию, но это будет неэффективно.
Точно также как и в случае с std::advance — универсальная реализация линейная, но есть более оптимальная для более узкой категории итераторов. Другой пример — std::partition
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, _hum_, Вы писали:
__>>я об этом и сказал выше — что одной универсальной не получится
EP>Имя может быть одно, например через перегрузку. EP>А вот реализация разная, потому что это контейнеры разных концепций. Точнее ты можешь сделать одну универсальную реализацию, но это будет неэффективно. EP>Точно также как и в случае с std::advance — универсальная реализация линейная, но есть более оптимальная для более узкой категории итераторов. Другой пример — std::partition
да, все так, но речь шла про простой выход из положения,а не про написание собственной библиотеки