f + b

[cd_riper]

Пожалуй, function + bind вторая, после умных указателей, по полезности и частоте использовании штука в boost. Совсем не удивительно, что это одна из тех вещей, которая из boost перекочует в стандартную библиотеку C++0x

Comments

[theiced]

>ее без труда, с помощью bind, можно превратить в вызов метода с любой сигнатурой, с замыканием любого числа параметров.

вот врёшь же. не любого - 9ти или 11ти максимум. патамуша с++ кривое гогно, да ;]

[cd_riper]

о да! :)

буст - сублимация костылизма =)))

[ext_290530]

// Очевидно, что все вызовы от модели к представлению нужно перекидывать как сообщения в message loop Qt
// путем всем известных сигналов и слотов.

Впервые такое вижу. Если идет контроль какого-либо процесса, то в Qt просто заводится таймер, по которому отображается состояние модели ( ну хорошо, можно не модели, а очереди сообщений ). Ну да, синхронизированный доступ, где надо. В каком месте применять слоты и сигналы. Это первое,

второе

/// std::find_if( first, last, bind( &X::name, _1 ) == "Peter" )

Конский код какой-то ( понятно, что из доки ) ) Во-первых кто-то когда-то поленился проиндексировать коллекцию из X (или там ключевых полей дофига, но все равно, код-то компилируемый, а значит раннее связывание и никаких тебе модификаций в рантайме), во-вторых кто-то второй поленился по-человечески написать функтор. Ну и откуда лень? inline bool f(X& x){ return x.name()=="Peter"; } - это большая цена ? Ой сомневаюсь -)

Re: буст - сублимация костылизма =)))

[cd_riper]

> В каком месте применять слоты и сигналы

// not gui context
m_view->Update(data) // что будем делать в методе Update()?

> Ну и откуда лень?

оттуда -- сильно до хера лишних действий, да еще и абсолютно лишняя функция.
и это хорошо, когда тебе надо сравнить с константой, а когда так?

std::find_if( first, last, bind( &X::name, _1 ) == name ) ?

Re: буст - сублимация костылизма =)))

[ext_290530]

// > В каком месте применять слоты и сигналы

// // not gui context
// m_view->Update(data) // что будем делать в методе Update()?

нет, ничего не делаем. Потому что нет такого вызова =) Должно быть
I) m_view->setDataRepresentationAttributesOrSomethingOfThatKind( бла-бла-бла (допустим - указатель на очередь внутренних сообщений, или контекст или что-то что содержит описание модели) )

II) Заводится Таймер Qt, в котором будет вызываться m_view->Update()
III) В View::Update() используя то, что передавали в m_view->setDataRepresentationAttributes....
и обновляемся ( _если_ View юзает что-то типа QGraphicsScene или QLabel, _иначе_ дергаем QWidget::update(), что в свою очередь приведет к вызову QWidget::paintEvent ( QPaintEvent * event ) ну и так далее

// оттуда -- сильно до хера лишних действий, да еще и абсолютно лишняя функция.
// и это хорошо, когда тебе надо сравнить с константой, а когда так?

// std::find_if( first, last, bind( &X::name, _1 ) == name ) ?

Ок, тут не о чем спорить, вопрос философский =)

Re: буст - сублимация костылизма =)))

[cd_riper]

> Должно быть

спасибо, я знаю как должно быть.

> вопрос философский

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

вопрос по производительности

[theambient]

а насколько быстро реализация boost::function? насколько я понимаю, она построена на идеях Loki::Functor ? то есть обладает полиморфным поведением?

иными словами, что будет быстрее:

сlass ClassicExtendable {
protected:
virtual void overrideme(){} // not pure!
//....
public:
void foo1()
{
// ...
extendme();
// ...
}
};

//или

сlass FunctorExtendable {
public:
boost::function extendme;
void foo1()
{
// ...
if( extendme )
{
extendme();
}
// ...
}
};

что скажете?

Re: вопрос по производительности

[cd_riper]

> то есть обладает полиморфным поведением?

ты вообще запись читал? :)

>
Единственный момент, который нужно помнить -- это полиморфное решение, и чаще всего оно менее производительно, чем решение на основе STL примитивов.

Re: вопрос по производительности

[theambient]

> Единственный момент, который нужно помнить -- это полиморфное решение, и чаще всего оно менее производительно, чем решение на основе STL примитивов.

но зато как удобно!

Re: вопрос по производительности

[cd_riper]

> но зато как удобно!

за запись читал? :)
в ней как бэ об этом и говорится

[aamonster]

Забавно - мне эта пара позарез понадобилась тоже именно для переброски вызовов в другой тред. Правда, не в qt, а в самописном коде.