STL. Как оптимальнее сделать предикат с каким-то еще необходимыми параметрами

Сделать предикат классом с методом ()

[code] class pr:public std::unary_function<DrawObjects*, int> { int l; int h; public: pr(int l_, h_) : l(l_),h(h_){} int operator()(DrawObjects* arg) const { return arg->isNormal(l, h); } }

// использование

i_objects = find_if(m_objects.begin(), m_objects.end(), pr(L,H) );

[/code]

спасибо огромное, сейчас буду разбираться, но более менее понятно

А ещё можно использовать bind.

Да что все так привязались к этому сборищу велосипедов под названием boost? В STL есть своя реализация bind: bind1st и bind2nd. Для простых случаев этого вполне достаточно, а для более сложных реализаций лучше использовать функциональные объекты как показал nikitos

Для простых случаев этого вполне достаточно

Ну покажи как bind1st или bind2nd в данном случае использовать. Не нравиться boost::bind в C++0x есть std::bind и лямбда-выражения.

boost::bind тебя спасет

заплюсую boost::bind

З.Ы.
Лучше чем C++, boost, Qt пока ничего не создали :)

создали лисп :)

>> Лучше чем C++, boost, Qt пока ничего не создали :)

создали лисп :)

и, что, он может заменить Qt? :)

и что, Qt уже может заменить лисп ? :)

> и что, Qt уже может заменить лисп ? :)

лисп настолько «часто» используется, что его может заменить все что угодно ;)

П.С. теперь это лиспосрач-тред

я бы сделал так:

class pr : public std::binary_function<DrawObjects*, int, int>
{
  int operator()( DrawObjects *arg1, int arg2 ) const
  {
    return arg1->isNormal( arg2 );
  }
};

i_objects = find_if( m_objects.begin(), m_objects.end(), std::bind2nd( pr(), h ) );

>boost::bind тебя спасет

лишняя зависимость

У отдельных классов для функциональных объектов, помимо очевидного плюса - ясности кода, есть в ряде случаев существенный минус - отдалённость определения от точки использования. Это не есть хорошо в случае единственного использования этого класса. Приведённый тобой пример использования ИМХО менее читабелен, чем вариант с boost::bind в данном случае. Отдельный класс для функционального объекта я бы стал использовать если бы в выражении были бы вложенные вызовы, условия (boost::lambda это кошмар).

лишняя зависимость

Скопируй boost::bind в исходники проекта.

Она в хидерах. И вообще это Си++, а тут без буста довольно проблематично писать что-либо серьезное.

И вообще это Си++, а тут без буста довольно проблематично писать что-либо серьезное.

Да что вы говорите! Лично я последние 3,5 года программистской деятельности прекрасно обхожусь без этих велосипедов. P.S. Конечно, это мое ИМХО

значит ты тратишь кучу времени на написание, тестирование и сопровождение своих собственных велосипедов

В данном случае я с вами полностью согласен. Просто лично я считаю неоправданной роскошью ради такой мелочи тянуть в зависимости монструозный boost. Хотя, если он используется по всему проекту, то boost::bind вам в руки

> Просто лично я считаю неоправданной роскошью ради такой мелочи тянуть в зависимости монструозный boost.

В boost для Вашей задачи самое прямое и правильное решение — каррирование. Создание функционального объекта это уже другая вещь — замыкание.

значит ты тратишь кучу времени на написание, тестирование и сопровождение своих собственных велосипедов

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

...для Вашей задачи...

Ну начнем с того что задача не моя

Я не заблуждаюсь. Мой опыт говорит мне прямо противоположное. Если не использовать буст, то получается нагромождение велосипедов, да еще и с кучей ifdef'ов, если речь идет о кроссплатформенной разработке. Мне тоже не нравится буст, но, увы, в C++ без него очень сложно.

Подобного рода классы пишутся и тестируются за пару минут. И иногда просто невозможно использовать boost или выдирать файлы из него.

Под мелочью вы понимаете boost::bind или единичное использование? Если bind, то повторюсь - его можно скопировать в дерево исходников, man bcp за подробностями.

ну во-первых не за пару минут, а во-вторых кроме bind'а есть еще туева хуча вещей которые нужны постоянно

Под мелочью вы понимаете boost::bind или единичное использование

Единичное использование

его можно скопировать в дерево исходников

А вы сами хоть раз пытались такое провернуть? Попробуйте и получите незабываемые впечатления от прохождения этого квеста. Boost до ужаса запутан и завязан сам на себе, и нет никаких гарантий, что boost::bind не использует что-нибудь типа boost::lambda или что-то вроде того.

кроме bind'а есть еще туева хуча вещей которые нужны постоянно

Приведите пример. Может, мне просто не попадались задачи, которые без boost'а не решаются?

thread, smart_ptr, filesystem, interprocess, asio ... про мелочь типа lexical_cast и прочие строковые функции я уж не говорю

thread

pthread

smart_ptr

Включить мозг при использовании указателей

interprocess

sendmsg, signal и т.п.

filesystem, asio

Даже не знаю что там такого, чего может постоянно не хватать...

lexical_cast и прочие строковые функции

stringstream

pthread

А на альтернативной ОС?

Включить мозг при использовании указателей

Даже не смешно.

Даже не знаю что там такого, чего может постоянно не хватать...

А в стандартной библиотеке уже появились средства манипулирования путями файлов, получения информации о файлах?

stringstream

Опять не смешно. Можно выражение с использованием stringstream эквивалентное boost::lexical_cast<foo>(s)?

Далее добавлю полезную мелочь boost/cstdint.hpp и не мелочь boost::optional и boost::variant.

pthread

А на кроссплатформенность забиваем? А для того, чтобы пустить в отдельный поток метод класса будем городить свой boost::bind.

Включить мозг при использовании указателей

В больших проектах такой подход плохо работает.

sendmsg, signal и т.п.

см. пункт 1

stringstream

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

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

А на альтернативной ОС?

Нет других ОС, кроме Linux. А если серьезнее, то мне не встречались заказы промышленного уровня под другие ОС. А лабораторки студентам соседнего ВУЗА можно склепать и платформозависимыми. Видимо только Linux готов для enterprise. Чаще всего попадаются заказы для древней версии gcc и ядра 2.4

средства манипулирования путями файлов

А что это? Или проблема к имени каталога прицепить имя файла?

получения информации о файлах

man stat

эквивалентное boost::lexical_cast<foo>(s)

Я понятия не имею, что это выражение делает

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

А с каких это пор boost стал стандартом?

В общем, по всему вышесказанному могу сделать вывод, что опыта промышленного программирования у тебя маловато

Скоропалительные выводы делаете, батенька

А если серьезнее, то мне не встречались заказы промышленного уровня под другие ОС.

Это не значит, что у других их нет.

Или проблема к имени каталога прицепить имя файла? man stat

Ключевое слово - кроссплатформенно.

А с каких это пор boost стал стандартом?

С учётом того, сколько библиотек из boost'а попало в TR1, а затем в C++0x, можно говорить, что это почти стандарт.

Нет других ОС, кроме Linux.

всё, вопросов больше не имею, с вами мне всё понятно