есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 28.07.16 11:28
Оценка: +1
ну, честное слово, ну, задолбало уже писать:
const auto it = MyVerySpecialFoosMap.find();

if(it != MyVerySpecialFoosMap)
{
  <...>
};

с дубляжом идентификатора контейнера (который обычно немаленький, а потому смотрится громоздким). ведь так и просится

if(!it.is_at_the_end())
{
  <...>
};
Re: есть ли средства от громоздкой проверки конечной позиц
От: Evgeny.Panasyuk Россия  
Дата: 28.07.16 11:42
Оценка:
Здравствуйте, _hum_, Вы писали:

__>с дубляжом идентификатора контейнера (который обычно немаленький, а потому смотрится громоздким). ведь так и просится

__>
__>if(!it.is_at_the_end())
__>{
__>  <...>
__>};
__>


Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно.
Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так:
if(auto x = find_value(some_map, value))
{
}

Либо как вариант:
find_value(some_map, value, [](auto &x)
{
});
Отредактировано 28.07.2016 11:44 Evgeny.Panasyuk . Предыдущая версия .
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 28.07.16 11:57
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


EP>Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно.


ладно, наверное, соглашусь. спасибо.

EP>Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так:

EP>
EP>if(auto x = find_value(some_map, value))
EP>{
EP>}
EP>

да уж простую (еще и optional приплетать и разруливать возврат по ссылки и по значению)
Re[3]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: Evgeny.Panasyuk Россия  
Дата: 28.07.16 12:09
Оценка:
Здравствуйте, _hum_, Вы писали:

EP>>Итератор может быть легковесным, и не знать где конец. Поэтому одного итератора недостаточно.

__>ладно, наверное, соглашусь.

А почему наверное? Например у std::vector итератором может быть обычный указатель — он не знает где конец

EP>>Можешь сделать простую функцию-обёртку, возвращающую optional, тогда можно писать так:

EP>>
EP>>if(auto x = find_value(some_map, value))
EP>>{
EP>>}
EP>>

__>да уж простую (еще и optional приплетать и разруливать возврат по ссылки и по значению)

Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием.
Re[4]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 28.07.16 12:25
Оценка:
Здравствуйте, 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-итератора?
От: Evgeny.Panasyuk Россия  
Дата: 28.07.16 12:36
Оценка: +1
Здравствуйте, _hum_, Вы писали:

EP>>Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием.

__>ну, все равно придется писать случаи для констатного и неконстантного указателя.

Не придётся, оно получится всё автоматом.

__>в общем, все равно неудобно


Что конкретно неудобно?
Re[6]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 28.07.16 12:46
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


EP>>>Вместо optional можешь использовать обычный указатель, либо второй вариант с замыканием.

__>>ну, все равно придется писать случаи для констатного и неконстантного указателя.

EP>Не придётся, оно получится всё автоматом.


__>>в общем, все равно неудобно


EP>Что конкретно неудобно?


что приходится писать свои функции, да еще и на каждый контейнер
Re[7]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: Evgeny.Panasyuk Россия  
Дата: 28.07.16 12:52
Оценка: :)
Здравствуйте, _hum_, Вы писали:

__>>>в общем, все равно неудобно

EP>>Что конкретно неудобно?
__>что приходится писать свои функции,

Так ты её напишешь один раз, можешь даже в библиотеку какую-нибудь отослать.
Впрочем я тебя понял — тебе лишь бы к чему-нибудь придраться. Если у тебя предвзято-негативное отношение к C++ — переходи на другой язык, в чём проблема-то?

__>да еще и на каждый контейнер


Почему на каждый?
Re[8]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 28.07.16 13:08
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


__>>>>в общем, все равно неудобно

EP>>>Что конкретно неудобно?
__>>что приходится писать свои функции,

EP>Так ты её напишешь один раз, можешь даже в библиотеку какую-нибудь отослать.

EP>Впрочем я тебя понял — тебе лишь бы к чему-нибудь придраться. Если у тебя предвзято-негативное отношение к C++ — переходи на другой язык, в чём проблема-то?
почти как "не нравится, сделай лучше" я спрашивал, почему с с++ не сделано так, как удобнее, вы ответили. все, я понял суть проблемы, и это немного сняло недовольство. спасибо.

__>>да еще и на каждый контейнер


EP>Почему на каждый?


потому что в мапе поиск ведется по ключам, запакованным в пары, а, например, в векторе, по значениям, из-за чего функция сравнения будет разной.
Re[9]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: SaZ  
Дата: 28.07.16 14:53
Оценка:
Здравствуйте, _hum_, Вы писали:

__>почти как "не нравится, сделай лучше" я спрашивал, почему с с++ не сделано так, как удобнее, вы ответили. все, я понял суть проблемы, и это немного сняло недовольство. спасибо.


С чего вы взяли, что можно сделать удобнее? Какие критерии удобства?

__>>>да еще и на каждый контейнер

EP>>Почему на каждый?
__>потому что в мапе поиск ведется по ключам, запакованным в пары, а, например, в векторе, по значениям, из-за чего функция сравнения будет разной.

Поиск ведётся по ключу. Мапа — это дерево. Почитайте хотя-бы основы по структурам данных. Пригодится и не только в С++, это базовые вещи для программиста. А ещё есть такая замечательная штука, как шаблоны.
Re: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: B0FEE664  
Дата: 28.07.16 15:03
Оценка: 1 (1)
Здравствуйте, _hum_, Вы писали:

__>ну, честное слово, ну, задолбало уже писать:

  Скрытый текст
__>
__>const auto it = MyVerySpecialFoosMap.find();

__>if(it != MyVerySpecialFoosMap)
__>{
__>  <...>
__>};
__>

__>с дубляжом идентификатора контейнера (который обычно немаленький, а потому смотрится громоздким). ведь так и просится

__>
__>if(!it.is_at_the_end())
__>{
__>  <...>
__>};
__>

И тут я понял, зачем С++17:
auto Find(const auto& oWhere, const auto& rWhat)
{
    return {oWhere.find(rWhat), oWhere.end()};
}

int main()
{
    std::map<std::string, int> oMap = { {"a", 1}, {"b", 2} };
    
    if ( const auto [it, itEnd] = Find(oMap, "a")); it != itEnd )
    {
    
    }
    return 0;
}

И каждый день — без права на ошибку...
Re[10]: есть ли средства от громоздкой проверки конечной позиции std-итератора
От: _hum_ Беларусь  
Дата: 28.07.16 15:09
Оценка:
Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, _hum_, Вы писали:


__>>почти как "не нравится, сделай лучше" я спрашивал, почему с с++ не сделано так, как удобнее, вы ответили. все, я понял суть проблемы, и это немного сняло недовольство. спасибо.


SaZ>С чего вы взяли, что можно сделать удобнее? Какие критерии удобства?


я же привел момент неудобства — необходимо два раза писать идентификатор контейнера — один раз при вызове функции поиска, второй раз при проверке результативности поиска.

__>>>>да еще и на каждый контейнер

EP>>>Почему на каждый?
__>>потому что в мапе поиск ведется по ключам, запакованным в пары, а, например, в векторе, по значениям, из-за чего функция сравнения будет разной.

SaZ>Поиск ведётся по ключу. Мапа — это дерево. Почитайте хотя-бы основы по структурам данных. Пригодится и не только в С++, это базовые вещи для программиста. А ещё есть такая замечательная штука, как шаблоны.


в нашем же разговоре речь шла про написание универсальной (применимой к любому stl-контейнеру) функции.
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 28.07.16 15:21
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>И тут я понял, зачем С++17:

BFE>
[cut=code]
BFE>auto Find(const auto& oWhere, const auto& rWhat)
BFE>{
BFE>    return {oWhere.find(rWhat), oWhere.end()};
BFE>}

BFE>int main()
BFE>{
BFE>    std::map<std::string, int> oMap = { {"a", 1}, {"b", 2} };
    
BFE>    if ( const auto [it, itEnd] = Find(oMap, "a")); it != itEnd )
BFE>    {
    
BFE>    }
BFE>    return 0;
BFE>}
BFE>

[/cut]
BFE>

кстати, интересный вариант
Re: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: rm822 Россия  
Дата: 29.07.16 10:31
Оценка:
есть 3 очевидных решения
1)
 const auto& c = myVeryLongContainerName;
 auto it = c.find(...)
 if (it != c.end())
 {
  ...
 }

2) использовать visual assist, т.к. он сразу подсказывает имя контейнера, причем именно того с которого был взят исходный итератор
подозреваю что IntelliSense тоже

3) использовать code snippets
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: Evgeny.Panasyuk Россия  
Дата: 29.07.16 10:42
Оценка: :)
Здравствуйте, rm822, Вы писали:

R>2) использовать visual assist, т.к. он сразу подсказывает имя контейнера, причем именно того с которого был взят исходный итератор

R> подозреваю что IntelliSense тоже
R>3) использовать code snippets

Использовать решения на стороне редактора — самые топорные варианты, и трудноподдерживаемые. К ним следует прибегать только когда другие пути отсутствуют, либо труднодоступны.
Здесь же лучше всего написать простую функцию-обёртку с требуемым интерфейсом.
Re[11]: есть ли средства от громоздкой проверки конечной позиции std-итератора
От: Кодт Россия  
Дата: 29.07.16 11:06
Оценка:
Здравствуйте, _hum_, Вы писали:

__>в нашем же разговоре речь шла про написание универсальной (применимой к любому stl-контейнеру) функции.


Это будет не одна функция, а большое семейство.
Для разных контейнеров.
Для диапазонов прямых и обратных.
Для поиска значений и предикатов.

Кстати, вместо optional или пары (найдено, конец) проще всего возвращать голый указатель.
template<class I>
auto ptr_from_iter(I i, I e) { return i == e ? nullptr : &*i; }

template<class I, class V>
auto find_from_to(I b, I e, V&& v) { return ptr_from_iter(std::find(b, e, v), e); }

// для контейнеров, у которых есть член find
template<class C, class V>
auto find_in(C&& c, V&& v) { return ptr_from_iter(c.find(v), end(c)); }

// для контейнеров, у которых find внешний
template<class C, class V>
auto find_over(C&& c, V&& v) { return find_from_to(begin(c), end(c), v); }

int main() {
  std::map<int,string> the_map = { {1,"hello"} };
  std::vector<int> the_vec = {3,5,1};

  for (int i=0; i<2; ++i) {
    std::cout << "looking for " << i << ":" << std::endl;
    if(auto p = find_in(the_map, i)) {
      std::cout << p->first << ":" << p->second << std::endl;
    } else {
      std::cout << "not found" << std::endl;
    }

    if(auto p = find_over(the_vec, i)) {
      std::cout << *p << std::endl;
    } else {
      std::cout << "not found" << std::endl;
    }
  }
}
Перекуём баги на фичи!
Re[12]: есть ли средства от громоздкой проверки конечной позиции std-итератора
От: _hum_ Беларусь  
Дата: 29.07.16 11:31
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, _hum_, Вы писали:


__>>в нашем же разговоре речь шла про написание универсальной (применимой к любому stl-контейнеру) функции.


К>Это будет не одна функция, а большое семейство.

К>Для разных контейнеров.
К>Для диапазонов прямых и обратных.
К>Для поиска значений и предикатов.

я об этом и сказал выше — что одной универсальной не получится
Re[2]: есть ли средства от громоздкой проверки конечной позиции std-итератора?
От: _hum_ Беларусь  
Дата: 29.07.16 11:34
Оценка:
Здравствуйте, rm822, Вы писали:

R>есть 3 очевидных решения

R>1)
R>
R> const auto& c = myVeryLongContainerName;
R> auto it = c.find(...)
R> if (it != c.end())
R> {
R>  ...
R> }
R>

не пойдет, так как вводится новый идентификатор "с", что замусоривает как текст, так и семантику кода.
Re[13]: есть ли средства от громоздкой проверки конечной п
От: Evgeny.Panasyuk Россия  
Дата: 29.07.16 11:50
Оценка:
Здравствуйте, _hum_, Вы писали:

__>я об этом и сказал выше — что одной универсальной не получится


Имя может быть одно, например через перегрузку (UPD: хотя в этом случае тут семантика разная, это не просто оптимизация).
А вот реализация разная, потому что это контейнеры разных концепций. Точнее ты можешь сделать одну универсальную реализацию, но это будет неэффективно.
Точно также как и в случае с std::advance — универсальная реализация линейная, но есть более оптимальная для более узкой категории итераторов. Другой пример — std::partition
Отредактировано 29.07.2016 19:22 Evgeny.Panasyuk . Предыдущая версия .
Re[14]: есть ли средства от громоздкой проверки конечной позиции std-итератора
От: _hum_ Беларусь  
Дата: 29.07.16 12:03
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, _hum_, Вы писали:


__>>я об этом и сказал выше — что одной универсальной не получится


EP>Имя может быть одно, например через перегрузку.

EP>А вот реализация разная, потому что это контейнеры разных концепций. Точнее ты можешь сделать одну универсальную реализацию, но это будет неэффективно.
EP>Точно также как и в случае с std::advance — универсальная реализация линейная, но есть более оптимальная для более узкой категории итераторов. Другой пример — std::partition

да, все так, но речь шла про простой выход из положения,а не про написание собственной библиотеки
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.