Паттерн наблюдатель

[Old]

Вот, вместо скромной ф-ции мы уже соорудили целый класс

Конечно, мы же здесь на C++ пишем, а это объектно-ориентированный язык (обратите внимание на выделенное слово).

А ведь использующих индикатор много десятков - и что, все их переводить в такие классы? Ну это просто нереально, да и выглядит совсем уж глупо  . Кстати QObject наверное нужен если есть сигналы.

Это выглядит глупо только для вас. А QObject не нужен, мы это уже два или три раза выше прошли. Вы уже забыли?

И, что интересно, никакого выгодного ф-ционала этим не достигается.

Достигается.

Скорее наоборот - хоть тот же m_canсel, куда легче было спросить его у интерфейса индикатора в любой момент.

Нет, это глупо, что-то спрашивать в асинхронной системе.

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

Сигналов старт может прийти несколько, если работа выполняется в несколько потоков и никаких новых сигналов, кроме описанных мной ранее для FileLoader не понадобиться.

А finished вообще не наблюдаю, как и отработку исключения.

А сможете сами догадаться, куда вставить emit finished?

Из этого вовсе не следует что "слот/сигнал = плохо", просто здесь он неуместен.

Из этого ничего не следует, потому что ни одной проблемы вы привести так и не смогли.

Во всяком случае я думал примерно так (пока не дошло др дела/реализации  )

Так у вас получилось или вы еще реализуете? 

[Igors]

И не будет. Индикатор сам должен решать, как часто ему апдейтиться. Например, каждый десятый сигнал, или 2 раза в секунду - это с загрузчиком никак не связано.

И я того же мнения - но тогда не надо утверждать "получил сигнал - отрисовал"

Все наоборот, интерфейс должен предоставлять индикатор

Это с какого перепуга? Загрузчику вообще все равно, есть индикатор или нет. Его задача - загружать.
Основное правило: индикатор не может существовать без загрузчика -> следовательно, индикатор - это подчиненный. А значит, он и должен получать инфу от загрузчика, а не загрузчик должен знать о (возможно несуществующем) индикаторе.

Все верно, только "инфа != интерфейс" . Да, загрузчик керует, вот он и пишет данные в интерфейс предоставляемый индикатором.

[Igors]

Нет, это глупо, что-то спрашивать в асинхронной системе.

Как ни странно, флажок отмены не требует никаких средств синхронизации, достаточно его отдавать простым геттером. Так иногда бывает 

[Old]

Как ни странно, флажок отмены не требует никаких средств синхронизации, достаточно его отдавать простым геттером. Так иногда бывает 

Ну и что?

[Bepec]

Спор глухого с умным. Результат примерно тот же в этой теме

offtop: я предрекаю что тема загнётся через день

[Racheengel]

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

Откуда загрузчику знать, что где-то существует какой-то индикатор?
Это проблема индикатора - получить данные от загрузчика.
Умеет загрузчик слать сигналы - вешаемся на сигналы.
Умеет загрузчик только DoUpdate(this) - следим за его интерфейсом.
Думайте о загрузчике, как о "черном ящике", тогда все станет на места.

[Igors]

Откуда загрузчику знать, что где-то существует какой-то индикатор?
Это проблема индикатора - получить данные от загрузчика.

Попробуйте изобразить это для примера ReadVertices выше. Ну хоть "схематично" (я без понятия как реализовать Ваше предложение)   

Думайте о загрузчике, как о "черном ящике", тогда все станет на места.

Зато с раздачей рекомендаций все отлично 

[Vamireh]

Я что-то уже запутался. Если не рассматривать асинхронность, то все к callback'ам сводится, получается?
А вот подход с опросом по таймеру из GUI встречал неоднократно у коллег.

[Igors]

Я что-то уже запутался. Если не рассматривать асинхронность, то все к callback'ам сводится, получается?
А вот подход с опросом по таймеру из GUI встречал неоднократно у коллег.

По таймеру это другой ф-ционал/подход. Здесь индикатор знает подробности выполняемой операции (обычно в др нитке), положительная сторона - операции ничего самой делать не нужно. Отрицательная - плохо с общностью, нужно приспосабливать индикатор к каждой операции.

[_Bers]

Есть класс по загрузке неких файлов, например. В нем есть сигнал, который информирует о проценте загрузке. В слоте, соответственно, меняется значение QProgressBar. А как бы вы это сделали без Qt только на C++? Только идея интересует. boost:signals, собственный велосипед или еще что-то.

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

Просто понял, что меня бы подобная задача озадачила бы слегка. Коряво, сделал бы, но интересно как это сделают гуру.

как то так:

http://rextester.com/CEHV62401

Код:

//g++  4.9.3

#include <iostream>
#include <functional>


class loader
{
    using progress = std::function<bool(float)>;
public:
    template<class F> loader(F&& callback)
        :m_callbak( std::forward<F>(callback))
    {}
    
    void load(const size_t size)
    {
        sumulateLoading_(size);
    }
    
private:
    void sumulateLoading_(const size_t size)
    {
        if(!m_callbak)
            return std::cout <<"loading finished!\n",
            void();
        
        const auto total = static_cast<float>(size);
        
        for(size_t n=0; n<size; ++n)
            if(!m_callbak( n*100/total ))
                return std::cout <<"loading abort!\n", 
                void();
        
        std::cout <<"loading finished!\n";
    }
    
private:    
    progress m_callbak;    
};


int main()
{
    std::cout << "Hello, world!\n";
    
    const auto callback = [](const float v){ 
        std::cout <<"loading ... "<<v << "%\n";
        return v<90.0;
    };
    
    loader(callback).load(10);
}

output:

Hello, world!
loading ... 0%
loading ... 10%
loading ... 20%
loading ... 30%
loading ... 40%
loading ... 50%
loading ... 60%
loading ... 70%
loading ... 80%
loading ... 90%
loading abort!